Microsoft Edit

 (github.com/microsoft)
3 puan yazan GN⁺ 2025-06-26 | 1 yorum | WhatsApp'ta paylaş
  • Microsoft Edit, klasik MS-DOS Editor’e saygı duruşunda bulunan basit bir metin düzenleyicisidir
  • VS Code’a benzer modern bir arayüz ve giriş kontrolleri sunar
  • Geliştirme hedefi, terminale aşina olmayan kullanıcıların da erişebileceği bir düzenleme ortamı sunmaktır
  • Search and Replace özelliği için ICU kütüphanesine isteğe bağlı bağımlılık içerir
  • Paket yöneticileri için açık çalıştırılabilir dosya adlandırması ve ortam değişkeni seçenekleri rehberini içerir

Açık kaynak proje özeti

  • Microsoft Edit, basit işler için klasik editör tarzında bir metin düzenleyicisidir
  • MS-DOS Editor’ün modern bir yeniden yorumu olmasıyla öne çıkar ve VS Code tarzı tanıdık bir arayüz ile giriş biçimini uygular
  • Özellikle terminal kullanım deneyimi az olan kullanıcıların da kolayca kullanabileceği sadeliğe odaklanarak tasarlanmıştır

Özellikler ve işlevler

  • En düşük karmaşıklıkla temel metin düzenleme işlerini kolayca gerçekleştirebilir
  • Arayüz tanıdık bir his verir ve erişilebilirlik ile kullanım kolaylığını ön planda tutar
  • ICU (International Components for Unicode) kütüphanesine isteğe bağlı olarak bağımlıdır ve Search and Replace işlevini destekler

Paket yöneticileri ve paketleme sorumluları için notlar

Paket adlandırması

  • Varsayılan çalıştırılabilir dosya adı "edit", alternatif ad ise "msedit"’tir
  • Mevcut sistem komutu "edit" ile çakışma nedeniyle "msedit" gibi alternatif adlandırmalar önerilir
  • "ms-edit" gibi adlardan kaçınılması tavsiye edilir

ICU kütüphanesi adlandırması (SONAME)

  • ICU kütüphanesi Search and Replace özelliği için kullanılabilir
  • Her işletim sistemi için varsayılan olarak aranan kütüphaneler şunlardır
    • Windows: icuuc.dll
    • macOS: libicuuc.dylib
    • UNIX ve diğerleri: libicuuc.so
  • Sistem ortamına göre kütüphane adı (SONAME) farklıysa çeşitli ortam değişkenleri (EDIT_CFG_ICUUC_SONAME, EDIT_CFG_ICUI18N_SONAME vb.) ile ayarlanabilir
  • ICU export symbol adlandırma kurallarının farklı olduğu durumlar için ek ortam değişkenleri sunulur

Diğer

  • ICU yeniden adlandırmasını otomatik algılama, C++ sembol desteği gibi ek seçenekler vardır
  • Bu ayarların doğrulanması için cargo test -- --ignored komutuyla test yapılabilir

Sonuç

  • Sadelik ve erişilebilirliği önemserken aynı zamanda esnek ortam yapılandırması sunabilen açık kaynaklı bir editör
  • Geliştiriciler, açık kaynak katkıcıları ve paket yöneticileri için açık yönergeler ve yüksek uyumluluk sağlar

İlgili okumalar

1 yorum

 
GN⁺ 2025-06-26
Hacker News görüşleri

  • Bu sadece “canım istediği için yaptım” türü bir proje hikâyesi ama ben de bu şekilde bir şeyler yaparak iç çalışma mantığını anlama konusunda çok deneyim edinmiştim. Yine de Turbo Vision’ın FPC ile yeniden yazılıp birden fazla hedefi destekleyerek derlenen sürümü zaten yaklaşık 20 yıllık. Bence Turbo Vision gelmiş geçmiş en iyi metin modu pencere kütüphanesi. Asıl eğlence, tüm metin ekranını bir diziye eşleme kısmında başlıyor. var Screen: Array[1..80,1..25] Of Byte Absolute $B800 Sanırım buna benzer bir şeydi. Turbo Vision’ı gerçekten yenilikçi yapan şey, taşınabilir (non-)modal pencereleriydi. Yani sonuçta o diziyi döngüde sürekli yeniden yazıyordunuz. Oldukça hızlıydı. Ben de o kütüphaneyle epey gelir elde ettiğimi hatırlıyorum

    • Merak edenler için, güncel bir C++ Turbo Vision sürümü ve hatta Unicode destekli bir port da var: https://github.com/magiblot/tvision

    • TP’de diziler row-major idi. Bir karakter 2 bayttan oluşuyordu (harf + öznitelik). Bu yüzden hatta array[1..25, 1..80] of packed record ch: char; attr: byte end absolute $B800:0000 gibi bir kullanım kolaylığı da vardı. Monokrom metin ekranında $B800 yerine $B000 kullanmak yeterliydi. Örneğin Hercules gibi ortamlarda

    • VSCode’da böyle bir arayüz terminalde, hatta uzaktan bile çalışsa gerçekten harika olurdu

    • O kütüphaneyle nasıl para kazandığını merak ettim. Keşke işin sırrını anlatsa

    • Bu aralar çıkan her yeni TUI framework’üne baktığımda hep aynı şeyi düşünüyorum: “Turbo Vision kadar iyi değil”

  • Öte yandan Notepad’e AI Copilot gibi gereksiz bir şişkinlik zorla ekleniyor. Oysa Notepad’in özü, hiçbir fazlalık olmadan tek bir işi düzgün yapmasıydı diye hatırlıyorum

    • Yeni Edit de bu tür kararlardan tamamen bağımsız değil. Satya döneminde MS FOSS’u seviyormuş gibi davrandı ama Gates/Balmer dönemi Windows geliştiricileri için çok daha dostçaydı diye hatırlıyorum. Şimdi web/masaüstü framework’leri birbirine girmiş durumda ve şirket içinde bile pek kullanılmıyor gibi. Eskiden Visual Studio sihirbazları ya da eklentiler varken, şimdi CLI aracıyla Excel dosyası dump etme tarzı işlere dönmüş gibi. Nesiller arası Windows geliştirme kültürü farkı ve yönetim tarafındaki deneyim eksikliği açıkça görünüyor

    • Raymond Chen bir keresinde Notepad’in şaşırtıcı derecede çok testte kullanıldığını söylemişti. Basit bir araç ama deneysel amaçlarla sık sık kullanılıyor https://devblogs.microsoft.com/oldnewthing/20180521-00/?p=98795

    • Windows 11’deki yeni Paint’e bir ekran görüntüsü yapıştırdım; simge durumuna küçültülmüş olsa bile CPU’yu sürekli %5 kullanıyor ve yaklaşık 250 MB bellek tüketiyordu. RAM neyse de CPU’yu böyle harcamak pek kabul edilebilir gelmiyor. Eskiden bir kalite anlayışı ve bununla ilgili gurur vardı diye hatırlıyorum

    • ISP’de aralıklı bir sorun olduğunda (IPv4/MTU problemi), Notepad’de kaydetmek bile mümkün olmadı. Zorla kapatınca ancak yapılabildi. O sırada Wireguard ile geçici bir dolaşma ayarı yapıyordum

    • Modern notepad’i kaldırırsanız, Başlat menüsünde eski notepad’i arasanız da çıkmıyor

  • Yaklaşık bir ay önce MS’in Windows kullanıcılarına daha tanıdık gelecek bir Linux dağıtımı çıkardığından söz edildiğini hatırlıyorum. Hatırladığım kadarıyla sadece sade bir GNOME ortamıydı ve pek özel bir yanı yoktu. Oysa MS kendi Linux dağıtımını yaparken bash yerine powershell’i, vim/nano yerine Edit’i koyabilir, hatta .NET ya da Visual Studio Code’u varsayılan geliştirme araçları olarak ekleyebilirdi... MS bunu WSL’nin varsayılan dağıtımı olarak kullansaydı, savaşı kazanmasa bile kullanıcı payını artırabilirdi diye düşünüyorum. MS çekirdeği ele geçiremese de kullanıcı alanına (userland) hâkim olabilir. Birçok Windows kullanıcısını, varsayılan kurulum uygulamaları olarak doğal biçimde MS araçlarını kullanmaya yöneltebilirdi. Artık Microsoft Edit de Linux’ta kullanılabiliyor. Powershell gibi diğer uygulamalar da öyle. Eğer bu stratejiyi 10 yıl önce uygulamış olsaydı, bugün WSL’de bir MS dağıtımı ilk 5 içinde olabilirdi diye hayal ediyorum. Büyük şirketlerin (M$) benim kişisel bilgisayarıma kadar nüfuz edebilmesi biraz rahatsız edici. Sonunda bu Microsoft Edit’in de bir gün Co-Pilot ile varsayılan gelmesini hayal ediyorum

    • Bir gün MS’in en azından Windows Server ya da gömülü Windows gibi bazı alanlardan başlayarak yavaş yavaş Linux tarafına kayacağını düşünüyorum. Uzun vadede Windows masaüstü de kademeli olarak değişip “Windows Legacy” ve “Windows Linux Workstation” gibi seçenekler sunabilir. Linux çekirdeği + ayarlanmış WINE + bazı eski uygulamalar için entegre VM tarzı bir yapıya evrilmesini bekliyorum. Sorun şu ki NT çekirdeğinin tasarım olarak Linux’tan daha ileride olduğu birçok nokta var (örneğin GPU sürücüsünün tamamen çökmesinden sonra toparlanabilmesi). Ama Windows’un kendisi giderek bir varlıktan çok yüke dönüşüyor. Gerçekte MS’in büyüme motoru Azure ve Office 365; Windows lisansları ise neredeyse durgun. En azından Linux tabanlı Windows sunucu ve iş istasyonu görmek mümkün görünüyor

    • Azure Linux (eski adıyla CBL-Mariner), MS’in konteyner, VM ve sunucu kullanımı için yaptığı resmî Linux dağıtımıdır. Bunu, sıradan Windows kullanıcılarına yönelik bir kaplama ya da masaüstü ortamıyla karıştırmamak gerekir

    • MS’in eskiden yaptığı Linux dağıtımının adı “Xenix” idi ama pek başarılı olmadığını hatırlıyorum

    • WSL’nin ortaya çıkma sebebi, büyük şirketlerdeki geliştiricilerin Linux ortamına giderek daha çok ihtiyaç duymasıydı. IT destek ekipleri Linux’u pek bilmiyor ve desteklemek de istemiyordu. WSL bu sorunu çözdü. Gerçekten de birçok geliştirici Linux kullanmak istemiyor ve terminal konusunda da rahat değil. GUI araçlarına bağımlılar

    • MS’in Windows kullanıcılarının beklentilerine hitap etmek için gizlice kendi dağıtımını sürdürdüğü fikri biraz gerçek dışı geliyor

  • Bu haberin bir hafta içinde üç kez paylaşılacak kadar ilgi gördüğü anlaşılıyor

    1. Yazarın gönderisi - https://news.ycombinator.com/item?id=44034961
    2. Ubuntu resmî gönderisi - https://news.ycombinator.com/item?id=44306892
    3. Ve şimdi bu gönderi

  • Eskiden edit.com (DOS 6.22’den itibaren, sonra 7.0/Windows 95) benim ilk IDE’mdi. Başlangıçta qbasic vardı ve neredeyse edit.com ile aynı programdı. C/C++’ı djgpp ile öğrenirken de edit.com kullanmaya devam ettim. “Proje dosyam” e.bat idi; edit file1.cpp file2.cpp... şeklinde birden çok dosyayı tek seferde açabiliyordum. Diğer editörlerde çoklu dosya geçişi hantaldı ama alt-1,2,3... ile doğrudan geçebilmek hoşuma gidiyordu. Hâlâ bugün bir editörün kısayollarını değiştirirken bu tarzı korumaya çalışıyorum. Elbette kod editörü olarak çok da iyi değildi. Sözdizimi vurgulaması yoktu ve girinti desteği zayıftı (bu yüzden başta iki boşluk girinti kullanıyordum; elle yapmak daha kolaydı). Yine de yazdığım koda anında geri bildirim vermesi ve tanıdık hissettirmesi çok iyiydi. qedit gibi editörler de vardı ama bana göre değildi; Unix tarzı editörlerin DOS’ta pek uygun olmadığını düşünüyordum. Bu yeni editör çoklu tamponu destekliyor ama benim alıştığım tuş atama biçimini benimsememiş gibi görünüyor

    • Bunu issue olarak açmak iyi olabilir. Böyle geri bildirimler erken verilirse gerçekten uygulanabiliyor. Ayrıca bu gerçekten sadece benzer düzeyde değildi; edit.com, qbasic’in tek bir bayrak eklenerek başlatılmış hâliyle birebir aynıydı. Hatta ben qbasic’i o bayrakla doğrudan çalıştırırdım https://news.ycombinator.com/item?id=44037509

    • Sözdizimi vurgulaması yoktu ama sözdizimi büyük harfe çevirme vardı (örneğin ayrılmış anahtar sözcükleri otomatik büyük harf yapma). Mesela bir satırı tamamen küçük harfle yazsanız bile Enter’a bastığınızda ayrılmış sözcükler otomatik olarak büyük harfe dönüşürdü. Ufak bir şeydi ama oldukça kullanışlıydı

    • copy con dönemine kıyasla edit tam bir kurtarıcıydı

  • Birçok açıdan çok hoşuma gitti. Öncelikle, bağımlılığı olmayan tertemiz bir liste! Bayıldım. Tüm TUI’yi yalnızca bu editör için baştan yazmış olmaları inanılır gibi değil. Diyaloglar, dosya tarayıcısı bile var. Kendi projemde de denemek isterim. İçeriden birileri varsa, neden Ratatui kullanmadıklarını merak ediyorum. Kod kalitesi olağanüstü. Tek kelimeyle: Bravo!

  • Eskiden böyle bir metin editörü arayanlara micro’yu[1] önerirdim. Şimdi ne önereceğimden emin değilim

    • https://micro-editor.github.io/

    • Bence öneriyi değiştirmene gerek yok. edit, en azından benim denediğim kadarıyla, sözdizimi vurgulaması bile desteklemiyor

    • En son kontrol ettiğimde, micro’dan çok macro denmesi gerekecek kadar ikili dosya boyutu büyüktü

    • Bir diğer seçenek de dte[1]. Unicode desteği, CUA tuş atamaları gibi özelliklerle çok sade ama güçlü. nano yerine terminal editörü olarak memnunum https://craigbarnes.gitlab.io/dte/

    • Windows’ta winget install zyedidia.micro komutuyla kurulabiliyor. Eski 8-bit/16-bit dönem editörlerini andırıyor

  • MS gibi büyük bir organizasyonda böyle bir projenin nasıl onay aldığını gerçekten merak ediyorum. Sadece bir geliştiricinin yan projesi mi, ürün yol haritasının parçası mı, yoksa liderliği ikna etme süreci mi vardı, merak ediyorum

    • Metin editörleri, copilot entegrasyonu için son derece uygun hedefler

    • Gerekçe açıklamasından da anlaşılacağı üzere, komut satırında çalışan bir editöre ihtiyaç vardı (Windows Core Server kurulumları için), ayrıca SSH ile bağlanınca da kullanılabilmeliydi (Windows’a birkaç yıldır varsayılan olarak SSH sunucusu dahil geliyor) ve vi deneyimi olmayan Windows yöneticileri için modalsız bir editör ihtiyacı vardı. Bu ihtiyaçlar bu projeye yol açtı

    • Bazen ekiplerin bir tür kota doldurması gerekir ve bu yüzden fikirler ortaya atılır; bazen de bu işler lider talimatıyla başlar (copilot kullanımı gibi) ya da hackathon benzeri etkinliklerden çıkıp büyür. Araştırma organizasyonlarında teknik personel boşta kaldığında böyle şeyler çıkabiliyor ya da uzun analizlerden sonra ancak bütçe alabiliyor. Sadece committer sayısına bakınca bile bunun oldukça stratejik bir yatırım olduğu anlaşılıyor. Bir gecede ortaya çıkmış bir proje değil

  • Eski EDLIN’in Unicode destekli bir sürümünün gelmesini isterdim. EDLIN’de toplu iş dosyasından tuş girişlerini pipe ederek belli işleri otomatikleştirmek mümkündü. Bir bakıma sed ya da awk’ın bazı kullanım alanlarının yerine geçebiliyordu. vi da benzer bir mimariye sahip olabilir diye düşünüyorum ama bunun ne kadar anormal olduğu ayrı mesele

    • Sanırım aradığın şey ed. -s seçeneğiyle tam script’lik olur

  • İlgili tartışma (271 puan, 185 yorum) https://news.ycombinator.com/item?id=44031529