> 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 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?
> (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.
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'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
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.
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.
47 comments
[ 2.4 ms ] story [ 102 ms ] threadEmphasis added.
(https://www.gnu.org/software/emacs/manual/html_node/emacs/Se...)
Yes, it's not necessary with justified text when using (for example) TeX.
But seeing a solid wall of text in a long paragraph with no hints as to its sentence structure other than a tiny "."? No thanks.
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.
https://i.redd.it/1a4yhesko26a1.png
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?
(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.
Is that from a package?
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 took that to mean that the author painted all non-emacs editors as not really being useful editors.
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 ..."
> 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.
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.
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
- use-package built in
- csharp-mode (now built in)
- typescript-mode (now built in)
- same with json-mode too.
- project.el instead of projectile
- eglot (now built in) over lsp-mode
As far as Emacs releases goes this one has more functionality packed than I can remember in any previous release ever.
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??
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.
https://www.gnu.org/software/emacs/manual/html_node/emacs/Pr...
As far as I'm concerned, project.el lacks the following features OOTB:
1. Something like the .projectile file to mark a folder as a project (without VCS).
2. Support for ag, rg and vterm.
3. Register new project types (to customize configure commands, compile commands, etc.)
4. Regenerate tags.
5. The ability to find the "other file" (x.h <-> x.c) across the project.
And this list is incomplete! So if you rely on any of the above, I suggest not migrating to a project.el-only setup.
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.