Bagaimana editor kode secara efektif memberi petunjuk pada level kode bersarang - tanpa menggunakan indentasi? [Tutup]


233

Saya telah menulis editor teks XML yang menyediakan 2 opsi tampilan untuk teks XML yang sama, satu indentasi (secara virtual), yang lain dibenarkan kiri. Motivasi untuk tampilan yang dibenarkan kiri adalah untuk membantu pengguna 'melihat' karakter spasi putih yang mereka gunakan untuk lekukan teks biasa atau kode XPath tanpa gangguan dari lekukan yang merupakan efek samping otomatis dari konteks XML.

Saya ingin memberikan petunjuk visual (di bagian editor yang tidak dapat diedit) untuk mode yang dibenarkan kiri yang akan membantu pengguna, tetapi tanpa terlalu rumit.

Saya mencoba hanya menggunakan jalur penghubung, tapi itu sepertinya terlalu sibuk. Sejauh ini yang terbaik yang saya hasilkan ditunjukkan dalam screenshot tiruan editor di bawah ini, tetapi saya mencari alternatif yang lebih baik / lebih sederhana (yang tidak memerlukan terlalu banyak kode).

editor kode indikasi tingkat bersarang

[Sunting]

Mengambil ide heatmap (dari: @imp) saya mendapatkan ini dan 3 alternatif - berlabel a, b dan c:

Ide awal

Bagian berikut menjelaskan jawaban yang diterima sebagai proposal, menyatukan ide-ide dari sejumlah jawaban dan komentar lainnya. Karena pertanyaan ini sekarang adalah wiki komunitas, silakan perbarui ini.


NestView

Nama untuk gagasan ini yang menyediakan metode visual untuk meningkatkan keterbacaan kode bersarang tanpa menggunakan lekukan.

Garis Kontur

Nama untuk garis yang diarsir berbeda dalam NestView

masukkan deskripsi gambar di sini

Gambar di atas menunjukkan NestView yang digunakan untuk membantu memvisualisasikan cuplikan XML. Meskipun XML digunakan untuk ilustrasi ini, setiap sintaks kode lain yang menggunakan nesting dapat digunakan untuk ilustrasi ini.

Gambaran:

  1. Garis kontur diarsir (seperti dalam peta panas) untuk menyampaikan tingkat bersarang

  2. Garis kontur miring untuk menunjukkan kapan level bersarang dibuka atau ditutup.

  3. Garis kontur menautkan mulai dari level bersarang ke ujung yang sesuai.

  4. Lebar garis kontur yang digabungkan memberikan kesan visual tingkat bersarang, di samping peta panas.

  5. Lebar NestView mungkin dapat diubah ukurannya secara manual, tetapi tidak boleh berubah karena kode berubah. Garis kontur dapat dikompres atau dipotong untuk mempertahankannya.

  6. Baris kosong terkadang menggunakan kode untuk memecah teks menjadi potongan-potongan yang lebih mudah dicerna. Baris seperti itu dapat memicu perilaku khusus di NestView. Misalnya peta panas dapat diatur ulang atau garis kontur warna latar belakang digunakan, atau keduanya.

  7. Satu atau lebih garis kontur yang terkait dengan kode yang dipilih saat ini dapat disorot. Garis kontur yang terkait dengan tingkat kode yang dipilih akan paling ditekankan, tetapi garis kontur lain juga bisa 'menyala' di samping untuk membantu menyoroti grup bertingkat yang mengandung

  8. Perilaku yang berbeda (seperti pelipatan kode atau pemilihan kode) dapat dikaitkan dengan mengklik / mengklik dua kali pada Garis Kontur.

  9. Bagian garis kontur yang berbeda (ujung depan, tengah, atau belakang) mungkin memiliki perilaku dinamis yang berbeda.

  10. Tooltips dapat ditampilkan pada acara mouse di atas garis kontur

  11. NestView diperbarui terus-menerus saat kode diedit. Di mana asumsi bersarang tidak seimbang dapat dibuat di mana level bersarang harus berakhir, tetapi garis kontur sementara yang terkait harus disoroti dalam beberapa cara sebagai peringatan.

  12. Perilaku seret dan lepas dari Garis Kontur dapat didukung. Perilaku dapat bervariasi sesuai dengan bagian garis kontur yang diseret.

  13. Fitur yang biasa ditemukan di margin kiri seperti penomoran baris dan penyorotan warna untuk kesalahan dan perubahan kondisi dapat menutupi NestView.

Fungsi Tambahan

Proposal membahas berbagai masalah tambahan - banyak di luar ruang lingkup dari pertanyaan awal, tetapi efek samping yang bermanfaat.

Menautkan secara visual awal dan akhir wilayah bersarang

Garis kontur menghubungkan awal dan akhir setiap tingkat bersarang

Sorot konteks dari baris yang dipilih saat ini

Saat kode dipilih, level sarang terkait di NestView dapat disorot

Membedakan antara wilayah kode pada tingkat bersarang yang sama

Dalam kasus XML, warna yang berbeda dapat digunakan untuk ruang nama yang berbeda. Bahasa pemrograman (seperti c #) mendukung daerah bernama yang dapat digunakan dengan cara yang sama.

Membagi area dalam area bersarang menjadi blok visual yang berbeda

Garis ekstra sering dimasukkan ke dalam kode untuk membantu keterbacaan. Baris kosong seperti itu dapat digunakan untuk mereset level saturasi garis kontur NestView.

Tampilan Kode Multi-Kolom

Kode tanpa lekukan membuat penggunaan tampilan multi-kolom lebih efektif karena pembungkus kata atau pengguliran horizontal cenderung tidak diperlukan. Dalam tampilan ini, setelah kode mencapai bagian bawah satu kolom, kode akan mengalir ke yang berikutnya:

masukkan deskripsi gambar di sini

Penggunaan lebih dari sekadar memberikan bantuan visual

Seperti yang diusulkan dalam ikhtisar, NestView dapat menyediakan serangkaian fitur pengeditan dan seleksi yang akan secara luas sejalan dengan apa yang diharapkan dari kontrol TreeView. Perbedaan utama adalah bahwa simpul TreeView khas memiliki 2 bagian: ikon expander dan ikon node. Garis kontur NestView dapat terdiri dari 3 bagian: pembuka (miring), konektor (vertikal) dan tutup (miring).


Pada Indentasi

NestView disajikan bersama pelengkap kode tanpa lekukan, tetapi tidak mungkin untuk menggantikan, tampilan kode lekukan konvensional.

Kemungkinan setiap solusi yang mengadopsi NestView, akan menyediakan metode untuk beralih secara mulus antara tampilan kode indentasi dan non-indentasi tanpa mempengaruhi teks kode itu sendiri - termasuk karakter spasi putih. Salah satu teknik untuk tampilan lekukan adalah 'Pemformatan Virtual' - di mana margin kiri dinamis digunakan sebagai pengganti karakter tab atau spasi. Data tingkat sarang yang sama yang digunakan untuk secara dinamis membuat NestView juga dapat digunakan untuk tampilan indentasi yang lebih konvensional.

Pencetakan

Lekukan akan menjadi penting untuk keterbacaan kode cetak. Di sini, tidak adanya karakter tab / spasi dan margin kiri dinamis berarti bahwa teks dapat membungkus pada margin kanan dan tetap mempertahankan integritas tampilan indentasi. Nomor baris dapat digunakan sebagai penanda visual yang menunjukkan di mana kode dibungkus dengan kata dan juga posisi indentasi yang tepat:

masukkan deskripsi gambar di sini

Layar Real-Estate: Flat Vs Indented

Mengatasi pertanyaan apakah NestView menggunakan real-estate layar yang berharga:

Garis kontur berfungsi dengan baik dengan lebar yang sama dengan lebar karakter editor kode. Oleh karena itu, lebar NestView dengan 12 karakter dapat mengakomodasi 12 level sarang sebelum garis kontur dipotong / dikompresi.

Jika tampilan lekukan menggunakan 3 karakter-lebar untuk setiap level bersarang maka ruang disimpan hingga bersarang mencapai 4 level bersarang, setelah level bersarang ini, tampilan datar memiliki keunggulan hemat-ruang yang meningkat dengan setiap level bersarang.

Catatan: Lekukan minimum 4 lebar karakter sering direkomendasikan untuk kode, namun XML sering kali mengelola dengan kurang. Juga, Pemformatan Virtual memungkinkan lekukan yang lebih sedikit untuk digunakan karena tidak ada risiko masalah penyelarasan

Perbandingan 2 tampilan ditampilkan di bawah ini:

masukkan deskripsi gambar di sini

Berdasarkan hal di atas, mungkin adil untuk menyimpulkan bahwa pilihan gaya tampilan akan didasarkan pada faktor-faktor selain layar real-estate. Satu-satunya pengecualian adalah di mana ruang layar berada pada premium, misalnya pada Netbook / Tablet atau ketika beberapa kode jendela terbuka. Dalam kasus ini, NestView yang dapat diubah ukurannya tampaknya menjadi pemenang yang jelas.

Gunakan Kasing

Contoh-contoh dunia nyata di mana NestView mungkin merupakan opsi yang berguna:

  1. Di mana layar real-estat berada di premium

    Sebuah. Pada perangkat seperti tablet, notes, dan ponsel cerdas

    b. Saat menampilkan kode di situs web

    c. Ketika beberapa kode windows perlu terlihat di desktop secara bersamaan

  2. Dimana lekukan spasi putih yang konsisten dari teks dalam kode adalah prioritas

  3. Untuk meninjau kode yang sangat bersarang. Misalnya di mana sub-bahasa (misalnya Linq di C # atau XPath di XSLT) dapat menyebabkan tingkat bersarang yang tinggi.

Aksesibilitas

Pengubahan ukuran dan opsi warna harus disediakan untuk membantu mereka yang memiliki gangguan penglihatan, dan juga agar sesuai dengan kondisi lingkungan dan preferensi pribadi:

masukkan deskripsi gambar di sini

Kesesuaian kode yang diedit dengan sistem lain

Sebuah solusi yang menggabungkan opsi NestView idealnya mampu menghilangkan karakter tab dan spasi terkemuka (diidentifikasi sebagai hanya memiliki peran format) dari kode yang diimpor. Kemudian, setelah ditelanjangi, kode tersebut dapat ditampilkan dengan rapi di tampilan kiri-kanan dan lekukan tanpa perubahan. Bagi banyak pengguna yang mengandalkan sistem seperti penggabungan dan alat diff yang tidak sadar spasi ini akan menjadi perhatian utama (jika bukan show-stopper lengkap).


Pekerjaan lain:

Visualisasi Markup yang Tumpang tindih

Penelitian yang diterbitkan oleh Wendell Piez , tertanggal dari 2004, membahas masalah visualisasi markup yang tumpang tindih, khususnya LMNL . Ini termasuk grafik SVG dengan kemiripan yang signifikan dengan proposal NestView, sehingga diakui di sini.

Perbedaan visualnya jelas pada gambar (di bawah), perbedaan fungsional utama adalah bahwa NestView hanya dimaksudkan untuk XML atau kode yang tersusun rapi, sedangkan grafik Wendell Piez dirancang untuk mewakili penyarangan yang tumpang tindih.

masukkan deskripsi gambar di sini

Grafik di atas direproduksi - dengan izin baik - dari http://www.piez.org

Sumber:

  1. Menuju Markup Hermenutik
  2. Setengah langkah menuju LMNL

6
Saya tidak punya jawaban nyata untuk Anda, hanya pendapat. Melihat contoh Anda, B adalah pilihan yang saya sukai. Itu menonjol bagi saya karena "peta panas" benar-benar mengikuti indentasi alih-alih mencerminkannya seperti contoh pertama dan C lakukan. A juga mengikuti indentasi yang sebenarnya, tetapi B lebih seperti apa yang akan Anda lihat ketika xml yang sebenarnya akan indentasi. Contoh kedua terlalu "solid" untuk seleraku.
Marjan Venema

4
Saya lebih suka kode indentasi sendiri. Tidak yakin apa manfaatnya ini? Apakah saya kehilangan sesuatu yang jelas? (Benar-benar tidak bermaksud ini kedengarannya negatif.)
Chris

9
Saya gagal melihat bagaimana mengambil margin besar pada 100% dari garis lebih baik daripada hanya mengambil margin sebanyak yang dibutuhkan setiap baris.
John Gietzen

1
@ John Gietzen. Tujuannya bukan untuk menyimpan layar real-estate (meskipun ini mungkin efeknya dalam banyak kasus). Ini untuk memungkinkan kontrol yang lebih ketat dari karakter spasi ketika itu penting - tampilan lekukan masih akan diberikan (tetapi virtual, tanpa menggunakan karakter padding).
pgfearo

3
Saya memberikan suara untuk menutup pertanyaan ini sebagai di luar topik karena ini adalah pertanyaan UX tetapi terlalu tua untuk dimigrasi.
ratchet freak

Jawaban:


104

Saya telah mencoba untuk menjawab pertanyaan saya sendiri di sini, tetapi ini menggabungkan ide peta panas dari @imp dan juga ide 'membuatnya lebih XML-ish' dari @Andrea:

masukkan deskripsi gambar di sini

Mudah-mudahan, warna-warna di peta panas bersama dengan garis sudut membantu menarik mata antara tag awal dan akhir; menghapus pemisah garis horizontal meningkatkan 'aliran' dari awal hingga akhir. Saat pengguna memilih dengan elemen bagian yang cocok dalam peta panas dapat disorot dalam beberapa cara - mungkin dengan perbatasan bercahaya (seperti yang ditunjukkan).

Sunting Telah memutuskan untuk mengikuti ini, mungkin harus ada opsi pengguna untuk warna. Tangkapan layar 'siap produksi':

masukkan deskripsi gambar di sini

Dan untuk perbandingan ... tampilan indentasi alternatif:

masukkan deskripsi gambar di sini

Sunting Sekarang, untuk kasing yang lebih berat - menguji kemampuan menggambar saya ...

masukkan deskripsi gambar di sini


1
Tampak hebat ! Kerja bagus. Tetapi bagaimana kelihatannya bila ada lebih banyak lekukan?
Loïc Lopes

1
@ Louhike Terima kasih! Ya, maksimal di 4 level dan saya tidak ingin meregangkan margin kiri untuk lebih - jadi saya akan mengompres lebar bar vertikal semakin meningkat pada level bersarang yang lebih tinggi - sedikit seperti peta kontur semoga.
pgfearo

2
@ Louhike. Saya telah menambahkan gambar ekstra untuk menunjukkan bagaimana hal-hal dapat terlihat dengan 9 level sarang - setelah sekitar 15 level mungkin perlu untuk menggabungkan bar tengah, mungkin menggunakan gradien fill.
pgfearo

10
Ini luar biasa. +1 untuk membawa pengeditan kode dan antarmuka pengguna ke tingkat berikutnya. Seseorang dengan akun harus memposting ini ke Hacker News, /.atau r / pemrograman.
Konrad Rudolph

2
Ingin tahu seperti apa bentuknya dengan bilah samping terbalik secara horizontal ... imgur.com/u5mNi
chanux

24

Satu ide mungkin untuk mencoba dan menambahkan 3D ke teks. Menambah / mengurangi ukuran font berdasarkan level apa itu.

Misalnya, kode ini:

masukkan deskripsi gambar di sini

Akan terlihat seperti ini:

masukkan deskripsi gambar di sini

Itu mungkin mengganggu untuk bekerja karena kehilangan penjajaran ukuran teks tetap di berbagai tingkatan. Ide lain; ubah saturasi setiap level:

masukkan deskripsi gambar di sini

Seberapa baik itu bertahan untuk sesuatu yang sangat dalam? Tidak yakin...

Saya sebenarnya sangat menyukai ide visualisasi selokan Anda; mudah untuk mengelompokkan berbagai hal bersama. Mungkin dikombinasikan dengan salah satu dari ide-ide ini itu akan terlihat lebih baik, atau jauh lebih jelek. ;)


Beberapa waktu yang lalu saya melakukan peta panas yang menunjukkan ruang lingkup di C. Mungkin menyenangkan untuk melihat untuk brainstorming:

masukkan deskripsi gambar di sini

Rata kiri:

masukkan deskripsi gambar di sini


2
Sangat menggoda untuk melakukan sesuatu dengan teks, tetapi ini sulit dilakukan tanpa mengganggu pengembang saat mereka mengetik atau sesudahnya. Perubahan yang memengaruhi ketinggian font menyebabkan masalah - mungkin kita mentolerir melihat kode kita naik dan turun bahkan kurang dari sisi ke sisi. Saya suka ide Anda menaungi kode, tetapi ini harus halus karena saya ingin mencoba dan menjaga hal-hal tampak berantakan.
pgfearo

2
tetapi ini akan bagus untuk lingkungan pengajaran!
jcolebrand

Saran ukuran font anehnya menarik - saya bisa melihat kekurangannya. Mengapa tidak membuat font yang lebih kecil karena ruang lingkupnya lebih dalam bersarang - ini akan membantu mencegah bersarang dalam (meskipun itu akan menyebabkan masalah di mana bersarang dalam sebenarnya merupakan solusi yang masuk akal)
Peter

2
peta panas ini sebenarnya jauh lebih baik dalam memvisualisasikan ruang lingkup daripada visualisasi lingkup selaras-kiri (solusi @ pfgearo)
Sandeep

@ Tetaplah. Saya setuju bahwa ini dalam banyak kasus merupakan solusi yang lebih baik - terutama ketika meninjau kode daripada mengeditnya. Kendala teknis (seperti yang mudah-mudahan dijelaskan dalam pertanyaan) mempersulit saya untuk memodifikasi warna latar belakang dengan kontrol saat ini yang saya gunakan. Secara efektif, saya telah menggunakan sisi kiri dari peta panas dalam jawaban ini - tetapi dengan tepi miring ke arah area yang diedit untuk membantu menarik perhatian. Salah satu masalah dengan latar belakang teks berwarna adalah bahwa keterbacaan / kontras hilang pada tingkat yang lebih tinggi tingkat bersarang.
pgfearo

21

Hanya mengubah ide asli Anda dan beralih dari kotak ke kapsul. Saya pikir versi ini (termasuk yang asli Anda) lebih mudah dibaca karena mereka kurang kompleks daripada yang menunjukkan bersarang melalui elemen tampilan bersarang. Saya pikir elemen pohon menyampaikan informasi dengan cara yang lebih sederhana dan lebih intuitif.

kapsul

Saya pikir sisi kiri bagus untuk menunjukkan indentasi secara langsung, sementara sisi kanan lebih baik dalam menyampaikan hubungan yang bersarang.


2
Saya lebih suka kelembutan kapsul Anda, tetapi mereka tampaknya terlalu terpisah dari teks, saya butuh sesuatu yang lebih kohesif dan memberikan pandangan yang lebih jelas tentang apa bagian yang mengandung.
pgfearo

9

Ide saya:

Sarang itu lebih mirip sarang. Lebar horizontal setiap lapisan tidak harus terlalu lebar.


Saya pikir apa yang Anda usulkan pada dasarnya sama dengan jawaban (terinspirasi oleh orang lain) yang saya berikan tetapi tanpa garis miring. Saya pikir garis miring membantu menarik mata antara membuka dan menutup dengan lebih baik. Lebar bukan masalah nyata karena (seperti yang ditunjukkan pada gambar 9-tingkat) lebar garis vertikal tidak tergantung dari lebar garis miring, sehingga garis vertikal dapat dikompresi.
pgfearo

Ya, hal- Saya perhatikan setelah saya memposting. Mereka identik secara topografi - untuk membiasakan diri. Ini masalah selera saya kira, tetapi versi saya hanya berteriak "bersarang" kepada saya dengan cara yang tidak versi Anda. Mungkin fitur ini dapat mendukung keduanya dan memungkinkan pengguna untuk memilih.
broc7

8

Saya suka ide itu. Saran saya untuk menjaga "sibuk" adalah untuk menggunakan gradien alih-alih kotak. Itu akan memotong garis. Mungkin warna berbeda untuk lekukan ekstrem.

Saya akan mengatakan semua yang Anda miliki bagus, meskipun sedikit kuning untuk selera saya.

Komentar saya: Saya selalu berjuang dengan cara Visual Studio IDE melakukan lekukan. Saya ingin menggunakan sesuatu seperti ini atau variasi.

Jadi bayangkan tautan itu tanpa garis, dan segaris dengan xml / kode Anda saat ini.


Ya, idenya masih terus berkembang. Gambar dalam jawaban yang saya kirimkan (bukan pertanyaan saya) kurang kuning karena memiliki kemiringan depan / belakang, saya mempertimbangkan untuk menggunakan gradien (tapi sedikit berbeda) juga untuk sedikit menurunkan nada. Saya bersama Anda dengan warna yang berbeda, untuk indentasi tinggi, tetapi juga untuk menyoroti hal-hal seperti komentar atau kesalahan. Dan kemudian ada penyorotan dinamis, untuk menunjukkan konteks saat ini / debugging ... kesulitannya akan dalam menilai kapan harus berhenti.
pgfearo

5

Karena Anda mengatakan visualisasi harus ada di margin yang tidak dapat diedit (kiri?), Saya percaya bahwa maksud visualisasi tidak dapat diintegrasikan atau berada di belakang kode.

Mungkin peta panas di kolom kiri, dengan warna-warna cerah yang menunjukkan lekukan yang lebih dalam? Jadikan margin sebagai ukuran tetap, dengan visualisasi seperti apa yang Anda miliki (harapkan dari kiri ke kanan seperti lekukan) yang secara dinamis menggunakan semua ruang yang diberikan sesuai dengan lekukan maksimum yang ditentukan oleh kedalaman DOM.

Jika Anda bersedia untuk bercabang ke wilayah editor, saya akan menyarankan sesuatu yang sangat mirip, tetapi sebagai latar belakang dokumen. Daerah yang diarsir akan di mana spasi akan jika lekukan yang diaktifkan. Dalam hal ini, saya akan menggunakan warna yang terang dan terang yang kontras dengan penyorotan teks.


@ jimp Ya, visualisasi tidak bisa dengan atau di belakang kode - sebanyak yang saya ingin coba ini, keterampilan pengkodean / platform saya akan membuat ini terlalu rumit. Warna latar belakang dalam editor itu sendiri sekali lagi sulit, tetapi itu memberi saya ide bahwa saya bisa mencoba nada warna latar depan yang berbeda. Saya akan mencoba bilah kiri ke kanan dan memanaskan peta juga seperti yang Anda sarankan.
pgfearo

+1 untuk ide peta panas (Y) .. dan saya dapat menyarankan level bersarang berada di dalam warna untuk orang-orang dengan kebutuhan khusus visual (seperti buta warna).
M.Sameer

@sederhana sekali. Memperbarui pertanyaan saya untuk mengilustrasikan ide peta panas Anda, yang saya suka, tapi saya pikir saya salah dari kiri ke kanan yang salah ...
pgfearo

@pgfearo Saya senang ide saya membantu! Berdasarkan apa yang saya lihat telah Anda lakukan, saya pikir saya lebih menyukai L&F kanan-ke-kiri. Maaf saya tidak mendapat kesempatan untuk memeriksanya kembali sebelum sekarang (akhir pekan yang sibuk). Karena Anda telah membuat banyak kemajuan, saya hanya akan mengomentari jawaban yang Anda posting di atas.
jimp

@pgfearo Ups, saya tidak memiliki reputasi yang cukup untuk mengomentari jawaban Anda! Saya akan memposting beberapa pemikiran pada jawaban Anda setelah saya mendapatkan hak istimewa itu, semoga segera!
jimp

3

jGRASP melakukan ini dengan menggunakan penanda visual di margin:

masukkan deskripsi gambar di sini

Bahkan mengenali ketika Anda menggunakan loop dan menggunakan jenis garis yang berbeda untuk mewakili loop batin itu.

Saya pikir saya akan menunjukkan bagaimana editor yang ada melakukannya.


5
Terlalu berisik menurut saya tapi masih ide bagus.
Konrad Rudolph

Saya telah melihat ini, dan situs documentatin menyiratkan bahwa tangkapan layar berasal dari penampil kode, ini diagram, bukan editor kode. Juga, tentu saja tidak ada karakter padding tetapi masih berupa lekukan. Saya mencari solusi sederhana yang tidak memerlukan lekukan kode, karena alasan yang diberikan dalam pertanyaan. Yang mengatakan, JGrasp terlihat seperti alat yang sangat baik untuk meningkatkan kelengkapan kode.
pgfearo

JGrasp seharusnya menjadi editor kode di sekolah saya, kami menggunakannya dalam pengantar kami untuk kelas ilmu komputer, itu adalah editor kode yang direkomendasikan. Ini memiliki alat untuk membantu mengkompilasi dan menjalankan program Anda, tetapi tidak semewah Eclipse atau Netbeans. Tetapi ini sedikit berbeda dari apa yang Anda gambarkan sebagai tujuan yang sebenarnya tidak umum dan hanya benar-benar mengetahui sintaks java.
ash

3

Bukan ide yang buruk tetapi harus merujuk margin kiri untuk melihat dengan jelas blok saya mungkin sedikit mengganggu. Itu bahkan tidak memikirkan layar real-estate atau hal-hal apa yang akan mulai terlihat jika struktur menjadi sangat dalam.

Karena motivasinya adalah untuk membantu pengguna 'melihat' karakter spasi putih yang mereka gunakan untuk indentasi, Anda bisa menunjukkan kepada mereka karakter spasi putih.

Saya tidak berbicara karakter visual khusus seperti penanda paragraf, hanya highlight. Spasi berwarna kuning, tab berwarna hijau (atau apa pun)

Untuk masalah margin / nesting, Anda bisa memindahkan margin untuk setiap blok. Tidak ada yang mengatakan margin harus berupa garis lurus.

Saya yakin ini bukan ide baru.

Sesuatu seperti ini:

sampel xml menunjukkan margin kiri bergerak dan sorot spasi putih


Dengan tampilan lekukan rencananya adalah untuk menerangi ruang putih secara dinamis, mirip dengan ide Anda. Juga, ingat bahwa dalam tampilan datar 30 tingkat sarang mengambil ruang yang sama dengan 1 tingkat, indentasi, itu akan berada di ujung layar Anda, itulah salah satu alasan mengapa pengembang diberi pilihan tampilan.
pgfearo

1
Ya itu sebabnya saya mengatakan itu bukan ide baru. Namun jika level indentasi adalah logaritmik atau dinamis berdasarkan level yang saya edit saat ini, Anda tidak akan memiliki masalah yang Anda bicarakan. Bahkan jika itu hanya diperbaiki pada 1 ruang, itu tidak akan keluar layar. Anda bahkan tidak akan setengah jalan di layar 80 karakter lama. Ya dengan beberapa dari ide-ide ini 30 level membutuhkan ruang yang sama dengan 1 level, tetapi ketika Anda melihat beberapa dari ini tidak menghemat ruang hanya karena indentasi, mereka hanya memasukkan semua dan menambahkan beberapa grafik mewah.
Justin Ohms

Ohm Sekarang ada bagian di layar real-estate dalam pertanyaan (ini adalah wiki komunitas dan semua), ini termasuk perbandingan tangkapan layar. Jika Anda dapat memperbarui bagian ini dengan pengamatan Anda sendiri, itu akan sangat bagus. Harap terima bahwa saya adalah penggemar berat pandangan indentasi (bekerja di dunia XML dan lainnya), itu sebabnya saya telah menghabiskan 6 bulan terakhir atau lebih menyempurnakan teknik untuk format virtual di mana lekukan dikelola oleh sistem. Jika ada satu hal yang saya pelajari, itu yang pengembang suka pilihan - maka pandangan datar.
pgfearo

Pada bacaan pertama, saya melewatkan ide-ide Anda pada lebar indent yang dinamis - ini bisa menjadi fitur yang kuat. Itu meningkatkan kemungkinan bahkan memiliki beberapa kode indentasi sementara sisanya datar, tidak yakin bagaimana ini akan bekerja dalam prakteknya tetapi mudah diuji - dengan proyek saya, logika indentasi masih digunakan bahkan untuk tampilan datar, hanya saja pengganda diatur ke 0. Jadi pengali ini saja yang perlu disesuaikan. Panggilan yang bagus.
pgfearo

2

Mengapa tidak membuka dan menutup tanda kurung?

  1. Lekukan berarti penahanan: (dan) berarti persis seperti itu bagi programmer.
  2. (dan) masing-masing karakter tunggal: bilah kiri akan tetap sangat tipis.
  3. Elemen kosong mudah terlihat: use () pada baris yang sama.
  4. Konten suatu elemen tidak memerlukan petunjuk visual: kosong jauh lebih baik.
  5. Posisi kursor di sebelah kanan dapat dicocokkan dengan blok yang mengandung di sebelah kiri: secara dinamis menambahkan warna ke karakter di kolom dengan (dan)
  6. Anda bisa membuatnya lebih XML-ish menggunakan <dan>, yang terlihat lebih baik dari kejauhan.

Beberapa ide berguna - akan mencoba menggabungkannya, terutama bit XML-ish. Juga, ada sedikit yang berjalan secara dinamis, dan saya mungkin bisa menambahkan lebih banyak - tanpa terlalu sombong.
pgfearo

2

Vim sudah bisa melakukan hal serupa, meskipun tidak secantik itu.

Ada berbagai cara melakukan "kode lipat" di Vim. Salah satunya didasarkan pada aturan lipat sintaksis. Ketika ini dilakukan, kode dapat dilipat menggunakan struktur garis bersarang, dan "FoldColumn" dapat digunakan untuk memberikan representasi grafis (sebenarnya "berbasis karakter" dengan karakter '|' dan '-' chars) dari "foldlevel" .

Kolom lipat dapat memberikan representasi sarang terlepas dari metode lipat, tetapi metode berbasis sintaks adalah metode yang mungkin sesuai untuk apa yang Anda inginkan. Saya tidak yakin apakah ada aturan lipat berbasis sintaks pra-dibuat di luar sana untuk xml di suatu tempat, saya kira mungkin ada.


Editor yang saya rancang akan diintegrasikan ke dalam sistem yang jauh lebih besar dengan GUI di mana Vim, atau alat pihak ke-3 tidak dipertimbangkan, untuk alasan teknis dan lisensi. Namun, saya tertarik pada bagaimana Vim menangani hal ini sehingga akan menyelidiki - semoga mereka memiliki tangkapan layar dalam dokumentasi. Ya, grafik berbasis karakter dapat bekerja sampai tingkat tertentu - Saya telah mengejeknya untuk penelitian. Pelipatan kode dapat dilakukan dari margin kiri, tetapi tampilan garis pohon yang tersinkronisasi juga disediakan.
pgfearo

@pgfearo: Anda mungkin melihat protokol NetBeans Vim. Ini dimaksudkan untuk digunakan untuk menanamkan Vim di dalam IDE, tanpa masalah lisensi.
greyfade

@ Greyfade - Saya khawatir ada masalah lisensi, dengan proyek saya saat ini setidaknya, karena sumbernya tertutup dan saya akan membutuhkan faciltity (bahkan jika saya tidak menggunakannya) untuk memodifikasi sumber Vim tanpa kekhawatiran GPL. Selain itu, protokolnya memang terlihat menarik.
pgfearo

1

Saya pikir Anda berada di jalur yang benar dengan opsi B dan C: termasuk pewarnaan lebar dan peta panas. Saya suka opsi B lebih dari C pada saat ini, karena itu kurang mengganggu (baik yang lebar dan diencerkan, atau sempit dan intens, daripada blok yang sangat berat di tengah C) Satu kelemahan adalah bahwa dengan opsi itu Anda harus bangun kembali seluruh grafik jika Anda memasukkan level di suatu tempat. Saya pikir Anda bisa membuat blok lebih kecil, 1 atau 2 px mungkin akan cukup. Tidak harus banyak, hanya perlu dibedakan. Terutama ketika orang diharapkan untuk menggunakan editor berkali-kali, efek yang tidak mencolok dan lebih halus lebih mudah untuk dikerjakan karena mereka tidak terlalu mengganggu.

Satu hal yang penting ketika menggunakan semacam editor adalah menyoroti ruang lingkup saat ini: ketika memilih garis di editor, Anda perlu melihat dengan tepat elemen apa yang dikandungnya, dan di mana ia berhenti. Anda bahkan bisa menyorot pohon ke atas (elemen apa itu anak). Saya pikir itu adalah masalah terpisah yang perlu ditangani dan dipikirkan dan akan memiliki lebih banyak pengaruh pada bagaimana pengguna akan menilai pengalaman mereka dengan editor.


Saya sekarang telah mengirimkan jawaban yang menurut saya terlintas dengan Anda tetapi secara kebetulan mengikat ide Anda untuk menyoroti ruang lingkup saat ini (dengan perbatasan yang bersinar) ?. Saya setuju bahwa blok harus kurang menonjol, efeknya dilebih-lebihkan di sini untuk membantu menggambar saya dan juga sehingga membuat ok pada screenshot diperkecil.
pgfearo

1

Satu hal yang belum saya lihat disebutkan adalah apa yang dapat Anda lakukan dengan rona di atas efek saturasi yang tampaknya telah Anda selesaikan. Saran saya adalah untuk mengubah warna sarang di mana pointer berada. Ini akan membuatnya lebih mudah bagi pengguna untuk membedakan garis mana yang merupakan bagian dari sarang, dibandingkan saudara kandung di sepanjang jalan.

Saat menerapkan hal-hal berbasis rona, harap sadar akan kebutaan warna, dan baik pilih warna yang dapat dibedakan secara universal, atau menawarkan beberapa pilihan bagi orang untuk memilih.


Ini menyoroti, saya pikir, bahwa masih banyak yang bisa dilakukan untuk menambahkan detail pada implementasi pola ini. Ya, saya lebih nyaman menggunakan nada untuk menghindari masalah kesadaran warna, tetapi jika tersedia, saya setuju itu akan membantu menambah dimensi ekstra. Karena pertanyaan ini sekarang adalah wiki komunitas, saya akan mencoba mengirimkan bingkai gambar untuk melihat apakah orang lain ingin berkontribusi gambar yang variasi pada tema - preferensi mungkin akan bervariasi di berbagai kelas penggunaan, sintaksis bahasa dan konteks dinamis.
pgfearo

0

Satu opsi, yang dapat digunakan bersamaan dengan saran lainnya sejauh ini, adalah dengan menggunakan tooltip di margin kiri yang menunjukkan jalur ke garis menggunakan notasi XPath. Alat "periksa elemen" peramban (mis. Firebug, yang ada di dalam Chrome) sering melakukan hal serupa tetapi di bilah status.


Saya hanya berkonsentrasi pada kontrol ini, tetapi 'XPath Location Bar' dengan navigator 'breadcrumb' bekerja dan dimasukkan ke dalam editor, seperti juga elemen tree-view yang disinkronkan.
pgfearo

0

Mungkin Anda bisa memiliki tampilan runtuh untuk peta panas (dari pos asli) dengan hanya satu kolom warna dan angka kedalaman. Ini akan memungkinkan mereka untuk mengetahui seberapa dalam mereka dan memberi mereka lebih banyak layar real estat untuk xml. Sepertinya menang untuk saya.

Saya khawatir apakah akan ada perbedaan warna yang cukup untuk membuat sarang dalam-dalam.


Dukungan untuk bersarang tingkat tinggi adalah prioritas. Tapi, hanya ada begitu banyak mata yang perlu dilihat (dan dapat diterima) pada satu waktu, jadi di luar level tertentu, saya sedang mempertimbangkan memadukan warna bersama, hanya untuk memberi kesan kedalaman, dan hanya menyoroti level kunci. Jadi saya akan memeriksa ide Anda ketika tingkat sarang tinggi.
pgfearo
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.