xsleft.blogg.se - Writeroom mode

#WRITEROOM MODE WINDOWS#

(Which can happen if the mode is disabled.) That's not really a problem if your text is hard-wrapped, of course, but I find it annoying when using visual-line-mode (which I do most of the time). The advantage of adjusting the margins over disabling the mode altogether is, in my opinion, that the text doesn't suddenly gets refilled, because the width of the text area isn't changed. OTOH writeroom-mode does adjust the margins if the window is split, so you should never end up with too narrow a text area. Note that by default, writeroom-mode also has several global effects and I believe it wouldn't be good to disable those each time a window is split. Would you care to explain a bit what you find so appealing about it? ) I've often wondered about the attraction of darkroom-tentative-mode. IIRC you can configure Writeroom Mode to do the same, but since Darkroom Mode does it right out of the box I switched to that. Writeroom Mode -> Darkroom Mode: The latter has a darkroom-tentative-mode that automatically invokes Darkroom if the frame contains a single window. Emacs' default other-window ( C-x o) -> ace-window.

PHP Mode from 2004 -> The one I co-maintain, heh.Įdit 3: Oh, another one worth mentioning. IIRC you can configure Writeroom Mode to do the same, but since Darkroom Mode does it right out of the box I switched to that.Įdit 2: Shameless self-promotion. Writeroom Mode -> Darkroom Mode: The latter has a darkroom-tentative-mode that automatically invokes Darkroom if the frame contains a single window.Emacs narrowing commands -> recursive-narrow.For Git specifically the counsel commands are quite useful. Magit -> The various counsel-git-* functions: I am by far in the minority here, but I prefer not using Magit and instead using Emacs' standard C-x v keys whenever, since they work with many other version control systems.

#WRITEROOM MODE WINDOWS#

enlarge-window ( C-x ^) -> resize-window: Easier and faster control for resizing windows in a frame.

That said, I think they are both equally fantastic Lispy just fits my personal preferences better.

Paredit -> Lispy: Since I'm a fan of Key Seq/Chord, I prefer Lispy's one-and-two key commands to Paredit's commands involving lots of Ctrl and Meta modifiers by default.

Do I want to really kill them? Or just keep them alive and bury them at the bottom of the buffer list? Or automatically kill all buffers matching certain criteria?

kill-buffer -> kill-or-bury-alive: Lets me control how Emacs kills buffers.

Key Seq prevents this only jc would be recognized as a chord. For example, it will treat jc and cj as the same thing.

However, Key Chord triggers the chords if you press the keys in reverse. Key Chord -> Key Seq: These both allow you to define two-key chords.Helm -> Ivy: Helm has more features but I found myself only using a small subset of them, features which in my opinion Ivy works better for.