Bram Moolenaar wrote:
Tony Mechelynck wrote:
On 04/06/08 21:40, Ilya Bobir wrote:
[...]
If there are no scripts that use two numbers with a dot in between
without interleaving spaces then it follows that there are none that
have these kind of numbers with an exponent appended. And it
Ben Schmidt wrote:
When would you need Float - Int? You can actually use
printf(.0f, float), and rely on automatic String to Int conversion,
but it's clumsy.
Float - Int can be very handy, using floats as intermediate
calculations in scripts and then converting to ints for some kind
Gary Johnson wrote:
On 2008-06-10, Ben Schmidt [EMAIL PROTECTED] wrote:
Out of curiosity, why the preference for a few functions with
parameters, e.g.,
To be honest, I probably prefer the 'many functions' approach. I was
just thinking in terms of not cluttering the Vim function namespace
John Beckett wrote:
Ben Schmidt wrote:
math('sqrt',argument)
math('exp',exponent[,base=e])
math('log',argument[,base=e])
math('sin',argument[,degrees (bool)=0])
math('cos',argument[,degrees (bool)=0])
math('tan',argument[,degrees (bool)=0])
math('atan',argument[,degrees (bool)=0
Bram Moolenaar wrote:
Ben Schmidt wrote:
When would you need Float - Int? You can actually use
printf(.0f, float), and rely on automatic String to Int conversion,
but it's clumsy.
Float - Int can be very handy, using floats as intermediate
calculations in scripts and then converting
Hi, Bram,
The attached one-line patch alters the behaviour of retrieving the 'key'
option.
Rather than always returning * it returns the empty string if 'key' is
empty. While still protecting any key that is used, this is useful to be able
to
determine whether or not a file is encrypted,
Kana Natsuno wrote:
On Tue, 17 Jun 2008 03:49:19 +0900, Bram Moolenaar wrote:
The current version of this file doesn't set 'encoding' at all.
Should work fine.
Really? I checked with the following steps and environment, it
does set 'encoding' to latin1.
$ vim -u NONE -U NONE --noplugin
Can you tell me exactly in which script (of which date) you find that
misbehaving menu statement (use :verbose menu followed by the menu
name to see where it was set), so I can check the mod-date mentioned at
the top of that script on my system?
It's a third party plugin, Tony (the HTML
(From your previous post I found out that e.g. gui_mch_draw_string()
will pass strings in the encoding specified by 'enc', thus I can look
at output_conv to determine if I need to convert the string to utf-8
before drawing it. However, I cannot use the same method to decide if
conversion is
Tony Mechelynck wrote:
On 20/06/08 02:02, Ben Schmidt wrote:
Can you tell me exactly in which script (of which date) you find that
misbehaving menu statement (use :verbose menu followed by the menu
name to see where it was set), so I can check the mod-date mentioned at
the top of that script
With a small amount of testing, it's looking good, Bram. Tests says ALL
DONE which I presume means they all passed.
A few points:
- Wouldn't float2nr() be more consistent with the other Vim functions
than float2number()? O yes! So much so that it seems that's what you
implemented it as.
Bram Moolenaar wrote:
Patrick Texier wrote:
On Fri, 20 Jun 2008 14:29:07 +0200, Vladimir Marek wrote:
I don't have the previous post.
As a workaround in eval.c you can simply replace
rettv-vval.v_float = round(f);
with
rettv-vval.v_float = ceil(f + 0.5);
Yes.
I think it's:
You are apparently looking at slightly outdated runtime files. I'll
push the current version now, so that they match with the latest
floating point patch.
Yep. They look better now. Two suggestions for improvement:
- An example of pow() with floats would be good. E.g. pow(32,0.20)=2.0
Bill McCarthy wrote:
On Fri 20-Jun-08 3:08pm -0600, Bram Moolenaar wrote:
Ben Schmidt wrote:
- No chance of getting sin(), cos(), atan() and log10()? I realised
after thinking a bit further and reading some other users' posts that
these actually would truly be useful. Surely they would
Matt Tolton wrote:
Hi,
I'm doing some work on MacVim and I've written a function (see below)
to programmatically evaluate an expression in vim and convert the
result to cocoa values. I'd like to be able to return information
about why the evaluation failed if it does. Can anyone give me
[Actually the patch I attached goes over a couple of other patches I also
had applied; but it still applies to the current source and runtimes OK,
just with some offsets.]
Ben Schmidt wrote:
I'm not sure how to add the variables.
I am. :-)
I've patched 7.1.386 with the new floating point
I don't see what you mean. If you want to convert a Number to a Float
you can add 0.0 to it.
I misinterpreted you in my previous reply. I just realised what you
meant. That makes sense.
Ben.
--~--~-~--~~~---~--~~
You received this message from the vim_dev
Please do read my earlier replies where I note this and other things in
more detail, and provide patches to achieve them (by the way, I'm happy
to fiddle with the patch if you want things done differently/removed if
it makes things easier for you). I just realised something else
though...
- Furthermore, on investigation, it seems there is an interesting
definition of 'significant figures' in the library docs, and %.15g is
the correct value, not %.16g. It might be worth noting at the printf()
docs, or the Float docs where precision is mentioned, or both, that
Matt Tolton wrote:
Hmm. Yes. Looking at it, though, the error message is simply:
E15: Invalid expression: {expr}
That's just the last message, though. Usually the one immediately
prior to it is more useful.
O, right. I see.
No, I can't think of any other way apart from trimming the
Hi, Bram,
Another oddity I've recently discovered is that str2nr won't accept an
explicitly
positive number, such as '+3'.
This is unexpected. Would you be willing to adjust the behaviour? I can't think
of
any negative/compatibility-breaking side effects this would have, but I also
don't
Mikael Jansson wrote:
Hi,
I'm not very familiar with the Vim code base, so I couldn't quite find
my way around, so I'm asking here instead:
Will the range for % (the entire file) always be 1 for line1 and
number-of-lines-in-file for line2?
Yes.
:tag do_one_cmd | /%
There is a comment
Tony Mechelynck wrote:
On 23/06/08 19:28, Ben Schmidt wrote:
Hi, Bram,
Another oddity I've recently discovered is that str2nr won't accept an
explicitly
positive number, such as '+3'.
This is unexpected. Would you be willing to adjust the behaviour? I can't
think of
any negative
Gary Johnson wrote:
On 2008-06-24, Ben Schmidt [EMAIL PROTECTED] wrote:
Bram Moolenaar wrote:
Chris Sutcliffe wrote:
There is a small issue with this patch:
*** ../vim-7.1.327/src/os_unix.cFri Jun 20 11:58:27 2008
--- src/os_unix.c Sat Jun 21 13:06:45 2008
Bram Moolenaar wrote:
Ben Schmidt wrote:
Another oddity I've recently discovered is that str2nr won't accept an
explicitly positive number, such as '+3'.
This is unexpected. Would you be willing to adjust the behaviour? I
can't think of any negative/compatibility-breaking side effects
Ben Schmidt wrote:
Bram Moolenaar wrote:
Ben Schmidt wrote:
Another oddity I've recently discovered is that str2nr won't accept an
explicitly positive number, such as '+3'.
This is unexpected. Would you be willing to adjust the behaviour? I
can't think of any negative/compatibility
Bram Moolenaar wrote:
Ben Schmidt wrote:
While working on the Float printing function, I also noted an odd Vim
behaviour: it won't let you assign a Float to a variable that was
previously a Number, and vice-versa. Or for that matter, it won't let
you change the type of a variable at all
It's called sticky type checking. Not everybody likes it, but that's
the way it is.
I guess it has analogies with languages such as C that use static
typing.
But does it actually have any benefit in Vim script? I can't think of
one. I mean, do people actually see this error and think, I
David Fishburn wrote:
I just installed Vim 7.2a and tried it out.
First launch reported:
Error detected while processing c:\vim\vimfiles\plugin\nerd_commenter.vim
line 4:
E806: using Fload as a String
The plugin is doing this:
let s:NERD_commenter_version = 2.1.7
I don't see this
if has(float)
let g:pi = 3.14159265358979324
let g:e = 2.71828182845904524
let g:d2r = pi / 180
This should be g:pi, surely?
Ben.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit
Bill McCarthy wrote:
On Fri 27-Jun-08 9:17am -0600, Ben Schmidt wrote:
if has(float)
let g:pi = 3.14159265358979324
let g:e = 2.71828182845904524
let g:d2r = pi / 180
This should be g:pi, surely?
Perhaps for clarity - but unless pi were used inside
I would
like to suggest a new project, with the simple purpose to gather or to link,
to all those patches from different sources for different purposes and
needs, that are not *yet* on the mainline or for some reasons they will
never be.
This will help:
- to redirect people when
Alexei Alexandrov wrote:
Ben Schmidt wrote:
Is it possible to get what I want?
With a little jiggerypokery it should be! Perhaps something like
gvim --remote-send C-\C-N:cfile build.logCR:call foreground()CR
You'd obviously want to wrap that in a shell script or alias
Jan Minář wrote:
On Fri, Jul 18, 2008 at 3:45 PM, Ben Schmidt
[EMAIL PROTECTED] wrote:
Jan Minář wrote:
mktemp(1) creates the file securely, with 0600 permissions. That's the
whole point. There is no race condition. That's the whole point.
Presuming the directory it's in is sticky
But now
that I think of it... it really seems like a stretch to imagine that
anybody would find fault with the new behavior if it were done this
way (Hey! Paragraph motions are now stopping at all my whitespace-only
lines!!!), but... who knows...? ;-)
Yes, I would consider that
Matthew Winn wrote:
On Sun, 20 Jul 2008 00:44:48 +1000, Ben Schmidt
[EMAIL PROTECTED] wrote:
As has been pointed out, making a directory in /tmp is more secure. More
specifically, making a directory and putting a file in it (there is a
race condition there, of course...but checking/setting
Ex command substitutions (:help cmdline-special) seem to be done on the keyword
when using the K command. Due to normal settings for iskeyword this won't
usually
show up for K, but will for {Visual}K if you, e.g., highlight a URL with a # in
it
and use K on it (with keywordprg set to
At the moment
:help ctrl-W_f
will jump to
CTRL-W_F
at present. It would be better if it jumped to
CTRL-W_f
I don't know if it's easy to implement a 'least number of characters of
different
case to the original' kind of search, if multiple candidates are equal apart
from
case, but it
Jan Minář wrote:
On Wed, Aug 20, 2008 at 4:38 AM, Ben Schmidt
[EMAIL PROTECTED] wrote:
the shell. It should be checked that the keyword is properly
shell-escaped, too. I can't quickly think of a way to easily exploit
this one, so I don't think it's a security risk, but it's definitely
a bug
This time Vim says :!seamonkey www.example.comxclock which apparently
doesn't do anything. Pasting the URL into the Location bar gives
I bet you're in gvim, right, Tony? I expect you're encountering the
can't run processes in the background problem that a number of users
have commented on
Robert Webb wrote:
Hi,
In a vim script, what's the best way to load a file (to search for
some info), then get rid of it again without any side-effects.
Eg, it shouldn't change the alternative buffer, it should no longer
be loaded in a hidden buffer, and it should work even when there's
place your cursor on 'pwnme', and press K. xclock appears.
Yeah, this is the kind of exploit where you have to tell the user to do
something stupid and them blame Vim that the user is stupid.
Yes. Still...that seems to be the current trend...
The command executed can be an shell alias.
Gary Johnson wrote:
On 2008-08-22, bjrn [EMAIL PROTECTED] wrote:
Hi,
This may not be the right place for this post, but it seems like I've
come across a bug so I am posting here.
If I type
:args file1.m file1.h file2.m
then I expect the arglist to have the file appear in the order I
John Beckett wrote:
Peter Prohaska wrote:
:help right-justify
There is no command in Vim to right justify text. [...]
Justify means to insert variable-width spacing throught the entire
line so the left and right margins are aligned. That's how most books
and newspaper articles appear.
The terms left align and right align are often used as
alternatives to flush left and flush right, but where I was,
align referred to blocks like tables, diagrams, or a block of text.
Mmm. I think that's still the case in DTP circles--alignment refers to
the relationship between objects on a
vim
:set ft=php
i
Esc
%
Illegal backreference.
The patch below fixes it. The problem is that in a substitution stands for
the
original match, but here we want to insert it literally into the string. There
may
be other places where the same mistake is made, I guess, but I didn't look; I
Tony Mechelynck wrote:
On 03/09/08 06:11, Bill McCarthy wrote:
Hello Vim Developers,
I noticed a global variable that doesn't appear to be
intentionally set. The variable `cpo_save' undecorated and
outside a function is implicitly global.
Unfortunately `verbose let' does not reveal where
#elif is not highlighted correctly in vim. I've applied the patch
posted at the following thread. Can somebody take a look to fix the
bug.
Hi, Chip and other script developers,
I have an old Vim 6 lying around I use in 'emergencies' and discovered that it
chokes on the hilinks plugin and others. The problem seems to be the :for
command.
Vim 6, it seems, is unable to even skip over it when it's in an if version=700
or
such
Ian Kelling wrote:
Ok. I've also found I can fix it by doing :diffoff in the new tab,
and :diffthis in the old tab. I can understand having to do :diffoff
to change the foldcolumn and other diff settings that were derived
from the first window. But I think the folding being screwed up in the
in a query string should be passed as amp; or as %26 though many web
pages don't use this, even though the W3C HTML guidelines require it.
I don't believe that's accurate, Tony. Only if you are writing an HTML
file need you use amp; ever and that's only because of the necessity to
escape
For example
:view http://www.vim.org/scripts/script_search_results.php?keywords=netrw
shows an empty buffer, because the URL that is passed to wget contains '\?'.
I guess the URL is also inside quotes when passed to wget (via the
shell)? If it isn't, it *should* have '\?' because ? has a
Thanks for the advice. I attempted this already. It was suggested by a
person on the vim_use mailing list.
I had problems setting up my mappings though:
map silent f2 :silent! !chmod u+w `cygpath %`CR
map F2 :call system('chmod u+w `cygpath '.expand('%').'`')CR
should be close. It
Anyway, all this makes me wonder if we really should be basing the Git
repo on the SVN repo since not even Edward is satisfied with it. I've
been thinking if it wouldn't be simpler to just apply the patches Bram
posts myself. Did you consider this option Markus?
Not really until now,
Ben Schmidt wrote:
Anyway, all this makes me wonder if we really should be basing the Git
repo on the SVN repo since not even Edward is satisfied with it. I've
been thinking if it wouldn't be simpler to just apply the patches Bram
posts myself. Did you consider this option Markus
John Beckett wrote:
Ben Schmidt wrote:
I gave up on SVN ages ago--I would have loved to use it, but
it's just too messy. Now I apply patches. Below is the script
Eventually I'd like to have a tip (http://vim.wikia.com/) on building Vim,
with
probably one overview article, and separate
spell.c:7958: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
All the new warnings I see, with no exception, are for not using the
result of a function which returns a result of type warn_unused_result.
My first impression was that:
- these
I know
that windows file systems are case-insensitive, but I'm trying to
emulate a unix environment, so I want to be able to turn off this
behavior and have file globbing match in a case-sensitive way.
It makes sense to be able to change it, too, as although the *default*
Windows file
Thanks. I see the same thing. I'll look into it presently.
What's the status of this patch? Does it still work with current Vim?
If yes, Markus, would you be willing to merge this into vim_extended?
FYI, I always have the patch compiled into all my versions of Vim (GTK,
console, MacVim) and
I have a prototype of what I think the final product should look like
(see attached) but sticking it into the actual code is proving more
difficult than I originally thought.
Hehe. That doesn't surprise me at all. That's why I was going to put it
on my to do list, and not attempt it for a
I think we don't need the foldcolumn in HTML. One can click on the fold
to open it, and on the text to close it again. That's a lot simpler and
removes the not-so-nice-looking fold column.
How do you solve the ambiguity problem when there are two folds starting
on the same line without the
That's what I was thinking. However, it would certainly be easier to
code (and potentially to interact with) if the foldcolumn width would
just grow to accommodate the highest fold level. What do people
think...should 'foldcolumn' be used for the width of the fold column,
complete with a
You can compile your own Vim 7.2.075, see
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm
I'm sure Matt is completely capable of doing this, Tony, and almost
certainly needs no assistance.
Before reporting a bug, it is always better to try reproducing it with
the latest
If you're writing to a file that another program critically needs
/that's/ your problem.
Configuration file, for example, is critically for almost every daemon.
Do you think that it is only my problem? No, it is very real scenario
which could happen to everyone who use vim.
He didn't mean
I'll make it: make all windows the same height width
How about: make all windows the same size
FWIW, I prefer 'height width'. Neither is strictly correct of course;
consider any three window layout which is a mix of horizontal and
vertical splits.
Ben.
On 4/03/12 11:30 PM, Bram Moolenaar wrote:
John Beckett wrote:
Bram wrote:
1. Write tests for the regexp engine, so that we can finally
use NFA.
2. Fix bugs and review patches
3. Fix bugs and review patches
2. and 3. should be able to work together, so that the mentor
(me) does not have to
I can act as a backup if necessary, too. I've been a bit quiet recently,
but if direct questions or a direct task were in front of me I'd be able
to help out.
Thanks for the offer. John volunteered to be the backup administrator.
Perhaps you can help mentoring students? This involves having a
Everything in the codebase looks OK to me. win_T is a Vim structure, and
has a w_width member when huge features are enabled. All the appropriate
header files are installed. Ruby builds fine for me (and others) on
other platforms.
Have you applied any patches at all?
If not, my best guess is
I don't understand either the original problem or Bram's comment,
because it works fine for me using Vim 7.3.600, from the Cream site
but without Cream, on Windows XP. I click in the upper left window
and the scroll wheel scrolls the upper left window; I click in the
upper right window and the
On 29/07/12 11:41 PM, Balazs Kezes wrote:
My vim seems to flicker on big terminals because the output buffer is
limited to 2K. Outputting a full redraw of large screen needs much more
characters (especially if it has lots of colors). Currently it is
distributed to several writes (separated by
On 18/09/12 8:49 AM, Dominique Pellé wrote:
Raymond Ko raymond.w...@gmail.com wrote:
Hello all,
After compiling VIM with Visual Studio 2012,
apparently a buffer overflow was detected
and caused VIM to crash.
...snip...
mb_unescape() seems to meant for only
decoding individual characters,
On 18/09/12 10:30 AM, Ben Schmidt wrote:
On 18/09/12 8:49 AM, Dominique Pellé wrote:
Raymond Ko raymond.w...@gmail.com wrote:
Hello all,
After compiling VIM with Visual Studio 2012,
apparently a buffer overflow was detected
and caused VIM to crash.
...snip...
mb_unescape() seems to meant
Here are the steps:
1. Get Visual Studio 2012. The Express edition should be using the
same compiler for the backend but I'm not sure.
2. Compile VIM. Not that the default Make_mvc.mak file doesn't work
anymore because the Windows SDK is no longer referenced by the
vcvarsall.bat. Instead I had to
I think E163 could do with some rewording, or perhaps another error
could be created. It seems E163 is used when there are less than two
arguments, and E165 or E164 when there are two or more. However, the
case when there are zero arguments is confusing. E.g.
vim -u NONE
:n
E163: There is only
On 24/10/12 6:14 PM, Ingo Karkat wrote:
On 24-Oct-2012 02:25:58 +0200, Ben Schmidt wrote:
I think E163 could do with some rewording, or perhaps another error
could be created. It seems E163 is used when there are less than two
arguments, and E165 or E164 when there are two or more. However
On 25/10/12 3:17 PM, Bram Moolenaar wrote:
Ben Schmidt wrote:
I think E163 could do with some rewording, or perhaps another error
could be created. It seems E163 is used when there are less than two
arguments, and E165 or E164 when there are two or more. However, the
case when there are zero
On 30/10/12 2:40 AM, Jürgen Krämer wrote:
Hi,
Christian Brabandt wrote:
On Mon, October 29, 2012 16:17, Axel wrote:
s makes the cursor move to the beginning of the line(!) changing the
character found there (hence the $ sign). Also, the character ^ is in
fact not displayed.
And how do you
There is a variable tabstops patch by Matthew Winn; it's listed on the Vim
patches page (http://groups.google.com/group/vim_dev/web/vim-patches):
I notice on this page at the moment there is a THIS IS GOING TO BREAK
SOON notice from Google. Is there any replacement page somewhere that
takes
Hi, Bram,
Could the attached changes be incorporated into the syntax/c.vim
included with Vim? I put them together a couple of years ago in response
to a post on one of the mailing lists.
They add support for #if 0...#else and #if 1...#else to highlight the
relevant parts as comments.
I have
On 20/01/11 3:29 PM, Bram Moolenaar wrote:
Ben Schmidt wrote:
Could the attached changes be incorporated into the syntax/c.vim
included with Vim? I put them together a couple of years ago in response
to a post on one of the mailing lists.
They add support for #if 0...#else and #if 1...#else
Oops. Here it is as a patch.
Ben.
On 20/01/11 4:59 PM, Ben Schmidt wrote:
On 20/01/11 3:29 PM, Bram Moolenaar wrote:
Ben Schmidt wrote:
Could the attached changes be incorporated into the syntax/c.vim
included with Vim? I put them together a couple of years ago in response
to a post
On 30/01/11 11:05 AM, Marc Weber wrote:
Does the current vim.sf.net page tell about existing repositories where
vim patches mature ?
If if they are never merged upstream it would be nice to have a local
place to share them.
I know about a git repository which collects many of them.
Mmm. But
Anyway: Is there a way to view/set both: local and global settings for those
options which are both?
:set sets both, but displays the value in effect. To display both, you
need to use :setlocal and :setglobal.
Ben.
--
You received this message from the vim_dev maillist.
Do not top-post!
Hi, Bram,
It came up in a private conversation I had that this line in get_varp() is
useless:
default:EMSG(_(E356: get_varp ERROR));
The reason is that the first time it is called, it is because set_options_default
is running at initialisation time, and since this happens in
On 4/02/11 8:03 AM, Bram Moolenaar wrote:
Ben Schmidt wrote:
It came up in a private conversation I had that this line in
get_varp() is useless:
default:EMSG(_(E356: get_varp ERROR));
The reason is that the first time it is called, it is because
set_options_default
$ cc -o conftest -g -I/usr/local/include -L/usr/local/lib conftest.c
-lm -ltermlib -lelf -lnsl -lsocket -liconv
conftest.c, line 192: warning: statement not reached
This sounds like a bug with the linker for not erroring out when it
can't link against the libraries it has been told to link
On 14/02/11 4:12 PM, Yue Wu wrote:
On Sun, Feb 13, 2011 at 07:30:57PM -0800, Ben Fritz wrote:
On Feb 12, 6:10 pm, Yue Wuvano...@gmail.com wrote:
On Sat, Feb 12, 2011 at 09:42:42AM -0800, Ben Fritz wrote:
On Feb 12, 8:15 am, Yue Wuvano...@gmail.com wrote:
As the title, when setting wrap,
On 15/02/11 3:34 AM, Christian Brabandt wrote:
On Mon, February 14, 2011 12:34 pm, Ben Schmidt wrote:
I think there is a bug here, but it's not the bug you think.
I can make a short single line fold, but it doesn't always do it at
first. It seems I have to make a two-line fold and then shorten
On 15/02/11 11:43 AM, Yue Wu wrote:
I'm confused with `screen line', I think 3 screen lines without EOL in
'wrap' condition will be a long screen line in 'nowrap' condition,
right?
Yes, that's right. So with nowrap, that line should only be folded when
fml is 0; but with wrap, it should be
Plus, it's only the queue of incoming keypresses - that queue isn't
going to stay very big for very long.
It's not just the input queue that's in question here, it's everywhere
in Vim where keypresses are represented. For instance, the right hand
sides of mappings are not primarily characters,
Plus, it's only the queue of incoming keypresses - that queue isn't
going to stay very big for very long.
It's not just the input queue that's in question here, it's everywhere
in Vim where keypresses are represented. For instance, the right hand
sides of mappings are not primarily characters,
Firstly: even if it would be true for ls - it's a matter of 'ls'
maintainers decision, nothing more. Especially it does not say
foo/bar and foo/bar/ are same, in any manner. Only it says is ls
shows them in the same way, sometimes.
That's true. But it's like saying that 3.14159 isn't exactly
On 22/02/11 12:09 AM, Bram Moolenaar wrote:
Phil Carter wrote:
Using ctrl+v U in insert mode, you can enter Unicode characters by
code point. UTF-8 can only encode up to U+7FFF. Entering any code
point up to that value works fine, but if if you type ctrl+v U
81234567 for example, you get
The whole situation is pretty arbitrary. E.g. ./demo's output under a
modifyOtherKeys:2 UXTerm, compressed to one row, for Shift+ the top row of my
typical US 105-key or variant:
S-~ ! S-@ # $ % S-^ * ( ) S-_ + Backspace
Why the Shift modifier on ~, @, ^, and _, but not !, #, $, etc? (Guessing
So basically backward compatibility and memory efficiency are what
hold vim back in 1970. You made a lot of good points and reasons for
it to be so, but I'm always sad when good ideas are refused just
because of old scenarios.
I don't think anybody has refused the idea, and I don't think
This is my first time joining a discussion, I had a hard time just to
open an account and send my suggestion. I use the default reply
function and I don't mean to upset anyone. Hopefull now this reply is
well-edited (I removed the quote).
Yes, it was a much better reply, thanks, Stephen. And
Another way to extend this might be to switch from a byte queue to a short
integer
queue. The lower 8-bits would be as it is now; the upper eight bits would encode
modifier keys (shift, ctrl, alt, meta, whatever).
I think sticking to the byte queue is best. So much in Vim relies on
text being
I just tried the file. Opening Vim took about a minute with Vim
running at 100% CPU after which Vim became responsive. I then scrolled
down by repeating 99PageDown and just before I reached the bitmap
part of the XPM file Vim crashed. I've tried a few times and it
crashes every time, but only
On 11/02/11 11:02 PM, Dimitar DIMITROV wrote:
I just tested:
:com! Test ec '♛'
then
:Test prints ♀fdQ
:ec '♛' prints '♛'
So the problem is :com related not tr() as previously thought
Attached is the fix.
K_SPECIAL is not a multibyte character code, so vim_strchr is not an appropriate
way
In this case, I'd yanked some text that I wanted to 'put' in
a bunch of places. While going through the buffer, putting the text
where I wanted it, I noticed a line that needed to come out, so I
deleted it. Naturally, the next attempt to put gave me that line
instead of the original text I'd
101 - 200 din 260 matches
Mail list logo
