Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A vision of a multi-threaded Emacs

coredumped.dev

Post reply on HN
Print view View original

131–136 of 136 posts

Re: A vision of a multi-threaded Emacs

#131

Post by ParetoOptimal »

light_hue_1 wrote: post #54
funcDropShadow wrote: post #44

Earlier quoted context omitted.

> But languages are absolutely slow or fast! There are fast Schemes and Lisps and there are slow ones. You are contradicting yourself. If languages instead of implementations were slow or fast, then their would not be fast and slow Schemes and Lisps. Scheme would be either slow or fast. Actually, I would go even further than saying only implementations are slow or fast, they are slow or fast for certain use cases. >…

> You are contradicting yourself. If languages instead of implementations were slow or fast, then their would not be fast and slow Schemes and Lisps. Scheme would be either slow or fast. You are unfamiliar with the huge differences between what counts as a "Scheme" or a "Lisp". Neither "Scheme" or "Lisp" are a language, they're language families. The difference between Schemes is larger than the difference between sa…

> GHC 7, from 10 years ago, is marginally slower than GHC 9.4 if you run the same large app in both.

I don't have access to $someLargeApp you mrntion, but I find this hard to believe.

Re: A vision of a multi-threaded Emacs

#132

Post by gjadi »

Kaze404 wrote: post #123
appletrotter wrote: post #80

Earlier quoted context omitted.

As a third party in this conversation, and someone who uses emacs daily - I/O hangs seem to be something that is a pretty frequent issue for users. My emacs likes to crash sometimes, usually a few times a week. Hopefully I’ll be able to take some time to bisect my config and see what’s going on. Looks like a memory leak.

To add to this, my Emacs never crashes but at least once a week I'll run an innocent command (sometimes just opening magit) and it will become unresponsive indefinitely, with the only way of closing it being sending a kill command from the terminal.

If your emacs freezes, you can often recover it by sending the USR2 signal. When it receives this signal, Emacs will drop in the debugger.

Re: A vision of a multi-threaded Emacs

#133

Post by [deleted] »

alex_smart wrote: post #129
complex1314 wrote: post #41

Earlier quoted context omitted.

Use emacsclient and have a emacs server running at all times. Super fast startup times, you can even use emacsclient -nw (or make an alias 'e' for that) in the terminal for fast edits with instantaneous startup. You could also make a script that starts emacs as a client only if a server already is running #!/bin/sh if [ "$#" -eq 0 ] then echo "Starting new Emacs process ..." >&2 nohup emacs > /dev/null 2>&1 & elif em…

You don't need to do all that. Just run emacsclient with `emacsclient -a ""`. From the man page: -a, --alternate-editor=COMMAND If the Emacs server is not running, run the specified shell command instead. This can also be specified via the ALTERNATE_EDITOR environment variable. If the value of ALTERNATE_EDITOR is the empty string, run "emacs --daemon" to start Emacs in daemon mode, and try to connect to it.

[deleted]

Re: A vision of a multi-threaded Emacs

#134

Post by complex1314 »

alex_smart wrote: post #129
complex1314 wrote: post #41

Earlier quoted context omitted.

Use emacsclient and have a emacs server running at all times. Super fast startup times, you can even use emacsclient -nw (or make an alias 'e' for that) in the terminal for fast edits with instantaneous startup. You could also make a script that starts emacs as a client only if a server already is running #!/bin/sh if [ "$#" -eq 0 ] then echo "Starting new Emacs process ..." >&2 nohup emacs > /dev/null 2>&1 & elif em…

You don't need to do all that. Just run emacsclient with `emacsclient -a ""`. From the man page: -a, --alternate-editor=COMMAND If the Emacs server is not running, run the specified shell command instead. This can also be specified via the ALTERNATE_EDITOR environment variable. If the value of ALTERNATE_EDITOR is the empty string, run "emacs --daemon" to start Emacs in daemon mode, and try to connect to it.

Didn't know that, thanks!

Re: A vision of a multi-threaded Emacs

#135

Post by OrderlyTiamat »

anotherevan wrote: post #84
OrderlyTiamat wrote: post #68

Earlier quoted context omitted.

I've had that fixed in the past by simply adding an ampersand to org's compile command. This does make it run in the background but makes it ring the bell a number of times. Now when I'm editing and want to see the compiled pdf side by side I just start a bash while loop that recompiles continually with latexmk.

> I just start a bash while loop that recompiles continually with latexmk. There's the -pvc option in latexmk that[1], "continuously check all input files for changes and re-compile the whole thing if needed and always display the result," depending on if your PDF viewer will refresh. That may obviate the need for a bash while loop. [1] https://mg.readthedocs.io/latexmk.html

Neat, thanks!

Re: A vision of a multi-threaded Emacs

#136

Post by samus »

__d wrote: post #122
convolvatron wrote: post #8

Earlier quoted context omitted.

one really nasty conflating issue is that emacs uses a mess of globals. partially because of the domain but largely because of dynamic binding and the lack of namespaces. emacs really needs to be hoisted onto another language and runtime. everyone says this but no one can really conceive of doing this and rewriting or at least refactoring all the elisp extensions. I guess guile emacs is still alive? I should really t…

I wonder if it would be possible to automatically rewrite the elisp code to whatever new runtime was chosen? Assuming the new language is still more-or-less a Lisp ... maybe?

The issue is always the parts where the two language semantics differ too much. And then, you usually have too much legacy code that would be impacted by changes in those areas. That's the hard part.

You lost when that code lies beyond some organizational boundary, e.g., a separate project that has is too big in its own right to refactor in one go, or where the maintainers have sufficient clout to resist such a change. Such a transformation would effectively entail a fork of that project.

Post reply on HN