Re: Bug: Gvim window resizes during save with :w
Jochen Baier wrote: hi, i have weird behavior here (latest svn gvim, linux, Gnome or Wmii) if i save with :w the window change the size to larger size (5 pixel) for moment then it size back to the orginal size. The left scrollbar is visible during this. no problems with normal konsole vim. is this bug known ? regards jochen Strange. 1. What are the first lines (until and including Features included (+) or not (-)) output by the :version command? To copy them to the clipboard, use the following (on gvim for X11): :redir @* :version :redir END :let @+ = @* Then paste the clipboard into your mailer, and remove the part starting with either +arabic or -arabic. 2. Immediately after experiencing the strange behaviour, without waiting, try :verbose set guioptions? What is the output? If a script name is mentioned, maybe that script temporarily sets the left scrollbar on (that's the l flag in 'guioptions', q.v.). Best regards, Tony.
[Fwd: Re: I just updated my Vim site]
Hi Steve, I got the attached email privately. I believe it is meant for you. Best regards, Tony. ---BeginMessage--- A.J.Mechelynck wrote: And even if someday you do understand RPM (used by RedHat and SuSE), you'll still have to figure out dpkg (for Debian) and what-not... I have compiled gvim on my SuSE system and found the process remarkably easy. But it'd be much easier to make a deb as someone in Debian already maintains one: http://packages.qa.debian.org/c/cream.html The package description (from Ubuntu, but it's the same for Debian essentially): Package: cream Priority: optional Section: universe/editors Installed-Size: 2904 Maintainer: Christoph Haas [EMAIL PROTECTED] Architecture: all Version: 0.33.1-1 Depends: vim (= 1:6.2), gvim | kvim, ucf Filename: pool/universe/c/cream/cream_0.33.1-1_all.deb Size: 844946 MD5sum: d848a0b33614f63eb838793924c8d96e Description: VIM macros that make the VIM easier to use for beginners Cream's motto is Cream makes the powerful Vim text editor easy!. It brings a completely different look and feel to the VIM for those who are used to more intuitive editors while still preservering the more powerful features of VIM. It features pull-down menus, color themes, bookmarking, auto spellcheck and more. It leaves the default VIM untouched and is started by running 'cream'. See also: http://cream.sf.net Bugs: mailto:[EMAIL PROTECTED] Origin: Ubuntu So, talk to [EMAIL PROTECTED] if you need help packaging it. You might not even need to package it as he'll happily continue doing it along with whatever else he packages. signature.asc Description: OpenPGP digital signature ---End Message---
incorrect behavior of gzip.vim plugin?
I was following Chip Campbell's advice in the vim list to download v100 of the netrw plugin when I discovered the following undesirable behavior of the gzip.vim plugin. I downloaded netrw.vba.gz, then opened it with view netrw.vba.gz and saw the following messages at the bottom of the screen: netrw.vba.gz [readonly][noeol] 260L, 67511C ~/.vim/netrw.vba [readonly] 7156L, 274745C Source this file to extract it! (:so %) Press ENTER or type command to continue I took a brief look at the file, then closed vim with :q When I did an 'ls' of the directory, I discovered that netrw.vba.gz had been replaced by netrw.vba! I didn't want to unzip the file, only look at it. I believe this is an error in the behavior of the gzip.vim script. Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: incorrect behavior of gzip.vim plugin?
Gary Johnson wrote: I was following Chip Campbell's advice in the vim list to download v100 of the netrw plugin when I discovered the following undesirable behavior of the gzip.vim plugin. I downloaded netrw.vba.gz, then opened it with view netrw.vba.gz and saw the following messages at the bottom of the screen: netrw.vba.gz [readonly][noeol] 260L, 67511C ~/.vim/netrw.vba [readonly] 7156L, 274745C Source this file to extract it! (:so %) Press ENTER or type command to continue I took a brief look at the file, then closed vim with :q When I did an 'ls' of the directory, I discovered that netrw.vba.gz had been replaced by netrw.vba! I didn't want to unzip the file, only look at it. I believe this is an error in the behavior of the gzip.vim script. The problem here is :so % doesn't source the buffer, it sources the underlying file. Thus the file must needs be gunzip'ed first. Vimball could be set up not to gunzip the file, but then sourcing it would fail. Regards, Chip Campbell
Re: incorrect behavior of gzip.vim plugin?
Charles E Campbell Jr wrote: [...] The problem here is :so % doesn't source the buffer, it sources the underlying file. Thus the file must needs be gunzip'ed first. Vimball could be set up not to gunzip the file, but then sourcing it would fail. Regards, Chip Campbell Looking at the vimball plugin, I notice it always unpacks into directories of the first (existing) directory in 'runtimepath'. That is, into ~/.vim/something or ~/vimfiles/something if they exist. The description (at vim-online) of the netrw plugin also recommends to remove the version under $VIMRUNTIME. This has two consequences: - It is not possible to install a vimball (such as a new version of the netrw plugin) system-wide under $VIM/vimfiles unless ~/.vim or ~/vimfiles does not exist. - If the recommendations at vim-online are followed, the netrw functionality (including local directory browsing) will be made unavailable to all users except the one who installed the new version. The above may be intentional but I believe it is a severe drawback. It is admittedly documented under :help :Mkvimball but not under install details at http://vim.sourceforge.net/scripts/script.php?script_id=1075 (where your .vim/ or vimfiles\ directory can be construed as including $VIM/vimfiles); and searching that HTML page for vimball gives a null result so anyone not already knowing about vimballs won't be drawn to the pi_vimball.txt helpfile. Suggestion 1: I suggest to add optional additional parameters to the vimball commands: :MkVimball filename [path] :UseVimball [filename] [path] Maybe even (but perhaps less iimportant) :MkVimball filename [path] [EMAIL PROTECTED] where filelist is a file containing one filename per line, relative to [path] or, by default, to the first existing directory in 'runtimepath'. As a further refinement (I'm thinking aloud here) maybe the result of applying :redir to UseVimball/VimballList could be acceptable too. This would allow: 1) creating a vimball from files located elsewhere than in the first existing directory in 'runtimepath'. The following possible locations come to mind: $VIM/vimfiles (the system-wide non-distribution tree in 'vimruntime') ~/.build/vim/vim70 (a directory tree used to build vim but not necessarily for execution on this machine) /home/myusername/.vim (a Vim directory tree for a different user, e.g. when done from an admin account having implicit +rw permissions everywhere) 2) unpacking a vimball other than the current file and/or to some non-default location. The same locations as above come to mind, and in addition a not-yet-existing ~/.vim or ~/vimfiles 3) by making then unpacking a vimball, copying a series of related vim scripts from one location to another (for instance, from /root/.vim and its subdirectories to the corresponding locations in and under /home/user1/.vim but not to /home/user2/.vim). 4) optionally, keeping a disk record of which files belong to a given project, in a format acceptable to :MkVimball, to streamline the creation of the relevant vimball. A cursory glance at plugin/vimball.vim and autoload/vimball.vim seems to indicate that this suggestion (which, IIUC, wouldn't break existing functionality) wouldn't be too hard to implement, but of course you know those plugins much better than I do. If you want me to suggest a patch, ay so, and I will try. Suggestion 2: I also suggest to explicitly mention vimballs in the vim-online blurbs for vimballed scripts. Best regards, Tony
Documentation bug about matchparen
*pi_paren.txt* For Vim version 7.0. Last change: 2006 Apr 24 line 46 (i.e. 5th from bottom) there is 'synmaxcolumn' there should be 'synmaxcol' Best regards, Tony.
\(an\_s\+\)\@=file
Hello Vim List, \(an\_s\+\)\@=file is the first example in help for \@= Since \_s\+ should find one or more white space characters (including end-of-line characters), why doesn't this match when there is more than one end-of-line in the white space? For example, this doesn't match: an file Substituting \zs for \@= shows what I expected. -- Best regards, Bill
Re: \(an\_s\+\)\@=file
On 6/13/06, Bill McCarthy [EMAIL PROTECTED] wrote: Hello Vim List, \(an\_s\+\)\@=file is the first example in help for \@= Since \_s\+ should find one or more white space characters (including end-of-line characters), why doesn't this match when there is more than one end-of-line in the white space? For example, this doesn't match: an file Substituting \zs for \@= shows what I expected. I confirm this strangeness of \@= Yakov
Textwidth setting Directory Listing
I noticed a problem that occurs whenever I open a file via the Directory listing. Whenever a file is opened via the directory listing it screws up the textwidth settings for all the buffers. I am not sure if it is the directory listing plugin or vim 7 itself that is causing the problem. Even running the set textwidth=78 command doesn't seem to resolve this. Has anyone else noticed this and found a fix for this problem? -jb
Picking nits about 'ballooneval' + 'mousehide'
I'm running gvim 7 under windows xp pro. I like to set 'mousehide' so that the pointer gets out of my way while I'm actually editing text. Recently I started fooling around with the 'ballooneval' feature, and I'd like to be able to make the balloon dissapear when I begin editing, just like the pointer does with 'mousehide' set. I've poked around the docs, and there doesn't seem to be a 'balloonhide' option. Manually setting 'noballooneval' also doesn't seem to make a displayed balloon go away. Does anyone have any ideas as to how I might accomplish this?
Re: gf , isfname and @
Hi, Emmanuel Sixou wrote: I am using vim7. The char @ seems not to be considered as a filename character even though it appears in the isfname set variable, for the commands gf, gF. What's wrong? inside isfname and some other options @ is a placeholder for all characters where isalpha() (i.e., a library function) returns true. Have a look at :help 'isfname' and search for the first @ below the different default values of this option. There you'll find an explanation and how to insert a @ into this option. Regards, Jürgen -- Jürgen Krämer Softwareentwicklung HABEL GmbH Co. KGmailto:[EMAIL PROTECTED] Hinteres Öschle 2 Tel: +49 / 74 61 / 93 53 - 15 78604 Rietheim-WeilheimFax: +49 / 74 61 / 93 53 - 99
Re: Textwidth setting Directory Listing
jbw wrote: I noticed a problem that occurs whenever I open a file via the Directory listing. Whenever a file is opened via the directory listing it screws up the textwidth settings for all the buffers. I am not sure if it is the directory listing plugin or vim 7 itself that is causing the problem. Even running the set textwidth=78 command doesn't seem to resolve this. Has anyone else noticed this and found a fix for this problem? I suspect you're talking about netrw; please download v100 from http://vim.sourceforge.net/scripts/script.php?script_id=1075 I advise removing the installation version of netrw, too. Regards, Chip Campbell
Re: Calling through a function reference with a variable argument list
On 6/12/06, Hari Krishna Dara [EMAIL PROTECTED] wrote:
On Mon, 12 Jun 2006 at 4:07pm, Charles E Campbell Jr wrote:
Bob Hiestand wrote:
On 6/2/06, Charles E Campbell Jr [EMAIL PROTECTED] wrote:
Bob Hiestand wrote:
My question is whether there is a simpler way to pass an unknown
number of arguments from the current function to a function which
accepts a variable-length list of arguments.
...snip...
I don't think that does what I wanted, though I may have misunderstood
the implications. That converts the arguments into a string
representation of a list, which then becomes the single argument to
the second function.
Looks like I made a mistake. Here's one that does illustrate passing a
variable number of arguments along:
--
fun! AFunc(...)
let args = string(a:000)
let len = strlen(args)
let args = strpart(args,1,len-2)
echomsg call BFunc(.args.) a:0=.a:0
exe call BFunc(.args.)
endfun
--
fun! BFunc(...)
echomsg BFunc sees: a:0=.a:0
echomsg a:000.string(a:000).
endfun
--
echomsg 'AFunc(1):'
call AFunc(1)
echomsg 'AFunc(1,a):'
call AFunc(1,a)
echomsg 'AFunc(1,a,b):'
let b=BBB
call AFunc(1,a,b)
The idea is to have a string hold just the arguments, not the list
delimiters.
The exe squeezes the string together and then executes it. Consequently,
the output is:
AFunc(1):
call BFunc(1) a:0=1
BFunc sees: a:0=1
a:000[1]
AFunc(1,a):
call BFunc(1, 'a') a:0=2
BFunc sees: a:0=2
a:000[1, 'a']
AFunc(1,a,b):
call BFunc(1, 'a', 'BBB') a:0=3
BFunc sees: a:0=3
a:000[1, 'a', 'BBB']
P
So you can see that BFunc is being called with a variable number of
arguments depending on whatever AFunc received (look at the
BFunc sees: lines)
I don't know if the OP can use a Vim7.0 only solution, but the genutils
plugin has a utility to make this possible for prior versions. I have
been using this in several places of one of my plugins with no issues.
However, if Vim7.0 only solution is acceptable, Vim supports this
already with the call() function.
--
fun! AFunc(...)
echomsg call BFunc(.string(a:000).) a:0=.a:0
call call('BFunc', a:000)
endfun
--
fun! BFunc(...)
echomsg BFunc sees: a:0=.a:0
echomsg a:000.string(a:000).
endfun
--
HTH,
Hari
My intention was to create a passthrough function that could call any
other function after determining the function to which it would
dispatch control (the application here is a general source integration
script that would dispatch to the appropriate function specific to the
version control system controlling the current file).
As it turns out, I was a victim of narrow thinking because I was
trying to modify as little as possible of an existing plugin. The
correct change was to simply make the dispatch function and the end
functions accept a list as the parameter, in which case pass-through
becomes trivial.
Thank you for looking at this,
You're welcome!
Chip Campbell
Thanks, Hari, that was exactly the functionality I wanted.
Re: R: Vim doesn't open files with chinese file names
On 6/11/06, Wu Yongwei [EMAIL PROTECTED] wrote: On 6/11/06, A.J.Mechelynck [EMAIL PROTECTED] wrote: Cesar Romani wrote: -Messaggio originale- Da: A.J.Mechelynck [mailto:[EMAIL PROTECTED] Inviato: venerdì 9 giugno 2006 23.34 A: Cesar Romani Cc: Vim Oggetto: Re: Vim doesn't open files with chinese file names Cesar Romani wrote: If I have a file with a chinese file name, f.e. 感情包袱.txt It won't open but it throws the message: E303: Unable to open swap file for .txt, recovery impossible Instead with notepad I can open the file. Many thanks in advance, Andalou Is your Vim version compiled with +multi_byte ? (:echo has(multi_byte) should return 1). The multi-byte feature is also mentioned in the :version text as one of +multi_byte, +multi_byte_ime or +multi_byte_ime/dyn If yes, check near the bottom of the :version text the name of the compiler: Vim binaries compiled with BCC32 have been notorious in the past for bad support of multi-byte characters, especially in filenames; IIUC, other compilers such as gcc and (don't remember the compiler executable name) MS Visual C have less problems in that respect. (I could be wrong though; I don't use non-Latin1 filenames and only very rarely non-7-bit-ASCII ones.) If has(multi_byte) is nonzero and it wasn't compiled with BCC32 then I don't know what it is -- maybe a bug. In this case, a makeshift workaround (until Bram fixes it) would be to rename the file back and forth to something with only 7-bit ASCII in the name. Normally, E303 means the swapfile can't be opened; but you should still be able to edit the file itself, unless it is very large. But you won't get a recovery option if Vim crashes, so don't forget to save your work extra often. Oh, and you are using a recent version of Vim aren't you? A year or two ago Vim just couldn't handle filenames with multibyte characters in them, but I thought that bug had been fixed. Best regards, Tony. Thanks for your answer, I use the vim 7.0 compiled with MS Visual C and it has multibyte. echo has(multi_byte) return 1. The file won't be opened and can't be edited even though the file is small. All what I get is an empty file. If I rename the file with ASCII, even with accented file name it will be opened. But notepad can open and edit it. Many thanks in advance, Andalou I now see the problem. You code page is not 936, right? Vim seems only able to open files with names that are valid in the current code page, as are many other applications that do not use the Unicode version of Windows APIs. This is an OS-related issue. You should not have such problems when the system locale uses UTF-8, such as modern Linux distros. One correction. This failure only occurs on the command line. :set encoding=utf-8, and you can open the file with :e successfully. -- Wu Yongwei URL: http://wyw.dcweb.cn/
Re: Vim: Reading from stdin
Hi Mikolaj, I get: Vim: Reading from stdin What happens when you do this: date | /usr/bin/vim -u NONE - Assuming that your vim is installed at /usr/bin/vim. What version of Vim are you using? --Eljay
Re: negative match pattern, again
It follows the general form of a negative line search for embedded search: /^\%(.*[limit0.*]search[.*limit1]\)[EMAIL PROTECTED] For example, to match a line that contains foo but does not contain bar between big and tummy: /\%(.*big.*bar.*tummy\)[EMAIL PROTECTED] Edward Wong wrote: Learn a lot more about regexp from this post. Thanks! Sorry, I missed the ^ anchor: /^\%(.*big.*bar.*tummy\)[EMAIL PROTECTED] Just a question, why it is necessary to have the ^ anchor? Isn't .* already includes the characters start from the beginning of the line? Sorry if I'm asking a stupid one Not a stupid question at all. [EMAIL PROTECTED] and variants are tricky (IMHO). Considering: /^\%(.*big.*bar.*tummy\)[EMAIL PROTECTED] First, big.*bar.*tummy can not match quite often! Just as [EMAIL PROTECTED] ordered. So look at the following two lines: big junk bar junk tummy junk foo junk bar junk tummy junk foo Its best to :set hls first, so as to see what matches. Try matching with and without that leading ^. With the ^, big junk bar junk tummy junk foo-- doesn't match junk bar junk tummy junk foo-- matches which is what one would expect. However, without that ^, the pattern is free to start matching _after_ the start-of-line, and so ig junk bar junk tummy junk foo -- matches junk bar junk tummy junk foo-- matches (I left off the non-matching b in the first line). Thus, both lines match, which isn't what's wanted, especially considering the regexp was expected to be used with :g/regex-here/somecmd Regards, Chip Campbell
Re: Vim: Reading from stdin
On Tue, 13 Jun 2006, John Love-Jensen wrote: Hi Mikolaj, I get: Vim: Reading from stdin What happens when you do this: date | /usr/bin/vim -u NONE - Vim does its job, and after quitting vim I get: [EMAIL PROTECTED] ~ $ date | /usr/bin/vim -u NONE - Vim: Reading from stdin... What version of Vim are you using? :version VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Nov 16 2005 01:53:08) (...) OS is linux (gentoo), terminal is Konsole (from KDE), shell is bash. -- Jorge Almeida
RE: gf , isfname and @
Thanks Emmanuel Sixou Mobileye Vision Technologies Project Manager - ASIC Department Tel: +972 (2) 541 7311 Fax: +972 (2) 541 7300 Cell: +972 (54) 5665 206 E-mail: [EMAIL PROTECTED] -Original Message- From: Jürgen Krämer [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 13, 2006 17:31 To: vim mailing list Subject: Re: gf , isfname and @ Hi, Emmanuel Sixou wrote: I am using vim7. The char @ seems not to be considered as a filename character even though it appears in the isfname set variable, for the commands gf, gF. What's wrong? inside isfname and some other options @ is a placeholder for all characters where isalpha() (i.e., a library function) returns true. Have a look at :help 'isfname' and search for the first @ below the different default values of this option. There you'll find an explanation and how to insert a @ into this option. Regards, Jürgen -- Jürgen Krämer Softwareentwicklung HABEL GmbH Co. KGmailto:[EMAIL PROTECTED] Hinteres Öschle 2 Tel: +49 / 74 61 / 93 53 - 15 78604 Rietheim-WeilheimFax: +49 / 74 61 / 93 53 - 99 smime.p7s Description: S/MIME cryptographic signature
***SPAM*** Error detected while processing function SNR1_BMShow
I use vim 7.0 on Windows XP compiled with MS Visual C. If I do: gvim -u NONE -U NONE -c set verbosefile=C:/vim.log I get: -- Error detected while processing function SNR1_BMShow: line 12: E329: No menu Buffer Error detected while processing function SNR1_BMShow: line 14: E328: Menu only exists in another mode Tear off this menu --- Many thanks in advance, Andalou
Re: Vim: Reading from stdin
Hi Jorge, Vim does its job, and after quitting vim I get: Actually, you are getting the Vim: Reading from stdin... first, and then Vim does it's job. When Vim quits, it restores the screen (available in some termcaps), which includes the prior Vim message that it was reading from stdin. I believe it is possible to change Vim's termination behavior such that it does not restore the screen, rather it does a screen clear or just drops the cursor to the bottom of the screen and exit (keeping the rest of just-quit Vim's screen contents onscreen, except for the top line or two which may scroll off, depending on your PS1 or PROMPT setting). But that's different from the other poster's issue, where Vim would hang (i.e., not do its job). --Eljay
Re: Vim: Reading from stdin
On Tue, 13 Jun 2006, John Love-Jensen wrote: Hi Jorge, Vim does its job, and after quitting vim I get: Actually, you are getting the Vim: Reading from stdin... first, and then Vim does it's job. When Vim quits, it restores the screen (available in some termcaps), which includes the prior Vim message that it was reading from stdin. I believe it is possible to change Vim's termination behavior such that it does not restore the screen, rather it does a screen clear or just drops the cursor to the bottom of the screen and exit (keeping the rest of just-quit Vim's screen contents onscreen, except for the top line or two which may scroll off, depending on your PS1 or PROMPT setting). That would be worse than the message! I don't want the remains of the vim session visible. The problem is the message, which shouldn't be send to sdtin in the first place. Ah, well... But that's different from the other poster's issue, where Vim would hang (i.e., not do its job). I think I didn't receive those mails... --Eljay Thanks, Jorge
Re: Vim: Reading from stdin
Hi Jorge, That would be worse than the message! You should modify the Vim source code so it does not emit the message, and compile your own version. Note: the message is there so it does not appear that your machine is hung if vim is being sent a large amount of input, or a input from a slow pipe. It would be nice if -V0 would suppress the message, but alas. Sincerely, --Eljay
Re: Error detected while processing function SNR1_BMShow
On Tue, Jun 13, 2006 at 05:37:13PM +0200, Cesar Romani wrote: I use vim 7.0 on Windows XP compiled with MS Visual C. If I do: gvim -u NONE -U NONE -c set verbosefile=C:/vim.log I get: -- Error detected while processing function SNR1_BMShow: line 12: E329: No menu Buffer Error detected while processing function SNR1_BMShow: line 14: E328: Menu only exists in another mode Tear off this menu --- Many thanks in advance, Andalou The SNR1_ bit refers to the first script that has been :source'd. Since you started with -u NONE, this will be the first script in your plugin directory. In any event, you can see which script is :source'd first with :scriptnames Check this. I am pretty sure that it will not be one of the plugins from the standard distribution. Look at the plugin and search for the BMShow function. HTH --Benji Fisher
Re: non-latin characters aren't displayed correctly in Windows menu
On 6/13/06, A.J.Mechelynck wrote:
Mojca Miklavec wrote:
On 6/12/06, A.J.Mechelynck wrote:
You must make sure that you have:
- an 'encoding' which includes the non-Latin characters you want to use
- (in console Vim) a terminal code page which includes them
What is that? And console vim if you mean the one without GUI menus
is not always there (I have it one one computer, but not on the
other).
Console Vim is the one without GUI. On Windows a different executable
must be used, usually named vim.exe (or possibly something starting in
vim as in vimd.exe for a debug version etc.); it displays in a Dos
Box. On Unix a single executable can be used as a GUI (through X11) or
as a console version (displaying on /dev/tty or on xterm, konsole, etc.)
depending on how it is invoked.
OK, when I installed the new vim 7, it's there. It wasn't present in
the old 6.4 version, but that's not really important: I (would/will)
never use it anyway.
'guifont' empty means some default system font, such as Fixed. IMHO it
is not he prettiest but if you're satisfied with it you may stay with it.
I don't say that it's the prettiest, but I tried to search for some
better fonts using some suggestions in vim recipes. The problem is
that most fonts mentioned don't support Central European characters.
(And some fonts that I have need to big sizes to be readable. Lucida
Consile is the only other acceptable font that I know/have.) I would
really like to use something else, but I didn't find anything more
suitable yet.
There is a -menufont {font} command-line option, but from where it is
described in the help I fear it is only applicable to X11 (all
Unix/Linux versions and possibly some MacOsX versions). AFAIK the font
used for menus in Windows is common to all applications and thus outside
the reach of gvim. Try the following:
gvim -N -u NONE
:language messages
:set encoding?
Great! Thanks a lot. That did it! [grrr ... I'm so stupid that I
didn't try to remove my _vimrc file before]
I get:
Current messages language: SL
encoding=cp1250
The problem was that I had the following two lines in _vimrc:
set encoding=utf-8 termencoding=cp1250
set fileencodings=ucs-bom,utf-8,cp1250
I don't know how exactly each one influences the behaviour (the second
line was suggested to me on this mailing list some time ago), but I
had to comment out the first one and the problem has gone. I had
numerous problems with utf-8 before adding those lines. For some
strange reason Windows doesn't recognize vim as being able to do
Unicode, so it communicates in an old cp1250 fashion with it. cp1250
is indeed set in the regional settings, but I didn't manage to explain
to Windows that vim can handle utf-8 as well.
OK, I only left
set fileencodings=ucs-bom,utf-8,cp1250
in my _vimrc and the menues seem to be OK now.
But now my second question: if I open some utf-8 file, it opens as
utf-8, which is OK. But when I open a new file and save it, it's saved
in cp1250 unless I type :set encoding=utf-8 before. So, after saying
set encoding=utf-8 the menu stays OK, but if I put that into my
_vimrc, the encoding in menu is broken. Any remedy for it?
Thanks a lot,
Mojca Miklavec
Re: Error detected while processing function SNR1_BMShow
Cesar Romani wrote: I use vim 7.0 on Windows XP compiled with MS Visual C. If I do: gvim -u NONE -U NONE -c set verbosefile=C:/vim.log I get: -- Error detected while processing function SNR1_BMShow: line 12: E329: No menu Buffer Error detected while processing function SNR1_BMShow: line 14: E328: Menu only exists in another mode Tear off this menu --- Many thanks in advance, Andalou The error happened while sourcing the first sourced script (notice SNR1_? That's the value of SID for script #1). Do it again, and, once Vim has started up, check the output of :scriptnames The first line should tell you which script has the offending lines (search it for a function named SIDBMShow or s:BMShow). Notice that the standard Vim menus include a Buffers menu (plural) but no Buffer menu (singular). Best regards, Tony.
Re: ***SPAM*** Error detected while processing function SNR1_BMShow
Mathias Michaelis wrote: Hello Andalou I use vim 7.0 on Windows XP compiled with MS Visual C. If I do: gvim -u NONE -U NONE -c set verbosefile=C:/vim.log I get: -- Error detected while processing function SNR1_BMShow: line 12: E329: No menu Buffer Error detected while processing function SNR1_BMShow: line 14: E328: Menu only exists in another mode Tear off this menu --- I can confirm that behaviour of gvim, but I think it is a feature, not a bug. Typing :scriptnames in the gvim opened like above shows that SNR1_BMShow means the function BMShow() defined in $VIMRUNTIME\menu.vim. Line 12 and line 14 of that function contain the code 12: silent! unmenu Buffers 14: silent! unmenu! Buffers Here, the silent! means that it is expected that something could go wrong, but an error message should not be displayed nor queued in the message history (shown by :messages). :silent is probably not designed to suppress verbose messages, although I can't find that explicitly in the :help :silent With best regards Mathias 'verbosefile' says it's analogous to :redir, and the latter (as mentioned not very clearly under :help :redir) does not filter away silent messages (they are logged but not displayed). I would expect silent messages to be logged to the 'verbosefile' (even though not displayed) when 'verbosefile' is nonempty. However, under :help -u it is said that -u NONE disables vimrc, gvimrc, and all global plugins. If menu.vim was sourced nevertheless, then IIUC the user must have somehow triggered that sourcing. Best regards, Tony.
Re: non-latin characters aren't displayed correctly in Windows menu
Mojca Miklavec wrote:
On 6/13/06, A.J.Mechelynck wrote:
Mojca Miklavec wrote:
On 6/12/06, A.J.Mechelynck wrote:
You must make sure that you have:
- an 'encoding' which includes the non-Latin characters you want
to use
- (in console Vim) a terminal code page which includes them
What is that? And console vim if you mean the one without GUI menus
is not always there (I have it one one computer, but not on the
other).
Console Vim is the one without GUI. On Windows a different executable
must be used, usually named vim.exe (or possibly something starting in
vim as in vimd.exe for a debug version etc.); it displays in a Dos
Box. On Unix a single executable can be used as a GUI (through X11) or
as a console version (displaying on /dev/tty or on xterm, konsole, etc.)
depending on how it is invoked.
OK, when I installed the new vim 7, it's there. It wasn't present in
the old 6.4 version, but that's not really important: I (would/will)
never use it anyway.
'guifont' empty means some default system font, such as Fixed. IMHO it
is not he prettiest but if you're satisfied with it you may stay with
it.
I don't say that it's the prettiest, but I tried to search for some
better fonts using some suggestions in vim recipes. The problem is
that most fonts mentioned don't support Central European characters.
(And some fonts that I have need to big sizes to be readable. Lucida
Consile is the only other acceptable font that I know/have.) I would
really like to use something else, but I didn't find anything more
suitable yet.
Courier_New has a larger variety of glyphs than most other fixed-width
encodings. If Lucida_Console hasn't got the glyphs you need, I recommend
Courier_New.
There is a -menufont {font} command-line option, but from where it is
described in the help I fear it is only applicable to X11 (all
Unix/Linux versions and possibly some MacOsX versions). AFAIK the font
used for menus in Windows is common to all applications and thus outside
the reach of gvim. Try the following:
gvim -N -u NONE
:language messages
:set encoding?
Great! Thanks a lot. That did it! [grrr ... I'm so stupid that I
didn't try to remove my _vimrc file before]
I get:
Current messages language: SL
encoding=cp1250
The problem was that I had the following two lines in _vimrc:
set encoding=utf-8 termencoding=cp1250
This tells gvim to represent the data internally using UTF-8 but to go
on interpreting the data sent by your keyboard according to cp1250 which
is what Windows sends.
set fileencodings=ucs-bom,utf-8,cp1250
This defines the heuristics used by gvim to detect a file's charset when
opening it for editing. They are used from left to right:
- ucs-bom: if the file starts with a BOM, the Unicode encoding
defined by the BOM is used. (The BOM is a prefix of two to four bytes,
different for all Unicode encodings, and the BOM for each encoding is
illegal in all others.) If there is no BOM, then:
- utf-8: if the data in the file is valid for UTF-8, then Vim does
the equivalent of setlocal fileencoding=utf-8. If it is no valid
UTF-8, then:
- cp1250: This is an 8-bit encoding, it cannot return an invalid
signal. If none of the above is recognised, then the file is read
according to the Windows-1250 charset (Windows proprietary charset for
Central Europe).
I don't know how exactly each one influences the behaviour (the second
line was suggested to me on this mailing list some time ago), but I
had to comment out the first one and the problem has gone. I had
numerous problems with utf-8 before adding those lines. For some
strange reason Windows doesn't recognize vim as being able to do
Unicode, so it communicates in an old cp1250 fashion with it. cp1250
is indeed set in the regional settings, but I didn't manage to explain
to Windows that vim can handle utf-8 as well.
OK, I only left
set fileencodings=ucs-bom,utf-8,cp1250
in my _vimrc and the menues seem to be OK now.
With these settings, you will be able to edit cp1250 files; but UTF-8
files containing codepoints not pesent in cp1250 will appear garbled
(Unicode caters for more than 10 million characters, cp1250 has only 256).
But now my second question: if I open some utf-8 file, it opens as
utf-8, which is OK. But when I open a new file and save it, it's saved
in cp1250 unless I type :set encoding=utf-8 before. So, after saying
set encoding=utf-8 the menu stays OK, but if I put that into my
_vimrc, the encoding in menu is broken. Any remedy for it?
Thanks a lot,
Mojca Miklavec
Since your Windows encoding is Windows-1250, I believe it would be more
prudent to write your menufile in cp1250 (and, I suppose, include
cp1250 in its name where there was utf-8).
See :help ++opt about how to set the file's charset manually when
reading or writing.
IMHO you may change 'encoding' after the menus have been set up. For
instance:
source $VIMRUNTIME/vimrc_example.vim
if termencoding ==
set termencoding =
Re: FTDetect
On 2006-06-13, Max Dyckhoff [EMAIL PROTECTED] wrote: I am having some issues with filetype detection stuff. Here is what I am doing, so far as I can see I am doing exactly what it says in the help. 1. I am on Windows, my runtimepath is ~/vimfiles,C:\Program Files\Vim/vimfiles,c:\Progam Files\Vim\vim70, C:\Program Files\Vim/vimfiles/after,~/vimfiles/after The folder ~/vimfiles does not exist. 2. I have :filetype plugin indent on set in my vimrc file. 3. I place a file called wibble.vim in c:\Program Files\Vim/vimfiles/ftdetect which contains the following: if exists(did_load_filetypes) finish endif augroup filetypedetect au! BufRead,BufNewFile *.wibble setfiletype wibblewobble augroup END 4. I open a file called foo.wibble and do :set filetype, it returns filetype=. If I comment out the first three lines of wibble.vim (namely the check on did_load_filetypes) then it works fine. So, am I right in not including the did_load_filetypes check (which :help ftdetect says you should have), or am I doing something wrong elsewhere? There are a number of different methods of doing filetype detection; you have confused two of them. I don't understand exactly how the ftdetect directory works, but :help ftdetect says that if you are going to add filetype detection for a new file type by putting a file in the ftdetect directory, that file should contain _only_ the autocommand, e.g., au BufRead,BufNewFile *.wibble set filetype wibblewobble Note that there is no '!' after the 'au' and the command is set filetype, not setfiletype. Note also that the help entry does say, Note that there is no augroup command, this has already been done when sourcing your file. If, on the other hand, you add filetype detection by creating your own ~/.vim/filetype.vim file, _then_ you would put in that file the commands you used above, i.e., if exists(did_load_filetypes) finish endif augroup filetypedetect au! BufRead,BufNewFile *.wibble setfiletype wibblewobble augroup END HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: Error detected while processing function SNR1_BMShow
Tony, Andalou If I do: gvim -u NONE -U NONE -c set verbosefile=C:/vim.log I get: [...] E329: No menu Buffer [...] I can confirm that behaviour of gvim, but I think it is a feature, not a bug. [...] However, under :help -u it is said that -u NONE disables vimrc, gvimrc, and all global plugins. If menu.vim was sourced nevertheless, then IIUC the user must have somehow triggered that sourcing. Since I can confirm that behaviour of gvim, I am the user :-) I believe that nobody knows the Vim manual better than you, but after seriously studying :help startup :help gui-init I think that -u NONE prevents only the global plugin to be loaded, but do not prevent the initialisation of the graphical user interface, while -U NONE prevents the latter with one exception: The system-wide menu files are sourced. If I verify this with :help -U ,I come to the same conclusion. To prevent gvim from sourcing the menu.vim script, call it like that: gvim -u NONE -U NONE --cmd set guioptions+=M \ -c set verbosefile=vim.log Indeed! Now the error messages within the vim.log file have vanished! This is why I think that the user is innocent ;-) Best regards Mathias
Re: omni completion, calling different types
Dnia poniedziałek, 12 czerwca 2006 19:39, Silent1 napisał: I'm using the omni completion so far on my php scripts and i'm wondering if there are ways i can call different sets of data with different key strokes. You can use 'completefunc' to call different completion script. ctrl-x+ctrl+o will bring up everything and display everything and will open up a preview window that has info if a function is called with parameters. How do i get the menu that comes up to display the parameters as well? They come up in the preview window just fine just wondering if i can see them in the drop down menu. No. For many (most?) built in functins popup menu would be too wide. Also, everytime i start omni completion with ctrl-x+ctrl+o does it research the file again and display everything including the new stuff i may have typed? Part of it. If so is there a quicker way to see functions with the parameters without reloading the file? ctrl+n will bring up functions but will not update the preview window. No. Also is there a way that i can just call php functions with parameters and not see functions/classes/variables in the file i'm editing? Also the reverse say i would like to only see functions/classes/variables in the current file or say just the variables? No. m.
Re: Vim: Reading from stdin
Dnia wtorek, 13 czerwca 2006 17:22, John Love-Jensen napisał: date | /usr/bin/vim -u NONE - Still the same. Vim7.017 m.
Re: FTDetect
Max Dyckhoff wrote:
Thank you for your answers.
See :help ftdetect. The augroup statements are also not necessary.
The variable did_load_filetypes is set to 1 by
$VIMRUNTIME/filetype.vim (at line 10 in the version for Vim 7.0, lat
change May 02). Your script is sourced from line 2166 of the same
file,
i.e., much later.
That was what I was thinking. How does one get C. If your file type can
be detected by the file name. to work (from :help new-filetype) then,
given that my file type can in fact be detected by the filename.
It's not a bug, it's a feature.
As mentioned under :help ftdetect (in the NOTE at line 178 of
filetype.txt for Vim 7.0, last change 2006 Apr 28), your
$VIM/ftdetect/wibble.vim (or, maybe better, wibblewobble.vim) should
only contain the single line
Deliberately named wibble.vim; this is just a test and I wanted to make
sure it wasn't just taking the filetype from the file suffix.
Method 1: Like you did.
-
Create a one-line file named one of
~/.vim/ftdetect/wibblewobble.vim (user-specific on Unix including Linux
and Cygwin)
~/vimfiles/ftdetect/wibblewobble.vim (user-specific on Windows, but not
on Vim for Cygwin)
$VIM/vimfiles/ftdetect/wibblewobble.vim (system-wide on any platform)
and containg just
au BufRead,BufNewFile *.wibble setlocal ft=wibblewobble
(the filename is unimportant but making the same as the filetype avoids
clashes with other future nonstandard filetypes you may want to add,
and it allow detection by more than one extension. For instance,
replacing the line above by
au BufRead,BufNewFile *.wibble,*.wobble setlocal ft-wibblewobble
would use the filetype wibblewobble for all files named either
*.wibble or *.wobble. The directory where the file is placed _is_
important. If the directory you want to use doesn't exist, just create
it using mkdir in the shell or :!mkdir in Vim. (On Windows, but not on
Unix, md can of course be used as a synonym for mkdir.)
Method 2: One centralized ft-detection script.
-
This may be more or less advantageos than Method 1 depending on
circumstances. Here both the name of the file and its directory (one of
three) are rigidly fixed. Again, if the file and/or its directory don't
exist, you may create them. Here are the applicable pathfilenames:
~/.vim/filetype.vim single-user on Unix
~/vimfiles/filetype.vim single-user on Windows
$VIM/vimfiles/filetype.vim system-wide on all platforms
That file consistes of a header, a trailer, and one line per
user-defined filetype in-between. It may also contain any number of
comments (a comment in vim-script language is defined as anything
starting with a double-quote and ending at the end of the line. There
are a few ex-commands which may not be followed by a comment but most of
them, including :set and friends, may. Blank lines are also allowed:
their only role is to improve legibility.
--- Header part --- {{{1
Filetype-detection script for user-defined filetypes
Written by: your name here
Last change: 13 Jun 2006
Don't run this twice
if exists(b:did_load_filetypes)
finish
endif
We do NOT set did_load_filetypes here
because the global filetype.vim must not be inhibited.
augroup filetypedetect
--- Middle part: list of autocommands --- {{{1
au BufRead,BufNewFile *.wibble,*.wobble setf wibblewobble
au BufRead,BufNewFile *.foo,*.bar,*.baz setf foobarbaz
au BufRead,BufNewFile *.foobar setf foobaronly
etc...
--- Trailer part --- {{{1
augroup END
vim: textwidth=0:foldmethod=marker
The |modeline| at the end and the {{{ folding-markers |fold.txt| are
optional but I recommend using them.
Method 3: Combine both of the above.
-
It is also possible to detect some filetypes by mleans of a central
filetype.vim and others by individual ftdetect/*.vim scripts. IMHO the
only reason for this would be if you wrote some of the filetype-plugins
yourself (and detected their respective filetypes centrally), and
downloaded ftplugin/filetype.vim, syntax/filetype.vim,
indent/filetype.vim and ftdetect/filetype.vim from somewhere on the
Web for other filetypes.
Also, it is possible to detect some filetypes system-wide and others
user-privately: the filetype-detection scripts are run in the following
sequence (if one of them is not found, the result is the same as if it
were present but did nothing; where I use a wild card, _all_ scripts
verifying the wildcarded name will be run):
~/.vim/filetype.vim (on Unix) or ~/vimfiles/filetype.vim (on Windows)
$VIM/vimfiles/filetype.vim
$VIMRUNTIME/filetype.vim
~/.vim/ftdetect/*.vim (on Unix) or ~/vimfiles/ftdetect/*.vim (on Windows)
$VIM/vimfiles/ftdetect/*.vim
$VIMRUNTIME/ftdetect/*.vim (which currently doesn't exist but in theory
it could).
IMPORTANT: Never change anything in $VIMRUNTIME or in any of its
subdirectories. The files there are downloaded when installing Vim; any
upgrade may change any of them without warning, and upgrading to a new
release such
Re: I sometimes have to double strike when using gvim7 over Hummingbird Exceed
Hi DrC, et al, On Fri, Jun 02, 2006 at 12:17 PM PDT, Charles E. Campbell, Jr. wrote: ... Text Deleted ... CECJ I suggest narrowing down the problem. CECJ CECJ vim -u NONE -U NONE CECJ CECJ for starters. Then try to source in a minimal file (I believe you CECJ mentioned something about laststatus). CECJ If you get the double strike effect, you've got something that others CECJ have a chance at duplicating, and in particular, CECJ Bram M has a shot at fixing. I've narrowed this down to the minimum configuration that causes a problem for me. It's these two settings: set spell set incsearch If I start vim thusly: % vim -g -u NONE -U NONE --noplugin filename And then source a file with the two above settings--or just set them in the vim session--I start getting the weird behavior in my search line. Again, I see this with my GTK-1 build on Solaris; but not with a Motif or GTK-2 build. Unfortunately for me, I prefer the GTK-1 build because it is so much faster to load than my Motif build. And it doesn't have the font issues like GTK-2. Thanks in advance. Regards, -- Mun
Re: non-latin characters aren't displayed correctly in Windows menu
Mojca Miklavec wrote: On 6/13/06, A.J.Mechelynck wrote: Mojca Miklavec wrote: Courier_New has a larger variety of glyphs than most other fixed-width encodings. If Lucida_Console hasn't got the glyphs you need, I recommend Courier_New. No, Lucide_Console is OK (and Courier_New as well), but on high-resolution they are a bit too thin for my eyes. ... (but that's not the main point of my question anyway) set encoding=utf-8 termencoding=cp1250 This tells gvim to represent the data internally using UTF-8 but to go on interpreting the data sent by your keyboard according to cp1250 which is what Windows sends. set fileencodings=ucs-bom,utf-8,cp1250 This defines the heuristics used by gvim to detect a file's charset when opening it for editing. They are used from left to right: - ucs-bom: if the file starts with a BOM, the Unicode encoding defined by the BOM is used. (The BOM is a prefix of two to four bytes, different for all Unicode encodings, and the BOM for each encoding is illegal in all others.) If there is no BOM, then: - utf-8: if the data in the file is valid for UTF-8, then Vim does the equivalent of setlocal fileencoding=utf-8. If it is no valid UTF-8, then: - cp1250: This is an 8-bit encoding, it cannot return an invalid signal. If none of the above is recognised, then the file is read according to the Windows-1250 charset (Windows proprietary charset for Central Europe). Thanks! OK, I only left set fileencodings=ucs-bom,utf-8,cp1250 in my _vimrc and the menues seem to be OK now. With these settings, you will be able to edit cp1250 files; but UTF-8 files containing codepoints not pesent in cp1250 will appear garbled (Unicode caters for more than 10 million characters, cp1250 has only 256). UTF-8 files are opened properly (which is perfect). It's only for the new files that I have to set encoding manually. That would be pretty cumbersome, since I try to switch to UTF-8 completely anyway and I would most probably keep forgetting to set the proper encoding each time. Since your Windows encoding is Windows-1250, I believe it would be more prudent to write your menufile in cp1250 (and, I suppose, include cp1250 in its name where there was utf-8). I prepared all three variants (cp1250, utf-8 and latin2), but it really doesn't seem to matter to gvim which one I use. If one works, all of them do and if one doesn't, all three fail. See :help ++opt about how to set the file's charset manually when reading or writing. Thank you. That one should be part of the save as and open menu as well. (I try to learn new commands every now and then or when I need to do some repetitive task, but being able to use some standard Windows shortcuts or menu really simplifies everything for non-experts.) It would be great if the user could set the encoding visually. No matter how strange it may sound - I often use Mozilla to check the encoding of arbitrary files. It might be due to the lack of my skills with vim (and due to too many encodings everywhere: one for keyboard, one for file, one for font, one for menu, one for mapping, one for cummunication with operating system ...). (Working with encodings in Mozilla is much more intuitive, but I may not compare it with Vim, which is much more powerful if you know how to use it.) IMHO you may change 'encoding' after the menus have been set up. For instance: source $VIMRUNTIME/vimrc_example.vim if termencoding == set termencoding = encoding endif set encoding=utf-8 fileencodings=ucs-bom,utf-8,cp1250 I believe the following will set 'fileencoding' to cp1250 by default for newly-created files, and set a BOM at the start of newly-created Unicode files setglobal fileencoding=cp1250 bomb The example above didn't work. I was able to say if termencoding == set termencoding = encoding endif (without the '' sign) in which case I get a message window each time when I start gvim, saying that encoding=cp1250. Oops! typo! I should have written let termencoding = encoding But set encoding=utf-8 after that influences the menu and the menu is wrong again, no matter where in _vimrc I set it. Also, the following recipe described under :help menutrans doesn't work: :source $VIMRUNTIME/delmenu.vim :source c:\soft\vim\vim70\lang\menu_sl_si.cp1250.vim :source $VIMRUNTIME/menu.vim I get the English menu instead, even if I additionally set :language messages sl_SI.cp1250 which you suggested (Menus are set up, in your Windows default language and encoding which are SL.cp1250, by the vimrc_example. Do you want to say that vimrc_example sets anything relevat? Because I can't find any font/language/encoding-related commands there. It issues commands (see below) which result in loading the menu structure; the :language messages setting defines in which language the menus will be loaded. If the language looked for isn't found, then English (United States) is used as
Re: Error detected while processing function SNR1_BMShow
Mathias Michaelis wrote:
Tony, Andalou
If I do: gvim -u NONE -U NONE -c set verbosefile=C:/vim.log
I get: [...]
E329: No menu Buffer [...]
I can confirm that behaviour of gvim, but I think it is a feature,
not a bug.
[...]
However, under :help -u it is said that -u NONE disables vimrc,
gvimrc, and all global plugins. If menu.vim was sourced nevertheless,
then IIUC the user must have somehow triggered that sourcing.
Since I can confirm that behaviour of gvim, I am the user :-) I
believe that nobody knows the Vim manual better than you, but after
seriously studying
:help startup
:help gui-init
I think that -u NONE prevents only the global plugin to be loaded,
but do not prevent the initialisation of the graphical user
interface, while -U NONE prevents the latter with one exception: The
system-wide menu files are sourced. If I verify this with
:help -U
,I come to the same conclusion. To prevent gvim from sourcing the
menu.vim script, call it like that:
gvim -u NONE -U NONE --cmd set guioptions+=M \
-c set verbosefile=vim.log
Indeed! Now the error messages within the vim.log file have
vanished! This is why I think that the user is innocent ;-)
Best regards
Mathias
You're saying that no one knows the Vim documentation better than I. I
have studied it assiduously (as, IMHO, any Vim user should do) but I am
by far not the oldest user of Vim on this list. I first knew Vim when
its latest release was 6.1, and there are people here who remember 5.7.
If someone knows the Vim docs better than anyone, I bet it's Bram
Moolenaar. (Flatter not thy brother, it is treason; should thy brother
flatter thee, fear lest he should corrupt thee. How are you trying to
corrupt me? ;-) )
Under :help -u (at lines 431-434 of $VIMRUNTIME/doc/starting.txt for
Vim 7.0, last change 2006 Apr 25):
[...]
When {vimrc} is equal to NONE (all uppercase), all
initializations from files and environment variables are
skipped, including reading the |gvimrc| file when the GUI
starts. Loading plugins is also skipped.
[...]
IOW, -u NONE implies -U NONE
From what I found out answering another user, :filetype on (and its
variations) implicitly loads the menu structure. So if you issued a
:filetype [...] on statement manually, that implicitly loaded the
menus (and issued the incriminated messages, which were intentionally
ignored except for verbose logging, when trying to delete a nonexistent
menu structure).
Otherwise, menu.vim is still sourced, as you noted, at GUI
inistialization time (see :help -U and :help gui-init. The latter
has something which will probably be of interest to you (under :help
buffers-menu):
The system menu file includes a Buffers menu. If you don't want
this, set
the no_buffers_menu variable in your .vimrc (not .gvimrc!):
:let no_buffers_menu = 1
NOTE: Switching on syntax highlighting also loads the menu file, thus
disabling the Buffers menu must be done before :syntax on.
...and, I would add, also before :filetype on or any of its variations.
Best regards,
Tony.
Vim7 auto-downloading spell dictionary
Does the vim7 automatic downloading of a new spellcheck dictionary
work as advertised in :help spellfile.vim? The command in help is:
autocmd SpellFileMissing * call
Download_spell_file(expand('amatch'))
but in spellfile.vim is:
autocmd SpellFileMissing * call spellfile#LoadFile(expand('amatch'))
I was just getting ready to write this feature until I saw it in the
help, but I can't get either to work. (And don't even grep the first
in any runtime file.)
--
Steve Hall [ digitect mindspring com ]
Re: non-latin characters aren't displayed correctly in Windows menu
On 6/14/06, A.J.Mechelynck wrote: In $VIMRUNTIME/vimrc_example.vim for Vim 7.0, last change 2002 Sep 19, at line 56 filetype plugin indent on ... Thanks for all the hints. Using the extensive explanation and after playing with all possible combinations: the most crutial part was setting set termencoding=cp1250 encoding=utf-8 before both syntax on filetype plugin indent on in vimrc_example. I'll play with it and inspect a bit more (looks pretty weired and I would never have come to the clue that termencoding might be important for syntax and highlighting issues) to understand it better. Again: thanks a lot for taking your time, it works like a charm now! Mojca
Re: negative match pattern, again
Very great explanation! Many thanks to Gerald and Chip Campbell. Now I _really_ got it. :) On 6/13/06, Charles E Campbell Jr [EMAIL PROTECTED] wrote: It follows the general form of a negative line search for embedded search: /^\%(.*[limit0.*]search[.*limit1]\)[EMAIL PROTECTED] For example, to match a line that contains foo but does not contain bar between big and tummy: /\%(.*big.*bar.*tummy\)[EMAIL PROTECTED] Edward Wong wrote: Learn a lot more about regexp from this post. Thanks! Sorry, I missed the ^ anchor: /^\%(.*big.*bar.*tummy\)[EMAIL PROTECTED] Just a question, why it is necessary to have the ^ anchor? Isn't .* already includes the characters start from the beginning of the line? Sorry if I'm asking a stupid one Not a stupid question at all. [EMAIL PROTECTED] and variants are tricky (IMHO). Considering: /^\%(.*big.*bar.*tummy\)[EMAIL PROTECTED] First, big.*bar.*tummy can not match quite often! Just as [EMAIL PROTECTED] ordered. So look at the following two lines: big junk bar junk tummy junk foo junk bar junk tummy junk foo Its best to :set hls first, so as to see what matches. Try matching with and without that leading ^. With the ^, big junk bar junk tummy junk foo-- doesn't match junk bar junk tummy junk foo-- matches which is what one would expect. However, without that ^, the pattern is free to start matching _after_ the start-of-line, and so ig junk bar junk tummy junk foo -- matches junk bar junk tummy junk foo-- matches (I left off the non-matching b in the first line). Thus, both lines match, which isn't what's wanted, especially considering the regexp was expected to be used with :g/regex-here/somecmd Regards, Chip Campbell -- Ed
Re: non-latin characters aren't displayed correctly in Windows menu
Mojca Miklavec wrote: On 6/14/06, A.J.Mechelynck wrote: In $VIMRUNTIME/vimrc_example.vim for Vim 7.0, last change 2002 Sep 19, at line 56 filetype plugin indent on ... Thanks for all the hints. Using the extensive explanation and after playing with all possible combinations: the most crutial part was setting set termencoding=cp1250 encoding=utf-8 before both syntax on filetype plugin indent on in vimrc_example. I'll play with it and inspect a bit more (looks pretty weired and I would never have come to the clue that termencoding might be important for syntax and highlighting issues) to understand it better. Again: thanks a lot for taking your time, it works like a charm now! Mojca Well, so much the better if it woks like a charm. Once you understand how best to do it, maybe you should write a tip and publish it at vim-online http://vim.sourceforge.net/. Don't forget to mention pitfalls and alternative methods (such as using 'langmenu'). I don't recommend modifying the vimrc_example (except by copying it to another pathfilename) because: a) if a bug is found in it, a patchlevel upgrade may modify it silently; b) when you upgrade to a Vim version higher than 7.0, the whole $VIMRUNTIME structure will be re-created from scratch under a different name (such as $VIM/vim71 instead of $VIM/vim70). In both cases, any modifications you made into the vimrc_example will be lost (maybe after you've forgotten about them). What I recommend is sourcing the vimrc_example from your own vimrc, with most customizations after it, and maybe a few lines before it if they influence what the vimrc_example does. For instance, I prefer English menus and messages, and I have noticed that to get them even on multilingual Vim, and that on both Windows and Linux, I need the following before sourcing the vimrc_example: if has(unix) language messages C else language messages en endif Anything which doesn't have to go before the vimrc_example should go after it, and many settings must go after it to override it. For instance: filetype indent off overrides the indent part of :filetype plugin indent on set nobackup writebackupoverrides set backup in the vimrc_example etc. 'termencoding' defines how Vim interprets keyboard input in all cases. In console vim but not in the GUI it also tells Vim how the console interface will interpret screen output. In the GUI, screen output is defined by 'encoding' and by the glyphs in the font(s) defined by 'guifont' and, when used (which is seldom necessary), 'guifontset' and 'guifontwide'. Your further experiments may help us all understand how Vim writes to the menu bar. I would expect that when 'termencoding' is empty Vim should fall back to the value of 'encoding' (see :help 'termencoding then scroll to /^\s*When empty/). That would be right until or unless the 'encoding' setting is altered (normally by the vimrc). I notice that the help says 'termencoding' is forcibly set to UTF-8 at GUI startup in the GTK+2 gvim. I wonder why. Does the GTK+2 keyboard interface always use UTF-8? Best regards, Tony.
A question on langmenu setting
I read vim doc, it says: Language to use for menu translation. Tells which file is loaded from the lang directory in 'runtimepath': lang/menu_ . langmenu . .vim (without the spaces). For example, to always use the Dutch menus, no matter what $LANG is set to: :set langmenu=nl_NL.ISO_8859-1 When 'langmenu' is empty, |v:lang| is used. Only normal file name characters can be used, /\*?[| are illegal. If your $LANG is set to a non-English language but you do want to use the English menus: :set langmenu=none This option must be set before loading menus, switching on filetype detection or syntax highlighting. Once the menus are defined setting this option has no effect. But you could do this: :source $VIMRUNTIME/delmenu.vim :set langmenu=de_DE.ISO_8859-1 :source $VIMRUNTIME/menu.vim Warning: This deletes all menus that you defined yourself! I follow its direction, add this script to _vimrc: if has(gui_win32) NT Windows try language messages en finally set langmenu=none endtry endif Now the menu in Vim is not in English, what's wrong with my script? could anyone point it out, thanks. Here is the content of my _vimrc : set nocompatible source $VIMRUNTIME/vimrc_example.vim source $VIMRUNTIME/mswin.vim behave mswin if has(gui_win32) NT Windows try language messages en finally set langmenu=none endtry endif set diffexpr=MyDiff() function MyDiff() let opt = '-a --binary ' if diffopt =~ 'icase' | let opt = opt . '-i ' | endif if diffopt =~ 'iwhite' | let opt = opt . '-b ' | endif let arg1 = v:fname_in if arg1 =~ ' ' | let arg1 = '' . arg1 . '' | endif let arg2 = v:fname_new if arg2 =~ ' ' | let arg2 = '' . arg2 . '' | endif let arg3 = v:fname_out if arg3 =~ ' ' | let arg3 = '' . arg3 . '' | endif let eq = '' if $VIMRUNTIME =~ ' ' if sh =~ '\cmd' let cmd = '' . $VIMRUNTIME . '\diff' let eq = '' else let cmd = substitute($VIMRUNTIME, ' ', ' ', '') . '\diff' endif else let cmd = $VIMRUNTIME . '\diff' endif silent execute '!' . cmd . ' ' . opt . arg1 . ' ' . arg2 . ' ' . arg3 . eq endfunction __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
