Re: Proposal/Discussion on decoupling clipboard functionality from X11
On 2/10/24 00:35, Tony Mechelynck wrote: > I used to have a HowTo page about it — two, actually, one for > Unix/Linux and one for Windows — but my ISP took down my user > site, saying "Our engineers will gladly design a user site for > you". I thought I had saved the contents somewhere, but alas, > at the moment I cant't find it back, or I would have attached > the Linux page to this message. Tony, Your site has a number of snapshots saved by the Internet Archive's Wayback Machine: https://web.archive.org/web/2021050100*/http://users.skynet.be/antoine.mechelynck/ The snapshot from 2021-07-22 appears to be the most recent, but that seems to be after the site went down: https://web.archive.org/web/20210722042200/http://users.skynet.be/antoine.mechelynck/ The most recent snapshot that appears to work is from 2021-03-30: https://web.archive.org/web/20210330142852/http://users.skynet.be/antoine.mechelynck/ Your link to "The Vim Editor" page works in that snapshot, with the Linux instructions for compiling Vim still present: https://web.archive.org/web/20210411035912/http://users.skynet.be/antoine.mechelynck/vim/compunix.htm Hopefully you can resurrect whatever portions of your original web site that you'd like to keep. Michael Henry -- -- 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/6f2e8a14-65ce-4142-b492-5c4d781edf0b%40drmikehenry.com.
Re: Overflow detection issue in 9.0.2111, 9.0.2109
On 11/17/23 06:50, Christian Brabandt wrote: > Thanks both. I have created the following PR to address this > and another issue reported by Coverity: > https://github.com/vim/vim/pull/13539 > > I think it should work as expected now, but please verify. It looks correct to me. Thanks for the rapid response! You've really been putting in the time lately. Bram left some big shoes to fill, and I appreciate how hard you have been working for the Vim community. Michael Henry -- -- 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/16fed3c5-33ca-458c-b69f-bdca86f33dcd%40drmikehenry.com.
Re: Overflow detection issue in 9.0.2111, 9.0.2109
Hi, Ernie, > I just tried the following as a single compare at entry > (derived from: x * 10 + digit <= max) if (x > ((INT_MAX - digit) / 10)) return FAIL; > AFAICT, it replicates your results without a separate check > for addition. Yes, I think `x > ((INT_MAX - digit) / 10)` is an accurate test for predicting overflow. A separate check might be a little easier to reason about, though in my experience people find it complicated no matter how the check is implemented due to the truncating nature of division; but I shouldn't have said a second check was necessary, but rather that checking only `x` (without consideration of `digit`) is insufficient to make an accurate check. Extracting this logic into a function provides a single location for explaining why the above test is correct, so I see no reason not to use this more compact implementation. As a user, I'd prefer in general that Vim perform range calculations accurately rather than approximately. The most important thing is to avoid generating signed overflow, as this leads to undefined behavior in C. Approximating the above check using `9` instead of `digit` is conservative; it avoids all overflow cases while disallowing some valid (but extremely large) values. Given that these values are generally being typed in by humans and that most uses of these values have additional range constraints far smaller than `INT_MAX`, I can understand the temptation to throw away a few huge values. If this were performance-critical code, it would make sense to consider an approximate solution. But this code is generally running character-by-character as the user types in keystrokes, and after converting the characters to integer values, the subsequent operations that use these integers will in general take much longer to execute than the integer conversion code. I think it's unlikely the difference could be measured in a Vim benchmark. Since a helper function like this is general-purpose code, I'd prefer the exact implementation unless profiling demonstrates a performance bottleneck. Michael Henry -- -- 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/4fbb1843-4553-46d0-b0de-a2bae5603330%40drmikehenry.com.
Overflow detection issue in 9.0.2111, 9.0.2109
All,
I noticed these two patches too late to comment on the associated pull
request:
- patch 9.0.2111: [security]: overflow in get_number:
- patch 9.0.2109: [security]: overflow in nv_z_get_count:
Both perform overflow detection similarly, verifying that multiplication
by 10 does not overflow; in both cases, the detection logic lacks a
necessary extra check to ensure the addition of the new digit value does
not overflow.
For the `int` case, on a typical box with 32-bit `int` the value of
`INT_MAX` will be 2147483647. Consider the case where all but the last
`7` has been typed; the current value is then 214748364, which is no
greater than `INT_MAX/10`, so another digit is accepted. Multiplying by
10 yields 21474836470. Any digit up to `7` will remain in range, but
`8` and `9` will cause overflow. Similar logic applies for the `long` case.
The below example program shows helper functions for detecting whether a
given value (`int` or `long`) can accept another digit.
```c
#include
#include
#define OK 1
#define FAIL 0
#define CHECK_ADDITION 1
int
vim_append_digit_int(int *value, int digit)
{
int x = *value;
if (x > (INT_MAX / 10))
return FAIL;
x *= 10;
#if CHECK_ADDITION
if (x > (INT_MAX - digit))
return FAIL;
#endif
x += digit;
*value = x;
return OK;
}
int
vim_append_digit_long(long *value, int digit)
{
long x = *value;
if (x > (LONG_MAX / 10))
return FAIL;
x *= 10;
#if CHECK_ADDITION
if (x > (LONG_MAX - digit))
return FAIL;
#endif
x += digit;
*value = x;
return OK;
}
static void
testInt(int value, int digit)
{
int oldValue = value;
int success = vim_append_digit_int(&value, digit);
if (success)
{
printf("int: %d:%d = %d <= %d\n", oldValue, digit, value, INT_MAX);
}
else
{
printf("int: %d:%d > %d (FAIL)\n", oldValue, digit, INT_MAX);
}
}
static void
testLong(long value, int digit)
{
long oldValue = value;
int success = vim_append_digit_long(&value, digit);
if (success)
{
printf("long: %ld:%d = %ld <= %ld\n", oldValue, digit, value,
LONG_MAX);
}
else
{
printf("long: %ld:%d > %ld (FAIL)\n", oldValue, digit, LONG_MAX);
}
}
int
main(void)
{
testInt(INT_MAX / 10, 0);
testInt(INT_MAX / 10, INT_MAX % 10);
testInt(INT_MAX / 10, INT_MAX % 10 + 1);
testLong(LONG_MAX / 10, 0);
testLong(LONG_MAX / 10, LONG_MAX % 10);
testLong(LONG_MAX / 10, LONG_MAX % 10 + 1);
return 0;
}
```
On my 64-bit Ubuntu Linux machine, I get the following output:
```
int: 214748364:0 = 2147483640 <= 2147483647
int: 214748364:7 = 2147483647 <= 2147483647
int: 214748364:8 > 2147483647 (FAIL)
long: 922337203685477580:0 = 9223372036854775800 <= 9223372036854775807
long: 922337203685477580:7 = 9223372036854775807 <= 9223372036854775807
long: 922337203685477580:8 > 9223372036854775807 (FAIL)
```
In the sample program change `CHECK_ADDITION` to `0` to demonstrate the
need for the second check.
Michael Henry
--
--
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/0508913e-a47a-4bd5-a5ce-e528eec801c7%40drmikehenry.com.
Re: Proper way to find when a function appeared in vim
:04 04 f914e241611c09b17fdeb5a7910f8000f22c6308 b4e89aaa22df2526168397d90110ee9a5a658de0 M runtime :04 04 cbc446e0dbc2e2b20e2251961eb4ff1f10f2ee5b 4ce29cab4483f42b95adafb3f07b62479df7f808 M src bisect run success This technique helps when the commit message doesn't necessarily mention the text you are searching for. Michael Henry -- -- 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/31c267e9-f324-6579-fd45-26f1d2b536a6%40drmikehenry.com.
Simplify "syn region" regex for reStructuredText literal text
All, Vim's reStructuredText syntax highlighting currently has a difficult to fix problem described below. There exists a fairly complex solution that's hard to simplify. Can anyone suggest a simpler solution that's being overlooked here? Currently, the below snippet of reStructuredText has a syntax highlighting problem: - A bullet with literal following:: Correctly highlighted literal Incorrectly highlighted as literal Correctly unhighlighted. A literal block is introduced via a line ending in ``::``; it continues for all lines that are indented further than this introductory line. For bulleted or numbered lines, there is an additional complexity: the reference point for indentation is measured not from the start of the line, but from the first non-white character after the bullet or number. In the example above, the indentation reference point is the column with the ``A`` in ``A bullet with literal following`` (two columns after the initial bullet, ``-``). Currently, highlighting is incorrectly measured from the bullet itself, leading to the line ``Incorrectly highlighted as literal`` being highlighted as literal text, even though it is not indented further than the reference ``A``. Numbered lines have a similar problem, e.g.: 1000. One thousand:: Indented Not indented, yet highlighted The current rst syntax file uses the below simple ``syn region`` to detect lines ending in ``::`` in order to activate the ``rstLiteralBlock`` region: syn region rstLiteralBlock matchgroup=rstDelimiter \ start='\(^\z(\s*\).*\)\@<=::\n\s*\n' \ skip='^\s*$' \ end='^\(\z1\s\+\)\@!' \ contains=@NoSpell It uses the regular expression ``^\z(\s*\)`` in ``start=`` to capture any whitespace at the start of the line (before any optional bullet or number), storing this captured whitespace in ``\z1``; it then uses the absence of more than this amount of leading whitespace to detect the end of the literal block in the ``end=`` expression. The problem is that the columns consumed by a bullet or number aren't figuring into the calculation for minimum required indentation. There doesn't appear to be a simple way to capture the bullet or number within the ``start=`` regular expression, and then convert that captured text into a requirement to match the same number of characters of whitespace in the ``end=`` line. For example, an initial line of `` 1000. One thousand::`` has two leading spaces, four columns for ``1000`` and two columns for the period and the following space; literal text would then need to be indented at least one more space than this (a minimum of 2 + 4 + 2 + 1 = 9 spaces in this example). The leading whitespace and bullet-or-number could be captured into a group and passed to the ``end=`` regular expression, but there doesn't appear to be any way to construct a pattern of that many spaces. If ``\z1`` were the captured text `` 1000. ``, then conceptually ``len(\z1) + 1`` would be the number of spaces to match (if that were legal syntax). The complex solution contains a large amount of explanatory documentation and a lot of code that carefully constructs a complicated regular expression to work around the lack of a ``len(\z1)`` feature. The basic idea is to split the possible matches from ``start=`` into different groups, where all members of a given group consume the same number of characters. For example, a bullet character such as ``-`` or ``*`` consumes a single column; ``1.`` and ``9.`` consume two columns; ``(1)``, ``99.``, etc., consume three columns; and so on. Based on which group has matched, it's possible to know the length of the captured text. Given the wide variety of bullet types and enumeration syntaxes supported by reStructuredText, this leads to a very large regular expression. There are two main questions: - Is there a simpler way to solve this? - Will the complex regular expression cause performance problems? Any suggestions or comments are welcome. Michael Henry Here's the pull request containing the complex solution shown below: https://github.com/marshallward/vim-restructuredtext/pull/63 The commit is here: https://github.com/marshallward/vim-restructuredtext/pull/63/commits/102d8f4bd1c906846012a90c2069440fd6cb92e0 To ensure the mailing list contains the full idea for archival purposes, the commit is copied below this line as well. ## """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Re: Add ttymouse=xterm support when TERM=tmux
On 09/29/2016 07:34 AM, James McCoy wrote: > > On Sep 29, 2016 7:12 AM, "Christian Brabandt" wrote: > > I thought, tmux proposed to use the screen terminal entry? > > Staying in 2.1 tmux can be used to differentiate functionality. > > https://github.com/tmux/tmux/blob/20598dff258da1e96a060adba95e8e05bfdd8b3b/FAQ#L355-L378 Yes, the difference between the ``screen`` and ``tmux`` termcap entries is how they deal with italics and reverse-mode video. That's the motivation for setting ``TERM=tmux``, as GNU screen doesn't support italics and the terminfo for ``TERM=screen`` is incorrect for use with tmux: $ infocmp screen tmux comparing screen to tmux. comparing booleans. comparing numbers. ncv: NULL, NULL. comparing strings. ritm: NULL, '\E[23m'. rmso: '\E[23m', '\E[27m'. sitm: NULL, '\E[3m'. smso: '\E[3m', '\E[7m'. Most Vim functionality works correctly with ``TERM=tmux``, but the mouse is detected incorrectly. It works for ``TERM=screen`` because of the special-case checks for ``screen`` (among others) in Vim's ``use_xterm_like_mouse()`` function. At present it appears that hard-coding knowledge of certain terminals into Vim's source is the solution for determining the correct mouse protocol, which is why I proposed adding support for tmux in the above function. Is there a different way Vim should be detecting the mouse protocol? Michael Henry -- -- 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.
Add ttymouse=xterm support when TERM=tmux
All, Vim has compiled-in knowledge of a few terminals whose mouse support is like that of xterm. One such terminal is GNU screen. Missing from this list is tmux, a terminal multiplexer similar to GNU screen: https://tmux.github.io/ When ``$TERM`` is ``screen``, Vim automatically performs the equivalent of ``:set ttymouse=xterm``; when ``$TERM`` is ``tmux``, ``ttymouse`` is left unset which causes the following incorrect mouse-related settings to be set: ^[[ ^[} ^[MG in particular interferes with the processing of key codes that start with ``^[[``. I'd like to propose the below patch which adds supports for tmux in the same way that Vim currently supports screen. diff --git a/src/os_unix.c b/src/os_unix.c index 5f1c487..f12e944 100644 --- a/src/os_unix.c +++ b/src/os_unix.c @@ -2261,6 +2261,7 @@ use_xterm_like_mouse(char_u *name) return (name != NULL && (term_is_xterm || STRNICMP(name, "screen", 6) == 0 +|| STRNICMP(name, "tmux", 4) == 0 || STRICMP(name, "st") == 0 || STRNICMP(name, "st-", 3) == 0 || STRNICMP(name, "stterm", 6) == 0)); Thanks, Michael Henry -- -- 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 8 pre-announcement
On 08/18/2016 02:11 PM, Yegappan Lakshmanan wrote: > On Thu, Aug 18, 2016 at 5:48 AM, Michael Henry wrote: >> I was trying to find something in the help regarding the meaning >> of a "window id". Though there are several functions that >> accept and return these, I can't find anything that defines >> them. >> > > The window identifier is described in windows.txt. I am copying > the description below: Thanks; that's exactly what I was hunting. I've figured out why I couldn't find it in the help. I'd done the following two searches that didn't turn up any hits in windows.txt:: :helpgrep winid :helpgrep window.id I hadn't realized that :helpgrep doesn't pay attention to 'ignorecase', which I've set in my .vimrc. I've since learned from the help on :helpgrep that I should have been using ``\c`` to get case-ignoring behavior like this:: :helpgrep \cwindow.id That finds the sole hit for "window ID" in windows.txt. Thanks again, Michael Henry -- -- 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: Changing the defaults with Vim 8
On 08/20/2016 01:22 PM, Bram Moolenaar wrote: > Hirohito Higashi wrote: >> `set ttimeoutlen=0` will solve the above. >> >> I have invested in above setting more than a year, but the >> trouble does not happen even once. > > Zero only works when you are directly using a terminal. When > using a remote shell it might not work properly. But one > second is indeed too much. > > I have it set to 200, this still has some lag. I think 100 > would work for just about everyone. I ran for a long time without trouble using 50 milliseconds. But even this eventually proved too long once I began using Alt-letter mappings in console Vim. The key sequence for Alt-j is j. I would frequently press to exit insert mode followed quickly by the j key, and Vim would misinterpret the sequence as Alt-j (which would then invoke my insert-mode mapping for Alt-j). I found experimentally that I could set ttimeoutlen to 5 to avoid most instances of this kind of incorrect key interpretation. This value has never proved to be too small in my use. I've never noticed a case of Vim timing out in the middle of a valid multi-key sequence and splitting it incorrectly into multiple keypresses, even when using Vim across an SSH connection; however, these connections were typically done over a local Ethernet, so on a slower network it's possible that such splitting could occur (such that Alt-j might be split erroneously into followed by j). I consider this an unlikely case, since the multi-key sequence will probably be written to the network as a unit and carried in a single network packet, regardless of the speed of the network; still, until we start using uniquely decodable key sequences so we don't have to rely on timeouts, there will always be some risk of incorrect key interpretation. I think 100ms is better than 200ms as a default. I wouldn't suggest a default as low as 5ms due to the possible risk of misinterpreting multi-byte key sequences, even though I've never personally noticed such a failure. Users like myself who require shorter values can always override the default. I'll also note that I've seen 100ms used elsewhere, such as in Tim Pope's "Sensible Defaults" plugin: https://github.com/tpope/vim-sensible/blob/master/plugin/sensible.vim#L28 Michael Henry -- -- 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 8 pre-announcement
On 08/17/2016 01:58 PM, Yegappan Lakshmanan wrote:
> On Wed, Aug 17, 2016 at 4:12 AM, Michael Henry
wrote:
>> I'd like functions that:
>>
>> - Return True if a given window is a QuickFix or Location List
>> window.
>> [...]
>
> The new getwininfo() function can be used to distinguish between
> the quickfix and location list windows. Check the 'quickfix' and the
> 'loclist' keys in the returned dictionary.
> [...]
>
> The getqflist() function returns the window ID of the quickfix window
> (if it is opened). You can check for this.
> [...]
> You can use the getqflist() and getloclist() functions for these.
>
> - Yegappan
Thanks, Yegappan, that's very helpful. I think these extensions
will make things much smoother.
I was trying to find something in the help regarding the meaning
of a "window id". Though there are several functions that
accept and return these, I can't find anything that defines
them.
Perhaps the help could contain a definition of window ID that
answers these questions:
- How does a window ID differ from a window number?
- Since getloclist() accepts either a window number or a window
ID for the first argument, these two number spaces must be
non-overlapping; how does Vim ensure this property?
- Are window IDs unique across tab pages?
- Are window IDs more permanent in some way than window numbers?
For example, if I rearrange the windows in a tab page, do the
window numbers change but the window IDs remain the same?
That empirically seems to be the case when I move the QuickFix
window around within a tab page; is this guaranteed? The
window id empirically changes when closing and reopening the
QuickFix window and when moving the QuickFix window to another
tab; does that mean that the window ID stays the same until
the window is closed?
Also, in the help for getwininfo() (vim 7.4.) is this
sentence:
"""
Without an information about all the windows in all the tab
pages is returned.
"""
Should that start with "Without {winid}, information about..."?
Thanks,
Michael Henry
--
--
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 8 pre-announcement
On 08/17/2016 12:00 AM, Yegappan Lakshmanan wrote:
> I am in particular interested in any comments/suggestions about the
following
> new functions:
>
> getbufinfo()
> gettabinfo()
> getwininfo()
> getqflist()
> setqflist()
> getcompletion()
I've got some custom functions in my .vimrc related to QuickFix
and Location List windows. They are clunky and inefficient
because as far as I can tell, Vim doesn't expose quite enough
information. I've included the functions below for reference.
I haven't been able to track all of the new developments, but
perhaps someone can say whether there is a better way than the
below functions (either with pre-existing or recently added Vim
functionality). I'd like functions that:
- Return True if a given window is a QuickFix or Location List
window. (Both types of window have &buftype == "quickfix".)
- Return True if the QuickFix is window open.
- Return True if the Location List window is open for a given
window.
- Return the window number of the QuickFix window (0 if not
open).
- Return the window number of the associated Location List
for a given window (0 if not open).
When the current window has ``&buftype == "quickfix"``, I'd
originally tried to determine whether it was a QuickFix window
or a Location List using ``getloclist(0)``. I'd wanted to say
``isLocationList = (getloclist(0) > 0)``, but that fails when
it's a Location List that happens to be empty, so I resorted to
the uglier hacks you see below.
I thought I'd seen some activity along these lines that might
expose the details directly, but I haven't been keeping up with
all of the new changes.
Michael Henry
Sample functions for reference
" Return 1 if current window is the QuickFix window.
function! IsQuickFixWin()
if &buftype == "quickfix"
" This is either a QuickFix window or a Location List window.
" Try to open a location list; if this window *is* a location list,
" then this will succeed and the focus will stay on this window.
" If this is a QuickFix window, there will be an exception and the
" focus will stay on this window.
try
noautocmd lopen
catch /E776:/
" This was a QuickFix window.
return 1
endtry
endif
return 0
endfunction
" Return 1 if current window is a Location List window.
function! IsLocListWin()
return (&buftype == "quickfix" && !IsQuickFixWin())
endfunction
" Return window number of QuickFix buffer (or zero if not found).
function! GetQuickFixWinNum()
let qfWinNum = 0
let curWinNum = winnr()
for winNum in range(1, winnr("$"))
execute "noautocmd " . winNum . "wincmd w"
if IsQuickFixWin()
let qfWinNum = winNum
break
endif
endfor
execute "noautocmd " . curWinNum . "wincmd w"
return qfWinNum
endfunction
" Return 1 if the QuickFix window is open.
function! QuickFixWinIsOpen()
return GetQuickFixWinNum() > 0
endfunction
" Return 1 if current window's location list window is open.
function! LocListWinIsOpen()
let curWinNum = winnr()
let numOpenWindows = winnr("$")
" Assume location list window is already open.
let isOpen = 1
try
noautocmd lopen
catch /E776:/
" No location list available; nothing was changed.
let isOpen = 0
endtry
if numOpenWindows != winnr("$")
" We just opened a new location list window. Revert to original
" window and close the newly opened window.
noautocmd wincmd p
noautocmd lclose
let isOpen = 0
endif
return isOpen
endfunction
" Open Quickfix window (if not already open).
function! Copen()
if !QuickFixWinIsOpen()
execute "silent botright copen " . g:QuickFixWinHeight
endif
endfunction
" Open QuickFix window using standard position and height.
command! -bar Copen call Copen()
" Open Location List window (if not already open).
function! Lopen()
if !LocListWinIsOpen()
execute "silent lopen " . g:LocListWinHeight
endif
endfunction
" Open Location List window using standard height.
command! -bar Lopen call Lopen()
--
--
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: Minor getpos() documentation patch
On 11/23/2014 11:25 AM, Bram Moolenaar wrote:
> Michael Henry wrote:
>> - call setpos(''a', save_a_mark
>> + call setpos("'a", save_a_mark
>
> Thanks. Also, a parenthesis is missing.
Ack! I'd intended to put that in as well. Thanks for catching
that :-)
Michael Henry
--
--
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.
Minor getpos() documentation patch
Here is a small patch to the getpos() documentation.
diff -r 8bb4ca7fba40 runtime/doc/eval.txt
--- a/runtime/doc/eval.txt Wed Oct 22 22:09:01 2014 +0200
+++ b/runtime/doc/eval.txt Sun Nov 23 07:48:21 2014 -0500
@@ -3514,7 +3514,7 @@
This can be used to save and restore the position of a
mark: >
let save_a_mark = getpos("'a")
...
- call setpos(''a', save_a_mark
+ call setpos("'a", save_a_mark
< Also see |getcurpos()| and |setpos()|.
Michael Henry
--
--
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.
Documentation patch: :global [cmd] can have a range
Bram, Here is a small documentation patch that indicates the [cmd] associated with the :global command may contain a range. Tim Chase pointed out a couple of pre-existing examples in the documentation, so I've linked to them from :global, which required adding one extra tag in usr_25.txt. diff -r 8bb4ca7fba40 runtime/doc/repeat.txt --- a/runtime/doc/repeat.txtWed Oct 22 22:09:01 2014 +0200 +++ b/runtime/doc/repeat.txtMon Oct 27 07:04:58 2014 -0400 @@ -64,6 +64,8 @@ For the definition of a pattern, see |pattern|. +NOTE [cmd] may contain a range as well; see |collapse| and |edit-paragraph-join|. + The global commands work by first scanning through the [range] lines and marking each line where a match occurs (for a multi-line pattern, only the start of the match matters). diff -r 8bb4ca7fba40 runtime/doc/usr_25.txt --- a/runtime/doc/usr_25.txtWed Oct 22 22:09:01 2014 +0200 +++ b/runtime/doc/usr_25.txtMon Oct 27 07:04:58 2014 -0400 @@ -402,7 +402,7 @@ :map gj -TURNING A PARAGRAPH INTO ONE LINE +TURNING A PARAGRAPH INTO ONE LINE *edit-paragraph-join* If you want to import text into a program like MS-Word, each paragraph should be a single line. If your paragraphs are currently separated with empty Thanks, Michael Henry -- -- 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.
Build failure with Fedora 20 and --enable-perlinterp
ARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 2147483647 == 1) ? 1 : -1]; @@ -11553,7 +11562,7 @@ We can't simply define LARGE_OFF_T to be 9223372036854775807, since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ -#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31)) +#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 2147483647 == 1) ? 1 : -1]; @@ -11577,7 +11586,7 @@ We can't simply define LARGE_OFF_T to be 9223372036854775807, since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ -#define LARGE_OFF_T off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31)) +#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 2147483647 == 1) ? 1 : -1]; Michael Henry -- -- 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] updated breakindent patch
On 05/28/2014 05:30 PM, Christian Brabandt wrote: > It will take some time, until I can work on those items. Probably not > within the next 2 weeks (I'll be on vacation with my kids, so Vim won't > be my priority the next couple of days ;)) Based on the time you must spend on your many patches, it will be a well-deserved vacation :-) Michael Henry -- -- 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: Dear Bram
On 10/28/2013 07:41 AM, Bram Moolenaar wrote:
>
> Michael Henry wrote:
>> So I suggest that a single global option that simply switches on
>> support for extended modifier for all keys, regardless whether
>> those keys are mapped, may well be good enough and might make
>> the implementation simple enough to become reality. The day the
>> option appears in Vim, I'll put it at the top of my .vimrc :-)
>
> So we add an option that breaks mappings? No, not a good plan.
Sorry I was not clear. I certainly wasn't trying to break all
mappings :-) I was thinking of and discussing mostly the :map
functionality of Vim, not (yet) the terminal-handling side, and
talking about behavior for a terminal where the codes for
key and are distinguishable.
Also, I'm not familiar with all the inner workings of Vim, so
the suggestions below might be laughable to those with better
understanding. So I thought I'd try to clarify it some more.
Worst-case, I figure at least you'll get a laugh :-)
Today, users that have both :map and :map will find
that the most recently defined map clobbers the other, because
Vim aliases them even in the definition of the mappings. I'd
like to see Vim eliminate the enforced aliasing at this layer
(the :map layer) for several reasons.
I think new users do not find this aliasing intuitive. There is
no intuitive reason why pressing CTRL-I should be the same thing
as pressing Tab, unless you have a priori knowledge of terminal
history.
If a terminal has a separate Tab key with a key code that is
distinguishable from the key code for CTRL-I, I'd like those
keys to remain distinguishable as Vim processes them. As much
as possible, I'd like each key on my keyboard to be uniquely
recognizable to Vim, so that I get maximum value out of these
keys. Personally, I don't get any benefit from the fact that
the Tab key is just another way of pressing CTRL-I. Though
people have found a way to get some benefit out of this aliasing
that is forced upon us by many current terminals, it seems like
a mis-feature for Vim to force it as well. Users that want two
keys to be aliases can give them identical mappings. But users
that want to treat them separately can't do it as long as Vim
aliases them under the hood.
A terminal that sends identical key codes for different key
presses is not as flexible as one that sends unique codes. We
have to deal with terminals as they exist today, which means we
have to handle hardware aliasing of Tab and CTRL-I (for
example). What if Vim were to handle this in the early stages
of terminal input, by decoding a given key code into a set of
keys aliases specific to the terminal's capabilities? So for
this particular terminal, ASCII code 9 would be translated to
the set {, }. Mappings would match if the mapping's
key is in the set of aliases returned from the terminal layer.
So if the user has mapped only one of and , Vim will
use that mapping. Vim might search mappings in reverse order of
definition so that a more recent mapping will win out in the
event of a tie. That way, a user can control on a per-mapping
basis which alias will win out in a given mapping mode.
I hope that the suggested changes above would be transparent to
most users, but there would be ways that users could detect
things were different (for example, by setting a mapping for
and trying to query that same mapping using ). I
don't see a way to make it 100% transparent without leaving some
vestige of baked-in aliasing, which I feel should ideally be
removed everywhere except in the early terminal-handling stages;
that way, when we get terminals without inherent aliasing, we
can be rid of the aliasing problem entirely.
So the purpose of the option I was proposing was to
control whether Vim would continue to alias certain key
combinations at the point of mapping.
> It's already implemented that a key-with-modifiers that is not
> mapped falls back to the key-without-modifiers. There is no
> reason to make it more complicated for the user who hasn't
> read all the documentation of all options (hint: nobody has).
It's interesting that Vim treats a key-with-modifiers that has
no mapping as that same key without modifiers. I'm not sure I
understand how that works, nor why it's considered desirable. I
especially don't see how having that fall-back makes things less
complicated for users that haven't read the documentation. In
my way of thinking, the intuitive behavior for a keyboard is
that two different keys generally perform two different
behaviors (unless they are labeled the same, such as the two
Enter keys on a typical PC keyboard).
If Vim were changed to distinguish key names like and
throughout most of the code base, and to deal with
terminals that do not have unique key codes by return a set of
aliases for a given key press, I sus
Re: Dear Bram
On Sat, Oct 26, 2013 at 12:50 PM, Bram Moolenaar wrote: > I already said this: It's fine to add so long as it's 100% backwards > compatible. That means encoding keys on top of what's already there, > and falling back to the ordinary key if the key + modifier isn't mapped. This is very encouraging to me. I read this as 100% compatibility out-of-the-box, which is a fine (and longstanding) goal for Vim. I'd be happy to have a Vim option to control this feature. It could default to providing 100% compatible key processing. If the user changes this option, he would get clean support for key modifiers with some slight backward incompatibilities. For example, the aliasing of control keys (e.g., CTRL-I being equivalent to ) is a historical artifact that I suspect has no value to the vast majority of users. If there were no compatibility concern and it's weren't *already* true that CTRL-I aliases , would anyone seriously argue that we ought to *add* that feature to Vim? I suspect not. To me, that's a convincing argument to do the simplest possible kind of backward compatibility, since very few users actually need the old behavior. So I suggest that a single global option that simply switches on support for extended modifier for all keys, regardless whether those keys are mapped, may well be good enough and might make the implementation simple enough to become reality. The day the option appears in Vim, I'll put it at the top of my .vimrc :-) Michael Henry -- -- 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: Dear Bram
On 10/26/2013 04:06 PM, Nikolay Pavlov wrote: > > How to detect the modifiers for many terminals in a portable way, > > without requiring installing an obscure library (at least Ubuntu must > > have it), I don't know. > > I think that vim is popular enough to expect distribution > maintainers to package library once we start using it. With > some lag, greater as this library will likely be optional, but > add. If this is handled similarly to the way Vim deals with other features, a hypothetical extra library would be required only for users that enable the feature. As I routinely rebuild Vim anyway, I'd be delighted to install an extra library or two to gain this feature. Once the feature becomes well-supported and its worth proven, distro maintainers will get requests to enable this feature in Vim, and they'll start packaging any dependent libraries accordingly. But even if they cannot be convinced to support this feature, users like myself will still have the benefits (which are substantial, IMO). Michael Henry -- -- 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: [PATCH] Asynchronous functions (settimeout, setinterval, and cancelinterval)
All, I've been wondering about the use of CTRL-C regarding timers. There has been a lot of discussion on ways to regain control in the face of a runaway timer, which is of course an important consideration. I've been wondering, however, about any negative effects of accidental cancellation. If I understand correctly, when a user presses CTRL-C while a timer happens to be running, that timer will be canceled and not rescheduled. Can this happen accidentally when the user is pressing CTRL-C for other reasons (e.g., to abandon an ex-mode command he was typing)? Since timers might be running at arbitrary times, how can a user be sure it's safe to press CTRL-C without running the risk of canceling a timer by mistake? Should it require multiple CTRL-C presses in a row before aborting current and future timers, or is there some other way to make sure the user won't accidentally cancel timers that are operating properly? Michael Henry -- -- 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: Bug: writing encrypted file, while asked for password, destroys contents
On 08/13/2013 05:47 AM, Ingo Karkat wrote: > On 13-Aug-2013 11:15 +0200, Bram Moolenaar wrote: >> Doing a ":write" on FocusLost is a bad idea. > > This is a common idiom to auto-save, e.g. see > http://vim.wikia.com/wiki/Auto_save_files_when_focus_is_lost > >> Perhaps ":update" would be acceptable, but generally a FocusLost event >> should not do something like this, because it can happen at any time. Reading the tip on the wiki, it's recommending ":wa", not ":write", which is similar to Bram's suggested ":update" in that it writes only modified files. Michael Henry -- -- 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's Ruby version detection breaks on Fedora 19
On 08/04/2013 02:07 PM, Bram Moolenaar wrote: > How about only using the VERSION when the other one is empty? Does this > work for you or generate some error (in src/auto/configure): > > rubyversion=`$vi_cv_path_ruby -r rbconfig -e "print $ruby_rbconfig::CONFIG['ruby_version'].gsub(/\./, '')[0,2]"` > if test "X$rubyversion" = "X"; then > rubyversion=`$vi_cv_path_ruby -e "print ((VERSION rescue RUBY_VERSION)).gsub(/\./, '')[0,2]"` > fi Yes, this works fine for me. It seems like a good work-around to me. Thanks, Michael Henry -- -- 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's Ruby version detection breaks on Fedora 19
On 08/03/2013 08:59 PM, James McCoy wrote: > Notice how the version number here doesn't match the version number in > the previous command? RbConfig::CONFIG['ruby_version'] reports the API > version, while VERSION/RUBY_VERSION report the release version. > > $ ruby --version > ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux] > $ ruby -e 'puts ((VERSION rescue RUBY_VERSION))' > 1.9.3 > $ ruby -r rbconfig -e "puts RbConfig::CONFIG['ruby_version']" > 1.9.1 > > What Vim needs to know is the API version, not the release version. Thanks - that's informative. Would RUBY_VERSION and ruby_version ever differ in their major.minor values? Vim's configure script concatenates the major and minor number to get a single integer (19 or 20 for 1.9.x or 2.0.y), ignoring the third number entirely. If the API and release versions can differ in their major.minor value, then as you say, this patch to use RUBY_VERSION wouldn't work. If there is not another way to query the API version (which I could believe), then it seems that Fedora 19's build of Ruby is broken, since 'ruby_version' is set to an empty string on that platform:: [root@fedora19 ~]# ruby -r rbconfig -e "puts RbConfig::CONFIG['ruby_version']" [root@fedora19 ~]# I'm not very familiar with Ruby, so before I reopen the below Fedora ticket (which the maintainer marked "CLOSED NOTABUG"), would you be able to point me at some official Ruby documentation that requires 'ruby_version' to contain something useful? My searching didn't show anything I could recognize as authoritative. This is the Fedora ticket in question: https://bugzilla.redhat.com/show_bug.cgi?id=923703 The comment from the maintainer is: """ >From Vít Ondruch 2013-03-20 07:10:25 EDT You are right. That is coming into that place due to "--with-ruby-version=''" configuration option. Since you can specify there any arbitrary string (if I am not mistaken) using that option, I don't think you get what you want. I am going to reject this issue. If you disagree then we can consider upstream report. Also, if you provide me with your use case, we might find some better option. """ I don't understand why Vít talks about an "upstream report", since that makes it seems like something the Ruby project itself would need to address; but if Ruby installations are expected to provide an API version for 'ruby_version' and I can point at some documentation that says so, I'll reopen the Fedora ticket. Thanks for any help, Michael Henry -- -- 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.
Vim's Ruby version detection breaks on Fedora 19
All,
On Fedora 19, Vim's configure script no longer correctly detects
the version of Ruby. Vim's current algorithm involves the Ruby
expression ``RbConfig::CONFIG['ruby_version']``, which returns a
string such as "1.9.1" on Fedora 17. On Fedora 19, the above
Ruby expression returns an empty string.
It appears to me that this is due to a change in Fedora. In the
ticket linked below, the maintainer asserts that querying
``ruby_version`` is incorrect, as that variable can have
arbitrary contents:
https://bugzilla.redhat.com/show_bug.cgi?id=923703#c1
Empirically, I can verify that the behavior has changed. On
Fedora 17, the query works:
$ ruby -r rbconfig -e "puts RbConfig::CONFIG['ruby_version']"
1.9.1
On Fedora 19, this same query prints the empty string.
The following patch changes the Ruby version detection algorithm
to check the ``VERSION`` and ``RUBY_VERSION`` variables as used
earlier in Vim's configure script. Essentially, the query
becomes::
$ ruby -e "puts ((VERSION rescue RUBY_VERSION))"
1.9.3
This works on Fedora 19 as well::
$ ruby -e "puts ((VERSION rescue RUBY_VERSION))"
2.0.0
Given that Vim's configure script relies on this same check
to ensure the version is at least "1.6.0", it seems reasonable
to me to use this algorithm (though I'm no Ruby expert).
Here is the patch against Vim 7.4.14:
$ diff -Naur vim-7.4/src/auto/configure{.orig,}
--- vim-7.4/src/auto/configure.orig 2013-08-03 20:00:13.595912341 -0400
+++ vim-7.4/src/auto/configure 2013-08-03 20:02:11.269574272 -0400
@@ -6740,7 +6740,7 @@
if test -d "$rubyhdrdir/$rubyarch"; then
RUBY_CFLAGS="$RUBY_CFLAGS -I$rubyhdrdir/$rubyarch"
fi
-rubyversion=`$vi_cv_path_ruby -r rbconfig -e "print
$ruby_rbconfig::CONFIG['ruby_version'].gsub(/\./, '')[0,2]"`
+rubyversion=`$vi_cv_path_ruby -e "print ((VERSION rescue
RUBY_VERSION)).gsub(/\./, '')[0,2]"`
RUBY_CFLAGS="$RUBY_CFLAGS -DRUBY_VERSION=$rubyversion"
rubylibs=`$vi_cv_path_ruby -r rbconfig -e "print
$ruby_rbconfig::CONFIG['LIBS']"`
if test "X$rubylibs" != "X"; then
Thanks,
Michael Henry
--
--
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: Automatic scrollbar causes column growth
On 02/23/2013 07:16 PM, John Little wrote: > On Sunday, February 24, 2013 2:15:47 AM UTC+13, Michael Henry wrote: > >> Each time the spacebar is pressed, the value of 'columns' will be >> displayed at four points in time. > > My vim 7.3.820 on Kubuntu misbehaves much more than yours. > All I have to do is press the space bar once, then away it > goes, getting wider and wider, a little unsteadily, till it > reaches the width of my display, 237, where it bounces > erratically between 237 and 238. > If I change the map to noremap, or map a key not used in the > mapping, the looping does not occur, and gvim's behaviour > becomes predictable, in that the columns always go up by 1 in > the fourth number. It sounds like you've got a stray space character at the end of the :map command. I can replicate your results if I put a trailing space after the . I should have used :nnoremap instead of :map to avoid this kind of problem. > Now clearly gvim is looping for me with a > recursive map, which shouldn't happen, because :map mappings > don't apply on the command line, :map! ones do. I think this is explained by the fact that Vim goes back to normal mode after executing the ``:call TestColumns()`` part of the mapping. > If I start gvim -u NONE -N, and run :wincmd v then :wincmd o, > the window size doesn't increase. But :wincmd v | windcmd o > increases the width by one. Yes, there is definitely a timing component to this, which is why it fails only some of the time for me. Thanks for the verification. With a timing-dependent problem, it's not always a given that everyone can replicate it. Michael Henry -- -- 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.
Automatic scrollbar causes column growth
All, By default in Gvim, creating or destroying a vertical split causes the left-side scrollbar to automatically be created or destroyed. There appears to be some kind of timing-related bug wherein Gvim is not always able to maintain the value of 'columns' at its original value. To demonstrate this, save the following snippet of VimL as ``scrollbar-column-growth.vim``:: function! TestColumns() let c1=&columns wincmd v let c2=&columns wincmd o let c3=&columns sleep 250m echomsg c1 c2 c3 &columns endfunction map :call TestColumns() Then, invoke Gvim as:: gvim -u NONE '+set nocp | source scrollbar-column-growth.vim' Each time the spacebar is pressed, the value of 'columns' will be displayed at four points in time. The first and last values show the initial and final 'columns' values. The bug doesn't always manifest itself with each keypress, but when the bug occurs, the final 'columns' value will have grown larger than the initial value. Try pressing spacebar multiple times in a row, then looking at the resulting :messages. Here is a sample run:: 80 80 80 80 80 80 80 80 80 80 82 82 82 82 84 84 84 84 86 86 86 86 88 86 86 86 86 86 86 86 86 88 As you can see, sometimes the 'columns' value is always correct, sometimes it goes up and comes back down (e.g., ``86 86 88 86``), and sometimes it goes up permanently. I can work around the problem by removing the default ``L`` in 'guioptions'; the bug manifests only when a scrollbar is setup to appear automatically using ``L`` or ``R``. This test was done on Fedora 17 Linux with a self-compiled Vim with :version output shown after my signature, but this is a problem that have been around for a long time (years, I think, but I've only just now isolated it to a somewhat repeatable test). Thanks, Michael Henry VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Feb 23 2013 07:51:24) Included patches: 1-831 Compiled by v...@drmikehenry.com Huge version with GTK2 GUI. Features included (+) or not (-): +arabic -ebcdic +listcmds+persistent_undo +terminfo +autocmd +emacs_tags +localmap+postscript +termresponse +balloon_eval+eval-lua +printer +textobjects +browse +ex_extra+menu+profile +title ++builtin_terms +extra_search+mksession +python +toolbar +byte_offset +farsi +modify_fname-python3 +user_commands +cindent +file_in_path+mouse +quickfix +vertsplit +clientserver+find_in_path+mouseshape +reltime +virtualedit +clipboard +float +mouse_dec +rightleft +visual +cmdline_compl +folding +mouse_gpm +ruby +visualextra +cmdline_hist-footer -mouse_jsbterm +scrollbind +viminfo +cmdline_info+fork() +mouse_netterm +signs +vreplace +comments+gettext +mouse_sgr +smartindent +wildignore +conceal -hangul_input-mouse_sysmouse -sniff +wildmenu +cryptv +iconv +mouse_urxvt +startuptime +windows +cscope +insert_expand +mouse_xterm +statusline +writebackup +cursorbind +jumplist+multi_byte -sun_workshop+X11 +cursorshape +keymap +multi_lang +syntax -xfontset +dialog_con_gui +langmap -mzscheme+tag_binary +xim +diff+libcall +netbeans_intg +tag_old_static +xsmp_interact +digraphs+linebreak +path_extra -tag_any_white +xterm_clipboard +dnd +lispindent +perl-tcl -xterm_save system vimrc file: "$VIM/vimrc" user vimrc file: "$HOME/.vimrc" user exrc file: "$HOME/.exrc" system gvimrc file: "$VIM/gvimrc" user gvimrc file: "$HOME/.gvimrc" system menu file: "$VIMRUNTIME/menu.vim" fall-back for $VIM: "/usr/local/share/vim" Compilation: 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 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/local/include -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 Linking: gcc -L. -Wl,-z,relro -rdynamic -Wl,-export-dynamic -Wl,--enable-new-dtags -Wl,-rpath,/usr/lib64/perl5/CORE -L/usr/local/lib -Wl,--as-needed -o vim -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lglib-2.0 -lSM -lICE -lXpm -
Re: [patch] new cpo setting to make n/N search in the same direction
On 02/18/2013 08:37 PM, John Beckett wrote: > However, sometimes I take the trouble to scroll everything to > just how it is needed (so some critical portion of code is > visible). Pressing * to search forwards, and then N followed by > another N to go backwards might scroll the window, and that > would be a great distraction. I get around that problem by mapping ``*`` to avoid moving at all; instead, it grabs the word under the cursor and sets the current search term from that. Since I have 'hlsearch' set, all of the matches visible in my window become highlighted without the disruption of scrolling the window. The price I pay for this is the need to press ``n`` (or ``N``) immediately if I want to find the next (or previous) match. I find this a good trade-off, but your mileage may vary. Michael Henry -- -- 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: [patch] new cpo setting to make n/N search in the same direction
> I sometimes map n and N to add zz so the hit is in the middle > line, or for various other things, and while I suppose one could > add workarounds, I repeatedly find myself cursing the confusing > n/N behaviour after using # to search backwards. I've always been confused by the behavior of "n" and "N" after backward searches. The only work-around my brain can handle is to simply avoid backward searches entirely; instead, I search forward and press "N". Michael Henry -- -- 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: Prioritize buffer-local mappings over global ones (with patch)
On 02/17/2013 12:11 PM, Bram Moolenaar wrote: > On 02/15/2013 05:57 PM, Michael Henry wrote: >> If there is anything you'd like me to adjust about either patch >> to make the change suitable for inclusion, please let me know. > > Thanks for the patch. Bug fixes go first, thus it's somewhere down in > the todo list. That's great - thanks! I didn't think to check the TODO list, but I see it's there. I'd thought there might something more I should be doing here, but I certainly agree with fixing bugs before adding features. Michael Henry -- -- 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: Prioritize buffer-local mappings over global ones (with patch)
Bram,
Life's been a bit hectic lately (as I'm sure you'd find familiar
:-)), and I haven't had a chance to follow up regarding the
various options for the idea below. The original patch provided
a Vim option to control the behavior of buffer-local mappings
that have global mappings as prefixes. The modified patch below
removed the idea of a new Vim option.
If there is anything you'd like me to adjust about either patch
to make the change suitable for inclusion, please let me know.
Thanks,
Michael Henry
On 01/30/2013 09:14 AM, Michael Henry wrote:
> On 01/29/2013 04:33 PM, Bram Moolenaar wrote:
>> I do not like the behavior to depend on timing. I would prefer the
>> local mapping to always take precedence, also when another character was
>> already typed that causes a global mapping to match. Otherwise the
>> behavior depends on how busy your computer is, or the remote connection.
>
> Agreed. The patch eliminates the dependence on timing, which I
> see as a good thing, too.
>
>> Even better would be if we do not need an option at all. Every option
>> makes it more difficult for a Vim user to understand what's happening.
>
> Agreed.
>
>> So would it be "the right thing to do" to always let local mappings
>> overrule any matching global mapping? It's a slightly incompatible
>> change though. But the current behavior is bad enough to accept that
>> (you need to type another chacter to stop waiting for the possibility
>> that the global mapping would match).
>
> I'd be in favor of making the behavior non-optional. Here is a
> modification to the patch that removes the option.
>
> Michael Henry
>
> diff -r 274c841f033a runtime/doc/map.txt
> --- a/runtime/doc/map.txt Fri Jan 25 20:11:01 2013 +0100
> +++ b/runtime/doc/map.txt Wed Jan 30 09:13:18 2013 -0500
> @@ -654,6 +654,18 @@
> you type slowly, or your system is slow, reset the 'timeout' option.
> Then you
> might want to set the 'ttimeout' option.
>
> + *map-precedence*
> +Buffer-local mappings (defined using |:map-|) take precedence
over
> +global mappings. When a buffer-local mapping is the same as a global
> mapping,
> +Vim will use the buffer-local mapping. In addition, Vim will use a
> complete
> +buffer-local mapping immediately, even if a longer global mapping has the
> +buffer-local mapping as a prefix. For example, given the following two
> +mappings: >
> + :map \a :echo "Local \a"
> + :map \abc :echo "Global \abc"
> +The buffer-local mapping \a will be used immediately. Vim will not
> +wait for more characters to see if the user might be typing \abc.
> +
> *map-keys-fails*
> There are situations where key codes might not be recognized:
> - Vim can only read part of the key code. Mostly this is only the first
> diff -r 274c841f033a src/getchar.c
> --- a/src/getchar.c Fri Jan 25 20:11:01 2013 +0100
> +++ b/src/getchar.c Wed Jan 30 09:13:18 2013 -0500
> @@ -1912,6 +1912,7 @@
> mapblock_T *mp;
> #ifdef FEAT_LOCALMAP
> mapblock_T *mp2;
> + int expecting_global_mappings;
> #endif
> mapblock_T *mp_match;
> int mp_match_len = 0;
> @@ -2093,6 +2094,7 @@
> /* First try buffer-local mappings. */
> mp = curbuf->b_maphash[MAP_HASH(local_State, c1)];
> mp2 = maphash[MAP_HASH(local_State, c1)];
> + expecting_global_mappings = (mp && mp2);
> if (mp == NULL)
> {
> mp = mp2;
> @@ -2116,6 +2118,20 @@
> #endif
> (mp = mp->m_next))
> {
> +#ifdef FEAT_LOCALMAP
> + if (expecting_global_mappings && mp2 == NULL)
> + {
> + /*
> + * This is the first global mapping. If we've
> + * got a complete buffer-local match, use it.
> + */
> + if (mp_match)
> + {
> + break;
> + }
> + expecting_global_mappings = FALSE;
> + }
> +#endif
> /*
> * Only consider an entry if the first character
> * matches and it is for the current state.
>
--
--
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: Prioritize buffer-local mappings over global ones (with patch)
On 01/29/2013 04:33 PM, Bram Moolenaar wrote:
> I do not like the behavior to depend on timing. I would prefer the
> local mapping to always take precedence, also when another character was
> already typed that causes a global mapping to match. Otherwise the
> behavior depends on how busy your computer is, or the remote connection.
Agreed. The patch eliminates the dependence on timing, which I
see as a good thing, too.
> Even better would be if we do not need an option at all. Every option
> makes it more difficult for a Vim user to understand what's happening.
Agreed.
> So would it be "the right thing to do" to always let local mappings
> overrule any matching global mapping? It's a slightly incompatible
> change though. But the current behavior is bad enough to accept that
> (you need to type another chacter to stop waiting for the possibility
> that the global mapping would match).
I'd be in favor of making the behavior non-optional. Here is a
modification to the patch that removes the option.
Michael Henry
diff -r 274c841f033a runtime/doc/map.txt
--- a/runtime/doc/map.txtFri Jan 25 20:11:01 2013 +0100
+++ b/runtime/doc/map.txtWed Jan 30 09:13:18 2013 -0500
@@ -654,6 +654,18 @@
you type slowly, or your system is slow, reset the 'timeout' option.
Then you
might want to set the 'ttimeout' option.
+*map-precedence*
+Buffer-local mappings (defined using |:map-|) take precedence over
+global mappings. When a buffer-local mapping is the same as a global
mapping,
+Vim will use the buffer-local mapping. In addition, Vim will use a
complete
+buffer-local mapping immediately, even if a longer global mapping has the
+buffer-local mapping as a prefix. For example, given the following two
+mappings: >
+:map \a :echo "Local \a"
+:map \abc :echo "Global \abc"
+The buffer-local mapping \a will be used immediately. Vim will not
+wait for more characters to see if the user might be typing \abc.
+
*map-keys-fails*
There are situations where key codes might not be recognized:
- Vim can only read part of the key code. Mostly this is only the first
diff -r 274c841f033a src/getchar.c
--- a/src/getchar.cFri Jan 25 20:11:01 2013 +0100
+++ b/src/getchar.cWed Jan 30 09:13:18 2013 -0500
@@ -1912,6 +1912,7 @@
mapblock_T*mp;
#ifdef FEAT_LOCALMAP
mapblock_T*mp2;
+intexpecting_global_mappings;
#endif
mapblock_T*mp_match;
intmp_match_len = 0;
@@ -2093,6 +2094,7 @@
/* First try buffer-local mappings. */
mp = curbuf->b_maphash[MAP_HASH(local_State, c1)];
mp2 = maphash[MAP_HASH(local_State, c1)];
+expecting_global_mappings = (mp && mp2);
if (mp == NULL)
{
mp = mp2;
@@ -2116,6 +2118,20 @@
#endif
(mp = mp->m_next))
{
+#ifdef FEAT_LOCALMAP
+if (expecting_global_mappings && mp2 == NULL)
+{
+/*
+ * This is the first global mapping. If we've
+ * got a complete buffer-local match, use it.
+ */
+if (mp_match)
+{
+break;
+}
+expecting_global_mappings = FALSE;
+}
+#endif
/*
* Only consider an entry if the first character
* matches and it is for the current state.
--
--
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.
Prioritize buffer-local mappings over global ones (with patch)
All,
Andy Wokula suggested a solution to the problem that
buffer-local mappings have to wait if they are prefixes of
global mappings. Below is a patch that implements his
suggestion.
A new 'localmaplinger' option is introduced. When set (the
default), Vim behaves in the traditional way. When reset,
complete buffer-local mappings will be accepted immediately
without waiting for incomplete global mappings.
As I'd commented in a previous thread, it's hard to know what
name to choose for this option; improvements to the name are
welcome.
The patch includes documentation along with the minor code
change. I didn't know how to implement a test for this
functionality. If anyone has a suggestion on that front, I'd be
happy to try to implement something.
Michael Henry
diff -r 274c841f033a runtime/doc/map.txt
--- a/runtime/doc/map.txtFri Jan 25 20:11:01 2013 +0100
+++ b/runtime/doc/map.txtTue Jan 29 08:26:29 2013 -0500
@@ -654,6 +654,15 @@
you type slowly, or your system is slow, reset the 'timeout' option.
Then you
might want to set the 'ttimeout' option.
+*map-linger*
+By default, the presence of any incomplete matches will cause Vim to
wait for
+more input, as described above in |map-typing|. This can be undesirable
+when a short buffer-local mapping is a prefix of a longer global mapping,
+since it's likely that the user wants the specialized local mapping to
+be used right away. To cause Vim to accept complete buffer-local mappings
+immediately despite the presence of incomplete global mappings, reset the
+'localmaplinger' option.
+
*map-keys-fails*
There are situations where key codes might not be recognized:
- Vim can only read part of the key code. Mostly this is only the first
diff -r 274c841f033a runtime/doc/options.txt
--- a/runtime/doc/options.txtFri Jan 25 20:11:01 2013 +0100
+++ b/runtime/doc/options.txtTue Jan 29 08:26:29 2013 -0500
@@ -4649,6 +4649,26 @@
Note that using the "-u NONE" and "--noplugin" command line arguments
reset this option. |-u| |--noplugin|
+*'localmaplinger'* *'nolocalmaplinger'*
+'localmaplinger' boolean(default on)
+global
+{not in Vi}
+When 'localmaplinger' is set (the default), Vim gives equal
priority
+to buffer-local and global mappings in the traditional way. As
+explained in |map-typing|, it compares what you type against all
+mapped sequences. If it finds at least one incomplete match,
it will
+get more characters until no more incomplete matches exist,
then use
+the longest complete match it has found (if any).
+
+When 'localmaplinger' is reset, Vim will treat buffer-local
mappings
+as more important than global mappings. When it finds a complete
+match for a buffer-local mapping with no incomplete buffer-local
+matches, it will not wait for any incomplete matches of global
+mappings. This is useful for plugins that make buffer-local
mappings
+which are prefixes of longer global mappings, resulting in forced
+delays of 'timeoutlen' before the incomplete global mapping
times out
+and allows the local mapping to take effect.
+
*'macatsui'* *'nomacatsui'*
'macatsui'boolean(default on)
global
diff -r 274c841f033a src/getchar.c
--- a/src/getchar.cFri Jan 25 20:11:01 2013 +0100
+++ b/src/getchar.cTue Jan 29 08:26:29 2013 -0500
@@ -1912,6 +1912,7 @@
mapblock_T*mp;
#ifdef FEAT_LOCALMAP
mapblock_T*mp2;
+intexpecting_global_mappings;
#endif
mapblock_T*mp_match;
intmp_match_len = 0;
@@ -2093,6 +2094,7 @@
/* First try buffer-local mappings. */
mp = curbuf->b_maphash[MAP_HASH(local_State, c1)];
mp2 = maphash[MAP_HASH(local_State, c1)];
+expecting_global_mappings = (mp && mp2);
if (mp == NULL)
{
mp = mp2;
@@ -2116,6 +2118,22 @@
#endif
(mp = mp->m_next))
{
+#ifdef FEAT_LOCALMAP
+if (expecting_global_mappings && mp2 == NULL)
+{
+/*
+ * This is the first global mapping. If we've
+ * got a complete buffer-local match and we
+ * shouldn't linger for a longer global match,
+ * use the current match.
+ */
+if (mp_match && !p_lmlinger)
+{
+break;
+}
+expecting_global_mappings = FALSE;
+}
+#endif
/*
* Only consider an entry if
:sandbox setlocal appears to be disallowed
All, The :sandbox command seems to disallow the use of :setlocal, even though it permits changing buffer-local options via :set. For example, this works fine: vim -u NONE '+set nocp | sandbox set ts=16' But this fails: vim -u NONE '+set nocp | sandbox setlocal ts=16' It generate the following error message: Error detected while processing command line: E48: Not allowed in sandbox: sandbox setlocal ts=16 I was expecting :setlocal would work with :sandbox; should it? Thanks, Michael Henry -- 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: Patch 7.2.361
On 02/18/2010 09:53 AM, Bram Moolenaar wrote:
>
> James Vega wrote:
>>> diff -Naur vim72.360.rubypatch/src/if_ruby.c vim72.361/src/if_ruby.c
>>> --- vim72.360.rubypatch/src/if_ruby.c2010-02-18
06:48:21.0 -0500
>>> +++ vim72.361/src/if_ruby.c2010-02-18 06:44:32.0 -0500
>>> @@ -864,7 +869,10 @@
>>> longn = NUM2LONG(num);
>>> aco_save_Taco;
>>>
>>> -if (n >= 0 && n <= buf->b_ml.ml_line_count && line != NULL)
>>> +if (line != NULL) {
>>
>> This condition should have been changed to "line == NULL" when it was
>> made its own, standalone check.
>
> Ah, good catch. I'll send out a patch.
>
> Would be nice to have a test for the basic Ruby stuff, so that things
> like this are caught early.
Thanks - that fixed it. I now get the same behavior as with
Masaki's patch. On 32-bit Fedora 11 with ruby 1.8.6, things are
fine. On 64-bit Arch Linux with ruby 1.9.1p378, there odd error
message is still there for the LustyExplorer plugin. I suspect
that's a problem with the plugin and ruby 1.9, but I'll look
into that separately and submit a bug report to the plugin
author.
Thanks for the prompt patches :-)
Michael Henry
--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Re: Patch 7.2.361
On 02/17/2010 10:23 AM, Bram Moolenaar wrote:
>
> Patch 7.2.361
> Problem:Ruby 1.9 is not supported.
> Solution: Add Ruby 1.9 support. (Msaki Suketa)
> Files:src/Makefile, src/auto/configure, src/configure.in,
src/if_ruby.c
Bram,
Something about this patch isn't quite right, though I don't
yet know what. It differs in a number of ways from Masaki Suketa's
patch (note typo "Msaki" in Solution: line above). I can build 7.2.360
with Masaki's patch and it still works for me on Fedora 11. I haven't
yet gotten to try it on Arch with Ruby 1.9.
I can build 7.2.361, but it's giving me odd errors in the Ruby-based
plugin I'm using:
IndexError: (eval):1063:in `append': NULL line
(This is the LustyExplorer plugin.)
I've attached a diff between 7.2.360 with Masaki's original
patch and 7.2.361, in case that helps point out the difference
that's causing the trouble.
Thanks,
Michael Henry
diff -Naur vim72.360.rubypatch/src/auto/configure
vim72.361/src/auto/configure
--- vim72.360.rubypatch/src/auto/configure2010-02-18
06:48:21.0 -0500
+++ vim72.361/src/auto/configure2010-02-18 06:44:32.0 -0500
@@ -793,6 +793,7 @@
enable_tclinterp
with_tclsh
enable_rubyinterp
+with_ruby_command
enable_cscope
enable_workshop
enable_netbeans
@@ -1503,6 +1504,7 @@
--with-plthome=PLTHOME Use PLTHOME.
--with-python-config-dir=PATH Python's config directory
--with-tclsh=PATH which tclsh to use (default: tclsh8.0)
+ --with-ruby-command=RUBY name of the Ruby command (default: ruby)
--with-xuse the X Window System
--with-gtk-prefix=PFX Prefix where GTK is installed (optional)
--with-gtk-exec-prefix=PFX Exec prefix where GTK is installed (optional)
@@ -5703,9 +5705,21 @@
{ $as_echo "$as_me:$LINENO: result: $enable_rubyinterp" >&5
$as_echo "$enable_rubyinterp" >&6; }
if test "$enable_rubyinterp" = "yes"; then
+ { $as_echo "$as_me:$LINENO: checking --with-ruby-command argument" >&5
+$as_echo_n "checking --with-ruby-command argument... " >&6; }
- # Extract the first word of "ruby", so it can be a program name with
args.
-set dummy ruby; ac_word=$2
+# Check whether --with-ruby-command was given.
+if test "${with_ruby_command+set}" = set; then
+ withval=$with_ruby_command; RUBY_CMD="$withval"; { $as_echo
"$as_me:$LINENO: result: $RUBY_CMD" >&5
+$as_echo "$RUBY_CMD" >&6; }
+else
+ RUBY_CMD="ruby"; { $as_echo "$as_me:$LINENO: result: defaulting to
$RUBY_CMD" >&5
+$as_echo "defaulting to $RUBY_CMD" >&6; }
+fi
+
+
+ # Extract the first word of "$RUBY_CMD", so it can be a program name
with args.
+set dummy $RUBY_CMD; ac_word=$2
{ $as_echo "$as_me:$LINENO: checking for $ac_word" >&5
$as_echo_n "checking for $ac_word... " >&6; }
if test "${ac_cv_path_vi_cv_path_ruby+set}" = set; then
@@ -5799,8 +5813,8 @@
_ACEOF
else
-{ $as_echo "$as_me:$LINENO: result: not found" >&5
-$as_echo "not found" >&6; }
+{ $as_echo "$as_me:$LINENO: result: not found; disabling Ruby" >&5
+$as_echo "not found; disabling Ruby" >&6; }
fi
else
{ $as_echo "$as_me:$LINENO: result: too old; need Ruby version
1.6.0 or later" >&5
diff -Naur vim72.360.rubypatch/src/configure.in vim72.361/src/configure.in
--- vim72.360.rubypatch/src/configure.in2010-02-18
06:48:21.0 -0500
+++ vim72.361/src/configure.in2010-02-18 06:44:32.0 -0500
@@ -949,8 +949,12 @@
[enable_rubyinterp="no"])
AC_MSG_RESULT($enable_rubyinterp)
if test "$enable_rubyinterp" = "yes"; then
+ AC_MSG_CHECKING(--with-ruby-command argument)
+ AC_ARG_WITH(ruby-command, [ --with-ruby-command=RUBY name of the
Ruby command (default: ruby)],
+RUBY_CMD="$withval"; AC_MSG_RESULT($RUBY_CMD),
+RUBY_CMD="ruby"; AC_MSG_RESULT(defaulting to $RUBY_CMD))
AC_SUBST(vi_cv_path_ruby)
- AC_PATH_PROG(vi_cv_path_ruby, ruby)
+ AC_PATH_PROG(vi_cv_path_ruby, $RUBY_CMD)
if test "X$vi_cv_path_ruby" != "X"; then
AC_MSG_CHECKING(Ruby version)
if $vi_cv_path_ruby -e '(VERSION rescue RUBY_VERSION) >= "1.6.0" or
exit 1' >/dev/null 2>/dev/null; then
@@ -1003,7 +1007,7 @@
RUBY_PRO="if_ruby.pro"
AC_DEFINE(FEAT_RUBY)
else
-AC_MSG_RESULT(not found, disabling Ruby)
+AC_MSG_RESULT(not found; disabling Ruby)
fi
else
AC_MSG_RESULT(too old; need Ruby version 1.6.0 or later)
diff -Naur vim72.360.rubypatch/src/if_ruby.c vim72.361/src/if_ruby.c
--- vim72.360.rubypatch/src/if_ruby.c2010-02-18 06:48:21.0
Ruby 1.9 compatibility status
All, Vim does not currently support integration with Ruby 1.9, but it's on the list (see :help todo). Masaki Suketa supplied a patch[1] to the vim_dev mailing list in July 2009, under the subject line "Patch for Vim with Ruby 1.9". Using this patch, I'm able to build Vim with support for Ruby 1.9 (on Arch Linux), as well as Ruby 1.8 (on Fedora 12 Linux). The Ruby-based plugins I use (LustyExplorer[2] and LustyJuggler[3]) work fine Ruby 1.8 and Masaki's patch. With Ruby 1.9, LustyExplorer is throwing an exception[4], but I think it's a problem with the plugin and the changing Ruby language definition, not a problem with integrating Ruby into Vim. Until Ruby 1.9 is supported in Vim, it will be more difficult for plugin authors to try Ruby 1.9 and fix any problems. Arch Linux uses Ruby-1.9, so the Arch packager for Vim has disabled Ruby integration[5] pending a Vim patch that works with Ruby 1.9. This leave Arch users somewhat out in the cold for Ruby integration. Is Masaki's patch ready to be incorporated, or is more testing required? Masaki had done testing with multiple versions of Ruby, including 1.8.7, 1.9.1, and 1.9.2dev. It's working for me with Ruby 1.8 on Fedora, so it looks harmless for Ruby 1.8 users, while allowing Ruby 1.9 users a chance to more widely exercise Ruby-based plugins and shake out compatibility bugs. Thanks, Michael Henry [1]: http://groups.google.com/group/vim_dev/browse_thread/thread/699c65598bc6348b/e5c0a53a8a26624e?lnk=raot&pli=1 [2]: http://www.vim.org/scripts/script.php?script_id=1890 [3]: http://www.vim.org/scripts/script.php?script_id=2050 [4]: The exception looks like this: type mismatch: Fixnum given (eval):118:in `index' (eval):118:in `block in buildScoreArray' (eval):117:in `each_byte' (eval):117:in `buildScoreArray' (eval):103:in `score' (eval):326:in `block in matching_entries' (eval):325:in `select' (eval):325:in `matching_entries' (eval):312:in `compute_ordered_matching_entries' (eval):246:in `refresh' (eval):222:in `key_pressed' (eval):560:in `block in key_pressed' (eval):492:in `time' (eval):531:in `key_pressed' (eval):1:in `' [5]: http://bugs.archlinux.org/task/16710 -- You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php
Re: Patch 7.2.315
On 12/02/2009 11:59 AM, Bram Moolenaar wrote: > Patch 7.2.315 > Problem:Python libs can't be found on 64 bit system. > Solution: Add lib64 to the list of directories. (Michael Henry) > Files:src/auto/configure, src/configure.in > Thanks, Bram, I can confirm that this patch works for me. Michael Henry -- You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php
Re: Feature request: Add a Diff option upon open when "Found a swap file..."
Ben Schmidt wrote: > >> 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: > > http://vim.wikia.com/wiki/Swap_file_%22...%22already_exists!_-_so_diff_it > > And the 'Comment' at the end of the tip, IMHO, is the most useful part. Yes, indeed. Until this thread, I hadn't really understood all of the options presented to the user when an old swapfile is detected, so I hadn't thought to try the useful :DiffOrig user-defined command that the help recommends under :help :DiffOrig. That makes things much smoother. When I first started using Vim and got the 'Swap file exists' message, I found it very hard to understand the difference between the options presented. Several things were unclear to me: - If a previous Vim session crashed, did I lose any unsaved changes? How can I check? - Why is recovery optional? Wouldn't Vim just know how to pickup where it left off? - Why is cleanup of dead swapfiles a manual step? Can't Vim figure that out? - What gets opened when I choose "Open Read Only" - the swapfile or the real file? What can I do with the read-only version once I open it? - What happens if I Edit Anyway? Do I have a swapfile? Is that swapfile shared with another instance of Vim (which sounds bad)? How can I tell if I'm colliding with another live Vim instance instead of an old crashed one? - How does Quit differ from Abort? Questions like these make it very hard to know how to proceed. I would have been comforted to see "Help" among the listed options. The message does suggest :help recovery, which has lots of good explanation about the options, but the user has to decide something before he can read that help. Perhaps a little more direct guidance would be helpful, such as "To understand the options below, please read :help recovery, either by starting a new instance of Vim or by choosing Abort below and restarting Vim without trying to open any files". > Here's what I usually do. When I'm confronted with the 'Swap file > exists' message, I choose 'Recover' and then immediately issue > :DiffOrig (:help :DiffOrig). Once I've considered the changes, I > either (1) close the Scratch buffer that is the original file, to keep > the recovered file, and delete the old swap file, or (2) I edit the > file again and choose 'Delete' when confronted with the 'Swap file > exists' message. Ben's suggestion above would be a welcome addition to the text of :help recovery as an alternative to making a temporary file. > Now, perhaps a good solution is to have (1) a 'Recover and diff' > option that basically does 'Recover' and :DiffOrig in one step and (2) > a :KeepThis command that you can run in the buffer you're interested > in keeping, that writes the buffer you're editing to disk (you may > have even edited it, e.g. to incorporate *some* changes from a > recovered version), deletes all the stale swap files, closes any other > buffers that were editing that file (to avoid 'Buffer already editing > that file' issues, etc.), and re-edits the file so that its current > swap file is .swp not .swo and thus easily recoverable in future. These options seem very friendly to me. Michael Henry --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: c/c++ comment highlighting bug with "syntax on"
cadabras wrote: > > If I'm understanding you correctly, your workplace will permit you to > > submit some of your source code here as long as you have properly > > "sanitized" it to remove confidential information. For example, the > > phrase "My Company Name" would become "AA AAA ". > > Yes, you are, but I did not replace only strings like "My Company > Name", but also strings like > "class MyClass : public MyMotherClass" with > "A AAA : AA A" Understood. > My file is large and I cannot reduce it very much because the problem > occurs only with files with big c/c++ comments. Some problems are like that :-( > I obviously can submit a good description to reproduce the problem. > > I could submit the file using rapidshare.de. Do you agree? That sounds like a reasonable thing to me. I'm unfortunately not expert in the area of syntax highlighting, so I expect to remain silent when your question shows up. But there are a number of helpful experts on this mailing list, so if you make your code available in a relatively easy to access manner (no login required, etc.) and someone recognizes what's going on, they will probably try to help you. Hope this helps, Michael Henry --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: c/c++ comment highlighting bug with "syntax on"
cadabras wrote: > I was at work last week and I was programming. > I found a bug in c/c++ comment highlighting with "syntax on". > I replaced all [[:alnum:]] characters with "A" character. In this way > I can submit it to this group. > If I'm understanding you correctly, your workplace will permit you to submit some of your source code here as long as you have properly "sanitized" it to remove confidential information. For example, the phrase "My Company Name" would become "AA AAA ". > How can I submit my "c/c++ like" file to show the bug? > In short, just submit your sample of mis-behaving C/C++ as an email to the list. In case you were asking for more detail on the process, I'd recommend the following. It's best to reduce the size of your source code to the smallest possible example that demonstrates the bug. That makes it much easier on the volunteers on the list (and correspondingly more likely that you'll get help with your problem). Since you've indicated it's a problem with comment highlighting, you might be able to post a single C/C++ comment that shows the problem. Then, after shrinking the example as much as possible, email your example to the list (simply paste the example code directly into the email). Please include a good description of what you think is wrong. For example, instead of saying "this doesn't highlight properly", you might say "the third word comes out blue, but it should be yellow". You may have already seen this, but I've found the following document interesting and helpful for posting questions on mailing lists: http://www.catb.org/~esr/faqs/smart-questions.html Hope this helps, Michael Henry --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug: :echo output missing with QuickFix and Command-line windows
Bram Moolenaar wrote: > Michael Henry wrote: > > >> It appears that the output from :echo and :echomsg does not >> show up properly when used from the Command-line window >> while a QuickFix window is open. >> [...] > If you use: > :echo "hello\nthere" > > You get the hit-enter prompt before redrawing te display. So it's > indeed that closing the command-line window causes a redraw and that > clears the message. > > Forcing the hit-enter prompt would be a solution, but at the same time > may annoy quite a few users. > Yes, that would be annoying :-) > I'll make a remark in the todo list if it's possible to redraw without > erasing the message. Don't expect this soon though. > Intuitively, I'd imagined that forcing a redraw when the command-line window closes but before the command is executed might fix the problem. I poked around a little bit this morning and made the following two-line patch against Vim 7.2.25: --- vim72/src/ex_getln.c.orig 2008-11-02 07:34:57.0 -0500 +++ vim72/src/ex_getln.c2008-11-02 07:30:20.0 -0500 @@ -6247,6 +6247,8 @@ setmouse(); # endif +update_screen(0); +out_flush(); return cmdwin_result; } #endif /* FEAT_CMDWIN */ This fixes the symptoms I'm seeing, though I really have no idea how wrong-headed this approach might be. I just stepped through the code to see how re-drawing gets triggered, then added these calls to update_screen(0) and out_flush() at the end of the ex_window() function. I didn't study how the code works in-depth, so the patch may well have some subtle problem related to the details of Vim's implementation. At a higher level, however, I think it's a reasonable trade-off to force an "extra" screen redraw when exiting the command-line window. It has the right feel to me to pop up a temporary editing window for command-line history, grab a new command to execute, close the temporary window, and tidy up by re-drawing everything, leaving no trace that the user didn't just type the command at the ex prompt. Does this fix seem reasonable, perhaps with some tweaking? Thanks, Michael Henry --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Bug: :echo output missing with QuickFix and Command-line windows
All,
It appears that the output from :echo and :echomsg does not
show up properly when used from the Command-line window
while a QuickFix window is open.
Steps to reproduce:
- Startup Vim clean:
vim -u NONE -N
- Test regular :echo command:
:echo "Hello"
This works properly.
- Open command-line window:
q:
- Cursor up to :echo "Hello", press Enter to execute.
This works properly.
- Open the QuickFix window:
:copen
- Re-open the Command-line window:
q:
- Cursor up to :echo "Hello", press Enter to execute.
The expected output ("Hello") does not show up (or perhaps
more likely, shows up but is subsequently erased, as my
testing with :redir shows that "Hello" is actually written).
Tested Configuration: Vim 7.2, patches 1-25, compiled on Linux.
:version output follows.
Michael Henry
--
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Oct 19 2008 19:56:42)
Included patches: 1-25
Compiled by [EMAIL PROTECTED]
Huge version with GTK2 GUI. Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info
+comments
+cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic
+emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path
+float +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand
+jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds
+localmap
+menu +mksession +modify_fname +mouse +mouseshape +mouse_dec +mouse_gpm
-mouse_jsbterm +mouse_netterm -mouse_sysmouse +mouse_xterm +multi_byte
+multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra +perl
+postscript
+printer +profile +python +quickfix +reltime +rightleft +ruby +scrollbind
+signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary
+tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects
+title
+toolbar +user_commands +vertsplit +virtualedit +visual +visualextra
+viminfo
+vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim
+xsmp_interact +xterm_clipboard -xterm_save
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/usr/local/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/freetype2
-I/usr/include/libpng12 -I/usr/include/pixman-1 -g -O2
-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/lib/perl/5.8/CORE -I/usr/include/python2.5 -pthread
-I/usr/lib/ruby/1.8/i486-linux
Linking: gcc -L. -Wl,-Bsymbolic-functions -rdynamic
-Wl,-export-dynamic -Wl,-E -L/usr/local/lib -o vim -lgtk-x11-2.0
-lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0
-lcairo -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lXt -lncurses -lgpm
-Wl,-E -L/usr/local/lib /usr/lib/perl/5.8/auto/DynaLoader/DynaLoader.a
-L/usr/lib/perl/5.8/CORE -lperl -L/usr/lib/python2.5/config -lpython2.5
-lutil -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions
-lruby1.8 -lm
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Proposal: "Modes" for Vim
[EMAIL PROTECTED] wrote: > Hello, > > krischik <[EMAIL PROTECTED]> wrote: > >> On Aug 30, 2:46 pm, [EMAIL PROTECTED] wrote: >>> PS: As "mode" already means something in Vim context, I do not really >>> like this new use of the term. >> Got an alternative name? > > I wish I had :-( > It would be something with "filetype" I guess. The TextMate editor on OS X uses the term "bundle" for this kind of thing. Apple defines a bundle[1] as "a directory in the file system that contains executable code and related resources". I don't know if it would be confusing to OS X developers to reuse the term "bundle" for your proposed "Mode" concept in Vim; but then again, Mac users are in the minority (especially Mac developers). Other possibilities, in no particular order: - filetype kit - filetype package - filetype pack - filetype suite I've been using the following sentence in my head to see how these sound: "Download and install the ADA (blank)." Michael Henry [1]: See "Bundles" section on this page: http://developer.apple.com/documentation/Porting/Conceptual/win32porting/Articles/intern.html --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Small typo in patch 7.1.088 (extra)
All,
The MoveWindow() and MoveWindowStructure() functions take slightly
different parameters. The final TRUE argument in the original
MoveWindow() call[1] is for the formal parameter "front" which controls
whether the window should become the frontmost window. Unfortunately,
MoveWindowStructure() doesn't have the "front" parameter[2]. Patch
7.1.088 does not build on OS X with the extraneous TRUE argument to
MoveWindowStructure.
The function invocation should be:
MoveWindowStructure(gui.VimWindow, x, y);
(simply remove the final TRUE argument)
Michael Henry
[1]: http://developer.apple.com/documentation/mac/Toolbox/Toolbox-246.html
[2]:
http://tuvix.apple.com/documentation/macos8/HumanInterfaceToolbox/WindowManager/ProgWMacOS8.5WindowMgr/WindowMgr.42.html
Bram Moolenaar wrote:
>
> Patch 7.1.088 (extra)
> Problem:The coordinates used by ":winpos" differ from what getwinposx()
> and getwinposy() return.
> Solution: Use MoveWindowStructure() instead of MoveWindow(). (Michael Henry)
> Files:src/gui_mac.c
>
>
> *** ../vim-7.1.087/src/gui_mac.c Tue Jun 19 16:33:53 2007
> --- src/gui_mac.c Wed Aug 29 20:33:34 2007
> ***
> *** 3149,3155
> /* TODO: Should make sure the window is move within range
>*e.g.: y > ~16 [Menu bar], x > 0, x < screen width
>*/
> ! MoveWindow(gui.VimWindow, x, y, TRUE);
> }
>
> void
> --- 3149,3155
> /* TODO: Should make sure the window is move within range
>*e.g.: y > ~16 [Menu bar], x > 0, x < screen width
>*/
> ! MoveWindowStructure(gui.VimWindow, x, y, TRUE);
> }
>
> void
> ***
> *** 5556,5562
>* SetDialogTracksCursor() : Get the I-beam cursor over input box
>* MoveDialogItem():Probably better than SetDialogItem
>* SizeDialogItem():(but is it Carbon Only?)
> ! * AutoSizeDialog():Magic resize of dialog based on text lenght
>*/
> }
> #endif /* FEAT_DIALOG_GUI */
> --- 5556,5562
>* SetDialogTracksCursor() : Get the I-beam cursor over input box
>* MoveDialogItem():Probably better than SetDialogItem
>* SizeDialogItem():(but is it Carbon Only?)
> ! * AutoSizeDialog():Magic resize of dialog based on text length
>*/
> }
> #endif /* FEAT_DIALOG_GUI */
> *** ../vim-7.1.087/src/version.c Tue Aug 21 18:02:58 2007
> --- src/version.c Thu Aug 30 10:32:28 2007
> ***
> *** 668,669
> --- 668,671
> { /* Add new patch number below this line */
> + /**/
> + 88,
> /**/
>
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Minor fix to a.vim plugin documentation
Charles E Campbell Jr wrote: > Michael Henry wrote: > >> The a.vim (alternate) plugin's[1] documentation file begins with a blank >> line, preventing it from showing up in the local-additions (:help >> local-additions) section of Vim's help system[2]. Simply removing the >> line corrects this minor problem. >> >> > Changes to plugins should be addressed to their maintainers (usually > their authors). Generally the > authors have placed their email addresses in the script file itself and > sometimes in the associated help file. > > After all, Mike Sharpe may not even read this forum. > > Regards, > Chip Campbell (Rats - I replied but forgot to use my subscribed email address. Trying again...) You're right - I should have looked for an email address for the author. I've included him on this reply. Thanks, Michael Henry --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Minor fix to a.vim plugin documentation
All, The a.vim (alternate) plugin's[1] documentation file begins with a blank line, preventing it from showing up in the local-additions (:help local-additions) section of Vim's help system[2]. Simply removing the line corrects this minor problem. Michael Henry [1]: http://www.vim.org/scripts/script.php?script_id=31 [2]: See :help write-local-help for details --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Patch for mac-specific bug in :winpos
All, The mac port of gvim has a bug in the implementation of :winpos. Version: 7.1.82 (mac only) Symptom: The following command, which should do nothing, causes gvim's window to move up the screen on the mac: exe "winpos " . getwinposx() . " " . getwinpoxy() On Linux and Windows, the above command correctly does nothing[1]. The problem stems from a mis-matched pair of function calls in src/gui_mac.c. Vim implements the getwinposx() and getwinposy() functions in terms of a port-specific function gui_mch_get_winpos(). In gui_mac.c, this function makes this call[2]: GetWindowBounds(gui.VimWindow, kWindowStructureRgn, &bounds); The constant kWindowStructureRegion requests coordinates relative to the outer bounds of the window. The implementation of `:winpos x y` calls the port-specific function gui_mch_set_winpos(). In gui_mac.c, this function make this call[3]: MoveWindow(gui.VimWindow, x, y, TRUE); The coordinates of MoveWindow() are relative to the content area inside the window; this content area is shifted down a distance equal to the height of the title bar. The mis-match between the two system calls results in a vertical shift of the window in the example given above. The attached patch fixes this problem by using the MoveWindowStructure() function[4], whose coordinates are compatible with those used for the GetWindowBounds() function. Michael Henry [1]: For the curious non-mac user: The bug may be simulated on a correctly operating gvim using this command: exe "winpos " . getwinposx() . " " . (getwinpoxy() - 22) [2]: http://tuvix.apple.com/documentation/macos8/HumanInterfaceToolbox/WindowManager/ProgWMacOS8.5WindowMgr/WindowMgr.41.html [3]: http://developer.apple.com/documentation/mac/Toolbox/Toolbox-246.html [4]: http://tuvix.apple.com/documentation/macos8/HumanInterfaceToolbox/WindowManager/ProgWMacOS8.5WindowMgr/WindowMgr.42.html begin patch --- src/gui_mac.c.orig 2007-08-18 17:24:21.0 -0400 +++ src/gui_mac.c 2007-08-18 17:56:07.0 -0400 @@ -3149,7 +3149,7 @@ /* TODO: Should make sure the window is move within range * e.g.: y > ~16 [Menu bar], x > 0, x < screen width */ -MoveWindow(gui.VimWindow, x, y, TRUE); +MoveWindowStructure(gui.VimWindow, x, y); } void --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
grep.vim portability problem with Mac OS-X xargs
All, I just upgraded to version 1.8 of Yegappan Lakshmanan's convenient grep.vim[1] plugin. As part of the fix in version 1.8 for handling spaces in file and path names, the `--null` switch was added to xargs. Unfortunately, the OS X version of xargs doesn't support the long spelling of this argument, though it does support the short spelling, `-0`. Could the grep.vim script be modified to use `-0` instead of `--null`? I believe the `-0` option is more portable than the `--null` option, though it doesn't seem to be universally available[2]. It is available on OS X and systems with GNU xargs (Linux, *BSD, ...), but a quick Google search indicates that it's not fully portable. For example, Tom's Hardware page shows a comparison of xargs options across many operating systems[2]. Support for `-0` is missing on AIX and Solaris. The Open Group web page[3] doesn't mention the `-0` flag. Given that the `-0` option for xargs is not universal (nor, for that matter, is the `-print0` option for find), perhaps the grep.vim script could offer a variable to configure the use of the `-print0`/`-0` combination. As the script stands, users can work around the issue by disabling the use of xargs entirely (via the Grep_Find_Use_Xargs variable) but this comes at a performance penalty. Thanks, Michael Henry [1]: http://www.vim.org/scripts/script.php?script_id=311 [2]: http://www.tomshardware.com/ucg/commands/xargs-15408.html [3]: http://www.opengroup.org/onlinepubs/95399/utilities/xargs.html --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
