Hi,
Could we have this fix in vim73?
I did email original author of indent/vb.vim -- Johannes Zellner
but had no reply.
Maxim.
-- Forwarded message --
From: Maxim Kim
Date: 20 авг 2009, 10:58
Subject: VisualBasic 'elseif' indent error
To: vim_dev
Hi,
I have just found thatv
Hello vimmers!
I did spot that "setlocal iskeyword+=-" breaks syntax highlight for css (and
derived sass). I am using this iskeyword modification to improve behaviour of
word completion and word selection for these file types.
Attached a patch to css.vim that fixes this for font-*, small-* and
b
On 28/07/10 02:54, winterTTr wrote:
On Tue, Jul 27, 2010 at 11:04 PM, Ben Fritz http://gmail.com>> wrote:
On Jul 27, 2:55 am, winterTTr mailto:winterttr@gmail.com>> wrote:
> I know that we can use the "set nomodifiable" to make a buffer
read-only,
> which makes all the
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
, , , and other tags for markup.
The :help says:
> By default, HTML optimized for
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 editing
> here
> If i can force the and to be read-only, which prevents
> deleting the tag,
> it maybe more convenient for me SOMETIMES.
> OK, until now, i can us
2010/7/28 Dominique Pellé :
> * 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 rem
Nazri Ramliy wrote:
> 2010/7/28 Dominique Pellé :
>> 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;
> +{
> +
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 o
On Tue, Jul 20, 2010 at 4:23 PM, Dennis Benzinger
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
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 g
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.al
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 sho
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 anoth
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 Mon, 26 Jul 2010 22:50:17 +0800, Bram Moolenaar
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
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 fol
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 cas
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
> >| runti
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.
-
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 conten
On Tue, Jul 27, 2010 at 11:04 PM, Ben Fritz wrote:
>
>
> On Jul 27, 2:55 am, winterTTr 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 no
On Wed, Jul 28, 2010 at 2:44 AM, Nazri Ramliy wrote:
> When I set 'path' to something like "c:\src\**" the completion doesn't work:
>
> :find
>
> 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] htt
On Tue, Jul 27, 2010 at 4:30 PM, Nazri Ramliy 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(
2010/7/28 Dominique Pellé :
> 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
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
> >
On Jul 20, 9:22 am, Garner Halloran 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 wor
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 HTM
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,
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 d
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
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:
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
Bram Moolenaar wrote:
> Dominique Pelle wrote:
>
>> Peter Odding wrote:
>>
>> > Ingo Karkat wrote:
>> >>
>> >> Granted, most filetypes do define custom highlighting via a
>> >> $VIMRUNTIME/syntax/.vim script. But shouldn't the filetype
>> >> completion
>> >> also take into account files from the f
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
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
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 s
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 wrote:
>
> > Using 7.3a BETA on Windows 7. If
Dominique Pelle wrote:
> Peter Odding wrote:
>
> > Ingo Karkat wrote:
> >>
> >> Granted, most filetypes do define custom highlighting via a
> >> $VIMRUNTIME/syntax/.vim script. But shouldn't the filetype
> >> completion
> >> also take into account files from the ftplugin and syntax directories,
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
Date: Sat, Jul 24, 2010 at 12:33 PM
Subject: Win32 flicker
To: vim-
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 fro
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
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 /
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
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 wrote:
> Using 7.3a BETA on Windows 7. If I double click on any file in explorer
> tha
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 ap
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
On Tue, Jul 27, 2010 at 10:55 AM, Ajit Thakkar wrote:
> On Mon, Jul 26, 2010 at 9:16 PM, Nazri Ramliy wrote:
>> On Tue, Jul 27, 2010 at 6:01 AM, Yegappan Lakshmanan
>> wrote:
>>
>>> When I press after typing ":find ", I expected that the filenames from
>>> the current directory will be complete
Peter Odding wrote:
> Ingo Karkat wrote:
>>
>> Granted, most filetypes do define custom highlighting via a
>> $VIMRUNTIME/syntax/.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 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 m
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 Jul 27, 2:55 am, winterTTr 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
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 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 n
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/syn
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
- Message transféré
De : Dimitar DIMITROV
À : Bram Moolenaar
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
> >
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? O
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
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
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
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
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
t
Ingo Karkat wrote:
Granted, most filetypes do define custom highlighting via a
$VIMRUNTIME/syntax/.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
On Tue, Jul 27, 2010 at 4:30 PM, Nazri Ramliy 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 yo
On Sat, Jul 24, 2010 at 8:59 AM, Nazri Ramliy 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 co
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 ca
Dominique Pelle wrote:
> Bram Moolenaar 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 java
> >> > jav
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
> An: Roland Puntaier
> Kopie: vim_dev@googlegroups.com
> Datum: 25.07.2010 14:24
> Betreff: Vim 7.3: Python3
68 matches
Mail list logo
