I reckon there's a reasonably large subset of DSLs in the computing world that lend themselves to a 2D description, rather than a simplistic 1D sequential list down a text file. Anything involving concurrency in particular needs more than just a list.
A graphical language like asciiflow would serve this well. Edit your graph in the flow diagram and parse it in a specialised parser.
Are there any generic asciiflow parsers out there?
Most source code is already three dimensional, and running code has at least two, but oddly, only one in common. Any block of text has an X and Y axis. But we keep jumping in and out of it to other files or functions, which is another degree of freedom.
A Turing machine has one dimensional storage, but the order of operations matter quite a bit. So the second axis is time. But in a network, where it happens also matters. Although one might argue that the entire network is a single synthetic Turing machine with a segmented tape, and thus it’s just 2 dimensions.
It should soon or now be possible to define custom editors for file types in VS Code[1], so I think this extension would fit very nicely for contributing a custom editor for plaintext files. I may be wrong, but at first glance, it doesn't look like this extension makes use of that functionality yet.
As a full time Emacs user for more than 13 years now, I have at least three explanations (from the worst aspect to the less bad IMHO):
1. Emacs is different (copy, paste, undo, exit… none of these work the way they work in Windows, KDE, Gnome, Firefox…). This makes you either configure Emacs to behave like everything else and you end up having a subpar Emacs experience, or try to configure everything else to behave like Emacs and you end up doing everything into it, not unlike many Vim users (I'm on my way to the latter option).
2. Emacs doesn't work out of the box. Seriously, there's so much features builtin (artist-mode is only one of thousands), but so little that actually works for stuff that matters. I'm not even talking about advanced stuff like LSP (that most people take for granted nowadays), just about the most basic stuff like the home / end keys, multi-level undo… It's just a matter of turning a few knobs, but you still have to do that. Oh, and while this could be the best way to start understanding where Emacs is incredibly powerful (customization), it isn't because you do it in Elisp.
3. Emacs is not pretty. I've solved the problem by hiding everything but the text editing UI, but it sure doesn't give much appeal at first sight.
I find most other editors ugly. But I suspect this is the main stickler. Had a Windows friend ask why nobody has made a ribbon interface for Emacs. Not many icons at all. I didn't know how to respond, as I have long ago turned off most decorations.
Programming got easier as soon as I started really internalizing that I am not programming a computer, per se, instead I am programming the editor.
For the out of box experience. This is at odds, or competition, with how much many users have customized it. I'm sympathetic, but not sure how to fix it. And, I think this is not fair, either. Blindly pasting in Word or Excel is also a frustrating experience. Just in a different way.
My main problem with emacs is the lack of out of the box source code indexing and autocomplete.
I’m sure there’s a way to set it up, but even after years of using emacs, I haven’t figured it out.
It took me 10 minutes to get VS code to import and index a non-trivial C++ code base, and that’s with no prior VS Code experience. It even popped up some hints when stuff started going sideways.
If you're willing to give Emacs another shot, check out LSP-mode [0]. It's an implementation of the language server protocol, the same tech that powers the autocomplete/jump-to-def/etc. in VS Code, and so it offers exactly the same functionality for all the same languages. It's true that it's not built into Emacs, but it's easy to set up and works well.
It's been a total game changer for me - it's allowed me to transition to using Emacs full-time for professional Python programming.
Oddly, I've gotten bitten by code indexing tools so many times, I like that it is not part of my editor. I sometimes think of seeing up autocorrect. But I find I prefer a greppable codebase over an autocorrect one.
That said, plenty of starting packages that do have this setup. I think doom Emacs is the popular one nowadays.
I mean, I get what you are saying. But the extensible nature of Emacs is years beyond what other editors typically offer. Can offer?
Elisp is not the best lisp out there, but it is still a really powerful language. And that the editor doesn't have any tricks/parts that you can't use as a user is huge.
Emacs can do everything but for specific tasks there's often something that specializes in that thing that's better (IMHO).
For example, when I'm writing C++ on Windows, I use Visual Studio. I do Python work in PyCharm. I use Sublime Text for Markdown and light duty text editing. If I'm working over an ssh connection, I use vi. If I'm writing a letter, I'll use Word or Pages. If I want a spreadsheet I use Excel. For slides I'll use Keynote or Powerpoint.
This is great, I am using ascii art a lot in comments to visualize flows (etc.) of code where it is needed instead of additional documents that no one reads and have much greater possibilty to get out of sync with the code (although comments have that tendency too). Love it, just provide enough of primitives with it.
unfortunately this is really hard to look at when using a dark theme - switching to a light theme is a workaround but it's too bad it's so glaring in a dark mode.
I reckon there's a reasonably large subset of DSLs in the computing world that lend themselves to a 2D description, rather than a simplistic 1D sequential list down a text file. Anything involving concurrency in particular needs more than just a list.
A graphical language like asciiflow would serve this well. Edit your graph in the flow diagram and parse it in a specialised parser.
Are there any generic asciiflow parsers out there?