uzywalem dlugo Emacsa, ale mnie wkurzył z kilkoma rzeczami.

Od około tygodnia używam ViMa.
Kilka refleksji, takich początkowych:

1. ViM script jest znacznie prostszy od Emacs Lispa, ale przez to również trochę bardziej ograniczony
2. ViM wydaje mi się jednak prostszy od Emacsa, ogólnie jako całość
3. Po tygodniu niregularnej nauki *.vim uczę się pisać funkcje, a mój vimrc ma już 225 linijek kodu, a ledwo zacząłem w się w to bawić, mógłbym już sporo pluginów całkowicie zmienić
4. najprawdopodobniej przerzucę się na Emacsa, ale za jakieś 2-3 lata, muszę się lepiej wyrobić w programowaniu (Lisp jest trudny), narazie zostaję przy ViM
5. Wiele rzeczy w ViM jest od razu dostępnych, nie musialem grzebać tak głęboko w Googlach jak w przypadku Emacsa
6. Nie ma się co oszukiwać, Emacs momentami jest znacznie potęzniejszym edytorem. np:
http://www.emacswiki.org/emacs/DiredMode
http://www.emacswiki.org/emacs/BookMarks
http://www.emacswiki.org/emacs/BookmarkPlus#Bookmark%2b –>tego mi najbardziej brakuje w VIM i chyba napiszę skrypt który to poprawi, bo aktualnie jest tragedia

w VIM znalazłem rzeczy których nie znalazłem w Emacs. Emacs ma strasznie rozbudowanych kilka pluginów, których nie ma ViM.
Ja zostaję narazie przy ViM, bo Emacs jest zbyt trudny, ale za kilka lat jak się wyrobie z funkcjami i logiką informatyczną to raczej wrócę do Lispa.

Hey Luke,

This is self-promotional, but my big scripting project for vim has just reached a mostly mature state. It is a pannable, zoomable ‘infinite plane’ for organizing massive amounts prose called “textabyss”. Check it out at:

https://github.com/q335r49/textabyss

Thanks!

Leon

[…] Using Vim for writing Prose […]

I find it easier to keep paragraphs on one line and use screen wrapping. This works for more use cases, such as blog posts, blog comments, and for reading into a word processor document. These environments treat hard returns as either line breaks or paragraph breaks. Unfortunately, to distinguish paragraphs within plain text editors, you must have two hard returns. Vim makes dealing with this very easy: :%s/\n\n/\n/ replaces all doubled new lines with one. Run this command just before copying into a word processor and paragraphs will have no extra breaks between them.

Vim has the gj and gk commands for navigating by screen lines, and these can be mapped to j and k respectively with: noremap j gj and noremap k gk. They are just as effective with screen wrapping turned off. Navigating by paragraph still works with { and } and by sentence with ( and ). Deleting, changing, and yanking iw (inner word), is (inner sentence), and ip (inner paragraph) or their aw, as, and ap (around) counterparts also still work as expected.

It may not be as pretty as some distraction-free environments, but more than makes up for it with superior editing features.

I’ve been trying a lot of things to have Vim center prose when I write in fullscreen. Using foldcolumn is absolutely brilliant. I’ve set it to 12 because you can’t go higher (and it happens to look nice), and then I’ve subtracted that twice from 116, which is my total number of columns when in fullscreen, which gave me a textwidth of 92. Put simply I now have 12+92+12 when in fullscreen. And I now finally have a distraction-free code/prose editor with all Vim shortcuts (and not the incomplete emulation you get in Sublime Text)! Thank you so much! And the rest of the article was very helpful, too!

@ Luke Maciak:
Everybody finds the best way for her, but Leo Tolstoy would never use the “one-sentence-per-vim-line” idiom.
Just kidding.

@ J. Alan Atherton:

Wow, the one sentence per line is actually a very good tip. d d p to swap sentences is indeed quicker and easier to remember than d a s ) p. TIL :)

@ Alexei Matyushkin:

Very good points. That said “sentences” are valid vim text objects and it recognizes them and can operate on them in hard wrapped mode just as easily as in soft wrapped. The semantics of, say deleting current sentence are the same: d i s (delete inner sentence). It doesn’t stop at the end of the line but continues till a full stop followed by a space is encountered in text.

But yeah, I can see what you are saying about lines of code being logical entities whereas lines in “prose” are typically jumbles of incomplete sentence fragments. I think Alan’s suggestion of using soft wrap and keeping one sentence per vim line is a good compromise between the two “problematic” extremes. :)

The main problem with writing prose (besides the talent for,) is a typography. One has two options for making the result perfect: either to remember all the rules and apply them as she’s typing or to use the proper formatting tool which is none but TeX.
Hard wrap brings a lot of problems during hardly stropping the text. The ability of dd-ing (and operating in general) lines of code looks very important to me because the line of code is an entity. The hard-wrapped piece of plain text is not, though. What’s to force me to want to cut several random words, having actually neither a clear begin nor an end? Who the hell needs to delete a part of the sentense above, starting right after a definite article and containing 80-or-a-bit-less symbols?
Writing a prose is likely a process which let’s me to concentrate on it for a long time; I do not need to switch a context often, so I may to give an editor window it’s own personal desktop. That’s why I personally prefer to resize a window so that it has ≈80-letters width and use the old good not-wrapping environment in my Vim.

As a graduate student, I use LaTeX for writing “prose”. To separate paragraphs, you must have a blank line between them, and it doesn’t matter how you organize your sentences. Because I also use vim, I just put each sentence on its own line. This makes it dead simple to change the order of sentences in a paragraph.