Re: [vim/vim] Defaulting mouse=a in a terminal is incorrect (new as of 7.4.2111) (#2841)

[François Ingelrest]

Hello,

On Tue, 13 Dec 2022 at 02:31, Alex von Gluck IV 
wrote:

> Shift makes no difference for me. Can you provide documentation on what
> shift is supposed to do?
>
> I can reference the FreeDesktop clipboard specification which doesn't
> mention anything about required modifiers:
>
> https://specifications.freedesktop.org/clipboards-spec/clipboards-0.1.txt
>

Can't you automatically alias vim to vim -c 'set mouse=' when you ssh into
a machine ?

Something like this :

ssh -t MY_MACHINE 'bash --init-file <(echo "alias vim=\"vim -c \\\"set
mouse=\\\"\"")'

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/CALs0%3D_74hVAh96eRdhi%2B6gs_4BWYd3qzw2HO5ecwKvjASaoGWw%40mail.gmail.com.

Re: how to get old versions of vim

[François Ingelrest]

Hi,

On Sat, 27 Aug 2022 at 06:56, Charles Campbell  wrote:
> So, I thought what I'd like to do is to get vim 9.0 back (with no
> patches) and see if that worked. Then, if the plugin continues to
> misbehave, then I'd like to get vim 8.0. Once I have a version of vim
> where the plugin works I'd like to use git bisect to find the
> problematic patch. I realize that I'd have to learn more git. So, how to
> get vim 9.0, vim 8.0?

I've never used git bisect myself, but AFAICT it will check out the
revisions by itself each time you tell it whether the current revision
is good or bad. As to find the initial good/bad commits, you can
simply use e.g., "git checkout v9.0.". The command "git tag" will
tell you all the tags you can check out.

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/CALs0%3D_6LzF6ceXg9STxd1K9MFnnnk%2B9R2JRj2Rp0sfAPQFENpA%40mail.gmail.com.

netrw v165 seems to ignore sort sequence

[François Ingelrest]

Hi all,

I recently updated my vim to v8.1.1824, including netrw which is now v165.

When sorting by name, directories and files are now mixed up among
other things. I'm not sure whether this is a bug or if I didn't get
how to use g:netrw_sort_sequence, but this variable seems to be
ignored which could be the cause of the initial issue. I've tried
various sequences including the default one, but the file listing
seems unaffected.

Thanks!

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/CALs0%3D_6OQ0BUx0bwbgPVKgPGka0o4m7OuDz%2BHN%3DVo96YSPR4og%40mail.gmail.com.

Re: Off-by-one error in varsofttabstop description?

[François Ingelrest]

BTW, I'm sorry if this has been asked before as I didn't have time to
catch all my emails recently, but if the vartab feature is to be used
for column editing (and it's great at that), wouldn't it be more
logical to provide the columns where to stop at rather than the length
of tabs?

For instance, I have a configuration file where columns starts at 4,
13, 23, 31, 60, which means I had to go through the computation of the
vsts option to end up with vsts=3,9,10,8,29. It's not that complicated
and it has to be done only once, but providing the actual tab stops
would be easier. Also, adding a tab stop means recomputing the whole
sequence, while with the actual list of tab stops this would require
adding a single value to the list.

Anyway, this feature is already really useful to me for editing column
based files. Thanks for it!

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Off-by-one error in varsofttabstop description?

[François Ingelrest]

Hello,

:h varsofttabstop reads :

For example, when editing assembly language files where statements
start in the 8th column and comments in the 40th, it may be useful
to use the following:
:set varsofttabstop=8,32,8

To me, this will move the cursor to the 9th (inserting 8 spaces) and
41th columns (inserting 8 + 32 spaces) since the cursor starts at
column 1.

Shouldn't it rather be " :set varsofttabstop=7,32,8 " ?

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Moving away from SourceForge

[François Ingelrest]

On 22 February 2018 at 03:55, Christian J. Robinson wrote:
> _Please_ make it possible to use http://vim.org, even if it just
> automatically redirects to http://www.vim.org.  Your own reply here shows
> why it's needed.

It's been asked again and again for years, e.g.,
https://groups.google.com/d/topic/vim_dev/tyTTlowNg5s/discussion

For some reason, the person in charge of the DNS (I don't think it's
Bram) is kind of old-school and dogmatic, and has decided that vim.org
is the domain name and not the address of the website. While true,
this was and is still a ridiculous justification of a stubborn
behavior.

Oh well...

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: '?12$p' shows at the first line, since Vim 8.0.1009

[François Ingelrest]

Hi,

On 30 August 2017 at 18:59, Bram Moolenaar wrote:
> I made the check > 4000, thus 3801 would indeed not match.
> Let's make it > 3000 then.

Works fine now, thanks for taking care of this.

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: '?12$p' shows at the first line, since Vim 8.0.1009

[François Ingelrest]

Hi,

On 30 August 2017 at 13:48, Bram Moolenaar wrote:
> I'm getting tired of those terminals that say they are xterm while they
> are not...
>
> My gnome-terminal reports this version:  [>1;4402;0c
> What does yours say?
> Since a real xterm only has a version in the 300 range now, we could
> take a version >4000 as Gnome perhaps?

Not sure whether patch 8.0.1016 was supposed to fixed this for
everyone, but I'm still having this issue after patch 8.0.1018. My
version is [>1;3801;0c, so not > 4000 (this is with Debian 8, the
oldstable).

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: '?12$p' shows at the first line, since Vim 8.0.1009

[François Ingelrest]

Hi,

On 29 August 2017 at 20:18, Bram Moolenaar wrote:
> Gnome terminal can't handle a standard xterm escape sequence?
> The escape sequence is correct, it works fine on any xterm.
> I verified it correctly gets us the right cursor blink mode.
>
> I don't see this problem in a gnome-terminal on my system:
> GNOME Terminal 3.20.2

I can reproduce it on my system (Debian 8 / Gnome Terminal 3.14.1).
When trying with « vim --clean », I can see the sequence briefly
appearing before automatically disappearing. Not sure whether that
means that it's correctly handled by Gnome Terminal.

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Cryptic characters displayed in :term buffer when switching between buffers

[François Ingelrest]

Hi,

On 17 August 2017 at 16:55, Bram Moolenaar wrote:
> OK, then try this:
> :set t_SH=

Thanks, this fixes the issue. I guess it is related to this discussion:

https://groups.google.com/d/topic/vim_dev/TFYu5FtOA30/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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Cryptic characters displayed in :term buffer when switching between buffers

[François Ingelrest]

Hi,

On 17 August 2017 at 14:24, James McCoy wrote:
> What exactly are the extra characters you're seeing?  At a guess, it's
> something like "[2 q".  If so, that's because libvte (until relatively
> recently) passed through control codes that it didn't understand, which
> meant they were printed to your terminal.  That particular control code
> is the one to control the shape of the cursor.

First character is cryptic (see attached screenshot) but that could
well be "[1 q" I guess.

On 17 August 2017 at 14:36, Bram Moolenaar wrote:
> See if you recognize the characters in the ":set termcap" output.
> You can also use the "script" program to record what is going over the
> line.  And you can use:
> call ch_logfile('name', 'w')
> to log the I/O.

ch_logfile() doesn't provide any useful information, but according to
script that would be "<1b>[1 q".

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Cryptic characters displayed in :term buffer when switching between buffers

[François Ingelrest]

Hi Bram,

On 16 August 2017 at 21:09, Bram Moolenaar wrote:
> I don't see this.  Most likely related to using Gnome.  Have you tried
> using an xterm?

I don't see this with an xterm or even in a console outside of X, so
it may indeed have something to do with gnome-terminal. Anything I
could do to help solving this matter?

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Setting t_RB breaks :term background color

[François Ingelrest]

Hi Bram,

On 16 August 2017 at 22:46, Bram Moolenaar wrote:
> If I use a dark color them: ":colors darkblue", and open a terminal with
> :term, then the terminal window has a dark background.
>
> libvterm does not recognize t_RB, I don't see how it matters.  Perhaps
> your 'background' value in Vim is actually not set to "dark"?

You are right, setting background to dark solves the issue.

I'm not sure I understand why, since according to :h background
setting this option does not set the background color. Shouldn't the
background color of normal buffers be used in terminal buffers as
well?

Anyway, thanks for the help!

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Cryptic characters displayed in :term buffer when switching between buffers

[François Ingelrest]

Hi all,

When I do this:
 1. vim -u NONE
 2. :term
 3. c-w w
 4. c-w w

At step 4, the :term buffer gets the focus but a few bytes seem to be
sent to the buffer as well. They're displayed right over my prompt on
the first line, first column, and there doesn't seem to be a way to
get rid of them.

This is using Vim 8.0.0946 under a Debian 8 and a Gnome terminal.

Thanks.

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Setting t_RB breaks :term background color

[François Ingelrest]

Hi all,

The new :term command is great! But I get a white background in my
terminal instead of a black one. Foreground colors look right I think.

I made a few tests and found that the 'set t_RB=' line in my .vimrc
causes this issue. If I remove it I get a proper black background.
However if I remove it termguicolors stops working as well (see
https://groups.google.com/d/topic/vim_dev/u80SfYhQLDw/discussion).

Is there a way to have both Vim and terminal colors to display
properly with termguicolors, or do I have to choose between them?

BTW, this is using Vim 8.0.0946 under a Debian 8 and a Gnome terminal
(same results with an xterm).

Thanks.

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [proposal][patch] Want to stop supporting troublesome options 'gdefault' and 'edcompatible'.

[François Ingelrest]

Hi,

On 3 May 2017 at 11:11, Christian Brabandt  wrote:
> So gdefault seems to be popular to a certain degree. I wouldn't have
> thought that, it is just such an obscure option.

I've always used it, it's quite handy to always replace all
occurrences and not just the first one. In fact I can hardly remember
a time where I wanted just the first occurrence in a line to be
replaced, hence the gdefault option.

Not that I wouldn't be able to live without it, but I would certainly
not consider it useless and from your stats it seems I'm not the only
one.

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 8.0.0567

[François Ingelrest]

On 2 May 2017 at 11:15, Bram Moolenaar  wrote:
> Hmm, and when you set 'background' to the right value in your .vimrc,
> does that make any difference?

Yes this works. I added 'set t_RB=<1b>]11;?<07>' and I get the proper
colors. Actually setting it to any value seems to work as well since
it's overwritten by vim's code later on if I got it correctly. So
setting it to be empty or to any string works, it's not setting it at
all in my .vimrc that breaks termguicolors for me.

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 8.0.0567

[François Ingelrest]

Hi,

On 1 May 2017 at 17:37, Bram Moolenaar  wrote:
> OK, well then maybe we should implement this comment:
> {/* TODO: don't set option when already the right value */
>
> Try this patch:
>
> ...

Sorry but that doesn't work.

Patch applies cleanly and compilation doesn't generate any error or
warning, but if I remove the 'set t_RB=' line from my .vimrc
termguicolors doesn't work.

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 8.0.0567

[François Ingelrest]

Hi Bram,

On 1 May 2017 at 15:35, Bram Moolenaar  wrote:
> Strange.  Do you have t_RB set?  If so, does it help to make it empty?

Yes it seems to be automatically set (at least not set in my .vimrc)
to <1b>]11;?<07>. If I make it empty in my .vimrc, termguicolors works
as expected.

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 8.0.0567

[François Ingelrest]

Hi,

On 18 April 2017 at 18:53, Bram Moolenaar  wrote:
> Patch 8.0.0567
> Problem:Call for requesting color and ambiwidth is too early. (Hirohito
> Higashi)
> Solution:   Move the call down to below resetting "starting".
> Files:  src/main.c

This patch broke termguicolors for me (debian 64 bits, Gnome
terminal), it was working fine before this patch.

Am I the only one affected by this?

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] patch 8.0.0056 (d0b5138)

[François Ingelrest]

On 23 November 2016 at 15:17, Matlink wrote:
> Doesn't work on my 2:7.4.488-7 on debian.

Have you upgraded the package? I got an upgrade this morning, I guess
it fixed the issue.

-- 
-- 
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 because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Search skips one occurence of sentence

[François Ingelrest]

Hi,

On 9 May 2015 at 16:31, Daniel Kosiński wrote:
 This does happens for both / and ? searches. I tried searching for it with 
 vim/gvim -u NONE and it couldn't match it either. If I search only for 
 'Makijaż' it matches the word correctly but as soon as I add space character 
 it skips h2 tag.

The occurrence of Makijaż in the h2 tag is not followed by a space,
but by some invisible character that looks like a space (it could even
be a undividable space, I don't know the code of those ones). Just
replace this character by a regular space and your search will work.

-- 
-- 
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 because you are subscribed to the Google Groups 
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Crash while deleting directory

[François Ingelrest]

Hi Dominique,

On 27 December 2013 09:07, Dominique Pellé wrote:
 Can you try the attached patch?  Since I can't reproduce
 the bug, I'm not sure it will fix it.  So please verify that it
 fixes the crash and the valgrind error.

Yes it does! The inability to edit the current buffer is still
present, but no more crash nor Valgrind error.

 By the way, you used valgrind-3.7.0, which is 2 years old.
 Latest version is 3.9.0. But it does not really matter here.

Yep, I just installed the version found on the Debian Wheezy
repository so I'm not surprised it's out of date.

-- 
-- 
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 because you are subscribed to the Google Groups 
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Crash while deleting directory

[François Ingelrest]

Hi all,

I don't know whether this is caused by Vim or Netrw, but here's a way
to crash both:

1. cd /tmp  mkdir foo
2. vim
3. :e foo/
4. rmdir foo  touch foo
5. In Netrw choose .. to go up to /tmp
6. Open foo

Vim crashes at this point with a segmentation fault. Sometimes it will
not crash immediately but something weird definitively happens and you
can't edit the buffer.

This is with Vim 7.4.131 on Debian Wheezy 64 bits (big build) and Netrw v147nNR.

-- 
-- 
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 because you are subscribed to the Google Groups 
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Crash while deleting directory

[François Ingelrest]

On 26 December 2013 13:43, Tony Mechelynck wrote:
 Hm, you're removing the directory you're working on and replacing it by a
 file of the same name, then asking to follow the hardlink ./.. in it, which
 you implicitly just removed? Sounds to me like you were asking for trouble,
 but well…

Of course I'm not saying this is something users do regularly, I just
happened to do this and got this crash so since I was able to
reproduce it I reported it. If there's a way to gracefully handle this
situation then fine, otherwise too bad.

 To compile Vim yourself (current version is 7.4.131 but your runtime files
 seem a little out-of-date) see:

I already compile Vim by myself, but I thought that runtime files were
automatically pulled by Mercurial now that CVS is now longer used.
Maybe that's a version of Netrw I installed myself and it somehow
takes priority over the Mercurial's one, I'll check that.

On 26 December 2013 13:50, Lech Lorens wrote:
 Can you specify how you Open foo? I selected the file and pressed
 return.

Yep, that's what I do.

On 26 December 2013 14:01, Dominique Pellé wrote:
 If you can reproduce it, can you give a stack trace
 with gdb, and also try to reproduce it with valgrind
 or address sanitizer?

I'm not sure how to get a meaningful stack trace: I compiled Vim with
-g and ran it with GDB, but all I get in the log file is:

Starting program: /usr/local/bin/vim

Program received signal SIGSEGV, Segmentation fault.
0x7770e078 in main_arena () from /lib/x86_64-linux-gnu/libc.so.6
A debugging session is active.

Inferior 1 [process 27106] will be killed.

As for Valgrind I never used it, any explanation on how to get it
running with Vim?

-- 
-- 
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 because you are subscribed to the Google Groups 
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: gg=G

[François Ingelrest]

Hi,

 gg=G does not work in vim 7.4

I just tried with Vim 7.4.77 ('big' build) on a C file and it worked
fine for me. Could you please elaborate a bit more?

-- 
-- 
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 because you are subscribed to the Google Groups 
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Vim hangs with insertion after long line

[François Ingelrest]

On Thu, Feb 14, 2013 at 12:54 PM, Christian Brabandt wrote:
 Question is, if you run into a problem, how do you know you have to turn
 off that option?  If syntax highlighting is off it might be obvious, but
 when some plugins behave badly you might not have a clue.

 Anybody that uses such an option should be aware, that this can have
 consequences. So I would expect the first thing to do when one notices
 something strange to turn that option off.

I think as well that such an option could be a good idea, not just for
RE but for any bigger changes that strives to be eventually included
into the main development line. I'm sure many people on this list
would go for experimental just to help testing new features. I
personally don't have enough time to help in Vim development, but I'm
always happy to run into various issues and report them.
experimental could be a compilation option as well to avoid having
both old and new code compiled into the program. It should be
reported with bug reports like any other compilation option (just as
in happens with big features but not with tiny).

-- 
-- 
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 because you are subscribed to the Google Groups 
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: New feature: absolute line number in relativenumber for the current line

[François Ingelrest]

On Wed, Jan 30, 2013 at 12:31 PM, Bram Moolenaar wrote:
 This looks like a good solution.  I'll include it.  With Christian's
 addition.

I think I found a case where the 'relativenumber' option is reset. I'm
sending this report in this thread, although I don't know if it's
caused by the recent changes to relativenumber:

1. vim -u NONE -U NONE
2. :set number
3. :set relativenumber
4: :e .zshrc
5: :e .zsh_history

At step 4., relativenumber is on. At step 5., it's off. Not setting
number (step 3.) before relativenumber doesn't exhibit this behavior.

This is with Vim 7.3.798, features=big, on a Debian Squeeze.

-- 
-- 
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 because you are subscribed to the Google Groups 
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Netrw failure with latest Vim

[François Ingelrest]

Hi all,

I've updated Vim to 7.3.744 (features=big) and now netrw fails the
second time I try to open a file using :Explore

1. Start vim
2. :E and open a file
3. :E fails

At step 3 I get a blank screen with no listing. This seems to be
caused by this line in my .vimrc:

let g:netrw_liststyle=3

If I comment this line, everything works as expected.

This is on a Debian Squeeze with netrw v146.

-- 
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: [DNS] vim.org should point to www.vim.org

[François Ingelrest]

On Mon, Mar 5, 2012 at 12:24, Birger J. Nordølum wrote:
 I can only once again petition that the DNS part of the Vim project get
 fixed, as this is to considered as being a flawed configuration, and can't
 be acknowledged as a good design decision.

I personally don't care whether vim.org works without the www prefix
or not, but I'd vote to fix it just to stop the recurring requests
for making it work. And I must say I can't see any reason to prevent
vim.org from working without the www prefix, while I can easily find
some to make it work.

-- 
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

Incorrect preprocessor highlighting in cpp filetype

[François Ingelrest]

Hi all,

The following code is highlighted incorrectly when using the cpp filetype:

#if defined FOO
#elif defined BAR
#endif

The part defined BAR is not highlighted, while defined FOO is.
AFAICT, my runtime files are up to date.

I don't know much about Vim syntax files, so I can't tell where
exactly is the problem.

-- 
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.

[François Ingelrest]

Hi,

2010/7/28 Dominique Pellé:
 I'm sorry, I messed up again and forgot one file in the patch :-(
 Here it is again.

This new feature is great! It's easier and a bit faster to have
completion at hand when setting the file type.

One (maybe silly) question though: Isn't it possible to use completion
also with :set ft= ? It's not that I can't use :setf, just that
I'm used to the former and thought that the patch wasn't working at
first.

-- 
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: Update on Vim 7.3 status

[François Ingelrest]

2010/5/25 Dominique Pellé dominique.pe...@gmail.com:
 Does anybody use all Vim features? :-)

Does anybody actually know all Vim features? :-)

Sometimes I accidentally quit Vim while editing a file (hitting w and
q at the same time when saving for instance), losing the undo history
at the same time. I can certainly see a utility to persistent undo for
such cases.

Even if this feature will not be the most useful to me, I'm glad to
see new features added to Vim that make it even better.

-- 
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

Left margin not correctly restored when returning from diff mode

[François Ingelrest]

Hi all,

I've started to use the command DiffOrig proposed in the help (see :h
:DiffOrig). When I use it and then return to normal mode, the left
margin is not correctly restored, some empty space being left in front
of the text (or in front of line numbers if displayed).

Here are some steps:

1. Open an existing file
2. Add a space somewhere
3. :DiffOrig
4. :only

After the last step, the margin is not correctly restored (see the
attached two screenshots).

This is with Vim 7.2.302 on Ubuntu 9.10 (normal features, no GUI).

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

attachment: before.pngattachment: after.png

Re: Left margin not correctly restored when returning from diff mode

[François Ingelrest]

On Tue, Nov 24, 2009 at 11:04, Christian Brabandt wrote:
 I believe, that is the foldcolumn. You should issue :diffoff when closing
 your diff. See :h foldcolumn

Indeed, thanks!

Is there a way to go back to normal mode (i.e., closing the diff
window and issuing :diffoff) or should I just create a mapping for
doing that?

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Patch 7.2.269

[François Ingelrest]

On Tue, Nov 3, 2009 at 12:10, Bram Moolenaar b...@moolenaar.net wrote:
 Patch 7.2.269
 Problem:    Many people struggle to find out why Vim startup is slow.
 Solution:   Add the --startuptime command line flag.
 Files:      runtime/doc/starting.txt, src/globals.h, src/feature.h,
            src/main.c, src/macros.h

Wow, this is very cool and can be very handy. Thanks!

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Tabline not refreshed when using :saveas

[François Ingelrest]

Hi,

On Wed, Nov 12, 2008 at 13:08, Bram Moolenaar wrote:
 Francois Ingelrest wrote:

 Hi all,

 When I do the following:
  1. vim -u NONE -U NONE foo.c
  2. :tabnew
  3. :tabprev
  4. :saveas bar.c

 The tabline is not refreshed, and the current tab is still named
 foo.c. Switching to the other tab correctly refreshed the first tab,
 which is then renamed bar.c (as expected).

 This is with Vim 7.2.30 on Ubuntu 8.10.

 One more for the todo list...

Here's a patch that hopefully fixes this bug.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Index: ex_cmds.c
===
RCS file: /cvsroot/vim/vim7/src/ex_cmds.c,v
retrieving revision 1.118
diff -u -r1.118 ex_cmds.c
--- ex_cmds.c	13 Jan 2009 15:58:01 -	1.118
+++ ex_cmds.c	1 Feb 2009 09:32:55 -
@@ -2703,11 +2703,16 @@
 	retval = buf_write(curbuf, ffname, fname, eap-line1, eap-line2,
  eap, eap-append, eap-forceit, TRUE, FALSE);
 
-	/* After :saveas fname reset 'readonly'. */
+	/* After :saveas fname reset 'readonly' and redraw tabs. */
 	if (eap-cmdidx == CMD_saveas)
 	{
 	if (retval == OK)
+	{
 		curbuf-b_p_ro = FALSE;
+#ifdef FEAT_WINDOWS
+		redraw_tabline = TRUE;
+#endif
+	}
 	/* Change directories when the 'acd' option is set. */
 	DO_AUTOCHDIR
 	}

Re: Patch 7.2.055

[François Ingelrest]

On Fri, Nov 28, 2008 at 21:27, Bram Moolenaar wrote:
 Patch 7.2.055
 Problem:Various compiler warnings with strict checking.
 Solution:   Avoid the warnings by using return values and renaming.
 Files:  src/diff.c, src/eval.c, src/ex_cmds.c, src/ex_docmd.c,
src/fileio.c, src/fold.c, src/globals.h, src/gui.c,
src/gui_at_sb.c, src/gui_gtk_x11.c, src/gui_xmdlg.c,
src/gui_xmebw.c, src/main.c, src/mbyte.c, src/message.c,
src/netbeans.c, src/option.c, src/os_unix.c, src/spell.c,
src/ui.c, src/window.c

No more warning for me, thanks.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Patch 7.2.050

[François Ingelrest]

Hi,

On Fri, Nov 28, 2008 at 10:08, Bram Moolenaar wrote:
 Patch 7.2.050
 Problem:Warnings for not checking return value of fwrite(). (Chip 
 Campbell)
 Solution:   Use the return value.
 Files:  src/spell.c

I still get such warnings, for instance:

diff.c:702: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
diff.c:707: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result

There are also many other ignored values:

diff.c:928: warning: ignoring return value of 'chdir', declared with
attribute warn_unused_result
diff.c:931: warning: ignoring return value of 'chdir', declared with
attribute warn_unused_result
ex_cmds.c:1944: warning: ignoring return value of 'fchown', declared
with attribute warn_unused_result
ex_docmd.c:8756: warning: ignoring return value of 'chdir', declared
with attribute warn_unused_result
fileio.c:2217: warning: ignoring return value of 'dup', declared with
attribute warn_unused_result
fileio.c:3452: warning: ignoring return value of 'fchown', declared
with attribute warn_unused_result
fileio.c:4368: warning: ignoring return value of 'fchown', declared
with attribute warn_unused_result
fileio.c:6035: warning: ignoring return value of 'fgets', declared
with attribute warn_unused_result
main.c:2375: warning: ignoring return value of 'dup', declared with
attribute warn_unused_result
os_unix.c:323: warning: ignoring return value of 'write', declared
with attribute warn_unused_result
os_unix.c:3930: warning: ignoring return value of 'dup', declared with
attribute warn_unused_result
os_unix.c:3931: warning: ignoring return value of 'dup', declared with
attribute warn_unused_result
os_unix.c:3932: warning: ignoring return value of 'dup', declared with
attribute warn_unused_result
os_unix.c:4017: warning: ignoring return value of 'dup', declared with
attribute warn_unused_result
os_unix.c:4023: warning: ignoring return value of 'dup', declared with
attribute warn_unused_result
os_unix.c:4162: warning: ignoring return value of 'write', declared
with attribute warn_unused_result
ui.c:1823: warning: ignoring return value of 'dup', declared with
attribute warn_unused_result
window.c:4032: warning: ignoring return value of 'chdir', declared
with attribute warn_unused_result
window.c:4039: warning: ignoring return value of 'chdir', declared
with attribute warn_unused_result

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Patch 7.2.050

[François Ingelrest]

On Fri, Nov 28, 2008 at 13:51, Tony Mechelynck wrote:
 Hm, François, is this a console-only version with no multibyte
 capabilities? I have additional warnings in mbyte.c, gui.c,
 gui_gtk_x11.c (and netbeans.c).

Yes, it's a fresh CVS checkout with just normal features and nothing else.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Compiler warnings (was: Patch 7.2.050)

[François Ingelrest]

On Fri, Nov 28, 2008 at 17:12, Bram Moolenaar wrote:
 Can you check if adding (void) before a function gets rid of the warning
 for an unused return value?

No, adding (void) makes no difference as I get the same warning in both cases.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: crash when pasting clipboard from mouse

[François Ingelrest]

On Mon, Nov 17, 2008 at 22:18, Dominique Pelle
[EMAIL PROTECTED] wrote:
 Does anybody else see that bug too?

Works fine for me.

VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Nov 17 2008 08:42:16)
Included patches: 1-42
Normal version with GTK2 GUI

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Feature request? Cannot set the color of non selected entries in the wildmenu

[François Ingelrest]

Thanks for the trick!

On Sun, Nov 9, 2008 at 07:01, Tony Mechelynck
[EMAIL PROTECTED] wrote:
 On 08/11/08 14:12, François Ingelrest wrote:
 Hi all,

 The only highlight concerning the wildmenu I'm aware of is 'WildMenu'.
 This lets me choose how the current match should be highlighted, but I
 can't set the style of other entries in that menu. AFAICT, Vim
 automatically uses the highlight style of the status bar.

 This is annoying, because I like to use colors such as dark grey /
 white for this kind of things (e.g., completion menu, tabs), so that
 the current entry is clearly visible. However, to do that, I would
 have to set the foregound color of the status bar to dark grey,
 resulting in a status bar not easily readable most of the time (when
 the wildmenu is not currently used).

 Is there a solution to this problem?

 AFAIK, there isn't; but it's only a problem if you want it to be. The
 selected 'wildmenu' entry is in WildMenu highlight, and the rest in
 StatusLine highlight. You can change them at any time, and the current
 values will be used. In my colorscheme, I alternate the StatusLine
 highlight between two contrasting values, and the WildMenu is set to the
 other setting, as follows:

 let s:colors_name = almost-default
 [...]
  display the status line of the active window in a distinctive color:
  bold black on bright red in the GUI, white on green in the console
  (where the bg is never bright, and dark red is sometimes an ugly sort
  of reddish brown).
 hi StatusLine   gui=NONE,bold   guibg=red   guifg=black
 \   cterm=NONE,bold ctermbg=darkgreen   ctermfg=white
 hi WildMenu gui=NONE,bold   guibg=green guifg=black
 \   cterm=NONE,bold ctermbg=black   ctermfg=white
  make the status line bold-reverse (but BW) for inactive windows
 hi StatusLineNC gui=reverse,bold
 \   cterm=NONE  ctermbg=black   ctermfg=lightgrey
  make the active status line colours alternate between two settings
  to give a visual notice of the CursorHold/CursorHoldI events
 if ! exists(s:statuslineflag)
   let s:statuslineflag = 0
 endif
 function! ToggleStatusLine()
 if s:statuslineflag
 hi StatusLine
   \ cterm=NONE,bold ctermbg=darkgreen   ctermfg=white
   \ gui=NONE,bold   guibg=red   guifg=black
 hi WildMenu
   \ cterm=NONE,bold ctermbg=black   ctermfg=white
   \ gui=NONE,bold   guibg=green guifg=black
 else
 hi StatusLine
   \ cterm=NONE,bold ctermbg=black   ctermfg=white
   \ gui=NONE,bold   guibg=green guifg=black
 hi WildMenu
   \ cterm=NONE,bold ctermbg=darkgreen   ctermfg=white
   \ gui=NONE,bold   guibg=red   guifg=black
 endif
 let s:statuslineflag = ! s:statuslineflag
 endfunction
 exe augroup s:colors_name
 au! CursorHold,CursorHoldI * call ToggleStatusLine()
 au! ColorScheme *
 \ if g:colors_name != s:colors_name
 \ | exe au! s:colors_name
 \ | endif
 augroup END
 [...]
  remember the current colorscheme name
 let g:colors_name = s:colors_name

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Vim syntax: highlight keyword not highlighted inside functions

[François Ingelrest]

On Sun, Nov 9, 2008 at 11:14, Anton Sharonov [EMAIL PROTECTED] wrote:
 Unfortunately, it is not true. At least for SVN, (and I suspect
 that for CVS it is as well the case) there are recent versions of
 the runtime files (don't ask me why, for me it is also _very_
 confusing). Anyway, to get recent runtime files, please use
 rsync, as described on Tony's howto [1] about compiling vim.

Thanks for pointing this. I've updated my runtime files, but the
highlight problem is nevertheless still there.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Feature request? Cannot set the color of non selected entries in the wildmenu

[François Ingelrest]

Hi all,

The only highlight concerning the wildmenu I'm aware of is 'WildMenu'.
This lets me choose how the current match should be highlighted, but I
can't set the style of other entries in that menu. AFAICT, Vim
automatically uses the highlight style of the status bar.

This is annoying, because I like to use colors such as dark grey /
white for this kind of things (e.g., completion menu, tabs), so that
the current entry is clearly visible. However, to do that, I would
have to set the foregound color of the status bar to dark grey,
resulting in a status bar not easily readable most of the time (when
the wildmenu is not currently used).

Is there a solution to this problem?

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Vim syntax: highlight keyword not highlighted inside functions

[François Ingelrest]

On Thu, Nov 6, 2008 at 22:41, Roberto Miura Honji [EMAIL PROTECTED] wrote:
 I'm using highlight inside a function and It's working.

You get the same color highlighting inside and outside the function?
For me the highlighting works inside functions for most statements,
but not for the 'highlight' statement itself (see attached
screenshot).

 Do you call the function?
 If you only define a function on foo.vim, this only will be defined. Try
 append a follow line in a foo.vim: call Foo()

This doesn't make a difference. Actually, I'm not sure the syntax file
checks that functions are called to highlight them.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

inline: screenshot.png

Re: Vim syntax: highlight keyword not highlighted inside functions

[François Ingelrest]

On Fri, Nov 7, 2008 at 08:08, François Ingelrest
[EMAIL PROTECTED] wrote:
 On Thu, Nov 6, 2008 at 22:41, Roberto Miura Honji [EMAIL PROTECTED] wrote:
 I'm using highlight inside a function and It's working.

 You get the same color highlighting inside and outside the function?
 For me the highlighting works inside functions for most statements,
 but not for the 'highlight' statement itself (see attached
 screenshot).

 Do you call the function?
 If you only define a function on foo.vim, this only will be defined. Try
 append a follow line in a foo.vim: call Foo()

 This doesn't make a difference. Actually, I'm not sure the syntax file
 checks that functions are called to highlight them.

I should add that I'm using Vim 7.2.26, compiled by myself using the
sources from the CVS, so I guess the syntax file also comes from the
CVS. I get the same result when using Vim -u NONE -U NONE, and
enabling only syntax highlighting after that.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: How can I send a patch?

[François Ingelrest]

On Thu, Nov 6, 2008 at 23:36, Roberto Miura Honji [EMAIL PROTECTED] wrote:
  - Auto-complete using a tab key (like ctrl-p).
  - When the word have a '/' (linux separator of directories) auto-complete
 like a file (ctrl-x ctrl-f).
  - When the list search is returned, the tab can be used to scroll through
 the list.
  - when the previous char is space, tab, the cursor position is a col = 0 or
 ctrl-x ctrl-i is typed, the char tab is insert normally)

Maybe I didn't get what you mean, but 1, 3, and 4 can already be done
using the right mappings. I actually use something similar in my own
setup. Regarding 2, I think this should also be quite easy to do
without modifying Vim source code.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Vim syntax: highlight keyword not highlighted inside functions

[François Ingelrest]

Hi all,

If I put this in a foo.vim file:


highlight Comment guifg=White guibg=Black

function! Foo()

highlight Comment guifg=White guibg=Black

endfunction


The first highlight line is highlighted, but not the second one. It
seems that's because it's inside a function. Is it intended, or is
this a bug in the vim syntax file?

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Possible Arbitrary Code Execution vulnerability

[François Ingelrest]

Hi,

On Fri, Aug 29, 2008 at 06:35, Martti Kuparinen [EMAIL PROTECTED] wrote:
 I don't know if this is valid or not but if this is, is someone working on 
 this?

 http://www.rdancer.org/vulnerablevim-K.html

See this thread:
http://groups.google.com/group/vim_dev/browse_thread/thread/1434d0812b5c817e

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Five (5) new features request

[François Ingelrest]

On Wed, Jul 16, 2008 at 01:10, Ian Kelling [EMAIL PROTECTED] wrote:
 For 4, you can do something similar, like :inoremap ESC ESCl

I've been using something like that for some time:

inoremap Esc RightEsc

This works in GVim but breaks extended keys in Vim (they send Esc as
the first keycode).

It seems that Vim doesn't wait a bit to see if another keycode
follows, but rather immediately applies the mapping. This does not
happen without the mapping, because in this case Vim correctly waits a
bit to see whether it's Esc or an extended keycode. Not sure whether
this a bug or something desirable though...

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Five (5) new features request

[François Ingelrest]

On Wed, Jul 16, 2008 at 16:57, Tony Mechelynck
[EMAIL PROTECTED] wrote:
 I've been using something like that for some time:

 inoremapEsc  RightEsc

 This works in GVim but breaks extended keys in Vim (they sendEsc  as
 the first keycode).

 It seems that Vim doesn't wait a bit to see if another keycode
 follows, but rather immediately applies the mapping. This does not
 happen without the mapping, because in this case Vim correctly waits a
 bit to see whether it'sEsc  or an extended keycode. Not sure whether
 this a bug or something desirable though...

 IIUC it is usually a side-effect of 'ttimeoutlen' being at its default
 of -1 (wait just as long for keycodes as for mappings). With something like

set timeout ttimeoutlen=100 timeoutlen=5000

 keycodes will timeout after one-tenth of a second (fast for a human, but
 usually quite lazy for a keyboard driver or a telecom line) while
 mappings will only timeout after five seconds (which should be ample for
 a human typist). Then if Esc is followed by something within one-tenth
 of a second it is examined for a keycode, but after that it still counts
 for a mapping.

Solely this does not work, because (if I got it correctly) the timeout
is the maximum time that Vim will wait to see whether a mapping has
been matched, not the minimum time. So when I hit Esc, Vim doesn't
wait at all, because a mapping already matched.

 If it still doesn't work, add

inoremap   EscEsc  Esc

 to force the full timeout (5s in my example) on the Esc key when not
 part of a keycode.

This works a bit better, but when I hit Esc to go back to normal
mode, Vim applies my first mapping and then it still waits during 5
seconds to see whether another mapping will match. If I hit an
extended key within those 5 seconds, the EscEsc mapping is
matched, and the second keycode is interpreted separately.

The best solution I could come up with was to map RightEsc to
something than Esc. I'm used to the movement of the cursor upon
going back to the normal mode, but I still prefer when it doesn't
move.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: netrw v126 testing -- need help!

[François Ingelrest]

Hi,

On Tue, Jul 8, 2008 at 05:05, Charles E. Campbell, Jr.
[EMAIL PROTECTED] wrote:
 I'm just beginning a semi-automated test suite -- I expect that that
 will help enormously sometime in the misty future.  I'll be going
 through the commands and trying to build the tests, checking netrw as I
 go.  However, for now:

 Please test netrw v126g!  Its available via my website:
 http://mysite.verizon.net/astronaut/vim/index.html#NETRW

 Bram would like netrw released so he can release vim 7.2b and I'm going
 to be gone for two weeks starting next week (and will be nowhere near
 electricity let alone a computer).  The changes have been to put
 fnameescape()s and shellescape()s in where appropriate -- so you'll need
 vim 7.2a with patches 1-13 (its up to #16 as of this writing).

 I'm planning on releasing netrw to Bram at the end of this week.

I used this new version today, and faced no problem so far.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Gvim issue: slow scrolling of terminal output

[François Ingelrest]

On Wed, Jul 2, 2008 at 22:57, Amy Williams [EMAIL PROTECTED] wrote:
 Gvim appears to have very slow scrolling for output from external commands.
 This is an issue for me, particularly with :make and with spell checking.
 To see the issue, run gvim, type a word, and then with the cursor over that
 word, type z= (for suggested spell corrections).  The issue is worse for me
 when I do :make, especially for a LaTeX document, since LaTeX spews all
 kinds of information to its output.

Yes, this has always been like that, and the difference between Vim
and GVim is huge. I agree that it's a bit annoying, but no so much in
my case, I can live with it. Of course, I wouldn't be against an
improvement :-)

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: vim

[François Ingelrest]

Hi,

On Sat, Jun 28, 2008 at 10:30, momodi [EMAIL PROTECTED] wrote:
 I download the src files of vim7.2a and run make install
 now my vim's version is 7.2a
 but my gvim's version is also 7.1

 why?

 my OS: ubuntu 8.04

A possible explanation would be that you have compiled v7.2 without
GUI support, so GVim (which is just a symbolic link) is still pointing
to your previous Vim version (7.1).

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Patch 7.2a.001

[François Ingelrest]

On Thu, Jun 26, 2008 at 22:18, Bram Moolenaar [EMAIL PROTECTED] wrote:
 Patch 7.2a.001
 Problem:On some systems X11/Xlib.h exists (from X11-dev package) but
X11/Intrinsic.h does not (in Xt-dev package).  This breaks the
build.  Also, on Solaris 9 sys/ptem.h isn't found.
 Solution:   Have configure only accept X11 when X11/Intrinsic.h exists.
Check for sys/ptem.h while including sys/stream.h. (Vladimir
Marek)
 Files:  src/auto/configure, src/configure.in

Is, by any chance, an AAP recipe going to be set up? That's much
simpler on user's side, although maybe not on your side.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Patch 7.2a.001

[François Ingelrest]

On Fri, Jun 27, 2008 at 15:42, Bram Moolenaar [EMAIL PROTECTED] wrote:

 Francois Ingelrest wrote:

 On Thu, Jun 26, 2008 at 22:18, Bram Moolenaar [EMAIL PROTECTED] wrote:
  Patch 7.2a.001
  Problem:On some systems X11/Xlib.h exists (from X11-dev package) but
 X11/Intrinsic.h does not (in Xt-dev package).  This breaks the
 build.  Also, on Solaris 9 sys/ptem.h isn't found.
  Solution:   Have configure only accept X11 when X11/Intrinsic.h exists.
 Check for sys/ptem.h while including sys/stream.h. (Vladimir
 Marek)
  Files:  src/auto/configure, src/configure.in

 Is, by any chance, an AAP recipe going to be set up? That's much
 simpler on user's side, although maybe not on your side.

 Well, it means that everybody will get the beta test version.  Since I
 did quite a few last-minute changes I was awaiting success/fail reports
 first.  It looks like 7.2a is doing quite well, so I might indeed update
 the script.  Those who use CVS got it already anyway.

Isn't it possible to create a specific recipe for v7.2, different from
the official one? The latter could still point to the current
version, it doesn't have to be changed. Anyway, I can still use CVS
with aap, which is also fine.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Vim version 7.2a ready for BETA testing

[François Ingelrest]

On Tue, Jun 24, 2008 at 22:38, Bram Moolenaar [EMAIL PROTECTED] wrote:
 Announcing:  Vim (Vi IMproved) version 7.2a BETA

Compiled and installed fine on Ubuntu 8.04 with GTK2.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: [Patch] Nicer notebook tabs with GTK2

[François Ingelrest]

On Tue, May 6, 2008 at 5:43 PM, Antony Scriven [EMAIL PROTECTED] wrote:
  Nico Weber [EMAIL PROTECTED] wrote:
 the GUI version and that's the way GUIs generally look
 like. The same goes for icons in notebook tabs: Almost
 all the GUI applications I can think of display such an
 icon although the label would be sufficient. It's just
 a bit nicer to look at.
   
FWIW, I think this is a nice change. If I edit more than,
say, 5 files, I can't use a tab for each file anyways.
For just two to three tabs, the icons give the tabs
a much nicer look (at least on GTK, where most tabs
include file icons. In OS X, tabs usually don't have file
icons, so I wouldn't want it in the OS X version).

  More than just looking nicer, I think it can be a usability
  improvement, e.g. Firefox displays the shortcut icon in its
  tabs; I find this makes finding a tab easier. But... Vim can
  detect ~500 different filetypes. Who's coming up with 500
  distinct and easily recognizable icons? --Antony

GTK actually uses the system icons defined by the user's theme, i.e.,
you provide it the mime type and it provides you the icon associated
to that mime type in the current user's theme. Those icons are the
ones that are used for instance in Nautilus. Almost the same goes for
the toolbar: AFAIK, icons are taken from the user's theme and are
directly provided by GTK.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: [Patch] Nicer notebook tabs with GTK2

[François Ingelrest]

Hi!

On Fri, May 2, 2008 at 10:23 PM, Bram Moolenaar [EMAIL PROTECTED] wrote:
   Here is a patch that improves a bit notebook tabs with GTK2. It:
- Groups the creation of tab labels into one function (the code was
   duplicated at two places before)
- Adds a file icon in front of the label
  
   Here are some screenshots:
  
   http://www.silent-blade.org/misc/gvim-notebook-before.png
   http://www.silent-blade.org/misc/gvim-notebook-after.png
  
   Comments are welcome :-)

  I also think that the space that the icon takes is too much.  Most
  people edit files of the same type (e.g., all Java files), the icon
  isn't very helpful then.  And when you have two windows in one Tab, what
  icon are you going to show?

I would not say it's useless in the sense that icons make notebook
tabs a bit nicer to look at. I actually never liked notebook tabs in
GVim because they are too narrow and that makes difficult to spot the
one I need (the main reason I wrote this small patch). Also, in this
perspective, the toolbar is useless as it takes too much space for
commands that can already easily be typed. But it's there because it's
the GUI version and that's the way GUIs generally look like. The same
goes for icons in notebook tabs: Almost all the GUI applications I can
think of display such an icon although the label would be sufficient.
It's just a bit nicer to look at.

Regarding multiple windows in one notebook tab: As Tony said, the
active window should be used. Actually the active filetype should be
used, and the icon should be updated as soon as it changes, be it
because the active window has changed or because the user has :set it.

Anyway, if you feel it's useless, I'm fine with that: I'm not going to
spend time writing code that people don't want/need. That's also why I
wanted your feedback :-)

And thanks for taking the time to reply!

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

[Patch] Nicer notebook tabs with GTK2

[François Ingelrest]

Hi,

Here is a patch that improves a bit notebook tabs with GTK2. It:
 - Groups the creation of tab labels into one function (the code was
duplicated at two places before)
 - Adds a file icon in front of the label

Here are some screenshots:

http://www.silent-blade.org/misc/gvim-notebook-before.png
http://www.silent-blade.org/misc/gvim-notebook-after.png

Comments are welcome :-)

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

--- Vim_orig/vim/src/gui_gtk_x11.c	2008-03-29 14:30:03.0 +0100
+++ Vim/vim/src/gui_gtk_x11.c	2008-04-30 19:56:10.0 +0200
@@ -3308,13 +3308,50 @@
 }
 
 /*
+ * Create a new label for the tabline
+ */
+GtkWidget*
+gui_mch_create_label(void)
+{
+GtkWidget	*tab_box;
+GtkWidget	*label;
+
+#ifdef HAVE_GTK2
+GtkWidget	*icon;
+
+tab_box = gtk_hbox_new(FALSE, 4);
+gtk_widget_show(tab_box);
+
+icon = gtk_image_new_from_stock(GTK_STOCK_FILE, GTK_ICON_SIZE_MENU);
+gtk_widget_show(icon);
+gtk_misc_set_padding(GTK_MISC(icon), 0, 2);
+gtk_box_pack_start(GTK_BOX(tab_box), icon, FALSE, FALSE, 2);
+
+label = gtk_label_new(-Empty-);
+gtk_widget_show(label);
+gtk_misc_set_padding(GTK_MISC(label), 0, 2);
+gtk_box_pack_start(GTK_BOX(tab_box), label, TRUE, TRUE, 2);
+#else
+tab_box = gtk_event_box_new();
+gtk_widget_show(tab_box);
+label = gtk_label_new(-Empty-);
+gtk_misc_set_padding(GTK_MISC(label), 2, 2);
+gtk_container_add(GTK_CONTAINER(tab_box), label);
+gtk_widget_show(label);
+#endif
+
+return tab_box;
+}
+
+
+/*
  * Update the labels of the tabline.
  */
 void
 gui_mch_update_tabline(void)
 {
 GtkWidget	*page;
-GtkWidget	*event_box;
+GtkWidget	*tab_box;
 GtkWidget	*label;
 tabpage_T	*tp;
 int		nr = 0;
@@ -3341,21 +3378,29 @@
 	/* Add notebook page */
 	page = gtk_vbox_new(FALSE, 0);
 	gtk_widget_show(page);
-	event_box = gtk_event_box_new();
-	gtk_widget_show(event_box);
-	label = gtk_label_new(-Empty-);
-	gtk_misc_set_padding(GTK_MISC(label), 2, 2);
-	gtk_container_add(GTK_CONTAINER(event_box), label);
-	gtk_widget_show(label);
+	tab_box = gui_mch_create_label();
 	gtk_notebook_insert_page(GTK_NOTEBOOK(gui.tabline),
 		page,
-		event_box,
+		tab_box,
 		nr++);
 	}
 
-	event_box = gtk_notebook_get_tab_label(GTK_NOTEBOOK(gui.tabline), page);
-	gtk_object_set_user_data(GTK_OBJECT(event_box), (gpointer)tab_num);
-	label = GTK_BIN(event_box)-child;
+	tab_box = gtk_notebook_get_tab_label(GTK_NOTEBOOK(gui.tabline), page);
+	gtk_object_set_user_data(GTK_OBJECT(tab_box), (gpointer)tab_num);
+
+#ifdef HAVE_GTK2
+{
+GList	*children;
+
+children = gtk_container_get_children(GTK_CONTAINER(tab_box));
+label = g_list_nth_data(children, 1);
+g_list_free(children);
+}
+#else
+label = GTK_BIN(event_box)-child;
+#endif
+
+
 	get_tabline_label(tp, FALSE);
 	labeltext = CONVERT_TO_UTF8(NameBuff);
 	gtk_label_set_text(GTK_LABEL(label), (const char *)labeltext);
@@ -3363,7 +3408,7 @@
 
 	get_tabline_label(tp, TRUE);
 	labeltext = CONVERT_TO_UTF8(NameBuff);
-	gtk_tooltips_set_tip(GTK_TOOLTIPS(tabline_tooltip), event_box,
+	gtk_tooltips_set_tip(GTK_TOOLTIPS(tabline_tooltip), tab_box,
 			 (const char *)labeltext, NULL);
 	CONVERT_TO_UTF8_FREE(labeltext);
 }
@@ -3701,20 +3746,16 @@
 gtk_tooltips_enable(GTK_TOOLTIPS(tabline_tooltip));
 
 {
-	GtkWidget *page, *label, *event_box;
+	GtkWidget *page, *tab_box;
 
 	/* Add the first tab. */
 	page = gtk_vbox_new(FALSE, 0);
 	gtk_widget_show(page);
+tab_box = gui_mch_create_label();
+
 	gtk_container_add(GTK_CONTAINER(gui.tabline), page);
-	label = gtk_label_new(-Empty-);
-	gtk_widget_show(label);
-	event_box = gtk_event_box_new();
-	gtk_widget_show(event_box);
-	gtk_object_set_user_data(GTK_OBJECT(event_box), (gpointer)1);
-	gtk_misc_set_padding(GTK_MISC(label), 2, 2);
-	gtk_container_add(GTK_CONTAINER(event_box), label);
-	gtk_notebook_set_tab_label(GTK_NOTEBOOK(gui.tabline), page, event_box);
+	gtk_object_set_user_data(GTK_OBJECT(tab_box), (gpointer)1);
+	gtk_notebook_set_tab_label(GTK_NOTEBOOK(gui.tabline), page, tab_box);
 }
 
 gtk_signal_connect(GTK_OBJECT(gui.tabline), switch_page,

Re: [Patch] Nicer notebook tabs with GTK2

[François Ingelrest]

2008/5/1 Christian J. Robinson [EMAIL PROTECTED]:
   Are icons tied with MIME system? So it will be different icon for
   HTML file, different for C++ .h header?

  Actually, Vim already has the filetype detection system, so an icon
  for each filetype could be defined.

  I like this idea, but only if it can be implemented for all--or at
  least most--of the GUI interfaces.  And, of course, it should be
  possible to turn the icons in the tabs off.

The same icon is currently always used, it's a first version of the patch :-)

GTK provides a way to get icons from the current theme of the user, so
I guess it should be possible to display the correct icon based on the
mime type of the file. However, I can work on this only for GTK, as I
don't have any Windows or Mac at hand. Also, I don't know what would
be the best way to disable these icons.

I would like to get Bram's feedback before continuing to work on this.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: How to create Binary packages.

[François Ingelrest]

On Tue, Apr 29, 2008 at 11:18 AM, gnani [EMAIL PROTECTED] wrote:
  But from the compiled source code, I don't know how to create package.
  Can you help me

As Tony said, it's related to how to package something for netBSD, not
to Vim specifically.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Problems compiling vim with --enable-gui on Debian 4.0

[François Ingelrest]

On Sun, Apr 20, 2008 at 1:25 AM, Joe Keen [EMAIL PROTECTED] wrote:
   Are you two having the same problem?
  
   There is a difference in the size_t and int type of the second argument.
   But the idea is that these lines are removed when the function prototype
   is in the header.  Question is why that doesn't happen.  I appear to
   have the same thing in the header file and it works for me.

  That is the problem I had before I installed the x-window-system-core
  package in Debian.  Commenting out the definition in osdefs.h did work
  for me as well.

I think I got it.

From what I understood, osdef.h is generated by osdef.sh. At first,
when I launched the compilation, I was missing some X headers (the
xserver-xorg-dev package I think), and it seems that osdef.sh was
executed at that point. Since it did not find the headers, it kept
many definitions (including _Xmblen), and the compilation finally
failed because of the missing headers. Then I installed them, and I
think that osdef.sh was never executed after that, resulting in the
conflict.

I've just tried to execute it by hand, and it has generated an almost
empty osdef.h this time. Maybe the script should be run each time
compilation is started? BTW, I'm using aap for this.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: GSOC: On-the-fly Code Checking for Vim - Challenges

[François Ingelrest]

On Sat, Apr 12, 2008 at 8:11 PM, Birgi Tamersoy [EMAIL PROTECTED] wrote:
  I really think that by the end of this August we can have an on-the-
  fly code checker which will be used by a majority of the community.

I'm not sure how many people are interested in on-the-fly compilation.
I know I'm not: the first thing I do when I have to use Eclipse is to
turn off that feature. I find that very annoying when I get errors
because I've not finished to write some code. I frequently write
incomplete code to get the global structure (e.g., loops, conditions)
before completing it.

IMO Eclipse's and Vim's communities are different from each other. I
understand that Eclipse users like such feature, but maybe that's
precisely why they use a tool like Eclipse.

That's only my two cents, maybe I'm wrong and I'm just too old-school
to appreciate such feature :-)

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

[patch] Fix typo in eval.txt

[François Ingelrest]

An easy one.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

--- Vim_orig/vim/runtime/doc/eval.txt	2008-03-29 14:30:45.0 +0100
+++ Vim_nlines/vim/runtime/doc/eval.txt	2008-04-08 11:45:15.0 +0200
@@ -2049,7 +2049,7 @@
 			returned)
 		Additionally {expr} can be [lnum, col]: a |List| with the line
 		and column number. Most useful when the column is $, to get
-		the las column of a specific line.  When lnum or col is
+		the last column of a specific line.  When lnum or col is
 		out of range then col() returns zero.
 		To get the line number use |line()|.  To get both use
 		|getpos()|.

Re: Completion popup menu is invisible when the current line does not fit on the screen

[François Ingelrest]

On Sat, Mar 29, 2008 at 9:22 PM, Dominique Pelle
[EMAIL PROTECTED] wrote:
  Hi François:

  I have tested your patch #1.  For long lines that wrap multiple times,
  completion popup
  does not behave in a symetric way whether popup appears:

  1/ below the cursor (i.e. when cursor is near the top of the screen)
  2/ or above the cursor (i.e. when cursor is near the bottom of the screen)

  In the first case, popup behaves as you intended I think i.e. it goes
  below the entire wrapped line, but no more than 3 screen-lines below
  when the line wraps many times  (good)

  In the second case, popop always appears only one screen-line
  above the cursor, even if the line is long and wraps several time.  I
  would  expect the popup to be at the top of the line being edited but
  no more than 3 screen-lines above the cursor to behave symetrically
  with case 1/

  Hopefully this explanation makes sense to you.  If not, I can put a link
  with screenshots if you want.

Yes, I understand what you mean and it would make sense to keep the
same amount of lines of context in both cases, I'll try to fix that.
Thanks for your feedback, that was almost the first time I looked at
Vim's code :-)

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Completion popup menu is invisible when the current line does not fit on the screen

[François Ingelrest]

On Fri, Mar 28, 2008 at 5:09 PM, François Ingelrest [EMAIL PROTECTED] wrote:
 On Wed, Mar 26, 2008 at 10:15 PM, Bram Moolenaar [EMAIL PROTECTED] wrote:
François Ingelrest wrote:
 I've taken a look at the code and the fix consists in one small change
 (see attached patch): setting the height of the current real line to 1
 instead of the number of visible lines, so that the menu always
 appears under the current visible line. I can't believe such an easy
 solution has not been applied before without a good solution, so I'm
 pretty sure I must be missing something. Is there someone that could
 enlighten me on the subject?
  
The idea is that the rest of the line may contain useful text that you
want to read when selecting an entry from the popup menu.  Obviously
this only works when the line wraps only once or twice.
  
Perhaps a good compromise is to use 1 when the number of visible lines
is more than 2 or 3.

  I was on trip this week and while using Vim I noticed this does not
  work: if the word to be completed is not on the first visible line,
  the popup menu may appear over it since it is always below the first
  visible line.

  I understand your argument, but the first time I saw the popup menu
  far from the current (visible) line, I did not understand it was below
  the real line and thought it was somewhat a bug. I'll try using Vim
  with your suggestion, to see if I can get used to it. Thanks!

Here are two patches I've written. The first one leaves a maximum of
two lines of context between the cursor and the popup menu. The second
one introduces an option (pumshift) to set that value (default is
two).

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



pum_fix1
Description: Binary data


pum_fix2
Description: Binary data

Re: Completion popup menu is invisible when the current line does not fit on the screen

[François Ingelrest]

On Sat, Mar 29, 2008 at 3:17 PM, François Ingelrest [EMAIL PROTECTED] wrote:
  Here are two patches I've written. The first one leaves a maximum of
  two lines of context between the cursor and the popup menu. The second
  one introduces an option (pumshift) to set that value (default is
  two).

Sorry, I just figured out that there was a problem in the computation
of the height, here are the updated patches.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---



pum_fix1
Description: Binary data


pum_fix2
Description: Binary data

Re: upgrading vim on linux

[François Ingelrest]

On Tue, Mar 4, 2008 at 4:58 PM, Charles E Campbell Jr
[EMAIL PROTECTED] wrote:

  [EMAIL PROTECTED] wrote:
   I seem to have a problem where I want to upgrade my version of gvim
   for linux but am somewhat confused by the site
  
   there seems to be a vim-7.1.tar.bz2 but I have no idea what a bz2
   file is and the site doesn't explain it (that I can find...).
  
   so I tried to use vim-6.4-src1.tar.gz and vim-6.4-src2.tar.gz and
   untar'ed them.
   according to the site you need to type make install and everything
   will work (assuming a c compiler and such...) but unfortunately, I
   couldn't find a makefile
  
   Not sure why this couldn't be setup to be as easy as installing gvim
   for my windows box...
  
  bunzip2 vim-7.1.tar.bz2
  tar -xf vim-7.1.tar
  cd vim71
  configure
  make
  make install

I find the method using aap much simpler:

http://www.a-a-p.org/ports.html

It downloads all patches automatically.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Completion popup menu is invisible when the current line does not fit on the screen

[François Ingelrest]

This is with Vim 7.1.251

1) vim -u NONE
2) :set lines=25
3) :set columns=80
4) 150i computer chairEsc
5) gg
6) icc-n

The popup menu is displayed below the current real line instead of the
current visible line. Since the real line does not fit on the screen,
it is invisible. Even when it fits on the screen, it's quite strange
to see the popup menu appearing a few lines below the current one. I
guess the current visible line should be used instead.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Patch 7.1.246

[François Ingelrest]

  No idea.  You could check the log files to check if you see a hint.
  Is the file patches/7.1.246 corrupted in some way?
 
  I just tried and both with CVS and with patches Vim builds fine.

 The patch is not corrupted. I've the checked the files
 src/auto/configure and src/configure.in, and it seems they are
 already patched, as they contain the new modified line. That's why the
 patch command does not work.

 However, I don't understand why the command failed on the first run if
 the patching process did succeed. The first log file from today seems
 to be log6:

 -rw-r--r-- 1 ingelres 121K 2008-02-13 13:09 log
 -rw-r--r-- 1 ingelres 121K 2008-02-13 13:07 log1
 -rw-r--r-- 1 ingelres 121K 2008-02-13 13:01 log2
 -rw-r--r-- 1 ingelres 121K 2008-02-13 12:56 log3
 -rw-r--r-- 1 ingelres 121K 2008-02-13 12:51 log4
 -rw-r--r-- 1 ingelres 121K 2008-02-13 12:51 log5
 -rw-r--r-- 1 ingelres 121K 2008-02-13 12:50 log6
 -rw-r--r-- 1 root 295K 2008-02-11 08:22 log7
 -rw-r--r-- 1 ingelres 308K 2008-02-11 08:06 log8
 -rw-r--r-- 1 ingelres  704 2008-02-11 08:01 log9

 So log6 should be the log of the first run, and it only says that the
 patch could not be applied:

 depend: 3 - updating target patches/7.1.246.done
 depend: 4 - Using build rule patches/%.done : patches/% for target
 patches/7.1.246.done
 depend: 5 - updating target patches/7.1.246
 extra:  Looking up local name for 
 ftp://ftp.vim.org/pub/vim/patches/7.1/7.1.246
 info:   Attempting download of ftp://ftp.vim.org/pub/vim/patches/7.1/7.1.246;
 info:   Downloaded ftp://ftp.vim.org/pub/vim/patches/7.1/7.1.246; to
 /home/ingelres/.aap/cache/21068251.1.246
 info:   Copied file from cache: patches/7.1.246
 depend: 5 - Target has no build commands and exists: patches/7.1.246
 depend: 5 - Unknown type of file, no dependency check for patches/7.1.246
 depend: 3 - Updating patches/7.1.246.done from patches/7.1.246: no
 old signature for patches/7.1.246
 changedir:  Entering directory `/home/ingelres/Install/Vim'
 changedir:  Entering directory `/home/ingelres/Install/Vim/vim'
 extra:  Shell commands for updating patches/7.1.246.done:
 system: /usr/bin/patch -p0 -f  ../patches/7.1.246 21 
 ../patches/7.1.246.done
 error:  Error in recipe /home/ingelres/Install/Vim/main.aap line 179:
 Shell command returned 256

 So I don't know what happened. Maybe this has nothing to do, but log7
 belongs to root, that's certainly the log generated the last time I
 ran aap install. Could it be that some other files now also belong
 to root and aap could not overwrite them during the first run?

I don't know why, but your patch assumes that the modified line in
src/auto/configure is at line 14262 while in my file, it's located
at line 14507.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Discrepancy when using 'longest' or not as a complete option

[François Ingelrest]

  It seems that Vim does not have the same behavior depending on whether
  longest is used as a complete option.
 
  When using set completeopt=menu, if I use c-n and there's only one
  possible completion, the current word is completed without showing the
  menu and I'm immediately out of the completion mode.
 
  When using set completeopt=menu,longest, if I use c-n and there's
  only one possible completion, the current word is completed without
  showing the menu and I'm stuck into completion mode. The status line
  says -- Keyword completion (^N^P) Back at original and even if I
  type new characters (except a space), I can no longer use c-n until
  I stop the completion mode by hand (c-e). While this may not be a
  problem with text files, it is very annoying when programming.
 
  For instance, when typing:
 
  myTab[myIndex]
 
  If I use c-n to complete myTab and that's the only possibility,
  then I cannot use it to complete myIndex unless I hit c-e.
 
  IMHO, either Vim should get out of the completion mode after the first
  completion, or it should consider that a character such as '[' stops
  the completion mode (as a space does).

 What version of Vim?  Especially patch 7.1.145 matters.

I was using v7.1.56 (Ubuntu Gutsy). I've just tested with v7.1.241 and
this version indeed correctly stops the completion when a new
character is typed.

Sorry for the outdated report, I should have tested with the latest
version first. Lesson learnt.

--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---