I'm looking for tips related to setting up vim for writing. Ideally I
would want:
1) text to wrap at 80 chars (no extra newline, wrap only) assuming
there are 80 cols available to use of course.
2) live word count
3) some kind of periodic auto save.
It would be nice to be able to do a full screen mode where there may
be say 160 columns to place the text in, and instead of displaying the
text to the far left there was a 40 column "margin" either side of the
80 column strip in which you could write (because of point 1).
Am I being too picky?
If anyone can help with this it would be greatly appreciated.
Kind Regards
Richard Fletcher
Vim works great for writing...It's how I write most of my text in
addition to almost all my code :)
> 1) text to wrap at 80 chars (no extra newline, wrap only) assuming
> there are 80 cols available to use of course.
:set wrap linebreak tw=0 wm=0
where wm is set to columns-80 or 0, whichever is
larger...possibly using something like
:let &wm=&columns - 80 > 0 ? &columns - 80 : 0
> 2) live word count
A little more taxing. If you're willing to have it "semi-live",
reporting on a keypress, you can do something like
:nnoremap <f4> :%s/\<\w\+\>//gn<cr>
:inoremap <f4> <c-o>:%s/\<\w\+\>//gn<cr>
which will report the number of matches (where it's matching
words) and the number of lines in your doc. This also holds the
ability to more tightly define what a "word" is, so if "a" isn't
a word because it's too short, you can put min lengths on what
constitutes a "word".
You might be able to work some sort of CursorHold/ICursorHold
event jockeying to update an element of your 'rulerformat'
setting with the results above. Unfortunately, the above seems
to move the cursor to the beginning of the line which might mess
with your head.
> 3) some kind of periodic auto save.
I recommend fairly strongly against auto-saving over your current
document unless you're on a versioning filesystem. Vim does an
auto snapshot in the swapfile for recovery purposes. The
settings are controlled by the 'updatecount' and 'updatetime'
settings, as described in
:help recover.txt
in the section titled "Updating the swapfile" (easiest to just
search for "updatecount" in the document...there's no easy link
to point directly to that section of the helpfile)
There are also some nice VCS plugins that integrate with
RCS/CVS/SVN/whatever that allow you to track your historical work
and compare revisions.
> It would be nice to be able to do a full screen mode where there may
> be say 160 columns to place the text in, and instead of displaying the
> text to the far left there was a 40 column "margin" either side of the
> 80 column strip in which you could write (because of point 1).
You might be able to hack something by jockeying the 'wm',
'foldcolumn' and 'number'/'numberwidth' options.
I've never had this problem as I'm always fighting for screen
real-estate (even at work where I have dual 1280x1024 monitors,
each in portrait mode...my 1024x768 laptops at home are even
tighter or to say nothing of my old 800x600 monitor which usually
just ends up in 80x50 text-mode). I've read an article on the
benefits of removing distractions by full-screening, so I can see
there being a want for it...just not from me :)
> Am I being too picky?
Nah...Vim's marvelously accommodating for whatever your work
habits. You might have to monkey with your settings to get
things the way you want, but at least there are knobs to twiddle.
Are there things I wouldn't do? Clearly, but that's to be
expected when discussing personal preferences...I'd much rather
have an option I don't use and be able to change it from a
default I don't like than to have a chafing choice made for me
that I can't do anything about. :)
-tim
I second that. Most of the Vim defaults are great, the vimrc_example.vim is
even better, but there are still a few settings which I set differently once
and for all in my vimrc after sourcing the vimrc_example. So there are
"chafing" defaults, but I can (almost always) "do something" about them.
Best regards,
Tony.
--
As the poet said, "Only God can make a tree" -- probably because it's
so hard to figure out how to get the bark on.
-- Woody Allen
In addition to the excellent advice already given, you may also want to
remap your cursor keys to move up and down within paragraphs rather than
from paragraph to paragraph.
:noremap <Up> g<Up>
:noremap <Down> g<Down>
:noremap! <Up> <C-O>g<Up>
:noremap! <Down> <C-O>g<Down>
:noremap j gj
:noremap k gk
Or something like that. (I haven't tested.)
>> It would be nice to be able to do a full screen mode where there may
>> be say 160 columns to place the text in, and instead of displaying the
>> text to the far left there was a 40 column "margin" either side of the
>> 80 column strip in which you could write (because of point 1).
Another option for doing this would be to use multiple Vim windows.
:help windows.txt
With some autocommands and so on you could make this work pretty
effectively--two or three windows side-by-side, the larger one for
editing and the smaller one to fill the space, and have them
automatically open, etc.. This could have the added advantage of being
able to make rough notes in the 'margins', too.
Smiles,
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
>>2) live word count
>>
>>
>
>A little more taxing. If you're willing to have it "semi-live",
>reporting on a keypress, you can do something like
>
> :nnoremap <f4> :%s/\<\w\+\>//gn<cr>
> :inoremap <f4> <c-o>:%s/\<\w\+\>//gn<cr>
>
>
g CTRL-g is another option.
Putting the whole thing in the statusline would
sound interesting. But there are problems :
1.
I guess using :s will be to slow.
2.
Using 'g CTRL-g' is nice computation wise
( I suppose theses values are available at any time
in the vimsystem.), but suffers from the necessity to
use a normal command with redir etc., which messes
up insert mode. At least I haven't found a way around it.
So this would be semi-live, excluding insert mode.
-ap
>With some autocommands and so on you could make this work pretty
>effectively--two or three windows side-by-side, the larger one for
>editing and the smaller one to fill the space, and have them
>automatically open, etc.. This could have the added advantage of being
>able to make rough notes in the 'margins', too.
>
>
>
Yes, and then throw a scrollbind in it. That sounds good.
-ap
try
autocmd CursorHold,CursorHoldI * normal g^G
where ^G is obtained by hitting Ctrl-V (or Ctrl-Q if Ctrl-V pastes) followed
by Ctrl-G.
This will display the position in the file (as bytes, words, etc.) whenever
you stop typing for 'updatetime' milliseconds.
Best regards,
Tony.
--
ARTHUR: Old woman!
DENNIS: Man!
ARTHUR: Man. I'm sorry. Old man, What knight live in that castle over there?
DENNIS: I'm thirty-seven.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
The following tip is a bit of a mess, but the advice given at the top is
good (if I do say so myself:) - the script is my adaptation of advice I've
seen here):
http://vim.wikia.com/wiki/VimTip38
John
This has the same problem as using redir and the statusline,
it messes up insert mode.The normal command has an implicit
<ESC> at the end, which resets the cursor if it is on a
'void' column.
-ap
autocmd CursorHold * call feedkeys("g\<c-g>", 'n')
autocmd CursorHoldI * call feedkeys("\<c-o>g\<c-g>", 'n')
When in insert mode, showmode has to be off or cmdheight >= 2.
IMHO it's kind of distracting though and I personally would stick with
typing the g<c-g> combination when I have time to think about
something how many words left to go.
This seems to work well enough :
---------------%<-----------------------
augroup foo
au!
autocmd CursorHoldI * if !search('\%#$','nc') | exec "normal g\<c-g>"
| endif
autocmd CursorHold normal g
augroup END
"or
let s:words=""
func! Words()
if mode() != 'i' || !search('\%#$','nc')
redir => s:words
normal g
redir END
let s:words = matchstr(s:words,';\zs[^;]*Word[^;]*\ze;')
endif
return s:words
endfun
setl stl=%{Words()}
--------------------%<----------------------
-ap
Sorry, I left 2 errors :
>This seems to work well enough :
>
>---------------%<-----------------------
>augroup foo
> au!
> autocmd CursorHoldI * if !search('\%#$','nc') | exec "normal g\<c-g>"
>| endif
> autocmd CursorHold * normal g
>augroup END
>
>"or
>
>let s:words=""
>
>func! Words()
> if mode() != 'i' || !search('\%#$','nc')
> redir => s:words
> silent normal g
I am confused :
When the cursor is on the last char of a line and one enters
insertmode with 'a'. Typing <C-O> in this state moves the
cursor from 'between the last char and eol' to the 'last char'.
I don't recall vim doing that.
-ap
Does the use of <c-\><c-o> improve the situation:
autocmd CursorHoldI * call feedkeys("\<c-\>\<c-o>g\<c-g>", 'n')
But I don't like this anyway and I personally think it promotes bad
and aimless writing behaviour -- unless you're doing some kind of
experimental poetry or participating in some speed-writing contest.
Thanks, I didn't know about this mapping : <c-\><c-o> .
-ap
I admit I have no idea what the OP's situation is, but may I point out
that sometimes one has word limits on articles, or minimum qty of words
needed for a paper, etc.
Regards,
Chip Campbell
> I recommend fairly strongly against auto-saving over your current
> document unless you're on a versioning filesystem. Vim does an
> auto snapshot in the swapfile for recovery purposes. The
> settings are controlled by the 'updatecount' and 'updatetime'
> settings, as described in
The one exception I know is when you use pine & vim over a flaky
ssh connection. It is great to have your mail in the place you want
it when resuming writing the message instead of having to hunt for
a .swp
Unfortunately, it seems there is not way to easily and elegantely
achieve this.
There is a script [1] and a rather blunt FAQ item [2], that seems to
be it :/
Richard
[1] http://vim.sourceforge.net/tips/tip.php?tip_id
[2] http://vimdoc.sf.net/cgi-bin/vimfaq2html3.pl#5.9
While we're on the subject, how do most vim users deal w/ cases where
they want to pretty their text up for, say, a nice print manual? Do
you just do all your text in vim, then port to a word processor and
add water?
Mike
Word-processor? Yecch...
I just do it up directly in html. Do it right, and it should come out
fine in both print and in a browser, but the latter would have hot links
as well. I also add things like definitions and such, so you could
hover the mouse on a term and the def would pop up in a "balloon", I
think they're called.
It might take some manual tweaking to get pagination right, but with
stylesheets, you can define a "page" table, and stick text in there. I
personally *don't* do that, but you can.
From there, there exist apps which convert from/to .pdf files as well.
Not as flexible as .html files, but they're essentially self-contained
in a single file, instead of moving a directory of images, text, and
such, 'though ODF (Open Document Format) is essentially
html-in-a-.zip-file, nice and neat.
Besides, *which* wp would you use? WP? M$W? They're all proprietary
formats, 'though M$ products are notoriously incompatible with even
earlier versions of themselves. Stick with an open format that can be
read by just about anything, I always say. HTML, TeX/LaTeX,
troff/nroff, whatever spins your wheels.
When I want fancy typography (fat titles, drop caps, several fonts, colours,
floating pictures, etc.) I use HTML+CSS. I can edit it in Vim (no word
processor) and see it prettified in any browser. (That's appropriate to the
little publishing I do, which is on the web.) For paper typesetting, IIUC
there are HTML-to-PDF tools.
Best regards,
Tony.
--
Dear Miss Manners:
My home economics teacher says that one must never place one's
elbows on the table. However, I have read that one elbow, in between
courses, is all right. Which is correct?
Gentle Reader:
For the purpose of answering examinations in your home
economics class, your teacher is correct. Catching on to this
principle of education may be of even greater importance to you now
than learning correct current table manners, vital as Miss Manners
believes that is.
Well (plug), the viki plugin[1] along with the deplate converter[2]
are meant to provide a way to write text in a mostly unintrusive
markup and then to convert it to whatever you like. I currently do all
my writing this way. (Unless I have to work with WP-Users or have to
submit in RTF format or similar, then I switch to WP via HTML after
the first draft.)
There are other vim plugins or programs[3] that serve a similar
purpose. And there is LaTeX of course for which quite a few
converters[4] exist, although latex doesn't lend itself well to
conversion. tex4ht is about the only converter I know of that is able
to convert reliably latex + any extra packages. Others rely on
restricting yourself to some subset of latex commands.
[1] http://www.vim.org/scripts/script.php?script_id=861
[2] http://deplate.sourceforge.net/
[3] http://micans.org/zoem/ecosphere.html
[4] http://tug.org/utilities/texconv/textopc.html
I am rather doubtful about HTML-to-PDF. If printed effects are to be
taken care of, I guess TeX/LaTeX or roff is preferred to plain HTML.
There are translators to convert the former to HTML, and HTML support
is standard in the latter.
If people are already familiar with HTML, maybe DocBook is a suitable
solution? However, my feeling is that the tools are not yet mature
enough.
Best regards,
Yongwei
--
Wu Yongwei
URL: http://wyw.dcweb.cn/
And my if you didn't all respond! My flabber is well and truly gasted.
Thanks for all the suggestions. It will take me some time to work
through them all and test them thoroughly.
Hugely useful stuff.
Thanks very much
Regards
Richard
> -----Original Message-----
> From: vim...@googlegroups.com
> [mailto:vim...@googlegroups.com] On Behalf Of Tony Mechelynck
> there are HTML-to-PDF tools.
If you are on Windows, there's
CutPDF(http://www.cutepdf.com/Products/CutePDF/writer.asp). It
essentially becomes a printer that anything you send to it becomes a
PDF.
Mike
Mike
Personally, I copy my LaTeX template and start writing in there. It has a
higher learning curve than others, but it is well worth it. As you are using
vim and not mcedit, I can spare myself listing the benefits of this approach :)
Richard