Hi, I am reflecting on the importance of building a good editor to write an article.
I am trying to focus on:
Do you have stories on editors to share? Or articles to suggest? Or stuff I should look into?
Are you talking about specific editors, like âtext editors for the webâ, or âgraphical editors for business applicationsâ, or something like that, or are you talking âeditorsâ in general?
Also, what goal do you have with the article?
This is extreme but wise.
No, I am talking about editors in general. Every way to edit code written in a formal language: text editors, IDE, browser-based, desktop-based, or mixed (like Theia). Drag and drop editor, visual editors, projectional editors.
In general my goal is to discuss the importance to have a tool supporting you when using a language.
Discuss when it makes sense to build an editor basically, and discuss the different forms of editors than there are. The article should support people in understanding why they may want to build or adopt an editor, which characteristics are the most important and which alternatives there are out there.
This may all sound a bit vague or ambitious, I am still figuring out exactly how to frame the article 
Well, âcode editorsâ already is a pretty significant way to narrow it down, Iâd say.
This seems to be setting the focus on âcodersâ as a target group, and there, discussing editors sometimes seems like discussing religions (e.g. Vim vs IDEs).
Donât think I can contribute anything I feel like you wouldnât already know, so best of luck!
Thank you! Yes, it would be about forms of âcodeâ but including also DSLs, so the potential users would not be just developers but also users of other languages, such as engineers using Verilog, for example
Well, this is huge, I mean starting with enigma machine, then unices editors, ms dos / mac editors (wordstar, wordperfect) , email clients editor, type settings tools like QuarkXpress and InDesign, Corel, maybe editors for movieâs subtitles, hex editors, up to Visual Studio Code & other IDEs, the subject is really deep and with a large perimeter.
Plus tools which are in between like TreeSheets http://strlen.com/treesheets/
I think if you throw DSLs back in the mix, this means your field is even bigger then what @cristian.vasile listed.
In my opinion, one of the bigger problems DSLs have is that we (their proponents) think of them solely as languages, including their editors, meaning that the front-end tooling for DSLs often feels like an IDE, which is not very appealing to target groups that usually only ever see an IDE if they look at a developerâs machine.
The line to application front-ends with rich widget libraries is blurry to me when I start a new DSL. If there target group needs the look and feel of a spreadsheet application, I try to build it. Im curious howâd you plan to make a point that is generic enough to account for everything, yet valuable to anybody.
Can share based on my experience, which is way similar to most of the people here. But let me put this obvious/plain in words.
Everything is structured or has arrangement/pattern (APS : acronym created in alphabetical order) else it is a random number. If agreed, then editor should give a way to custom identify the APS or should have pre-defined or has learning built into to identify or a way to custom train before hand even without any formal custom identification files supplied, by way of examples.
When group is identified, the amount of individualizing and relations (and leveraging these for lot of stuff: navigation is one such) is all differentiates each of these editors.
The most important single characteristic is âcolorâ (I had a patent filing experience regarding this, where during prior art search the attorney notified some similarities and I had done a survey on colleagues as users to reword the claims and identified, on screen the most differentiating is color, than anything else) when it comes to interface.
SourceInsight 3.5 on windows which has tens (if not tons) of style properties for each individualization manifested as identified group and vi (with some plugins, ctags + cscope shortcuts) on Linux are the ones I use.
My suggestion is always to go for survey and order / sequence the needs / differentiate-ors. For me, no survey, no success for these kind of things.
which characteristics are more important
I think the basic answer to this is pretty simple, but getting there is really hard: A good editor is one I donât have to think about. I should be able to completely focus on my actual task, and the editor should provide all the right information and interaction at the right point â but not more than that!
âI donât have to think about the editorâ closely relates to âI know what will happen nextâ.
IMHO, thatâs a big part of why text editors are that good: They might not be extremely powerful, but I can very reliably predict what will happen if I type, navigate, search, save, diff, etc.
A really bad example are UML editors, partly due to the complexity of UML: In a bad editor, I have to pause at about every step to figure out how to do it (âdo I click on source, than target, or drag from source to target?â). In the best ones, I only have to pause on every 5th step (âWhy can I create a class attribute by typing + name: string, but not an object with myself : Person?â).
Traditional IDEs fail on the âbut not more than the right interactionâ part: No matter where I open the context menu, it will always fill the complete screen. Even if I know the exact title of the required entry, itâs hard to find in the long list. The command prompts of VS Code (and nowadays also Eclipse / IntelliJ / VS to some extent) are one way to tackle this problem.
Agreed!
Now that I am working on WebEditKit (web editors for MPS) I realize this: there are a tons of things to consider to make the editor feel natural when the user press the arrow keys, or enter, or backspace. A lot of details to consider all to give the feeling of the editing being ânaturalâ
One of the things that make it hard to get there is that a good editor for one person isnât necessarily a good editor for another person. Be careful not to take yourself as a reference, I know e.g. that I have some very specific preferences. There are many aspects that play a role:
Indeed!
Just an example: When my father started using smart phone and interacted with computer (windows based), I have realized what is going up and down wrt vertical scrolling is for different people. Completely opposite to what I used to.
@ftomassetti, you might also want to look at the xi editor project (WIP):
The author, Raph Levien, takes on a rather innovative approach on how editors should be designed, the main one being using JSON-RPC async-protocols for communications between the various modules of the editor, instead of standard interfaces. Youâll find a good presentation of his motives in the video linked above, where he also goes into great lengths on the test-suite he has developed to benchmark performance (quite impressive work, indeed).
Hi Tristano, thank you for sharing it. It seems something quite different indeed. Very interesting. Thank you for sharing it. I was a bit skeptical when I read about the JSON-RPC async protocol but I will keep an open mind 
Me too ⌠until I saw the video conference! Extensive hardware-based benchmarks have shown that there is no significant loss of performance with the adoption of JSON-RPC (not in Rust, at least).
R.Levien has really ultimately convinced me of the advantages of using RPC protocols for inter-module communication. This opens applications development not only to full language-agnosis (without requiring ABI-based FFIs) but also leads to context-agnostic modularity (via remote computers, the Internet, SSH, or whatever).
I personally think that this might be natural step in development â just look how LSP (Language Server Protocol) has changed the way we expect editors to work today. LSP is probably the first standard that managed to âcross the rubiconâ in this sense, and now most developers agree that the benefits of writing a language server once and then use it with any editor/IDE that supports (the ubiquitous) JSON-RPC protocol are indeed a good solution, which allows to ship with each language an error-tolerant version of the parser to provide syntax highlighting, IntelliSense, linting and refactoring functionality in a language-agnostic way.
The idea that every and each module could be reused with any other language, thanks to a standard JSON-RPC (or other RPC protocol) is quite practical if you think about it. This is especially true in editors, which have a trend to become more and more modular, to allow user customization and reuse in different context. With hardware becoming always more powerful, the adoption of RPC protocols is already becoming negligible in many contexts, whereas the benefits it might bring are numerous.
I am in the process of watching it and getting convinced 
A simple editor can be done in C# using a TextBox control or a RichTextBox control. The effort is what kinds of commands or structure is wanted. There is the source for a tree editor on my site PineTreeJoe.com There is also source for an editor control in SnipAssist.com I have an editor I am working on but will never finish. After you have a working editor and the source for it you can try different commands. You keep the ones that work OK and remove the others. I have added thing like todayâs date or removing comments.