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.v
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 you
egers 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
t; 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 mor
: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 &
rge 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:
ht
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 w
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));
Th
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 th
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
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()
ion 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
=
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 in
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 |getcur
d
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/maillis
? 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
n 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
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
>
r.
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 a
pendent
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
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 receive
;
>> 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 sug
27;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 li
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 Fedo
LAGS="$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
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
blem 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 versi
ed 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_
he 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
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
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:
>
or 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
+
ation 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:0
27;
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" mailli
arly.
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
ase 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-
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/699c65598bc
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 con
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
-~--~~~~--~~--~--~---
ively
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
-~--~~~~--~~--~--~---
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-quest
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 &
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 -
er:
- 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.app
ortunately,
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)
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]. Sim
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://w
rtical 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
s 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:
49 matches
Mail list logo
