I have somewhat a similar thing going on with https://github.com/meain/toffee/ . Being able to do “run current test” and “run previous test” comes in pretty handy.
Alt-o (or its equivalents in other editors) I use all the time. Generally for me, multicursor + such “extend selection to the next syntax node” + moving arrows and other navigation keys to the home row give 80% of the modal editing, without needing modal editing.
This sent me down a rabbit hole, finding out how to æ make option really work as alt on macos with Norwegian keyboard.
Turns out there’s a ton of nonsense coded as alt(option)+letter - behaving more like compose - eg option-o inserts unicode glyph for œ (U+0153), and alt-a inserts the apple logo, for those with a burning desire to type that in directly.
So far the best fix I’ve found (wip) is to define a copy of current input in ukulele - and manually remove/replace pretty much everything defined behind option-modifier.
As a bonus there are some dead keys, like tilde - that only outputs tilde on tilde followed by space - otherwise a composition like ñ (U-00F1) - which is also possible to get rid of.
For anyone who has similar problems with dead keys on macOS, but only in the terminal, note that you don’t need to create a new keyboard layout to solve that:
In macOS’s built-in Terminal, go to Preferences > Profiles > Keyboard and check “Use Option as Meta key”.
In iTerm, go to Preferences > Profiles > Keys > General and select “Esc+” for the Left Option key or the Right Option key (docs).
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.”
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.
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
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.
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 :)
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)
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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…
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.
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.
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.
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.
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”:
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.
Kinda interestingly, at former $JOB we had a coding interview set up in repl.it. One day they moved over to Nix as the way to set things up.
We used to have a simple pip install -r requirements.txt flow. That got switched over to nix packages python39Package.blah. But the kinda shocking thing was how there really was no simple way to do version pinning absent pulling in all the packages ourselves.
I believe that they talk about having a … globally consistent repository state, and not having a billion different versions of packages everywhere. But I really do wish there would be a practical consideration for how people tend to work with language packages (especially in Python).
If you have 30 Python dependencies, asking people to just upgrade all of them at once through channel switching is very unreasonable. Especially when the version of Django I’m using is completely orthogonal to the version of, like, zsh I’m using.
I have seen descriptions of how to pull in packages manually, and I have to play with that more, but I do hope to one day figure out the “trick” to allow for easier Nix adoption for languages like Python that sorely need what Nix has to offer.
But, you are correctly identifying a sharp corner. The ~distro model is okay for general use, but not so great for dev. (and it takes extra work, within nix, to fix this).
I have somewhat a similar thing going on with https://github.com/meain/toffee/ . Being able to do “run current test” and “run previous test” comes in pretty handy.
One candidate here is syntax aware “text objects”: https://docs.helix-editor.com/usage.html#syntax-tree-motions
Do you use that a lot? For me it seems to have tho potential to be amazing, but I keep forgetting to use it.
For me the killer feature is the multi cursor. I use that all the time.
Neovim does have this feature in the form of https://github.com/nvim-treesitter/nvim-treesitter-textobjects/
Alt-o(or its equivalents in other editors) I use all the time. Generally for me, multicursor + such “extend selection to the next syntax node” + moving arrows and other navigation keys to the home row give 80% of the modal editing, without needing modal editing.Wow, Alt-o is killer - I should use this a lot more!
This sent me down a rabbit hole, finding out how to æ make option really work as alt on macos with Norwegian keyboard.
Turns out there’s a ton of nonsense coded as alt(option)+letter - behaving more like compose - eg option-o inserts unicode glyph for œ (U+0153), and alt-a inserts the apple logo, for those with a burning desire to type that in directly.
So far the best fix I’ve found (wip) is to define a copy of current input in ukulele - and manually remove/replace pretty much everything defined behind option-modifier.
As a bonus there are some dead keys, like tilde - that only outputs tilde on tilde followed by space - otherwise a composition like ñ (U-00F1) - which is also possible to get rid of.
Now I can have my alt-o!
https://software.sil.org/ukelele/
The general idea: https://medium.com/@scr34mz/make-your-mac-keyboard-work-on-medium-and-others-editors-without-dead-keys-issues-french-keyboard-4666b72fa2ae For dead keys
For anyone who has similar problems with dead keys on macOS, but only in the terminal, note that you don’t need to create a new keyboard layout to solve that:
Haven’t seen that yet! Looks pretty nice.
Sounds like an interesting idea, but I think it might be better added to something like git notes instead of into the commit message.
Do you know of any online web frontend that shows git-notes? I think that not even cgit shows them. Same with github and gitea.
Ahh, unfortunately I don’t think any frontends show git notes. GitHub used to do it, but dropped support way back. https://github.blog/2010-08-25-git-notes-display/
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.”
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.
What font is that being used in the editors?
Looks like Dank Mono: https://philpl.gumroad.com/l/dank-mono
Yup, the Emacs screenshots/videos are using Dank Mono.
thank you!
Seems like that would be a nice typeface if they’d get rid of the stupid ligatures.
thank you!
Uhu, couple of things to add:
Also, thanks for rust-analyzer
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 :)
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.
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)
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.
Coming from a kakoune (and to a lesser extent Sublime Text) background, I’d put first-class multi-selection support high on that list.
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.
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.
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.
I mean, it’s nice that you can do this, but it’s not really easier than a good old substitution:
Do you have an example where multiple cursors are strictly the best approach?
…which use a lot of modifier keys. And how would you even express something like
d2t,(delete till second-next comma) with “standard” mappings?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.
Here’s a case I ran into recently, tweaked a bit to make the problem clearer. I had an setup like this:
Where each
a_nis a number, not a variable (nos/\w4!), and I wanted to change the fourth element in every array tox. 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,andyisandg/foo/norm!. Text editing is all about having a wide set of tools to cover as many niche cases as possible.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.
Well, I don’t think it’s that uncommon.
Not really, I use similar combinations all the time.
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-nto 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.
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?
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.
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.
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…
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.
+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
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.
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.
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 withdiredoreshell, 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.
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
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.
ls.|sortin your bar, select the text you want to sort, and middle click|sort. Your text is now sorted.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.
@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.
Woops, let me take care of that. The blog source is private as of now.
The combination of direnv and nix has been just blissful
Kinda interestingly, at former $JOB we had a coding interview set up in repl.it. One day they moved over to Nix as the way to set things up.
We used to have a simple
pip install -r requirements.txtflow. That got switched over to nix packagespython39Package.blah. But the kinda shocking thing was how there really was no simple way to do version pinning absent pulling in all the packages ourselves.I believe that they talk about having a … globally consistent repository state, and not having a billion different versions of packages everywhere. But I really do wish there would be a practical consideration for how people tend to work with language packages (especially in Python).
If you have 30 Python dependencies, asking people to just upgrade all of them at once through channel switching is very unreasonable. Especially when the version of Django I’m using is completely orthogonal to the version of, like, zsh I’m using.
I have seen descriptions of how to pull in packages manually, and I have to play with that more, but I do hope to one day figure out the “trick” to allow for easier Nix adoption for languages like Python that sorely need what Nix has to offer.
You can use tools like https://github.com/nix-community/poetry2nix to convert your pinned python dependencies to nix and use that instead of just pulling from nixpkgs.
Related to what meain said, https://github.com/DavHau/Mach-nix can do this with a requirements.txt file.
But, you are correctly identifying a sharp corner. The ~distro model is okay for general use, but not so great for dev. (and it takes extra work, within nix, to fix this).