Comment by vidarh | Hacker News Reader

Comment by vidarh | Hacker News Reader

Parent Full thread

I wouldn't be happy with Python, but I do agree with the general premise that extensibility or automation ought to be expected of editors.

My own editor is written in Ruby, and so all extension is done by loading Ruby code into the running process, and I can drop into the Pry debugger with a keypress, or another keypress gives me a prompt to enter a single-line expression instead. The latter is literally a one-line method. Adding a binding to eval() a whole buffer would be equally trivial... Being able to extend everything trivially in a language I'm comfortable with (so not Emacs lisp) makes such a difference to usability.

Incidentally, the ability to interact with the open buffers using a script also from outside the editor is another thing I love as an extension mechanism for editors - an idea I first saw in FrexxEd (co-written by the founder of Curl) for the Amiga, which exposed the open buffers in the filesystem (think the Amiga equivalent of a FUSE filesystem), which would have the added benefit of not being language specific. It doesn't need to involve any FUSE-like stuff either - just a command line utility to "cat" an open buffer and to replace the open buffer from stdin would be sufficient.

Out of curiosity, what do you actually use the Ruby liveloading feature for? I use Neovim, which has a similar (but less powerful) feature that allows one to live-execute Lua code (or Vimscript, I suppose). But I almost never use it outside of testing code for my configuration, because the rest of the editor's feature set suffices fairly well for text editing.

I don't very often load code "live" other than on starting a client in the form of "macros" which are pretty much stuff I don't want to add into the editor core because it e.g. might be short lived or is just too esoteric. Even though my editor is mostly for myself, imagine anything you might put in your .vimrc, except it's only self-discipline that separates this from core editor code.

E.g. I have functions in there to insert headers in my journal for example.

In terms of executing code "actually" live, it's ~80% for debugging when I work on the editor itself. Pry provides all of the plumbing so all the code needed to add that is just to suspend the editors own input handling and call pry, coupled with an exception handler that calls pry as well, so there was no reason not to, basically.

But once I'd added it, the 20% left felt worthwhile as a means of e.g. do complex searches, or generate tables or otherwise do search and replace of content that requires more (e.g. parsing timestamps and replacing them with another format....) and any number of things I don't do very often but that feels very comfortable when you do need it. To be clear it's not like it does much you can't do easily without it. E.g. after all I could just dump the buffer to a file, load it in my repl of choice, manipulate it and write it out again and reload it in my editor. It's one of those small things that feels unimportant when you don't have it there, that doesn't save you a huge amount of time, but that just makes things feel nicer when you get used to them.

Vim can run Ruby scripts, so it also provides this feature.

Yeah it does not need to be python, I dropped emacs lisp due to (pain), never liked bash, or perl. Java like in matlab isnt nice either, too damned verbose. Ruby might work, most webstuff is great at showing stuff, but I havent tried it.

The generic variant would be to make it modular and replaceable, but that would be a mistake, I would much rather have a tool good at a specific subset of jobs than a config heavy tool which is medicore at all. Perhaps advanced search and replace fits that, but I think its a fundamental aspect of editing.

Thats a good idea!

Reply on news.ycombinator.com