Wie würden Sie sich fühlen, wenn Ihr Code-Editor Ihren Code während der Eingabe ohne Tabulatoren / Leerzeichen für Sie formatieren würde? [geschlossen]

8

Wie bei den meisten Dingen bin ich sicher, dass dieses Konzept schon einmal ausprobiert wurde - ich bin nur nicht auf Editoren gestoßen, die das verwenden, was ich als "virtuelle Formatierung" bezeichnet habe. Das Prinzip ist, dass es einen schwebenden linken Rand gibt, der den Effekt der Auffüll- / Tabulatorzeichen simuliert, die herkömmlicherweise vom Entwickler oder vom Editor selbst eingefügt werden, um den Code zu formatieren. Der Editor analysiert während der Eingabe kontinuierlich Code (auch wenn er auskommentiert ist) und berechnet den erforderlichen Einzug basierend auf dem Kontext, in dem sich jeder Zeilenvorschub befindet

Ich entwickle diese Idee speziell mit einem XML-Editor, da XML einige besondere Probleme mit der Formatierung von Zeichen hat und in der Regel stark verschachtelt ist. Ich glaube jedoch, dass viele der Prinzipien für herkömmlichen Code immer noch gelten.

Haben Sie Erfahrung mit dem Codieren mit einem solchen Tool oder haben Sie eine Vorstellung davon, ob es helfen oder behindern würde? Würde es Probleme mit Versionskontrollsystemen verursachen? (Es erkennt und entfernt alle vorhandenen Füllzeichen.)

Wenn Sie es nicht ausprobiert haben, ist das Verhalten eines solchen Tools schwer zu beschreiben. Es sieht konventionell aus, bis Sie tatsächlich mit der Bearbeitung beginnen. Ich habe ein Screencast-Video erstellt, das einen Prototyp in Aktion zeigt, der das Bearbeiten von XML, das Ändern seiner Hierarchie und das Ausführen von Drag & Drop- und Kopier- und Einfügevorgängen sowie die Fehlerbehebung / Korrektur bei der Eingabe ungültiger Zeichen demonstriert.

Bearbeiten Alle Antworten / Kommentare waren bisher negativ. Um das Gleichgewicht wiederherzustellen, sollten Sie einige Vorteile der virtuellen Formatierung berücksichtigen:

  • Keine Debatten mehr über Formatierungsstandards, platzieren Sie Zeilenvorschübe nur dort, wo dies Ihrer gewählten / vorgeschriebenen Konvention entspricht
  • Wenn der Platz knapp ist (in einem Buch / Blog / einer Dokumentation), können Sie die Zeilen umbrechen, erhalten aber dennoch eine perfekte Einrückung
  • Jeder Codeblock kann einen 'Mausgriff' unmittelbar neben dem Startpunkt haben, der nicht in den Bildschirmrand gedrückt wird. Klicken Sie hier, um den gesamten Block oder den inneren Block auszuwählen
  • Ziehen, Ablegen und Vergessen - wird zum ersten Mal möglich
  • Keine Zeit für die Neuformatierung des Codes anderer Leute
  • Kein falsch formatierter Code (in dem Sinne, dass es keinen gibt - nur das Rendern)
  • Wenn Sie die Rücktaste anstelle von Strg + Rücktaste verwenden, bleiben Ihre Finger auf den Tastaturführungstasten
  • Flexibles Rendern - Passen Sie die gerenderte Formatierung an Ihre Umgebung an. Hat jemand versucht, Code auf einem Mobiltelefon / Tablet mit kleinem Bildschirm zu lesen?
  • Bedenken Sie, dass es ungefähr 25% weniger bearbeitbare Zeichen gibt (in einem Beispiel-XSLT). Hat das nicht Effizienzvorteile?

Bearbeiten - Bisherige Schlussfolgerungen

  1. Entwickler haben Tools und Arbeitsmethoden entwickelt, mit denen die meisten Nachteile der Verwendung von Füllzeichen zum Einrücken effizient überwunden werden können.

  2. Es besteht die Sorge, dass das Entfernen von Formatierungszeichen einige differenzierende Tools nachteilig beeinflusst.

  3. Entwickler möchten die Flexibilität, die Formatierung so zu optimieren, dass das automatisierte Rendern nicht möglich ist.

  4. Das Entfernen führender Leerzeichen / Tabulatoren bedeutet, dass ein "Code-fähiges" Tool zur Code-Formatierung erforderlich ist, um diesen Code effizient zu überprüfen - ein Nur-Text-Editor würde keine Formatierung anzeigen.

  5. Diejenigen, die der Meinung sind, dass es einige hypothetische Vorteile (für die virtuelle Einrückung) geben könnte, sind der Ansicht, dass die Nachteile diese potenziellen Vorteile überwiegen - schlüssig .

Bearbeiten - Urteil

Die Wahrnehmung der Hindernisse und der wenigen (wenn überhaupt) Vorteile ist so, dass es für mich als Einzelentwickler unklug wäre, dieses platzfreie Bearbeitungskonzept für allgemeine Sprachen zu verfolgen. Für XML / XSLT scheint es jedoch (aufgrund der speziellen Behandlung von Leerzeichen) zumindest eine gewisse Übereinstimmung des Potenzials zu geben.

Bearbeiten - Produkt versendet

Trotz der allgemein negativen Stimmung, die hier zu finden ist, habe ich den Herausgeber verschickt. Ich habe eine kostenlose Version erstellt, in der Hoffnung, dass sie Kritik in Form konkreterer Themen auf der Grundlage realer Erfahrungen hervorruft. Etwas frustrierend ist, dass es bisher keine Beschwerden gab (tatsächlich kaum Feedback bezüglich des Download-Volumens). Ich würde gerne glauben, dass dies daran lag, dass sich die Benutzer so gut auf die Idee eingestellt haben, dass sie dies als "na und?" Art von Feature - aber es gibt keine Möglichkeit zu sagen ...

coding-style xml editor formatting pgfearo
quelle
Ich denke, einige Schema-Editoren führen diese Art der Formatierung im laufenden Betrieb durch, fügen jedoch echte Leerzeichen ein (und löschen sie)
Javier
@Javier Ich muss gestehen, dass ich nicht auf Schema gestoßen bin - ich werde dies nachschlagen. Ich bin der Ansicht, dass es einige Sprachen gibt, in denen die Formatierung kritischer / gefährlicher ist als andere, daher ist Schema möglicherweise eine davon
pgfearo
Ich schlage vor, Sie sehen Firebug und wie es den HTML-Baum bearbeitet.
Lie Ryan
@Lie Ryan - Ja, ich mag den Baumeditor, soweit es geht. Aber es fühlt sich immer noch so an, als würden Sie eher ein Formular als einen frei fließenden Text ausfüllen. Ich denke, das liegt daran, dass nur Attribute und keine Elemente bearbeitet werden (soweit ich das beurteilen kann, in diesem Modus).
pgfearo
HTML ist anfangs nicht gerade ein Freeflow-Text, aber ich verstehe, was Sie unter dem Ausfüllen von Formularen verstehen (aus diesem Grund gefällt es mir , dass die Einschränkungen es unmöglich machen, versehentlich nicht geschlossene / nicht übereinstimmende Tags, nicht zitierte Attribute usw. einzuführen. Ich würde keinen dedizierten XML-Editor verwenden, wenn ich nicht wohlgeformtes XML schreiben könnte. In Firebug können Sie einen neuen Knoten hinzufügen, indem Sie mit der rechten Maustaste auf> HTML bearbeiten klicken. Dies ist recht unpraktisch, reicht jedoch für kleinere Bearbeitungen aus, die Webentwickler benötigen. In einem seriöseren Editor ist es jedoch möglich, Schaltflächen / Kontextmenüs / Verknüpfungen zum Einfügen von Knoten zu haben.
Lie Ryan

Antworten:

6

Das größte Problem wäre, wie Dateien für andere Tools angezeigt werden, insbesondere für Tools zur Versionskontrolle. Zeilenenden sind für diese Werkzeuge von Bedeutung. Ich möchte keinen Zusammenführungsbildschirm sehen, auf dem ich eine ganze Klasse in einer Zeile habe, und versuchen, einen Teil des Textes in Spalte 347 zusammenzuführen.

Jeremy
quelle
1
@Jeremy - Zur Verdeutlichung bleiben alle Zeilenvorschübe (falls vorhanden) erhalten, nur die Tabulatoren / Leerzeichen, die entfernt werden. Ich hatte gehofft, dass differenzierende Tools damit fertig werden könnten, wenn diese fehlen würden.
pgfearo
1
Einige Tools zur Versionskontrolle und Diff bieten die Möglichkeit, Leerzeichenunterschiede zu ignorieren.
FrustratedWithFormsDesigner
1
+1 - Ich sehe keinen Nutzen daraus. Alles, was es tun wird, ist die Versionskontrolle und die Diff-Tools durcheinander zu bringen.
4
@pgfearo Das Problem, das ich mit so etwas habe, ist, dass es fast großartig wäre, aber die <1% der Änderungen, die ich nicht vornehmen möchte, dass der Editor fortfährt und Änderungen sowieso verrückt wären . Ihr Editor müsste bis zum n-ten Grad vollständig anpassbar sein, um sicherzustellen, dass er alle Anforderungen erfüllt.
Michael Todd
1
@pgfearo - XML-Formatierung, ja, dies ist definitiv der richtige Ansatz, aber ich dachte, so formatierten die meisten Editoren XML trotzdem.
4

Das wäre toll. Emacs macht das mehr oder weniger und macht es meistens richtig. Haben Sie den nXML-Modus von Emacs ausprobiert? Wie würden Sie das verbessern?

Sie können keinen neuen Editor erstellen, bis Sie die bereits verfügbaren Daten getestet haben.

Auf jeden Fall muss der Einzug in der Ausgabedatei gespeichert werden, damit die Datei mit anderen Tools angezeigt werden kann. Ich werde wahrscheinlich keinen neuen Editor verwenden, es sei denn, er unterstützt Laufzeitanpassungen wie Emacs.

Kevin Cline
quelle
Warum muss die Einrückung gespeichert werden, sollten wir unsere Formatierung anderen auferlegen? Verwenden Benutzer immer noch Tools, für die keine XML-Plug-Ins verfügbar sind, die das XML nach ihren Anforderungen formatieren können (nicht nach denen des Autors)?
pgfearo
Auf Emacs. Ich habe Emacs nur lange genug benutzt, um zu wissen, dass ich (damals) nicht die Zeit hatte, es richtig zu lernen, um es gerecht zu machen. Ich vermute, Emacs-Benutzer würden es ebenfalls schwer haben, den "anderen Weg" zu versuchen. Ich werde Emacs noch einmal anschauen, aber ich mache mir Sorgen darüber, dass es meistens richtig läuft - das können Sie verbessern.
pgfearo
@pgfearo sein genanntcat
Alternative
@mathepic hoffentlich * nix Kommandozeilenentwickler haben Zugriff auf xmlsh oder ähnliches?
pgfearo
@pgfearo Ehrlich gesagt hatte ich noch nie davon gehört und würde nie eine Shell für XML verwenden;)
Alternative
3

Ich habe diese Idee schon einmal gesehen, aber ich habe noch nie gesehen, dass sie tatsächlich funktioniert. Die meiste Zeit, wenn ich die Idee kommt gesehen habe, es wurde von jedem Entwickler da draußen abgeschossen - oder wenn es wird umgesetzt, und zwar aus der Versionskontrolle praktisch nutzlos , da nur sieht gefalteten Code würde die Datei ändern und weiter confuse das Diff-Tool. (Ein Beispiel dafür, wie schlimm das ist, ist das Witango Development Studio.)

Ich kann mir einige Hürden vorstellen, die Ihr Editor überwinden müsste, um für viele Entwickler nützlich zu sein:

  • Änderungen an einer Datei dürfen im diff -uwBefehl * nix kein Rauschen verursachen . (Keine falschen Unterschiede!)
  • Das Bearbeiten einer (zuvor unformatierten) Datei darf das Zusammenführen in SCM-Tools nicht erschweren.
  • Es muss gut mit anderen Editoren zusammenarbeiten, die vom Entwicklerteam verwendet werden.
  • Benutzer müssen in der Lage sein, die Formatierung nach Herzenslust anzupassen - einige Leute sind ziemlich begeistert davon, wie ihr Code angezeigt wird.
  • Änderungen an vorhandenem Code dürfen die vorhandene Formatierung nicht ändern. Es ist wichtig, dass der Editor nicht plötzlich eine ganze Datei ohne ersichtlichen Grund neu formatiert und die Formatierung einer Zeile für einfache kleinere Änderungen nicht ändert - dies verwirrt die Diff-Tools und verärgert andere Teammitglieder.
  • Es sollte wahrscheinlich kein überschüssiges Leerzeichen entfernen - es wird wahrscheinlich jemanden verärgern. Am besten nicht riskieren.
  • Neue Zeilen, die einer Datei hinzugefügt werden, sollten den Einstellungen der vorhandenen Modelllinien entsprechen oder der lokalen (innerhalb von +/- 3 Zeilen) vorhandenen Formatierung entsprechen.
  • Der Editor sollte über ein Einstellungsfeld verfügen, in dem der Benutzer die Code-Formatierungsrichtlinie des Teams definieren kann, die von der vom Editor tatsächlich angezeigten Richtlinie getrennt ist.

Es ist unnötig zu erwähnen, dass dies eine gewisse Menge an Metadaten über die vorhandene Formatierung der Datei erfordert. Sie möchten es wahrscheinlich von den Quellen trennen, aber es wäre wahrscheinlich ziemlich schwierig, es mit einem sich ständig ändernden Repository synchron zu halten.

Als Vim-Benutzer würde ich auch der Meinung sein, dass der Editor die Modelines von Vim, Emacs und anderen Editoren respektieren und die verbotene Formatierung der Modeline beibehalten sollte, unabhängig davon, was letztendlich angezeigt wird.

Meiner Meinung nach machen die Anforderungen an eine solche Software sie unhaltbar. Zu viele Benutzer erwarten zu oft zu viel davon, um ein solches Projekt erfolgreich zu machen.

grau verblassen
quelle
Es sieht also so aus, als ob wir an unserer aktuellen Lösung festhalten, nicht weil sie die beste ist, sondern weil es zu schwer ist, sie zu ändern. Leider trifft dies in so vielen Bereichen der IT zu, dass es für mich dumm / arrogant wäre, das Gefühl zu haben, ich könnte dies selbst beheben. Da ich hartnäckig bin, werde ich dieses Konzept weiterhin als optionales Tool in eine viel größere Desktop-Lösung integrieren, bei der die Verarbeitung / Analyse das Hauptanliegen ist. Auf diese Weise hat der Entwickler die Wahl.
pgfearo
@pgfearo: Nein, ich denke, wir sind mit unserer aktuellen Situation "festgefahren", nicht weil es das Beste ist, sondern weil es nichts Besseres gibt. Um die Benutzer von Vim und Emacs für die Idee zu gewinnen, müssen Sie einen erheblichen Vorteil gegenüber den bereits effizienten Tools bieten, die sie verwenden. Um alle anderen zu überzeugen, müssen Sie nur die Funktionen, die Vim- und Emacs-Benutzer bereits genießen, einem breiteren Publikum zur Verfügung stellen. Warten Sie, vielleicht , dass Textmate Lizenz ist es wert.
Greyfade
@pgfearo: Mein allgemeiner Punkt ist, dass ich nicht glaube, dass Sie jemals etwas erreichen werden, das irgendjemand gegenüber seinen vorhandenen Tools verwenden möchte, außer einem sehr kleinen Teil unserer Arbeit. XML- und XSLT-Hacker haben einen offensichtlichen Vorteil, da die Struktur 99% der Arbeit ausmacht, aber weniger streng strukturierte Sprachen wie C, Java, C #, Ruby usw. haben weitaus weniger offensichtliche Vorteile. Dies ist ein sehr schwieriger Verkauf für die Hard -Ader.
Greyfade
Ja, dieser Punkt über effiziente vorhandene Tools / Methoden ist die Nummer 1 in den bearbeiteten (Zwischen-) Schlussfolgerungen zu der Frage. Nach dem, was bereits gesagt wurde, bezweifle ich, dass ich überhaupt versuchen sollte, Vim / Emacs-Benutzer zu gewinnen - wenn es jemals Interesse daran gibt, wird es von woanders kommen.
pgfearo
Akzeptierte diese Antwort, weil sie die Themen kurz und bündig aufschlüsselt und mit der allgemeinen Meinung anderer Antworten / Kommentare übereinstimmt. Nicht die Antwort, auf die ich gehofft hatte, aber sie hat mich davon überzeugt, dass es - zumindest für Nicht-XML / XSLT-Umgebungen - keinen Sinn macht, dieses Konzept weiter zu verfolgen, und dass keine weiteren Anstrengungen erforderlich sind.
pgfearo
2

Lösung unter Verwendung textbasierter (z. B. XML) Formatierungskonfigurationsdateien:

  • Lassen Sie einen persönlichen Formatierer vom einzelnen Entwickler konfigurieren.

    • Speichern Sie diesen Formatierer lokal.

    • Dateien werden mit lokaler Formatierung geladen und bearbeitet.

    • Sie können ihren Formatierungsstil frei ändern, ohne etwas zu beschädigen.

    • Die automatische Formatierung kann deaktiviert werden, um unformatierte Dateien anzuzeigen und zu bearbeiten.

  • Lassen Sie einen minimalen Teamformatierer für den Teamstandard konfigurieren.

    • Speichern Sie diesen Formatierer in der Teamversionskontrolle.

    • Dateien werden mit Teamformatierung als Ersatz für andere Tools gespeichert .

    • Diffs leiden nicht unter Formatierungsproblemen.

Es ist lächerlich, sich Gedanken über die Wirtschaftlichkeit des Speicherns von Dateien ohne Leerzeichen zu machen, sodass Sie nichts verlieren, wenn Sie die Dateien mit einer Formatierung speichern, die von einem Teamstandard definiert wird. Im Fall eines Einzelentwicklers können Sie die Möglichkeit bieten, die Formatierung (für das "Team" von einem) gespiegelte Formatierungen zu speichern.

Wenn der Formatierer nicht ausreicht, haben Sie zwei Möglichkeiten:

  • Stellen Sie eine Schnittstelle für benutzerdefinierte Formatierer bereit.

    • Richtig gemacht, das ist die beste Lösung.

    • Falsch gemacht, es ist das Schlimmste.

  • Manuelles Überschreiben der automatischen Formatierung zulassen.

    • Die Benutzerfreundlichkeit leidet nicht - beachten Sie Strg- (Enter | Tab | Space).

    • Vernunft tut - wo speichern Sie diese Formatierung? Machst du?

Jon Purdy
quelle
Nützliche Punkte. Ich mag die Idee, gemeinsam genutzte Formatierungskonfigurationsdateien zu haben. Die automatische Formatierung kann bereits im Prototyp umgeschaltet werden, da es wichtig ist, "echte" Leerzeichen von den virtuellen Elementen zu isolieren. Das Wechseln zwischen Ansichten ändert natürlich kein einziges Zeichen. Meine Neigung besteht nicht darin, innerhalb des Tools die Option zum Speichern "mit Formatierung" bereitzustellen, sondern "Adapter" bereitzustellen, die kostenlos und plattformübergreifend sind und auch als Webdienst ausgeführt werden können. Diese könnten dieselben XML-Formatierungskonfigurationsdateien verwenden du schlägst vor.
pgfearo
2

Ich wäre in Ordnung mit Code AutoFormatted wird , wenn die Sprache nicht empfindlich formatiert wurde Husten Python Husten .

Emacs macht die Lisp-Formatierung wirklich gut und sie wird sofort formatiert. Ich würde mich sehr freuen. Ich kann das automatische Einfügen von Parens oder anderen Trennzeichen nicht ertragen: Keiner der Autoinserter, die ich versucht habe, hat es für meine Eingabe annähernd richtig gemacht.

Paul Nathan
quelle
Ja, ich denke, F # verwendet auch die Formatierung innerhalb seiner Syntax. Das automatische Einfügen von Trennzeichen ist ein Problem. Für XML erfolgt dies in Form von Anführungszeichen usw. Es ist nicht perfekt, kompensiert jedoch Touch-Typisten, die möglicherweise dem Rennen voraus sind, und prüft daher, ob etwas, das eingegeben wurde, noch nicht zum automatischen Einfügen in die Warteschlange gestellt wurde sowieso - Wiederholung vermeiden. Ohne automatische Einfügung kann der Parser nur raten, wie er einrücken soll - dies kann sich etwas verzögern, aber es würde zu einem gewissen "Wackeln" des Randes kommen, wenn der Parser versucht, die wahre Absicht des eingegebenen Codes zu verstehen.
pgfearo
@pgfearo: fortran, cobol, f #, haskell, python, make und einige andere Systeme sind durch Leerzeichen getrennt. Es ist ziemlich lächerlich, IMO, da es die automatischen Tools in ihrem Betrieb (und beim Parsen des Benutzers) behindert, aber wir bleiben bei ihnen.
Paul Nathan
2

Ich liebe die Idee im Konzept . Und obwohl Sie vielleicht Erfolg haben, muss ich noch einen Editor finden, der alles tut, was ich in Bezug auf die Formatierung möchte. Hier sind einige Straßensperren (IMO):

  • Whitespace-wählerische Sprachen
  • Was wird für die Ausgabe gespeichert? (Bis zu einem gewissen Grad müssten Sie zumindest einen Teil der Einrückung speichern, damit sie ohne das Tool für andere lesbar bleibt.)
  • Es muss unbedingt gut mit den vorhandenen Quell- / Versionskontrollprodukten spielen, die bereits vorhanden sind
  • Es muss hochgradig anpassbar sein, insbesondere für diejenigen von uns (ich eingeschlossen), die sehr, sehr, sehr wählerisch sind, wie Code formatiert und eingerückt wird (und wo dieses Komma in einer Liste stehen soll, aber wenn die Liste wirklich lang ist, wie Linien sollten unterbrochen sein usw.)
  • Es muss die Sprache wirklich verstehen. Damit meine ich, dass es genau der Sprache folgen muss, wie der Compiler es verstehen wird. Ich hatte viel zu viele Editoren mit farbiger Syntax, die die Syntax falsch verstehen, weil es eine verrückte Facette der Sprache gibt, die nicht einfach mit einem RegExp behandelt werden kann. Zugegeben, Sie haben angegeben, dass Sie die Sprache kontinuierlich analysieren würden, aber wer soll sagen, dass das, was Sie analysieren, dem von mir verwendeten Compiler entspricht? (Glauben Sie mir, es gibt viele Standards, und es gibt eine Menge lustiger Geschäfte, die in den meisten Sprachen ablaufen, einschließlich Code, der für einen einfachen Parser falsch aussieht , für den Compiler jedoch vollkommen korrekt ist.)
  • Es muss schnell sein . Und hier trifft der Gummi auf die Straße - Sie können meinen Code nicht bei jedem Tastendruck vollständig kompilieren (insbesondere bei einem großen Projekt), es sei denn, Sie können Ihren Parser bis zum N-ten Grad optimieren. Wenn der Editor auch nur einen Anflug von Langsamkeit enthält, wird er von niemandem verwendet. (Ich bin ein perfektes Beispiel dafür, wie man langsame Editoren zugunsten schnellerer Editoren aufgibt. Wenn es im Geringsten zurückbleibt, bin ich raus.)

Könnten Sie etwas schaffen, das die meisten Kriterien einigermaßen gut erfüllt? Wahrscheinlich. Aber wir Programmierer sind pingelig und wählerisch und hassen es, uns zu ändern, und werden beim ersten Anzeichen von Ärger sofort loslegen. Hier wird es Probleme geben, wenn die Ausgabe eine andere Person im Entwicklerteam abhakt oder wenn sie mit dem Versionsverwaltungssystem nicht 100% gut funktioniert oder wenn sie meinen Code nicht genau so formatiert oder wenn dies der Fall ist versteht die Sprache falsch und rückt meinen Code falsch ein oder wenn er eine Millisekunde hinter dem zurückbleibt, was ich erwarte. Denn so sehr ich die Idee auch mag, ich werde sofort zu meinen bevorzugten Redakteuren springen.

Kerri Shotts
quelle
Zu Ihrem Leistungspunkt: Die Reaktionsfähigkeit kann mit vorhandenen Tools vergleichbar sein. Da die Formatierung keinen Einfluss auf den Codetext hat, kann die Verarbeitung im Hintergrund ausgeführt und nach Belieben beendet werden. Bei XSLT gibt es einen Kaskadenansatz. Die Formatierung / Kolorierung wird vor der Feinkornvalidierung und der endgültigen Kompilierung durchgeführt. Da dies alles in einem Hintergrund-Thread geschieht und beim nächsten Tastendruck sofort unterbrochen wird, ist keine Leistungsverzögerung erkennbar. Nur der sichtbare Text muss sofort aktualisiert werden. Der verbleibende Text wird nach einer Pause in Blöcken neu formatiert.
pgfearo
Was wird für die Ausgabe gespeichert? Keine direkte Formatierung, da dies anderen einen Formatierungsstil auferlegen würde. Die Idee (als Antwort auf frühere Antworten) besteht darin, steckbare Formatierer bereitzustellen, die eine Standardkonfigurationsdatei verwenden, die Formatierungsregeln deklariert und bei Bedarf entsprechend ausgibt.
pgfearo
1

Es gibt einen noch radikaleren Ansatz - einen reinen semantischen Editor. Eine IDE behandelt einen Code, der sogar intern als AST dargestellt wird, nicht als einfacher Text. Siehe beispielsweise JetBrains MPS .

SK-Logik
quelle
Das ist interessant. Ich verstehe den MPS-Ansatz noch nicht vollständig, aber das Design für diesen Editor verwendet ein AST-Äquivalent zu Zuordnungen zu Positionen im Klartext-XML. Wenn also Benutzer mit dem Klartext interagieren, weiß der Editor sofort, welcher Teil des 'AST' bearbeitet wird. Auf diese Weise können Sie feststellen, ob eine erneute Analyse erforderlich ist, und Teile des Baums vor versehentlichem Löschen schützen, wenn der Benutzer beispielsweise das Löschen durch Drücken und Halten durchführt. Dies wird auch verwendet, um Daten zur aktuellen Auswahl in Echtzeit darzustellen. Ich werde mich weiter mit MPS befassen.
pgfearo
0

Nachdem ich den in meiner Frage beschriebenen XML-Editor veröffentlicht habe, bin ich in einer besseren (aber nicht idealen) Position, um zu versuchen, dies selbst zu beantworten - also werde ich:

Nach weit über 500 Downloads in weniger als 2 Wochen war die Reaktion auf dieses bahnbrechende neue Konzept in der dynamischen Code-Formatierung ...

NULL

Keine Beschwerden, kein Lob. Meine (hoffnungsvolle) Interpretation davon ist, dass die Leute nur einen Editor wollen und erwarten, der sich normal anfühlt und ihren Code nicht durcheinander bringt. Benutzer werden kaum bemerken, dass ihre Formatierung vollständig virtuell ist, und es gibt Hinweise darauf, dass sie sich noch weniger darum kümmern.

Es wäre jedoch ein Fehler, zu viel in diese Nichtreaktion zu lesen. Dieses Tool ist kostenlos, und dies bedeutet leider, dass zumindest einige Benutzer weniger geneigt sind, Kritik zu üben. Wenn sie es nicht mochten, haben sie es vielleicht einfach weggeworfen und etwas anderes benutzt.

pgfearo
quelle