1. 39
  1. 26

    I think that integrating everything into the editor to make it modern is debatable. Terminal users already have a terminal emulator and several file pickers available (like mc or ranger). Working remotely by ie. using ssh and mosh is available too. Utilities like lazygit are also available.

    An editor should not need to re-implement file picking, a window system, a way to work remotely and a terminal emulator to be modern.

    tl;dr UNIX already is an IDE.

    1. 11

      UNIX ain’t modern, it’s seventies tech. Besides, the modern thing is to ignore UNIX and put everything in one application. Zawinski’s law and all…

      I mean, I live inside Emacs most of the time too when I’m working, and it does offer some conveniences like a sibling comment points out. But I’m not sure I’d call Emacs exactly “modern”, either…

      1. 1

        UNIX is both old and modern at the same time. The UNIX philosophy is old, but still relevant.

        Linux distros like Arch Linux has a wide selection of up-to-date and well maintained packages. The Linux kernel might be based on old ideas, but I would argue that it is no longer seventies tech. For distros like Arch or Fedora, the users can choose to install only modern packages, if they want.

        macOS, a proper UNIX, is a modern OS with modern software available.

        UNIX is modern.

      2. 10

        +1. See also https://blog.sanctum.geek.nz/unix-as-ide-introduction/ and the subsequent parts in the series for a good read about this

        1. 9

          I’m not saying putting everything into the editor makes it modern, just saying that it makes it easier to integrate between different things. I was a long time neovim user and didn’t even bother touching the integrated terminal or git plugins like fugitive but rather use tmux to combine everything. That said, if you have your git thingy in your editor, jumping to the file you are browsing in the git thingy, then enabling blame, going to the function under cursor flow is easy. And not just navigating, you can control the window positioning. You can technically do this with tmux + lazygit/tig + neovim, but it will be much harder to make them work together.

          1. 9

            Nebulous arguments about what is and isn’t “modern” aside, this seems to me to be the difference between a well-integrated workshop and a pile of tools. I like neat, isolated tools as much as the next digital aesthetician (daily tmux user) but there’s a reason that taking on the mental load of a greater pile of tools is unpopular and people want their development environment to just do useful things for them without reading a few dozen man pages and a handful of stack overflow posts. I like the way that Fish shell goes with this for example. It does a decent job of not taking on far too many features where it affects my own experience and I don’t have to worry about mile long dotfiles to get all the useful features. Would be nice to see more tools like that which aren’t stuck in the old ways.

            1. 5

              I think that integrating everything into the editor to make it modern is debatable.

              I don’t want to get into what’s modern and what’s not but one thing that’s useful to remember about “integrating everything into the editor” is that it’s cultural baggage. (I say that with all the sympathy in the world, I use Emacs).

              In Emacs, which is what the post seems to lean towards, it’s because of its ties with Lisp, the MIT environment, and, in the case of GNU Emacs, because of its drive towards portability. Emacs is very much a Lisp environment that runs an editor as its persistent interface. This is foreign to us but it was a popular way to make interfaces back then: dired, for example, which we now know as a major mode in Emacs, was once a standalone program with a deliberately editor-like interface (you can read some things about it here: https://www.saildart.org/DIRED.SGK%5BUP,DOC%5D1 ). Many of Emacs’ popular packages exist because people wanted to integrate it better with the underlying system, or they missed things from other systems – that’s how we wound up with dired or eshell, for example.

              In many editors that emerged from the DOS days, lots of functions and window management functions are integrated because the underlying system had poor multi-tasking and program integration capabilities. It wasn’t uncommon for DOS editors to integrate things like calculators and whatnot because even with TSR, it was rather unwieldy. System constraints (including the quality of window management and multitasking) in early Windows and OS/2 versions is one of the factors that contributed to the development of MDIs.

              More recently, the fact that lots of editors based on web stacks wind up integrating their own window management system is an artefact of the technological environment they’re in. Limited integration with the underlying system, or unreliable integration across the systems they want to support, means they have to redo some things themselves, higher up the stack.

              I can’t point at specific examples (editor internals isn’t something I’ve terribly preoccupied with in 10+ years) but I wouldn’t be surprised if integrating some functions were simply a way to avoid dependency churn, too. If a component is internal, you have control over visual and/or API changes, and over the schedule of integration efforts. I am personally guilty of having reinvented wheels for this exact reason over the years.

              I think it’s important for developers and designers not to get high on our own supply. Lots of things we make are made the way they are not because of some stroke of brilliant genius but as a consequence of external design constraints, or as workarounds for shortcoming further down the tech stack, or because it’s just the only way they can be made at the time, not necessarily the best. That’s how things like this goddamn terminal nonsense have been perpetuated, constraining shell interfaces to 1970s capabilities, even in editors, which likely don’t even need the full backwards compatibility baggage.

              1. 3

                An editor should not need to re-implement file picking

                A fun aside, my text editor, KeenWrite had a pure JavaFX file picker, which is a re-implementation of the native file picker.The reason? On Windows, there was a strange interaction between loss of focus and returning to the main application window. Fortunately, that bug was squashed in JavaFX 19, meaning the native file picker is back.

                On a related note, native file pickers can’t (easily) be integrated as tabbed panels in a JavaFX desktop application because they are dialogs. This leads to either re-implementing the native file picker, or integrating two different file pickers: native and JavaFX-based. Here’s a screenshot of the dockable file picker integrated into KeenWrite, showing the feature that needs a “re-implemented file picker”:

                https://i.ibb.co/DYTQzFh/keenwrite-filepicker.png

                1. 2

                  Here’s my obligatory mention of the acme editor, which acknowledged this. It’s been called more of an integrating development environment, instead of an integrated on.

                  • there’s a built-in “terminal”. This might seem like bloat, but in plan 9, a “terminal” didn’t need to do anything too fancy compared to a full vterm in unix land.
                  • file browsing: anything you right(?) click that is a path is opened. If it’s a directory, it’s a buffer with the output of ls.
                  • you can easily pipe selected text through commands you’d save in the “bar”. e.g. put |sort in your bar, select the text you want to sort, and middle click |sort. Your text is now sorted.
                  • window contents are exposed over 9p. You can extend the editor in any language that can do file IO.
                  • more “rich” features such as email are handled by mail being exposed as a filesystem. This is cheating a bit because that’s benefiting from the idioms of the plan 9 ecosystem, but it was meant to make that ergonomic.

                  I think it lacks some things that are table stakes for a quality development experience nowadays– but it exemplified the unix philosophy better than any other unix editor.

                2. 12

                  Uhu, couple of things to add:

                  • multiple cursors
                  • extend selection (https://www.jetbrains.com/idea/guide/tips/extend-selection/)
                  • light bulb (https://rust-analyzer.github.io/blog/2020/09/28/how-to-make-a-light-bulb.html) as a core UI metaphor alongside command palette.
                  • workspace/document symbol based navigation. It’s up to LSP to provide the data for these, but it’s up to the editor to make it a foundation of users workflow.
                  • syntax highlighting is tricky, ideally you do it in three layers: synchronous lexer-based highlighting, async syntax based highlighting, and async build-system dependent semantic highlighting.
                  • if editor is modal, it should use kakoune model
                  • if the editor is not modal, ctrl cvz should work as expected these days.
                  • these days, rg/computers are fast enough, but trigram index still feels like the right solution for code search
                  • not being shackled to the pile of obsolescence the Unix terminal is (text-centered interface is ok though)
                  • no save button/keybinding. Editor should automatically save files when needed, I should be able to revert to any file version in local history.
                  • run current test: boggles my mind that this is not part of LSP, rust-analyzer has this since forever.
                  • plug-ins are tricky (https://www.tedinski.com/2018/01/30/the-one-ring-problem-abstraction-and-power.html), I think the sweet spot is making the core things (eg, everything mentioned) built in, and having a well-defined narrow API for plugins to foster ecosystem (eg, vscode, not emacs, model)
                  1. 5
                    • multiple cursors: I almost always found using regex to find and replace better, or use macros
                    • extend selection: I am a big fan of using text-objects for a similar usecase (https://github.com/meain/evil-textobj-tree-sitter/)
                    • worksapce/document symbols: I kinda chucked them under the “language intelligence section” thought I should have called them out, but it is really useful
                    • modal editing: while I like how kakoune does things, I personally use vim as I can get a vim mode in most places. Same reason why I use markdown over org-mode even though org is better in most cases
                    • these days, rg/computers are fast enough, but trigram index still feels like the right solution for code search : I kinda do agree on this one. I also tried using things like https://github.com/BrianHicks/tree-grepper for code search which works in some scenarios, but grep/rg is just easier to go for
                    • not being shackled to the pile of obsolescence the Unix terminal : I waited for too long to get sixel in tmux and gave up
                    • no save button/keybinding: I personally like to save manually, I might have processes being kicked off every time the files is saved like rebuilding/running tests
                    • run current test: This makes a huge difference. I like https://github.com/vim-test/vim-test on the vim side, but nothing like it exists on Emacs. I am currently using https://github.com/meain/toffee/ to hack together something which does something like this.
                    • making the core things built in, and having a well-defined narrow API for plugins to foster ecosystem: I like the emacs model. While I might not change the core often, I would like to have the option to change it or at least instrument it to see how things work.

                    Also, thanks for rust-analyzer

                    1. 3

                      I personally use vim as I can get a vim mode in most places

                      I’ve found that the thing I need in most places (like this text area, for example) is mostly just convenient cursor movements, backspace and delete. This is solved more tactically by remapping arrow keys to the home row with software or firmware. But yeah, I am also very anti-vendor-lock-in type of person, with NixOS, Rust, djot, etc :)

                      I am currently using https://github.com/meain/toffee/ to hack together something which does something like this.

                      If I were to solve this problem, I’d probably try to add this feature to go language server, then to make Rust and Go language server agree on the extension, then publish a post advertising this. I think support from two big languages should be enough to get this implemented in every language. See https://github.com/microsoft/language-server-protocol/issues/944 as well.

                      I like the emacs model. While I might not change the core often, I would like to have the option to change it or at least instrument it to see how things work.

                      This is obviously a useful power, but it comes at the expense of the property – it’s now harder for core to evolve without breaking user’s init files. So, emacs is more extensible, but, at this point, VS Code has more extensions. Part of that is just popularity, but I also think is that a significant other factor is that VS Code extension is a much more well-defined component with a specific “syscall interface”. A fun testament to this model is how people now run VS Code extensions in vim using coc. To clarify, I don’t want to make a judgement call that “ecosystem evolution” is always better than “power of a single user to tinker”, but I do want to highlight that there’s an interesting tension between the two (but really I just want to plug tedinski post cause it’s that great)

                    2. 2

                      Window management

                      Oh, and this one should be made a bit stronger: editor should automatically show the relevant thing, and hide irrelevant things. “Standard” ide layout with file tree on the left, terminal on the bottom, and the editor squeezed in in between is pretty bad. Emacs with golden-ratio mode is much closer to ideal here.

                    3. 6

                      Glah! These editors are terrible. Where are my breadcrumbs (automatic saves between commits, for me not the team)? My debuggers have no evil or fuzzy schedulers to do optimally nasty swapping between jobs. I have no internationalization support to speak of, no type discovery from test cases, and no line/spec/test correlation.

                      We need to cultivate an understanding of how great the possible is, lest we get complacent with the commonplace.

                      1. 5

                        I never got into vim or emacs and I encourage anyone who feels that I am already wrong to keep reading.

                        Why do I prefer bloated IDEs like anything Jetbrains makes? Because they just work.

                        If I get a junior dev on my project, I can give them PyCharm and they’ll have syntax highlighting, code completion, and type hinting with zero configuration. They won’t have to google how to save a file or exit the editor. They can set a breakpoint, right-click the file and debug it with zero configuration. Wanna know what arguments go to that function? Press ctrl+p. Wanna go to the function definition even if that function comes from a library? Press ctrl+b. And it doesn’t matter if we’re working on Python, C, Rust, Go, or anything else — the buttons and features are all there every time.

                        I just don’t see the benefit of the other side. Sure I could spend weeks configuring dot files and installing supplemental language servers and documenting all of it, but I can’t give that to a junior. I now also have to maintain this system of dependencies just to write code.

                        Working on new systems is also difficult. What about offline systems? I can transfer a single CLion binary and it has everything bundled and it works.

                        I’m missing something clearly, but I just don’t get the other side.

                        1. 2

                          I would never deny anyone a tool that they find useful and productive. And for myself I do not find all that configuring and setup productive in and of itself, luckily I don’t have to do it all that often. What the configuring does offer me is the power to precisely configure my environment. To create tools that help me be productive.

                          Recently I used Helix Editor for a few coding sessions, and the subtle differences from Neovim killed my productivity. It made me realize that it is all the little things that I use that help me code, and edit, faster. I was able to configure some shortcuts to act like vim, but not enough to make it useful.

                          The draw for me, to Helix, is that everything is built-in, and I don’t have to spend time knowing what lspconfig is and why I need it if LSP is built into Neovim. Which is the same draw to IDEs, however IDEs are take it or leave it and don’t allow for precise configuration that vim allows. At least to the best of my knowledge.

                          1. 1

                            Why do I prefer bloated IDEs like anything Jetbrains makes? Because they just work.

                            They are amazingly good out of the box 99% of the time… but when things go bad, they go really bad. I got to fight a lot with PyCharm vs. 1+ million lines of Python 2.7. The codebase won. PyCharm could never really work properly in that very odd, customized mess of an environment.

                            If I get a junior dev …

                            I have worked with hundreds of juniors, and you know what I don’t do? Try to shove my personal environment onto them. If they don’t have one already, I generally recommend Jetbrains or VSCode.

                            Experts and junior developers use very different tools and workflows often. A junior barely knows how they want to work yet, let alone would grave the power of having a full lisp eval bound to M-:.

                            As you pointed out, learning Jetbrains IDEs is simple and well-documented, which means I can still show others how to use it while using a more adept setup personally.

                            I just don’t see the benefit of the other side.

                            Flexibility, customization, alternative workflows, advanced automation and integration, and in the case of emacs best in industry accessibility support – putting to shame the Jetbrains tools (which I am a $25 a month subscriber to). I know exactly how I want to work…

                            Sure I could spend weeks configuring dot files and installing supplemental language servers and documenting all of it,

                            It doesn’t take weeks, it shouldn’t take days unless you fall off the rails. It is a slow evolution, you don’t build a new workflow all at once, it comes in drips and drabs, you find something that bothers you, you fix it. Rinse and repeat for a few years and you got something exceedingly well built for you.

                            but I can’t give that to a junior.

                            Again, that is a very strange thing to optimize for – as you said, you can give a junior a link to jetbrains and it works out of the box, why constrain yourself to the worst developer on your team? That isn’t meant as an insult to them just – they are a brand new developer. Then you go on to speak of basic use of the tools and how they won’t have to google for this and that… again, I don’t think anyone is in favor of force-feeding junior developers emacs or vim. Most of the time, I am convincing them NOT to try to copy my environment, as it is mine and suited to me.

                            Working on new systems is also difficult. What about offline systems? I can transfer a single CLion binary and it has everything bundled and it works.

                            Most users of vim or emacs have fairly well defined solutions for setting up their environments, emacs and vim dwarf Jetbrains IDEs in portability. Look at the list of ancient/odd systems they are actively running on…

                            I have a somewhat kludgy solution versus lots of others and I am setup and running in under 6 minutes on most systems, even if I only have SSH access to them.

                            I’m missing something clearly, but I just don’t get the other side.

                            Keep in mind, most of the vim / emacs users I know are also able to work perfectly fine in Jetbrains, as you repeatedly pointed out – it is easy, consistent, and ready to go. But they choose not to, you on the other hand have never even tried the other side yet are willing to fairly aggressively discount its utility. Who knows, come take a vacation in alternative editors land (Kakoune, Emacs, Neovim), you might like it so much you stay.

                          2. 6

                            tl;dr emacs.

                            1. 21

                              The post is a lot better and more balanced than this comment makes it seem.

                              1. 7

                                You’re right, my comment was unnecessarily snarky.

                                I do think the article has a strong emacs bias. It lands on emacs being the best implementation of each modern editor feature, without rigorous comparisons (or often comparisons, period).

                                That’s not to say the article doesn’t have value - far from it, I enjoyed reading.

                                However, I do think it’s important to surface the bias.

                            2. 3

                              I skimmed the article, so forgive me if I missed this point: the actual editing of source code. This includes completion, modal, etc.

                              All I care about getting now is structured editing. I’ve seen several people’s experiments with tree-sitter powered structured editing in Emacs and in Neovim and it has me excited.

                              An interesting modern code editor outside of the ones listed in the article: https://github.com/CodeEditApp/CodeEdit.

                              1. 3

                                Now, without further adieu

                                Language nerd here. It’s actually “without further ado.” No italics: ado is an English word, just archaic except in a few phrases like this one and “much ado about nothing.”

                                1. 2

                                  I kinda meant that more as a joke(and thus the italics), but I guess it was too subtle. Appreciate you pointing it out though.

                                2. 2

                                  Coming from a kakoune (and to a lesser extent Sublime Text) background, I’d put first-class multi-selection support high on that list.

                                  1. 3

                                    This is one of the things that made me try out kakoune, but I still have not fully been able to grasp/utilize it. I always just tend to reach out to regex replace when I have to edit similar ish things.

                                    1. 3

                                      What’s the practical use of multiple cursors? Puzzle games have taught me that trying to control multiple moving objects at once is incredibly annoying, so I’m avoiding them.

                                      1. 3

                                        Text characters aren’t Lemmings that wander around the screen. A pretty common programming task is to take some group of objects and apply similar changes to all of them. Like say I have a string “a b c d e f g” and I want to make it into a JSON array. There are a million ways to do it, but in ST, a fast way is, highlight the space between a and b, press cmd+d five times, press enter, now it’s all on separate lines. Highlight the lines, and press cmd+shift+l. Now you have a multicursor on each line. Hold shift and highlight the word (if you use option+arrow, it will work with words of different lengths). Type quote and it will add the pair quote on the other side. Add the comma at the end, then use the mouse to clean up the extra comma. Typing out all the steps makes this seem tedious, but you can do it all in less than ten seconds and without thinking about what tools to use or whatever. And unlike Vim, it uses the same key mappings as normal GUI text editors, so you don’t have to learn a lot of bespoke mappings that don’t work in your web browser.

                                        1. 4

                                          I mean, it’s nice that you can do this, but it’s not really easier than a good old substitution:

                                          :s/\w/"\0",
                                          

                                          Do you have an example where multiple cursors are strictly the best approach?

                                          And unlike Vim, it uses the same key mappings as normal GUI text editors

                                          …which use a lot of modifier keys. And how would you even express something like d2t, (delete till second-next comma) with “standard” mappings?

                                          so you don’t have to learn a lot of bespoke mappings that don’t work in your web browser.

                                          There are tools like Tridactly, Firenvim and Qutebrowser. But to be honest, I just treat the editor and browser as two different tools with different controls.

                                          1. 3

                                            Here’s a case I ran into recently, tweaked a bit to make the problem clearer. I had an setup like this:

                                            [[a1, a2, a3, a4, a5],
                                             [b1, b2, b3, b4, b5],
                                             [c1, c2, c3, c4, c5],
                                             [d1, d2, d3, d4, d5]]
                                            

                                            Where each a_n is a number, not a variable (no s/\w4!), and I wanted to change the fourth element in every array to x. I could do this with a regex, but it’s a lot easier to do it with multiple cursors.

                                            You might say this is a very niche case, and that’s right, it is! But so is d2t, and yis and g/foo/norm!. Text editing is all about having a wide set of tools to cover as many niche cases as possible.

                                            1. 4

                                              For this I wouldn’t use regex, but either visual-block mode (if the numbers were vertically aligned) or a recording (otherwise). Either way, not that hard. What would the multiple cursors approach look like?

                                              Thinking about it, recordings are kind of like multiple cursors, with the difference that the cursors don’t exist at the same time.

                                              You might say this is a very niche case, and that’s right, it is!

                                              Well, I don’t think it’s that uncommon.

                                              But so is d2t, and yis

                                              Not really, I use similar combinations all the time.

                                              1. 7

                                                You really can combine the best of both: use a regexp to make multiple selections and then transform them somehow.

                                                This way you can visualize what changes you’re about to make and even edit them if needed.

                                                In my editor, I will often shift-n to select the next occurrence of the word under the main cursor, but then I can also skip occurrences and finally only edit the places I want.

                                                Also, with multiple cursors, implementing a ‘rotate params left’ is really easy.

                                    2. 2

                                      What font is that being used in the editors?

                                      1. 2
                                        1. 2

                                          Yup, the Emacs screenshots/videos are using Dank Mono.

                                          1. 1

                                            thank you!

                                          2. 2

                                            Seems like that would be a nice typeface if they’d get rid of the stupid ligatures.

                                            1. 1

                                              thank you!

                                          3. 1

                                            I also have syntax highlighting on, but I’m unsure if that’s wise. Maybe semantic highlighting might make more sense. Highlight the same variable in the same colour so that it’s easier to spot. Reserved words could be italicised. And I think comments should be more prominent. Maybe not boilerplate like javadoc. What would you use bold for? Types?

                                            1. 1

                                              I highlight variables with different colors, but only when I need to see the flow of a variable through code. Having it on permanently on felt a bit distracting.

                                            2. 1

                                              I really really like Kate, but it easier debugging capabilities. Currently it’s a bit fiddly to get to work.

                                              1. 1

                                                @meain: The tree-sitter link is broken, I wanted to send a pull request but couldn’t find the website sources on your GitHub profile.

                                                1. 1

                                                  Woops, let me take care of that. The blog source is private as of now.