Re: Possible problem with sudden shortening of very large files by an external process
Bram Moolenaar wrote:
Gary Bickford wrote:
I often misuse vim to view log files while debugging batch jobs. It is
very handy for moving around in the file, viewing the colorized content
and searching for relevant text. These log files can be from several
thousand to millions of lines. Vim does a remarkably good job of
handling these files. However, sometimes it has a problem when the
batch job is re-run while I am viewing the file in vim, and the log file
is replaced by a much shorter one.
When vim tries to reload the file, sometimes I get a very long series of
red warning messages - I can't repeat the event just now, so can't
provide the content of the warning, but I think it has to do with
missing lines.
This succession of warnings can be inconvenient when there are several
million to report, or even a few thousand! And very occasionally vim
hangs (apparently), or just gives up the ghost and dies. I think
problems are more likely when the 'present location' is far down the
file.
Considering the abuse I am giving vim this is within the range of
acceptable behavior, but I thought it was worth mentioning as an issue
anyway. From the behavior, I speculate that vim has found the present
line to be after the end of file, is trying to move the line pointer
upwards one line at a time, and is finding no data there each time.
It would help a lot to know what the text of that error message is.
If it is ml_get: cannot find line {N} then the cause might be hard to
find. A stack trace would be helpful then.
That is the error message - E315 ml_get: cannot find line (N). I note
that if I type 'q', when it waits for me to hit enter, I don't have to
hit Enter after each line, it just spews this error message with
increasing line numbers until it gets to the end or dies with a segfault.
I am not at work so I can't run any tests today - sorry for the slow
response cycle. Since I don't write C, I haven't had to deal with
segfaults for a long time. To get a stack trace, do I need to run vim
under gdb?
--
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
Possible problem with sudden shortening of very large files by an external process
I often misuse vim to view log files while debugging batch jobs. It is very handy for moving around in the file, viewing the colorized content and searching for relevant text. These log files can be from several thousand to millions of lines. Vim does a remarkably good job of handling these files. However, sometimes it has a problem when the batch job is re-run while I am viewing the file in vim, and the log file is replaced by a much shorter one. When vim tries to reload the file, sometimes I get a very long series of red warning messages - I can't repeat the event just now, so can't provide the content of the warning, but I think it has to do with missing lines. This succession of warnings can be inconvenient when there are several million to report, or even a few thousand! And very occasionally vim hangs (apparently), or just gives up the ghost and dies. I think problems are more likely when the 'present location' is far down the file. Considering the abuse I am giving vim this is within the range of acceptable behavior, but I thought it was worth mentioning as an issue anyway. From the behavior, I speculate that vim has found the present line to be after the end of file, is trying to move the line pointer upwards one line at a time, and is finding no data there each time. -- He that breaks a thing to find out what it is has left the path of wisdom.-- J.R.R. Tolkien - But where does that leave particle physics? -- 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
Re: Vim plugin to maintain journal?
Another possible suggestion - use the docuwiki format, and save the file as .wiki. It's a simple format to use, and can be easily pushed onto the web using docuwiki. AFAI can tell the VIM wiki plugin doesn't have folding support however. -- You received this message from the vim_use maillist. For more information, visit http://www.vim.org/maillist.php
Re: Session or file activity transcript replay?
There are some good ideas here, I'll check them out. I wonder though - the recovery file exists already (if the vim session has gone away). Does it contain the change history, or just the final state? If it contains the change history, then it seems that there might be a way to use that in the manner I'm thinking of. -- You received this message from the vim_use maillist. For more information, visit http://www.vim.org/maillist.php
Re: Session or file activity transcript replay?
I should mention, Im going to try Christian's plug-in. :) On Jan 19, 6:21 pm, Christian Brabandt cbli...@256bit.org wrote: On Mo, 18 Jan 2010, Christian Brabandt wrote: The amusing part was that you could watch as the editor replayed your actions at an accelerated speed. I don't recall that the speed was adjustable, but that would be useful. […] While we are at that part, I started to read into the undo-tree feature of vim a little bit more carefully. This is really an awesome feature, unfortunately it is a little bit awkward to use. Therefore I created the histwin.vim Plugin (http://www.vim.org/scripts/script.php?script_id=2932) which let's you browse your undo-branches, tag states and replay all your changes (this was just for fun ;)) I hope, this can ease the use of the undo-branches feature (which I did know before, but rarely used and I think this plugin is really easy for browsing the undo-tree). regards, Christian -- hundred-and-one symptoms of being an internet addict: 81. At social functions you introduce your husband as my domain server. -- You received this message from the vim_use maillist. For more information, visit http://www.vim.org/maillist.php
Session or file activity transcript replay?
Has anyone built a session transcript plug-in for vim? I am aware of the macro capability, and the kill-ring plug in, and some other suggestions but I haven't seen anything quite like this: Back in the day, on the Perq workstation, the text editor had a very handy feature. It retained a transcript file for every change made to a file, from the time it was created. The transcript could be deleted, and then from then on it would retain the changes made since that point. Among other things, this transcript was both useful and amusing. More than once, the system died while I was in the middle of work. I was able to run the transcript back to the point where the last change was written (block store), which in one case gave me back 36 hours worth of work. (Yes, I forgot to save backups for 36 hours straight...) In other cases, when one either screwed up on a big change and wanted to go back to just before the change, you could replay the transcript to just before the big change, step forward and back one change at a time, then stop the replay and continue on a new editing path. The amusing part was that you could watch as the editor replayed your actions at an accelerated speed. I don't recall that the speed was adjustable, but that would be useful. It seems that, since Vim already keeps a recovery file for when a session is killed one way or another, all or nearly all the mechanisms required for this kind of transcript replay would not be a huge project. Am I wrong? Would this be doable as a plug-in? -- You received this message from the vim_use maillist. For more information, visit http://www.vim.org/maillist.php
