Zen room for Vim: Focsuing only on the essential(amix.dk)
amix.dk
Zen room for Vim: Focsuing only on the essential
http://amix.dk/blog/post/19744
9 comments
While I credit HN for accuracy in representing Amir's title, fixing that annoying typo would be a Good Thing.
It is also mistyped in the quoted link on the github's readme page at https://github.com/amix/vim-zenroom, which has another letter inversion:
Pelase read more here zenroom for Vim: Focsuing only on the essential.
I suspect dyslexia is at work here, not simply a typo... :)
Pelase read more here zenroom for Vim: Focsuing only on the essential.
I suspect dyslexia is at work here, not simply a typo... :)
No dyslexia :-), it was simply a copy and paste gone wrong and I wrote that in a hurry.
Reminds me of LiteDFM: https://github.com/bilalq/lite-dfm
I've been using it for a while now, love it.
I've been using it for a while now, love it.
Hey! I'm the author of LiteDFM, and I'm glad to hear you like it.
There are actually quite a few plugins that have sprung up to bring similar functionality to Vim. From what I have seen, there are two main approaches:
* Surrounding your window with hidden scratch windows to introduce "margins" around your working area
* Making use of natural offsetting mechanisms such as hidden line number columns and foldcolumns to offset text from the left.
The former gives proper centering, but typically makes vsplits troublesome. The latter (which is the approach I took), allows for a better out-of-the-box experience with vsplits (at the expense of perfect centering). I often work with a file open with LiteDFM active and the TagBar window open on the right.
The main reason I wrote my own plugin was out of frustration with most existing implementations. They usually didn't play nice with a vimrc that looked any different from the plugin author's. I had conflicts with colorschemes, plugins, etc...
My current workflow is to use LiteDFM when reading/editing code, and to use Goyo.vim (https://github.com/junegunn/goyo.vim) when working with markdown files. It's a plugin that uses the scratch window padding approach, but it's the only one I've tried that doesn't have compatibility issues with other plugins.
I am interested in seeing how ZenRoom works out. I'll give it a try and see.
There are actually quite a few plugins that have sprung up to bring similar functionality to Vim. From what I have seen, there are two main approaches:
* Surrounding your window with hidden scratch windows to introduce "margins" around your working area
* Making use of natural offsetting mechanisms such as hidden line number columns and foldcolumns to offset text from the left.
The former gives proper centering, but typically makes vsplits troublesome. The latter (which is the approach I took), allows for a better out-of-the-box experience with vsplits (at the expense of perfect centering). I often work with a file open with LiteDFM active and the TagBar window open on the right.
The main reason I wrote my own plugin was out of frustration with most existing implementations. They usually didn't play nice with a vimrc that looked any different from the plugin author's. I had conflicts with colorschemes, plugins, etc...
My current workflow is to use LiteDFM when reading/editing code, and to use Goyo.vim (https://github.com/junegunn/goyo.vim) when working with markdown files. It's a plugin that uses the scratch window padding approach, but it's the only one I've tried that doesn't have compatibility issues with other plugins.
I am interested in seeing how ZenRoom works out. I'll give it a try and see.
goyo.vim seems to be the real deal, at least it seems to fix problems I have with vimroom (for example, the centering will be wrong if you update the font).
Still tho' it would be awesome if Vim had better native support for window margins, so you don't have to revert to hacks.
Still tho' it would be awesome if Vim had better native support for window margins, so you don't have to revert to hacks.
Yeah, I was really impressed with the way goyo.vim works. And I absolutely agree about the sad state of hackery we have to go through for such plugins.
A big part of why most such plugins fail is that they don't take into account user settings and the fact that it is their responsibility to "hide" other plugins. If you look through the source of goyo.vim, you'll find tons of lines dedicated to working around other plugins. Similarly, LiteDFM has a good chunk of code dedicated to remembering and restoring previous user settings.
A big part of why most such plugins fail is that they don't take into account user settings and the fact that it is their responsibility to "hide" other plugins. If you look through the source of goyo.vim, you'll find tons of lines dedicated to working around other plugins. Similarly, LiteDFM has a good chunk of code dedicated to remembering and restoring previous user settings.
I am fine with Vim in full screen mode through iTerm - The difference seems to be bigger margins, but I don't see much benefit in this.
my thought exactly, why not just buy a smaller screen and get on with code?
I have just published https://github.com/amix/vim-zenroom2 - - it's based on goyo.vim and seems to work better. Thanks bilalq for the tip :-)
Looks pretty cool! Seems to do a lot more for GUI Vim than terminal Vim right now though. It would be cool to see some cterm color values added to it.
I also love how goyo takes callbacks. It really makes interoperation a lot more elegant.
I also love how goyo takes callbacks. It really makes interoperation a lot more elegant.
The terminal isn't that well supported right now. I only use the terminal version on servers or when editing configs. Not when writing code/documentation.
Would love if someone improved this ;-)
Would love if someone improved this ;-)
I also wrote a very basic one of these as a Vundle: https://github.com/jamestomasino/vim-writeroom
I like to cut noise out from my code, but I've never understood "distraction free" modes in code editors.
If you're trying to be productive, you should be regularly checking the results of your code changes (i.e. watching test results in a terminal or a browser window); full-screen modes like this only seem to make it more jarring when I switch out of them...
If you're trying to be productive, you should be regularly checking the results of your code changes (i.e. watching test results in a terminal or a browser window); full-screen modes like this only seem to make it more jarring when I switch out of them...
The real utility of such modes comes when you're trying to read code. At such moments, you want to get rid of all the things that would normally be of great use. Things like line numbers, status bars, gitgutters, etc...
Aside from reading code, such modes are also great for working with markdown files. With them, you really only care about content.
The forcing fullscreen thing is definitely not for everyone though, I agree. I think such plugins would do well to have fullscreening be a configurable behavior. Even my own distraction-free plugin is guilty of forcing fullscreen onto GUI Vim users (I never really notice, since I myself use terminal vim).
Aside from reading code, such modes are also great for working with markdown files. With them, you really only care about content.
The forcing fullscreen thing is definitely not for everyone though, I agree. I think such plugins would do well to have fullscreening be a configurable behavior. Even my own distraction-free plugin is guilty of forcing fullscreen onto GUI Vim users (I never really notice, since I myself use terminal vim).
I might give this a go, but I've never had great success with distraction-free modes. I tend to work better with as much information as possible - tmux, with vim (multiple tabs) and repl panes, as well as browser open for docs or seeing output if working on a web project. Generally I'll also use something like python-mode and have my code get shoved through a bunch of linters on save.
The ability to toggle quickly between modes can be useful.
I've been doing more writing of late, and find I'm switching terminal clients (from rxvt to either the GNOME or XFCE terminals) for longer edit sessions -- the ability to scale up font sizes is helpful, as is the full-screen zoom of the more recent terminals. Centering text would be icing on the cake.
Switching back to windowed mode is just an F11 key away for when I need to reference notes or style/syntax guides (mostly coding in LaTeX).
I've been doing more writing of late, and find I'm switching terminal clients (from rxvt to either the GNOME or XFCE terminals) for longer edit sessions -- the ability to scale up font sizes is helpful, as is the full-screen zoom of the more recent terminals. Centering text would be icing on the cake.
Switching back to windowed mode is just an F11 key away for when I need to reference notes or style/syntax guides (mostly coding in LaTeX).
Can you use relativenumber with this, which is required for efficient vim use?
I tried 'relativenumber' for a few days. I threw it away as too annoying. Considering the topic here I find it especially amusing that 'rnu' should come up—this is all about focus, and it was the distraction that it was that I hated about 'rnu'.
If you were looking at relative line numbers and typing 8j, you can just as well look at line numbers and type 372gg when you have 'nu' set.
If you were looking at relative line numbers and typing 8j, you can just as well look at line numbers and type 372gg when you have 'nu' set.
The key to rnu is having a toggle bound. Once I had that it never annoyed because 90% of the time I want an absolute number I just jump to it. For the rest of the times I just toggle.
I tried that too. Far too annoying, when you could just use 372gg.
While I agree that it makes things easier, it's not required for efficient vim use. Case in point, it's a relatively new addition to Vim.