In that perspective, the work here is admirable in that it adds Lisp style scripting to VSCode, but it's destined to never get close to the sort of interactive extensibility and exploration you get in Emacs itself. I'm not faulting them - these are expensive and time-consuming choices to take - and they are often at odds with the goals of writing a useful browser. Web Browser JS environments have some of the interactivity here, but they miss out on the self-documenting part, the use of the extension language as an implementation language, and all the cross linking into the source. This is very much like what you see in a Smalltalk image or a Lisp machine - the system is all 'of a kind', self-documenting, and fundamentally open by nature. This works for native C code too, provided you have the source installed. There's more documentation besides, and pressing enter on 'files.el' then takes you to the source code for the save file function. > C-x C-s runs the command save-buffer (found in global-map), which isĪn interactive compiled Lisp function in ‘files.el’. If I want to know what 'C-x C-s' does, it's possible to say 'C-h k C-x C-s' and see this: More than that, the code behind all of the functions is a keystroke or three away. The reason I say this is that Emacs isn't just extensible in Emacs Lisp, it's very extensively written in Emacs Lisp. That looks promising, but I have a feeling that vscode doesn't offer as much options to hook into the editor as emacs does.īut I don't think it's possible to get to Emacs' level of extensibility unless you adopt its philosophies - both legal and technical - from the outset.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |