[bug report] C syntax broken with anonymous arrays
Hi all,
After reading
http://www.run.montefiore.ulg.ac.be/~martin/resources/kung-f00.html
I now use anonymous arrays in C. This is an exemple of use:
result = ldap_search_s( ld
, dc=u-strasbg,dc=fr
, LDAP_SCOPE_ONELEVEL
, NULL
, (char *[]){ objectClass,dc, NULL }
, 0
, msg
);
Unfortunatly, the { of the array and all the following { and } are
marked as cErrInParen and i'm not skilled enougth to fix the problem. So
i'm sorry to just report it.
Regards,
mc
Re: [bug report] C syntax broken with anonymous arrays
Marc Chantreux wrote:
After reading
http://www.run.montefiore.ulg.ac.be/~martin/resources/kung-f00.html
I now use anonymous arrays in C. This is an exemple of use:
result = ldap_search_s( ld
, dc=u-strasbg,dc=fr
, LDAP_SCOPE_ONELEVEL
, NULL
, (char *[]){ objectClass,dc, NULL }
, 0
, msg
);
Unfortunatly, the { of the array and all the following { and } are
marked as cErrInParen and i'm not skilled enougth to fix the problem. So
i'm sorry to just report it.
The normal C syntax uses highlighting of { and } inside () to indicate a
missing ). There is no other way to show this common mistake.
If you really use { and } inside () you can disable the highlighting
with this line in your vimrc file:
let c_no_curly_error = 1
--
hundred-and-one symptoms of being an internet addict:
142. You dream about creating the world's greatest web site.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
doc bug: 'browsedir'
In
*options.txt* For Vim version 7.1. Last change: 2007 May 11
under 'browsedir', at line 1151, there is:
{not in Vi} {only for Motif and Win32 GUI}
Actually, this option is functional in my GTK2/Gnome GUI.
Best regards,
Tony.
--
The day after tomorrow is the third day of the rest of your life.
Re: BUG: wrong recognition of words in Vim7.1b on Windows
Dnia poniedziałek 21 maj 2007, Bram Moolenaar napisał: That @ means that Vim uses the library function isalpha(). Apparently your environment is not setup properly for isalpha() to work with your encoding cp1250. Thus that is a problem with your library/system/environment. Well, I installed Vim on three MS-Windows XP machines coming from different vendors and everywhere was that bug. Looks like classic example of: 1. MS-Windows is always right 2. If MS-Windows is wrong see 1. m. -- The world really isn't any worse. It's just that the news coverage is so much better.
Bug in completion
Hi All, I see the following bug: 1. Open Vim, and vertically split into two windows. 2. File name complete something with very long file names (longer than the width of the window you're typing into). The screen is hodge podge. There are uncleared pieces of the completion menu left on the screen (on top of the other buffer). I'm using Vim 7.1a (sorry, haven't tested with 7.1b yet). GI -- 'Selfishness' -- Not being considerate of other people's selfishness.
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
Micah Cowan wrote: Following description lifted from bug filed at https://bugs.launchpad.net/ubuntu/+source/vim/+bug/78960 [EMAIL PROTECTED]:~$ rm .viminfo [EMAIL PROTECTED]:~$ ln -s /dev/null .viminfo [EMAIL PROTECTED]:~$ ls -l .viminfo lrwxrwxrwx 1 sa sa 9 2007-01-12 17:16 .viminfo - /dev/null [EMAIL PROTECTED]:~$ umask 007 [EMAIL PROTECTED]:~$ /usr/bin/vim.basic -c 'quit' [EMAIL PROTECTED]:~$ ls -l .viminfo -rw-rw-rw- 1 sa sa 509 2007-01-12 17:16 .viminfo As you can see the .viminfo file gets deleted and re-created with permissions 666 by vim. Note that the use of -c 'quit' is just to simplify the bug for transcribing here -- I promise you the same thing happens if you use vim for editing/saving a document as well. I consider this a security bug. vim deletes a file without telling me, and not only that but when it re-creates it, it ignores my umask by making it world writable. This is not what I expected it to do. Do you seriously believe that when you create a symlink to /dev/null that things continue to work normally? Come on... The solution is simple: Don't create a link in place of the .viminfo file. And certainly not to /dev/null. Background info: When Vim finds an existing .viminfo file, it writes the new info into a temp file (since it's still reading from the existing one it can't be overwritten). When finished the temp file is moved in place of the old .viminfo and owner and protection are set to match the original. Vim intentionally doesn't follow symlinks for .viminfo, because that can be used for a symlink attack, a security issue. -- hundred-and-one symptoms of being an internet addict: 111. You and your friends get together regularly on IRC, even though all of you live in the same city. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
Bram Moolenaar wrote: Micah Cowan wrote: Following description lifted from bug filed at https://bugs.launchpad.net/ubuntu/+source/vim/+bug/78960 [EMAIL PROTECTED]:~$ rm .viminfo [EMAIL PROTECTED]:~$ ln -s /dev/null .viminfo [EMAIL PROTECTED]:~$ ls -l .viminfo lrwxrwxrwx 1 sa sa 9 2007-01-12 17:16 .viminfo - /dev/null [EMAIL PROTECTED]:~$ umask 007 [EMAIL PROTECTED]:~$ /usr/bin/vim.basic -c 'quit' [EMAIL PROTECTED]:~$ ls -l .viminfo -rw-rw-rw- 1 sa sa 509 2007-01-12 17:16 .viminfo As you can see the .viminfo file gets deleted and re-created with permissions 666 by vim. Note that the use of -c 'quit' is just to simplify the bug for transcribing here -- I promise you the same thing happens if you use vim for editing/saving a document as well. I consider this a security bug. vim deletes a file without telling me, and not only that but when it re-creates it, it ignores my umask by making it world writable. This is not what I expected it to do. Do you seriously believe that when you create a symlink to /dev/null that things continue to work normally? Come on... The above were not my words; they were from the bug reporter, as I said (though I didn't make it clear that I didn't report the bug, I suppose). However, to answer your question: I would expect such a common idiom to work, at least in the case of files that are given to vim. Since .viminfo is a file that vim would supposedly generate and manage itself, the case may be less strong. The solution is simple: Don't create a link in place of the .viminfo file. And certainly not to /dev/null. Background info: When Vim finds an existing .viminfo file, it writes the new info into a temp file (since it's still reading from the existing one it can't be overwritten). When finished the temp file is moved in place of the old .viminfo and owner and protection are set to match the original. Vim intentionally doesn't follow symlinks for .viminfo, because that can be used for a symlink attack, a security issue. How so? The user won't be able to attack files he doesn't have write permission to, and other users wouldn't be running from his .viminfo, AFAICT. And the user shouldn't have permission to replace other users' .viminfo's with a symlink... so I'm missing something. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
Micah Cowan wrote: Bram Moolenaar wrote: [...] The solution is simple: Don't create a link in place of the .viminfo file. And certainly not to /dev/null. Background info: When Vim finds an existing .viminfo file, it writes the new info into a temp file (since it's still reading from the existing one it can't be overwritten). When finished the temp file is moved in place of the old .viminfo and owner and protection are set to match the original. Vim intentionally doesn't follow symlinks for .viminfo, because that can be used for a symlink attack, a security issue. How so? The user won't be able to attack files he doesn't have write permission to, and other users wouldn't be running from his .viminfo, AFAICT. And the user shouldn't have permission to replace other users' .viminfo's with a symlink... so I'm missing something. Maybe you're missing the fact that /dev/null is crw-rw-rw- i.e. world-readable and -writable? Best regards, Tony. -- You can take all the impact that science considerations have on funding decisions at NASA, put them in the navel of a flea, and have room left over for a caraway seed and Tony Calio's heart. -- F. Allen
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
A.J.Mechelynck wrote: Micah Cowan wrote: Bram Moolenaar wrote: [...] The solution is simple: Don't create a link in place of the .viminfo file. And certainly not to /dev/null. Background info: When Vim finds an existing .viminfo file, it writes the new info into a temp file (since it's still reading from the existing one it can't be overwritten). When finished the temp file is moved in place of the old .viminfo and owner and protection are set to match the original. Vim intentionally doesn't follow symlinks for .viminfo, because that can be used for a symlink attack, a security issue. How so? The user won't be able to attack files he doesn't have write permission to, and other users wouldn't be running from his .viminfo, AFAICT. And the user shouldn't have permission to replace other users' .viminfo's with a symlink... so I'm missing something. Maybe you're missing the fact that /dev/null is crw-rw-rw- i.e. world-readable and -writable? No, I'm not missing that. Why should that make a difference? It is, after all, a special file; and only root would be able to replace it with something else. Anyway, Bram was saying that it's a general security hole, not just for when /dev/null is the target. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
Micah Cowan wrote: A.J.Mechelynck wrote: Micah Cowan wrote: Bram Moolenaar wrote: [...] The solution is simple: Don't create a link in place of the .viminfo file. And certainly not to /dev/null. Background info: When Vim finds an existing .viminfo file, it writes the new info into a temp file (since it's still reading from the existing one it can't be overwritten). When finished the temp file is moved in place of the old .viminfo and owner and protection are set to match the original. Vim intentionally doesn't follow symlinks for .viminfo, because that can be used for a symlink attack, a security issue. How so? The user won't be able to attack files he doesn't have write permission to, and other users wouldn't be running from his .viminfo, AFAICT. And the user shouldn't have permission to replace other users' .viminfo's with a symlink... so I'm missing something. Maybe you're missing the fact that /dev/null is crw-rw-rw- i.e. world-readable and -writable? No, I'm not missing that. Why should that make a difference? It is, after all, a special file; and only root would be able to replace it with something else. Anyway, Bram was saying that it's a general security hole, not just for when /dev/null is the target. Yes, but when a viminfo exists, Vim re-creates it with the same permissions. IIUC, a link inherits the permissions of the target: here, rw-rw-rw-. Instead of linking to /dev/null, make sure your viminfo is not world-writable, and it will stay that way. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 231. You sprinkle Carpet Fresh on the rugs and put your vacuum cleaner in the front doorway permanently so it always looks like you are actually attempting to do something about that mess that has amassed since you discovered the Internet.
Re: [Bulk] Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
A.J.Mechelynck wrote: Micah Cowan wrote: A.J.Mechelynck wrote: Micah Cowan wrote: Bram Moolenaar wrote: [...] The solution is simple: Don't create a link in place of the .viminfo file. And certainly not to /dev/null. Background info: When Vim finds an existing .viminfo file, it writes the new info into a temp file (since it's still reading from the existing one it can't be overwritten). When finished the temp file is moved in place of the old .viminfo and owner and protection are set to match the original. Vim intentionally doesn't follow symlinks for .viminfo, because that can be used for a symlink attack, a security issue. How so? The user won't be able to attack files he doesn't have write permission to, and other users wouldn't be running from his .viminfo, AFAICT. And the user shouldn't have permission to replace other users' .viminfo's with a symlink... so I'm missing something. Maybe you're missing the fact that /dev/null is crw-rw-rw- i.e. world-readable and -writable? No, I'm not missing that. Why should that make a difference? It is, after all, a special file; and only root would be able to replace it with something else. Anyway, Bram was saying that it's a general security hole, not just for when /dev/null is the target. Yes, but when a viminfo exists, Vim re-creates it with the same permissions. IIUC, a link inherits the permissions of the target: here, rw-rw-rw-. Instead of linking to /dev/null, make sure your viminfo is not world-writable, and it will stay that way. Best regards, Tony. Tony, Out of curiosity, what would vim do in this case: cp -f /dev/null ~/.viminfo chmod 400 ~/.viminfo ? Would it give any write errors? Would it delete and recreate? Would the file be left blank on exit? I guess intuitively I would expect the file to be left blank (unmodified) without vim giving me any errors. But IIUC, vim would, on exit, actually silently delete the blank file, and create a new one with new contents with the permissions set to r. Is this correct? Thanks! -Robert
Re: [Bulk] Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
Robert Lee wrote: A.J.Mechelynck wrote: Micah Cowan wrote: A.J.Mechelynck wrote: Micah Cowan wrote: Bram Moolenaar wrote: [...] The solution is simple: Don't create a link in place of the .viminfo file. And certainly not to /dev/null. Background info: When Vim finds an existing .viminfo file, it writes the new info into a temp file (since it's still reading from the existing one it can't be overwritten). When finished the temp file is moved in place of the old .viminfo and owner and protection are set to match the original. Vim intentionally doesn't follow symlinks for .viminfo, because that can be used for a symlink attack, a security issue. How so? The user won't be able to attack files he doesn't have write permission to, and other users wouldn't be running from his .viminfo, AFAICT. And the user shouldn't have permission to replace other users' .viminfo's with a symlink... so I'm missing something. Maybe you're missing the fact that /dev/null is crw-rw-rw- i.e. world-readable and -writable? No, I'm not missing that. Why should that make a difference? It is, after all, a special file; and only root would be able to replace it with something else. Anyway, Bram was saying that it's a general security hole, not just for when /dev/null is the target. Yes, but when a viminfo exists, Vim re-creates it with the same permissions. IIUC, a link inherits the permissions of the target: here, rw-rw-rw-. Instead of linking to /dev/null, make sure your viminfo is not world-writable, and it will stay that way. Best regards, Tony. Tony, Out of curiosity, what would vim do in this case: cp -f /dev/null ~/.viminfo chmod 400 ~/.viminfo ? Would it give any write errors? Would it delete and recreate? Would the file be left blank on exit? I guess intuitively I would expect the file to be left blank (unmodified) without vim giving me any errors. But IIUC, vim would, on exit, actually silently delete the blank file, and create a new one with new contents with the permissions set to r. Is this correct? Thanks! -Robert Let's find out (and, first, move my usual viminfo out of the way by renaming...) Logged-in as root: the viminfo is overwritten with non-zero length and -rw---. But root can write anything. Let's retry with a different login. At Vim shutdown: E137: viminfo file is not writable: /home/tonymec/.viminfo ls -l .viminfo -r 1 tonymec users 0 2007-05-12 23:52 .viminfo The file remains zero-length and readonly. Best regards, Tony. -- Last week a cop stopped me in my car. He asked me if I had a police record. I said, no, but I have the new DEVO album. Cops have no sense of humor.
BUG: wrong recognition of words in Vim7.1b on Windows
Hello, Vim 7.1b on Windows XP doesn't properly recognizes words. It does not count Polish diacritics in, so each one is treated as separate word. This is serious bug and with taking into account that Windows users can have problems with getting patched versions it is IMO showstopper. In its nature it may be similar to bug fixed by 6.3.052 - not proper recognition of non ASCII characters (but inserting works). On Linux everything works OK. gvim7.1b from ftp.vim.org v:lang = PL v:lc_time = Polish_Poland.1250 encoding = cp1250 m. Wczoraj chodziło o honor. Dzisiaj - o sprawiedliwość. Mark Wahlberg i Danny Glover w pełnym akcji filmie STRZELEC - w kinach od 11 maja. http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fstrzelec.htmlsid=1134
Re: BUG: wrong recognition of words in Vim7.1b on Windows
Mikolaj Machowski wrote: Vim 7.1b on Windows XP doesn't properly recognizes words. It does not count Polish diacritics in, so each one is treated as separate word. This is serious bug and with taking into account that Windows users can have problems with getting patched versions it is IMO showstopper. In its nature it may be similar to bug fixed by 6.3.052 - not proper recognition of non ASCII characters (but inserting works). On Linux everything works OK. gvim7.1b from ftp.vim.org v:lang = PL v:lc_time = Polish_Poland.1250 encoding = cp1250 What do you mean with recognizing a word? What commands do you use? What version of Vim (console/GUI/...)? Did you compile yourself or use one of the distributed binaries? What is the :version output? What is 'iskeyword' set to and where was it set? What if you use vim -u NONE? Very likely this is a problem in your setup, not in Vim. So please check your setup carefully before blaming Vim. -- hundred-and-one symptoms of being an internet addict: 95. Only communication in your household is through email. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: BUG: wrong recognition of words in Vim7.1b on Windows
What is 'iskeyword' set to and where was it set? :15verbose se isk? returns n:\mikolaj\pf\vim\vim71b\vimrc_example.vim m. INFERNAL: From Paris to Berlin Potężna dawka hitów! CD+DVD już w sklepach! http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Finfernal.htmlsid=1138
Re: BUG: wrong recognition of words in Vim7.1b on Windows
Mikolaj Machowski wrote: Vim 7.1b on Windows XP doesn't properly recognizes words. It does not count Polish diacritics in, so each one is treated as separate word. This is serious bug and with taking into account that Windows users can have problems with getting patched versions it is IMO showstopper. In its nature it may be similar to bug fixed by 6.3.052 - not proper recognition of non ASCII characters (but inserting works). On Linux everything works OK. gvim7.1b from ftp.vim.org v:lang = PL v:lc_time = Polish_Poland.1250 encoding = cp1250 What do you mean with recognizing a word? What commands do you use? Eg. diw For example when using diw on '³±ka' (meadow) on 1st character it removes only first two characters, the same for 2nd character, when using on 3rd or 4th char it removes last 2 chars. What version of Vim (console/GUI/...)? Did you compile yourself or use one of the distributed binaries? What is the :version output? *G*vim binaries from ftp.vim.org VIM - Vi IMproved 7.1b BETA (2007 May 10, compiled May 10 2007 17:57:09) MS-Windows 32 bit GUI version Compiled by [EMAIL PROTECTED] Big version with GUI. Features included (+) or not (-): [...] What is 'iskeyword' set to and where was it set? When started normally @,48-57,_,128-167,224-235 When -U NONE @,48-57,_ That @ means that Vim uses the library function isalpha(). Apparently your environment is not setup properly for isalpha() to work with your encoding cp1250. Thus that is a problem with your library/system/environment. You can fix it by manually setting 'iskeyword'. Vim has no other way to find out what are word characters in your language and encoding. Or you can use 'encoding' set to utf-8, because then Vim knows which characters are word characters. -- hundred-and-one symptoms of being an internet addict: 96. On Super Bowl Sunday, you followed the score by going to the Yahoo main page instead of turning on the TV. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Bug: .viminfo file gets deleted and re-created with 666 permissions
Following description lifted from bug filed at https://bugs.launchpad.net/ubuntu/+source/vim/+bug/78960 [EMAIL PROTECTED]:~$ rm .viminfo [EMAIL PROTECTED]:~$ ln -s /dev/null .viminfo [EMAIL PROTECTED]:~$ ls -l .viminfo lrwxrwxrwx 1 sa sa 9 2007-01-12 17:16 .viminfo - /dev/null [EMAIL PROTECTED]:~$ umask 007 [EMAIL PROTECTED]:~$ /usr/bin/vim.basic -c 'quit' [EMAIL PROTECTED]:~$ ls -l .viminfo -rw-rw-rw- 1 sa sa 509 2007-01-12 17:16 .viminfo As you can see the .viminfo file gets deleted and re-created with permissions 666 by vim. Note that the use of -c 'quit' is just to simplify the bug for transcribing here -- I promise you the same thing happens if you use vim for editing/saving a document as well. I consider this a security bug. vim deletes a file without telling me, and not only that but when it re-creates it, it ignores my umask by making it world writable. This is not what I expected it to do. I was able to confirm this bug, both in Ubuntu's vim-gnome-7.0-164+1ubuntu7 package, and in the latest 7.1b sources. I also have a separate question: is this an appropriate place to post bugs? Specifically, when (a) I am interested in potential discussion related to it, and/or (b) I am interested in possibly implementing the fix for it? :he bugs suggests submitting bugs to [EMAIL PROTECTED], but from the description, it sounds like those go to a single person, and are not tracked (so, no opportunity for discussion, and it's hard to know if a bug has been reported or what it's status is). A subject change may be appropriate for answering this separate question. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
Micah Cowan wrote: Following description lifted from bug filed at https://bugs.launchpad.net/ubuntu/+source/vim/+bug/78960 [EMAIL PROTECTED]:~$ rm .viminfo [EMAIL PROTECTED]:~$ ln -s /dev/null .viminfo [EMAIL PROTECTED]:~$ ls -l .viminfo lrwxrwxrwx 1 sa sa 9 2007-01-12 17:16 .viminfo - /dev/null [EMAIL PROTECTED]:~$ umask 007 [EMAIL PROTECTED]:~$ /usr/bin/vim.basic -c 'quit' [EMAIL PROTECTED]:~$ ls -l .viminfo -rw-rw-rw- 1 sa sa 509 2007-01-12 17:16 .viminfo As you can see the .viminfo file gets deleted and re-created with permissions 666 by vim. Note that the use of -c 'quit' is just to simplify the bug for transcribing here -- I promise you the same thing happens if you use vim for editing/saving a document as well. I consider this a security bug. vim deletes a file without telling me, and not only that but when it re-creates it, it ignores my umask by making it world writable. This is not what I expected it to do. I was able to confirm this bug, both in Ubuntu's vim-gnome-7.0-164+1ubuntu7 package, and in the latest 7.1b sources. I also have a separate question: is this an appropriate place to post bugs? Specifically, when (a) I am interested in potential discussion related to it, and/or (b) I am interested in possibly implementing the fix for it? :he bugs suggests submitting bugs to [EMAIL PROTECTED], but from the description, it sounds like those go to a single person, and are not tracked (so, no opportunity for discussion, and it's hard to know if a bug has been reported or what it's status is). A subject change may be appropriate for answering this separate question. I suppose it's not expected that your viminfo might be a soft link to a device. To avoid using a viminfo, use :set viminfo= To have it non-world-readable, what about cp -vf /dev/null ~/.viminfo chmod 600 ~/.viminfo I expect that when the viminfo is a true file, Vim will respect its permissions. Best regards, Tony. -- The Army is a place where you get up early in the morning to be yelled at by people with short haircuts and tiny brains. -- Dave Barry
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
Micah Cowan [EMAIL PROTECTED] writes: Is there a good reason not to simply follow symlinks when they are encountered, as this user obviously expected? If it did follow the symlink to /dev/null, and tried to read from that device, it would fail. You can't (or at least, shouldn't) read from /dev/null because it's a sink, not a source. What kind of behavior would you expect, trying to read from /dev/null? I realize that unsetting viminfo is preferable to linking .viminfo to /dev/null; but I believe we still have a responsibility to users who just happen to try a different route (perhaps being unaware of the canonical method), for which they have a reasonable expectation that it will DTRT. I think soft linking a file that is meant to be both read and written to the bit bucket demonstrates that the user has just enough knowledge to be dangerous but without knowing exactly how to get what they want. As that kind of a user, I would expect an error message of some sort, in this situation. -- Taylor Venable [EMAIL PROTECTED] http://www.metasyntax.net/
Re: Bug: .viminfo file gets deleted and re-created with 666 permissions
Taylor Venable wrote: [...] If it did follow the symlink to /dev/null, and tried to read from that device, it would fail. You can't (or at least, shouldn't) read from /dev/null because it's a sink, not a source. What kind of behavior would you expect, trying to read from /dev/null? [...] Reading from /dev/null wouldn't fail (in the sense of giving a read error): it would give an end-of-file signal. /dev/null is both a source (behaving as always at end-of-file) and a sink (writing to it always succeeds but the data is silently discarded). Try copying /dev/null to a valid but nonexistent filename, and you'll get a zero-length file with no error. Or if the file exists, cp -f /dev/null filename will truncate it to zero length. On Ms-Dos 2 and higher, the NUL device inherited the same behaviour, in (IIUC) conscious imitation of Unix. Best regards, Tony. -- Osborn's Law: Variables won't; constants aren't.
Re: (Doc bug) Error in options.txt
Tony Mechelynck wrote:
One word under :help 'ttymouse' was obviously forgotten when that
option got more possible settings. See suggested patch, attached.
To avoid it being forgotten again, I'll simply remove the count.
--
From know your smileys:
:-{} Too much lipstick
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
(Doc bug) Error in options.txt
One word under :help 'ttymouse' was obviously forgotten when that option got
more possible settings. See suggested patch, attached.
Best regards,
Tony.
--
You should never wear your best trousers when you go out to fight for
freedom and liberty.
-- Henrik Ibsen
*** ../vim71a/runtime/doc/options.txt Mon May 7 23:03:49 2007
--- runtime/doc/options.txt Wed May 9 03:02:49 2007
***
*** 1,4
! *options.txt* For Vim version 7.1a. Last change: 2007 May 05
VIM REFERENCE MANUAL by Bram Moolenaar
--- 1,4
! *options.txt* For Vim version 7.1a. Last change: 2007 May 09
VIM REFERENCE MANUAL by Bram Moolenaar
***
*** 7031,7037
{only in Unix and VMS, doesn't work in the GUI; not
available when compiled without |+mouse|}
Name of the terminal type for which mouse codes are to be recognized.
! Currently these three strings are valid:
*xterm-mouse*
xterm xterm-like mouse handling. The mouse generates
Esc[Mscr, where scr is three bytes:
--- 7031,7037
{only in Unix and VMS, doesn't work in the GUI; not
available when compiled without |+mouse|}
Name of the terminal type for which mouse codes are to be recognized.
! Currently these six strings are valid:
*xterm-mouse*
xterm xterm-like mouse handling. The mouse generates
Esc[Mscr, where scr is three bytes:
Bug: windo and exceptions
GVim runs into an endless loop if I do the following: clean startup :new at least two windows :windo throw foo Error detected while processing : E605: Exception not caught: foo E605: Exception not caught: foo E605: Exception not caught: foo E605: Exception not caught: foo ... Another example: clean startup :set modified :bot new :try : windo enew - go and kill GVim in the task manager (does not happen if :bot new is replaced by :abo new ) -- Regards, Andy EOM
Re: Bug: windo and exceptions
Andy Wokula wrote: GVim runs into an endless loop if I do the following: clean startup :new at least two windows :windo throw foo Error detected while processing : E605: Exception not caught: foo E605: Exception not caught: foo E605: Exception not caught: foo E605: Exception not caught: foo ... See patch below. Another example: clean startup :set modified :bot new :try : windo enew - go and kill GVim in the task manager (does not happen if :bot new is replaced by :abo new ) Solved with the same patch. Please verify. *** ../vim-7.0.240/src/ex_cmds2.c Tue Feb 13 06:21:24 2007 --- src/ex_cmds2.c Wed May 2 22:04:38 2007 *** *** 2287,2292 --- 2287,2294 if (!win_valid(wp)) break; win_goto(wp); + if (curwin != wp) + break; /* something must be wrong */ wp = curwin-w_next; } else if (eap-cmdidx == CMD_tabdo) -- The 50-50-90 rule: Anytime you have a 50-50 chance of getting something right, there's a 90% probability you'll get it wrong. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
bug in java indentation
There seems to be a bug in java indentation. The maintainer (Cc'ed) is said
to be resigned, so I'm writing here. It is sort of special situation. Take
a look at the println() in the following:
public class Bug {
public static void main(String args[]) {
Foo.bar(new Baz() {
public void run() {
if (true) {
/*nothing here*/
}
while (true);
System.out.println(doh!);
}
});
}
}
And some findings - it indent's correctly if you:
a) put the if .. { .. } on one line
b) remove the if
c) remove the while()
d) add body to the while
--
Best regards,
Tomas Golembiovsky
--
||- - -
|
| Law of Algebra
|
| You never catch on until after the test.
|
|- - -
Re: Bug: windo and exceptions
Bram Moolenaar schrieb: Andy Wokula wrote: GVim runs into an endless loop if I do the following: clean startup :new at least two windows :windo throw foo Error detected while processing : E605: Exception not caught: foo E605: Exception not caught: foo E605: Exception not caught: foo E605: Exception not caught: foo ... See patch below. Another example: clean startup :set modified :bot new :try : windo enew - go and kill GVim in the task manager (does not happen if :bot new is replaced by :abo new ) Solved with the same patch. Please verify. *** ../vim-7.0.240/src/ex_cmds2.c Tue Feb 13 06:21:24 2007 --- src/ex_cmds2.c Wed May 2 22:04:38 2007 *** *** 2287,2292 --- 2287,2294 if (!win_valid(wp)) break; win_goto(wp); + if (curwin != wp) + break; /* something must be wrong */ wp = curwin-w_next; } else if (eap-cmdidx == CMD_tabdo) Great, the patch works (examples tested). -- Thanks, Andy EOM
Re: possible bug: lowercase dotless i and langmap
Ali Polatel wrote: Hi everyone, I was playing around with langmap and found out there is a problem with characters 'ı'[1] - 0131;LATIN SMALL LETTER DOTLESS I - and 'Ä'[2] - 011F;LATIN SMALL LETTER G WITH BREVE The Turkish keyboard looks like this[3] for those who don't know about it. The problem is when I set langmap=ıi small dotless I doesn't work as expected. I'm using tr_TR.UTF-8 locale and I tried it both on the console,with consoles on X and with gvim. The same is true for g with breve. The other turkish keys work fine with langmap. I wasn't sure if this was about my system or vim so I made some people with turkish keyboards try this: [EMAIL PROTECTED] ~ $ vim -c set lmap=ıi execute \normal ıhi\Esc\ let line = getline(1) if line =~ \hi\ echo \The dotless small I works as expected\ else echo \The dotless small I doesn't work with langmap\ endif - - there is probably a shorter way but anyway :) - and they could reproduce the problem. Internationalizing dotted and dotless letter I has always been a problem[4] but I don't think this is the issue here because the same problem exists for g with breve. From :help 'langmap': This only works for 8-bit characters. The value of 'langmap' may be specified with multi-byte characters (e.g., UTF-8), but only the lower 8 bits of each character will be used. I guess most Turkish characters are in latin1, only the ones that are not won't work with 'langmap'. -- How To Keep A Healthy Level Of Insanity: 3. Every time someone asks you to do something, ask if they want fries with that. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: possible bug: lowercase dotless i and langmap
Bram Moolenaar wrote: [...] I guess most Turkish characters are in latin1, only the ones that are not won't work with 'langmap'. small undotted i, g-breve, s-cedilla, ... Best regards, Tony. -- The primary requisite for any new tax law is for it to exempt enough voters to win the next election.
possible bug: lowercase dotless i and langmap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, I was playing around with langmap and found out there is a problem with characters 'ı'[1] - 0131;LATIN SMALL LETTER DOTLESS I - and 'ğ'[2] - 011F;LATIN SMALL LETTER G WITH BREVE The Turkish keyboard looks like this[3] for those who don't know about it. The problem is when I set langmap=ıi small dotless I doesn't work as expected. I'm using tr_TR.UTF-8 locale and I tried it both on the console,with consoles on X and with gvim. The same is true for g with breve. The other turkish keys work fine with langmap. I wasn't sure if this was about my system or vim so I made some people with turkish keyboards try this: [EMAIL PROTECTED] ~ $ vim -c set lmap=ıi execute \normal ıhi\Esc\ let line = getline(1) if line =~ \hi\ echo \The dotless small I works as expected\ else echo \The dotless small I doesn't work with langmap\ endif - - there is probably a shorter way but anyway :) - and they could reproduce the problem. Internationalizing dotted and dotless letter I has always been a problem[4] but I don't think this is the issue here because the same problem exists for g with breve. Regards, [1] http://www.fileformat.info/info/unicode/char/0131/index.htm [2] http://www.fileformat.info/info/unicode/char/011f/index.htm [3] http://upload.wikimedia.org/wikipedia/commons/thumb/6/63/KB_Turkey.svg/540px-KB_Turkey.svg.png [4] http://www.i18nguy.com/unicode/turkish-i18n.html - -- Ali Polatel (hawking) [EMAIL PROTECTED] http://hawking.nonlogic.org/ gpg: 0x8E724EDC fp: DBC2 2BC7 95B8 6D6C 8BC3 37EC CA00 CFC1 8E72 4EDC () ascii ribbon campaign - against html mail /\ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) iD8DBQFGMRvFygDPwY5yTtwRAl34AKCR03ale9/J1wTZHd+iC2T4Jykl/ACgkoqE NaEI8m12uXStnfwAZdt/MG8= =pI61 -END PGP SIGNATURE-
Re: possible bug with vim7 and the arrow keys
On 4/23/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Виктор Кожухаров wrote: Hello, I think there might be a bug with vim7, and they way it handles the arrow keys in a terminal. The problem is, that in insert mode, the arrow keys don't navigate through the text, but output letters. For example, pressing Up in insert mode would do the equivalent of OAEsc in normal mode. All the arrow keys are printing the letters that are part of their escape codes in the line above the current one. Also, the reason I think this is a bug is that, on the same machines, vim6 works correctly. the TERM variable is set to xterm in both the terminal and in vim, and this behaviour occurs in any terminal. Furthermore, none of the timeout options have any effect on this behaviour. Vim has been compiled with +terminfo and +termresponse against ncurses-5.6 Don't you have one version compiled with +terminfo and the other with -terminfo? Are both versions running with the same value of 'ttybuiltin'? Is 'term' left at its default? yes Try the following in both versions: :echo has(terminfo) :set term? ttybuiltin? :echo has(terminfo) 1 :set term? ttybuiltin? term=xterm ttybuiltin Each of the above might explain (with a badly-set-up system) the difference in behaviour you're seeing. Also, does it get better or worse if you run vim7 or vim6 (try both) as vim -u NONE -N to avoid loading the vimrc, gvimrc and plugins? I forgot to mention that I've already tried vim -u NONE with no success (and I've also tried with a clean .vim/ directory without a .vimrc) However, I havent tried vim -u NONE with -N. having both -u NONE and -N makes the keys work. So I'll start with vim -u NONE -N and set each option in the vimrc manually, to see exactly what breaks the arrow keys Best regards, Tony. -- If a camel flies, no one laughs if it doesn't get very far. -- Paul White .vimrc Description: Binary data
Re: possible bug with vim7 and the arrow keys
On 4/23/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Виктор Кожухаров wrote: Hello, I think there might be a bug with vim7, and they way it handles the arrow keys in a terminal. The problem is, that in insert mode, the arrow keys don't navigate through the text, but output letters. For example, pressing Up in insert mode would do the equivalent of OAEsc in normal mode. All the arrow keys are printing the letters that are part of their escape codes in the line above the current one. Also, the reason I think this is a bug is that, on the same machines, vim6 works correctly. the TERM variable is set to xterm in both the terminal and in vim, and this behaviour occurs in any terminal. Furthermore, none of the timeout options have any effect on this behaviour. Vim has been compiled with +terminfo and +termresponse against ncurses-5.6 Don't you have one version compiled with +terminfo and the other with -terminfo? Are both versions running with the same value of 'ttybuiltin'? Is 'term' left at its default? Try the following in both versions: :echo has(terminfo) :set term? ttybuiltin? Each of the above might explain (with a badly-set-up system) the difference in behaviour you're seeing. Also, does it get better or worse if you run vim7 or vim6 (try both) as vim -u NONE -N to avoid loading the vimrc, gvimrc and plugins? It turned out that these mappings broke the arrow keys in the terminal: inoremap expr Esc pumvisible()?\C-E:\Esc inoremap expr CR pumvisible()?\C-Y:\CR inoremap expr Down pumvisible()?\C-N:\Down inoremap expr Up pumvisible()?\C-P:\Up inoremap expr PageDown pumvisible()?\PageDown\C-P\C-N:\PageDown inoremap expr PageUp pumvisible()?\PageUp\C-P\C-N:\PageUp Best regards, Tony. -- If a camel flies, no one laughs if it doesn't get very far. -- Paul White
Re: possible bug with vim7 and the arrow keys
Viktor Kojouharov wrote: It turned out that these mappings broke the arrow keys in the terminal: inoremap expr Esc pumvisible()?\C-E:\Esc inoremap expr CR pumvisible()?\C-Y:\CR inoremap expr Down pumvisible()?\C-N:\Down inoremap expr Up pumvisible()?\C-P:\Up inoremap expr PageDown pumvisible()?\PageDown\C-P\C-N:\PageDown inoremap expr PageUp pumvisible()?\PageUp\C-P\C-N:\PageUp IMHO, if one is expecting to use vim (as opposed to gvim), mapping Esc causes trouble. That's because most terminals issue escape sequences (esc..something..) when special keys (such as the arrow keys, functions keys, etc), and that mapping of the esc key messes up the escape sequence. Besides -- how do you get out of insert mode? I realize one can use ctrl-o and norm!, but that seems painful. If you're not using normal mode or command mode, then you're missing a lot of vim. Regards, Chip Campbell
Re: possible bug with vim7 and the arrow keys
В пн, 2007-04-23 в 19:56 +0200, Nikolai Weibull написа: On 4/23/07, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Viktor Kojouharov wrote: It turned out that these mappings broke the arrow keys in the terminal: inoremap expr Esc pumvisible()?\C-E:\Esc IMHO, if one is expecting to use vim (as opposed to gvim), mapping Esc causes trouble. That's because most terminals issue escape sequences (esc..something..) when special keys (such as the arrow keys, functions keys, etc), and that mapping of the esc key messes up the escape sequence. That's only true if Vim actually interprets the characters coming in as normal characters and not an escape sequence. In that case it doesn't matter if Esc is remapped or not, you're going to get weird results anyway. Besides -- how do you get out of insert mode? I realize one can use ctrl-o and norm!, but that seems painful. If you're not using normal mode or command mode, then you're missing a lot of vim. If the pum isn't visible it maps to Esc, so it's not hard to get out of insert mode. Just make sure the pum isn't visible. That was the idea behind the mappings, which I took from a vimtip btw. But something happens, and none of the remapped keys (besides the Esc) work correctly if the pum is not visible. Perhaps it might still be a bug in vim7, but at least its explained now why vim6 works correctly. nikolai -- Виктор Кожухаров /Viktor Kojouharov/ signature.asc Description: Това е цифрово подписана част от писмото
possible bug with vim7 and the arrow keys
Hello, I think there might be a bug with vim7, and they way it handles the arrow keys in a terminal. The problem is, that in insert mode, the arrow keys don't navigate through the text, but output letters. For example, pressing Up in insert mode would do the equivalent of OAEsc in normal mode. All the arrow keys are printing the letters that are part of their escape codes in the line above the current one. Also, the reason I think this is a bug is that, on the same machines, vim6 works correctly. the TERM variable is set to xterm in both the terminal and in vim, and this behaviour occurs in any terminal. Furthermore, none of the timeout options have any effect on this behaviour. Vim has been compiled with +terminfo and +termresponse against ncurses-5.6 -- Виктор Кожухаров /Viktor Kojouharov/ signature.asc Description: Това е цифрово подписана част от писмото
Re: possible bug with vim7 and the arrow keys
Виктор Кожухаров wrote: Hello, I think there might be a bug with vim7, and they way it handles the arrow keys in a terminal. The problem is, that in insert mode, the arrow keys don't navigate through the text, but output letters. For example, pressing Up in insert mode would do the equivalent of OAEsc in normal mode. All the arrow keys are printing the letters that are part of their escape codes in the line above the current one. Also, the reason I think this is a bug is that, on the same machines, vim6 works correctly. the TERM variable is set to xterm in both the terminal and in vim, and this behaviour occurs in any terminal. Furthermore, none of the timeout options have any effect on this behaviour. Vim has been compiled with +terminfo and +termresponse against ncurses-5.6 Don't you have one version compiled with +terminfo and the other with -terminfo? Are both versions running with the same value of 'ttybuiltin'? Is 'term' left at its default? Try the following in both versions: :echo has(terminfo) :set term? ttybuiltin? Each of the above might explain (with a badly-set-up system) the difference in behaviour you're seeing. Also, does it get better or worse if you run vim7 or vim6 (try both) as vim -u NONE -N to avoid loading the vimrc, gvimrc and plugins? Best regards, Tony. -- If a camel flies, no one laughs if it doesn't get very far. -- Paul White
Re: Fwd: Perl colour coding bug
On Tue, 10 Apr 2007, Jon Combe wrote: The following snippet of code, when saved with a .pl file extension breaks the colour coding in Vim @split = split ( / |-|\/|\/ , $surname , -1 ); This sometimes annoys me, too. To work around it, use the 'm' operator specifically, thus: @split = split ( m/ |-|\/|\/ , $surname , -1 ); -- .
Fwd: Perl colour coding bug
The following snippet of code, when saved with a .pl file extension
breaks the colour coding in Vim
#!/usr/bin/perl -w
my $surname = ABC-DEF GHI;
@split = split ( / |-|\/|\/ , $surname , -1 );
foreach ( @split )
{
print $_\n;
}
The lines after the split (that contains a regular expression) are
highlighted as if they are within a double quoted string. The colour
coding is being confused by the character in the regular expression
and thinks (incorrectly) that it marks the start of a string. Is it
possible to fix this problem? For example the foreach text should
appear in yellow.
Thanks.
Jon.
Re: Fwd: Perl colour coding bug
Jon Combe wrote:
The following snippet of code, when saved with a .pl file extension
breaks the colour coding in Vim
#!/usr/bin/perl -w
my $surname = ABC-DEF GHI;
@split = split ( / |-|\/|\/ , $surname , -1 );
foreach ( @split )
{
print $_\n;
}
The lines after the split (that contains a regular expression) are
highlighted as if they are within a double quoted string. The colour
coding is being confused by the character in the regular expression
and thinks (incorrectly) that it marks the start of a string. Is it
possible to fix this problem? For example the foreach text should
appear in yellow.
The maintainer for perl is: Nick Hibma n_hibma AT van-laarhoven.org;
he's the appropriate contact for this sort of thing. I found his name in
vim70/syntax/perl.vim; syntax file maintainers generally put their contact
information in the syntax file they maintain.
Regards,
Chip Campbell
Re: autocmd bug?
Jürgen Krämer wrote:
[...]
the FileType event is only fired once with the exact filetype you
specified in your set command, so you must additionally define the
following autocommand:
autocmd FileType c.doxygen setlocal cindent number cursorline
Regards,
Jürgen
If that is true, doesn't it defeat the purpose of setting the filetype with a
dot?
Or should we add something like (untested)
:au Filetype \(w*\).\(\S*\) exe doau FileType \1 | exe doau FileType \2
?
('cindent' is set by the indent/c.vim plugin).
Best regards,
Tony.
--
If God had meant for us to be naked, we would have been born that way.
Re: autocmd bug?
Hi,
A.J.Mechelynck wrote:
Jürgen Krämer wrote:
[...]
the FileType event is only fired once with the exact filetype you
specified in your set command, so you must additionally define the
following autocommand:
autocmd FileType c.doxygen setlocal cindent number cursorline
If that is true, doesn't it defeat the purpose of setting the filetype with a
dot?
I'm not sure -- at least it seems to be a little bit inconsistent to
me, because :help 'filetype' explicitly mentions filetype plugins and
syntax files:
| When a dot appears in the value then this separates two filetype
| names. Example:
| /* vim: set filetype=c.doxygen : */ ~
| This will use the c filetype first, then the doxygen filetype.
| This works both for filetype plugins and for syntax files. More than
| one dot may appear.
So, moving the :setlocal commands from the autocommand to a filetype
plugin would work, but there seem to be a lot of people that want to
keep their settings in one single place -- namely ~/.vimrc -- to make
it simpler to exchange them between multiple installations.
Or should we add something like (untested)
:au Filetype \(w*\).\(\S*\) exe doau FileType \1 | exe doau FileType \2
?
Nice idea (esp. the recursion), but alas it's not that simple, because
the pattern only accepts wildcards (not regular expressions) and if it
did, the subpatterns would probably not be recognized in the command.
But your command gave me an idea -- the following should work
au FileType *.* exe substitute(expand('amatch'),
\ '^\(.*\)\.\(.*\)$',
\ 'doau FileType \1 | doau FileType \2',
\ '')
('cindent' is set by the indent/c.vim plugin).
Regards,
Jürgen
--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. (Calvin)
Re: autocmd bug?
Jürgen Krämer wrote:
[...]
Nice idea (esp. the recursion), but alas it's not that simple, because
the pattern only accepts wildcards (not regular expressions) and if it
did, the subpatterns would probably not be recognized in the command.
But your command gave me an idea -- the following should work
au FileType *.* exe substitute(expand('amatch'),
\ '^\(.*\)\.\(.*\)$',
\ 'doau FileType \1 | doau FileType \2',
\ '')
('cindent' is set by the indent/c.vim plugin).
Regards,
Jürgen
additional question: does :doau work in an autocommand or does it require a
nested flag somewhere?
Best regards,
Tony.
--
It was one of those perfect summer days -- the sun was shining, a
breeze was blowing, the birds were singing, and the lawn mower was
broken ...
-- James Dent
Re: autocmd bug?
On 3/26/07, Michael Wookey [EMAIL PROTECTED] wrote: I have the following in my .vimrc: filetype plugin indent on autocmd FileType c,h,cpp,hpp,cs setlocal cindent number cursorline If I have a new buffer and set the filetype as follows, everything works just fine: :set filetype=c However, if I have a new buffer and I set the filetype like this, the autocmd doesn't fire: :set filetype=c.doxygen This syntax is described in: :help 'filetype' Which line/paragraph ? Can you paste a n excerpt ? I don;t have it in my filetype.txt doc. I have vim7.188 and I don't have this functionality. About year ago I suggested such syntax -- 'set filetype=TYPE.SUBTYPE' -- but I don't think it was accepted. I think vim does not have this. Or is it some recent addition I'm not aware of ? Yakov
RE: autocmd bug?
I have the following in my .vimrc:
filetype plugin indent on
autocmd FileType c,h,cpp,hpp,cs setlocal cindent number
cursorline
If I have a new buffer and set the filetype as follows, everything
works
just fine:
:set filetype=c
However, if I have a new buffer and I set the filetype like this,
the
autocmd doesn't fire:
:set filetype=c.doxygen
This syntax is described in:
:help 'filetype'
Which line/paragraph ? Can you paste a n excerpt ? I don;t have
it in my filetype.txt doc. I have vim7.188 and I don't have this
functionality.
About year ago I suggested such syntax -- 'set filetype=TYPE.SUBTYPE'
-- but I don't think it was accepted. I think vim does not have this.
Or is it some recent addition I'm not aware of ?
From:
*options.txt* For Vim version 7.0. Last change: 2007 Mar 14
*'filetype'* *'ft'*
'filetype' 'ft' string (default: )
local to buffer
{not in Vi}
{not available when compiled without the
|+autocmd|
feature}
When this option is set, the FileType autocommand event is
triggered.
All autocommands that match with the value of this option will
be
executed. Thus the value of 'filetype' is used in place of the
file
name.
Otherwise this option does not always reflect the current file
type.
This option is normally set when the file type is detected. To
enable
this use the :filetype on command. |:filetype|
Setting this option to a different value is most useful in a
modeline,
for a file for which the file type is not automatically
recognized.
Example, for in an IDL file:
/* vim: set filetype=idl : */ ~
|FileType| |filetypes|
When a dot appears in the value then this separates two filetype
names. Example:
/* vim: set filetype=c.doxygen : */ ~
This will use the c filetype first, then the doxygen
filetype.
This works both for filetype plugins and for syntax files. More
than
one dot may appear.
Do not confuse this option with 'osfiletype', which is for the
file
type that is actually stored with the file.
This option is not copied to another buffer, independent of the
's' or
'S' flag in 'cpoptions'.
Only normal file name characters can be used, /\*?[| are
illegal.
Re: autocmd bug?
Hi, Michael Wookey schrieb: I have the following in my .vimrc: filetype plugin indent on autocmd FileType c,h,cpp,hpp,cs setlocal cindent number cursorline If I have a new buffer and set the filetype as follows, everything works just fine: :set filetype=c However, if I have a new buffer and I set the filetype like this, the autocmd doesn't fire: :set filetype=c.doxygen This syntax is described in: :help 'filetype' The result is that I don't get cindent, number or cursorline set. I actually noticed this behaviour when a modeline in a C file set the filetype to 'c.doxygen' and my options didn't appear. Does this work for anyone else or is it just my settings messing something up? Vim build details are below. the FileType event is only fired once with the exact filetype you specified in your set command, so you must additionally define the following autocommand: autocmd FileType c.doxygen setlocal cindent number cursorline Regards, Jürgen -- Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. (Calvin)
BUG vim 7.0-204?: autocmd CusorMoved vs select/visual mode vs :behave mswin vs norm!
Hi, When I use the following command (for demonstration purposes): au CursorMoved * norm! zz When I now press s-c-left or s-c-right, zz get inserted in the buffer. These cursor key seem to be set by :behave mswin. In summary: :au CursorMoved * norm! zz :behave mswin Press s-c-left or s-c-right zz gets inserted. Is there a work-around? Regards, Thomas.
Re: BUG vim 7.0-204?: autocmd CusorMoved vs select/visual mode vs :behave mswin vs norm!
Thomas wrote: Hi, When I use the following command (for demonstration purposes): au CursorMoved * norm! zz When I now press s-c-left or s-c-right, zz get inserted in the buffer. These cursor key seem to be set by :behave mswin. In summary: :au CursorMoved * norm! zz :behave mswin Press s-c-left or s-c-right zz gets inserted. Is there a work-around? Regards, Thomas. :behave mswin only sets a few options, but it is often used in conjunction with :source $VIMRUNTIME/mswin.vim, which sets a lot of potentially dangerous mappings. Search your vimrc /mswin\.vim and remove the line, or comment it away. Is the result better? Best regards, Tony. -- Scientists are people who build the Brooklyn Bridge and then buy it. -- William Buckley
Re: BUG vim 7.0-204?: autocmd CusorMoved vs select/visual mode vs :behave mswin vs norm!
Thomas wrote: When I use the following command (for demonstration purposes): au CursorMoved * norm! zz When I now press s-c-left or s-c-right, zz get inserted in the buffer. These cursor key seem to be set by :behave mswin. In summary: :au CursorMoved * norm! zz :behave mswin Press s-c-left or s-c-right zz gets inserted. Is there a work-around? When you do :behave mswin the shifted cursor keys start Select mode. What you type then replaces the selected text. Have a look at what :behave does, you can also set individual options. -- Q: Why does /dev/null accept only integers? A: You can't sink a float. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: BUG vim 7.0-204?: autocmd CusorMoved vs select/visual mode vs :behave mswin vs norm!
When in Select mode you are still in sort-of Normal mode. Your autocommand will have to take care of mode stuff by itself. You can use CTRL-\ CTRN-N to make sure you are in Normal mode. Okay, I now wrapped the norm! commands in a function and check via mode() if we are in select mode and then prepend c-o to the command if that's the case. It works without destroying the selection but it looks strange to me. Regards, Thomas. ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: Bug report: display bug with accented characters and completion menu
Gombault Damien wrote: I noticed a display bug with the completion menu. If accented characters appears in the completion menu, some others characters from the edited file appears too in the menu ! It's quite difficult to explain so I've made some screenshots. You can also notice these bad characters appears only if a filename is displayed next to the word. Screenshots taken from Ubuntu Feisty (VIM 7.0-164) : - GVIM (GTK+) with custom config : http://img139.imageshack.us/img139/21/vim1et2.png - GVIM (GTK+) with custom config (another colorscheme) : http://img115.imageshack.us/img115/6541/vim2jb9.png - GVIM (GTK+) with default config : http://img163.imageshack.us/img163/2661/vim3fp1.png - VIM (gnome-terminal) with default config : http://img53.imageshack.us/img53/6716/vim4xk5.png I noticed this bug with : - GVIM (GTK+) 7.0-164 (Ubuntu Feisty) - VIM (gnome-terminal) 7.0-164 (Ubuntu Feisty) - GVIM (GTK+) 7.0-201 (Gentoo) - GVIM (x11) 7.0-201 (Gentoo) (I have not tested x11 on other builds) - VIM (konsole) 7.0-201 (Gentoo) - GVIM (GTK+) 7.0-219 (custom build on Gentoo) - VIM (konsole) 7.0-219 (custom build on Gentoo) I have NOT noticed this bug with : - GVIM (win32) 7.0-219 (Cream build without Cream config) A few questions: - What is 'encoding' set to? - What is the actual text in the entries with problems? Give this byte-for-byte. You may need to insert an entry to find out. - Can you reproduce it by setting 'omnifunc' to a simple function that returns a fixed list of text entries? If so, please give us the script with this. Otherwise, give us a text file to reproduce the problem. - The entries in the menu appear not to be sorted. How did this happen? - What did you type to get to these screenshots? -- When I die, I want a tombstone that says GAME OVER - Ton Richters /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Bug report: display bug with accented characters and completion menu
A few questions: - What is 'encoding' set to? - What is the actual text in the entries with problems? Give this byte-for-byte. You may need to insert an entry to find out. - Can you reproduce it by setting 'omnifunc' to a simple function that returns a fixed list of text entries? If so, please give us the script with this. Otherwise, give us a text file to reproduce the problem. - The entries in the menu appear not to be sorted. How did this happen? - What did you type to get to these screenshots? My system is UTF-8, so 'encoding' is also set to 'utf-8'. On the screenshot, the file was wrotten in 'latin1' charset. After some tests, I noticed this bugs seems only appears when 'encoding' and 'fileencoding' are not the same. Finally, I could get this bug on win32 : I set 'encoding' to 'utf-8' then open some 'latin-1' files. I wrote two very simple C++ file to help you to reproduce the bug. These two files are written in 'latin1' charset. Their content is simple C++ comments containing French text with accented characters like é, è, à, etc. Put the two files in the same directory. Then open gvim and set your 'encoding' to 'utf-8'. Edit the '2.cpp' file. Verify that 'fileencoding' is set to 'latin1'. Insert a new line between #include and the begin of the /* comment. (o key) Then type CTRL+x CTRL+i and the include completion menu appears like this : http://img131.imageshack.us/img131/4117/vim5ls3.png Another test : 'encoding' = latin1 and utf-8 texts, you get this : http://img78.imageshack.us/img78/483/vim6nt2.png Accents are not correctly displayed. The completion menu uses 'encoding' to display its text. When you edit a file, the buffer is converted to the current encoding (the [converted] message). When you use the completion menu with current buffer words, accented characters will be correctly displayed. But if you use completion menu with words in other files (like with include completion) with a different fileencoding than your current buffer encoding, accented characters will not be displayed correctly because they are not converted to the current encoding. So words from other files should be converted to the current buffer 'encoding' before display them in the completion menu. That will certainly fix this problem. Regards. -- Gombault Damien | Powered by Gentoo Linux AMD64 texts.tar.gz Description: application/tgz
Re: Bug report: display bug with accented characters and completion menu
Another test with 3 files : 1.cpp : UTF-8 file with French accented characters. 2.cpp : the same file but with Latin-1 charset. 3.cpp : a file to test 'include' completion. Yes, it's a bit strange because it's not a great idea to work with different encodings. But it shows the problem. :) Put the 3 files in the same directory. Run Gvim, set your 'encoding' to 'latin1'. Edit 3.cpp file. Type, before the comment, CTRL-x CTRL-i for 'include' completion. Words from 1.cpp are not displayed in the completion menu because words are not converted to the current encoding. Run Gvim, set your 'encoding' to 'utf-8'. Edit 3.cpp file. Type, before the comment, CTRL-x CTRL-i for 'include' completion. Words from 2.cpp are displayed but you have a display bug with the completion menu because words are not converted to the current encoding. Regards. -- Gombault Damien | Powered by Gentoo Linux AMD64 another_test.tar.gz Description: application/tgz
Re: Bug report: display bug with accented characters and completion menu
Gombault Damien wrote:
A few questions:
- What is 'encoding' set to?
- What is the actual text in the entries with problems? Give this
byte-for-byte. You may need to insert an entry to find out.
- Can you reproduce it by setting 'omnifunc' to a simple function that
returns a fixed list of text entries? If so, please give us the
script with this. Otherwise, give us a text file to reproduce the
problem.
- The entries in the menu appear not to be sorted. How did this happen?
- What did you type to get to these screenshots?
My system is UTF-8, so 'encoding' is also set to 'utf-8'. On the screenshot,
the file was wrotten in 'latin1' charset.
After some tests, I noticed this bugs seems only appears when 'encoding'
and 'fileencoding' are not the same. Finally, I could get this bug on win32 :
I set 'encoding' to 'utf-8' then open some 'latin-1' files.
I wrote two very simple C++ file to help you to reproduce the bug. These two
files are written in 'latin1' charset. Their content is simple C++ comments
containing French text with accented characters like é, è, à, etc.
Put the two files in the same directory.
Then open gvim and set your 'encoding' to 'utf-8'.
Edit the '2.cpp' file.
Verify that 'fileencoding' is set to 'latin1'.
Insert a new line between #include and the begin of the /* comment. (o key)
Then type CTRL+x CTRL+i and the include completion menu appears like this :
http://img131.imageshack.us/img131/4117/vim5ls3.png
Another test :
'encoding' = latin1 and utf-8 texts, you get this :
http://img78.imageshack.us/img78/483/vim6nt2.png
Accents are not correctly displayed.
The completion menu uses 'encoding' to display its text.
When you edit a file, the buffer is converted to the current encoding (the
[converted] message). When you use the completion menu with current buffer
words, accented characters will be correctly displayed.
But if you use completion menu with words in other files (like with include
completion) with a different fileencoding than your current buffer encoding,
accented characters will not be displayed correctly because they are not
converted to the current encoding.
So words from other files should be converted to the current buffer
'encoding' before display them in the completion menu. That will
certainly fix this problem.
Thanks for the clear example. I'm now able to reproduce the problem.
There are actually two problems. One is that text with non-printable
characters causes trouble in the popup menu. I'll fix that now (see
patch below).
The other is that completions obtained from a file in another encoding
result in text with the wrong encoding. That's difficult to fix. It
would require loading the file as if editing it, so that the encoding is
detected. I'll put this in the todo list, but don't expect it to be
fixed soon.
*** ../vim-7.0.219/src/charset.cTue Apr 18 00:04:40 2006
--- src/charset.c Sat Mar 24 21:10:37 2007
***
*** 317,323
}
}
! #if defined(FEAT_EVAL) || defined(FEAT_TITLE) || defined(PROTO)
/*
* Translate a string into allocated memory, replacing special chars with
* printable chars. Returns NULL when out of memory.
--- 317,324
}
}
! #if defined(FEAT_EVAL) || defined(FEAT_TITLE) || defined(FEAT_INS_EXPAND) \
! || defined(PROTO)
/*
* Translate a string into allocated memory, replacing special chars with
* printable chars. Returns NULL when out of memory.
*** ../vim-7.0.219/src/popupmnu.c Tue Aug 22 21:51:18 2006
--- src/popupmnu.c Sat Mar 24 21:07:39 2007
***
*** 280,287
w = ptr2cells(p);
if (*p == NUL || *p == TAB || totwidth + w pum_width)
{
! /* Display the text that fits or comes before a Tab. */
! screen_puts_len(s, (int)(p - s), row, col, attr);
col += width;
if (*p != TAB)
--- 280,299
w = ptr2cells(p);
if (*p == NUL || *p == TAB || totwidth + w pum_width)
{
! /* Display the text that fits or comes before a Tab.
!* First convert it to printable characters. */
! char_u *st;
! int saved = *p;
!
! *p = NUL;
! st = transstr(s);
! *p = saved;
! if (st != NULL)
! {
! screen_puts_len(st, (int)STRLEN(st), row, col,
! attr);
! vim_free(st);
! }
col += width;
if (*p != TAB)
--
Dreams are free, but there's a small charge for alterations.
/// Bram
Re: Bug report : Spell checking doesn't know about HTML entities
Bram Moolenaar wrote: Tony Mechelynck wrote: In languages using accented letters, the Vim spell checker doesn't recognise HTML entities (in HTML text): for example, the letters outside of the ...; entities are highlighted as spellBad (after :set spell spelllang=fr) in the following French words: ougrave; meaning: où (where) apregrave;s après (after) ceacute;reacute;monie cérémonie (ceremony) courrouccedil;a courrouça ([he] angered) deacute;sespeacute;reacute; désespéré (desperate) neacute;cessairenécessaire (necessary) anneacute;e année (year) etc. They are perfectly valid French words, if one takes into account the following equivalences: ugrave; = ù egrave; = è eacute; = é ccedil; = ç etc. I don't know how to solve the problem; maybe an interpretation layer to resolve the entities between the HTML text and the French (or other non-English language) dictionary? Well, words with HTML things in them are NOT French words. Why don't you use utf-8 encoded HTML? I started that particular site some years ago, in 7-bit ASCII plus entities. I'm loath to change it now, and risk making it incompatible with some older browsers. It already holds quite a bit of text. I disagree with the statement that these words are not French words. In an HTML file, where HTML syntax must be taken into account, they are. If you really want to recognize these words, you could take the French dictionary, do a global replace and build a spell file from that. Actually, I don't use spell (I am blessed with a good sense of orthography); but I wondered if there couldn't (someday) be a solution for people who don't share the same blessing. The proposed solution would mean creating an additional spell file, slightly larger than the French dictionary, for use only with HTML text. I'm not convinced of such a solution's viability, especially since it would have to be repeated for German, Swedish, Turkish, Polish, etc., etc., etc. Maybe even for words like risqué and garçon in English. You'll have to check if using and ; in the middle of a word is causing trouble. Adding them to word characters will probably create different problems. The semicolon can also mean a semicolon, which is a punctuation mark and not a word character, and can be used as such after a word with no intervening space (or with nbsp; preceding it, depending on typesetting conventions). The case of the ampersand is simpler: to obtain a true ampersand in the rendered text, one must use one of amp; (symbolic entity) #38; (decimal entity) or #x26; (hex entity) in the HTML. Best regards, Tony.
Re: Bug report : Spell checking doesn't know about HTML entities
François Pinard wrote: [Bram Moolenar] Tony Mechelynck wrote: In languages using accented letters, the Vim spell checker doesn't recognise HTML entities (in HTML text) [...] You'll have to check if using and ; in the middle of a word is causing trouble. Adding them to word characters will probably create different problems. Character entities come from the old time people were still trying to salvage the 8th bit of each byte, on communication channels, to convey byte parity. And also, whatever justification people may invent, to protect their laziness about using tools able to do more than ASCII. They also bypass compatibility problems for users who have to upload HTML pages to servers where they don't master the headers which will be sent with the HTML. (Yes, now I know about the BOM and the META HTTP-EQUIV=Content-Type tag, but the former isn't mentioned and the latter is only mentioned but not explained, in the books I have about HTML.) Even now, email channels aren't guaranteed do be able to convey 8-bit text other than by downgrading it to 7-bit by means of conversion schemes like quoted-printable or base64: some servers are 8-bit-compliant, others still aren't. In the email I get, I sometimes notice that the body has been autoconverted between 8-bit, quoted-printable and base64 by my ISP's routers, with no obviously apparent rule to such behaviour. One property of character entities which is apparently not so well known (or maybe that property was withdrawn since then) is that the semicolon is optional. It is only mandatory where ambiguity would otherwise arise (for example, when a letter follows, a fairly common case after all). That property is not part of the present rules; it is obsolete and deprecated: ce n'est pas la règle, c'est une tolérance. It is only recognised for downward compatibility; IIUC, it does not apply to XHTML. The semicolon has of course always been mandatory when the entity is immediately followed by a letter or semicolon (or by a digit, but that is rarer). I presume that if software (or people) generating HTML were sparing those semicolons wherever they may be spared, a lot of other software would break, we would get a riot against people following standards :-). I suppose that's why the most recent standards require the semicolons. Best regards, Tony. -- Everything is worth precisely as much as a belch, the difference being that a belch is more satisfying. -- Ingmar Bergman
Bug report : Spell checking doesn't know about HTML entities
In languages using accented letters, the Vim spell checker doesn't recognise HTML entities (in HTML text): for example, the letters outside of the ...; entities are highlighted as spellBad (after :set spell spelllang=fr) in the following French words: ougrave; meaning: où (where) apregrave;s après (after) ceacute;reacute;monie cérémonie (ceremony) courrouccedil;a courrouça ([he] angered) deacute;sespeacute;reacute; désespéré (desperate) neacute;cessairenécessaire (necessary) anneacute;e année (year) etc. They are perfectly valid French words, if one takes into account the following equivalences: ugrave; = ù egrave; = è eacute; = é ccedil; = ç etc. I don't know how to solve the problem; maybe an interpretation layer to resolve the entities between the HTML text and the French (or other non-English language) dictionary? Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 131. You challenge authority and society by portnuking people
Re: Bug report : Spell checking doesn't know about HTML entities
Tony Mechelynck wrote: In languages using accented letters, the Vim spell checker doesn't recognise HTML entities (in HTML text): for example, the letters outside of the ...; entities are highlighted as spellBad (after :set spell spelllang=fr) in the following French words: ougrave; meaning: où (where) apregrave;s après (after) ceacute;reacute;monie cérémonie (ceremony) courrouccedil;a courrouça ([he] angered) deacute;sespeacute;reacute; désespéré (desperate) neacute;cessairenécessaire (necessary) anneacute;e année (year) etc. They are perfectly valid French words, if one takes into account the following equivalences: ugrave; = ù egrave; = è eacute; = é ccedil; = ç etc. I don't know how to solve the problem; maybe an interpretation layer to resolve the entities between the HTML text and the French (or other non-English language) dictionary? Well, words with HTML things in them are NOT French words. Why don't you use utf-8 encoded HTML? If you really want to recognize these words, you could take the French dictionary, do a global replace and build a spell file from that. You'll have to check if using and ; in the middle of a word is causing trouble. Adding them to word characters will probably create different problems. -- The Law of VIM: For each member b of the possible behaviour space B of program P, there exists a finite time t before which at least one user u in the total user space U of program P will request b becomes a member of the allowed behaviour space B' (B' = B). In other words: Sooner or later everyone wants everything as an option. -- Vince Negri /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Bug report : Spell checking doesn't know about HTML entities
[Bram Moolenar] Tony Mechelynck wrote: In languages using accented letters, the Vim spell checker doesn't recognise HTML entities (in HTML text) [...] You'll have to check if using and ; in the middle of a word is causing trouble. Adding them to word characters will probably create different problems. Character entities come from the old time people were still trying to salvage the 8th bit of each byte, on communication channels, to convey byte parity. And also, whatever justification people may invent, to protect their laziness about using tools able to do more than ASCII. One property of character entities which is apparently not so well known (or maybe that property was withdrawn since then) is that the semicolon is optional. It is only mandatory where ambiguity would otherwise arise (for example, when a letter follows, a fairly common case after all). I presume that if software (or people) generating HTML were sparing those semicolons wherever they may be spared, a lot of other software would break, we would get a riot against people following standards :-). -- François Pinard http://pinard.progiciels-bpi.ca
BUG? line('A) always returns line number in all the files
Reproducible: Always
Steps to reproduce:
1. Place an uppercase mark A in file aa.c;
2. use :echo line('A), it will display the correct line number;
3. change to another file, execute :echo line('A), it will display the line
number too.
Actual result:
See above.
Expected result:
In a file other than the uppercase mark placed, line() should return 0, as
vim 6.3 behaved.
Additional info:
1. Vim version
:version
VIM - Vi IMproved 7.0 (2006 May 7, compiled Mar 20 2007 16:42:33)
Included patches: 1-219
Normal version with GTK2 GUI. Features included (+) or not (-):
-arabic +autocmd +balloon_eval +browse +builtin_terms +byte_offset
+cindent +clientserver +clipboard +cmdline_compl +cmdline_hist
+cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con_gui
+diff +digraphs +dnd -ebcdic -emacs_tags +eval +ex_extra +extra_search
-farsi +file_in_path +find_in_path +folding -footer +fork() -gettext
-hangul_input +iconv +insert_expand +jumplist -keymap -langmap
+libcall
+linebreak +lispindent +listcmds +localmap +menu +mksession
+modify_fname +mouse +mouseshape -mouse_dec +mouse_gpm -mouse_jsbterm
-mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme
+netbeans_intg -osfiletype +path_extra -perl +postscript +printer
-profile
-python +quickfix +reltime -rightleft -ruby +scrollbind +signs
+smartindent -sniff +statusline -sun_workshop +syntax +tag_binary
+tag_old_static -tag_any_white -tcl +terminfo +termresponse
+textobjects +title +toolbar +user_commands +vertsplit +virtualedit
+visual
+visualextra +viminfo +vreplace +wildignore +wildmenu +windows
+writebackup +X11 -xfontset +xim +xsmp_interact +xterm_clipboard
-xterm_save
system vimrc file: $VIM/vimrc
user vimrc file: $HOME/.vimrc
user exrc file: $HOME/.exrc
system gvimrc file: $VIM/gvimrc
user gvimrc file: $HOME/.gvimrc
system menu file: $VIMRUNTIME/menu.vim
fall-back for $VIM: /home/easwy/share/vim
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/gtk-2.0
-I/usr/lib/g
tk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0
-I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/freetype2/config
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O2
-fno-strength-reduce -Wall -I/usr/X11R6/include
Linking: gcc -L/usr/X11R6/lib -L/usr/local/lib -o vim
-Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
-lgdk_pixbuf-2.0 -lm -l
pangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0
-lglib-2.0 -lXt -lncurses -lacl -lgpm
Press ENTER or type command to continue
Re: BUG? line('A) always returns line number in all the files
Easwy Yang wrote:
Reproducible: Always
Steps to reproduce:
1. Place an uppercase mark A in file aa.c;
2. use :echo line('A), it will display the correct line number;
3. change to another file, execute :echo line('A), it will display the line
number too.
Actual result:
See above.
Expected result:
In a file other than the uppercase mark placed, line() should return 0, as
vim 6.3 behaved.
This is actually documented. The idea is that you can use line('A) to
check if the mark 'A is set. To find out what buffer the mark refers to
use the getpos() function.
--
ARTHUR: Listen, old crone! Unless you tell us where we can buy a shrubbery,
my friend and I will ... we will say Ni!
CRONE: Do your worst!
Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
Fwd: BUG? line('A) always returns line number in all the files
Sorry for sending to Bram's private mail address.
Here's my original mail.
-- Forwarded message --
From: Easwy Yang [EMAIL PROTECTED]
Date: 2007-3-21 上午9:19
Subject: Re: BUG? line('A) always returns line number in all the files
To: Bram Moolenaar [EMAIL PROTECTED]
Yes, it is! Sorry for the misinformation.
BTW, there's a mistake in the document, about col() function, the line
To get the line number use |col()|.
^^^
should be
To get the line number use |line()|.
2007/3/20, Bram Moolenaar [EMAIL PROTECTED]:
Easwy Yang wrote:
Reproducible: Always
Steps to reproduce:
1. Place an uppercase mark A in file aa.c;
2. use :echo line('A), it will display the correct line number;
3. change to another file, execute :echo line('A), it will display the line
number too.
Actual result:
See above.
Expected result:
In a file other than the uppercase mark placed, line() should return 0, as
vim 6.3 behaved.
This is actually documented. The idea is that you can use line('A) to
check if the mark 'A is set. To find out what buffer the mark refers to
use the getpos() function.
--
ARTHUR: Listen, old crone! Unless you tell us where we can buy a shrubbery,
my friend and I will ... we will say Ni!
CRONE: Do your worst!
Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
[BUG] vimball changes global 'modifiable' setting
Opening a vimball in Vim sets 'nomodifiable' not only locally but also
globally: henceforward, all new [No Name] buffers opened in the same session
will be created with 'nomodifiable' set.
Workaround: Use :set modifiable in the first [No Name] buffer created after
opening a vimball.
Fix: See suggested patch, attached.
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
121. You ask for e-mail adresses instead of telephone numbers.
*** /usr/local/share/vim/vim70/plugin/vimballPlugin.vim Fri Mar 16 00:34:04 2007
--- /usr/local/share/vim/vimfiles/plugin/vimballPlugin.vim Sat Mar 17 09:07:46 2007
***
*** 27,33
com! -na=0 VimballList call vimball#Vimball(0)
com! -na=* -complete=dir RmVimball call vimball#RmVimball(f-args)
au BufEnter *.vba.gz,*.vba.bz2,*.vba.zip call vimball#Decompress(expand(amatch))
! au BufEnter *.vba set noma bt=nofile fmr=[[[,]]] fdm=marker|call vimball#ShowMesg(0,Source this file to extract it! (:so %))
=
Restoration And Modelines: {{{1
--- 27,33
com! -na=0 VimballList call vimball#Vimball(0)
com! -na=* -complete=dir RmVimball call vimball#RmVimball(f-args)
au BufEnter *.vba.gz,*.vba.bz2,*.vba.zip call vimball#Decompress(expand(amatch))
! au BufEnter *.vba setlocal noma bt=nofile fmr=[[[,]]] fdm=marker|call vimball#ShowMesg(0,Source this file to extract it! (:so %))
=
Restoration And Modelines: {{{1
Re: [BUG] vimball changes global 'modifiable' setting
A.J.Mechelynck wrote: Opening a vimball in Vim sets 'nomodifiable' not only locally but also globally: henceforward, all new [No Name] buffers opened in the same session will be created with 'nomodifiable' set. Workaround: Use :set modifiable in the first [No Name] buffer created after opening a vimball. Fix: See suggested patch, attached. Best regards, Tony. P.S. I think the autocommand in the modified line can be moved from the BufEnter event to the BufReadPost event. Best regards, Tony. -- The United States Army; 194 years of proud service, unhampered by progress.
Re: [BUG] vimball changes global 'modifiable' setting
Quoting A.J.Mechelynck [EMAIL PROTECTED]: Opening a vimball in Vim sets 'nomodifiable' not only locally but also globally: henceforward, all new [No Name] buffers opened in the same session will be created with 'nomodifiable' set. Workaround: Use :set modifiable in the first [No Name] buffer created after opening a vimball. Fix: See suggested patch, attached. Seems a harmless enough patch -- I'll include it! Chip Campbell
Re: BUG? :tab wincmd ] doesn't open a new tab
Bram Moolenaar wrote: Tony Mechelynck wrote: Ctrl-W ] (or :wincmd ] ) splits the window to show the definition of the tag under the cursor, but prefixing it with :tab doesn't open a new tab: Reproducible: Always Steps to reproduce: 1. Place the cursor on a tag (e.g. on an identifier in a program for which ctags has been run). 2. Type either :tab wincmd ] or :tab exe norm \C-W] Actual result: The (first) file containing the tag definition is opened in a split window. Expected result: The file should have been opened in a new tab Right. It's not difficult to make this work. Vim 7.0.216 now opens a new tab for :tab wincmd ] but not for any of :tab exe norm \C-W] :exe tab norm \C-W] :tab norm ^W] (using Ctrl-V Ctrl-W to enter the latter): all three split the current window without changing tabs. Is this intended behaviour? If it is, then I guess doc/tabpage.txt (2006 Nov 18) should be modified near line 77 to mention that :tab also doesn't work with :normal (in addition to :diffsplit and :diffpatch). Best regards, Tony. -- Paul Revere was a tattle-tale
Re: BUG? :tab wincmd ] doesn't open a new tab
Tony Mechelynck wrote: Ctrl-W ] (or :wincmd ] ) splits the window to show the definition of the tag under the cursor, but prefixing it with :tab doesn't open a new tab: Reproducible: Always Steps to reproduce: 1. Place the cursor on a tag (e.g. on an identifier in a program for which ctags has been run). 2. Type either :tab wincmd ] or :tab exe norm \C-W] Actual result: The (first) file containing the tag definition is opened in a split window. Expected result: The file should have been opened in a new tab Right. It's not difficult to make this work. Vim 7.0.216 now opens a new tab for :tab wincmd ] but not for any of :tab exe norm \C-W] :exe tab norm \C-W] :tab norm ^W] (using Ctrl-V Ctrl-W to enter the latter): all three split the current window without changing tabs. Is this intended behaviour? If it is, then I guess doc/tabpage.txt (2006 Nov 18) should be modified near line 77 to mention that :tab also doesn't work with :normal (in addition to :diffsplit and :diffpatch). :tab should work in the same places as :vertical. I'll add a remark for these split-window modifiers that they don't work for :execute and :normal. -- Yah, well, we had to carve our electrons out of driftwood we'd find. In the winter. Uphill. Both ways. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
BUG? :tab wincmd ] doesn't open a new tab
Ctrl-W ] (or :wincmd ] ) splits the window to show the definition of the tag under the cursor, but prefixing it with :tab doesn't open a new tab: Reproducible: Always Steps to reproduce: 1. Place the cursor on a tag (e.g. on an identifier in a program for which ctags has been run). 2. Type either :tab wincmd ] or :tab exe norm \C-W] Actual result: The (first) file containing the tag definition is opened in a split window. Expected result: The file should have been opened in a new tab Additional info: 1. Workaround: :exe tab stag expand(cword) 2. Vim version VIM - Vi IMproved 7.0 (2006 May 7, compiled Mar 8 2007 18:29:45) Included patches: 1-214 Compiled by [EMAIL PROTECTED] Huge version with GTK2-GNOME GUI. Features included (+) or not (-): +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra +perl +postscript +printer +profile +python +quickfix +reltime +rightleft +ruby +scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white +tcl +terminfo +termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim +xsmp_interact +xterm_clipboard -xterm_save (etc.) Best regards, Tony. -- I call them as I see them. If I can't see them, I make them up. -- Biff Barf
RE: bug: gvim 7.0.205 on xp can not display ucs-2
What gets displayed? Does this happen on gVim as well? Do Chinese characters appear correctly in the console window when using other programs? -Original Message- From: Mike Li [mailto:[EMAIL PROTECTED] Sent: Monday, March 05, 2007 10:04 PM To: vim-dev@vim.org Subject: Re: bug: gvim 7.0.205 on xp can not display ucs-2 console vim 7.0 (patches 1-205), built with the mingw compiler under cygwin (gcc -mno-cygwin), as well as the console vim 7.0.122 binary distributed with cygwin have the same problem as the gvim binaries under windows xp. -x On 3/5/07, Mike Li [EMAIL PROTECTED] wrote: gvim 7.0 (patches 1-205) under windows xp, built with the mingw compiler under cygwin (gcc -mno-cygwin), can not display ucs-2 text files. see below for the xxd-dump of an ucs-2 text file containing a single chinese character (U+6c38): 000: 6c 38 00 0d 00 0al8 the same problem is seen with the little-endian (ucs-2le) version of the same file: 000: 38 6c 0d 00 0a 008l the presence or absence of a BOM (byte order marker) at the beginning of the file does not make a difference. the issue is also seen with gvim from the original windows binary distribution. console vim 7.0 (patches 1-205) under fedora core 6, built with gcc 4.0, works fine with '++enc=ucs-2'. the original binary from the yum package vim-enhanced-7.0.201-1.fc6 also works fine. -x
Re: bug: gvim 7.0.205 on xp can not display ucs-2
for big-endian, the following is displayed: [EMAIL PROTECTED]@ for little-endian, the following is displayed: 8l^M^@ ^@ ^@ and ^M are control characters. this definitely happens on gvim as well as console vim under windows xp. i'm not sure if it happens with other programs in the console window, as the platform is windows. i have the appropriate fonts, and notepad displays the little-endian version correctly. -x On 3/6/07, Doug Cook [EMAIL PROTECTED] wrote: What gets displayed? Does this happen on gVim as well? Do Chinese characters appear correctly in the console window when using other programs? -Original Message- From: Mike Li [mailto:[EMAIL PROTECTED] Sent: Monday, March 05, 2007 10:04 PM To: vim-dev@vim.org Subject: Re: bug: gvim 7.0.205 on xp can not display ucs-2 console vim 7.0 (patches 1-205), built with the mingw compiler under cygwin (gcc -mno-cygwin), as well as the console vim 7.0.122 binary distributed with cygwin have the same problem as the gvim binaries under windows xp. -x On 3/5/07, Mike Li [EMAIL PROTECTED] wrote: gvim 7.0 (patches 1-205) under windows xp, built with the mingw compiler under cygwin (gcc -mno-cygwin), can not display ucs-2 text files. see below for the xxd-dump of an ucs-2 text file containing a single chinese character (U+6c38): 000: 6c 38 00 0d 00 0al8 the same problem is seen with the little-endian (ucs-2le) version of the same file: 000: 38 6c 0d 00 0a 008l the presence or absence of a BOM (byte order marker) at the beginning of the file does not make a difference. the issue is also seen with gvim from the original windows binary distribution. console vim 7.0 (patches 1-205) under fedora core 6, built with gcc 4.0, works fine with '++enc=ucs-2'. the original binary from the yum package vim-enhanced-7.0.201-1.fc6 also works fine. -x
Re: bug: gvim 7.0.205 on xp can not display ucs-2
one point of clarification: the correcly functioning fedora console vim binaries were run under x11 (rxvt-unicode) with appropriate truetype fonts. -x On 3/5/07, Mike Li [EMAIL PROTECTED] wrote: gvim 7.0 (patches 1-205) under windows xp, built with the mingw compiler under cygwin (gcc -mno-cygwin), can not display ucs-2 text files. see below for the xxd-dump of an ucs-2 text file containing a single chinese character (U+6c38): 000: 6c 38 00 0d 00 0al8 the same problem is seen with the little-endian (ucs-2le) version of the same file: 000: 38 6c 0d 00 0a 008l the presence or absence of a BOM (byte order marker) at the beginning of the file does not make a difference. the issue is also seen with gvim from the original windows binary distribution. console vim 7.0 (patches 1-205) under fedora core 6, built with gcc 4.0, works fine with '++enc=ucs-2'. the original binary from the yum package vim-enhanced-7.0.201-1.fc6 also works fine. -x
Re: bug: gvim 7.0.205 on xp can not display ucs-2
one more update: if i add the following two lines to my _vimrc, then the ucs-2le text file works: set fileencodings+=ucs-2le set encoding=utf-8 note that both need to be set before i edit the file. once i load the file, setting them no longer helps. -x On 3/6/07, Mike Li [EMAIL PROTECTED] wrote: one point of clarification: the correcly functioning fedora console vim binaries were run under x11 (rxvt-unicode) with appropriate truetype fonts. -x On 3/5/07, Mike Li [EMAIL PROTECTED] wrote: gvim 7.0 (patches 1-205) under windows xp, built with the mingw compiler under cygwin (gcc -mno-cygwin), can not display ucs-2 text files. see below for the xxd-dump of an ucs-2 text file containing a single chinese character (U+6c38): 000: 6c 38 00 0d 00 0al8 the same problem is seen with the little-endian (ucs-2le) version of the same file: 000: 38 6c 0d 00 0a 008l the presence or absence of a BOM (byte order marker) at the beginning of the file does not make a difference. the issue is also seen with gvim from the original windows binary distribution. console vim 7.0 (patches 1-205) under fedora core 6, built with gcc 4.0, works fine with '++enc=ucs-2'. the original binary from the yum package vim-enhanced-7.0.201-1.fc6 also works fine. -x
Re: bug: gvim 7.0.205 on xp can not display ucs-2
Mike Li wrote: one more update: if i add the following two lines to my _vimrc, then the ucs-2le text file works: set fileencodings+=ucs-2le set encoding=utf-8 note that both need to be set before i edit the file. once i load the file, setting them no longer helps. -x Of course: - Vim needs to be able to represent Unicode codepoints in memory (:set encoding=utf-8). This must be done before any attempt to read the file. - Vim needs to know how to detect the encoding. This can be done in several ways: * if 'fileencodings' *begins* with ucs-bom, any Unicode encoding with BOM will be recognised. * if you use :e ++enc=ucs-2be filename, the file will be interpreted according to big-endian UCS-2 * if 'fileencodings' contains ucs-2le, and anything preceding it checks invalid for that file, then the file will be read as little-endian UCS-2 if it contains no invalid bytes for that encoding. Of course, if you change 'fileencodings' after the file has been read, it is too late. You also need to set a font containing the glyphs for whatever codepoints you'll want to see. This is not a trivial problem in multilingual file: e.g., I know no fixed-width font having both Chinese and Arabic glyphs. Setting the font is done in gvim by means of the 'guifont' option; console Vim uses whatever font is set by the hardware text console or by the software terminal emulator. See: :help 'encoding' :help 'fileencodings' :help ++opt :help mbyte.txt :help 'guifont' Best regards, Tony. -- Did you know that there are 71.9 acres of nipple tissue in the U.S.?
RE: bug: gvim 7.0.205 on xp can not display ucs-2
Using gVim, if I load your file normally, I do get ASCII instead of Unicode. But if I then type: :e ++enc=ucs-2 it appears to work. I don't have a Chinese font, so I get a box, but it is a single character and it is double-width, so it appears to be interpreted correctly by Vim. The same thing happens automatically if I insert the UCS-2 byte order mark fe ff at the start of the file. The console version is a bit more tricky, and correct behavior from Vim might depend on various system settings. In my case, the console version reports a conversion error. -Original Message- From: Mike Li [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 06, 2007 1:53 AM To: Doug Cook Cc: vim-dev@vim.org Subject: Re: bug: gvim 7.0.205 on xp can not display ucs-2 for big-endian, the following is displayed: [EMAIL PROTECTED]@ for little-endian, the following is displayed: 8l^M^@ ^@ ^@ and ^M are control characters. this definitely happens on gvim as well as console vim under windows xp. i'm not sure if it happens with other programs in the console window, as the platform is windows. i have the appropriate fonts, and notepad displays the little-endian version correctly. -x On 3/6/07, Doug Cook [EMAIL PROTECTED] wrote: What gets displayed? Does this happen on gVim as well? Do Chinese characters appear correctly in the console window when using other programs? -Original Message- From: Mike Li [mailto:[EMAIL PROTECTED] Sent: Monday, March 05, 2007 10:04 PM To: vim-dev@vim.org Subject: Re: bug: gvim 7.0.205 on xp can not display ucs-2 console vim 7.0 (patches 1-205), built with the mingw compiler under cygwin (gcc -mno-cygwin), as well as the console vim 7.0.122 binary distributed with cygwin have the same problem as the gvim binaries under windows xp. -x On 3/5/07, Mike Li [EMAIL PROTECTED] wrote: gvim 7.0 (patches 1-205) under windows xp, built with the mingw compiler under cygwin (gcc -mno-cygwin), can not display ucs-2 text files. see below for the xxd-dump of an ucs-2 text file containing a single chinese character (U+6c38): 000: 6c 38 00 0d 00 0al8 the same problem is seen with the little-endian (ucs-2le) version of the same file: 000: 38 6c 0d 00 0a 008l the presence or absence of a BOM (byte order marker) at the beginning of the file does not make a difference. the issue is also seen with gvim from the original windows binary distribution. console vim 7.0 (patches 1-205) under fedora core 6, built with gcc 4.0, works fine with '++enc=ucs-2'. the original binary from the yum package vim-enhanced-7.0.201-1.fc6 also works fine. -x
Re: bug: gvim 7.0.205 on xp can not display ucs-2
much thanks to Doug and A.J. -- i now see that it wasn't a bug at all. sorry for the noise. -x On 3/6/07, Doug Cook [EMAIL PROTECTED] wrote: Using gVim, if I load your file normally, I do get ASCII instead of Unicode. But if I then type: :e ++enc=ucs-2 it appears to work. I don't have a Chinese font, so I get a box, but it is a single character and it is double-width, so it appears to be interpreted correctly by Vim. The same thing happens automatically if I insert the UCS-2 byte order mark fe ff at the start of the file. The console version is a bit more tricky, and correct behavior from Vim might depend on various system settings. In my case, the console version reports a conversion error. -Original Message- From: Mike Li [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 06, 2007 1:53 AM To: Doug Cook Cc: vim-dev@vim.org Subject: Re: bug: gvim 7.0.205 on xp can not display ucs-2 for big-endian, the following is displayed: [EMAIL PROTECTED]@ for little-endian, the following is displayed: 8l^M^@ ^@ ^@ and ^M are control characters. this definitely happens on gvim as well as console vim under windows xp. i'm not sure if it happens with other programs in the console window, as the platform is windows. i have the appropriate fonts, and notepad displays the little-endian version correctly. -x On 3/6/07, Doug Cook [EMAIL PROTECTED] wrote: What gets displayed? Does this happen on gVim as well? Do Chinese characters appear correctly in the console window when using other programs? -Original Message- From: Mike Li [mailto:[EMAIL PROTECTED] Sent: Monday, March 05, 2007 10:04 PM To: vim-dev@vim.org Subject: Re: bug: gvim 7.0.205 on xp can not display ucs-2 console vim 7.0 (patches 1-205), built with the mingw compiler under cygwin (gcc -mno-cygwin), as well as the console vim 7.0.122 binary distributed with cygwin have the same problem as the gvim binaries under windows xp. -x On 3/5/07, Mike Li [EMAIL PROTECTED] wrote: gvim 7.0 (patches 1-205) under windows xp, built with the mingw compiler under cygwin (gcc -mno-cygwin), can not display ucs-2 text files. see below for the xxd-dump of an ucs-2 text file containing a single chinese character (U+6c38): 000: 6c 38 00 0d 00 0al8 the same problem is seen with the little-endian (ucs-2le) version of the same file: 000: 38 6c 0d 00 0a 008l the presence or absence of a BOM (byte order marker) at the beginning of the file does not make a difference. the issue is also seen with gvim from the original windows binary distribution. console vim 7.0 (patches 1-205) under fedora core 6, built with gcc 4.0, works fine with '++enc=ucs-2'. the original binary from the yum package vim-enhanced-7.0.201-1.fc6 also works fine. -x
bug: gvim 7.0.205 on xp can not display ucs-2
gvim 7.0 (patches 1-205) under windows xp, built with the mingw compiler under cygwin (gcc -mno-cygwin), can not display ucs-2 text files. see below for the xxd-dump of an ucs-2 text file containing a single chinese character (U+6c38): 000: 6c 38 00 0d 00 0al8 the same problem is seen with the little-endian (ucs-2le) version of the same file: 000: 38 6c 0d 00 0a 008l the presence or absence of a BOM (byte order marker) at the beginning of the file does not make a difference. the issue is also seen with gvim from the original windows binary distribution. console vim 7.0 (patches 1-205) under fedora core 6, built with gcc 4.0, works fine with '++enc=ucs-2'. the original binary from the yum package vim-enhanced-7.0.201-1.fc6 also works fine. -x
Re: bug: gvim 7.0.205 on xp can not display ucs-2
console vim 7.0 (patches 1-205), built with the mingw compiler under cygwin (gcc -mno-cygwin), as well as the console vim 7.0.122 binary distributed with cygwin have the same problem as the gvim binaries under windows xp. -x On 3/5/07, Mike Li [EMAIL PROTECTED] wrote: gvim 7.0 (patches 1-205) under windows xp, built with the mingw compiler under cygwin (gcc -mno-cygwin), can not display ucs-2 text files. see below for the xxd-dump of an ucs-2 text file containing a single chinese character (U+6c38): 000: 6c 38 00 0d 00 0al8 the same problem is seen with the little-endian (ucs-2le) version of the same file: 000: 38 6c 0d 00 0a 008l the presence or absence of a BOM (byte order marker) at the beginning of the file does not make a difference. the issue is also seen with gvim from the original windows binary distribution. console vim 7.0 (patches 1-205) under fedora core 6, built with gcc 4.0, works fine with '++enc=ucs-2'. the original binary from the yum package vim-enhanced-7.0.201-1.fc6 also works fine. -x
Re: Bug report: mapping fails with a few characters (i.e.: « :imap ’ foo » fails)
2007/3/2, A.J.Mechelynck [EMAIL PROTECTED]: Mapping seems to be buggy with some characters. For instance: :imap ' foo does not work (the apostrophe is U+2019). What is 'encoding' set to? Using multibyte characters (e.g. in a mapping) will only work if 'encoding' (which defines how characters are represented internally in Vim memory) is set to an appropriate multibyte setting beforehand The encoding is set to utf-8. My point is, mapping works with some multibyte characters, but not all of them. For example: :imap ∀ foo ... that is, mapping the forall symbol (U+2200), works. Since I can map some multibyte characters, there is in my opinion no issue with the encoding. The question is: why is it possible to map U+2200 but not U+2019? Regards, thomas
Re: Bug report: mapping fails with a few characters (i.e.: « :imap ’ foo » fails)
thomas wrote: 2007/3/2, A.J.Mechelynck [EMAIL PROTECTED]: Mapping seems to be buggy with some characters. For instance: :imap ' foo does not work (the apostrophe is U+2019). What is 'encoding' set to? Using multibyte characters (e.g. in a mapping) will only work if 'encoding' (which defines how characters are represented internally in Vim memory) is set to an appropriate multibyte setting beforehand The encoding is set to utf-8. My point is, mapping works with some multibyte characters, but not all of them. For example: :imap ∀ foo ... that is, mapping the forall symbol (U+2200), works. Since I can map some multibyte characters, there is in my opinion no issue with the encoding. The question is: why is it possible to map U+2200 but not U+2019? Regards, thomas Hm. It just might be a bug, but Bram would be better able than me to check this. I can map Char-0x2019 but I cannot really test that it works (I can just see that it is represented correctly in the list of mappings), because that character is not on my keyboard. U+2019 is encoded as E2 80 99 while U+2200 is E2 88 80. I wonder if the presence of a 0x80 in the middle might cause a bug in gvim. Did you try the code snippet in my previous post? If it works, then we can start digging why your previous method didn't work. If it doesn't, we should have a clear-cut testcase for others to try and reproduce. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 80. At parties, you introduce your spouse as your service provider.
Re: Bug report: mapping fails wit h a few characters (i.e.: « :im ap ’ foo » fails)
Bram Moolenaar wrote:
[...]
How can you tell if the mapping works or not?
You can see what a key actually produces with CTRL-V key . So when
you type
:imap CTRL-V key foo
Where CTRL-V is one key and key is the mapped key.
Does the mapping still not work?
When I type
:map! “ -
where the {lhs}, U+201C (double high 6 quote) is produced on my keyboard by
AltGr-v
then,
:map!
list the mapping with “ (the character in question) in the {lhs}, but hitting
AltGr-v in Insert mode inserts “ (the {lhs}) not - (the {rhs}).
Using Ctrl-V before the key when defining the mapping makes no change: hitting
the key still doesn't invoke the mapping, but :map! “ (again, with or
without Ctrl-V) lists it.
Best regards,
Tony.
--
The grand leap of the whale up the Fall of Niagara is esteemed, by all
who have seen it, as one of the finest spectacles in nature.
-- Benjamin Franklin.
Re: Bug: :confirm w only works once
Die von Ihnen genutzte eMail-Adresse ([EMAIL PROTECTED]) existiert nicht oder existiert nicht mehr.
Re: Bug: :confirm w only works once
Michael Schaap wrote: When editing a read-only file, :confirm w only works the first time you use it in a session. The second time you try to use it, you simply get an error message, as if you didn't use :confirm. The same problem occurs when using :set confirm. To recreate: $ echo Hello hello.txt $ chmod 400 hello.txt $ vim -u NONE hello.txt :set nocompatible or you won't be able to overwrite at all A, WorldEsc :confirm w 'readonly' option is set for qq. Do you wish to write anyway? (Y)es, [N]o: y A!Esc :confirm w E505: qq is read-only (add ! to override) This is using 7.0.203, but it has been happening for quite a while. An old 6.3 does the same thing. Michael What happens when 'readonly' is set is that the :confirm asks you if you want to override it. If you select yes then it will behave as if you did :w!. If you do the same with 'readonly' off you don't get the prompt, but writing fails for :w, only :w! works. Note that when 'readonly' is set then :w results in E45, while a read-only file gives E505. They are two different things, but both are overruled with :w!. We don't have a separate ! for each situation. Perhaps the E505 should also trigger :confirm w to ask for writing anyway. That's more difficult, but would be what you expect. -- hundred-and-one symptoms of being an internet addict: 222. You send more than 20 personal e-mails a day. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
BUG: nested syntax regions and tranparent
G'day folks,
In the following sample string:
{pre{contained}post}
the right brace after contained is not highlighted when using these
syntax commands.
syn region foo1 matchgroup=foo2 start={ end=} contains=foo3
syn region foo3 start={ end=} transparent contained
hi def link foo1 Constant
hi def link foo2 Delimiter
Vim 6 seems to exhibit the correct behaviour.
Regards,
Doug
Re: Bug? in vimgrep with g flag and long lines.
Tony Mechelynck wrote: When cycling through matches using :cnext, if there are several matches in a single long line, the line is only shortened the first time (but _not_ the 2nd, 3rd, etc.,) to avoid a Hit-Enter prompt. Reproducible: every time. Steps to reproduce: 1. :set wrap I'm not sure this is necessary 2. :vimgrep /pattern/g filename where: - filename is a file or files with a number of lines longer than 'cmdheight' times 'columns' - /pattern/ will happen more than once in some long lines 3. :cn 4. Go to step 3. Notice that the first match in any given line never produces a Hit-enter prompt. Too-long lines have part of their non-matching text replaced by Actual result: 2nd, 3rd, etc. matches in any given line produces a Hit-enter prompt; the line is displayed in full, overflowing the command-line. Expected result: No hit-enter prompts. Additional info: I've been seeing this for as long as I've used :vimgrep (i.e., since shortly after that command was introduced) and I'm still seeing it in gvim 7.0.201. I just never came around to report it. (I didn't use the quickfix commands much before :vimgrep appeared, except for :helpgrep where lines are shorter than 80 characters.) This works as intended. It's a compromise between shortening the message, to avoid the press-enter prompt, and being able to see the whole message. The idea is that after jumping to a line with :cnext you can do :cc to see the whole message. It's implemented in a way that when displaying the same line twice the second time it displays the whole line. -- hundred-and-one symptoms of being an internet addict: 191. You rate eating establishments not by the quality of the food, but by the availability of electrical outlets for your PowerBook. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: BUG: nested syntax regions and tranparent
Doug Kearns wrote:
In the following sample string:
{pre{contained}post}
the right brace after contained is not highlighted when using these
syntax commands.
syn region foo1 matchgroup=foo2 start={ end=} contains=foo3
syn region foo3 start={ end=} transparent contained
hi def link foo1 Constant
hi def link foo2 Delimiter
Vim 6 seems to exhibit the correct behaviour.
I can reproduce it. One more for the todo list...
--
% cat /usr/include/sys/errno.h
#define EPERM 1 /* Operation not permitted */
#define ENOENT 2 /* No such file or directory */
#define ESRCH 3 /* No such process */
[...]
#define EMACS 666 /* Too many macros */
%
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
Bug? in vimgrep with g flag and long lines.
When cycling through matches using :cnext, if there are several matches in a single long line, the line is only shortened the first time (but _not_ the 2nd, 3rd, etc.,) to avoid a Hit-Enter prompt. Reproducible: every time. Steps to reproduce: 1. :set wrap I'm not sure this is necessary 2. :vimgrep /pattern/g filename where: - filename is a file or files with a number of lines longer than 'cmdheight' times 'columns' - /pattern/ will happen more than once in some long lines 3. :cn 4. Go to step 3. Notice that the first match in any given line never produces a Hit-enter prompt. Too-long lines have part of their non-matching text replaced by Actual result: 2nd, 3rd, etc. matches in any given line produces a Hit-enter prompt; the line is displayed in full, overflowing the command-line. Expected result: No hit-enter prompts. Additional info: I've been seeing this for as long as I've used :vimgrep (i.e., since shortly after that command was introduced) and I'm still seeing it in gvim 7.0.201. I just never came around to report it. (I didn't use the quickfix commands much before :vimgrep appeared, except for :helpgrep where lines are shorter than 80 characters.) Best regards, Tony. -- I'm going to Boston to see my doctor. He's a very sick man. -- Fred Allen
Re: bug? abbreviate does not work properly gvim-70d02
On Apr 13, 2006, at 11:30 AM, Andre Massing wrote: Andre Massing schrieb: Benji Fisher schrieb: On Thu, Apr 13, 2006 at 02:50:28PM +0200, André Massing wrote: Hi All, I defined an abbrevation :ab NK Newton-Kaskade , but to my surprise this abbrevation is not expanded in Insert Mode after typing Space, (but was expanded with Tab or Esc.) Actually it works properly only if I use iab NK Newton-Kaskade. This phenomena only occurs when I use gvim7 but neither in a terminal vim7 nor in any (gui or non-gui) prior version of vim (6.4.7). Is this a bug in gvim7? I cannot confirm this. Did you check for conflicting abbreviations and trailing spaces in the :ab command? HTH --Benji Fisher Yes I did, there were no other abbrevations and no trailing spaces. Actually I realizied that some problems occur with my settings if I load an old session via source. Last time when I started with an old sessin, my textwidth were not recognized and although set tw? showed me the assigned value, vim did not break any line automatically. But it broke lines with the gq command. Starting a new gvim7, everything worked fine (tw, abbrevations and so on). That seems rather strange to me. Any suggestions how I could investigate this problem since this phenomena prevents me from using sessions and forces me to remember and reopen all my files I had worked on (which is sometimes quite hard for me :-) ) Best wishes Andre Okay, now I realized that there is no connection with my sourced session but rather with some (LaTeX) files. So simply loading a (special) LaTeX File breaks some settings (both in vim and gvim, version 6 and 7). Andre Hello, I have been suffering from similar frustrations, being unable to utilize my abbreviations within Latex. Were you by any chance able to resolve this? Any clue as to what is necessary to fix it? Thanks! Brent
[BUG] gvim doesn't allow Alt keybindings
Hi, we have a bug report that keybindings with Alt does not work in gvim if the X input method is enabled: Testcase :set wak=no # disable keybindings for the menu :tabnew :map M-1 1gt :map M-2 2gt This should allow you to switch with Alt-1 and Alt-2 between tabs, but this does not work. The workaround is to disable X input method (with :set imdisable). Then it works. Maybe there's some relation to http://bugzilla.gnome.org/show_bug.cgi?id=331369. In the code it seems that GtkEventKey-state field has set Meta1 correctly. So the code in (vim) gui_gtk_x11.c:key_press_event() seems to be the cause. Regards, Matthias
Re: [BUG] gvim doesn't allow Alt keybindings
Matthias Koenig wrote: we have a bug report that keybindings with Alt does not work in gvim if the X input method is enabled: Testcase :set wak=no # disable keybindings for the menu :tabnew :map M-1 1gt :map M-2 2gt This should allow you to switch with Alt-1 and Alt-2 between tabs, but this does not work. The workaround is to disable X input method (with :set imdisable). Then it works. Maybe there's some relation to http://bugzilla.gnome.org/show_bug.cgi?id=331369. In the code it seems that GtkEventKey-state field has set Meta1 correctly. So the code in (vim) gui_gtk_x11.c:key_press_event() seems to be the cause. This may depend on the kind of input method that you are using. You seem to be able to get the key event. Perhaps you can step through the code to see what the difference is between the input method being on and off. -- hundred-and-one symptoms of being an internet addict: 145. You e-mail your boss, informing him you'll be late. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: bug: commandline not visible after :tabedit in maximized window
Vaclav wrote: [Bram, sorry for sending to your personal address by accident for the first time] What system? If Unix: what GUI? Sorry for not mentioning that. I am running the gnome GUI on Linux. I double-checked on a different machine to exclude the influence of the breakindent patch that is also applied. It seems that it works differently with Metacity WM than with the Xfce window manager (running the same program locally is different from running it remotely); also, the machine with Metacity is xinerama-doublehead, which may make some bugs in the WM code show up. I will install a clean version here and try to determine if it is really a vim bug. I assume you are using GTK then. If you use GTK + Gnome then try recompiling Vim without Gnome. The Gnome libraries introduce some problems. The window manager may do things that Vim can't handle. Whether that's the fault of the window manager or Vim is hard to decide. -- Nobody will ever need more than 640 kB RAM. -- Bill Gates, 1983 Windows 98 requires 16 MB RAM. -- Bill Gates, 1999 Logical conclusion: Nobody will ever need Windows 98. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: bug: commandline not visible after :tabedit in maximized window
[Bram, sorry for sending to your personal address by accident for the first time] What system? If Unix: what GUI? Sorry for not mentioning that. I am running the gnome GUI on Linux. I double-checked on a different machine to exclude the influence of the breakindent patch that is also applied. It seems that it works differently with Metacity WM than with the Xfce window manager (running the same program locally is different from running it remotely); also, the machine with Metacity is xinerama-doublehead, which may make some bugs in the WM code show up. I will install a clean version here and try to determine if it is really a vim bug. Regards, Vaclav
Resize bug (Was: html post)
John Doe wrote: I am sorry for my html post. Anyway I can reproduce the resizing bug on my system by doing: set lines=999 columns=999 twice in a row. Strange. Once I do that, gvim starts behaving strangely -- and very slowly. I don't see ex-commands I type (as if they were off-screen); what I see is my first window (with its statusline) and a couple of lines of the second window where the command-line ought to be. gvim starts using a lot of CPU time for several seconds (competing with Firefox which for some reason usually uses most). Then with the following :set lines=9 columns=9 :redir! vim.log :set lines? columns? :redir END followed in bash by cat vim.log I see two blank lines, then lines=1000 columns=1 which are the compiled-in maxima. The only way to make gvim behave normally seems to be clicking the maximize button once (maximizing the application), after what :set lines? columns? replies with sensible values of lines=37 columns=166 :qa and restart gvim: it starts up maximized with the intro screen. :set lines? columns? replies lines=37 Last set from ~/.vimrc columns=166 Last set from ~/.vimrc which is normal since my vimrc includes if has(gui_running) set lines=9 columns=9 endif and if ! verbose au VimEnter * set verbose=1 au VimLeave * set verbose=0 endif Then doing :set lines=9 columns=9 exhibits the strange behaviour avain: gvim behaves sluggishly, shows neither the bottom status line nor the command line, the command-line area is replaced by text from one of the edit files, and the right end of the status line is squeezed at the left, displaying (with a split window and a custom status line) [No Name] [utf-8,BOM] 0,0-1[0=0x00] All instead of dilating it somewhat like [No Name][utf-8,BOM] 0,0-1[0=0x00] All which would be normal, or just [No Name] which would be normal if gvim really believed it had ten thousand columns on which to draw. Now: :set lines=37 columns=166 Gvim redraws, albeit slowly (takes maybe half a second to display all the tildes for lines in the empty file) and the display looks normal again, with all status lines displayed where they belong, and All Top Bot or nn% flush at the right screen margin. Trying :set lines=9 columns=9 in kvim 6.2.14 (for comparison) exhibits different behaviour: after several seconds of intense processing, a blank window is displayed with a small scrollbar (three lines or so) at top left, all keys beep, and finally a SIGSEGV crash. (The same line in the vimrc is handled correctly, resulting in 37 lines and 142 columns, with the same font [9pt SUSE Sans Mono] but drawn slightly wider and somewhat prettier with Qt than with the GTK2 used by gvim and Thunderbird.) I think it's a bug. Workaround: :set lines=25 columns=80 lines=9 columns=9 (not needed in the vimrc). The display behaves weirdly with resizes and scrolls for a second or so, but the end result is a correct maximized display even if it already was so beforehand. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 16. You step out of your room and realize that your parents have moved and you don't have a clue when it happened.
vim/cscope interface bug
Folks,
Vim 6.4/7.0 can't show result of cscope find f name correctly.
E.g.
1 1 Makefile unknown
2 1 arch/Makefile unknown
h
3 1 arch/README unknown
4 1 arch/evbsh5/Makefile unknown
Ã~mts5
5 1 arch/evbsh5/compile/Makefile unknown
°
6 1 arch/evbsh5/conf/CAYMAN unknown
7 1 arch/evbsh5/conf/CAYMAN64 unknown
8 1 arch/evbsh5/conf/SIMULATOR unknown
^]Ãh
9 1 arch/evbsh5/conf/files.evbsh5 unknown
10 1 arch/evbsh5/conf/majors.evbsh5 unknown
^]ÃÃ~
11 1 arch/evbsh5/conf/std.evbsh5.eb unknown
Fix:
--- vim70-old/src/if_cscope.c 2006-11-09 15:17:47.0 -0600
+++ vim70/src/if_cscope.c 2006-11-09 15:21:16.0 -0600
@@ -1923,14 +1923,8 @@
if ((fname = strtok(NULL, (const char *)\t)) == NULL)
continue;
if ((lno = strtok(NULL, (const char *)\t)) == NULL)
- {
- /* if NULL, then no extra, although in cscope's case, there
-* should always be extra.
-*/
- extra = NULL;
- }
-
- extra = lno + strlen(lno) + 1;
+ continue;
+ extra = strtok(NULL, (const char *));
lno[strlen(lno)-2] = '\0'; /* ignore ; at the end */
Re: [BUG] Conversion error on write when 'autowriteall' is set causes infinite recursion
Nikolai Weibull wrote: Test case: vim -c 'e ++enc=latin1 a.test | exec normal! i\C-Vu2026 | set autowriteall | q' And make sure 'encoding' is utf-8. Yes, I can reproduce it. One more item for the todo list... -- hundred-and-one symptoms of being an internet addict: 39. You move into a new house and decide to Netscape before you landscape. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Bug with --remote-tab-silent
Alexei Alexandrov wrote: Hi Bram et al., here is a rather strange bug. It seems to be specific for Windows and only when I try to open *.exe or *.dll file (yes, it's strange but sometimes I use it). If I open an *.exe file with gvim bjam.exe it opens just fine. But if I open it with gvim --remote-tab-silent bjam.exe command, I get error message E479: No match. The problem reproduces even if bjam.exe file doesn't exist. Exe or dll files are usually binaries (which shouldn't cause E479 however); and unlike cmd.exe when executing them, Vim doesn't lookup the PATH for editfiles. 1) Are you sure the directory containing the editfile was current? If it wasn't, you should mention the path to the file on the command-line. 2) If the file's dir was current, try using gvim --remote-tab-silent +set bin bjam.exe Note: The Vim help is not very explicit: I'm not sure if the additional parameter should be +set bin +set bin or +set\ bin If one of them doesn't set 'binary', try another variant. Best regards, Tony.
Re: Bug with --remote-tab-silent
Hi Bram Moolenaar, you wrote: I can't reproduce it. It could be caused by a plugin. Does adding -V10 show some context of the error? Does anyone else see this? Not sure if my previous message reached the list: the bug is reproducible only if the extension of the file is in 'wildignore' -- Alexei Alexandrov
Re: Bug with --remote-tab-silent
Hi A.J.Mechelynck, you wrote: Exe or dll files are usually binaries (which shouldn't cause E479 however); and unlike cmd.exe when executing them, Vim doesn't lookup the PATH for editfiles. 1) Are you sure the directory containing the editfile was current? If it wasn't, you should mention the path to the file on the command-line. 2) If the file's dir was current, try using gvim --remote-tab-silent +set bin bjam.exe Note: The Vim help is not very explicit: I'm not sure if the additional parameter should be +set bin +set bin or +set\ bin If one of them doesn't set 'binary', try another variant. The key in the bug report is that error is reproducible only with --remote-tab-silent. I'm not sure why the advices above can have different behavior with this option. -- Alexei Alexandrov
Re: Bug with --remote-tab-silent
Alexei Alexandrov wrote: On 1/17/07, Bram Moolenaar [EMAIL PROTECTED] wrote: I can't reproduce it. It could be caused by a plugin. Does adding -V10 show some context of the error? Does anyone else see this? It reproduces only when the extension of the file is added into 'wildignore'. In my .vimrc I have set wildignore=*.o,*.obj,*.exe,*.lib,*.a,*.dll,*.swp,*.ncb,*.aps,*.opt,*.pdb,*.bak,*~,*.d and the bug can be reproduced for any of these extensions. And only with --remote-tab-silent. OK, I can reproduce it now. I have *.pyc in 'wildignore' and editing foo.pyc causes the error message in the remote gvim with --remote-tab and --remote-tab-silent. What is worse: with --remote it crashes. I'll look into it. -- Micro$oft: where do you want to go today? Linux: where do you want to go tomorrow? FreeBSD: are you guys coming, or what? /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Bug with --remote-tab-silent
Bram Moolenaar wrote:
Alexei Alexandrov wrote:
On 1/17/07, Bram Moolenaar [EMAIL PROTECTED] wrote:
I can't reproduce it. It could be caused by a plugin.
Does adding -V10 show some context of the error?
Does anyone else see this?
It reproduces only when the extension of the file is added into
'wildignore'. In my .vimrc I have
set
wildignore=*.o,*.obj,*.exe,*.lib,*.a,*.dll,*.swp,*.ncb,*.aps,*.opt,*.pdb,*.bak,*~,*.d
and the bug can be reproduced for any of these extensions. And only
with --remote-tab-silent.
OK, I can reproduce it now. I have *.pyc in 'wildignore' and editing
foo.pyc causes the error message in the remote gvim with --remote-tab
and --remote-tab-silent. What is worse: with --remote it crashes.
I'll look into it.
I've only looked into it for a bit, but if you start Vim with a command
line argument (eg. gvim /tmp/foo.txt) You don't get the crash with
--remote. If you start it without one (eg. gvim ) then it crashes.
This appears to be caused by
buf = buflist_findnr(ARGLIST[0].ae_fnum);
in ex_drop at ex_cmds.c:6984
I'm not familiar with Vim's source at all, but it looks like ARGLIST is
empty
(gdb) print (curwin)-w_alist-al_ga
$3 = {ga_len = 0, ga_maxlen = 0, ga_itemsize = 8, ga_growsize = 5,
ga_data = 0x0}
Todd
Re: Bug in non-gui vim 7.0-178: Command line expansion for emenu doesn't work for menu entries containing a period.
Thomas Link wrote:
set nocompatible
set wildmenu
amenu test.etc\..1 :echo 1cr
emenu test.{press tab}
This presents no possible completion in vim, but correctly shows the
submenu in gvim.
It works fine for me. Could there be something else that matters?
I tried this with the terminal version on linux windows (compiled with
GUI=no) and it didn't work when invoking vim as vim -u NONE. It
works when running gvim (@ winxp) though.
I first noticed this problem already some time ago when I first tried
the :emenu command because I happen to have some custom functions listed
in a tml.Vim\ etc\. submenu.
I can still execute the menu entry when I know the name, but command
line completion doesn't work -- which is somewhat bad because I put
stuff into the menu I use so seldomn that there isn't use in remembering it.
I tried again, but can't reproduce it. I run vim -u NONE, source the
three lines and type :emenu test.Tab. Result is
:emenu test.etc\... Another Tab adds the 1.
--
How To Keep A Healthy Level Of Insanity:
15. Five days in advance, tell your friends you can't attend their
party because you're not in the mood.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
Bug in non-gui vim 7.0-178: Command line expansion for emenu doesn't work for menu entries containing a period.
Hi,
In the following, command line expansion works in gvim but not in vim:
set nocompatible
set wildmenu
amenu test.etc\..1 :echo 1cr
emenu test.{press tab}
This presents no possible completion in vim, but correctly shows the
submenu in gvim.
Regards,
Thomas.
Re: Bug in non-gui vim 7.0-178: Command line expansion for emenu doesn't work for menu entries containing a period.
Thomas wrote:
In the following, command line expansion works in gvim but not in vim:
set nocompatible
set wildmenu
amenu test.etc\..1 :echo 1cr
emenu test.{press tab}
This presents no possible completion in vim, but correctly shows the
submenu in gvim.
It works fine for me. Could there be something else that matters?
--
How To Keep A Healthy Level Of Insanity:
13. Go to a poetry recital and ask why the poems don't rhyme.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
