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.
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...
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.
M-x is basically instant for me, though. So, not sure why anything like that would be slow.
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.
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. ¯\_(ツ)_/¯
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.
I sometimes fear it hurts my productivity, but I'm not seeing any real boost in the folks that use them.
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.
Could be my config but dude, it's a 99% almost pristine Spacemacs config. You can't get much more vanilla than that.
>vanilla
What? :O
Spacemacs is like 50k LOC away from vanilla config.
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. :|
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?
But I'll make time to migrate away, seems like it's time.
Seems like an appropriate FAQ item.
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?
macOS with iTerm2 and then Alacritty.
Now I am even more confused why it doesn't work well for me.
(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.)
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.
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.
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?
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.