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.
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.
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:
Who are the user? What background does a user have? What is he used to?
Some persons are more visually and some more textually oriented.
How is someone going to use the editor? Creating new models is often quite different from changing existing models.
For someone using an editor 7 * 24 it might be efficient to ensure everything can be done by the keyboard, potentially even by function keys. The ROI of learning these can be high. Someone who is using an editor occasionally more guidance (e.g. menus, buttons, etc.) might be more useful.
What kind of language is the editor for, this influences the notation and therefore the interaction.
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.
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.
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.