Re: Modelines: First Form
On Wed 14-Feb-07 1:30am -0600, A.J.Mechelynck wrote: > Bill McCarthy wrote: >> Most end with a ':' which does not appear to be permitted >> above. > It is. It just adds an empty do-nothing setting at the end. Thanks, Tony, I didn't consider the "do-nothing setting" and didn't read the exception at the bottom for vim: and vi: appearing at the start of the line. -- Best regards, Bill
Re: Modelines: First Form
Bill McCarthy wrote:
Hello Vim Developers,
The help files specifies (see :help modeline):
-
There are two forms of modelines. The first form:
[text]{white}{vi:|vim:|ex:}[white]{options}
[text] any text or empty
{white} at least one blank character ( or )
{vi:|vim:|ex:} the string "vi:", "vim:" or "ex:"
[white] optional white space
{options} a list of option settings, separated with white space or ':',
where each part between ':' is the argument for a ":set"
command
-
Yet most of the distributed help files fail to follow this
format (and are note second form).
Most end with a ':' which does not appear to be permitted
above.
It is. It just adds an empty do-nothing setting at the end.
Others start with 'vim:' without the mandatory white space
preceding it.
As stated in the following help text, the white space is not mandatory before
"vi:" or "vim:" if they start at the left margin. It is still required before
"ex:" to reduce the risk of confusion with "example".
Perhaps the docs should mention that {white} is optional if
[text] is empty - if that is true. And a trailing ':' is
permitted.
It does: Let me quote:
The white space before {vi:|vim:|ex:} is required. This minimizes the chance
that a normal word like "lex:" is caught. There is one exception: "vi:" and
"vim:" can also be at the start of the line (for compatibility with version
3.0). Using "ex:" at the start of the line will be ignored (this could be
short for "example:").
Also, for the second form, the same comment applies to its
{white}. It should also be mentioned that the mandatory ':'
is preceded by [white] (optional white space).
That is implicit: a ":set" command can be followed by any amount of whitespace
before being terminated by a | " or linebreak.
The second form (this is compatible with some versions of Vi):
[text]{white}{vi:|vim:|ex:}[white]se[t] {options}:[text]
[text] any text or empty
{white} at least one blank character ( or )
{vi:|vim:|ex:} the string "vi:", "vim:" or "ex:"
[white] optional white space
se[t] the string "set " or "se " (note the space)
{options} a list of options, separated with white space, which is the
argument for a ":set" command
^
: a colon
[text] any text or empty
My options.txt is the following:
*options.txt* For Vim version 7.0. Last change: 2007 Jan 17
Best regards,
Tony.
--
Am I ranting? I hope so. My ranting gets raves.
Modelines: First Form
Hello Vim Developers,
The help files specifies (see :help modeline):
-
There are two forms of modelines. The first form:
[text]{white}{vi:|vim:|ex:}[white]{options}
[text] any text or empty
{white} at least one blank character ( or )
{vi:|vim:|ex:} the string "vi:", "vim:" or "ex:"
[white] optional white space
{options} a list of option settings, separated with white space or ':',
where each part between ':' is the argument for a ":set"
command
-
Yet most of the distributed help files fail to follow this
format (and are note second form).
Most end with a ':' which does not appear to be permitted
above.
Others start with 'vim:' without the mandatory white space
preceding it.
Perhaps the docs should mention that {white} is optional if
[text] is empty - if that is true. And a trailing ':' is
permitted.
Also, for the second form, the same comment applies to its
{white}. It should also be mentioned that the mandatory ':'
is preceded by [white] (optional white space).
--
Best regards,
Bill
Multiple Opens to Write
Hello Vim Developers, I'm "alpha testing" software for Windows that archives files whenever they are opened for writing. Testing with Gvim, I noticed that the program's log showed multiple "open for write" entries by simply opening a file with Gvim and doing a :wq command. The author of the software wrote: I downloaded Gvim and traced its file writes -- it actually is opening the file for writing *4* times for each save. (Why, I can't begin to imagine, but it's the sort of thing you get when you port between various OS's without redoing the code.) I've made some changes to build 6 so that it will only archive it & log it once, ignoring the duplicates. Why isn't opening the file for writing just once good enough? -- Best regards, Bill
Re: newrw 107 and ':e .'
Bernhard Walle wrote: * A.J.Mechelynck <[EMAIL PROTECTED]> [2007-02-13 01:40]: It's Vim compiled by myself, from no other sources than Bram's official ones (including 192 "official" patches). Yes, that fixes it, but I don't want to have the new version in /usr/ simply because I have not root access on every machine (but my $HOME is everywhere through NFS and NIS). But following in ~/.vimrc helped: source ~/.vim/autoload/netrwSettings.vim source ~/.vim/autoload/netrwFileHandlers.vim source ~/.vim/autoload/netrw.vim source ~/.vim/plugin/netrwPlugin.vim Bernhard You shouldn't need that. The autoload subdirectory is for scripts which only have to be sourced on demand; but it is only supported in Vim 7 (and later ;-) ). If you are using Vim 7, remove the above lines and check the output of ":scriptnames". When Vim loads, it should show ~/.vim/plugin/netrwPlugin.vim as the first or only netrw script, and no netrw script of another name (such as plugin/netrw.vim, which is obsolete). After you use the netrw facility (e.g. directory browsing), the ":scriptnames" display should include one or more of the "autoload" scripts mentioned above. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 28. You have comandeered your teenager's phone line for the net and even his friends know not to call on his line anymore.
Re: newrw 107 and ':e .'
* A.J.Mechelynck <[EMAIL PROTECTED]> [2007-02-13 01:40]: > > It's Vim compiled by myself, from no other sources than Bram's official > ones (including 192 "official" patches). Yes, that fixes it, but I don't want to have the new version in /usr/ simply because I have not root access on every machine (but my $HOME is everywhere through NFS and NIS). But following in ~/.vimrc helped: source ~/.vim/autoload/netrwSettings.vim source ~/.vim/autoload/netrwFileHandlers.vim source ~/.vim/autoload/netrw.vim source ~/.vim/plugin/netrwPlugin.vim Bernhard -- Faulheit ist die Angewohnheit, sich auszuruhen, bevor man müde ist. -- (unbekannt) pgpuXDMclx11O.pgp Description: PGP signature
Subject: Re: vim on cygwin using win32 clipboard
Hi, I realized that I forgot to update the dependency data for winclip.c in makefile. The following is a patch after vim_patch.diff is applied. Index: Makefile === --- Makefile(revision 199) +++ Makefile(working copy) @@ -2787,6 +2787,10 @@ ascii.h keymap.h term.h macros.h option.h structs.h regexp.h gui.h \ gui_beval.h proto/gui_beval.pro ex_cmds.h proto.h globals.h farsi.h \ arabic.h version.h +objects/winclip.o: winclip.c vimio.h vim.h auto/config.h feature.h os_unix.h \ + auto/osdef.h ascii.h keymap.h term.h macros.h option.h structs.h \ + regexp.h gui.h ex_cmds.h proto.h globals.h farsi.h arabic.h \ + proto/winclip.pro objects/window.o: window.c vim.h auto/config.h feature.h os_unix.h auto/osdef.h \ ascii.h keymap.h term.h macros.h option.h structs.h regexp.h gui.h \ gui_beval.h proto/gui_beval.pro ex_cmds.h proto.h globals.h farsi.h \ Also, is there anything I can do to help get the original patch accepted? Thanks, Frodak
RFC: use hunspell dictionaries
Hello, Caolan McNamara wrote a patch for vim-7 to use hunspell dictionaries directly. This allows us to use one single set of dictionaries for OpenOffice, maybe firefox/thunderbird and vim. Please have a look at his comments at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219777 and at the patch available at https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=143756 Comments welcome, either here on this list or in the bugzilla. Karsten -- Karsten Hopp| Mail: [EMAIL PROTECTED] Red Hat Deutschland | Tel: +49-711-96437-0 Hauptstaetterstr.58 | Fax: +49-711-613590 D-70178 Stuttgart | http://www.redhat.de
RE: Win64-related patches
> One bug that I didn't fix. Build gvim.exe with OLE=no, run 'gvim
-register',
> and watch it crash while trying to display an error message.
This seems to fix the bug...
Index: src/message.c
===
--- src/message.c (revision 212)
+++ src/message.c (working copy)
@@ -2987,7 +2987,7 @@
* If 'verbosefile' is set write message in that file.
* Must come before the rest because of updating "msg_col".
*/
-if (*p_vfile != NUL)
+if (p_vfile && *p_vfile != NUL)
verbose_write(s, maxlen);
if (redir_fd != NULL
Index: src/misc2.c
===
--- src/misc2.c (revision 212)
+++ src/misc2.c (working copy)
@@ -1748,7 +1748,7 @@
return NULL;
}
#endif
-while ((b = *p) != NUL)
+while (p && (b = *p) != NUL)
{
if (b == c)
return p;
