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
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
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
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
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
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
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
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
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
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
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
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
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?
- 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.
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
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
---
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
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
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
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
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
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
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
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 -
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
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
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
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...
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:
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
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
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?
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
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
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
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
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
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
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:
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
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:
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
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
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
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
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
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;
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.
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
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
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.
--
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!
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
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
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
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!
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
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
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]:
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
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
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
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
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.
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
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
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
67 matches
Mail list logo
