Toward a "modern" Emacs

Posted Sep 25, 2020 19:44 UTC (Fri) by mtk (subscriber, #804)
Parent article: Toward a "modern" Emacs

someone mentioned that they've been using emacs since 1987. i've been using it since 1979 :-). i don't think a dark theme default is important (how old was the kid who suggested that?? his eyes must still work in dim light :-)). ditto for the other proposed changes. i think the way emacs supports LSP (the language server protocol) and eventually BSP (the build server protocol) is *critical*. this is what will matter to developers. this is how emacs can compete with IDE's and VS Code.

right now emacs supports LSP if you know how to pull it out of MELPA. but the number of available LSP servers for each language alone is confusing. and the number of complimentary libraries and their overlapping functionality is *bewildering*.

it would be useful if LSP support became part of the base. and if someone focused on providing a best-of-breed out-of-the-box LSP/tool setup that worked for all of the major languages

Toward a "modern" Emacs

Posted Sep 25, 2020 20:49 UTC (Fri) by mpr22 (subscriber, #60784) [Link] (4 responses)

I'm 43 and I prefer light-on-dark themes in applications and have my terminals set to lightgrey on black as the default colours.

bright backgrounds are (mostly) fantastic on reflective surfaces (books etc), but IME they're horrible on emissive surfaces (like computer screens).

Toward a "modern" Emacs

Posted Sep 25, 2020 21:23 UTC (Fri) by dskoll (subscriber, #1630) [Link] (3 responses)

Yes, my emacs is in "dark mode" by default.

$ xrdb -n -query | grep -i emacs
Emacs.background:       Black
Emacs.bold.attributeForeground: Blue
Emacs.foreground:       Wheat1
Emacs.italic.attributeForeground:       hotpink

Toward a "modern" Emacs

Posted Sep 26, 2020 4:47 UTC (Sat) by felixfix (subscriber, #242) [Link] (2 responses)

Does no-one use "--reverse-video"? I've got aliases and shell scripts which all use it.

Toward a "modern" Emacs

Posted Sep 26, 2020 13:01 UTC (Sat) by dskoll (subscriber, #1630) [Link] (1 responses)

That would give me white on black. I want wheat1 on black. ☺️

Toward a "modern" Emacs

Posted Sep 26, 2020 15:01 UTC (Sat) by felixfix (subscriber, #242) [Link]

You need a --glucose-tolerant mode :-)

Toward a "modern" Emacs

Posted Sep 25, 2020 21:52 UTC (Fri) by mina86 (guest, #68442) [Link] (19 responses)

As a person who doesn’t use LSP, I completely agree. When I speak with people about their editors, it’s never colours that they mention. It’s the ability to auto-complete, jump to definitions, refactor etc.

Toward a "modern" Emacs

Posted Sep 25, 2020 23:33 UTC (Fri) by dskoll (subscriber, #1630) [Link] (18 responses)

Autocompletion, jumping to definitions, etc. are all really good in Emacs. (OK, you need to use helper programs like etags for navigating to definitions.)

The problem is that some features require setup, and others are not obvious... I didn't know about Emacs's dynamic autocompletion using M-/ until I'd been using it for about 10 years. (I'm 30 years in on Emacs now and not switching editors any time soon...)

Toward a "modern" Emacs

Posted Sep 26, 2020 11:27 UTC (Sat) by dottedmag (subscriber, #18590) [Link] (16 responses)

etags means the definitions database is perpetually out of date (unless etags is run every time a file is changed in editor). This is not how computers ought to work in 2020.

Toward a "modern" Emacs

Posted Sep 26, 2020 13:00 UTC (Sat) by dskoll (subscriber, #1630) [Link] (2 responses)

I've never found this to be a problem in practice. When you're first navigating a large new software project, you don't change it much and etags is indispensable for navigating it. After that, refreshing a couple of times a day is generally good enough.

Toward a "modern" Emacs

Posted Sep 26, 2020 15:36 UTC (Sat) by dottedmag (subscriber, #18590) [Link] (1 responses)

Have you tried doing any extensive refactoring work on large codebases? It is essential to have up-to-date lists of references, especially in dynamically typed languages, to be productive.

Toward a "modern" Emacs

Posted Sep 26, 2020 21:02 UTC (Sat) by dskoll (subscriber, #1630) [Link]

I have not done extensive refactoring work on large codebases. I have done Linux kernel driver development and development of several quite large systems in languages including C, C++, Perl and PHP. And Emacs has worked very well for me.

Toward a "modern" Emacs

Posted Sep 27, 2020 9:52 UTC (Sun) by pgdx (guest, #119243) [Link] (10 responses)

I have a post-commit-hook in git that runs etags. Keeping each commit relatively small has the added benefit of keeping TAGS up-to-date.

You of course rebase/reorder/reword/squash your history before publishing it if necessary.

Toward a "modern" Emacs

Posted Sep 27, 2020 10:48 UTC (Sun) by dottedmag (subscriber, #18590) [Link] (8 responses)

Post-commit is too coarse.

I don't understand how in 2020 the index is not *always* up-to-date. We've got so much computing power, and we still have to run tools manually over a dataset (source code) that is sized in megabytes, and is modified less than a kilobyte per second?

Toward a "modern" Emacs

Posted Sep 27, 2020 11:55 UTC (Sun) by cmonsanto (subscriber, #96651) [Link] (7 responses)

> I don't understand

There's nothing to understand, it's a technically inferior solution. It was a hassle decades ago, and unacceptable in the age of LSP.

Toward a "modern" Emacs

Posted Sep 27, 2020 11:59 UTC (Sun) by dottedmag (subscriber, #18590) [Link]

Thanks, I was beginning to question my own sanity.

Toward a "modern" Emacs

Posted Sep 27, 2020 14:27 UTC (Sun) by dskoll (subscriber, #1630) [Link] (5 responses)

It's a "technically inferior" solution whose inferiority matters roughly 0.00% of the time, to the nearest hundredth of a percent. This is really nitpicking.

Toward a "modern" Emacs

Posted Sep 27, 2020 15:49 UTC (Sun) by cmonsanto (subscriber, #96651) [Link] (4 responses)

It's not nitpicking. The tags solution requires more work to setup and you get less from it. If it works for you then great, but why would a new user want to learn this arcane workflow when LSP Just Works(tm) in VSCode, the editor everyone else in their office uses? This is what I'm getting at when I say tags are "unacceptable" in this day in age.

Toward a "modern" Emacs

Posted Sep 28, 2020 0:32 UTC (Mon) by dskoll (subscriber, #1630) [Link] (3 responses)

Never having used VSCode before, I gave it a whirl. Fired it up on a directory containing some C sources, installed the C/C++ addon, and...

The cross-referencing didn't work. Every time I tried to jump to the definition of a function, it took me to the declaration instead. So much for "Just Works (tm)".

Toward a "modern" Emacs

Posted Sep 28, 2020 5:14 UTC (Mon) by jem (subscriber, #24231) [Link] (1 responses)

The C/C++/C# extensions for VSCode come from Microsoft. Call me paranoid, but I suspect Microsoft does not really want VSCode to be easy to use on projects using those languages. This because they don't want it to compete with their commercial offering, the original Visual Studio.

Toward a "modern" Emacs

Posted Sep 28, 2020 5:24 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

The original MSVS is 0xDEAD. It's stuck on 32 bits and apparently moving it to 64 bits would be tantamount to rewriting it fully. It's still being developed with incremental features because VSCode is not yet up to feature parity, but that's just a matter of time.

There's no incentive for MS to sabotage VSCode, they want to make sure developers are using Microsoft's tools that conveniently have all these nice out-of-the-box integrations with Microsoft services.

I have no idea what went wrong for you, but my VSCode works just fine with navigation and refactoring support.

Toward a "modern" Emacs

Posted Sep 28, 2020 12:04 UTC (Mon) by dskoll (subscriber, #1630) [Link]

I also investigated using VSCode for Perl development. The Perl extension I found asks you to install (surprise) ctags. So again, meh.

Toward a "modern" Emacs

Posted Sep 28, 2020 13:08 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

So you have to rerun manually when you switch branches? There is also a post-checkout hook too you might want to attach that to.

Toward a "modern" Emacs

Posted Oct 1, 2020 11:54 UTC (Thu) by neilbrown (subscriber, #359) [Link] (1 responses)

I used to use etags extensively when working with code. I recently changed to a different editor which doesn't (yet) support etags, and having missed it at all.
This editor has easy access to "git grep", so I click on a name, "Alt-dot", and up pops a list of matches, which I can select from or walk through. Sometimes finding the declaration among all the uses is tricky, but usually it is no trouble.
The result of "git grep" is always completely up-to-date!

Toward a "modern" Emacs

Posted Oct 1, 2020 14:48 UTC (Thu) by geert (subscriber, #98403) [Link]

Tried that in the days your git (or bk) tree didn't fit in the page cache?
Indexing matters, if your full data set doesn't fit in RAM.
These days we have Google search, which is faster than finding something on your local machine.

Toward a "modern" Emacs

Posted Oct 4, 2020 11:32 UTC (Sun) by wtarreau (subscriber, #51152) [Link]

> I didn't know about Emacs's dynamic autocompletion using M-/ until I'd been using it for about 10 years

Never heard about it over the last 25 years. I'm using M-, for tags though. Will have a look, thanks.

Discoverability of features is absolutely horrible there. Just enabling popups a-la "did you know" on startup would promote a lot of them. Of course it would require that they are actually usable without having to blindly copy-paste config sections from stackoverflow...