> (It never ceases to amaze me that MS Word and its ilk do not seem to have equivalents of view-lossage or describe-key or where-is. Or am I mistaken?)
(I'm guessing the author means VS Code, not MS Word here?)
There are some features of Emacs that are amazingly useful, have been there for years (or decades), but which I haven't yet managed to find in any other editor. For example, regional undo: select a region of text and step back through changes in that region only.
> (I'm guessing the author means VS Code, not MS Word here?)
The author might mean MS Word. I definitely had this thought about a lot of software of all kinds, not just editors/IDEs. The two the author highlighted - view-lossage and describe-key, are to answer the questions "what sequence of keys/operations I've just performed?", and "what does this key/key sequence do, here, in this context?".
The former is useful if you e.g. mistype or type at a wrong moment, invoking some random actions in the program, and now you're wondering what exactly did you do. Also, since it's Emacs, there's actually a quick way to turn lossage into a keyboard macro and clean it up - so if you figured you want to repeat some sequence of operations after you've already done it once, you don't have to record it from scratch.
describe-key approximation exists in some software, typically via the "keyboard binding" preferences dialog containing a textbox for looking up commands by assigned keyboard shortcut. Alas, besides being a worse UX, this will only show you global assignments (or, sometimes, divided by categories). describe-key excels by showing you context-aware help, i.e. it literally tells you what command will be invoked if you press a given key sequence exactly where you are right now.
Author here. Definitely meant MS Word. I know a few people using VSCode, and I never heard any one of them saying "I clicked/typed something and something strange happened". OTOH, this is pretty common with MS Word.
I just assumed that you were comparing coding environments, but now I come to think about it, something like view-lossage could be really useful for a WYSIWYG editor.
vscode or msword.. doesn't really matter in a way, any keyboard heavy application could give users the history of keypressed, it's natural and often useful
tiny side note, word used to have inline macro tags (dos version 6 IIRC), so one could type
{ if YEAR > 1987 }
text
{ end if }
it was straighforward, and now replaced by GUI heavy systems, user interaction has regressed in a way
Not, it's build in: when you undo with a region highlighted the undo is limited to the content of this region.
Really nice when you made changes elsewhere and realize late that you made a mistake (but not too late: the undo info must still be present of course).
I'm pretty sure it was a fair reading, for people who read the article.
The article discussed the option of throwing 40 years of development out the window or borrowing/imitating things from emacs/vim. Then the MS Word comment was made, "It never ceases to amaze me that MS Word and its ilk do not seem to have equivalents of ..."
I'm pretty sure you are reading what you want to tread instead of what is written.
> The article discussed the option of throwing 40 years of development out the window or borrowing/imitating things from emacs/vim.
The article says that even in a 40 y.o. piece of software such as emacs, low-hanging fruits can be found; and thus, that people writing new editors should take inspiration from features from vim/emacs when creating their own, and stand on the shoulders of 40 years of incremental improvements.
Then, as an aside, he remarks that he's surprised that MS Word has not borrowed the lossage feature from emacs – with which I agree: when I accidentally hit keys and break a document, it would be useful to know which key I hit, and which functions I triggered.
I already use use-package, so that's great...
I also use projectile and it's been working great... how should I prepare to move to project.el? Are there any guides? Or things just work the same I am used to, and I just need to delete projectile once upgrading?
I also use lsp-* for all IDE features... is eglot going to be the better choice here for every language?? LSP works with Go, Dart, Java, Zig, Rust, Lua... do I need to remove all my config for those to use eglot??
> how should I prepare to move to project.el? Are there any guides? #
I recently switched from projectile to project and I noticed essentially zero changes. If you're not doing anything particularly custom you might not even notice.
> I also use lsp-* for all IDE features... is eglot going to be the better choice here for every language?? LSP works with Go, Dart, Java, Zig, Rust, Lua... do I need to remove all my config for those to use eglot??
eglot is just another (awkwardly named) lsp-client. It uses the exact same servers as lsp-mode does.
You’ll need to adapt some hooks and key-bindings, but in terms of capabilities you shouldn’t be losing out.
> I am more excited by Emacs 30, mostly I like the ahead of time compilation of Lisp code.
Emacs has had an ahead of time compilation feature, "Native Compilation," since Emacs 28. Is this what you mean? Or is the Emacs 30 feature something different?
As an emacs user who has never paid much attention to the development pace, is it just that people talk more about Emacs or is there actually more momentum around it these days because it feels that way. Which is kind of amazing for a piece of software that old.
Probably both IMO. Since melpa there's been an increase in contributions (it helps not having to be license compatible like core emacs extensions I guess), and even then there was heavy work like native-comp that landed very very rapidly.
Does anyone have any recommendations on Emacs performance tweaks on large codebases? I used Emacs (Evil mode) for about a year, but then switched to VSCode simply because the latency spikes while editing drove me nuts. VSCode has these too, but not as frequently or severely.
> The sentence commands assume that you follow the American typist’s convention of putting two spaces at the end of a sentence. That is, a sentence ends wherever there is a ‘.’, ‘?’ or ‘!’ followed by the end of a line or two spaces, with any number of ‘)’, ‘]’, ‘'’, or ‘"’ characters allowed in between. A sentence also begins or ends wherever a paragraph begins or ends. It is useful to follow this convention, because it allows the Emacs sentence commands to distinguish between periods that end a sentence and periods that indicate abbreviations.
Over 40 years ago is definitely "at or before" Emacs 24.1. Specifically before.
As far as I can tell, the "probably introduced at or before" info comes from finding a symbol's first appearance in NEWS. So if there were no changes to `count-words` between Emacs 1 and 24, this is what you'd get.
(I'm guessing the author means VS Code, not MS Word here?)
There are some features of Emacs that are amazingly useful, have been there for years (or decades), but which I haven't yet managed to find in any other editor. For example, regional undo: select a region of text and step back through changes in that region only.