On 16 March 2015 at 21:25, wrote:
> Updates:
> Labels: Runtime
>
> Comment #1 on issue 342 by chrisbr...@googlemail.com: make.vim: vpath
> directive highlights incorrectly with multiple directories
> https://code.google.com/p/vim/issues/detail?id=342
>
> Please report to the maintainer of
> How much time did you give him?
>
> Chip
I sent him an email on 30/04/2013 and got no reply since then.
Lech
--
--
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/mailli
Vim incorrectly reads the number of buffer for which an autocommand
should be registered. The attached patch fixes the problem.
Cheers,
Lech
--
--
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,
On 16-Mar-2014 James McCoy wrote:
> On Sat, Mar 15, 2014 at 03:37:27PM +0100, Lech Lorens wrote:
> > I believe what you are trying to achieve is what I did in the patch
> > I posted 4 years ago here:
> > https://groups.google.com/forum/#!msg/vim_dev/JDLJgDk-ZrQ/nROMNPdwfhw
On 15-Mar-2014 Andre Sihera wrote:
> Hi all,
>
> I have found an annoyance with the tab indenting (SHIFT + '>', SHIFT
> + '<') and
> was wondering if this was by design or should be fixed.
>
> My .vimrc contains the following:
>
> set ts=4
> set shiftwidth=4
>
> So, when I visually sel
This should have gone to the list, not only to Bram.
On 5 February 2014 20:44, Lech Lorens wrote:
> On 05-Feb-2014 Bram Moolenaar wrote:
>> Looks useful. How much does this slow down moving the cursor around?
>> Would need to try it on a slow computer.
>
> I've b
On 05-Feb-2014 Bram Moolenaar wrote:
>
> Christian Brabandt wrote:
>
> > any plans for Vim to participate in this years GSOC?
> >
> > There is a good week left to apply for organizations.
> > https://www.google-melange.com/gsoc/homepage/google/gsoc2014
>
> There is some work to be done, such a
On 05-Feb-2014 Bram Moolenaar wrote:
>
> Lech Lorens wrote:
>
> > I'd like to propose the attached ftplugin for XXD I've been using for
> > a long time. The plugin highlights the corresponding hexadecimal
> > representation for the character the curso
eiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
" Vim filetype plugin file
" Language:XXD
" Maintainer: Lech Lorens
" Last Change: 2014 Feb 4
" When the cursor is
Might be related to the other NFA bug reported today.
The below script creates a file with 40 lines of the following format:
This is line 3 of block 2.
(there are 10 blocks numbered from 0 to 9 with lines from 0 to 3).
It also tries to find all the last lines of the blocks (i.e. lines where
the
On 20-Jan-2014 Christian Wellenbrock wrote:
> On Monday, January 20, 2014 1:08:07 PM UTC+1, Lech Lorens wrote:
> > I can confirm – it is caused by the indent script. The attached patch
> > marks the place that is incorrect (and might fix the problem in this
> > particu
On 20-Jan-2014 Yukihiro Nakadaira wrote:
> On Sun, Jan 19, 2014 at 1:45 PM, Anhad Jai Singh
> wrote:
>
> >
> > When I do 'o' (plain old 'o', no fancy mappings nothing, the deafult
> > open-INSERT-mode and take me to the next line 'o'), at a specific location
> > in a specific file, vim hits 100%
On 19-Jan-2014 Bram Moolenaar wrote:
>
> Anhad Jai Singh wrote:
>
> > When I do 'o' (plain old 'o', no fancy mappings nothing, the deafult
> > open-INSERT-mode and take me to the next line 'o'), at a specific location
> > in a specific file, vim hits 100% CPU usage, becomes unresponsive and need
On 17-Jan-2014 Bram Moolenaar wrote:
>
> Lech Lorens wrote:
>
> > winnr() returns the index of the window 1-based while v:beval_winnr
> > (:help 'bexpr') is 0-based. I believe the latter should be fixed. The
> > attached patch adds increments the v
On 17-Jan-2014 Ingo Karkat wrote:
> On 16-Jan-2014 23:46 +0100, Lech Lorens wrote:
>
> > winnr() returns the index of the window 1-based while v:beval_winnr
> > (:help 'bexpr') is 0-based. I believe the latter should be fixed. The
> > attached patch adds inc
winnr() returns the index of the window 1-based while v:beval_winnr
(:help 'bexpr') is 0-based. I believe the latter should be fixed. The
attached patch adds increments the value of v:beval_winnr by 1.
--
Lech Lorens
--
--
You received this message from the "vim_dev"
On 15 January 2014 10:13, Christian Brabandt wrote:
> On Wed, January 15, 2014 09:59, b...@airbladesoftware.com wrote:
>> Hello!
>>
>> A user of one of my plugins recently reported this error: `E117: Unknown
>> function: gettabvar`. He also told me the version of Vim he's using.
>>
>> How can I f
not set security context "));
+ MSG_PUTS(name);
+ MSG_PUTS(_(" for "));
i.e. so that there's "Could not set security context %s for " string to
translate instead of two shorter strings? Why start it with "\n" btw?
3.
+
On 10 January 2014 20:16, Gary Johnson wrote:
> On 2014-01-10, Bram Moolenaar wrote:
>> Patch 7.4.138 (after 7.4.114)
>> Problem:Directory change messages are not recognized.
>> Solution: Fix using a character range literally. (Lech Lorens)
>> Files:s
On 06-Jan-2014 Lech Lorens wrote:
> On 06-Jan-2014 Bram Moolenaar wrote:
[…]
> > What happens with nested lists and dicts?
>
> Whatever you think would be best. Currently exactly the same that would
> happen locally for string(list_var) or string(dict_var). I find it more
On 06-Jan-2014 Bram Moolenaar wrote:
>
> Lech Lorens wrote:
>
> > Yesterday while remotely debugging some Vim scripts I discovered
> > (actually it is mentioned in the documentation) that remote_expr()
> > imposes a limitation on the type of expressions handled: th
Hi,
Yesterday while remotely debugging some Vim scripts I discovered
(actually it is mentioned in the documentation) that remote_expr()
imposes a limitation on the type of expressions handled: the expression
must be a string or a list (although the implementation correctly
handles integers and
On 30-Dec-2013 Charles Campbell wrote:
> Hello!
>
> I'm using vim 7.4.131 (Huge version with GTK2-GNOME GUI), and
> haven't used Dominque's patch. When trying your problem out, netrw
> went up a directory, even though foo no longer existed; both
> going-up-directory techniques worked ( on "..",
7.4.114 doesn't seem to fix anything but breaks handling GNU make
"Entering directory" messages.
I have no idea how this got into Vim.
Fix attached.
Cheers,
Lech
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
F
On 05-Nov-2013 Lech Lorens wrote:
> On 5 November 2013 10:56, Christian J. Robinson wrote:
> > On Tue, 5 Nov 2013, Lech Lorens wrote:
> >
> >> On 5 November 2013 08:22, Christian J. Robinson wrote:
> >>>
> >>>
> >>> /u
e and pressed
return.
It doesn't crash for me but the Netrw mappings are not removed which
means editing foo is virtually imposible.
> This is with Vim 7.4.131 on Debian Wheezy 64 bits (big build) and Netrw
> v147nNR.
7.4.131 on 32 bits Linux Mint, Netrw v149.
CC: Charles Campbell.
On 12 December 2013 22:47, Lech Lorens wrote:
> I guess this will be a solution to a bug reported by Matteo Cavalleri in
> vim_use. At least it solves the totally messed-up numbers when diffing
> 2 windows, each with 'rnu' set that have been annoying me for a long
> time
I guess this will be a solution to a bug reported by Matteo Cavalleri in
vim_use. At least it solves the totally messed-up numbers when diffing
2 windows, each with 'rnu' set that have been annoying me for a long
time.
--
Lech Lorens
--
--
You received this message from th
On 08-Nov-2013 Lech Lorens wrote:
> On 08-Nov-2013 Bram Moolenaar wrote:
> >
> > Lech Lorens wrote:
> >
> > > Attached is a patch fixing E315 error caused by delete ex command not
> > > resetting visual selection.
> > >
> > > Test inc
On 08-Nov-2013 Bram Moolenaar wrote:
>
> Lech Lorens wrote:
>
> > Attached is a patch fixing E315 error caused by delete ex command not
> > resetting visual selection.
> >
> > Test included.
> >
> > Note that this is related to pressing Escape
On 5 November 2013 10:56, Christian J. Robinson wrote:
> On Tue, 5 Nov 2013, Lech Lorens wrote:
>
>> On 5 November 2013 08:22, Christian J. Robinson wrote:
>>>
>>>
>>> /usr/lib/../include/w32api/winnt.h:4951:15: error: two or more
>>> data
On 5 November 2013 08:22, Christian J. Robinson wrote:
>
> On the 2nd I built 7.3.054 under cygwin, then some new patches came down and
> when I tried to build again I got this:
>
> In file included from /usr/lib/../include/w32api/minwindef.h:146:0,
> from /usr/lib/../incl
*nix, Cygwin). This might mean
that the test file should source unix.vim. Or perhaps check for Vim
having been compiled with X11 support.
--
Lech Lorens
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replyi
On 29-Jul-2013 Stephen Lee wrote:
> On Tuesday, July 30, 2013 1:07:20 AM UTC+8, Ben Fritz wrote:
> >
> > Also note, the recommended place for your _vimrc file is in $HOME (or
> > $HOME/vimfiles with the latest 7.4 beta builds).
>
> Thankyou for your help. It looks like it is just a usage proble
t hope this email will change
anything. I *AM SORRY* and perhaps I believe that sharing will somehow
help me. I am a contributor of around 50-100 patches to Vim, I've been
here for 5 years and I don't feel I'm being taken seriously. I know
there are many others that will come and repl
On 10 July 2013 12:25, Bram Moolenaar wrote:
>
> Milan Vancura wrote:
>
>> > The biggest additions since 7.3:
>> > - A new, faster regular expression engine.
>> > - More than a thousand fixes and small improvements.
>>
>> ...and all the work about python? What's the current status, why it is not
>
On 30-Jun-2013 Lech Lorens wrote:
> On 30-Jun-2013 Bram Moolenaar wrote:
> > The fix seems OK. But the test already passes without it.
>
> Yes, this is what I tried to explain above but somehow didn't make it
> clear ;-)
>
> > Also, the test changes t
he cursor position, and your mapping eats it.
>
> I think we can void the problem by doing the 'ambiwidth' check in the
> second row instead of the first one. The returned sequence will then be
> [2;2R.
Just wanted to confirm that this problem indeed has been solved. Thanks!
is is target bar!
This is target bar!
Press ENTER or type command to continue
#v-
which clearly indicates that ":lmake bar" is executed.
--
Lech Lorens
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are r
On 29-Jun-2013 Aliaksandr Rahalevich wrote:
> It works with
> set regexpengine=1
> but fails to open file with regexpengine=2.
>
> It's definitely working with 1242 patchset, but fails with latest.
I can't believe you actually did send a 3 megabyte attachment to all the
people out there readin
On 30-Jun-2013 Bram Moolenaar wrote:
>
> Lech Lorens wrote:
>
> > I discovered a problem with the 'scrollbind' setting which causes one of
> > the bound windows to scroll unexpectedly introducing an offset to the
> > bounding thus effectively destr
I discovered a problem with the 'scrollbind' setting which causes one of
the bound windows to scroll unexpectedly introducing an offset to the
bounding thus effectively destroying the desired setup.
The attached script scb-problem.vim when sourced will make the problem
apparent. The intention i
ents.
I will prepare test for quickfix1.patch ASAP.
Before I prepare test for quickfix2.patch I would know if the change
will be accepted – I don't want to spend my time on something that will
never be used.
--
Lech Lorens
--
--
You received this message from the "vim_dev" maillis
On 27-Jun-2013 Lech Lorens wrote:
[…]
Actually attaching the patch.
--
Cheers,
Lech
--
--
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
clipboard),
4. enter some text, enter the visual mode and more some of the text,
5. open MS Notepad and press Ctrl-V (paste),
6. your console Vim has just crashed.
--
Lech Lorens
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the
On 26 June 2013 15:57, Charles Campbell wrote:
> mattn wrote:
>>
>> Hi list.
>>
[...]
>>
> I'm afraid that I don't see this problem with synax/vim.vim v7.3-25. You
> can get a copy from my website:
> http://www.drchip.org/astronaut/vim/index.html#SYNTAX_VIM .
> Please try it out and see if your p
I have a list of files grouped by file extension. I am trying to create
a fold for each of the groups. For this purpose I created the following
Vim function:
function! FoldByExtension()
let s:searchSave = @/
let s:wrapscanSave = &ws
set nowrapscan
normal zE
1
while 1
On 19 June 2013 12:31, Anton Konstantinov wrote:
> May be this bug is not sufficient, but i spent a lot time trying to solve
> this problem.
>
> Thank you.
Have you tried increasing the value of 'synmaxcol'?
--
Cheers,
Lech
--
--
You received this message from the "vim_dev" maillist.
Do not t
't simplify it any further; for some reason this does not
work when put in a simple script as follows (both produce 1):
set re=1
echo "string !~ regexp == " . string(string !~ regexp)
set re=2
echo "string !~ regexp == " . string(string !~ regexp)
--
Lech Lorens
--
-
On 15-Jun-2013 Mats Bertil Tegner wrote:
> On 06/15/2013 03:10 PM, Bram Moolenaar wrote:
> >
> >Patch 7.3.1196
> >Problem:Old regexp engine does not match pattern with backref correctly.
> > (Dominique Pelle)
> >Solution: Fix setting status. Test multi-line patterns better.
> >Files
Search for \v.*\/(.*)\n.*\/\1$ in a file with the following contents.
This should find adjacent lines with paths to files with the same base name.
With re=2 I get the first pair of lines highlighted (which is
nonsense). With re=1 I get a correct highlighting of the other pair.
#v+
./Dir1/Dir2/Dir3
ll take the bonus points ;)
> > >
> > > (patch already contained a test)
> >
> > I meant: You get bonus points for writing a test.
>
> Another one? The patch already contained a test for that particular
> problem.
I think Bram meant to say: bonus points fo
On 16 April 2013 06:20, Yegappan Lakshmanan wrote:
> I spent some time trying to narrow down the patch that introduced
> this problem. I am not able to reproduce the crash with the
> 7.2.446 release. But I am able to reproduce the crash with Vim 7.3
> version.
>
> I found that the following change
On 29-Mar-2013 Cody Cutler wrote:
> Hello list. The attached patch allows optional regexs to be passed to
> :tj and friends. these regexs is then used to further refine available
> tags before they are printed.
>
> This patch is useful when you have many tags for a single identifier.
> For exam
On 13-Apr-2013 Bram Moolenaar wrote:
> Thanks. Thus only when ~/.vimrc does not exist then ~/.vim/vimrc will
> be used. That should work for places where a new Vim is installed. For
> older Vim versions one would have to create a ~/.vimrc file that sources
> ~/.vim/vimrc.
Do we want to change
On 12-Apr-2013 Gary Johnson wrote:
> On 2013-04-12, Lech Lorens wrote:
> >
> > On 12 April 2013 13:45, Bram Moolenaar wrote:
> >
> >
> > The updated docs say:
> > Unix$HOME/.gvimrc or $HOME/.vim/gvimrc
> >
On 12-Apr-2013 Bram Moolenaar wrote:
>
> Lech Lorens wrote:
>
> > On 12 April 2013 13:45, Bram Moolenaar wrote:
> >
> > >
> > > The updated docs say:
> > > Unix$HOME/.gvimrc or $HOME/.vim/gvimrc
> > >
On 12 April 2013 13:45, Bram Moolenaar wrote:
>
> The updated docs say:
> Unix$HOME/.gvimrc or $HOME/.vim/gvimrc
> Unix$HOME/.vimrc or $HOME/.vim/vimrc
>
> What does that "or" mean? What if both files exist?
>
> This is an important thing, where yo
:help :read! does not mention that it's possible to specify options with
this form of the :read command.
diff --git a/runtime/doc/insert.txt b/runtime/doc/insert.txt
index 4db4341..0048c75 100644
--- a/runtime/doc/insert.txt
+++ b/runtime/doc/insert.txt
@@ -1869,7 +1869,8 @@ NOTE: These commands
The attached patch makes it possible to move the vimrc and gvimrc files
to your vim settings directory:
~/.vim/ (UNIX)
~\vimfiles\ (Windows)
etc. This makes it easier to move Vim settings from machine to machine:
you just copy one directory to the right place and it works.
Please, check and app
On 03-Apr-2013 Benjamin Fritz wrote:
> On Wed, Apr 3, 2013 at 5:22 AM, Lech Lorens wrote:
> > How do
> > you cope with that? In this case I can't simply check in the file
> > – I have to undo the line endings modifications which is quite a tedious
> > and annoyi
rticular case it is inferior to everything out there.
> Do I understand correctly, that I won't see the problem, because I already
> force-reload the file to remove the mixed line endings?
Yes, you are not going to see any improvements since you are already
handling this one problem.
-
On 02-Apr-2013 glts <676c7...@gmail.com> wrote:
> On Tue, Apr 2, 2013 at 1:59 AM, Lech Lorens wrote:
> > On 01-Apr-2013 Bram Moolenaar wrote:
> >> How about this alternative: Filter your tags file to change the patterns
> >> to include an optional CR before the $
On 02-Apr-2013 Nazri Ramliy wrote:
> On Mon, Apr 1, 2013 at 11:16 PM, Lech Lorens wrote:
> > The problem is that if Vim reads such a file with ff=unix, it will fail
> > to find tags if the tag pattern searched should match on a DOS-style
> > line. The attached patch han
On 01-Apr-2013 Bram Moolenaar wrote:
>
> Lech Lorens wrote:
>
> > People using ctags while working on code which is edited by multiple
> > people in various editors will be familiar with this situation: the code
> > ends up with a mix of line endings – some o
On 01-Apr-2013 David Fishburn wrote:
> On Mon, Apr 1, 2013 at 11:16 AM, Lech Lorens wrote:
>
> > People using ctags while working on code which is edited by multiple
> > people in various editors will be familiar with this situation: the code
> > ends up with a mix o
People using ctags while working on code which is edited by multiple
people in various editors will be familiar with this situation: the code
ends up with a mix of line endings – some of them are Unix-style, some
of them are DOS-style.
The problem is that if Vim reads such a file with ff=unix,
On 30-Mar-2013 Alex Efros wrote:
[…]
Confirmed on Vim 7.3.875.
--
Lech Lorens
--
--
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 rec
On 29-Mar-2013 Cody Cutler wrote:
> Hello list. The attached patch allows optional regexs to be passed to
> :tj and friends. these regexs is then used to further refine available
> tags before they are printed.
>
> This patch is useful when you have many tags for a single identifier.
> For exam
Wouldn't it be better to use the existing 'cinoptions' entry jN? It's
related to Java...
BTW, in the past I made a number of modifications to the indenting
code. It was like treading on a mine field (lots of things I could
break). Would you, please, also include a test case for your
functionality
On 28 February 2013 06:19, Ben Fritz wrote:
> Ugh, I can't reproduce it at home with the example config on Windows Vista.
>
> There has to be something else interfering. I hope it's not some video card
> thing or something. I'll try it on a few more computers at work I suppose.
Confirmed on Wind
the cursor abscissa exceeds a user-selectable value?
It's about code indenting, not highlighting.
--
Cheers,
Lech Lorens
--
--
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:/
On 5 February 2013 17:02, Nazri Ramliy wrote:
> On Tue, Feb 5, 2013 at 5:11 PM, Nazri Ramliy wrote:
>> Attached is an updated patch for the 'linenumber' option (it's getting
>> hairier and hairier! But not that much. I'd say it's less toy-ish by
>> now :)
>>
>> It contains a bugfix - "set (inv|no
The attached patch fixes an E315 error that occurs for me sometimes
when I work in Athena gvim under Cygwin.
The stack trace when the problem occurs is as follows:
#0 ml_get_buf (buf=0x8005b6e8, lnum=124, will_change=0) at memline.c:2435
#1 0x0049a8ad in ml_get_pos (pos=0x289cb4) at memline.c:23
On 19 November 2012 19:50, Christian Brabandt wrote:
> Hi Lech!
>
> On Mo, 19 Nov 2012, Lech Lorens wrote:
>> It might be me that Matt is referring to as a person that took over
>> maintaining the feature. In fact I only updated the patch to be
>> applicable to the so
On 19 November 2012 18:02, Christian Brabandt wrote:
> On Mon, November 19, 2012 17:21, Matthew Winn wrote:
>> I implemented a patch to do this a few years ago, when I was out of
>> work and decided to grab something off the TODO list to keep me busy.
>> (It's since been taken over by someone else
On 1 August 2012 04:38, Kana Natsuno wrote:
> On Wednesday, August 1, 2012 7:03:48 AM UTC+9, Lech Lorens wrote:
>> From ":help InsertLeave":
>>
>> *InsertLeave*
>> InsertLeave When
On 31 July 2012 21:36, Mikey wrote:
> Using as a leader key breaks 'Does not trigger the InsertLeave
> autocommand event'
>
> I use GVim 7.3.600.
> Steps to reproduce:
>
> gvim -u NONE -U NONE
> set nocompatible
> au InsertLeave * :echo "InsertLeave event triggered"
> nnoremap a k
>
> Now enter s
On 21 July 2012 16:45, Lech Lorens wrote:
> On 20 July 2012 21:48, Bram Moolenaar wrote:
>> Lech Lorens wrote:
>>> checkpath.patch contains a patch fixing the problem.
>>
>> Thanks!
>
> I found one more problem with :checkpath! and there are no tests for
The :checkpath! command reports random strings if the 'include' option
is set to a value containing "\zs" and "\ze".
The attached file checkpath-problem.tar.gz includes a couple of files
which allow the problem to show. Just enter the checkpath-problem
directory and run "vim -S ./do.vim". The last
On 13 July 2012 20:19, Dominique Pellé wrote:
> Lech Lorens wrote:
>
> This may be too obvious, but have you made sure that you
> compiled Vim with -O0 -g and made sure the the executable
> was not stripped. Vim's makefile strips the executable by
> default, but you ca
I have found a 100%-reproducible scenario in which Vim crashes. I work
on 2 computers sharing a mouse and a keyboard between them with
Synergy 2. One of the computers runs Windows 7 with Cygwin, the other
is running Linux.
Under Cygwin (no matter whether it is mintty or Cygwin/X with xterm;
it does
On 10 July 2012 23:36, I wrote:
[...]
I forgot to explain that the unpleasant scroll of the window contents
is caused by curwin->w_wrow being set to 0.
Calling win_new_height() inside f_winrestview() is intended to
recompute curwin->w_wrow.
Cheers,
Lech
--
You received this message from the "vi
There are some cases when winrestview() does not restore the way a
window looked when winsaveview() was called.
Namely: the top line is not correctly restored which results in the
contents of the window being scrolled.
The problem can be reproduced with by running the attached files:
- prepare.vim
On 2 July 2012 20:12, Bram Moolenaar wrote:
> Thanks, sounds useful. I'll add it to the todo list.
>
> I do think we need to keep the existing behavior of ":3tabmove", it's
> consistent with using a count for an Ex command. Just document that the
> +3 and -3 only work when the count is after the
The attached patch makes it possible to move a tab X places to the right
by issuing:
:tabmove +X
and X places to the left:
:tabmove -X
A set of tests has been added and the undocumented possibility of
specifying the argument as ":3tabmove" has been removed to prevent the
inconsistency which ":t
On 30 June 2012 13:01, Bram Moolenaar wrote:
> Lech Lorens wrote:
[...]
>> I can't see any spaces I wouldn't expect; for me there are only single
>> spaces at the joining points. Can you specify explicitly what would
>> you expect to be converted into what?
The attached bash script crash.sh causes Vim to crash. I found where a
NULL pointer is being dereferenced and fixed it (find the backtrace at
the moment of the crash below at [1]). However (here's the question to
Tim Pope), if I apply the patch (the attached fix.patch) that avoids
the crash, I am l
On 13 June 2012 14:05, Bram Moolenaar wrote:
>
> I wrote:
>
>> Patch 7.3.550 (after 7.3.541)
>> Problem: With "j" in 'formatoptions' a list leader is not removed. (Gary
>> Johnson)
>> Solution: Don't ignore the start of a
On 25 June 2012 10:43, Kerneels Roos wrote:
> Hi. What I meant is that if the "TO" field is consistently to the list then
> all the filters work :) but if the list's email is in the "Reply-To" or in
> the "Cc" fields then I have to create a new rule :) and do it in Thunderbird
> since Gmail doesn
Not terribly valuable input on the patch but I suppose this:
+ ) || curwin->w_buffer == NUL
should in fact read:
+ ) || curwin->w_buffer == NULL
Cheers,
Lech
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
On 7 June 2012 20:57, David Pineau wrote:
> 2012/6/7 Lech Lorens
>>
>> Admittedly, I did not read the message carefully. I just fixed it to
>> find out that you already did that.
>> Next time just go ahead and attach the patch.
>
> In my patch, I didn't upd
Hi!
Some time ago I remember being surprised that if in an assembly file
there's a modeline stating "ft=foo" and there's "asmsyntax=bar"
declaration, "ft=foo" will have precedence.
Perhaps adding a note to the documentation will save someone from
such a surprise. Find a patch attached.
Cheers,
L
On 7 June 2012 16:09, David Pineau wrote:
> Hello,
>
> While configuring my indentation, I came across a behaviour that seemed
> unintuitive to me (I did not manage to find anything related to this on the
> mailling lists, sorry if I missed it).
>
> When a value in the cinoptions string is describ
On 6 June 2012 19:35, Tony Mechelynck wrote:
> Compiling gvim (Huge) wigh GTK2/Gnome2 GUI after applying patches 7.3.539 to
> 7.3.544:
>
> gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread
> -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0
> -I/usr/include/cairo
On 6 June 2012 17:15, Gary Johnson wrote:
> I'm seeing some unexpected behavior from this patch.
>
> $ vim -N -u NONE foo.vim
>
> where
>
> $ cat foo.vim
> " This is the first line
> " and this is the second line
> " - Now a list item
> " - A second list item
>
> Add 'j' to 'fo
The attached patch adds the "j" flag to 'formatoptions' which is
described in todo.txt as follows:
7 Add 'j' flag to 'formatoptions': Remove comment leader when joining lines.
It makes it possible to perform a join on the following lines:
#v+
/*
* Comment
*/
#v-
to obtain:
#v+
/* Comment */
#
The attached patch causes Vim to handle pointer lines which consist of
a sequence of '-', '.', ' ' or tabs (I added tab handling; the rest was
obviously there).
As a result an error report like this can be handled correctly:
#v+
"foo.c", line 234: undefined identifier "Foo"
for (foo = b
er_id=1203
--
Pozdrawiam,
Lech Lorens
--
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
Hi,
There's a problem with tabpages and BufWinLeave autocommand: when
exiting a buffer which is displayed in the only window in a tab,
the autocommand fires already in a different tab. This can be shown by
executing the following commands in a new Vim session:
#v+
tabnew
tabdo windo echo "Buffer"
1 - 100 din 331 matches
Mail list logo
