Re: added completion to the :setfiletype command.
On 26-Jul-2010 23:29, Dominique Pellé wrote: The completion EXPAND_FILETYPE expands things from files located in $VIMRUNTIME/syntax/. Granted, most filetypes do define custom highlighting via a $VIMRUNTIME/syntax/filetype.vim script. But shouldn't the filetype completion also take into account files from the ftplugin and syntax directories, too? If I for example have a custom filetype bullettext that defines custom fold and indent settings, but no highlighting, I would expect to have this filetype included in the completion. Maybe $VIMRUNTIME/syntax/ should have rather be called $VIMRUNTIME/filetype/ but this should not be changed anymore since it has been like this for a long time and changing name would break things. As I understand it, there are three integration points: indent (obvious), syntax (for highlighting) and ftplugin (other buffer settings). Though syntax seems to be the most common one, I would prefer keeping that descriptive name. -- regards, ingo -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Vim 7.3: Python3 support
Hi Bram, That's good news to me. I'll check the sources and look into the crash as soon as possible. Roland b...@moolenaar.net schrieb am 25.07.2010 14:24:18: Von: Bram Moolenaar b...@moolenaar.net An: Roland Puntaier roland.punta...@br-automation.com Kopie: vim_dev@googlegroups.com Datum: 25.07.2010 14:24 Betreff: Vim 7.3: Python3 support Gesendet von: b...@moolenaar.net Roland - The Python 3 support has been included in Vim 7.3b. Please take a look and verify recent changes didn't cause trouble. We did encounter one serious problem: On Unix, when using this sequence of commands, Vim crashes: :python print hello :py3 print(hello) :python print hello I tried solving it by unloading one python library when loading the other, but that didn't really work. Thus for now I reject using both Python versions in one Vim session. It would be nice if you can help finding a solution. -- Dogs must have a permit signed by the mayor in order to congregate in groups of three or more on private property. [real standing law in Oklahoma, United States of America] /// Bram Moolenaar -- b...@moolenaar.net -- 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 /// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [patch] added completion to the :setfiletype command.
Dominique Pelle wrote:
Bram Moolenaar b...@moolenaar.net wrote:
Christian Brabandt wrote:
Hi Dominique!
On Sa, 24 Jul 2010, Dominique Pellé wrote:
Hi
Attached patch adds completion to the :setfiletype command.
Example:
:setf javaCTRL-D
javajavacc javascript
-- Dominique
diff -r 0c8219a26bc9 src/ex_docmd.c
--- a/src/ex_docmd.cSat Jul 24 20:57:44 2010 +0200
+++ b/src/ex_docmd.cSat Jul 24 23:36:07 2010 +0200
@@ -3829,6 +3829,7 @@
xp-xp_pattern = arg;
break;
+ case CMD_setfiletype:
case CMD_ownsyntax:
xp-xp_context = EXPAND_FILETYPE;
xp-xp_pattern = arg;
Since we now have filetype completion, why not add this to the
command-completion?
chrisbra t41:~/vim/src [1157]% hg diff ex_docmd.c ../runtime/doc/map.txt
diff -r 5bd81e397907 runtime/doc/map.txt
--- a/runtime/doc/map.txt Sun Jul 25 22:30:20 2010 +0200
+++ b/runtime/doc/map.txt Mon Jul 26 13:22:25 2010 +0200
@@ -1215,6 +1215,7 @@
-complete=mapping mapping name
-complete=menu menus
-complete=optionoptions
+ -complete=syntaxsyntax
-complete=tag tags
-complete=tag_listfiles tags, file names are shown when CTRL-D is
hit
-complete=var user variables
diff -r 5bd81e397907 src/ex_docmd.c
--- a/src/ex_docmd.cSun Jul 25 22:30:20 2010 +0200
+++ b/src/ex_docmd.cMon Jul 26 13:22:25 2010 +0200
@@ -5280,6 +5280,7 @@
{EXPAND_MENUS, menu},
{EXPAND_SETTINGS, option},
{EXPAND_SHELLCMD, shellcmd},
+{EXPAND_FILETYPE, syntax},
#if defined(FEAT_SIGNS)
{EXPAND_SIGN, sign},
#endif
If this is completing filetypes, why call it syntax? I would find
filetype less confusing.
In the same way, we could also add compiler and colorscheme completion.
Is that useful?
Generally completion is useful. Note that I'm not going to include new
features now. But these tiny changes should be OK.
I remember being a bit confused too with this when I wrote the patch.
The completion EXPAND_FILETYPE expands things from files
located in $VIMRUNTIME/syntax/.
EXPAND_SYNTAX already existed but it's something completely
different: it the expansion of the :syntax command.
Maybe $VIMRUNTIME/syntax/ should have rather be called
$VIMRUNTIME/filetype/ but this should not be changed anymore
since it has been like this for a long time and changing name would
break things.
Aha, so the filetypes are found by looking in the syntax directory.
Well, the result is still a list of filetypes, although there can be a
few syntax files that are not a filetype (e.g. 2html.vim). So do we let
the implementation details prevail? Or stick to the intention?
--
Corn oil comes from corn and olive oil comes from olives, so where
does baby oil come from?
/// Bram Moolenaar -- b...@moolenaar.net -- 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///
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Is read-only text possible in vim?
I know that we can use the set nomodifiable to make a buffer read-only, which makes all the text in it not modifiable. But is it possible to make some text in a buffer read-only but not for the whole buffer? I mean maybe we can bind a property to the string ( or text, or character ) , which can make the text read-only in a modifiable buffer. Or even finally, We can make the text not only a plain text, but text binding some properties set to different value to control the different aspects, such as highlighting, read-only, or even font. Maybe, conceal can also be one property of a text. :-) OK, you can consider this mail like a feature suggestion or just a brainstorm about the vim. Any discussion ? -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Command autocompletion behaving strangely
On Sat, Jul 24, 2010 at 8:59 AM, Nazri Ramliy ayieh...@gmail.com wrote:
I'll look into this again sometime next week.
It's done.
Please have a look at the patches - 0001 is the major one (have a look at the
two FIXMEs), while 0002 and 0003 are the minor fixes and documentation update
on the limitation of the completion when 'path' has upward search (;) and
directory limiter (/usr/**N) notations.
I'm sorry that I don't have access to a windows machine at the moment to
investigate the bug reports that people are reporting [1].
If anyone want to give a shot at fixing the bug the following information might
be useful:
The completion for find/sfind/tabfind is first handled by
misc1.c:expand_in_path() - it does the following:
1. Expand relative path entries in your 'path' setting into a list of
their equivalent full path directories:
. is expanded to the directory of the current file
,, (empty) is expanded to the current directory
foo is expanded to /current/directory/foo
The non-relative entries are left intact.
2. Joins the full path names in the previous step (with ,) and calls
globpath().
3. The matching list of full path file names are filtered through
misc1.c:uniquefy_paths() to shorten the filename while still keeping
them unique. If that is not possible then the fullname is used
instead.
If you would like to help making the completion works for the upward search (;)
and directory limiter notations (/usr/**N) the place to modify is the function
misc1.c:expand_path_option().
nazri.
[1] http://article.gmane.org/gmane.editors.vim.devel/27384
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
From 20b33f7376ce4852a1506757bb32b2db2fe095af Mon Sep 17 00:00:00 2001
From: nazri ayieh...@gmail.com
Date: Mon, 26 Jul 2010 12:57:33 +0800
Subject: [PATCH 1/3] find/sfind/tabfind completion: disambiguate completion list
Keep the full path if the unique file name could not be found with the
:find command.
---
src/misc1.c | 236 +++
1 files changed, 220 insertions(+), 16 deletions(-)
diff --git a/src/misc1.c b/src/misc1.c
index 9371760..ed5025a 100644
--- a/src/misc1.c
+++ b/src/misc1.c
@@ -9298,7 +9298,7 @@ is_unique(maybe_unique, gap, i)
if (other_path_len candidate_len)
continue; /* it's different */
- rival = other_paths[j] + other_path_len - candidate_len;
+ rival = gettail(other_paths[j]);
if (fnamecmp(maybe_unique, rival) == 0)
return FALSE;
@@ -9331,6 +9331,106 @@ remove_duplicates(gap)
}
/*
+ * Split the 'path' option to a an array of strings as garray_T. Relative
+ * paths are expanded to their equivalent fullpath. This includes the .
+ * (relative to current buffer directory) and empty path (relative to current
+ * directory) notations.
+ *
+ * TODO: handle upward search (;) and path limiter (**N) notations by
+ * expanding each into their equivalent path(s).
+ */
+static garray_T
+expand_path_option(curdir)
+char_u *curdir;
+{
+char_u *path_option = *curbuf-b_p_path == NUL
+ ? p_path : curbuf-b_p_path;
+garray_T ga;
+char_u *buf;
+
+ga_init2(ga, (int)sizeof(char_u *), 1);
+
+if ((buf = alloc((int)(MAXPATHL))) == NULL)
+ return ga;
+
+while (*path_option != NUL)
+{
+ copy_option_part(path_option, buf, MAXPATHL, ,);
+
+ if (STRCMP(buf, .) == 0) /* relative to current buffer */
+ {
+ char_u *p;
+ if (curbuf-b_ffname == NULL)
+ continue;
+
+ STRCPY(buf, curbuf-b_ffname);
+ p = gettail(buf);
+ *p = '\0';
+ }
+ else if (buf[0] == '\0') /* relative to current directory */
+ STRCPY(buf, curdir);
+ else if (!mch_isFullName(buf))
+ {
+ /* Expand relative path to their full path equivalent */
+ int curdir_len = STRLEN(curdir);
+ int buf_len = STRLEN(buf);
+
+ if (curdir_len + buf_len + 3 MAXPATHL)
+ continue;
+ STRMOVE(buf + curdir_len + 1, buf);
+ STRCPY(buf, curdir);
+ add_pathsep(buf);
+ STRMOVE(buf + curdir_len, buf + curdir_len + 1);
+ }
+
+ addfile(ga, buf, EW_NOTFOUND|EW_DIR|EW_FILE);
+}
+
+vim_free(buf);
+
+return ga;
+}
+
+/*
+ * Returns a pointer to the file or directory name in fname that matches the
+ * longest path in gap, or NULL if there is no match. For example:
+ *
+ *path: /foo/bar/baz
+ * fname: /foo/bar/baz/quux.txt
+ * returns: ^this
+ */
+static char_u *
+get_path_cutoff(fname, gap)
+char_u *fname;
+garray_T *gap;
+{
+int i;
+int maxlen = 0;
+char_u **path_part;
+char_u *cutoff = NULL;
+
+path_part = (char_u **) gap-ga_data;
+for (i = 0; i gap-ga_len; i++)
+{
+ int c = 0;
+ while (fname[c] == path_part[i][c] fname[c] != '\0'
+ path_part[i][c] != '\0')
+ c++;
+ if (c maxlen)
+ {
+ maxlen
Re: Command autocompletion behaving strangely
On Tue, Jul 27, 2010 at 4:30 PM, Nazri Ramliy ayieh...@gmail.com wrote:
Please have a look at the patches - 0001 is the major one
I noticed a leak. The fix is attached, to be applied after 0001.
nazri.
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
diff --git a/src/misc1.c b/src/misc1.c
index ed5025a..eaedd8c 100644
--- a/src/misc1.c
+++ b/src/misc1.c
@@ -9532,7 +9532,10 @@ uniquefy_paths(gap, pattern)
vim_free(fnames[i]);
fnames[i] = alloc((int)(STRLEN(rel_path) + 1));
if (fnames[i] == NULL)
+ {
+ vim_free(rel_path);
goto theend;
+ }
}
STRCPY(fnames[i], rel_path);
Re: added completion to the :setfiletype command.
Ingo Karkat wrote: Granted, most filetypes do define custom highlighting via a $VIMRUNTIME/syntax/filetype.vim script. But shouldn't the filetype completion also take into account files from the ftplugin and syntax directories, too? If I for example have a custom filetype bullettext that defines custom fold and indent settings, but no highlighting, I would expect to have this filetype included in the completion. Like Ingo I have several custom file types under my ~/.vim/ directory that don't have an associated syntax script and visa versa. Bram Molenaar wrote: Aha, so the filetypes are found by looking in the syntax directory. Well, the result is still a list of filetypes, although there can be a few syntax files that are not a filetype (e.g. 2html.vim). So do we let the implementation details prevail? Or stick to the intention? If sticking to the intention doesn't involve too much code that would IMHO be preferable to the current implementation because of the reason given above. Ideally file type completion would consider the base filenames of the Vim scripts in the system wide / user specific ftplugin / syntax / indent directories (and also their /after/ variants) but this might be too complex? - Peter Odding PS. Thanks Dominique and Christian for the patches you've posted, I've always been annoyed that :setfiletype doesn't support completion :-) -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: tarPlugin.vim needs to be updated to handle xz files
John Beckett wrote: In runtime file plugin/tarPlugin.vim, there are no lines for *.txz *.tar.xz which are needed to edit xz compressed tar archives. File plugin/gzip.vim handles *.xz, but tarPlugin.vim needs to be updated. The above is from Richard David Sherman who asked me to send it to vim_dev. Richard has limited computer access at the moment, so has not expanded on the above. Can someone please fill in the details and update the runtime for the 7.3 release. Attached is a patch that should do what you requested. This is against the latest Vim 7.3c pulled and updated less than an hour ago. - Peter Odding -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php diff -r acfb7eddf13c runtime/plugin/tarPlugin.vim --- a/runtime/plugin/tarPlugin.vim Mon Jul 26 22:51:56 2010 +0200 +++ b/runtime/plugin/tarPlugin.vim Tue Jul 27 12:39:54 2010 +0200 @@ -41,6 +41,8 @@ au BufReadCmd *.tar.Z call tar#Browse(expand(amatch)) au BufReadCmd *.tgz call tar#Browse(expand(amatch)) au BufReadCmd *.tar.lzma call tar#Browse(expand(amatch)) + au BufReadCmd *.txz call tar#Browse(expand(amatch)) + au BufReadCmd *.tar.xz call tar#Browse(expand(amatch)) augroup END com! -nargs=? -complete=file Vimuntar call tar#Vimuntar(q-args)
tutor.utf-8: typo and misinformation
Hi, I noted two minor problems in the tutor: Line 199: The information below will only be valid in Unix if the user has already :set showcmd because the default on Unix is noshowcmd: NOTE: The letter d will appear on the last line of the screen as you type it. Vim is waiting for you to type w . If you see another character than d you typed something wrong; press ESC and start over. Line 659: There is an 'Enter' instead of 'ENTER' as in the remaining of the text. -- Jakson Aquino -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: tarPlugin.vim needs to be updated to handle xz files
Peter Odding wrote: John Beckett wrote: In runtime file plugin/tarPlugin.vim, there are no lines for *.txz *.tar.xz which are needed to edit xz compressed tar archives. File plugin/gzip.vim handles *.xz, but tarPlugin.vim needs to be updated. The above is from Richard David Sherman who asked me to send it to vim_dev. Richard has limited computer access at the moment, so has not expanded on the above. Can someone please fill in the details and update the runtime for the 7.3 release. Attached is a patch that should do what you requested. This is against the latest Vim 7.3c pulled and updated less than an hour ago. Y'all ought to check on http://mysite.verizon.net/astronaut/vim/index.html#TAR -- its up to v25b at the moment, and already has *.txz and *.tar.xz support. Regards, Chip Campbell -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: tarPlugin.vim needs to be updated to handle xz files
Charles Campbell wrote: Y'all ought to check on http://mysite.verizon.net/astronaut/vim/index.html#TAR -- its up to v25b at the moment, and already has *.txz and *.tar.xz support. I'm sorry, I updated to the latest runtime files from vim-73c thinking that would include all the latest code. I didn't think to check on your website because the file in question doesn't contain a link to it. I didn't intent to change one of your scripts behind your back though. - Peter Odding -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
RE: Conceal Bugs
From: Benjamin Fritz [mailto:fritzophre...@gmail.com] I see mostly what I would expect, but the line that matches the concealends syntax rule is missing the listchars replacement for the first concealed end. See conceal_bug_start.png. Now, I press 'j' several times to move past all the comment lines, and see the two wholly concealed lines disappear entirely from view, without even the cchar replacement character. See conceal_bug_end.png. Both of these are regressions - I just checked test.vim with my Vim 7.2 (including my original conceal patch) and neither bug occurs. The bug also doesn't occur in the 7.3 beta of 15th May. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [patch] added completion to the :setfiletype command.
On 27/07/10 09:44, Bram Moolenaar wrote: [...] Aha, so the filetypes are found by looking in the syntax directory. Well, the result is still a list of filetypes, although there can be a few syntax files that are not a filetype (e.g. 2html.vim). So do we let the implementation details prevail? Or stick to the intention? The scripts in syntax/ which are not filetypes constitute a closed list (IIUC: 2html, syncolor, synload and syntax), they could be excluded from the list. OTOH, there might be a few filetypes with an ftplugin and/or an indent script but no syntax script. Are they worth the trouble of adding them to the list? (Taking care of duplicates could be done by a sort and uniquify after scanning all syntax etc. subdirs of all 'runtimepath' directories.) Best regards, Tony. -- It is illegal for a driver to be blindfolded while operating a vehicle. [real standing law in Alabama, United States of America] -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Tr : Re : Minor problems...
- Message transféré De : Dimitar DIMITROV mitk...@yahoo.fr À : Bram Moolenaar b...@moolenaar.net Envoyé le : Mar 27 juillet 2010, 13h 32min 56s Objet : Re : Minor problems... Dimitar Dimitrov wrote: I wrote: Dimitar Dimitrov wrote: I always have 'cursorline' set. Try this: :h'exrc Setting the cursor on this line...: setting the 'secure' option (see initialization). Using a local ...makes it move right. Same thing if you turn off cursorline but position your cursor on the left parens... I think this is related to the new conceal feature and the vertical bars appearing (|) The concealing is not done when there is something highlighted in the line. I'm not sure if this is required. Perhaps it would be highlighting the wrong position otherwise. But for 'cursorline' this doesn't matter. Vince? Looking at this again, I think it's bad that the cursor is at the wrong position. E.g. a search lands in the wrong place. Even when 'modifiable' is off a user would still want to copy text, and we don't want to copy something else than what's displayed. The highlighting does not appear to be a problem. Perhaps I didn't try the right kind? I pushed a new version that does it this way, please check for how it works now. I tried with Vim 7.3b and the problem is gone when cursorline is on but I still find it strange that vertical bars and stars would appear when highlighting the text. It may be relevant for other filetypes but I don't think it is for help files. Here is what I get when copying: 1.txt| About the manuals |usr_02.txt| The first steps in Vim |usr_03.txt| Moving around |usr_04.txt| Making small changes |usr_05.txt| Set your settings |usr -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
RE: Conceal Bugs
From: Benjamin Fritz [mailto:fritzophre...@gmail.com] I see mostly what I would expect, but the line that matches the concealends syntax rule is missing the listchars replacement for the first concealed end. See conceal_bug_start.png. Now, I press 'j' several times to move past all the comment lines, and see the two wholly concealed lines disappear entirely from view, without even the cchar replacement character. See conceal_bug_end.png. This bug crept in with changeset 2391 - Give each syntax item a sequence number, so that we know when it starts and.. rev 2390 is fine, 2391 is broken. Maybe there is a place where syntax_seqnr needs to be incremented but isn't? Vince -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
RE: Conceal Bugs
From: Vince Negri
This bug crept in with changeset 2391 -
Maybe there is a place where syntax_seqnr needs to be incremented but isn't?
This patch (against 2391) appears to fix the broken concealends. Not the blank
lines in a region though.
diff -r 0371401d9d33 src/syntax.c
--- a/src/syntax.c Sat Jul 24 17:29:03 2010 +0200
+++ b/src/syntax.c Tue Jul 27 14:50:39 2010 +0100
@@ -2492,7 +2492,10 @@
#ifdef FEAT_CONCEAL
cur_si-si_flags |= save_flags;
if (cur_si-si_flags HL_CONCEALENDS)
+ {
cur_si-si_flags |= HL_CONCEAL;
+ cur_si-si_seqnr = next_seqnr++;
+ }
#endif
cur_si-si_next_list = NULL;
check_keepend();
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Conceal Bugs
On Tuesday 27 July 2010 08:37:31 Vince Negri wrote: This bug crept in with changeset 2391 - Give each syntax item a sequence number, so that we know when it starts and.. rev 2390 is fine, 2391 is broken. you cannot use that first number to communicate -- the Give each item a sequence number changeset for me was 2432 -- that number is different for everybody -- you must use the horking and unambiguous 0371401d9d33 sorry to go off topic sc -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
RE: Conceal Bugs
From: sc [mailto:tooth...@swbell.net] you cannot use that first number to communicate -- the Give each item a sequence number changeset for me was 2432 -- that number is different for everybody -- you must use the horking and unambiguous 0371401d9d33 sorry to go off topic No need to apologise - thanks for the correction (I am something of a Mercurial n00b.) Back on topic - in order to fix the missing cchars in wholly concealed lines in a region, we need to somehow increment the seqnr with each new line begun in the region. Any ideas how to do this? It wasn't obvious as it was in the case of concealends. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Is read-only text possible in vim?
On Jul 27, 2:55 am, winterTTr winterttr@gmail.com wrote: I know that we can use the set nomodifiable to make a buffer read-only, which makes all the text in it not modifiable. But is it possible to make some text in a buffer read-only but not for the whole buffer? I mean maybe we can bind a property to the string ( or text, or character ) , which can make the text read-only in a modifiable buffer. Or even finally, We can make the text not only a plain text, but text binding some properties set to different value to control the different aspects, such as highlighting, read-only, or even font. Maybe, conceal can also be one property of a text. :-) I'm curious what your end goal is. Making only part of the buffer text read-only is probably not a trivial task. Knowing why you want this may help come up with some alternative solutions to the problem you are trying to solve. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Tr : Re : Minor problems...
On Tue, Jul 27, 2010 at 9:17 AM, Dimitar DIMITROV wrote: I tried with Vim 7.3b and the problem is gone when cursorline is on but I still find it strange that vertical bars and stars would appear when highlighting the text. It may be relevant for other filetypes but I don't think it is for help files. Here is what I get when copying: 1.txt| About the manuals |usr_02.txt| The first steps in Vim |usr_03.txt| Moving around |usr_04.txt| Making small changes |usr_05.txt| Set your settings |usr I'm not such a fan of that either. Is there some option to make copying copy exactly what's shown on the screen, without including concealed text? I actually can't think of a time when I'd want to copy the concealed text, for any use case I've thought of so far for conceal... ~Matt -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Tr : Re : Minor problems...
On Tue, Jul 27, 2010 at 12:12 PM, Matt Wozniski wrote: On Tue, Jul 27, 2010 at 9:17 AM, Dimitar DIMITROV wrote: I tried with Vim 7.3b and the problem is gone when cursorline is on but I still find it strange that vertical bars and stars would appear when highlighting the text. It may be relevant for other filetypes but I don't think it is for help files. Here is what I get when copying: 1.txt| About the manuals |usr_02.txt| The first steps in Vim |usr_03.txt| Moving around |usr_04.txt| Making small changes |usr_05.txt| Set your settings |usr I'm not such a fan of that either. Is there some option to make copying copy exactly what's shown on the screen, without including concealed text? I actually can't think of a time when I'd want to copy the concealed text, for any use case I've thought of so far for conceal... That was stupid - I managed to completely ignore the case of copying some text from one part of the current buffer to another part, I was only thinking about copying between buffers or between applications. Still, I think that an option controlling whether or not concealed text is included in the copy would be a good thing. ~Matt -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: added completion to the :setfiletype command.
Peter Odding wrote:
Ingo Karkat wrote:
Granted, most filetypes do define custom highlighting via a
$VIMRUNTIME/syntax/filetype.vim script. But shouldn't the filetype
completion
also take into account files from the ftplugin and syntax directories,
too?
If I for example have a custom filetype bullettext that defines custom
fold
and indent settings, but no highlighting, I would expect to have this
filetype
included in the completion.
Like Ingo I have several custom file types under my ~/.vim/ directory that
don't have an associated syntax script and visa versa.
Bram Molenaar wrote:
Aha, so the filetypes are found by looking in the syntax directory.
Well, the result is still a list of filetypes, although there can be a
few syntax files that are not a filetype (e.g. 2html.vim). So do we let
the implementation details prevail? Or stick to the intention?
If sticking to the intention doesn't involve too much code that would IMHO
be preferable to the current implementation because of the reason given
above.
Ideally file type completion would consider the base filenames of the Vim
scripts in the system wide / user specific ftplugin / syntax / indent
directories (and also their /after/ variants) but this might be too complex?
I can try to change the behavior. But just to make sure I understand
the problems:
:setfiletype and :ownsyntax commands currently both perform
completion by looking at syntax/*.vim from both $VIMRUNTIME
and ~/.vim/.
That's almost fine, but it not ideal for 2 reasons:
1/ :setfiletype should actually complete by looking at files matching
{syntax,ftplugin,indent}/*.vim from both $VIMRUNTIME/ and ~/.vim/
:ownsyntax completion should only look at syntax/*.vim (as it does now).
2/ there are a few files matching syntax/*.vim which are not syntax
files such as 2html.vim, syntax.vim, colortest.vim... They can thus
show up as a spurious completion results. These special files are
listed in syntax/README.txt. Any reasons for them to be in the
syntax/ directory?
In practice, current implementation is almost fine since almost
all files matching $VIMRUNTIME/{ftplugin,indent}/*.vim have a
corresponding file matching $VIMRUNTIME/syntax/*.vim. Using
the following commands...
$ cd /usr/local/share/vim/vim73c
$ vim -d (cd syntax/; ls *.vim) (cd ftplugin/; ls *.vim)
$ vim -d (cd syntax/; ls *.vim) (cd indent/; ls *.vim)
... I see only 3 files matching ftplugin/*.vim which do not correspond
to any file syntax/*.vim
- ftplugin/hostaccess.vim
- ftplugin/quickfix.vim
- ftplugin/AppendMatchGroup.vim: this file does not look
like a file type plugin anyway. It appears to contain a helper
function. Should it really be there?
And 1 file matching index/*.vim which has no corresponding files
matching syntax/*.vim:
- indent/GenericIndent.vim: this file is not an indent file but
contains helper functions. Should it be stored somewhere else?
I don't think this is a blocker for the release but Bram can decide :-)
-- Dominique
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Question about :find completion support in Vim 7.3b
On Tue, Jul 27, 2010 at 10:55 AM, Ajit Thakkar a...@unb.ca wrote: On Mon, Jul 26, 2010 at 9:16 PM, Nazri Ramliy ayieh...@gmail.com wrote: On Tue, Jul 27, 2010 at 6:01 AM, Yegappan Lakshmanan yegapp...@gmail.com wrote: When I press Tab after typing :find , I expected that the filenames from the current directory will be completed. But none of the filenames are displayed. If I try to complete file names using ./ or .\, then the file names are displayed. Is this the expected behavior? No this is a bug. It should behave as you expected. Does this happen on both console vim and gvim? Confirmed for both console and gui. I managed to get my hands on a Windows (Vista) machine. Attached patch should make the find/sfind/tabfind completion works (almost) as expected. It works when 'path' is .,, When I set 'path' to something like c:\src\** the completion doesn't work: :find tab has no effect. If nobody beat me to it I'll investigate further later. nazri -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php find-completion-win.patch Description: Binary data
RE: Conceal Bugs
Vince Negri wrote: you cannot use that first number to communicate -- the Give each item a sequence number changeset for me was 2432 -- that number is different for everybody -- you must use the horking and unambiguous 0371401d9d33 sorry to go off topic No need to apologise - thanks for the correction (I am something of a Mercurial n00b.) Back on topic - in order to fix the missing cchars in wholly concealed lines in a region, we need to somehow increment the seqnr with each new line begun in the region. Any ideas how to do this? It wasn't obvious as it was in the case of concealends. Would it be possible on the other end: decrement the expected sequence number when going to the next line? -- God made machine language; all the rest is the work of man. /// Bram Moolenaar -- b...@moolenaar.net -- 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/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
RE: Conceal Bugs
Vince Negri wrote:
Glad to hear from you again Vince. I've been making changes to the
conceal feature and had not received remarks from you yet. Especially
about the 'concealcursor' option. And also this issue with consecutive
matches of concealed items.
This bug crept in with changeset 2391 -
Maybe there is a place where syntax_seqnr needs to be incremented but
isn't?
This patch (against 2391) appears to fix the broken concealends. Not the blank
lines in a region though.
diff -r 0371401d9d33 src/syntax.c
--- a/src/syntax.c Sat Jul 24 17:29:03 2010 +0200
+++ b/src/syntax.c Tue Jul 27 14:50:39 2010 +0100
@@ -2492,7 +2492,10 @@
#ifdef FEAT_CONCEAL
cur_si-si_flags |= save_flags;
if (cur_si-si_flags HL_CONCEALENDS)
+ {
cur_si-si_flags |= HL_CONCEAL;
+ cur_si-si_seqnr = next_seqnr++;
+ }
#endif
cur_si-si_next_list = NULL;
check_keepend();
I found another place where HL_CONCEAL was set and the si_seqnr wasn't.
I'll push that right away.
--
The chat program is in public domain. This is not the GNU public license.
If it breaks then you get to keep both pieces.
-- Copyright notice for the chat program
/// Bram Moolenaar -- b...@moolenaar.net -- 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///
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: [bug] Windows 7 double-click file brings up empty vim
Still happening in 7.3b. Is there a list of open bugs? I don't want to keep harping on something as long as I know it'll be addressed at some point. Thanks! On Tue, Jul 20, 2010 at 10:22 AM, Garner Halloran garner...@gmail.comwrote: Using 7.3a BETA on Windows 7. If I double click on any file in explorer that has been associated with gvim it brings up an empty editor. I can drag the file into the window and it will work. I can right click and Edit with Vim and it will work. Gvim is my editor for p4v and if I double click a file there it works. I removed my _vimrc and the problem still exists. That is the version I created the bug report with to limit the size. I tried rebooting and that didn't fix it. I tried associating the file type with another editor and re-associated with gvim. To do that I'm using open with... and then choose default program. Let me know if you want me to try something or give more information. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: :command -complete bug?
Christian J. Robinson wrote: My explanation is probably unclear, but I can reproduce it by sourcing the attached file, typing :Foo and pressing tab (clear away the blank confirm dialog), then pressing backspace to delete the '1' and then pressing tab again. The confirm dialog shows only bar instead of foo\ bar/foo bar. Clearing away that confirm dialog shows foo\ foo\ bar1 on the command line. You also get the whole command line and the cursor position. You can use that to figure out the whole completion. Vim doesn't know that the thing being completed could continue before a space. But that doesn't work either. I can use the full command line to figure out the whole completion and return the possible completions, but Vim still inserts the new whole completion (with spaces) only in place of the text after the last space--it does not replace the entire text it should be replacing. Vim doesn't know where the text to be replaced starts, thus you need to give only the part that it expects. You have to strip the first part, which is identical in every returned item. Can I somehow tell Vim to replace the entire set of arguments after the command itself during completion? I really do think Vim should treat backslash-escaped spaces as being part of a greater single argument. As far as I can tell, as it is I have no way of effectively dealing with spaces in arguments during custom completion. Perhaps Vim could be altered to do it more like what I want if a command is defined with -nargs=? or -nargs=1 instead of -nargs=*? It's impossible to do this correctly in all situations. That's why it is left to the completion function, because it's the place where the desired behavior is known. So yes, it's a bit more work to write the completion function if you have arguments with spaces in it. The 'completefunc' has a separate call to find the start of the completed item. That makes some things easier, but also makes it more complicated for simple completions. -- (letter from Mark to Mike, about the film's probable certificate) I would like to get back to the Censor and agree to lose the shits, take the odd Jesus Christ out and lose Oh fuck off, but to retain 'fart in your general direction', 'castanets of your testicles' and 'oral sex' and ask him for an 'A' rating on that basis. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- 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/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [bug] access to free memory with :redir command in Vim-7.2.466 and Vim-7.3b BETA
Dominique Pellé wrote:
$ cat use-free-mem.vim
let temp={}
redir = temp[0]
exe silent! ls
let temp={}
redir = temp[0]
exe silent! ls
$ valgrind --leak-check=yes vim -u NONE -S use-free-mem.vim
2/tmp/valgrind.log
Gives the following error in /tmp/valgrind.log:
...snip...
Script to reproduce the bug can be simplified further.
This is enough to reproduce the bug:
$ cat use-free-mem.vim
let temp={}
redir = temp[0]
let temp={}
redir END
$ valgrind --leak-check=yes vim -u NONE -S use-free-mem.vim
2/tmp/valgrind.log
The deletion of the dictionary, while doing a redir to a member of the
dictionary triggers the bug. I'm looking at the code but it's not simple
to understand.
I think the only safe way is to call get_lval() again in
var_redir_stop(). The information gathered in redir_lval may have
become invalid in the mean time.
--
FATAL ERROR! SYSTEM HALTED! - Press any key to continue doing nothing.
/// Bram Moolenaar -- b...@moolenaar.net -- 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///
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: added completion to the :setfiletype command.
Dominique Pellé wrote:
I can try to change the behavior. But just to make sure I understand
the problems:
:setfiletype and :ownsyntax commands currently both perform
completion by looking at syntax/*.vim from both $VIMRUNTIME
and ~/.vim/.
That's almost fine, but it not ideal for 2 reasons:
1/ :setfiletype should actually complete by looking at files matching
{syntax,ftplugin,indent}/*.vim from both $VIMRUNTIME/ and ~/.vim/
:ownsyntax completion should only look at syntax/*.vim (as it does now).
2/ there are a few files matching syntax/*.vim which are not syntax
files such as 2html.vim, syntax.vim, colortest.vim... They can thus
show up as a spurious completion results. These special files are
listed in syntax/README.txt. Any reasons for them to be in the
syntax/ directory?
In practice, current implementation is almost fine since almost
all files matching $VIMRUNTIME/{ftplugin,indent}/*.vim have a
corresponding file matching $VIMRUNTIME/syntax/*.vim. Using
the following commands...
I was specifically talking about completion of file types under ~/.vim,
otherwise Vim could just include a static list of names. Here's what I
(and I assume Ingo) have in mind:
function! IdealFtComplete()
let types = {}
let pattern = '{ftplugin,syntax,indent}/*.vim'
let ignored = ['syntax', 'manual', 'synload', 'nosyntax', '2html',
\ 'colortest', 'hitest', 'whitespace', 'AppendMatchGroup',
\ 'GenericIndent']
for filename in split(globpath(rtp, pattern, 1), \n)
let type = fnamemodify(filename, :t:r)
if index(ignored, type) == -1 | let types[type] = 1 | endif
endfor
return sort(keys(types))
endfunction
I've excluded the files you identified in your previous message because
I agree they probably shouldn't be considered for file type completion.
- Peter Odding
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Misprint in doc file
Hi dev
I found a tiny misprint in the description of setreg() function (:h setreg())
It is written:
{options} can also contains a register type specification:
while it should be
{options} can also contain a register type specification:
Best, Marcin
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: [patch] Win32 flicker
I think this really makes a difference for some unstable windows installs. How can I help to make this patch to get tested (and ultimately accepted)? Best regards René -- Forwarded message -- From: René Aguirre rene.f.agui...@gmail.com Date: Sat, Jul 24, 2010 at 12:33 PM Subject: Win32 flicker To: vim-...@vim.org Hello, Refer to the attached .diff file for a patch to an annoying issue related to un-expected flicker in the main editor window. The reason for this is that the editor window, was not marked for clipping before the background was painted. Just adding the proper windows style settings fixes the issue. How to reproduce (easily): 1) Windows XP, (also in Vista, possibly on Win 7) 2) Set VIM background normal text to black 3) Set the main 3d / button face widget system color (as is used by VIM for background) to a light color, light gray or higher intensity. 4) re-start VIM 5) Open any file that allows to fill up the editor screen Issue: During regular motion or editing, random background refresh can be noticed, on some systems this is worst (windows seems to trigger random paint request to my windows, possible due the way some services are interacting with windows explorer) and really noticeable (example with a high resolution screen). Details on the fix: The main editor window style is changed to clip the children window from the background before erasing the background, so the text editor client area is not erased before re-painting. IMPORTANT: I'm using the latest vim73 source from the mercurial repo in order to facilitate integration, but the issue also happens in Vim72. Best regards René Aguirre -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php win32_flicker_fix.diff Description: Binary data
Re: added completion to the :setfiletype command.
Dominique Pelle wrote:
Peter Odding wrote:
Ingo Karkat wrote:
Granted, most filetypes do define custom highlighting via a
$VIMRUNTIME/syntax/filetype.vim script. But shouldn't the filetype
completion
also take into account files from the ftplugin and syntax directories,
too?
If I for example have a custom filetype bullettext that defines custom
fold
and indent settings, but no highlighting, I would expect to have this
filetype
included in the completion.
Like Ingo I have several custom file types under my ~/.vim/ directory that
don't have an associated syntax script and visa versa.
Bram Molenaar wrote:
Aha, so the filetypes are found by looking in the syntax directory.
Well, the result is still a list of filetypes, although there can be a
few syntax files that are not a filetype (e.g. 2html.vim). So do we let
the implementation details prevail? Or stick to the intention?
If sticking to the intention doesn't involve too much code that would IMHO
be preferable to the current implementation because of the reason given
above.
Ideally file type completion would consider the base filenames of the Vim
scripts in the system wide / user specific ftplugin / syntax / indent
directories (and also their /after/ variants) but this might be too complex?
I can try to change the behavior. But just to make sure I understand
the problems:
:setfiletype and :ownsyntax commands currently both perform
completion by looking at syntax/*.vim from both $VIMRUNTIME
and ~/.vim/.
That's almost fine, but it not ideal for 2 reasons:
1/ :setfiletype should actually complete by looking at files matching
{syntax,ftplugin,indent}/*.vim from both $VIMRUNTIME/ and ~/.vim/
:ownsyntax completion should only look at syntax/*.vim (as it does now).
2/ there are a few files matching syntax/*.vim which are not syntax
files such as 2html.vim, syntax.vim, colortest.vim... They can thus
show up as a spurious completion results. These special files are
listed in syntax/README.txt. Any reasons for them to be in the
syntax/ directory?
Historic reasons. I think it's not much of a problem, one would simply
not select these as the desired filetype. Moving them elsewhere will
break scripts.
In practice, current implementation is almost fine since almost
all files matching $VIMRUNTIME/{ftplugin,indent}/*.vim have a
corresponding file matching $VIMRUNTIME/syntax/*.vim. Using
the following commands...
$ cd /usr/local/share/vim/vim73c
$ vim -d (cd syntax/; ls *.vim) (cd ftplugin/; ls *.vim)
$ vim -d (cd syntax/; ls *.vim) (cd indent/; ls *.vim)
... I see only 3 files matching ftplugin/*.vim which do not correspond
to any file syntax/*.vim
- ftplugin/hostaccess.vim
- ftplugin/quickfix.vim
- ftplugin/AppendMatchGroup.vim: this file does not look
like a file type plugin anyway. It appears to contain a helper
function. Should it really be there?
That should be an autoload script. I don't think that was possible when
it was written. I'll ping the author, but it's been a long time.
And 1 file matching index/*.vim which has no corresponding files
matching syntax/*.vim:
- indent/GenericIndent.vim: this file is not an indent file but
contains helper functions. Should it be stored somewhere else?
It's from the same author.
I don't think this is a blocker for the release but Bram can decide :-)
I think that users will be disappointed when the filetype they were
looking for does not show up in completion. It's not so bad if a few
more choices pop up, a user can simply skip over them.
We need to keep performance in mind, completion is being done
interactive. But the syntax directory is the biggest one, adding indent
and ftplugin can't make it more than twice as slow. Hopefully.
Following these arguments we should add the indent and ftplugin
directories. And make sure duplicates are removed.
--
The most powerful force in the universe is gossip.
/// Bram Moolenaar -- b...@moolenaar.net -- 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///
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: [bug] Windows 7 double-click file brings up empty vim
Garner Halloran wrote: Still happening in 7.3b. Is there a list of open bugs? I don't want to keep harping on something as long as I know it'll be addressed at some point. Thanks! On Tue, Jul 20, 2010 at 10:22 AM, Garner Halloran garner...@gmail.comwrote: Using 7.3a BETA on Windows 7. If I double click on any file in explorer that has been associated with gvim it brings up an empty editor. I can drag the file into the window and it will work. I can right click and Edit with Vim and it will work. Gvim is my editor for p4v and if I double click a file there it works. I removed my _vimrc and the problem still exists. That is the version I created the bug report with to limit the size. I tried rebooting and that didn't fix it. I tried associating the file type with another editor and re-associated with gvim. To do that I'm using open with... and then choose default program. Let me know if you want me to try something or give more information. I can reproduce the problem. The Edit with Vim menu works fine, the Open with... results in starting Vim without a file. I'm using the 64 bit version of Windows 7, if that matters. George? -- People who want to share their religious views with you almost never want you to share yours with them. /// Bram Moolenaar -- b...@moolenaar.net -- 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/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [patch] Win32 flicker
On 27/07/10 21:48, René Aguirre wrote: I think this really makes a difference for some unstable windows installs. How can I help to make this patch to get tested (and ultimately accepted)? Best regards René The first step is already done: you've posted a description of the problem, with a suggested patch, on the vim_dev group. Now comes the harder part: Be patient. It may take hours to days for people to notice your post, minutes to apply the patch and compile, days to weeks to test the patched build and see if it works; and since the problem is apparently Windows-only, it means that anyone using (as I do) a different OS cannot test your fix. Best regards, Tony. -- It is illegal for anyone to try and stop a child from playfully jumping over puddles of water. [real standing law in California, United States of America] -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Is tagfiles() supposed to use suffixesadd?!
Hi list, I first noticed the following issue a long time ago when I was still using Vim 7.2 but I just found that it still applies to Vim 7.3c: When Vim expands the 'tags' option it also considers the 'suffixesadd' option. Because I have :set suffixesadd=.vim in my ~/.vimrc (so that :find automatically adds the extension .vim which seems like a valid use case to me?) the following then happens to me from time to time: $ vim -u NONE -U NONE --noplugin -N --cmd 'cd $VIMRUNTIME/syntax | set sua=.vim | echo tagfiles() | echo taglist(.)' --cmd quit ['tags.vim'] Error detected while processing pre-vimrc command line: E431: Format error in tags file tags.vim Before byte 95 [] I don't know whether Vim expands the 'tags' option using the same internal code that drives glob(). If that is the case then simply passing flag=1 (internally) should fix the issue. Unless this is all intentional, in which case it seems appropriate IMHO to mention this behavior near :help 'tags' or :help 'suffixesadd'. - Peter Odding -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: tutor.utf-8: typo and misinformation
Jakson A. Aquino wrote: I noted two minor problems in the tutor: Line 199: The information below will only be valid in Unix if the user has already :set showcmd because the default on Unix is noshowcmd: NOTE: The letter d will appear on the last line of the screen as you type it. Vim is waiting for you to type w . If you see another character than d you typed something wrong; press ESC and start over. You are supposed to start the tutor with vimtutor. It will set 'nocompatible' and 'showcmd' will be on. Line 659: There is an 'Enter' instead of 'ENTER' as in the remaining of the text. I'll fix that. -- A M00se once bit my sister ... Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- 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/// -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: added completion to the :setfiletype command.
Bram Moolenaar wrote:
Dominique Pelle wrote:
Peter Odding wrote:
Ingo Karkat wrote:
Granted, most filetypes do define custom highlighting via a
$VIMRUNTIME/syntax/filetype.vim script. But shouldn't the filetype
completion
also take into account files from the ftplugin and syntax directories,
too?
If I for example have a custom filetype bullettext that defines custom
fold
and indent settings, but no highlighting, I would expect to have this
filetype
included in the completion.
Like Ingo I have several custom file types under my ~/.vim/ directory that
don't have an associated syntax script and visa versa.
Bram Molenaar wrote:
Aha, so the filetypes are found by looking in the syntax directory.
Well, the result is still a list of filetypes, although there can be a
few syntax files that are not a filetype (e.g. 2html.vim). So do we let
the implementation details prevail? Or stick to the intention?
If sticking to the intention doesn't involve too much code that would IMHO
be preferable to the current implementation because of the reason given
above.
Ideally file type completion would consider the base filenames of the Vim
scripts in the system wide / user specific ftplugin / syntax / indent
directories (and also their /after/ variants) but this might be too
complex?
I can try to change the behavior. But just to make sure I understand
the problems:
:setfiletype and :ownsyntax commands currently both perform
completion by looking at syntax/*.vim from both $VIMRUNTIME
and ~/.vim/.
That's almost fine, but it not ideal for 2 reasons:
1/ :setfiletype should actually complete by looking at files matching
{syntax,ftplugin,indent}/*.vim from both $VIMRUNTIME/ and ~/.vim/
:ownsyntax completion should only look at syntax/*.vim (as it does now).
2/ there are a few files matching syntax/*.vim which are not syntax
files such as 2html.vim, syntax.vim, colortest.vim... They can thus
show up as a spurious completion results. These special files are
listed in syntax/README.txt. Any reasons for them to be in the
syntax/ directory?
Historic reasons. I think it's not much of a problem, one would simply
not select these as the desired filetype. Moving them elsewhere will
break scripts.
In practice, current implementation is almost fine since almost
all files matching $VIMRUNTIME/{ftplugin,indent}/*.vim have a
corresponding file matching $VIMRUNTIME/syntax/*.vim. Using
the following commands...
$ cd /usr/local/share/vim/vim73c
$ vim -d (cd syntax/; ls *.vim) (cd ftplugin/; ls *.vim)
$ vim -d (cd syntax/; ls *.vim) (cd indent/; ls *.vim)
... I see only 3 files matching ftplugin/*.vim which do not correspond
to any file syntax/*.vim
- ftplugin/hostaccess.vim
- ftplugin/quickfix.vim
- ftplugin/AppendMatchGroup.vim: this file does not look
like a file type plugin anyway. It appears to contain a helper
function. Should it really be there?
That should be an autoload script. I don't think that was possible when
it was written. I'll ping the author, but it's been a long time.
And 1 file matching index/*.vim which has no corresponding files
matching syntax/*.vim:
- indent/GenericIndent.vim: this file is not an indent file but
contains helper functions. Should it be stored somewhere else?
It's from the same author.
I don't think this is a blocker for the release but Bram can decide :-)
I think that users will be disappointed when the filetype they were
looking for does not show up in completion. It's not so bad if a few
more choices pop up, a user can simply skip over them.
We need to keep performance in mind, completion is being done
interactive. But the syntax directory is the biggest one, adding indent
and ftplugin can't make it more than twice as slow. Hopefully.
Following these arguments we should add the indent and ftplugin
directories. And make sure duplicates are removed.
Please try and review the attached patch.
It think it does what's needed and it's rather simple:
:setfiletype completes using things that match
$VIMRUNTIME/{syntax,ftplugin,indent}/*.vim and
~/.vim/{syntax,ftplugin,indent}/*.vim
:ownsyntax behaves as before, i.e. it completes using things that
match $VIMRUNTIME/syntax/*.vim and ~/.vim/syntax/*.vim
You can verify that :ownsyntax and :setfiletype complete
differently with this example:
:setfiletype hostCTRL-D
hostconf hostsaccess
:ownsyntax hostCTRL-D
hostconf
I have not done anything about the special files such as
syntax/2html.vim. I could hard-code something to exclude
them but it'd be ugly. Hopefully we can consider moving
those special files.
Regards
-- Dominique
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
diff -r da067045878f src/ex_docmd.c
--- a/src/ex_docmd.c Tue Jul 27 20:47:25 2010 +0200
Re: Is tagfiles() supposed to use suffixesadd?!
Peter Odding wrote: Hi list, I first noticed the following issue a long time ago when I was still using Vim 7.2 but I just found that it still applies to Vim 7.3c: When Vim expands the 'tags' option it also considers the 'suffixesadd' option. Because I have :set suffixesadd=.vim in my ~/.vimrc (so that :find automatically adds the extension .vim which seems like a valid use case to me?) the following then happens to me from time to time: $ vim -u NONE -U NONE --noplugin -N --cmd 'cd $VIMRUNTIME/syntax | set sua=.vim | echo tagfiles() | echo taglist(.)' --cmd quit ['tags.vim'] Error detected while processing pre-vimrc command line: E431: Format error in tags file tags.vim Before byte 95 [] I don't know whether Vim expands the 'tags' option using the same internal code that drives glob(). If that is the case then simply passing flag=1 (internally) should fix the issue. Unless this is all intentional, in which case it seems appropriate IMHO to mention this behavior near :help 'tags' or :help 'suffixesadd'. Hi Peter This issue was discussed recently (a month ago) and there is already an item for it in :help todo.txt: Bug: searching for tags file uses 'suffixesadd', should not happen. (Dominique Pelle, 2010 June 28) Regards -- Dominique -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Is netrw broken or is my machine?
Hi list, I'm used to being able to do stuff like: :edit http://www.vim.org/ Because of the netrw plug-in. However when I execute the above command in Vim 7.3c I get a bunch of gibberish (binary data), which is apparently gzip-encoded data: :write !file - /dev/stdin: gzip compressed data, from Unix The strangest thing is that www.vim.org itself doesn't seem to use gzip compression, so somehow the gzip compression happens on my machine?! $ curl -s http://www.vim.org/ | file - /dev/stdin: HTML document text I tried upgrading to the latest version of the netrw plug-in* but now it's broken in a different way...: $ vim -u NONE -U NONE -c ':edit http://www.vim.org/' http://www.vim.org/; Illegal file name Can anyone tell me how to fix this? Thanks in advance :-) - Peter Odding * http://mysite.verizon.net/astronaut/vim/index.html#NETRW -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Is tagfiles() supposed to use suffixesadd?!
Dominique Pellé wrote: This issue was discussed recently (a month ago) and there is already an item for it in :help todo.txt: Bug: searching for tags file uses 'suffixesadd', should not happen. (Dominique Pelle, 2010 June 28) Thanks Dominique. I'll check todo.txt next time I want to report a bug. - Peter Odding -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Is netrw broken or is my machine?
On 2010-07-27, Peter Odding wrote: Hi list, I'm used to being able to do stuff like: :edit http://www.vim.org/ Because of the netrw plug-in. However when I execute the above command in Vim 7.3c I get a bunch of gibberish (binary data), which is apparently gzip-encoded data: :write !file - /dev/stdin: gzip compressed data, from Unix The strangest thing is that www.vim.org itself doesn't seem to use gzip compression, so somehow the gzip compression happens on my machine?! $ curl -s http://www.vim.org/ | file - /dev/stdin: HTML document text I tried upgrading to the latest version of the netrw plug-in* but now it's broken in a different way...: $ vim -u NONE -U NONE -c ':edit http://www.vim.org/' http://www.vim.org/; Illegal file name The netrw plugin won't be loaded if you start vim with -u NONE. Here's what I did to test the default netrw plugin without loading my own plugins. $ vim -u NONE :let rtp=$VIMRUNTIME :runtime! plugin/**/*.vim :edit http://www.vim.org/ works fine for me. I get an HTML file that includes this line: titlewelcome home : vim online/title That :runtime command is from :help load-plugins Can anyone tell me how to fix this? Thanks in advance :-) Not off-hand, but I hope that will give you a start in finding the problem. Regards, Gary -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: added completion to the :setfiletype command.
Dominique Pellé wrote:
Please try and review the attached patch.
It think it does what's needed and it's rather simple:
:setfiletype completes using things that match
$VIMRUNTIME/{syntax,ftplugin,indent}/*.vim and
~/.vim/{syntax,ftplugin,indent}/*.vim
:ownsyntax behaves as before, i.e. it completes using things that
match $VIMRUNTIME/syntax/*.vim and ~/.vim/syntax/*.vim
You can verify that :ownsyntax and :setfiletype complete
differently with this example:
:setfiletype hostCTRL-D
hostconf hostsaccess
:ownsyntax hostCTRL-D
hostconf
I have not done anything about the special files such as
syntax/2html.vim. I could hard-code something to exclude
them but it'd be ugly. Hopefully we can consider moving
those special files.
I send this patch again with slightly more elegant way of doing it
saving 3 lines of code. Sorry for the noise.
-- Dominique
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
diff -r da067045878f src/ex_docmd.c
--- a/src/ex_docmd.c Tue Jul 27 20:47:25 2010 +0200
+++ b/src/ex_docmd.c Wed Jul 28 00:01:06 2010 +0200
@@ -3831,8 +3831,12 @@
xp-xp_pattern = arg;
break;
+ case CMD_ownsyntax:
+ xp-xp_context = EXPAND_OWNSYNTAX;
+ xp-xp_pattern = arg;
+ break;
+
case CMD_setfiletype:
- case CMD_ownsyntax:
xp-xp_context = EXPAND_FILETYPE;
xp-xp_pattern = arg;
break;
diff -r da067045878f src/ex_getln.c
--- a/src/ex_getln.c Tue Jul 27 20:47:25 2010 +0200
+++ b/src/ex_getln.c Wed Jul 28 00:01:06 2010 +0200
@@ -4116,6 +4116,7 @@
if (context == EXPAND_HELP
|| context == EXPAND_COLORS
|| context == EXPAND_COMPILER
+ || context == EXPAND_OWNSYNTAX
|| context == EXPAND_FILETYPE
|| (context == EXPAND_TAGS fname[0] == '/'))
retval = vim_strnsave(fname, len);
@@ -4502,8 +4503,10 @@
return ExpandRTDir(pat, num_file, file, colors);
if (xp-xp_context == EXPAND_COMPILER)
return ExpandRTDir(pat, num_file, file, compiler);
+if (xp-xp_context == EXPAND_OWNSYNTAX)
+ return ExpandRTDir(pat, num_file, file, syntax);
if (xp-xp_context == EXPAND_FILETYPE)
- return ExpandRTDir(pat, num_file, file, syntax);
+ return ExpandRTDir(pat, num_file, file, {syntax,indent,ftplugin});
# if defined(FEAT_USR_CMDS) defined(FEAT_EVAL)
if (xp-xp_context == EXPAND_USER_LIST)
return ExpandUserList(xp, num_file, file);
@@ -4942,28 +4945,39 @@
}
#endif
+/* Used in qsort */
+static int cmp_str(s1, s2)
+const void *s1;
+const void *s2;
+{
+return STRCMP(*(char_u **)s1, *(char_u **)s2);
+}
+
/*
* Expand color scheme, compiler or filetype names:
- * 'runtimepath'/{dirname}/{pat}.vim
+ * 'runtimepath'/{dirnames}/{pat}.vim
+ * dirnames may contain one directory (ex: colorscheme) or can be a glob
+ * expression matching multiple directories (ex: {syntax,ftplugin,indent}).
*/
static int
-ExpandRTDir(pat, num_file, file, dirname)
+ExpandRTDir(pat, num_file, file, dirnames)
char_u *pat;
int *num_file;
char_u ***file;
-char *dirname; /* colors, compiler or syntax */
+char *dirnames; /* colors, compiler or syntax */
{
char_u *all;
char_u *s;
char_u *e;
garray_T ga;
+int i;
*num_file = 0;
*file = NULL;
-s = alloc((unsigned)(STRLEN(pat) + STRLEN(dirname) + 7));
+s = alloc((unsigned)(STRLEN(pat) + STRLEN(dirnames) + 7));
if (s == NULL)
return FAIL;
-sprintf((char *)s, %s/%s*.vim, dirname, pat);
+sprintf((char *)s, %s/%s*.vim, dirnames, pat);
all = globpath(p_rtp, s, 0);
vim_free(s);
if (all == NULL)
@@ -4993,6 +5007,26 @@
vim_free(all);
*file = ga.ga_data;
*num_file = ga.ga_len;
+
+if (*num_file 1)
+{
+ /* Sort and remove dupes which can happen when specifying multiple
+ * directories in dirnames such as {syntax,ftplugin,indent}
+ */
+ qsort(*file, *num_file, sizeof(char_u *), cmp_str);
+ for (i = *num_file - 1; i 0; i--)
+ {
+ if (STRCMP((*file)[i - 1], (*file)[i]) == 0)
+ {
+ /* Remove dupe (*file)[i] */
+ vim_free((*file)[i]);
+ if (*num_file - i - 1 0)
+ mch_memmove((*file)[i], (*file)[i + 1],
+ (*num_file - i - 1)*sizeof(char *));
+ --*num_file;
+ }
+ }
+}
return OK;
}
diff -r da067045878f src/vim.h
--- a/src/vim.h Tue Jul 27 20:47:25 2010 +0200
+++ b/src/vim.h Wed Jul 28 00:01:06 2010 +0200
@@ -774,7 +774,8 @@
#define EXPAND_PROFILE 35
#define EXPAND_BEHAVE 36
#define EXPAND_FILETYPE 37
-#define EXPAND_FILES_IN_PATH38
+#define EXPAND_FILES_IN_PATH 38
+#define EXPAND_OWNSYNTAX 39
/* Values for exmode_active (0 is no exmode) */
#define EXMODE_NORMAL 1
Re: Is netrw broken or is my machine?
Hi Gary, The netrw plugin won't be loaded if you start vim with -u NONE. Here's what I did to test the default netrw plugin without loading my own plugins. $ vim -u NONE :let rtp=$VIMRUNTIME :runtime! plugin/**/*.vim :edit http://www.vim.org/ works fine for me. I get an HTML file that includes this line: titlewelcome home : vim online/title Thanks, I didn't realize that -u NONE prevents plug-ins in $VIMRUNTIME from loading. This explains the Illegal file name message in my first e-mail. However I wasn't able to load the netrw plug-in using the commands you gave above, apparently because Vim starts in compatible mode. Unfortunately given the command line below Vim still starts with the same gibberish I described in my first e-mail: vim -u NONE -U NONE -N -c 'let rtp = $VIMRUNTIME | runtime! plugin/**/*.vim | edit http://www.vim.org/' - Peter Odding -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Windows 7 double-click file brings up empty vim
On Jul 20, 9:22 am, Garner Halloran garner...@gmail.com wrote: Using 7.3a BETA on Windows 7. If I double click on any file in explorer that has been associated with gvim it brings up an empty editor. I can drag the file into the window and it will work. I can right click and Edit with Vim and it will work. Gvim is my editor for p4v and if I double click a file there it works. What happens if you set up file associations manually? http://vim.wikia.com/wiki/Windows_file_associations This is probably a problem with the installer...maybe Windows 7 does file associations differently than previous Windows versions? If so we should update the tip as well as the installer. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Is netrw broken or is my machine?
On 2010-07-28, Peter Odding wrote: Hi Gary, The netrw plugin won't be loaded if you start vim with -u NONE. Here's what I did to test the default netrw plugin without loading my own plugins. $ vim -u NONE :let rtp=$VIMRUNTIME :runtime! plugin/**/*.vim :edit http://www.vim.org/ works fine for me. I get an HTML file that includes this line: titlewelcome home : vim online/title Thanks, I didn't realize that -u NONE prevents plug-ins in $VIMRUNTIME from loading. This explains the Illegal file name message in my first e-mail. However I wasn't able to load the netrw plug-in using the commands you gave above, apparently because Vim starts in compatible mode. Sorry, my bad. I did include -N for my test but neglected to include it above. Unfortunately given the command line below Vim still starts with the same gibberish I described in my first e-mail: vim -u NONE -U NONE -N -c 'let rtp = $VIMRUNTIME | runtime! plugin/**/*.vim | edit http://www.vim.org/' I may have found a clue. I started vim much as you did but with 'verbose' set to 9 and the output saved to a file. vim -u NONE -U NONE -i NONE -N -V9vimout -c 'let rtp = $VIMRUNTIME | runtime! plugin/**/*.vim | edit http://www.vim.org/' Before displaying the contents of the URL, Vim displayed this at the bottom of the screen: :!elinks 'http://www.vim.org/' -source '/tmp/vOjHkf8/0' /tmp/vOjHkf8/0 412L, 16869C /home/garyjohn Press ENTER or type command to continue The log file 'vimout' also contained some commands related to elinks. So I wonder if there might be something wrong or just different about your installation of elinks. If you don't have elinks, netrw might try to use some other program and there might be a problem with it. On this RHEL4 system, which elinks returns /usr/bin/elinks and elinks -version returns ELinks 0.9.2 - Text WWW browser. Try that and let's see what you get. Regards, Gary -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: added completion to the :setfiletype command.
2010/7/28 Dominique Pellé dominique.pe...@gmail.com:
I send this patch again with slightly more elegant way of doing it
saving 3 lines of code. Sorry for the noise.
From your patch:
+/* Used in qsort */
+static int cmp_str(s1, s2)
+const void *s1;
+const void *s2;
+{
+return STRCMP(*(char_u **)s1, *(char_u **)s2);
+}
+
...
+ /* Sort and remove dupes which can happen when specifying multiple
+* directories in dirnames such as {syntax,ftplugin,indent}
+*/
+ qsort(*file, *num_file, sizeof(char_u *), cmp_str);
+ for (i = *num_file - 1; i 0; i--)
+ {
+ if (STRCMP((*file)[i - 1], (*file)[i]) == 0)
+ {
+ /* Remove dupe (*file)[i] */
+ vim_free((*file)[i]);
+ if (*num_file - i - 1 0)
+ mch_memmove((*file)[i], (*file)[i + 1],
+ (*num_file - i - 1)*sizeof(char *));
+ --*num_file;
+ }
+ }
The code to achieve this (sort and remove duplicates) are already implemented
and you can reuse it in place of the codes above.
The functions misc2.c:sort_strings() and misc1.c:remove_duplicates()
can be used as-is.
You'll have to export misc1.c:remove_duplicates() though.
See the sample usage in misc1.c:9455.
nazri.
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Command autocompletion behaving strangely
On Tue, Jul 27, 2010 at 4:30 PM, Nazri Ramliy ayieh...@gmail.com wrote:
Please have a look at the patches - 0001 is the major one
One teeny fix for 0001:
for (i = 0; i gap-ga_len; i++)
{
- path = fnames[i];
+ char_u *path = fnames[i];
+ int is_in_curdir;
len = (int)STRLEN(path);
- /* we start at the end of the path */
- pathsep_p = path + len - 1;
+ char_u *dir_end = gettail(path);
^^ Move this line one or two lines up. Sorry I'm a bit
spoiled by C++ :)
nazri
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Question about :find completion support in Vim 7.3b
On Wed, Jul 28, 2010 at 2:44 AM, Nazri Ramliy ayieh...@gmail.com wrote: When I set 'path' to something like c:\src\** the completion doesn't work: :find tab has no effect. When the patch is applied on top of my patches sent in [1], vim (on Windows) crashes. I'll investigate this later. nazri. [1] http://article.gmane.org/gmane.editors.vim.devel/27393 -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Is read-only text possible in vim?
On Tue, Jul 27, 2010 at 11:04 PM, Ben Fritz fritzophre...@gmail.com wrote: On Jul 27, 2:55 am, winterTTr winterttr@gmail.com wrote: I know that we can use the set nomodifiable to make a buffer read-only, which makes all the text in it not modifiable. But is it possible to make some text in a buffer read-only but not for the whole buffer? I mean maybe we can bind a property to the string ( or text, or character ) , which can make the text read-only in a modifiable buffer. Or even finally, We can make the text not only a plain text, but text binding some properties set to different value to control the different aspects, such as highlighting, read-only, or even font. Maybe, conceal can also be one property of a text. :-) I'm curious what your end goal is. Making only part of the buffer text read-only is probably not a trivial task. Knowing why you want this may help come up with some alternative solutions to the problem you are trying to solve. OK, maybe just a user experience problem. Let me give an example When you want to edit the text between the xml tag, such as textediting here/text If i can force the text and /text to be read-only, which prevents deleting the tag, it maybe more convenient for me SOMETIMES. OK, until now, i can use selection-mode/visual-mode to select the text between tag and edit them, but it does not limit the edit area. Actually, this not a good example, but just for showing an idea. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Is netrw broken or is my machine?
Gary Johnson wrote: I may have found a clue. I started vim much as you did but with 'verbose' set to 9 and the output saved to a file. vim -u NONE -U NONE -i NONE -N -V9vimout -c 'let rtp = $VIMRUNTIME | runtime! plugin/**/*.vim | edit http://www.vim.org/' Before displaying the contents of the URL, Vim displayed this at the bottom of the screen: :!elinks 'http://www.vim.org/' -source '/tmp/vOjHkf8/0' /tmp/vOjHkf8/0 412L, 16869C /home/garyjohn Press ENTER or type command to continue The log file 'vimout' also contained some commands related to elinks. So I wonder if there might be something wrong or just different about your installation of elinks. If you don't have elinks, netrw might try to use some other program and there might be a problem with it. On this RHEL4 system, which elinks returns /usr/bin/elinks and elinks -version returns ELinks 0.9.2 - Text WWW browser. Try that and let's see what you get. Thanks to your hints I seem to have found the problem. On my system elinks doesn't exist so netrw tries links, which does exist: $ which links /usr/bin/links $ man links # calls it links2 But with a twist (?): $ links http://www.vim.org/ -source | file - /dev/stdin: gzip compressed data, from Unix After I realized that /usr/bin/links was the problem I switched to curl and now netrw works again, so I found a decent workaround: vim -u NONE -U NONE -i NONE -Nc 'let rtp = $VIMRUNTIME | let g:netrw_http_cmd=curl | let g:netrw_http_xcmd=-o | runtime! plugin/**/*.vim | set more | edit http://www.vim.org/' In case anyone else out there has this problem: I'm running Ubuntu 9.10 and using the above two :let commands (which I can add to my ~/.vimrc script) the netrw plug-in works again. Cheers, - Peter Odding -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Bug in syntax/perl.vim
If one has:
else # Here is a comment
the comment section is shown as an error, this is due to line 219 of
perl.vim. It should be (as one possibility):
syn match perlElseIfError [^[:space:]{#]\+ contained
There may be other cases this will fail on, but it fixes the problem
with comments.
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Is netrw broken or is my machine?
On Wed, Jul 28, 2010 at 02:55:16AM +0200, Peter Odding wrote: Gary Johnson wrote: I may have found a clue. I started vim much as you did but with 'verbose' set to 9 and the output saved to a file. vim -u NONE -U NONE -i NONE -N -V9vimout -c 'let rtp = $VIMRUNTIME | runtime! plugin/**/*.vim | edit http://www.vim.org/' Before displaying the contents of the URL, Vim displayed this at the bottom of the screen: :!elinks 'http://www.vim.org/' -source '/tmp/vOjHkf8/0' /tmp/vOjHkf8/0 412L, 16869C /home/garyjohn Press ENTER or type command to continue The log file 'vimout' also contained some commands related to elinks. So I wonder if there might be something wrong or just different about your installation of elinks. If you don't have elinks, netrw might try to use some other program and there might be a problem with it. On this RHEL4 system, which elinks returns /usr/bin/elinks and elinks -version returns ELinks 0.9.2 - Text WWW browser. Try that and let's see what you get. Thanks to your hints I seem to have found the problem. On my system elinks doesn't exist so netrw tries links, which does exist: $ which links /usr/bin/links $ man links # calls it links2 But with a twist (?): $ links http://www.vim.org/ -source | file - /dev/stdin: gzip compressed data, from Unix Sounds like links sends Accept-Encoding: gzip when it requests the page. You can see a similar difference in curl -I http://www.vim.org/; vs. curl -I -H 'Accept-Encoding: gzip' http://www.vim.org/;. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Bug in syntax/perl.vim
On Tue, Jul 27, 2010 at 05:57:38PM -0700, batz wrote:
If one has:
else # Here is a comment
the comment section is shown as an error, this is due to line 219 of
perl.vim. It should be (as one possibility):
syn match perlElseIfError [^[:space:]{#]\+ contained
There may be other cases this will fail on, but it fixes the problem
with comments.
You should contact the author (listed at the top of the file) either via
email or by filing a bug in the issue tracker on the github project[0].
[0]: http://github.com/petdance/vim-perl/issues
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
signature.asc
Description: Digital signature
Re: Bug in syntax/perl.vim
On Tue, 27 Jul 2010, James Vega wrote: You should contact the author (listed at the top of the file) either via email or by filing a bug in the issue tracker on the github project[0]. Just to jump in here, neither of these things worked for me. The syntax/perl.vim file broke syntax based folding of subroutines at some point. I reported it to the maintainer listed in the file and he said to post it on the github issues page. It's been about two weeks now and there's no fix or even any feedback. I was hoping my issue would be fixed for the 7.3 stable release, but I suspect it will not happen. I would take a stab at fixing it myself, but for some reason, despite reading through the documentation more than once, Vim's syntax highlighting engine is impenetrable voodoo to me. I'm able to do simple things with it, but the Perl syntax rules are far from simple. - Christian -- Christian J. Robinson hept...@gmail.com -- http://christianrobinson.name/ -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: vim73brt+vim73bole can't run under windows 2000 sp4
On Mon, 26 Jul 2010 22:50:17 +0800, Bram Moolenaar b...@moolenaar.net wrote: Yue Wu wrote: I've downloaded vim73 beta(rt.zip+old.zip), after extract them and run gvim.exe, it warns: gvim is not a valid Win32 application. My OS is windows 2000 sp4. I have build the executable with the MSVC 2010 tools. The binary runs fine on my Windows XP system. But perhaps older systems are not supported by this compiler? I could go back to MSVC 2008, but I'm not sure all the 64 bit stuff works then. We defenitely want to support Windows 7 64bit, it's rapidly becoming wide spread. Sorry for long delay, how about a version for older windows(before XP) please? -- Regards, Yue Wu Key Laboratory of Modern Chinese Medicines Department of Traditional Chinese Medicine China Pharmaceutical University No.24, Tongjia Xiang Street, Nanjing 210009, China -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
[PATCH] Fix mishandling of Perl indent levels with folding
GetPerlSyntax() was testing for the syntax items 'perlBEGINENDFold' and
'perlIfFold', neither of which exists any more. The patch tests for
'perlBlockFold' instead. ('perlPackageFold' doesn't affect testing for
braces).
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
# HG changeset patch
# User Benjamin R. Haskell v...@benizi.com
# Date 1280285167 14400
# Branch vim73
# Node ID 9ebb356afea420c871ce4674d502a01b1c0a30a3
# Parent 6de9efd58dc0d68cfeb28b7334ad7dc908ca2365
Fix mishandling of Perl indent levels with folding.
GetPerlSyntax() was testing for the syntax items 'perlBEGINENDFold' and
'perlIfFold', neither of which exists any more. The patch tests for
'perlBlockFold' instead. ('perlPackageFold' doesn't affect testing for
braces).
diff -r 6de9efd58dc0 -r 9ebb356afea4 runtime/indent/perl.vim
--- a/runtime/indent/perl.vim Tue Jul 27 22:50:12 2010 +0200
+++ b/runtime/indent/perl.vim Tue Jul 27 22:45:43 2010 -0400
@@ -133,7 +133,7 @@
\ || synid == perlMatchStartEnd
\ || synid == perlHereDoc
\ || synid =~ ^perlFiledescStatement
- \ || synid =~ '^perl\(Sub\|BEGINEND\|If\)Fold'
+ \ || synid =~ '^perl\(Sub\|Block\)Fold'
let brace = strpart(line, bracepos, 1)
if brace == '(' || brace == '{'
let ind = ind + sw
@@ -148,7 +148,7 @@
let synid = synIDattr(synID(v:lnum, bracepos, 0), name)
if synid ==
\ || synid == perlMatchStartEnd
- \ || synid =~ '^perl\(Sub\|BEGINEND\|If\)Fold'
+ \ || synid =~ '^perl\(Sub\|Block\)Fold'
let ind = ind - sw
endif
endif
Re: [PATCH] Fix mishandling of Perl indent levels with folding
On Tue, 27 Jul 2010, Benjamin R. Haskell wrote:
GetPerlSyntax() was testing for the syntax items 'perlBEGINENDFold' and
'perlIfFold', neither of which exists any more. The patch tests for
'perlBlockFold' instead. ('perlPackageFold' doesn't affect testing for
braces).
[Hmm. Yet another thing I need to learn with mercurial. Expected to be
able to edit the email text à la git send-email --annotate...]
This is the hg-ified version of the patch I sent back in February to fix
this. I never followed up w/ Andy (as James also suggested back then).
CC:'ed now.
--
Best,
Ben
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
BUG: echo_string incorrectly detects a structure as recursive
To reproduce:
:echo repeat([{'a':'1'}], 2)
[{'a': '1'}, {...}]
expected output: [{'a': '1'}, {'a': '1'}]
:echo repeat([[0]], 2)
[[0], [...]]
expected output: [[0], [0]]
This seems to be caused by echo_string deciding that the data
structure is recursive, despite the fact that it definitely shouldn't
be.
~Matt
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
[patch] Add logcheck filetype
Bram, Attached patch adds support for detecting logcheck's[0] rules files[1] as the logcheck filetype. The one use, so far, is to disable automatic wrapping of text since each line is supposed to contain a single regular expression. [0]: http://logcheck.alioth.debian.org/ [1]: http://logcheck.alioth.debian.org/docs/README.logcheck-database -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com diff --git a/runtime/filetype.vim b/runtime/filetype.vim --- a/runtime/filetype.vim +++ b/runtime/filetype.vim @@ -993,6 +993,9 @@ LiteStep RC files au BufNewFile,BufRead */LiteStep/*/*.rc setf litestep + Logcheck files +au BufNewFile,BufRead /etc/logcheck/*.d*/* setf logcheck + Login access au BufNewFile,BufRead /etc/login.access setf loginaccess diff --git a/runtime/ftplugin/logcheck.vim b/runtime/ftplugin/logcheck.vim new file mode 100644 --- /dev/null +++ b/runtime/ftplugin/logcheck.vim @@ -0,0 +1,17 @@ + Vim filetype plugin file + Language:Logcheck + Maintainer: Debian Vim Maintainers pkg-vim-maintain...@lists.alioth.debian.org + Last Change: 2010-07-27 + License: GNU GPL, version 2.0 + URL: http://hg.debian.org/hg/pkg-vim/vim/file/unstable/runtime/ftplugin/logcheck.vim + +if exists(b:did_ftplugin) +finish +endif +let b:did_ftplugin = 1 + +let b:undo_ftplugin = setl fo + + Do not hard-wrap non-comment lines since each line is a self-contained + regular expression +setlocal formatoptions-=t signature.asc Description: Digital signature
Re: Bug in syntax/perl.vim
On Tue, 27 Jul 2010, Christian J. Robinson wrote:
On Tue, 27 Jul 2010, James Vega wrote:
You should contact the author (listed at the top of the file) either
via email or by filing a bug in the issue tracker on the github
project[0].
Gah. Blech. Issue tracking is not one of github's strong points, but I
suppose anything is better than nothing [...-]
Just to jump in here, neither of these things worked for me.
The syntax/perl.vim file broke syntax based folding of subroutines at
some point. I reported it to the maintainer listed in the file and he
said to post it on the github issues page. It's been about two weeks
now and there's no fix or even any feedback.
[-...] except when anything is nothing.
I was hoping my issue would be fixed for the 7.3 stable release, but I
suspect it will not happen.
I would take a stab at fixing it myself, but for some reason, despite
reading through the documentation more than once, Vim's syntax
highlighting engine is impenetrable voodoo to me. I'm able to do
simple things with it, but the Perl syntax rules are far from simple.
Before this thread (since I didn't follow up on it last time), I didn't
realize there was a repository for the Perl-related runtime files. The
files from there seem to have corrected the problem as I noticed it.
(steps to update below).
I also checked out the repo myself and added the rest of my patch that
wasn't already 'applied' ('applied' == 'independently rediscovered').
New repo at benizi/vim-perl
It would be nice if the petdance/vim-perl repo changes make it into the
release.
--
Best,
Ben
### check out the repository:
$ git clone http://github.com/petdance/vim-perl.git
### [... checked out into vim-perl/.git ...]
### make sure the required dirs exist:
$ mkdir -p ~/.vim/{syntax,indent,ftplugin}
### copy the files to the right places:
$ for l in syntax indent ftplugin ; do cp vim-perl/$l/perl.vim ~/.vim/$l/ ; done
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: GTK tear-off menus are not working
On Tue, Jul 20, 2010 at 4:23 PM, Dennis Benzinger dennis.benzin...@gmx.net wrote: Am 20.07.2010 13:30, schrieb Bram Moolenaar: James - I wonder if you noticed this problem: When I tear-off a menu in GTK, for example the Help menu, the buttons don't do anything. I have the same problem in Vim 7.2 and 7.3b, it might have something to do with the GTK version. I can't recall when it stopped working. Can others reproduce this problem? Does someone know how to fix this? FWIW, I have the same problem with 7.2 and 7.3 on Ubuntu 10.04. But if I tear off a menu with a submenu (e.g. the edit menu) then the menu items in the submenu (e.g. turn off toolbar) work. If you tear off the submenu itself (e.g. Global Settings) the menu items don't work. Regards, Dennis Benzinger -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php Not sure if this information is helpful, but as of gtk 2.20 the tear-off function was declared deprecated (there was quite some discussion about this). If the gtk library was compiled with #define GTK_DISABLE_DEPRECATED in your distro, it might simply be disabled. My Slackware still uses the 2.18.9 version of gtk, so I can't check it here (and the tear-off functions still work). Niels -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Bug in syntax/perl.vim
On Tue, 27 Jul 2010, batz wrote:
If one has:
else # Here is a comment
the comment section is shown as an error, this is due to line 219 of
perl.vim. It should be (as one possibility):
syn match perlElseIfError [^[:space:]{#]\+ contained
There may be other cases this will fail on, but it fixes the problem
with comments.
Fixed this in my fork[1] of Andy's vim-perl repo on Github. I changed it to:
syn match perlElseIfError \s\+if contained
which makes the 'if' show up as an error if you accidentally use 'else
if' instead of 'elsif'. Also added 'elseif' as an error.
Hopefully it'll get pulled back into the 'real' repo, and all of it'll
get into Vim 7.3.
(Andy, CC:'ed here. Also sent a 'pull request'... but I'm a bit of a
github n00b when it comes to actual collaboration.)
--
Best,
Ben
[1] http://github.com/benizi/vim-perl/commit/ddf895
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: added completion to the :setfiletype command.
Nazri Ramliy wrote:
2010/7/28 Dominique Pellé dominique.pe...@gmail.com:
I send this patch again with slightly more elegant way of doing it
saving 3 lines of code. Sorry for the noise.
From your patch:
+/* Used in qsort */
+static int cmp_str(s1, s2)
+ const void *s1;
+ const void *s2;
+{
+ return STRCMP(*(char_u **)s1, *(char_u **)s2);
+}
+
...
+ /* Sort and remove dupes which can happen when specifying multiple
+ * directories in dirnames such as {syntax,ftplugin,indent}
+ */
+ qsort(*file, *num_file, sizeof(char_u *), cmp_str);
+ for (i = *num_file - 1; i 0; i--)
+ {
+ if (STRCMP((*file)[i - 1], (*file)[i]) == 0)
+ {
+ /* Remove dupe (*file)[i] */
+ vim_free((*file)[i]);
+ if (*num_file - i - 1 0)
+ mch_memmove((*file)[i], (*file)[i + 1],
+ (*num_file - i - 1)*sizeof(char *));
+ --*num_file;
+ }
+ }
The code to achieve this (sort and remove duplicates) are already implemented
and you can reuse it in place of the codes above.
The functions misc2.c:sort_strings() and misc1.c:remove_duplicates()
can be used as-is.
You'll have to export misc1.c:remove_duplicates() though.
See the sample usage in misc1.c:9455.
nazri.
Thanks for having a look Nazri. I'll update the patch later today with
your comments. Some remarks though:
* yes, I can reuse sort_strings() as-is (I'll do that)
* I could also reuse remove_duplicates() but it has a slightly
different behavior since it calls fnamecmp() instead of
STRCMP() to check for dupes. I wonder whether that's
desirable here. I think it's better to use STRCMP() in my case.
Remark about remove_duplicate() in misc1.c: It'd be slightly better
if remove_duplicates(...) looped backward (as in my function) to
avoid doing more moves than necessary when there are dupes (and
to compare with 0 in exit condition which is also cheaper). Say you
have to remove dupes in this pathological case:
x, x, x, ... x, x (n times)
remove_duplicate() as currently implemented would do (n-1)*n/2
moves (that's O(n^2)) whereas when looping backward() as in my
function, it does 0 moves. Looping backward will always do less
moves since it avoids moving duplicates already removed.
Cheers
-- Dominique
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: added completion to the :setfiletype command.
2010/7/28 Dominique Pellé dominique.pe...@gmail.com: * I could also reuse remove_duplicates() but it has a slightly different behavior since it calls fnamecmp() instead of STRCMP() to check for dupes. I wonder whether that's desirable here. I think it's better to use STRCMP() in my case. In that case maybe remove_duplicate can be modified to accept a second argument which is a function pointer to be used as the string comparator. Remark about remove_duplicate() in misc1.c: It'd be slightly better if remove_duplicates(...) looped backward (as in my function) to avoid doing more moves than necessary when there are dupes (and to compare with 0 in exit condition which is also cheaper). Say you have to remove dupes in this pathological case: x, x, x, ... x, x (n times) remove_duplicate() as currently implemented would do (n-1)*n/2 moves (that's O(n^2)) whereas when looping backward() as in my function, it does 0 moves. Looping backward will always do less moves since it avoids moving duplicates already removed. That is indeed the better implementation. I didn't notice the difference the first time I looked at your loop. nazri. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Is read-only text possible in vim?
On Wed, July 28, 2010 2:54 am, winterTTr wrote: Let me give an example When you want to edit the text between the xml tag, such as textediting here/text If i can force the text and /text to be read-only, which prevents deleting the tag, it maybe more convenient for me SOMETIMES. OK, until now, i can use selection-mode/visual-mode to select the text between tag and edit them, but it does not limit the edit area. You can use my Narrow Region plugin (http://www.vim.org/scripts/script.php?script_id=3075), which opens the selected region in a new window and allows you to do all kind of modifications, whithout affecting the original file. regards, Christian -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Should 2html generate valid CSS by default?
I've taken over as maintainer of the TOhtml plugin during Vim 7.3 development. Something that's bugged me a little for some time about 2html, is that the current default is to NOT use CSS, but rather use old-style font, b, i, and other tags for markup. The :help says: By default, HTML optimized for old browsers is generated. If you prefer using cascading style sheets (CSS1) for the attributes (resulting in considerably shorter and valid HTML 4 file), use: :let g:html_use_css = 1 At this point, I'd consider old browsers to be Internet Explorer 6 and the like. I think the time has come to default g:html_use_css to true, by including this line in the tohtml.vim plugin file. A user could still disable this option by unletting it manually, or in an after/plugin file. I can personally think of no compelling reason not to do this. But, to avoid offending a lot of people out of my own ignorance... Are there any good reasons to keep the default behavior of generating markup that does not use basic CSS1? Please respond if you have concerns. I do plan to maintain the old non-CSS markup generation, at least to some extent. Some features, such as the diff view added in 7.3, will be less pretty, and others such as dynamic folding will be completely unavailable, but I hope to keep the basic functionality working and probably even fix a few existing bugs. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Is read-only text possible in vim?
On 28/07/10 02:54, winterTTr wrote: On Tue, Jul 27, 2010 at 11:04 PM, Ben Fritz fritzophre...@gmail.com http://gmail.com wrote: On Jul 27, 2:55 am, winterTTr winterttr@gmail.com mailto:winterttr@gmail.com wrote: I know that we can use the set nomodifiable to make a buffer read-only, which makes all the text in it not modifiable. But is it possible to make some text in a buffer read-only but not for the whole buffer? I mean maybe we can bind a property to the string ( or text, or character ) , which can make the text read-only in a modifiable buffer. Or even finally, We can make the text not only a plain text, but text binding some properties set to different value to control the different aspects, such as highlighting, read-only, or even font. Maybe, conceal can also be one property of a text. :-) I'm curious what your end goal is. Making only part of the buffer text read-only is probably not a trivial task. Knowing why you want this may help come up with some alternative solutions to the problem you are trying to solve. OK, maybe just a user experience problem. Let me give an example When you want to edit the text between the xml tag, such as textediting here/text If i can force the text and /text to be read-only, which prevents deleting the tag, it maybe more convenient for me SOMETIMES. OK, until now, i can use selection-mode/visual-mode to select the text between tag and edit them, but it does not limit the edit area. Vim has a notion of |text-objects| (q.v.). In Normal mode, cit (Change Inside Tag, without the quotes) will change the text between the tags, not touching them (and since the c command puts you in Insert, not Replace, mode, you won't delete them.) Conversely, dat (still without the quotes, and with a rather than i) deletes the tags and the content between them. Oh, and don't forget the power of undo! Actually, this not a good example, but just for showing an idea. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php Best regards, Tony. -- Show respect for age. Drink good Scotch for a change. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
