> My first thought would be whether the media he is writing to is beginning to
> die.
> The user isn't using some kind of removable media, which is being removed
> too early?
Bad or portable media is not the culpret. My friend logs into a powerful
networked computer system at Univesity of New York at Buffalo, where he is a
prefessor Emeritus. Vim is run on the Buffalo computers. True, he still uses
dos, an ancient IBM PC monitor, and a dialup modem to log in. Buffalo sets his
term to vt102, and keystrokes seem to be interpreted correctly by the Buffalo
computer.
> It may be something for which you'd need to read the source, but before we
> get to that.
There is a syntax highlight file, viminfo.vim which highlights lines in error.
It does this by simply checking for all types of lines that are OK. There is
no checking for which lines should go where, nor any coordination with the
actual error messages in the code.
> the user may be prepared to add f0 to the viminfo option
> and suppress saving of filenames, but that's an annoying work around.
Unfortunately, the only thing, so far, my blind friend likes about viminfo, it
the ability to save persistent (lowercase) marks in files, between sessions.
> also encoding issues I think would only come up if the user is editing
> something like raw Braille.
Encoding is not the problem. term is set to utf-8, and he edits only pure
ascii text, containing the old-style troff, ascii markup codes (e.g., .ce,
\fB etc.).
> What I saw in the docs says it attempts to merge the file,
The docs are not specific, but: When vim writes to viminfo it seems to add new
info. if it is not there (e.g., marks for a new filename, jumplist for a new
filename), and overwrite mark information for the A-Z and a-z marks, if the
user has changed these marks. It does not update any other old information.
For instance, the jumplist lines for a file previously edited, stay there
forever - until .viminfo is deleted. If not changed, alphbetic marks for old
files also stay forever.
I know of no vim aware scripts that update viminfo, when a file is renamed,
deleted or moved.
It is not clear if vim counts `+' lines of the jumplist towards the limits set
for marks. Too bad if it does, since there are often hundreds of jump lines!
> you mean that there are more errors despite your corrections.
Yes, I manually correct the viminfo file, and within days or hours another
format error occurs, within a line of viminfo. My friend also reports that
line numbers for named marks are not correctly set, as he edits. Somehow, vim
is writing bad lines to viminfo, when my friend quits vim.
One possibility: my friend has the (bad) habit of using unix to switch between
edited files. That is, he runs many instances of vim, suspending one with
Ctrl-Z to leave one file, and using the shell's jobs and fg command to enter
another file, by bring a suspended vim back to life in the foreground.
Off hand I do not see how this would confuse viminfo writes, although running
many instances like these in a console is asking for trouble.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
No comments:
Post a Comment