Christian Brabandt :
> Hi Jan!
>> Now if I want to do that in a :global command I can just do this:
>>
>> g/foo/d _
>>
>> However, this command is not quite as accomodating. It doesn't change the
>> unnamed register, but it does change the clipboard. It seems to clear it, in
>> fact. This affects
Hi,
:ver
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Mar 7 2015 10:48:00)
Included patches: 1-657
Here's a reproducible steps (it assumes that the environment variables
$LINES and $COLUMNS are set to the rows and columns of your terminal):
$ { echo -n " a = "; for i in `seq 1 $LINES`; do for
> Maybe the solution is not to force filling the fold line all the way to the
> right margin but to make it the length of the string foldtext() returned.
Something like an "empty fillchar" (which is currently impossible
AFAIK) would do the trick while still allowing for the current
behaviour in a
Hi all,
a cursory google search shows many posts about cursorline and relativenumber
turning vim slower. In an old low-end netbook I'm using right now this is all
too evident. Say I keep j pressed for a while while editing my (relatively
small) .vimrc. As I understand the issue, cursorline and
Hi Bram,
> The idea of 'colorcolumn' is that it applies to the text. So you can
> align items or make sure they are in a certain column. I don't see
> how that is useful in a folded region. I would think it makes the
> closed fold look odd. I have the idea that the closed fold is "above"
> the
Christian wrote:
> Bram,
>
> On Fr, 06 Mär 2015, Christian Brabandt wrote:
> > On Do, 05 Mär 2015, Carlos Pita wrote:
> >
> > > Hi all,
> > >
> > > is there any way to force the color column to show above a fold header?
> > >
> > > I tried:
> > >
> > > highlight Folded cterm=none ctermbg=non
Bram,
On Fr, 06 Mär 2015, Christian Brabandt wrote:
> On Do, 05 Mär 2015, Carlos Pita wrote:
>
> > Hi all,
> >
> > is there any way to force the color column to show above a fold header?
> >
> > I tried:
> >
> > highlight Folded cterm=none ctermbg=none
> >
> > and
> >
> > highlight clear Fol
John Marriott wrote:
> I get these warnings when compiling on HP-UX:
>
> cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/misc1.o misc1.c
> cc: "misc1.c", line 10178: warning 604: Pointers are not
> assignment-compatible.
> cc: "misc1.c", line 10178: warning 563: Argument #1 is not the correct
Patch 7.4.657 (after 7.4.656)
Problem:Compiler warnings for pointer mismatch.
Solution: Add a typecast. (John Marriott)
Files: src/misc1.c
*** ../vim-7.4.656/src/misc1.c 2015-03-05 21:21:14.497360702 +0100
--- src/misc1.c 2015-03-06 21:34:00.343452890 +0100
***
*** 10175,
I get these warnings when compiling on HP-UX:
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -o objects/misc1.o misc1.c
cc: "misc1.c", line 10178: warning 604: Pointers are not
assignment-compatible.
cc: "misc1.c", line 10178: warning 563: Argument #1 is not the correct type.
cc: "misc1.c", line 10940:
Charles Campbell wrote:
> mattn wrote:
>> let g:foo = 1
>>
>> The SynID of foo is not vimVar. Currently, it's vimIsCommand. IFAIK, it was
>> vimVar in few month ago. I'm thinking vimIsCommand is too generally pattern.
>>
>> syn match vimIsCommand "\<\h\w*\>" contains=vimCommand
>> syn ma
mattn wrote:
> let g:foo = 1
>
> The SynID of foo is not vimVar. Currently, it's vimIsCommand. IFAIK, it was
> vimVar in few month ago. I'm thinking vimIsCommand is too generally pattern.
>
> syn match vimIsCommand"\<\h\w*\>" contains=vimCommand
> syn match vimVar "\<[bwgl
This unused two characters-wide sign column wastes space, take for example a
screen that is vertically splitted to show multiple buffers. The attached
patch fixes this.
For reference, a link to the pyclewn issue tracker that raised the issue:
https://bitbucket.org/xdegaye/pyclewn/issue/7
Patch s
2015-03-04 10:29 GMT+03:00 Ran Regev :
> # alias eali
> alias eali='vim ~/.alias'
Can you replace Vim with echo and show what is `~/.alias` expanded to actually?
> # eali
> Vim: Caught deadly signal SEGV
> Vim: Finished.
> Segmentation fault (core dumped)
>
> # gdb /usr/bin/vim core
>
> Reading
let g:foo = 1
The SynID of foo is not vimVar. Currently, it's vimIsCommand. IFAIK, it was
vimVar in few month ago. I'm thinking vimIsCommand is too generally pattern.
syn match vimIsCommand "\<\h\w*\>" contains=vimCommand
syn match vimVar"\<[bwglsav]:\K\k*\>"
syn match vimVa
I wrote:
> Manuel Ortega wrote:
>
> > On Thu, Mar 5, 2015 at 1:35 PM, Bram Moolenaar wrote:
> >
> > >
> > > Patch 7.4.654
> > > Problem:glob() and globpath() cannot include links to non-existing
> > > files.
> > > (Charles Campbell)
> > > Solution: Add an argument to include
16 matches
Mail list logo
