EmacsConf 2021 Call for Proposals(emacsconf.org)
emacsconf.org
EmacsConf 2021 Call for Proposals
https://emacsconf.org/2021/cfp/
84 comments
As one of the EmacsConf organizers, I'm particularly fond of talks that explore how people use Emacs outside the standard software dev stuff, although I'm also keen on talks that demonstrate a well-configured workflow for code or other things. =) Both EmacsConf 2019 and 2020 had lots of talks for general audiences and lots of talks focused on development, so you'll probably find something that interests you.
Actually, can I convince you to share your experience and submit a talk proposal? User stories were a well-received part of EmacsConf last year, and lots of people liked Pierce Wang's talk on learning Emacs as a high school student who's passionate about music. I think people would love to hear about how you wandered in, how you climbed up that learning curve, and how you've been tweaking things to fit you. =)
Actually, can I convince you to share your experience and submit a talk proposal? User stories were a well-received part of EmacsConf last year, and lots of people liked Pierce Wang's talk on learning Emacs as a high school student who's passionate about music. I think people would love to hear about how you wandered in, how you climbed up that learning curve, and how you've been tweaking things to fit you. =)
p.s. love you weekly Emacs blog, its such a joy to read. Thanks for doing that!
Well said. :-)
> As someone who’s not a developer nor a full-time product person,
If this year's Emacsconf is anything like the last one, you are a good candidate for watching/attending it. I know whenever Emacs is brought up on HN inevitable comparisons with IDEs and VSCode are made, but if you browse last year's talks, you'll see that most talks are not related to SW development. Emacs has a lot of enthusiasts who like it not for SW development but as an ecosystem.
If this year's Emacsconf is anything like the last one, you are a good candidate for watching/attending it. I know whenever Emacs is brought up on HN inevitable comparisons with IDEs and VSCode are made, but if you browse last year's talks, you'll see that most talks are not related to SW development. Emacs has a lot of enthusiasts who like it not for SW development but as an ecosystem.
Unified interfaces and allowing users to transfer any transferable knowledge between programs was one of the main ideas behind GUIs like the original Macintosh and Windows, but somewhere around the turn of the millennium things... broke.
But there was a time when interfaces were unified, sometimes to an absurd level (e.g. applications having a File menu when they had nothing to do with files) but IMO that is still better than every app being its own thing.
But there was a time when interfaces were unified, sometimes to an absurd level (e.g. applications having a File menu when they had nothing to do with files) but IMO that is still better than every app being its own thing.
> but somewhere around the turn of the millennium things... broke
The rise of electron as an 'acceptable' (to some people) substitute for platform-native applications and the myth of the possibility of the "cross platform UI" has accelerated this, really. It's quite unfortunate.
The rise of electron as an 'acceptable' (to some people) substitute for platform-native applications and the myth of the possibility of the "cross platform UI" has accelerated this, really. It's quite unfortunate.
Seems like Electron would make a stronger foundation than native toolkits for Emacs-style flexibility, extensibility and composition. The DOM, for all its faults, charts a solid path between being flexible and still being structured, all while making it easy to change and extend from the outside. I've found it's much easier to write a browser extension that adds functionality to GMail—even without GMail actively supporting extensions—than it is to write a similar extension to, say, the native Outlook app (even with explicit plugin support from Microsoft).
I haven't paid much attention to the Electron world myself so I don't know to what extent anybody is taking advantage of this, but even if they're not, I expect it would be easier than with alternatives.
I haven't paid much attention to the Electron world myself so I don't know to what extent anybody is taking advantage of this, but even if they're not, I expect it would be easier than with alternatives.
My first job out of college was developing software on the Macintosh in the late 80s/early 90s and I absolutely took for granted being able to count on the user interface to work in a sane and consistent way for 99% of all software. I fondly recall and very much miss that.
there's some enjoyable stability in emacs in a way, sadly it's changing a bit due to the growing number of packages and overlays. But it's still a little less tiring than trying idea then vscode then <new-ide>
In emacs I get my freedom, it's cool. And in 2020.. it's the 2nd or 3rd lightest choice.
In emacs I get my freedom, it's cool. And in 2020.. it's the 2nd or 3rd lightest choice.
> As someone who’s not a developer nor a full-time product person
Emacs was famously used by “secretaries” (as they were referred to in those days) not only to write documents and mail but to write macros to make their lives simpler. Of course none of them could “program” (which was considered quite intimidating) but they didn’t consider writing Emacs macros to be “programming”.
Back then Emacs was written in TECO so writing actual libraries was pretty arcane and not as easy as it is today.
But I’m glad the learned helplessness around programming has largely ablated, in part through improved tools and in part through simple acceptance.
Emacs was famously used by “secretaries” (as they were referred to in those days) not only to write documents and mail but to write macros to make their lives simpler. Of course none of them could “program” (which was considered quite intimidating) but they didn’t consider writing Emacs macros to be “programming”.
Back then Emacs was written in TECO so writing actual libraries was pretty arcane and not as easy as it is today.
But I’m glad the learned helplessness around programming has largely ablated, in part through improved tools and in part through simple acceptance.
The version that was used by secretaries in that story was programmed in Lisp, MACLISP for Multics specifically, and extended in Lisp.
I would be surprised if that were the case as the secretaries in tech square were using it on the PDP-10.
But its very possible -- I never interacted with any non-programmer Multics users.
But its very possible -- I never interacted with any non-programmer Multics users.
The AI ITS machines I think weren't used by non-technical users much, the TOPS-20 machines might be, but the anecdote I heard was always in context of Multics, which had much more explicit time sharing story behind it (with computing as utility).
I don’t know why you say that — the ITS machines were used by everybody in 545 tech square, researchers, admins and “secretaries” alike (both AI and LCS), from when I was there until they were gradually retired. The one TOPS-20 machine, Oz, didn’t arrive until times had changed and a lot of alternatives were already in use.
As for time sharing: ITS stands for “Incompatible Timesharing System” (a joke on CTSS), with memory protection, etc used by multiple users on terminals and over the net starting around/before the Multics project (all of which preceded Emacs of course)
As for time sharing: ITS stands for “Incompatible Timesharing System” (a joke on CTSS), with memory protection, etc used by multiple users on terminals and over the net starting around/before the Multics project (all of which preceded Emacs of course)
Multics was also at 545 tech square, from 1967 to 1988.
ITS version 1 is counted from 1967 as well (first mentions of PDP-6 ITS), simply because Project MAC couldn't deliver computing resources needed by other groups, not to mention AI Lab tended to modify the hw all the time (a fate AFAIK common to all ITS systems).
The anecdote about secretaries extending Emacs came from RMS, describing a group that used the shared "utility" computing resources provided by Project MAC (later turned into LCS) and who used a manual that didn't mention the word programming, compiled by who-knows-who, which showed how to modify Multics Emacs (which was the second Lisp-based Emacs) to user's liking.
ITS version 1 is counted from 1967 as well (first mentions of PDP-6 ITS), simply because Project MAC couldn't deliver computing resources needed by other groups, not to mention AI Lab tended to modify the hw all the time (a fate AFAIK common to all ITS systems).
The anecdote about secretaries extending Emacs came from RMS, describing a group that used the shared "utility" computing resources provided by Project MAC (later turned into LCS) and who used a manual that didn't mention the word programming, compiled by who-knows-who, which showed how to modify Multics Emacs (which was the second Lisp-based Emacs) to user's liking.
> Emacs was famously used by “secretaries”
As a law student in 1980-81, I wrote a custom user manual for the law review editors and our admin to use Emacs and Brian Reid's Scribe formatter (on the Computer Science Department's TOPS-20 machine using a VT-100 terminal over a 9600 bps line). I was the only even-remotely technical person on the editorial board, but even so, we were all in heaven: Once manuscripts were typed into Emacs / Scribe by our admin, we didn't have to literally cut, paste, hand-mark, retype, etc., on paper as the editing process progressed. And it speeded up the production process because we sent "clean" edited manuscripts to the printer, as opposed to manuscripts with significant pen-and-ink proofreader marks; this dramatically reduced the time we spent reading and correcting galley proofs. (Electronic transmission to the printer was next on the experiment list but we graduated and left.) I'm sure that's why I've been an Emacs user ever since, and wrote keyboard emulators for WordPerfect and MS Word.
As a law student in 1980-81, I wrote a custom user manual for the law review editors and our admin to use Emacs and Brian Reid's Scribe formatter (on the Computer Science Department's TOPS-20 machine using a VT-100 terminal over a 9600 bps line). I was the only even-remotely technical person on the editorial board, but even so, we were all in heaven: Once manuscripts were typed into Emacs / Scribe by our admin, we didn't have to literally cut, paste, hand-mark, retype, etc., on paper as the editing process progressed. And it speeded up the production process because we sent "clean" edited manuscripts to the printer, as opposed to manuscripts with significant pen-and-ink proofreader marks; this dramatically reduced the time we spent reading and correcting galley proofs. (Electronic transmission to the printer was next on the experiment list but we graduated and left.) I'm sure that's why I've been an Emacs user ever since, and wrote keyboard emulators for WordPerfect and MS Word.
I've been using emacs for many years now, and I'm sad to say that it has never been slower, despite the hardware getting better. Now it lags like crazy when editing a latex document, no matter the recent version. Something went off the rails in the last year or so, and even Atom is more responsive.
Have you tried the new native compilation system? I haven't worked on LaTeX documents specifically, but I did see a noticeable improvement in responsiveness across the board and a massive improvement in Elisp-heavy functionality like org-agenda.
I've used it on both Linux and macOS; for whatever reason, my Emacs has always been snappier on my Linux machine, and that's still true with native compilation, but now the macOS experience is also pretty solid.
I've used it on both Linux and macOS; for whatever reason, my Emacs has always been snappier on my Linux machine, and that's still true with native compilation, but now the macOS experience is also pretty solid.
Have you tried profiling? It's working fine with me on both Windows (without WSL) and Linux.
Even without your init file (`emacs -Q`)? Or try profiling (M-x profiler-start, pick cpu, do stuff, then M-x profiler-report) to see if any third party package is involved or not
Emacs is really thriving right now. There are a lot of creative developers contributing to a really nice ecosystem of packages right now, with some things getting pushed upstream.
LSP-mode has really reinvigorated emacs, at least for me. With flycheck and a language server it's magical.
Writing go, it even auto-formats your code and auto-adds imports.
Writing go, it even auto-formats your code and auto-adds imports.
I've struggled a bit with LSP mode (at least for Elixir). I find it hard to use as a full-time IDE replacement, especially since IntelliJ has such good emacs keybindings.
However, as a general text editor, emacs is still great. And I enjoy org-mode.
However, as a general text editor, emacs is still great. And I enjoy org-mode.
Does IntelliJ support Elixir? I am writing Elixir now so would like to know that. However, I haven't encountered any problem while using elixir-ls with eglot (Emacs). For performance, I can recommend enabling native-comp. It's now merged into master which I recompile every month or so, it's pretty stable despite being git HEAD.
I write lots of Elixir at my day job. What’s been tricky for you setting up LSP mode?
For me it's not tricky, even on Spacemacs (where configuring modes is a bit more arcane but once you learn it it's happily easy), it's more like it's laggy. :(
I would recommend checking out the emacs native-comp feature. It may not entirely solve the lag, but in my experience it helps a lot.
Even if you don't run native-comp, use m-x lsp-doctor and do everything else it recommends.
I did this a while back and haven't had many lsp problems since.
I did this a while back and haven't had many lsp problems since.
One thing that isn't working for me is finding all the places in a project where a symbol is used.
How are you finding the performance of LSP?
I dropped Emacs for NeoVim because Emacs would frequently lockup for a second or more due to LSP. NeoVim doesn't have this problem.
I would love to return to Emacs someday.
I dropped Emacs for NeoVim because Emacs would frequently lockup for a second or more due to LSP. NeoVim doesn't have this problem.
I would love to return to Emacs someday.
From 27.1 Emacs could be configured to use a native library (jansson) for json parsing, it helped LSP a lot. And now there is a new native-comp feature, where you can AoT compile elisp bytecode to native code with libgccjit, which improves Emacs performance in general.
Anecdotally, a few months ago I wrote some Flutter on a potato laptop, NeoVim native LSP client + nvim-compe was borderline unusable. The vim-lsc somehow fared much better - albeit still choppy - even though it's written in vimscript. Emacs + eglot is the only combination that was smooth.
Anecdotally, a few months ago I wrote some Flutter on a potato laptop, NeoVim native LSP client + nvim-compe was borderline unusable. The vim-lsc somehow fared much better - albeit still choppy - even though it's written in vimscript. Emacs + eglot is the only combination that was smooth.
I only use some of the more mature ecosystems (C#, Microsoft's Python language server, golang, etc) but I've always found the performance to be good.
I don't experience any performance problems with lsp-mode, it is very snappy and never gets in my way of going from thought->code. In particular, Go's LSP support is excellent and very fast. I've found these days that the LSP perf is up to the LSP implementation, not Emacs.
Interesting. I'm using Rust on a fairly large project. I guess that takes a hefty chunk of processor time to work with, which causes Emacs to lock up and NeoVim not to..
100% this. I learned Emacs in college for LaTeX and R (pre RStudio). I used it off and on for years after college to be a contrarian if I'm being honest.
With LSP and the various client implementations I'm legitimately more productive in Emacs writing Python, Go, or Rust than whatever flavor of the month IDE thingamajig. Magit and Org are the cherry on top of the sundae.
That said I don't push my beliefs on anyone in my team and I try to learn JetBrains products to make pair programming easier for folks that don't use Emacs.
With LSP and the various client implementations I'm legitimately more productive in Emacs writing Python, Go, or Rust than whatever flavor of the month IDE thingamajig. Magit and Org are the cherry on top of the sundae.
That said I don't push my beliefs on anyone in my team and I try to learn JetBrains products to make pair programming easier for folks that don't use Emacs.
Just for what it's worth, `goimports` has done this for many years:
https://pkg.go.dev/golang.org/x/tools/cmd/goimports
It's how Emacs handled inputs before there was lsp-mode, and presumably is easy to link into other editors too (it's just an implementation of gofmt that manages imports). I agree: it's an extremely nice feature to have.
https://pkg.go.dev/golang.org/x/tools/cmd/goimports
It's how Emacs handled inputs before there was lsp-mode, and presumably is easy to link into other editors too (it's just an implementation of gofmt that manages imports). I agree: it's an extremely nice feature to have.
Ah, well, I only picked up go very recently so I have no experience writing go outside of the emacs+lsp environment.
Don't let me sound like I'm talking down lsp-mode, even though I have never gotten it to work reliably (railwaycat, Go, and Rust, and lots of TRAMP). lsp-mode is neat.
I use the railwaycat fork also, and it works fine for me writing go. I don't enjoy rust so I've never tried.
If you're interested, my emacs config is here: https://github.com/nathanvy/dotemacs/blob/master/init.org
If you're interested, my emacs config is here: https://github.com/nathanvy/dotemacs/blob/master/init.org
Before LSP, it was always annoying getting things setup. You want to get serious with a new language, spend a day configuring Emacs first. Or, fix your 3 year old config. Now it all pretty much just works! With native-comp its even better. Plus I'm using lot of modern features that I never did earlier, eg. renaming, automatically remove imports, see the inferred type in minibuffer.
Flycheck still makes it a bit slow. I think, one big missing piece is lack of multiple threads, which often makes few things a bit laggy. For example, if I'm reading a big C++ source code with indentation guides[1], even with native-comp it can lag a bit.
[1] https://github.com/DarthFennec/highlight-indent-guides
Flycheck still makes it a bit slow. I think, one big missing piece is lack of multiple threads, which often makes few things a bit laggy. For example, if I'm reading a big C++ source code with indentation guides[1], even with native-comp it can lag a bit.
[1] https://github.com/DarthFennec/highlight-indent-guides
As a vim user, I'm happy about EMACS popularity and converge increase...
Anything but Electron re-skins is a "right" technological move in my books...
I'm glad emacsconf is still a thing :)
a lot of very rich emacs development has happened in the last few years, both to emacs itself and to extensions. it’s been an absolute pleasure to use and has genuinely increased my productivity tremendously. eg after getting used to magit, the git cli becomes ludicrously cumbersome
Last year EmacsConf was amazing. Looking forward to another great edition.
Same as everyone else, happy to see EmacsConf is here. Hoping to get a talk together this time around.
Rant incoming. Dub it flamey or justified, it's up to you. I am posting it because this is one of my last hopes to make amends with Emacs. I accidentally used it for ~19 years -- my first ever team taught me it and I've never bothered to learn anything much else beyond Eclipse and VS Code.
So how about a more modern take on Emacs that doesn't pull punches? Let's go.
1. Finally use a proper LISP like Common Lisp, SBCL or Racket? (Maybe even Gerbil Scheme, last I checked it it was pretty nice to look at and code in.) While you're at it, make a transpiler from Elisp to the LISP you end up using?
2. Make sure your core editor is mega ultra super fast for a change? It's frankly pitiful to have Emacs lag on a server-grade / workstation CPU with an NVMe SSD when you are trying to pick one of 2000 files in a project. I should not even NOTICE a lag on this machine! I can enumerate ~10,000 files in the Alacritty terminal before I manage to blink and press Ctrl-C, so what does that say about Emacs? (And make ahead-of-time / JIT LISP compilation the default and only option for running LISP code, please!)
3. Drop GUI efforts and just make a full-blown terminal-only version? (This might be achievable with build flags and/or fetching certain packages if I remember correctly.) I mean, the GUI efforts are historically nothing short of heroic but if Emacs is going to lag severely on a retina 5K screen (iMac Pro) then obviously somebody is hard-coding assumptions into some GUI code somewhere. Not a good software design.
4. Use async interfaces to external tools like language servers? It's baffling to have my editor completely locked for 5-10 seconds when I first open a file in a project. I am sure I'll survive without compiler warnings for that period of time.
5. Oh, and can we stop lagging the editor on every scroll because the font has more than 1000 graphemes, please? My Apple IIc computer could handle a file with 1000 records in 2-3 ms (excluding time loading it from the floppy disc, of course). I know it's not the same but come on.
---
Emacs is dated in many ways. But I am not seeing any will for a change. It seems the team is happy with gradual super-careful steps until the end of time.
I mean, that's fine, obviously it's their prerogative and all others can't do anyhing.
But this here is one last cry from me; a cry for some common sense and perspective before I swallow my low-energy levels (pre-diabetes) and lack of time (family man) and sacrifice my not-so-much sleep and me-time and finally learn NeoVim. I am sure it's going to be worth it even if it ruins my health for a few weeks because the people there are actually invested in performance, lightweight operation and ergonomics.
So how about a more modern take on Emacs that doesn't pull punches? Let's go.
1. Finally use a proper LISP like Common Lisp, SBCL or Racket? (Maybe even Gerbil Scheme, last I checked it it was pretty nice to look at and code in.) While you're at it, make a transpiler from Elisp to the LISP you end up using?
2. Make sure your core editor is mega ultra super fast for a change? It's frankly pitiful to have Emacs lag on a server-grade / workstation CPU with an NVMe SSD when you are trying to pick one of 2000 files in a project. I should not even NOTICE a lag on this machine! I can enumerate ~10,000 files in the Alacritty terminal before I manage to blink and press Ctrl-C, so what does that say about Emacs? (And make ahead-of-time / JIT LISP compilation the default and only option for running LISP code, please!)
3. Drop GUI efforts and just make a full-blown terminal-only version? (This might be achievable with build flags and/or fetching certain packages if I remember correctly.) I mean, the GUI efforts are historically nothing short of heroic but if Emacs is going to lag severely on a retina 5K screen (iMac Pro) then obviously somebody is hard-coding assumptions into some GUI code somewhere. Not a good software design.
4. Use async interfaces to external tools like language servers? It's baffling to have my editor completely locked for 5-10 seconds when I first open a file in a project. I am sure I'll survive without compiler warnings for that period of time.
5. Oh, and can we stop lagging the editor on every scroll because the font has more than 1000 graphemes, please? My Apple IIc computer could handle a file with 1000 records in 2-3 ms (excluding time loading it from the floppy disc, of course). I know it's not the same but come on.
---
Emacs is dated in many ways. But I am not seeing any will for a change. It seems the team is happy with gradual super-careful steps until the end of time.
I mean, that's fine, obviously it's their prerogative and all others can't do anyhing.
But this here is one last cry from me; a cry for some common sense and perspective before I swallow my low-energy levels (pre-diabetes) and lack of time (family man) and sacrifice my not-so-much sleep and me-time and finally learn NeoVim. I am sure it's going to be worth it even if it ruins my health for a few weeks because the people there are actually invested in performance, lightweight operation and ergonomics.
I'm curious what OS you are in. Unless I am over a slow tramp connection, it isn't common for me to see any lag in the editor.
And it is amusing that async through a buffer has always been possible. Just far more common for folks to not go that route on round one.
And it is amusing that async through a buffer has always been possible. Just far more common for folks to not go that route on round one.
Not OP, but macOS here on a MacBook Pro less than a year old. Emacs has always tempted me, but a number of commands take roughly 2-5x the time compared to something like vscode.
Every time I get back to trying out emacs again, I find myself wondering why I would bother with the massive time sink to get it customized to be a sub-par equivalent to another tool that works better for me.
Doom emacs comes the closest for pre-configured setups, but even that isn't halfway to the productivity of what I am trying to replace.
What I really wish is sublime had gone with something other than python for plugins, and was more scriptable overall...
Every time I get back to trying out emacs again, I find myself wondering why I would bother with the massive time sink to get it customized to be a sub-par equivalent to another tool that works better for me.
Doom emacs comes the closest for pre-configured setups, but even that isn't halfway to the productivity of what I am trying to replace.
What I really wish is sublime had gone with something other than python for plugins, and was more scriptable overall...
That's why I am 99% likely to move to NeoVim (or LunarVim which steps on it). LuaJIT looks like a very easy script language to learn, with minimal quirks -- at least on the first few looks.
What commands, in particular?
The most distinctive one is when you start typing a chord- it can take up to a good second to populate the command list. Compare this to vscodes command palette which is instant.
I admit that perhaps there is a configurable lag built in (it would make sense to do so) and while there are other examples that I know bother me, this is the one that jumped out straight away. I'd have to dig back in to have more specifics.
I admit that perhaps there is a configurable lag built in (it would make sense to do so) and while there are other examples that I know bother me, this is the one that jumped out straight away. I'd have to dig back in to have more specifics.
I'm not sure what chord menu you mean. :(. I /think/ you are describing "echo-keystrokes", which defaults to one second.
M-x is basically instant for me, though. So, not sure why anything like that would be slow.
M-x is basically instant for me, though. So, not sure why anything like that would be slow.
Not OP, but for me adding or deleting a character in the middle of a paragraph in a latex doc hangs for maybe .5s or more, often. This is a fairly new phenomenon, never happened 2+ years ago.
That sounds broken. :(
Good luck getting it fixed, if you are still trying. A basic profiler-start, type, profiler-stop, profiler-report can probably pay the blame easily.
Good luck getting it fixed, if you are still trying. A basic profiler-start, type, profiler-stop, profiler-report can probably pay the blame easily.
macOS.
Can you give me a hint on how to do the async LSP thing then? I never was actually interested in becoming a master in Emacs. ¯\_(ツ)_/¯
Can you give me a hint on how to do the async LSP thing then? I never was actually interested in becoming a master in Emacs. ¯\_(ツ)_/¯
Apologies, I meant that async had long been doable in emacs. Compilation mode being a clear example of what that could look like.
That said, most of the newest lsp code is built with the idea that calls out to the server are fast enough to just block.
That said, most of the newest lsp code is built with the idea that calls out to the server are fast enough to just block.
Thank you for clarifying, much appreciated. <3
Looks like LSP mode is async [1], but I haven't set it up myself. I mostly use Emacs as an org-mode app.
[1] https://emacs-lsp.github.io/lsp-mode/
[1] https://emacs-lsp.github.io/lsp-mode/
I'm the same. I do still edit all of my code in emacs, but I grew to dislike most auto complete setups years ago. :(
I sometimes fear it hurts my productivity, but I'm not seeing any real boost in the folks that use them.
I sometimes fear it hurts my productivity, but I'm not seeing any real boost in the folks that use them.
Re (3):
There is a terminal-only version, and it's not even new. It should be available without any build flags, though maybe you'll need a launch flag. Try emacs -nw from the terminal if emacs by itself launches a GUI window for you.
There is a terminal-only version, and it's not even new. It should be available without any build flags, though maybe you'll need a launch flag. Try emacs -nw from the terminal if emacs by itself launches a GUI window for you.
Yep, did that a while ago, was very disappointed how much coloring do you lose by doing it, for seemingly no good reason. :(
Could be my config but dude, it's a 99% almost pristine Spacemacs config. You can't get much more vanilla than that.
Could be my config but dude, it's a 99% almost pristine Spacemacs config. You can't get much more vanilla than that.
Yeah, that’s part of using a terminal. Color support is janky and many keystrokes are indistinguishable from another (for example, C-i and TAB, C-[ and ESC, C-S-anything, C-arrow keys, and so forth). You can’t have a terminal emacs without these flaws.
>pristine Spacemacs
>vanilla
What? :O
Spacemacs is like 50k LOC away from vanilla config.
>vanilla
What? :O
Spacemacs is like 50k LOC away from vanilla config.
Ah, I mean vanilla Spacemacs. :D
I also meant I barely changed it, nothing more. Hence why I was baffled that switching to terminal mode lost like half the syntax coloring. :|
I also meant I barely changed it, nothing more. Hence why I was baffled that switching to terminal mode lost like half the syntax coloring. :|
>lost like half the syntax coloring
Spacemacs's default theme works quite well in the terminal. Of course, when you are mapping a theme designed for a colorspace with millions of colors to one with 256 colors, there might some issues, but that is to be expected.
If even trying a different theme is too much of an effort for you, why in God's name are you wasting your time on an editor whose main USP is customizability?
Spacemacs's default theme works quite well in the terminal. Of course, when you are mapping a theme designed for a colorspace with millions of colors to one with 256 colors, there might some issues, but that is to be expected.
If even trying a different theme is too much of an effort for you, why in God's name are you wasting your time on an editor whose main USP is customizability?
Because I had no idea Emacs is about that when I started (loooooong ago, almost 20 years ago) and by the time I found out I was already burned out. Sigh.
But I'll make time to migrate away, seems like it's time.
But I'll make time to migrate away, seems like it's time.
https://develop.spacemacs.org/doc/FAQ.html#why-does-my-color...
Seems like an appropriate FAQ item.
Seems like an appropriate FAQ item.
Well okay, fair enough but it doesn't actually solve the problem. Modern terminals can render basically all colors your DE / display supports so I am not sure why there isn't a check for that and utilize the feature if it's there.
You'll need to make sure that your terminal actually supports the variety of colors that emacs is emitting and that your terminal palette matches your emacs GUI color palette. Emacs can't magically switch your terminal from a 16-color mode to 256-colors, or change the palette.
I guess I have to tinker with the palette. Thought I didn't have to when the terminal supports a lot of colors.
https://i.imgur.com/TFTOj8Z.png
This is with the default spacemacs theme. Can you tell which one is the terminal and which one the GUI?
https://www.gnu.org/software/emacs/manual/html_node/efaq/Col...
Emacs does have the feature you want. Perhaps your setup wasn't supported. Which terminal/os were you on?
This is with the default spacemacs theme. Can you tell which one is the terminal and which one the GUI?
https://www.gnu.org/software/emacs/manual/html_node/efaq/Col...
Emacs does have the feature you want. Perhaps your setup wasn't supported. Which terminal/os were you on?
Ouch.
macOS with iTerm2 and then Alacritty.
Now I am even more confused why it doesn't work well for me.
macOS with iTerm2 and then Alacritty.
Now I am even more confused why it doesn't work well for me.
For your possible inspiration: Emacs in iterm2/tmux with 24-bit color, and a bunch of fancy icon sets mapped into the private use area running LSP mode looking a large Python code base[0].
[0]: https://muppetlabs.com/~mikeh/ttyemacs.png
[0]: https://muppetlabs.com/~mikeh/ttyemacs.png
Oh good lord, how do you get that sort of layout?
(I need to learn how Emacs manages its windows; Mostly I have one Treemacs buffer open on the left, then a single large editor window with Olivetti mode on the right.)
(I need to learn how Emacs manages its windows; Mostly I have one Treemacs buffer open on the left, then a single large editor window with Olivetti mode on the right.)
If you have xterm-mouse-mode set it's pretty easy to size windows with your mouse. I just create the splits with the usual emacs window commands and then move things around with my mouse until I have things just right.
>why it doesn't work well for me
Possible reasons:
1. (macOS + inside terminal) isn't a common workflow for emacs contributors, or perhaps for people with that workflow working with 256 colors isn't an issue
2. people who want that workflow who care about having 24 bit colors didn't bother to file a bug report (did you?)
Bitter pill, but I hope it helps: as a beginner to an ecosystem, if you are going to be opinioniated about having an unusual workflow, you are always going to run into problems. If you are running Emacs locally, just run it in GUI mode, that's what most people do.
Possible reasons:
1. (macOS + inside terminal) isn't a common workflow for emacs contributors, or perhaps for people with that workflow working with 256 colors isn't an issue
2. people who want that workflow who care about having 24 bit colors didn't bother to file a bug report (did you?)
Bitter pill, but I hope it helps: as a beginner to an ecosystem, if you are going to be opinioniated about having an unusual workflow, you are always going to run into problems. If you are running Emacs locally, just run it in GUI mode, that's what most people do.
I do run Emacs in GUI mode and it's embarrassingly slow due to various factors I gradually managed to pinpoint:
1. 5K retina display (other Mac owners seem to share the experience)
2. A font with a lot of graphemes (those without emoji seem to render faster)
3. The synchronous nature of LSP; I still don't get it why LSP can't work asynchronously in Emacs -- it does in VIM.
Hence me asking about terminal mode where it also works rather confusingly to me (I mean the colors).
> (macOS + inside terminal) isn't a common workflow for emacs contributors
As a guy who worked on OSS before -- and wants to do it again -- I am never feeling entitled to other people's work. I just wonder why those scenarios are supported in the first place (if no contributors are interested in making them work well).
> as a beginner to an ecosystem, if you are going to be opinioniated about having an unusual workflow, you are always going to run into problems
Fair enough and I don't think it's a bitter pill at all, I appreciate the feedback. But again, I am wondering why the supposedly first-class option (GUI) is also having problems. :(
> 2. people who want that workflow who care about having 24 bit colors didn't bother to file a bug report (did you?)
I wouldn't even know where to begin. The whole community and ecosystem seem extremely foreign to me and I never even got as far as to find a bug report template (admittedly I didn't try very hard). There's just something... alienating about this community, especially Emacs devs. Maybe I am wrong, I hope I am wrong but, just an accumulated feeling.
In any case, the reason I am getting a bit ticked off is that Emacs is supposedly hugely popular. I'd expect a 5K screen and some richer fonts to not trip it but perhaps you're right that macOS isn't a focus.
1. 5K retina display (other Mac owners seem to share the experience)
2. A font with a lot of graphemes (those without emoji seem to render faster)
3. The synchronous nature of LSP; I still don't get it why LSP can't work asynchronously in Emacs -- it does in VIM.
Hence me asking about terminal mode where it also works rather confusingly to me (I mean the colors).
> (macOS + inside terminal) isn't a common workflow for emacs contributors
As a guy who worked on OSS before -- and wants to do it again -- I am never feeling entitled to other people's work. I just wonder why those scenarios are supported in the first place (if no contributors are interested in making them work well).
> as a beginner to an ecosystem, if you are going to be opinioniated about having an unusual workflow, you are always going to run into problems
Fair enough and I don't think it's a bitter pill at all, I appreciate the feedback. But again, I am wondering why the supposedly first-class option (GUI) is also having problems. :(
> 2. people who want that workflow who care about having 24 bit colors didn't bother to file a bug report (did you?)
I wouldn't even know where to begin. The whole community and ecosystem seem extremely foreign to me and I never even got as far as to find a bug report template (admittedly I didn't try very hard). There's just something... alienating about this community, especially Emacs devs. Maybe I am wrong, I hope I am wrong but, just an accumulated feeling.
In any case, the reason I am getting a bit ticked off is that Emacs is supposedly hugely popular. I'd expect a 5K screen and some richer fonts to not trip it but perhaps you're right that macOS isn't a focus.
>5K retina display
>A font with a lot of graphemes
You might have fun reading the article linked here:
https://news.ycombinator.com/item?id=12830206
>The synchronous nature of LSP; I still don't get it why LSP can't work asynchronously in Emacs
Oh god, that is actually terrible.
> I never even got as far as to find a bug report template
The official way to file a bug report is M-x report-emacs-bug.
>especially Emacs devs
What's that feeling based on?
You might have fun reading the article linked here:
https://news.ycombinator.com/item?id=12830206
>The synchronous nature of LSP; I still don't get it why LSP can't work asynchronously in Emacs
Oh god, that is actually terrible.
> I never even got as far as to find a bug report template
The official way to file a bug report is M-x report-emacs-bug.
>especially Emacs devs
What's that feeling based on?
What is the output of "echo $TERM" and "tput colors"?
It's actually 256 for both. WTF, apparently I didn't setup iTerm2 correctly. Let me get to it...
Actually never mind, those commands don't know anything about true colors (> 256). I think you want to check for $COLORTERM according to https://gist.github.com/XVilka/8346728 ?
Proposal: emacs is now irrelevant. Stabilize it, freeze and kill "future development".
Oh, sorry, emacs 'development' is solely about emacs, rather than being about productivity. Too bad that emacs is more about DECs TECO than reality.
[deleted]
Like everyone, I’m finding that I’m in an increasingly disparate set of tools with diverging interface design choices to get my jobs done. The cognitive dissonance that all these different interfaces presents me with feels like it’s getting out of hand, and is growing non-linearly.
Emacs is a arcane tool, and is dated in so many ways, but I don’t know that I can find another solution that allows me to counter the ever-growing complexity of software productivity solutions that I presented with both in my personal and professional life. I know I’m not alone.
As someone who’s not a developer nor a full-time product person, (actually a doctor that wandered into tech), I often wonder why I can’t choose my own front end, and why am forced to use interfaces that don’t work very well for me. Emacs helps me escape some of that (at the cost of a huge relative learning curve, granted)