I am running gvim version 7.4 on Windows. Everytime i start gvim, before it loads the window with multiple tabs that i have, i get a popup. First thing i would see is this popup titled "Message" and it contains the following lines, with an "OK" button at bottom. If i click the ok button, gvim starts running without any further problems. I have not been able to find anything in google searches. What is the cause of this popup, and how to eliminate it ?
"Week-3-SCHEMA-DESIGN\hw3-2and3-3\blog.py"
"Week-3-SCHEMA-DESIGN\hw3-2and3-3\blog.py" [unix] 332L,
10531C
"Week-3-SCHEMA-DESIGN\using_update.30ad2dc2bda6.py"
"Week-3-SCHEMA-DESIGN\using_update.30ad2dc2bda6.py" [unix]
110L, 2680C
"Week-3-SCHEMA-DESIGN\hw3-2and3-3\blogPostDAO.py"
"Week-3-SCHEMA-DESIGN\hw3-2and3-3\blogPostDAO.py" [unix]
144L, 4261C
"Week-3-SCHEMA-DESIGN\hw3-2and3-3\blogPostDAO.py.b4vim.orig"
Additions after couple of replies:::
Thanks for the replies, Ingo Karkat and romain. I took a look into the vimlog file. It is 26000 lines long. So i searched for the first filename blog.py which occurs only in the following section of vimlog output file. The corresponding region of vimsession file is also given below.
line 140: badd +113 Week-3-SCHEMA-DESIGN\hw3-2and3-3\blog.py
line 141: badd +0 Week-3-SCHEMA-DESIGN\hw3-2and3-3\blogPostDAO.py.b4vim.orig
line 142: silent! argdel *
Error detected while processing C:\nirmal\vimsession:
line 142:
E480: No match: *
line 143: set lines=43 columns=171
line 144: edit Week-3-SCHEMA-DESIGN\hw3-2and3-3\blog.py
"Week-3-SCHEMA-DESIGN\hw3-2and3-3\blog.py"
"Week-3-SCHEMA-DESIGN\hw3-2and3-3\blog.py" [unix] 332L, 10531C
Since the above output contained an error at line 142, i took a look at my vimsession file. BTW, i have the very last statement of my _vimrc file as source vimsession. Even if i delete my vimsession file (while i have my gvim session open), and recreate it from the open gvim session, i still get the same kind of message box. I took a look at the help pages for argdel which occurs in line 142, causing the error, but unable to figure why this line gets into the vimsession. Following is the relevant section of my vimsession file, which pertains to the very first line that comes up in the popup Message window.
badd +1 Week-3-SCHEMA-DESIGN\hw3-2and3-3\blog.py
badd +98 Week-3-SCHEMA-DESIGN\hw3-2and3-3\blogPostDAO.py.b4vim.orig
badd +3466 \Documents\ and\ Settings\bharathil\vimlog
badd +89 \nsam\vimsession
silent! argdel *
set lines=43 columns=171
edit Week-3-SCHEMA-DESIGN\hw3-2and3-3\blog.py
In my readings, I have not yet finished the User Manual, even half way. My _vimrc file is the one that was suggested as starting setup (by the User Manual). I have only added minimal stuff to it. I don't understand how the argdel gets into the vimsession, since i don't remember messing with that command at all. I suspect once i figure out how to fix the error near blog.py (first file in error list), i will be able to repeat the process, for all the 10 tabs (2 windows in each) and stop this message box from popping up.
This is output from stuff in your ~/.vimrc or plugins that runs before GVIM is fully initialized. The execution of those commands should be delayed via
:autocmd VimEnter * {commands-here}
How to find these commands? You can capture a full log of a Vim session with vim -V20vimlog. After quitting Vim, examine the vimlog log file for suspect commands.
Related
A long file paths is broken up over multiple lines in the Vim quickfix window which then for example does not allow to jump to the error location displayed in the qf.
The file (and the lines around) are diplayed in the quickfix window as (the example is the output from neomakes pdflatex)
|| Enter file name:
|| /long/path/to/file/.../loca
tionOfTexFiles/myTexFile.tex|144 error| Emergency stop.
|| read
to be able to follow to the file line by lnext/cnext I should have
/long/path/to/file/.../locationOfTexFiles/myTexFile.tex|144 error| Emergency stop.
For quickfix files I have the following relevant (in my view) settings which are set to:
setlocal nolinebreak
setlocal nowrap
setlocal textwidth=9999
So I am wondering how I can display the file path in one line within the quickfix window?
On :make, Vim invokes 'makeprg', captures the output, and then parses it according to 'errorformat'. The latter does support multi-line error messages (cp. :help errorformat-multi-line), but that is mostly for what I would call intentional linebreaks, as specified by the compiler. What you suffer from is unintentional linebreaks because of line wrapping (due to overly long paths).
Now, I don't know about "neomakes pdflatex", but it looks like that tool creates the linebreaks, whereas it shouldn't, as Vim is capturing the output, and there's no receiving terminal (or user). Investigating in that direction (or opening an issue at the project's tracker) might be helpful.
The mentioned Vim options ('linebreak', 'wrap', etc.) have nothing to do with it. They apply to normal buffers; the quickfix buffer as such is not modifiable.
Workarounds
A possible workaround might be to :cd first to a directory that is "closer" to the processed files (or even :set autochdir); this might avoid the long paths in the output.
Alternatively, you may "unmangle" the output by adding a sed stage after the compiler:
let &makeprg .= "| sed -e 's/.../...'"
If I'm not mistaken, the issue is on pdflatex side. The || mark is a good indication: you'll have one per output line -- in case filename and/or lines numbers are recognized, they'll be fed in between the bars.
So. This means you'll need a way to fix the path names. It'll be better to do it outside vim. I'm not saying this is trivial. I'm just saying that if you can have a program able to fix pdflatex outputs, you'll just be one pipe away from the solution (plus a correct forwarding of error codes...).
If you prefer to implement it in vim script, this is possible. But you'll experience side-effects. In my BuildToolsWrapper plugin I'm able to post-process compilation output in vim side, but the result is far from being perfect. I'm working on getqflist() result, and parse each line. When I found a line where I want to fix the filename, it's not simply about fixing the filename but also about assigning a valid buffer number to it. See this function where I can replace a filename with another one. The magic happens where lh#buffer#get_nr() is used. Still you'd need to implement a vim script able to merge split filenames.
IOW: my understanding is that vim is not involved. It could be used to fix the issue, but IMO this is not the easier path to undertake.
I have been driven crazy for years with Vim's behavior of throwing away input characters. I start vim like this:
$ vim file.c
and then immediately begin typing commands. However, Vim discards some of those characters, causing the wrong action to take place.
Is there something we can put in the .vimrc to solve this issue?
Vim should be able to change the TTY to raw mode without flushing buffered input.
Update: the issue is more precisely characterized, thanks to the following investigation method. I created a script called delayvim which contains:
#!/bin/sh
sleep 2.0
vim "$#"
Now during this two second pause I can type something like iabc<ESC> and then when Vim comes up, everything is cool: the command is processed, abc is inserted and Vim pops back into command mode, with the cursor backed up over the c. Thus, it is not simply flushing the TTY input buffer.
However, if I keep typing during this delay, for instance iabcdefghijk..., it will sometimes lose a letter or two of the alphabet that is typed right around the time when the sleep terminates and the editor launches. For instance, here is the result of one trial I just performed:
abcdefghilmn_
~
~
Where are jk, oops? I am sure I typed them. I didn't type very fast; my cadence was around 4-5 strokes per second, yet two consecutive events disappeared.
Basically, it might be trying to interrogate the terminal, and in the process discarding the input that is mixed up in the response. Or it could be a combination of reading some of the prior input, then flushing the input buffer and losing the rest.
2 points that might help:
1) are you being sure to hit i first, to enter input mode, so that all characters you type afterward should go ahead and be seen in your buffer (on the screen?). Otherwise the letters you type will be processed as commands, which will often do nothing, especially if you're starting an empty file.
Note that a and o are other common commands for telling vim that you are about to begin inserting text starting with the next keystroke.
2) In case the reason on your system has to do with speed, you can look for options to change what happens at startup. For example, if you put this in your .vimrc file
autocmd VimEnter * :sleep 5
Then after processing other startup files, vim or gvim will literally do nothing for 5 seconds before showing your file on the screen. On my system, I was able to type iabcdef during those 5 seconds and when the time was up, I did see abcdef entered into my text file.
If your file was not empty, beware, as (depending on your settings) your vim installation might be kindly returning you to the last place you were editing inside the file, and you will have inserted the text there, instead of at the start.
If this doesn't work, you could try to find other things vim can do (on the web, or using :help from within vim) and program it using autocmd to happen at startup to see if it helps.
I am trying to quantify my vim action by logging timestamp when saving(:w) a file.
Is it possible to know whether the file had really been edited since the last saving?
for example, I saved the file by :w, then, did nothing and just type :w to save it again, is it possible to judge that the file wasn't actually modified?
You can check the value of the 'modified' option:
if &modified
" do something if the buffer is modified
else
" do something else if it is not
endif
Vim displays a '[+]' next to the file name when the file has been modified. However it displays it even if there is no diff between the file on disk and your buffer (for example if you add the letter 'a' then remove it it will consider that the file has been edited).
press :file and if changes have been made [Modified] will be displayed after your file name.
If you have set laststatus to 2 in Vim, it shows you a status line at the bottom of the window which has a [+] indicator next to the filename when the file has been modified since it was last written.
Relevant help pages: laststatus, statusline
Before reading your answer, I thought it was about knowing if the file had been updated from another vim instance / editor before saving it!
If so, vim usally tell me when I want to save it :
WARNING : the file has been updated since vim read it !
Do you want to write it anyway (y/n)?
If it's only about knowing if you change anything since last time, as explained before, Vim display a [+] after your filename.
I used to work with netbeans and it always put an asterisk and changed the tab color when the file had changed since last save. Is there any way to make vim do something similar, that is, remind me that I haven't saved the file?
I know that there is a way to have it save automatically once in a while, but I don't want to do that.
You can use the m flag in the 'statusline' option to add a [+] if file is modified. Note that in order to see the statusline, you'll need to set 'laststatus' to be greater than 0 (1-Only shows status line if there are two or more windows, 2-Always).
If you're using a GUI-version, such as MacVim, you may prefer to set 'titlestring', which uses the same syntax but will alter the name of the window in your window-manager.
Example:
:set laststatus=2
:set statusline=[%n]\ %<%f%h%m
This will display:
[: literal
%n: buffer number
]: literal
\<Space>: a space
%<: Truncate the field at the beginning if too long
%f: Path to the file in the buffer, as typed or relative to current
directory.
%h: Help buffer flag, text is "[help]".
%m: Modified flag, text is "[+]"; "[-]" if 'modifiable' is off.
For more information see:
:help status-line
Call :ls and you will see a + before unsaved buffers
If the terminal displays its title somewhere, it's possible to use
:set title
to display whether the file is modified: a + is displayed after the file name if it's modified.
However, a file can have + at the end of its file name. For most files this should work fine.
Source: https://stackoverflow.com/a/13244715/5267751
Pressing Ctrl+g (or equivalently :f) in normal mode will show the file status, which indicates whether the file is modified.
The status looks like this
"file_name" 100 lines --20%--
if the file is not modified, or
"file_name" [Modified] 100 lines --20%--
if the file is modified.
For more info see :help ^g.
I have a file where I store snippets of vim commands. When I need a snippet, I yank it and then execute it with #". The snippets are stored as a script, one line per command, like this:
:s/foo/bar/g
:echo "hello"
:s/1/2/g
Edit: I removed normal mode commands from the example, as they were not part of the problem.
Now this procedure doesn't work anymore: when executing the snippet, it just stops at the first line as if waiting for a newline.
Is there an option somewhere affecting how # is executed? I'm pretty sure it was working some time ago...
Substituting the newline with a ^M character works but makes the file more difficult to handle.
Additional information:
Here's another symptom: when I yank a snippet, if I execute it with #" it stops at the first line as I just explained. But if I execute it with :# it works. But the help file doesn't seem to imply any difference in how the two commands treat the register's content...
I don't think the problem is ^M vs. ^J. Vim macros will treat either one as a valid end-of-line character for recorded macros. I think the problem is extra newlines.
In your example, there's at least one spurious newline after 2j, and unless you're particularly careful when copying the snippet, there's probably another one after 10k as well. These extra newlines are like pressing <Enter> in Normal mode -- they move the cursor down one line.
Here's what I think you want the snippet to look like:
:s/foo/bar/g
2j:s/1/2/g
10k
(Even that's a little misleading -- you'd still have to be careful not to copy the newline after the 10k.)
Why do these extra newlines make such a big difference? Well, for one thing, they cause you to be at least one line away from where you expect to be, which throws off anything you want to do on a particular line (like execute the :s// command).
More importantly, however -- and this is what I think is happening in your example -- is that Vim stops macro playback if the macro attempts to use <Enter> on the last line of a buffer. (I'm guessing Vim considers it an error, and any error causes a macro to stop running.)
Here's an example. Suppose you've got this snippet stored in register x:
4j
:echo "Done"
(Notice the newline after 4j.)
Furthermore, suppose you have the following five lines (and only these five lines) in a buffer:
line 1
line 2
line 3
line 4
line 5
If you now press #x on line 1, the :echo "Done" never executes. Vim moves the cursor down 4 lines to line 5, then attempts to move down one more line because of the extra newline, but it can't. The macro stops executing at that point, before the :echo command gets a chance to run.
However, it works if you change the x register to this:
4j:echo "Done"
So to return to your original example, I'll bet what's happening is that the extra newline after 2j is attempting to move your cursor somewhere it can't go, and that causes the macro to stop. The bottom line of the screen contains the last command executed (:s/foo/bar/g), which makes it look like Vim is waiting for you to press Return.
Finally, I'd strongly recommend using another method to store and execute Vim command sequences. The technique you're using is tolerable for simple cases, but it's fragile and doesn't scale well. Vim has a full scripting language that includes functions and custom commands, and it can be used to do all the things you're doing now, but in a much more robust fashion. Vim scripting is a big topic, but I'd start here:
:help script
Be sure to read about the :normal command, which lets you execute Normal-mode commands (like 2j and 10k) within scripts.
Good luck!
I finally found the culprit. Somehow I had a command mapping on <C-J> in my .vimrc file. When read with the default cpoptions, this turned into a mapping on <NL>.
How I found out: I noticed that when starting vim with -u ~/.vimrc, it would indeed execute yanked snippets. I generated a session file with and without that commandline option and compared them. This way I found out that a different set of cpoptions where used to read the same .vimrc file, so that in one case the mapping was indeed on <C-J>, in the other it was converted into a mapping on <NL>!
If someone has a similar problem, I suggest to look carefully at the currently set command mappings, with :cmap.