On 11/7/20 2:36 am, Tony Mechelynck wrote:
On Fri, Jul 10, 2020 at 5:00 PM Yegappan Lakshmanan wrote:
Hi Tony,
On Fri, Jul 10, 2020 at 7:37 AM Tony Mechelynck
wrote:
On Fri, Jul 10, 2020 at 3:41 AM Yegappan Lakshmanan wrote:
Hi all,
Is anyone able to successfully build GUI Vim on
Not really, I would still have to hunt down messages in the archive,
look at patches to find one that looks like it would work, then figure
out who wrote this anyway...
But let this not be an invitation for someone to do all this work,
because I'm just going to add a line in the todo list and it
On 30/10/12 2:40 AM, Jürgen Krämer wrote:
Hi,
Christian Brabandt wrote:
On Mon, October 29, 2012 16:17, Axel wrote:
s makes the cursor move to the beginning of the line(!) changing the
character found there (hence the $ sign). Also, the character ^ is in
fact not displayed.
And how do you
On 25/10/12 3:17 PM, Bram Moolenaar wrote:
Ben Schmidt wrote:
I think E163 could do with some rewording, or perhaps another error
could be created. It seems E163 is used when there are less than two
arguments, and E165 or E164 when there are two or more. However, the
case when there are zero
On 24/10/12 6:14 PM, Ingo Karkat wrote:
On 24-Oct-2012 02:25:58 +0200, Ben Schmidt wrote:
I think E163 could do with some rewording, or perhaps another error
could be created. It seems E163 is used when there are less than two
arguments, and E165 or E164 when there are two or more. However
I think E163 could do with some rewording, or perhaps another error
could be created. It seems E163 is used when there are less than two
arguments, and E165 or E164 when there are two or more. However, the
case when there are zero arguments is confusing. E.g.
vim -u NONE
:n
E163: There is only
On 18/09/12 8:49 AM, Dominique Pellé wrote:
Raymond Ko raymond.w...@gmail.com wrote:
Hello all,
After compiling VIM with Visual Studio 2012,
apparently a buffer overflow was detected
and caused VIM to crash.
...snip...
mb_unescape() seems to meant for only
decoding individual characters,
On 18/09/12 10:30 AM, Ben Schmidt wrote:
On 18/09/12 8:49 AM, Dominique Pellé wrote:
Raymond Ko raymond.w...@gmail.com wrote:
Hello all,
After compiling VIM with Visual Studio 2012,
apparently a buffer overflow was detected
and caused VIM to crash.
...snip...
mb_unescape() seems to meant
Here are the steps:
1. Get Visual Studio 2012. The Express edition should be using the
same compiler for the backend but I'm not sure.
2. Compile VIM. Not that the default Make_mvc.mak file doesn't work
anymore because the Windows SDK is no longer referenced by the
vcvarsall.bat. Instead I had to
On 29/07/12 11:41 PM, Balazs Kezes wrote:
My vim seems to flicker on big terminals because the output buffer is
limited to 2K. Outputting a full redraw of large screen needs much more
characters (especially if it has lots of colors). Currently it is
distributed to several writes (separated by
I don't understand either the original problem or Bram's comment,
because it works fine for me using Vim 7.3.600, from the Cream site
but without Cream, on Windows XP. I click in the upper left window
and the scroll wheel scrolls the upper left window; I click in the
upper right window and the
Everything in the codebase looks OK to me. win_T is a Vim structure, and
has a w_width member when huge features are enabled. All the appropriate
header files are installed. Ruby builds fine for me (and others) on
other platforms.
Have you applied any patches at all?
If not, my best guess is
I can act as a backup if necessary, too. I've been a bit quiet recently,
but if direct questions or a direct task were in front of me I'd be able
to help out.
Thanks for the offer. John volunteered to be the backup administrator.
Perhaps you can help mentoring students? This involves having a
On 4/03/12 11:30 PM, Bram Moolenaar wrote:
John Beckett wrote:
Bram wrote:
1. Write tests for the regexp engine, so that we can finally
use NFA.
2. Fix bugs and review patches
3. Fix bugs and review patches
2. and 3. should be able to work together, so that the mentor
(me) does not have to
On 3/08/11 6:30 AM, Bram Moolenaar wrote:
Christian Brabandt wrote:
this patch fixes this issue from the todo list:
,
| 8 Add a command to jump to the next character highlighted with
| Error.
`
It implements the [e and ]e movement commands, which move to the
previous or next
Does this have some documentation with it? How will anybody find out about it
if not?
Ben.
On 21/07/11 1:27 AM, Bram Moolenaar wrote:
Patch 7.3.258
Problem:MS-Windows: The edit with existing vim context menu entries can be
unwanted.
Solution: Let a registry entry disable
I extracted a couple of lines from regexp.c (143,144): (vim 7.3.244)
#define BRANCH 3 /* node Match this alternative, or the
* next... */
and put them in a file junk.c. Then
vim -u NONE -N --noplugin junk.c
:syn on
shows the comment-ending pair of characters, */, in error highlighting.
No
On 26/06/11 11:15 AM, ZyX wrote:
Reply to message «Re: [BUG] `verbose set sw?' is not working in help buffer»,
sent 04:12:57 26 June 2011, Sunday
by Bram Moolenaar:
In help files the option values are set to sane values. Option values
set in the program don't have a verbose location.
If I
On 22/06/11 9:37 PM, Paul LeoNerd Evans wrote:
On Tue, Jun 21, 2011 at 10:45:57AM +1000, Ben Schmidt wrote:
I think as far as we got is a 'model' for how mappings should work.
Approach 4 built on all our discussions and clearly set out how mappings
should conceptually work. There were a number
On 21/06/11 12:13 AM, Paul LeoNerd Evans wrote:
On Sun, Jun 19, 2011 at 09:16:00PM +1000, Ben Schmidt wrote:
Yeah, this is a known limitation. We have planned out a roadmap to
fix it, but it is quite a large job, and I don't think anybody is
actually working on it yet. There are plenty
On 19/06/11 3:52 AM, Ian Liu Rodrigues wrote:
Dear list,
When I press ALT_C in GVim, it generates the character ã (a tilde).
This is problematic since I can't create an imap to ALT_C, for typing
ã will also trigger the mapping.
I'm interested in fixing this bug and providing a patch, but I've
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Mar 22 2011 13:03:19)
MS-Windows 32-bit GUI version with OLE support
Included patches: 1-142
Vim maintains the numbered registers 0-9. These are maintained
automatically by Vim.
I had a request for the YankRing plugin to also manage these registers
On 8/06/11 2:38 PM, Bram Moolenaar wrote:
fabian greffrath wrote:
Am 07.06.2011 05:40, schrieb Bram Moolenaar:
This tries to expand a file pattern starting with ~/, which won't work
when $HOME isn't set. However, it should not crash.
You say the shell chokes on the command, but how does
On 3/06/11 9:45 AM, Tony Mechelynck wrote:
On 02/06/11 23:27, Bram Moolenaar wrote:
ZyX wrote:
Is this expected:
try
throw 'Throw'
catch
echoe 'Echoe'
echom 'Echom'
endtry
will show only 'Echoe', but not 'Echom'? I though that «When used
inside a try conditional» refers only to the first
Below is a message from vim_use where we've partially identified the
cause of some bug. Maybe there's a Windows dev here who has some more
ideas, or could reproduce it and track it down? I'm afraid I'm pretty
useless from here.
Smiles,
Ben.
On Thu, May 26, 2011 at 5:00 PM, Ben Schmidt
[redirected from vim_use to vim_dev]
Good idea!
OK, I got confused. I think in vim.h FEAT_GUI should be defined even
when NO_X11_INCLUDES is defined. If there is some place where FEAT_GUI
causes trouble then add a check for NO_X11_INCLUDES there. That should
be a lot cleaner an avoids
On 18/05/11 1:50 AM, Radek wrote:
Another strange behavior of syntax engine. Though it occurs only when
there's at least one syntax group with 'containedin=' attribute, it
affects even completely unrelated syntax items. As before, I feel that
an example will explain it best.
Found it. Not sure
The other question is whether a sizeable population works on camelcase
code and would like to have this solved :).
I would like to see a camelcase and/or underscore-seperation movement
commands. But I think if done, it has to be done really carefully so it
doesn't end up using obscure keys or
On 18/05/11 1:50 AM, Radek wrote:
Another strange behavior of syntax engine. Though it occurs only when
there's at least one syntax group with 'containedin=' attribute, it
affects even completely unrelated syntax items. As before, I feel that
an example will explain it best.
The patch below
On 14/05/11 10:27 PM, Ben Schmidt wrote:
I've tried to look into the code to find the source of this behavior,
but eventually decided that trying to understand what it does would
take me too much time so I gave up.
I had a quick look, too, and haven't spotted the bug yet.
I have tracked
On 15/05/11 9:07 PM, H Xu wrote:
On 05/10/2011 11:22 PM, Bram Moolenaar wrote:
[snips entire patch description including 150+ lines of patches]
Hello Bram,
[...]
Another winner for the worst quote trimming ever.
I have no idea what you even wrote in your other messages, because I
I've tried to look into the code to find the source of this behavior,
but eventually decided that trying to understand what it does would
take me too much time so I gave up.
I had a quick look, too, and haven't spotted the bug yet.
Note that your second example is a red herring:
a[aaa]a
I've recently been trying to write a 'foldtext' setting that is specific
to LaTeX and would include useful information like for a example the
caption information for a folded environment. But then I discovered that
the 'foldtext' setting is local to a window and not to a buffer, making
Here is the version information:
...
+python/dyn +python3/dyn +quickfix +reltime +rightleft -ruby +scrollbind +signs
...
However, :echo has('python') returns 0.
Does the :python command work? If not, perhaps it can't find the python
library at runtime, as it's only dynamically linked.
Have
:python command doesn't work. It gives the following message:
OK. So you need to install Python where Vim can find it. :-)
See :help python-dynamic
Once Python is properly installed, Vim should find it on startup, and
:python should start working and has('python') should return 1.
Also note
Well, what if I yank (in Firefox, say, or in Thunderbird) a multiline sentence
from the middle of a paragraph? As in the example below, I mean? With this
newfangled system, I won't be able to insert it in the middle of a different
paragraph in Vim, except by calling setreg('+', '', 'ac') to force
I love vim, but must admit to not being so fond of the fairly old
looking icon. I recently created a new logo for my own use, and
would be more than happy if you'd like to use it for an actual app
icon or logo.
I quite like the icon, too. I agree the old one (which in recent times, I've only
On 4/05/11 12:11 AM, Jean-Rene David wrote:
* Lech Lorens [2011.05.03 10:00]:
On 03-May-2011 Jean-Rene Davidjrdavid...@magma.ca wrote:
Can someone reproduce this item from the todo list:
When 'lines' is 25 and 'scrolloff' is 12, j scrolls zero or two lines
instead of one. (Constantin Pan,
On 3/05/11 1:04 PM, sc wrote:
On Monday, May 02, 2011 20:02:03 Jean-Rene David wrote:
Can someone reproduce this item from the todo list:
When 'lines' is 25 and 'scrolloff' is 12, j scrolls zero or
two lines instead of one. (Constantin Pan, 2010 Sep 10)
I can't. And I didn't find a
http://groups.google.com/group/vim_dev/browse_thread/thread/36b81acf60548c20
I pointed out that it is a simple DNS issue, and gave some
examples of Sourceforge sites that have chosen to add an
A record for the domain (vim.org for us) in their DNS.
...
216.34.181.97 vim.org
Turns out you're
On 23/04/11 6:29 PM, John Beckett wrote:
Ben Schmidt wrote:
Turns out you're right, John, though I couldn't find any
actual evidence in your mail or the thread you cited to prove it. :-)
However, this page does prove it:
http://sourceforge.net/apps/trac/sourceforge/wiki/Custom%20VHOSTs
Jason wrote:
There is no A record for the domain name vim.org. That is,
this link shouldn't work:
http://vim.org/
That's correct, actually. Not only doesn't it work, but it shouldn't
work. It is a shame people have abused DNS and expect it to work.
Marc wrote:
There have been lot's of
Perhaps the simplest thing is to get some cheap 'DNS hosting' that
offers a 'redirect' function. Basically the function just has a
server listen on port 80 for requests and return a 3xx (preferably
301 in our case) redirect (to http://www.vim.org/ in our case)
whenever it gets one.
I've taken
On 23/04/11 2:33 PM, Ben Schmidt wrote:
Perhaps the simplest thing is to get some cheap 'DNS hosting' that
offers a 'redirect' function. Basically the function just has a
server listen on port 80 for requests and return a 3xx (preferably
301 in our case) redirect (to http://www.vim.org/ in our
On 21/04/11 10:10 AM, Ben Fritz wrote:
On Apr 19, 4:40 am, Yukihiro Nakadairayukihiro.nakada...@gmail.com
wrote:
When assigning or deleting list item no error raised for out-of-range index.
:let list = []
:let list[0] = 0
:echo list
[]
:let list = []
:unlet list[0]
I
If A3's not a showstopper, though, maybe the best next step would be
to start a test suite, to ensure things are working the way they're
supposed to work. Plus it gives a spec to shoot for. Things to
include would definitely be these sets:
Tab Ctrl-I Ctrl-Shift-I ^I
C-m Enter ^M
C-[ Esc
- Whatever byte-stream representation we land on, though, we would need
a more careful survey of what internal Vim things are needed, and a
sensible design for using the private area. That shouldn't be too hard
and probably doesn't need to involve the community too much.
What things
On 19/04/11 12:43 AM, Paul LeoNerd Evans wrote:
On Mon, Apr 18, 2011 at 12:11:01PM +1000, Ben Schmidt wrote:
- Ambiguous key triggers ambiguous map
- ^M triggers ^M
- Specific key triggers specific map, or ambiguous if none
- CSI-Ctrl-M triggers CSI-Ctrl-M or ^M
- CSI-Enter
On 16/04/11 12:45 AM, Paul LeoNerd Evans wrote:
Having recently dredged this topic up again - what is the current state
of plan? Are we happy we have a working model of how things will work
and are just awaiting time to write some code, or are there still
questions lingering about?
I think
as entered literally and in key
notation in the various places in which they could appear. Ben Schmidt
laid out several of those places in his response[4].
Actually, the specific paragraph you referenced in [4] is not a good
one. That was part of an argument I was building against a specific
For backward compatibility reasons, existing -notation should be
considered ambiguous, but we should come up with an extension of this
notation to be considered specific. Perhaps just adding an extra
character after the opening ''--for instance !Enter could mean
Enter, specifically. When
- It sounds like changing the internal Vim byte-stream representation for
keypresses to actually be CSI could be a good idea. By making careful use of the
private area we could ensure Vim can represent everything it needs to, plus
almost by definition it can represent all the keys/modifiers
APPROACH 2:
- -notation LHS defines specific and ambiguous maps
- C-M defines ^M and CSI-Ctrl-M
- Enter defines ^M and CSI-Enter
APPROACH 3:
- Ambiguous LHS defines ambiguous and specific maps
- ^M defines ^M, CSI-Ctrl-M and CSI-Enter
- -notation LHS defines specific and ambiguous maps
- C-M
So, what about executing
1000@@
as
@@999@@
(where in turn 999@@ is executed as
@@998@@
and so on ... and 2@@ as
@@1@@
and 1@@ as
@@
)?
I like the idea. Hadn't thought of using recursion when I wrote about
the issue earlier, but yes, of course, that's an obvious and simple way
to implement it.
On 10/04/11 11:51 PM, Ernie Rael wrote:
Could that change affect undo chunking?
I don't think so, but I could be wrong.
Ben.
--
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
So, what about executing
1000@@
as
@@999@@
(where in turn 999@@ is executed as
@@998@@
and so on ... and 2@@ as
@@1@@
and 1@@ as
@@
)?
I like the idea. Hadn't thought of using recursion when I wrote about
the issue earlier, but yes, of course, that's an obvious and simple way
to implement it.
Rather than reinventing the wheel, have you tried using the :options
command?
I don't think he meant *Vim* options. He's just wanting to present the
user with a menu of sorts, I think.
Ben.
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the
On 31/03/11 3:51 PM, Mun wrote:
Hi,
My OS: Red Hat Enterprise Linux 5.6
My configure command:
configure --with-features=huge --enable-perlinterp --enable-pythoninterp
--enable-gui
I must apologize that I don't have too much to go on with this issue,
but I'll provide what I have and I will
On 23/03/11 3:21 AM, Kevin wrote:
Wanted to suggest adding support for terminal colors to gvim.
I want this, too, and it's on my to-do list to investigate implementing some
time.
That certainly shouldn't stop anyone else jumping in and doing it, though. No idea
when I might have enough time
On 18/03/11 8:38 PM, Philippe Vaucher wrote:
As long as the two triplets of keypresses I suggested originally can all
be represented uniquely, and without reference to timing information in
the Escape vs Alt+ case, then I'm happy with whatever internal
implementation makes it happen.
The two
Dear Patrick,
Your comment is not clear to me.
Help says:
a options results in a word selected using Visual is automatically
yanked to the selection register (*).
It works.
With a suppressed, a Visual selected word is no longer yanked to
the selection buffer (*).
It works.
Now, I see no reason
On 10/03/11 9:20 AM, John Little wrote:
On Mar 9, 8:31 pm, Axelaxel.ben...@cip-kommunal.de wrote:
Entering :echow[tab] in 7.3 138 is giving me - instead of the first
option starting with w - the following wildmenu expansion:
[1] [No Name]
7.3.135, I get warn, which I imagine you should be.
On 9/03/11 6:39 PM, Christian J. Robinson wrote:
On Tue, 8 Mar 2011, Axel wrote:
Addendum:
The same happens for
:set all
The OS is Windows XP.
Does it still happen if you do :set nolazyredraw? A recent patch to fix
something else seems to have introduced this problem with 'lazyredraw'.
I would like to propose a patch which suppresses the conversion of
NL toCR when evaluaation ('\=') is used inside substitute()
function.
Simply this patch is what makes x == y true in the following code.
let x = substitute('a', '.', \n, )
let y = substitute('a', '.', '\=\n', )
Regardless
On 9/03/11 1:00 AM, Sebastian Humenda wrote:
Hello,
I would like to make a suggestion for the graphical Vim. When using
Orca, a screenreader for the graphical desktop, I can't use GVim.
Since the menu's and button's are written in GTK+, there are perfectly
usable, but not the main text body.
Zero reaction on this thread.
Any idea what was in it? Nothing was quoted.
Please think of desperate EasyVim users who never see search hit
BOTTOM, continuing at TOP when using the menu Edit/find then Next.
Please think of busy mailing list subscribers who don't find it easy to go back
In this case, I'd yanked some text that I wanted to 'put' in
a bunch of places. While going through the buffer, putting the text
where I wanted it, I noticed a line that needed to come out, so I
deleted it. Naturally, the next attempt to put gave me that line
instead of the original text I'd
On 24/02/11 8:49 PM, Ulf Magnusson wrote:
Hi,
One problem with searching for phrases in files that contain wrapped
text (LaTeX source files, e-mails, source code comments, etc.) is that
you never know whether two words will be separated by a space or a
newline. Therefore, it would be handy to
Hello,
Please open a file1.
Open a file file2 in a new tab.
Use the File/Close menu to close file2 tab.
The tab is not closed, instead an empty buffer with name No Name
replaces file2.
So the File/Close menu is not a synonym for :close.
Is it a feature or a bug ?
I think it's a bug.
I just tried the file. Opening Vim took about a minute with Vim
running at 100% CPU after which Vim became responsive. I then scrolled
down by repeating 99PageDown and just before I reached the bitmap
part of the XPM file Vim crashed. I've tried a few times and it
crashes every time, but only
On 11/02/11 11:02 PM, Dimitar DIMITROV wrote:
I just tested:
:com! Test ec '♛'
then
:Test prints ♀fdQ
:ec '♛' prints '♛'
So the problem is :com related not tr() as previously thought
Attached is the fix.
K_SPECIAL is not a multibyte character code, so vim_strchr is not an appropriate
way
So basically backward compatibility and memory efficiency are what
hold vim back in 1970. You made a lot of good points and reasons for
it to be so, but I'm always sad when good ideas are refused just
because of old scenarios.
I don't think anybody has refused the idea, and I don't think
This is my first time joining a discussion, I had a hard time just to
open an account and send my suggestion. I use the default reply
function and I don't mean to upset anyone. Hopefull now this reply is
well-edited (I removed the quote).
Yes, it was a much better reply, thanks, Stephen. And
Another way to extend this might be to switch from a byte queue to a short
integer
queue. The lower 8-bits would be as it is now; the upper eight bits would encode
modifier keys (shift, ctrl, alt, meta, whatever).
I think sticking to the byte queue is best. So much in Vim relies on
text being
The whole situation is pretty arbitrary. E.g. ./demo's output under a
modifyOtherKeys:2 UXTerm, compressed to one row, for Shift+ the top row of my
typical US 105-key or variant:
S-~ ! S-@ # $ % S-^ * ( ) S-_ + Backspace
Why the Shift modifier on ~, @, ^, and _, but not !, #, $, etc? (Guessing
Firstly: even if it would be true for ls - it's a matter of 'ls'
maintainers decision, nothing more. Especially it does not say
foo/bar and foo/bar/ are same, in any manner. Only it says is ls
shows them in the same way, sometimes.
That's true. But it's like saying that 3.14159 isn't exactly
On 22/02/11 12:09 AM, Bram Moolenaar wrote:
Phil Carter wrote:
Using ctrl+v U in insert mode, you can enter Unicode characters by
code point. UTF-8 can only encode up to U+7FFF. Entering any code
point up to that value works fine, but if if you type ctrl+v U
81234567 for example, you get
Plus, it's only the queue of incoming keypresses - that queue isn't
going to stay very big for very long.
It's not just the input queue that's in question here, it's everywhere
in Vim where keypresses are represented. For instance, the right hand
sides of mappings are not primarily characters,
Plus, it's only the queue of incoming keypresses - that queue isn't
going to stay very big for very long.
It's not just the input queue that's in question here, it's everywhere
in Vim where keypresses are represented. For instance, the right hand
sides of mappings are not primarily characters,
On 14/02/11 4:12 PM, Yue Wu wrote:
On Sun, Feb 13, 2011 at 07:30:57PM -0800, Ben Fritz wrote:
On Feb 12, 6:10 pm, Yue Wuvano...@gmail.com wrote:
On Sat, Feb 12, 2011 at 09:42:42AM -0800, Ben Fritz wrote:
On Feb 12, 8:15 am, Yue Wuvano...@gmail.com wrote:
As the title, when setting wrap,
On 15/02/11 3:34 AM, Christian Brabandt wrote:
On Mon, February 14, 2011 12:34 pm, Ben Schmidt wrote:
I think there is a bug here, but it's not the bug you think.
I can make a short single line fold, but it doesn't always do it at
first. It seems I have to make a two-line fold and then shorten
On 15/02/11 11:43 AM, Yue Wu wrote:
I'm confused with `screen line', I think 3 screen lines without EOL in
'wrap' condition will be a long screen line in 'nowrap' condition,
right?
Yes, that's right. So with nowrap, that line should only be folded when
fml is 0; but with wrap, it should be
$ cc -o conftest -g -I/usr/local/include -L/usr/local/lib conftest.c
-lm -ltermlib -lelf -lnsl -lsocket -liconv
conftest.c, line 192: warning: statement not reached
This sounds like a bug with the linker for not erroring out when it
can't link against the libraries it has been told to link
Hi, Bram,
It came up in a private conversation I had that this line in get_varp() is
useless:
default:EMSG(_(E356: get_varp ERROR));
The reason is that the first time it is called, it is because set_options_default
is running at initialisation time, and since this happens in
On 4/02/11 8:03 AM, Bram Moolenaar wrote:
Ben Schmidt wrote:
It came up in a private conversation I had that this line in
get_varp() is useless:
default:EMSG(_(E356: get_varp ERROR));
The reason is that the first time it is called, it is because
set_options_default
On 30/01/11 11:05 AM, Marc Weber wrote:
Does the current vim.sf.net page tell about existing repositories where
vim patches mature ?
If if they are never merged upstream it would be nice to have a local
place to share them.
I know about a git repository which collects many of them.
Mmm. But
Anyway: Is there a way to view/set both: local and global settings for those
options which are both?
:set sets both, but displays the value in effect. To display both, you
need to use :setlocal and :setglobal.
Ben.
--
You received this message from the vim_dev maillist.
Do not top-post!
Hi, Bram,
Could the attached changes be incorporated into the syntax/c.vim
included with Vim? I put them together a couple of years ago in response
to a post on one of the mailing lists.
They add support for #if 0...#else and #if 1...#else to highlight the
relevant parts as comments.
I have
On 20/01/11 3:29 PM, Bram Moolenaar wrote:
Ben Schmidt wrote:
Could the attached changes be incorporated into the syntax/c.vim
included with Vim? I put them together a couple of years ago in response
to a post on one of the mailing lists.
They add support for #if 0...#else and #if 1...#else
Oops. Here it is as a patch.
Ben.
On 20/01/11 4:59 PM, Ben Schmidt wrote:
On 20/01/11 3:29 PM, Bram Moolenaar wrote:
Ben Schmidt wrote:
Could the attached changes be incorporated into the syntax/c.vim
included with Vim? I put them together a couple of years ago in response
to a post
There is a variable tabstops patch by Matthew Winn; it's listed on the Vim
patches page (http://groups.google.com/group/vim_dev/web/vim-patches):
I notice on this page at the moment there is a THIS IS GOING TO BREAK
SOON notice from Google. Is there any replacement page somewhere that
takes
FOUND IT!
Correct behaviour relies on a long overflowing, which it does on 32 bit
machines, but not on 64 bit machines.
From onepage(...) in move.c:
long n;
...
while (n = curwin-w_height loff.lnum = 1)
{
topline_back(loff);
n += loff.height;
}
if (n = curwin-w_height) /* at begin of file */
Hi, Matthew,
Have you managed to do any work on this to bring it up to date?
If not, I'll volunteer, as I love this functionality, and have noted a couple of
areas which need fixing/improving since the last patch I have.
Either way, could you send me the latest version of the patch? Or
Hi, Bram,
I'm getting back into doing some Vim coding, and mailing list
interaction and so on, and have come across this old patch (attached;
originally on vim_use).
The changes to ex_cmds.c are obsoleted by patch 7.2.082, but the change
to option.c is still relevant.
The problem is that when
Adding the ability to easily diff the recovered buffer
against the on-disk file (the action recommended to the user)
is a valid request.
I'm not proposing the following as a solution, but I will
mention that there is a related tip:
Spencer Collyer wrote:
On Sun, 8 Feb 2009 20:40:09 -0800, Garrett Whelan wrote:
... Oh, also what is this declaration structure:
2038 static void
2039 list_func_vars(first)
2040 int *first;
2041 {
2042 if (current_funccal != NULL)
2043
I'll make it: make all windows the same height width
How about: make all windows the same size
FWIW, I prefer 'height width'. Neither is strictly correct of course;
consider any three window layout which is a mix of horizontal and
vertical splits.
Ben.
If you're writing to a file that another program critically needs
/that's/ your problem.
Configuration file, for example, is critically for almost every daemon.
Do you think that it is only my problem? No, it is very real scenario
which could happen to everyone who use vim.
He didn't mean
You can compile your own Vim 7.2.075, see
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm
I'm sure Matt is completely capable of doing this, Tony, and almost
certainly needs no assistance.
Before reporting a bug, it is always better to try reproducing it with
the latest
That's what I was thinking. However, it would certainly be easier to
code (and potentially to interact with) if the foldcolumn width would
just grow to accommodate the highest fold level. What do people
think...should 'foldcolumn' be used for the width of the fold column,
complete with a
1 - 100 din 260 matches
Mail list logo
