7 puan yazan GN⁺ 2025-02-24 | 1 yorum | WhatsApp'ta paylaş
  • mdq, Markdown belgelerinde belirli bölümleri kolayca bulmanıza yardımcı olan bir araç
  • GitHub PR'leri gibi Markdown belgelerinde belirli şablonları veya kontrol listelerini doğrularken kullanışlı
    • Örneğin, tamamlanmamış görevleri bulmak için mdq '- [ ]' komutunu kullanabilirsiniz

Temel kullanım

  • "usage" içeren bölümü seçme: cat example.md | mdq '# usage'
  • Filtreler zincirlenerek kullanılabilir: cat example.md | mdq '# usage | -'
  • Hata raporu göndermeden önce mevcut issue'ların arandığını doğrulama: mdq -q '- [x] I have searched for existing issues'
  • Referans ticket çıkarma: PR bir ticket'tan bahsettiğinde, Markdown'dan bağlantıları JSON olarak çıkarıp jq ile URL'yi alabilirsiniz.
    TICKET_URL="$(echo "$PR_TEXT" | mdq --output json '# Ticket | [](^https://tickets.example.com/[A-Z]+-\d+$)' | jq -r '.items[].link.url')"
  • Büyük tabloları daraltma: Belirli bir tarih veya kişinin nöbet planını bulmak için tabloyu filtreleyebilirsiniz.
    • Alice'in nöbet tarihlerini bulma: cat oncall.md | mdq ':-: /On-Call|Alice/:-: *'
    • 15 Ocak 2024 haftasının nöbetçi kişisini bulma: cat oncall.md | mdq ':-: * :-: 2024-01-15'

1 yorum

 
GN⁺ 2025-02-24
Hacker News görüşleri
  • GitHub PR'leri Markdown belgeleridir ve bazı organizasyonlar, tüm inceleyenlerin tamamlaması gereken kontrol listeleri içeren belirli şablonlar kullanır

    • Bu tür özellikleri zorunlu kılmak için karmaşık düzenli ifadeler kullanmak gerekir; bunları yazmak zordur ve hata ayıklamak daha da zordur
    • GitHub gerekli özelliği geliştirmek yerine yapay zekaya odaklanıyor
    • Bitbucket, açıklama kutusunun dışında onay kutusu listeleri kullanarak PR'leri engelleyebilme özelliği sunuyor
    • Bu sorunu çözmenin daha iyi bir yolu var; OP'nin README dosyasındaki ilk örneğe bakabilirsiniz
    • Harika bir proje ve bu aralar çoğunlukla MDX yazdığım için bu lehçeye destek görmek güzel olurdu
  • Markdown gibi metin tabanlı dosya biçimlerinin popüler olmasının nedenlerinden biri, düzenli ifadelerle ayrıştırılabilmeleri ve sürüm kontrolüyle yönetilebilmeleriydi

  • Benim iş akışım, Pandoc JSON AST üzerinden geçip ardından Jq kullanmak

    • Bu, diğer girdi biçimlerinde de çalışıyor
  • Paylaştığın için teşekkürler, inceleyeceğim

    • Ben de buna benzer bir şey istiyordum
  • Pek çok şeyi denedikten sonra, kullanmayı sürdürdüğüm tek "not sistemi", değişiklik olduğunda otomatik olarak git'e commit edilen Markdown dosyalarından oluşan bir dizin oldu

  • İşleri takip etmeye yardımcı olacak biraz akıllı özellik eklemek istedim

    • Örneğin tamamlanan görevleri temizlemek, tamamlanmayan görevleri ertesi günün günlüğüne taşımak ve "projeler" içinden görevleri toplamak gibi
    • Bunun için markdown-rs kullanarak biraz Rust kodu yazmaya başladım
    • Değişikliklerle birlikte Markdown'u round-trip yapabilmek için şu anda yalnızca GitHub tarzı Markdown'u serileştiren kütüphanenin JavaScript sürümü destekleniyor
    • Bu yüzden Rust'ta Markdown AST'yi JSON olarak döküp JavaScript'te serileştirerek bir kavram kanıtı yaptım
    • markdown-rs konum bilgisini saklıyor ama kaynak token bilgisini saklamıyor
    • Bu nedenle güvenilir bir round-trip mümkün değil
  • Markdown belgelerine ağaç gibi davranmak istiyordum

    • Başlıklara göre bölümleri çıkarmak için xpath benzeri bir dil kullanmak istiyordum
    • Her hâlükârda kodu inceleyeceğim, paylaştığın için teşekkürler
  • MarkdownDB, Markdown dosyaları için SQLite backend'i sağlıyor

    • .md dosyalarının yapısına her zaman veri serileştirme hedefi olarak saygı gösterilmediğini ya da bunun dikkate alınmadığını hissediyorum
  • Paylaştığın için teşekkürler; şu anda benim için doğrudan bir kullanım senaryosu yok ama böyle bir şeyin var olduğunu bilmek güzel

  • Belgelenmiş shell çağrılarıyla ilgili küçük bir noktaya değinmek istedim

    • Örneğin, cat example.md | mdq '# usage' komutu, gereksiz cat sürecini çağırmamak için stdin dosya yönlendirmesiyle değiştirilebilir
    • Benzer şekilde, echo "$ISSUE_TEXT" | mdq -q '- [x] I have searched for existing issues' de gereksiz echo sürecinden kaçınabilir
  • README'ye daha gerçekçi örnekler eklemek iyi olabilir

    • Kullanım amacını sezgisel olarak anlamayan kişiler için faydalı olur
  • Mevcut araçları ve kütüphaneleri incelerken öğrendiğim ilginç bir şey, birçok aracın yapılandırılmış çıkarma/manipülasyon yapmadan önce Markdown'u HTML'ye serileştirmesi oldu

    • Markdown, HTML'ye serileştirilmek üzere tasarlandığı için Markdown belgesi/AST temelde ağaç yapısı değildir
    • Bunun yerine, belgede göründükleri sıraya göre dizilmiş öğelerden oluşan bir listedir
    • Yalnızca listeler ve blok alıntılar iç içe geçmeyi destekler
    • Örneğin, h1 -> paragraf -> h2 -> paragraf iç içe değildir; sıralı dört öğeden oluşan bir dizidir
    • Cursor veya Copilot'a HTML kullanan bir uygulamayı test ettirirseniz daha hızlı geliştirme yapabilirsiniz
  • Bu aracı tam da ihtiyacım olan anda bulmuş gibiyim

    • Belirli bir görev için mükemmel uyacak
  • Yuval'a bu aracı paylaştığı için teşekkürler ve işte kullanabilmemiz için izin verici bir lisans seçtiği için de minnettarım