6 ms·

My relatively new stance is that sometimes having an Emacs process that doesn't share the state is a feature, not a flaw. Specifically I started using non-daemo

by vifon 3y ago

My relatively new stance is that sometimes having an Emacs process that doesn't share the state is a feature, not a flaw. Specifically I started using non-daemon Emacs processes alongside my main Emacs daemon to compartmentalize my work. Each non-trivial project, or "workspace", gets its own Emacs process, possibly with a persistent state with desktop-save & desktop-change-dir. The newish tab-bar-mode helps with that a lot as I cannot stand using multiple frames on a non-daemon Emacs due to it not always being obvious when I close just a frame and when I close the whole process.

cmrdporcupine 3y ago
Yeah I personally prefer to have the separation of buffer sets between tasks. Especially for something as transient as "write a git commit message" or do an interactive rebase, or write a quick note.
- mbork_pl 3y ago
  A personal preference is a personal preference, ofc, but what exactly are the actual benefits?
  - Scarbutt 3y ago
    While project.el or projectile.el are good sometimes you don't want to see anything else except your current project. A new instance is an easy way to achieve that.
mbork_pl 3y ago
> My relatively new stance is that sometimes having an Emacs process that doesn't share the state is a feature, not a flaw. That is a fair point, though not really fitting my workflow. (Also, my Emacs needs ~20 seconds to start, and I tend to have Emacs uptime of several days or sometimes even weeks.) > I cannot stand using multiple frames on a non-daemon Emacs due to it not always being obvious when I close just a frame and when I close the whole process. This is strange. In my Emacs, C-x 5 0 on the last frame results in "Attempt to delete the sole visible or iconified frame". (And I have `(setq confirm-kill-emacs #'yes-or-no-p)` in my init.el anyway.)
- vifon 3y ago
  Yes, C-x 5 0 is safe, but I often use my window manager's keybinding for closing a window instead. Customizing confirm-kill-emacs sounds like a great idea, I'll consider it, thanks!
hsbauauvhabzb 3y ago
I think your opinion as built is reasonable, but wouldn’t a better mechanism be an internal segregation concept?
- firewolf34 3y ago
  Emacs supports a "projects" concept: https://www.gnu.org/software/emacs/manual/html_node/emacs/Projects.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Pr... This is useful for segregating groups of work related to a set of files but I would be interested if there's anything for arbitrary unsaved buffers in general.

by vifon 3y ago

cmrdporcupine 3y ago

Yeah I personally prefer to have the separation of buffer sets between tasks. Especially for something as transient as "write a git commit message" or do an interactive rebase, or write a quick note.

mbork_pl 3y ago
A personal preference is a personal preference, ofc, but what exactly are the actual benefits?
- Scarbutt 3y ago
  While project.el or projectile.el are good sometimes you don't want to see anything else except your current project. A new instance is an easy way to achieve that.

mbork_pl 3y ago

> My relatively new stance is that sometimes having an Emacs process that doesn't share the state is a feature, not a flaw. That is a fair point, though not really fitting my workflow. (Also, my Emacs needs ~20 seconds to start, and I tend to have Emacs uptime of several days or sometimes even weeks.) > I cannot stand using multiple frames on a non-daemon Emacs due to it not always being obvious when I close just a frame and when I close the whole process. This is strange. In my Emacs, C-x 5 0 on the last frame results in "Attempt to delete the sole visible or iconified frame". (And I have `(setq confirm-kill-emacs #'yes-or-no-p)` in my init.el anyway.)

vifon 3y ago
Yes, C-x 5 0 is safe, but I often use my window manager's keybinding for closing a window instead. Customizing confirm-kill-emacs sounds like a great idea, I'll consider it, thanks!

hsbauauvhabzb 3y ago

I think your opinion as built is reasonable, but wouldn’t a better mechanism be an internal segregation concept?

firewolf34 3y ago
Emacs supports a "projects" concept: https://www.gnu.org/software/emacs/manual/html_node/emacs/Projects.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Pr... This is useful for segregating groups of work related to a set of files but I would be interested if there's anything for arbitrary unsaved buffers in general.