in ExtUtils::ParseXS changed
slightly. I've never bothered fixing it, because the writing of if_perl.c has
in fact succeeded, so running make again carries on with the build. Perhaps
that work around will work for you?
Regards, John Little
--
--
You received this message from the vim_dev
running on network shares, and maybe there's some such slowing you down.
If you're just looking at the end of the file,
tail -n 10 large_file | vim -
is quick and can be useful. (Shame vim won't open a loop device.)
Regards, John Little
--
--
You received this message from the vim_dev
On Tuesday, July 23, 2013 5:49:23 AM UTC+12, v...@googlecode.com wrote:
New issue 155 by gade...@gmail.com: feature request: Option for keeping
cursor position while scrolling by mouse
http://code.google.com/p/vim/issues/detail?id=155
Right now, vim always shows cursor in viewable part of
On Monday, August 19, 2013 8:16:23 PM UTC+12, Dimitar DIMITROV wrote:
If you use up down k or j you will not move just above/below the char but
in some weird location
My vim 7.4 doesn't do this, but 7.3.547 does, so it looks like a bug that's
been fixed.
Regards, John Little
--
--
You
lines for a
maintainer.
Regards, John Little
--
--
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
and 83, the only ones to mention tags, pass with that change. It
really needs to be checked with a large tags file so that the binary search
stuff is tested.
Regards, John Little
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you
I see this, with re=0 and re=1, and -u NONE. It doesn't matter what's on the
third line; with the text
alpha bravo
alpha bravo
charlie delta
and using
/\v(^.+\n)\1/e
the cursor moves to the l of delta.
This is a regression not present in my vim 7.3.547
Regards, John Little
On Sunday, September 8, 2013 7:29:21 AM UTC+12, Paul Evans wrote:
TERM=xterm, as it should be for this terminal. It's an xterm :)
My xterm XTerm(278) doesn't do that; ctrl-shift-p gives the same as ctrl-p.
Regards, John Little
--
--
You received this message from the vim_dev maillist.
Do
things.
If it does, which terminal app? (I mean, is it gnome-terminal, konsole...) If
it is an actual xterm, what does xterm -v say? And what does
env | grep TERM
at the shell prompt say?
Regards, John Little
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type
My vim 7.4.113 on linux (Kubuntu 13.10) crashes too, no 'caught deadly signal',
just Segmentation fault (core dumped) if run in a terminal.
vim 7.4 from the Kubuntu repository does not, even with :call garbagecollect()
I'll make a debug build...
Regards, John Little
--
--
You received
On Wednesday, December 11, 2013 11:37:55 AM UTC+13, John Little wrote:
I'll make a debug build...
Here's the last 12 lines of the backtrace:
#174623 0x00461591 in set_ref_in_item (tv=0x3945220, copyID=2)
at eval.c:6974
#174624 0x004614d9 in set_ref_in_list (l=0x2b89410
On Thursday, December 12, 2013 1:22:06 AM UTC+13, Bram Moolenaar wrote:
It appears to run out of stack space. Not strange when going 10
levels deep.
Indeed.
The solution would be to make this iterative instead of recursive.
Not so easy to do.
Indeed, I wasn't game to try. Be nice if it
=-1
Regards, John Little
--
--
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
; it doesn't mean @, you need @-@ to match a @.
Regards, John Little
--
--
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
report:
https://groups.google.com/forum/?hl=en#!topic/vim_dev/ZfEpoxL-j7w
Regards, John Little
--
--
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
Hi all,
I reproduced the problems, applied the patch, and they appear fixed. (Kubuntu
13.10, amd64)
Regards, John Little
--
--
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
the mail and home page buttons with gvim but not the search button, as
KDE wants to start a browser on Google if I press it.
Regards, John Little
--
--
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
:h map-error.
Regards, John Little
--
--
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
discovering apt-get build-dep, and judging by how often I posted
about it here so did others.)
Regards, John Little
--
--
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
See :help limits.
No need for all that stuff.
:echo 10*10
will show if your vim has 32 bit integers. Does anyone know how to compile
vim for 64 bit numbers?
Regards, John Little
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply
increase. But :wincmd v | windcmd o increases the width by one.
It seems that after wincmd v gvim is confused as to what state it is in.
Regards, John Little
--
--
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
the screen width is reached).
Regards, John Little
--
--
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
FWIW, gvim 7.3.843, Kubuntu, Huge version with GTK2-GNOME GUI, I’ve seen maybe
80 tooltips, and still going. I count 20 different tips moving the mouse
pointer through the file.
Regards, John Little
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply
It happens for me (on Kubuntu 12.10, 7.3.843).
xclip -o reports
Error: target STRING not available
and other apps (I tried konsole, kate, firefox, LibreOffice) paste nothing.
Regards, John Little
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your
I have runtime/doc/tags in my .hgignore file, but most times I update with
hg fetch --switch-parent
I'm told
abort: outstanding uncommitted changes
so I run hg commit, and the changed comment says
HG: changed runtime/doc/tags
Why isn't this ignored?
Regards, John Little
Patch 7.3.882
...
--- src/term.c2013-04-05 19:49:58.0 +0200
...
line 4137:
char *p = NULL;
This generates a warning for me with gcc -Wshadow, as it shadows a char_u *p
defined for the function on line 3875.
Regards, John Little
--
--
You received
On Sunday, April 7, 2013 9:13:55 AM UTC+12, Christian Brabandt wrote:
BTW: Here is a patch.
Patch fixes it for me.
Regards, John
--
--
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
of does, when the cursor is on the character).
AFAICT test 44 still does not test more than one combining character; I found
שּׁ from
http://www.user.uni-hannover.de/nhtcapri/combining-marks.html near the end,
perhaps the test could use it as a real example.
Regards, John Little
--
--
You
then interact with
the 'maxcombine' option.
Regards, John Little
--
--
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
, the Concise Oxford, which recommends substitute Y for X, the
original wording.
Regards, John Little
--
--
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
and buffer, while %{} items are evaluated in the
context of the window that the statusline belongs to.
Because it makes doing what I want to do basically impossible.
If you want Func() to run in that window's context, why not:
set stl=%{Func()}
Regards, John Little
--
--
You received
'set re=1' -c '/plain_text_string/p' -c :q large.c
reports 7.9 s, again 3.7 s is startup time, so 4.2 s for the search.
Clearly, the new engine is much slower than the old, especially for a simple
text search.
Regards, John Little
--
--
You received this message from the vim_dev maillist.
Do
of nfa_regatom() is only used near
the end; I suggest the declaration be moved to the scope where it is used.
Regards, John Little
--
--
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
of the switch, I'd say either it should be
declared in each case or the one in case NFA_COMPOSING removed.
Regards, John Little
--
--
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
, and it is slow, but vim 7.3.547 (the version I get from
Kubuntu 13.4) was slow, too, just not as slow. It took about 13 s to page
through test.decl, having sourced decl.vim and making the window 120 columns,
with gvim 7.3.547, and about 20 s for 7.3.1089 with re=1 and re=0.
Regards, John Little
on your OS and shell.
Regards, John Little
--
--
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
On Thursday, June 13, 2013 6:31:42 PM UTC+12, SungHyun Nam wrote:
/a\n\(^b$\n\)\{1,2}c
I see this, too; it can be simplified to
/a\n^b$
for me to see a difference. The ^ does not match with re=0, though the help
says it should after a \n.
Regards, John Little
--
--
You received
On Wednesday, June 19, 2013 2:59:10 AM UTC+12, Ken Takata wrote:
Sometimes 'make config' or 'make reconfig' don't work well.
I would get this annoyance about CC, configure complaining that it had been
changed to 'gcc'. Thank you!
--
--
You received this message from the vim_dev maillist.
,
I get Monospace 8.
* GTK3 is looming. I don't like some of the design decisions of GTK3, but more
importantly the Gnome 3 attitude (they know best, and are contemptuous of those
who disagree) rankles. I keep vowing to try out vim-qt.
Regards, John Little
--
--
You received this message
Marcin said:
I am not sure why it get's three Z though. I'd expected to see only two of
them.
The last z eats the first Z, if there are an odd number of z's, as z is a
prefix to two key commands.
Regards, John Little
--
--
You received this message from the vim_dev maillist.
Do
insignificant in the regex, allowing it to be spread over
several lines with indentation and comments). I wonder if something
similar would work in Vim, being intended for Vim scripts rather than
interactive use.
--
John Little
--~--~-~--~~~---~--~~
You received this message
Some years ago on the main vim mailing list I learned the following
gem:
setlocal autoread
function! Tailf()
normal G
checktime
let K_IGNORE = \x80\xFD\x35internal key code that is ignored
call feedkeys(K_IGNORE)
endfunction
augroup tailf
au!
au CursorHold,CursorHoldI * :call Tailf()
As I've posted on the vim_use group, Vim presently always runs
FileChangedShellPost autocommands whenever it checks if the file was
changed outside of vim, whether it has changed or not. This
includes every focus gained event in the GUI.
IMO this is a bug, and makes the event not useful in some
Tony Mechelynck wrote:
Is the following normal?
snip
rsync -avzcP --delete --exclude=/dos/ ftp.nluug.nl::Vim/runtime/
Tony, that --delete on your rsync command on your web site is, well, a
bit aggressive. I use subversion and it was broken by that --delete
because it trashed subversion's
The tail script http://www.vim.org/scripts/script.php?script_id=1714
causes cursor hold events to continually fire
(which suits its purposes very well), but only if the file it is
watching changes. So, something it does recocks the cursorhold event.
Regards, John
On Oct 14, 12:13 pm, frankjas [EMAIL PROTECTED] wrote:
I have been encountering an intermittent coredump ...
I rebuilt vim from source with symbols after I stumbled on a
reproduceable test case today...
Brilliant.
follows. It looks like the field uh_next_alt is being corrupted. Often
in
Hi
I like to conserve screen space, so I tried to change my GTK scrollbar
width in a gtk rc file:
style scroll
{
GtkScrollbar::slider-width= 10
}
class * style scroll
Now, gvim drew a narrow scrollbar in a wide space. Nosing around, I
found in gui.h,
/* Default size of scrollbar
Hi
Does anybody else see that bug too?
No. Ubuntu 8.04, x86_64, vim 7.2.042, huge including
+xterm_clipboard.
Regards, John
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
Dominique
When I follow this:
1/ start vim with valgrind: valgrind 2 valgrind.log vim -u NONE
2/ select some text with mouse outside vim (one line is enough)
3/ enter INSERT mode in vim and type some text: iThis is a testEsc
4/ visual select line typed in 3/ with: V
5/ click middle
Hi
On Nov 26, 6:40 am, Charles Campbell wrote:
catch /^Vim:\%((\a\+)\)\=:E801/
Your pattern doesn't match. In my vim v:exception has
Vim(call):E801: ID already taken: 4
Your pattern has an extra : after Vim.
Regards, John
--~--~-~--~~~---~--~~
You
Renato Alves wrote:
The visual-block operation makes the cursor invisible. This only
happens on the _1st character_ of each line and when numbers are active.
I see this with xterm, but not konsole or gnome-terminal. Rather than
say the cursor has been made invisible I would say the visual
Christian Brabandt said:
Vim doesn't care, whether the values are negative or positive. I can
successfully use negative values using either the Windows built or the
GTK built. What Gui are you using? It sounds rather like an issue with
your gui toolkit.
Er... on my gvim 7.3.353 Huge version
Hi all
I'm revising the function f_readfile in eval.c, to speed it up when
processing very long lines. (It presently grows a string every 200
bytes by allocating a new one 200 bytes longer, copying the old to the
new, and deallocating the new. F.ex., for a 1 MB line, such as may be
used by the
On Jan 20, 5:42 pm, Benjamin R. Haskell v...@benizi.com wrote:
I don't know the background of 'f_readfile', but why would the BOM be
removed in positions other than at the start of the string? Isn't it
only meaningful as an encoding detection when it's the first thing being
read? Anywhere
On Jan 21, 11:50 pm, Dominique Pellé dominique.pe...@gmail.com
wrote:
And graph after patch is here:
http://dominique.pelle.free.fr/time-readfile.png
Thank you, an interesting tutorial. Next time I want to graph
something I'll be searching for your post rather than firing up a
spreadsheet.
On Jan 22, 11:09 pm, Dominique Pellé dominique.pe...@gmail.com
wrote:
My patch also did not address the buggy removal of BOM as
you indicated...
The BOM bug can be reproduced ...
Perhaps more relevant in practice, CR before NL removal has the same
problem and can be demonstrated with a line
On Jan 22, 11:09 pm, Dominique Pellé dominique.pe...@gmail.com
wrote:
I'm curious to see your patch when ready.
Reading by buffer of 200 bytes makes f_readfile() complicated.
I think we're better off reading byte by byte using fgetc(fd)...
Googling fgetc performance indicates that on some
Hi all
Here's my version of the code for the readfile() function.
It fixes:
- Extreme slowness when lines are very long, such as those used by the
YankRing plugin.
- CR removal failed for lines 199 bytes long.
- BOM removal failed if the bom crossed a block boundary. They wouldn't
normally
On Feb 3, 3:21 pm, Charles peac...@gmail.com wrote:
Here's the patch adjusted to the hg source.
Thank you. I did the diff from hg, but I must have got my repository
out of line.
Also MSVC compiler doesn't
recognize MAX so I changed it into max.
I only used it because I saw it in other vim
On Feb 4, 10:17 am, Mikey smieciar...@gmail.com wrote:
Hello again.
Accidentally I've discovered some new facts about described problem.
In contrast to my previous posts now I dare to claim that the source
of bug is in the Vim itself. Steps to reproduce: ...
Yes, I get it too, but it's more
Ben
Is there a reason you don't use the ?: operator?
if (p_acd)
{
ea.cmdidx = CMD_cd;
}
else
{
ea.cmdidx = CMD_lcd;
}
seems more vim-C-ish written as
ea.cmdidx = p_acd ? CMD_cd : CMD_lcd;
to me, anyway.
Regards, John
--
You received this message
On Feb 14, 11:45 am, Ernie Rael e...@raelity.com wrote:
On 2/13/2012 2:36 PM, Dominique Pellé wrote: since realloc() can only be
faster than ...
Perhaps can not be slower than is more accurate
Disregarding function call overheads, I agree. I can imagine
scenarios with the heap being heavily
On Feb 14, 9:17 pm, Alexey Muranov alexey.mura...@gmail.com wrote:
Thanks a lot, i should have googled better.
IMO searching vim's help directly is better than googling. People
just like you pour over vim's help and suggest changes and cross
references over the years.
:help incsearch was what
When I start VIM with gvim or vim -g I get an escape sequence in the
terminal windows (esc has been replaced with ^] to show the full byte
sequence):
Do you have a redraw in your .vimrc, or something called from there?
If so, you've struck the problem discussed in
On Monday, March 19, 2012 4:15:43 PM UTC+13, Tony Mechelynck wrote:
Yes, it is possible (I do it), BUT: not only do I get a prompt whenever
I try to pull changes including runtime/doc/tags, but in addition that
prompt is not visible until AFTER I answer it ...
Perhaps an application for the
On Saturday, March 24, 2012 10:40:49 PM UTC+13, rameo wrote:
p.e.in a little window beside the vim window.
Well, if you type exactly
:for i in range(3,30)
put ='2**' . i . ' = '.printf('%-10.0f',pow(2,i))
endfor
That's exactly what will appear, in a few lines at the bottom of the vim
screen.
Sorry guys, the new google groups web interface appeared to have lost my first
post; it did not show when I reviewed the thread. Cursing, I retyped it, then
the first one popped back. Perhaps some interaction with my browser cache;
I've noticed that when I uncheck Let pages override these
There's a copyright notice:
# Copyright (©) 2001 by Jörg Ziefle joerg.ziefle@gmx.obfuscated
The © and the ö are encoded in ISO 8859-1, aka latin1
sed: RE error: illegal byte sequence
This looks to me like weirdness in the OS X implementation of sed. Mine (GNU
sed version 4.2.1) has no
Sorry, I can't reproduce this, vim 7.3.475 and xxd V1.10 on linux.
What versions and OS? What 16 bytes do you get?
I suspected there was some interaction with the endofline option, which applies
if you set binary, but I have to explicitly :set binary noeol before saving to
get a 16 byte file
Quick answer, hack the Makefile in the src directory. Mine has lots of lines
setting CFLAGS all commented out, except for the one I use, which has -g.
Regards, John
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For
On Friday, May 4, 2012 6:37:37 AM UTC+12, Bovy, Stephen wrote:
I am not a unix guru, what am I missing ??
Four more backslashes.
CFLAGS=`$as_echo $CFLAGS | sed 's/(/(/g;s/)/)/g'`
Regards, John
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply
On Thursday, May 17, 2012 11:24:15 AM UTC+12, Mikkel H wrote:
Can anyone help me figure out how to debug this issue, perhaps even fix it?
The TERM environment variable on the FreeBSD box is the first thing. It must
match the capabilities of what's on the mac, iTerm2 or Terminal.app. Logged
On Sunday, May 27, 2012 1:34:35 PM UTC+12, Richard Bronosky wrote:
Am I missing something here?
It would appear so, IIUC: the script highlights correctly for me if I
- name it with a .bash extension
- have a bash shebang, say #!/bin/bash or #!/bin/env bash
- :let is_bash = 1
.
The = and , in your example are other non-blank characters, so are words
for the purposes of b, e and w movements. vi was like this.
If you
:set isk=@,=-=,,-,
then w moves from the b to the end of the line. So, clearly 'iskeyword' is not
ignored.
Regards, John Little
--
You received this message from
:help text-object.
Regards, John Little
--
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
=lines
since the command/status line is no longer visible.
...
KDE 4.3.1
I get this too, with KDE 4.7.4, and also Gnome 3 (ugh) and Gnome 3 classic, vim
7.3.566 and also 7.3.154.
Regards, John Little
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply
are going to be applied, and what other
desktop components like panels might occupy screen space. I speculate that the
present approach
I'm going to experiment setting fit_to_display.
Regards, John Little
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply
On Wednesday, June 27, 2012 4:45:19 PM UTC+12, John Little wrote:
option.c calls gui_set_shellsize (in gui.c), with its 'fit_to_display'
parameter set to false;
That was written with the faulty recall of a late night debug session.
option.c does call gui_set_shellsize, but not directly
As I expected, setting fit_to_display gives a smaller vim window than not
setting it, two lines less, with a gap at the top of the display, unless the
vim shell was already at the top, in which case the gap is at the bottom.
Regards, John
--
You received this message from the vim_dev
On Friday, August 31, 2012 5:48:41 AM UTC+12, joe M wrote:
Just a heads-up to this group, the latest vim build from mercurial is
being affected by the below issue.
Thank you, but you seem to imply that there may be a bug in vim, that could be
addressed here. I expect that if there is any bug
I'm not sure I understand what you're annoyed by, but FWIW, my vim-gtk on Linux
appears to have a two-pixel internal border, which is coloured using the
Normal guibg, so is not noticeable. Do you really get that 5 pixel black
border?
--
You received this message from the vim_dev maillist.
Do
I am not sure I can see black borders, mine are white (right one and bottom
one). I found that on mouse over them the cursor changes to window resize, so
there are two resize events I guess. Vim's one and Winblows one.
Oops, I view Google groups with colours inverted, (white backgrounds
Works 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
FWIW, on Unix if you manage to get such a variable into the environment (bash
won't let you)
:echo libcall('', 'getenv', '$ProgramFiles(x86)')
will show it to you.
Surely, there's a better way.
Regards, John
--
You received this message from the vim_dev maillist.
Do not top-post! Type your
On Tuesday, November 27, 2012 1:12:42 AM UTC+13, WU Yue wrote:
Today I read a article about xorg's ClipboardPersistence bug [1], vim is
in the affected broken application list, and I'm sure the bug is still in
vim.
That's not a bug in vim; it's the way X worked historically. The
don't know if there's a cleaner way.
Regards, John Little
--
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
On Saturday, December 1, 2012 7:42:54 PM UTC+13, François Ingelrest wrote:
At step 3 I get a blank screen with no listing.
So do I.
On Kubuntu 12.10, vim 7.3.742, Huge version with GTK2-GNOME, starting vim with
vim -u NONE -N -c 'let g:netrw_liststyle=3' \
-c 'so
On Saturday, December 1, 2012 8:54:16 PM UTC+13, John Little wrote:
Attempting to install the latest netrw...
I downloaded netrw 147b from
http://www.drchip.org/astronaut/vim/index.html#NETRW
but it didn't work at all, home/john/ was prepended to every filename, note
no leading / (yes, my
John Little wrote:
I downloaded netrw 147b from
http://www.drchip.org/astronaut/vim/index.html#NETRW
but it didn't work at all, home/john/ was prepended to every filename,
note no leading / (yes, my home directory is /home/john).
and DrChip replied:
I haven't been able
I've just spent a few hours trying to track this down. It was very frustrating
as vim's behaviour became unpredictable, though I think I know the cause.
Using :Decho went bananas until I found the comment that explained that
DechoTabOn was necessary, but even that was subject to weirdness
On Sunday, December 2, 2012 4:31:43 AM UTC+13, DrChip wrote:
Unfortunately, I haven't been able to duplicate this loss of buffer with
a simpler example as yet.
I can reproduce it with
vim -u NONE -N -c 'so $VIMRUNTIME/plugin/netrwPlugin.vim'
:e .
iii
Maybe your .vim/.netrwhist needs to
CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_FEAT='--with-features=huge'
and source this before a make reconfig.
I imagine not many people do a normal build with the GUI, though looking at
:help +feature-list only +multi-byte and +conceal would appear to be relevant
to me.
Regards, John Little
by but I've seen other people try that
it's not a kosher movement.
Regards, John Little
--
--
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
On Sunday, January 27, 2013 5:44:38 PM UTC+13, James McCoy wrote:
Not that it isn't a kosher movement, but that (I don't think) it should
be a valid method to extend the range of a visual selection. As I
stated in my earlier email, changing to cmdline mode ends visual mode.
I kind of see
Why is Windows QuickEdit mode command prompt unable to do the same?
That seems incredible.
xterm (and so many of its emulators) defines an escape sequence that
requests mouse events to be passed to the app as escape sequences.
cmd.exe presumably lacks such a mechanism. It seems to be a bare-
Bram said:
The Mercurial repository now gets you the latest 7.3 version. If you
were following the vim73 branch, you need to do:
hg update default
I did that, and I got 7.2.446.
Then I tried hg update -C, it did nothing. Then I ran hg pull, and it
pulled all the 7.3 beta changes.
On Aug 22, 9:34 am, Jason Holt credential...@gmail.com wrote:
Hello. I got vim ported to
android:http://credentiality2.blogspot.com/2010/08/native-vim-for-android.html
Awesome.
But I'm getting weird behavior with $HOME:
What does vim say $HOME is? Type :echo $HOME in vim.
Regards, John
On Sep 19, 10:35 pm, Tom Link micat...@gmail.com wrote:
When I type
:echo eval('1.0')
I get an E806 error using Float as a String. This happens with...
... gvim 7.2.330 (the version that shipped
with ubuntu 10.04) ...
I run ubuntu 10.04 and gvim 7.2.330 doesn't do that for me.
--
You
I am sure that mapping mouse events used to work well in Vim 7.2.
I happened to be on Win XP with vim 7.2 when I read your post, and my
reading of :help scroll-mouse-wheel (For the Win32 GUI the scroll
action is hard coded) is that you can't map it.
Regards, John
--
You received this
Thanks for this, it has bugged me for years. I've been pressing tab
space to work around it.
BTW,
...The Gtk docs ...
Can you recommend any GTK docs or guides? I have other vim gtk nits
I'd like to pick.
Regards, John
--
You received this message from the vim_dev maillist.
Do not
1 - 100 din 226 matches
Mail list logo
