incsearch highlighting weirdness

[dcuaron]

Vimmers,

i'm patched through 293 and running suse
started vim with "vim -u NONE -U NONE"

to produce the weirdness
start vim and set incsearch then
from the empty buffer
":normal 3i justatestword"
yes there is a space between the i and beginning of the word.

from the resultant buffer place the cursor on the beginning of the line.  start
a search(e.g. /) just type .'s for the search pattern and you can see the
resultant search highlighting "jumping" forward.

further weirdness ensues if you start the search from the space between the
first "justatestword" and the second.  start the search there and for the
pattern just type repeated .'s... the incsearch highlighting jumps forward and
backwards

i realize these cases don't represent real world usage but i wasn't sure if
these quirks are bleeding into anything else.

-dan


--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Bug? Cannot use 'wildmenu' up-down arrows with :cd :lcd

[Tony Mechelynck]

On 16/04/08 22:15, Erik Falor wrote:
> On 4/16/08, *Erik Falor* <[EMAIL PROTECTED] >
> wrote:
>
> On 4/16/08, *Erik Falor* <[EMAIL PROTECTED]
> > wrote:
>
> On Wed, Apr 16, 2008 at 12:22 PM, Erik Falor <[EMAIL PROTECTED]
> > wrote:
>
>
> On 4/13/08, *Tony Mechelynck* <[EMAIL PROTECTED]
> > wrote:
>
>
> On 13/04/08 15:10, Andy Wokula wrote:
> >  Tony Mechelynck schrieb:
> > > vim -gNu NONE
> > > :set wildmenu wildmode=longest:full,full laststatus=2
> > > :lcd
> >
> >  Hmm, this works for me: Press twice before using
> the arrow keys.
> >  The first just shows the menu without selecting
> an entry. It
> >  would be less confusing if the first entry wasn't
> highlighted
> >  immediately.
> >
>
>
> Doesn't work either. Normally I use  rather than
>  until the
> right entry is both highlighted and filled-in but even
> with 
> instead I still get a beep when I try to use .
>
>
> Best regards,
> Tony.
>
> --
> Silverman's Law:
> If Murphy's Law can go wrong, it will.
>
>
>
>
> FWIW, I can reproduce this on Windows with Vim 7.1 w/o any
> patches.
> More specifically, directories that show up in the wildmenu
> as a result of :e  let you use  and  to
> enter/exit them.
> Directories that show up in the wildmenu as a result of :lcd
>  do not work the same way.
>
> VIM - Vi IMproved 7.1 (2007 May 12, compiled May 12 2007
> 14:19:39)
> MS-Windows 32 bit GUI version with OLE support
> Compiled by [EMAIL PROTECTED]
>
> I see this same confusing behavior on Linux Vim 7.1.244:
>
> VIM - Vi IMproved 7.1 (2007 May 12, compiled Feb 7 2008
> 22:31:25)
> Included patches: 1-244
> Compiled by [EMAIL PROTECTED]
> Normal version with GTK2 GUI. Features included (+) or not (-):
>
> Unfortunately I don't have an unpatched version of GTK2 Vim
> to play with :(
>
> --
> Erik Falor
> Registered Linux User #445632 http://counter.li.org
>
>
> I just had a thought: what if you define a custom command that
> uses -complete=file and another that uses -complete=dir? Will
> they behave the same? Do the built-in commands use the same code
> for their completion?
>
>
> These are the results of testing my idea:
>
> complete_test.vim:
> ==
> set history=0 wildmenu wildmode=longest:full,full laststatus=2
> command -nargs=1 -complete=dir CompleteDir echo 
> command -nargs=1 -complete=file CompleteFile echo 
> ==EOF=
>
> C:\Documents and Settings\efalor\Desktop>gvim -NU NONE -u
> complete_test.vim
>
> I just tried completing these two custom commands, and found that
> they do behave differently with regard to  and  keystrokes
> on a directory name.
>
> I checked this both on lately patched gvims on windows and linux, as
> well as the original 7.1 release of gvim.exe for windows. All three
> executables behaved the same.
>
>
> I found some code in src/ex_getln.c that looked likely to be the problem
> and changed it. So far, so good.
> If you want to help test this, here's the patch. I diffed this against
> the latest SVN sources, revision 1000.
>
> Index: ex_getln.c
> ===
> --- ex_getln.c (revision 1000)
> +++ ex_getln.c (working copy)
> @@ -532,8 +532,10 @@
> xpc.xp_context = EXPAND_NOTHING;
> }
> }
> +
> if ((xpc.xp_context == EXPAND_FILES
> - || xpc.xp_context == EXPAND_SHELLCMD) && p_wmnu)
> + || xpc.xp_context == EXPAND_SHELLCMD
> + || xpc.xp_context == EXPAND_DIRECTORIES) && p_wmnu)
> {
> char_u upseg[5];
>
> --
> Erik Falor
> Registered Linux User #445632 http://counter.li.org

Hm. Let's see what Bram thinks of it.


Best regards,
Tony.
-- 
Bore, n.:
A person who talks when you wish him to listen.
-- Ambrose Bierce, "The Devil's Dictionary"

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Improve vim's keyboard input subsystem

[LeoNerd]

Vim copes poorly with a variety of different keyboard inputs.

All the time, we get new users in #vim asking how they can map
Ctrl-Shift-L, or Alt-letters, or various other problems, and we're
forever explaining it Can't Be Done. Sometimes even in gvim, as I
understand, because of the way gvim implements a terminal-like wrapper
which presents terminal sequences at the vim core.

This presents three key problems, which I shall call Cases A, B and C:

  Case A: Ctrl-L and Ctrl-Shift-L generate the same single byte in the
terminal; namely 0x0c. They are indistinct

  Case B: Ctrl-I and Tab generate the same single byte in the terminal;
namely 0x09. They are indistinct

  Case C: UTF-8, Alt+letter, Esc-letter all generate the same bytes in
the terminal. E.g. é vs. Alt+C Alt+) vs. Esc C Esc )

Cases A and B cannot be solved without fixing the terminal itself. Vim
currently uses timing information to distinguish some of Case C.

Furthermore, until very recently, Vim did not understand any of Xterm
et.al.'s modified function key sequences; e.g. Ctrl-Left. It now has some
understanding of them, but not in a way I find very satisfactory. (See
later).

I have a fix for all of this mess, which involves a combination of fixes
in the terminal, and in vim. Some of these fixes are already in progress
in xterm or other places. The fixes I suggest here for vim are either
recognition of new things that previously didn't happen, or changes to
internals that would be of greater benefit anyway.

It is my understanding that the primary input queue is a sequence of
bytes from the terminal, that gets interpreted late (if at all) into
keys. This needs to become a queue of key events. Each key event would be
one of:

  struct { int modifiers; int codepoint };   /* for Unicode input */
  struct { int modifiers; int functionkey }; /* for non-printing keys */
  (in both cases, "modifers" is a bitfield of CTRL, SHIFT, ALT, etc..)

This becomes trivial to fill from the GTK, Win32, MacOSX or other cases.
It also becomes easy to fill from the terminal, if for example, my own
"libtermkey" library is used to parse the terminal's input. This already
provides structs of that form.

The advantages here in the non-terminal cases easily present themselves -
we can now easily tell apart all of cases A, B, and C above.

The fix in the terminals themselves involves changes to the sequences
used to express various concepts. Maintaining as much backward compat. as
possible, function keys in xterm et.al. already use the form

  CSI function;modifiers ~

For example, CSI 12;5~ as Ctrl-F2.

This scheme can extend into trivially to the "private use area" of CSIs,
where we define 'u' to mean a modified Unicode point:

  CSI codepoint;modifiers u

This now stands for any modified keystroke that isn't a function key
(i.e. sends normal Unicode data when unmodified). To reuse the examples
above:

  Ctrl-Shift-L  =>  CSI 76;5u(Codepoint 76 being Capital L, and the
  Ctrl modifier. The fact that Shift is used to obtain the capital L
  is unimportant. Compare to e.g. Ctrl-$ or other symbols that need
  to be shifted on most keyboard layouts)

We could, if we wanted to break everything, define that:

  Ctrl-L=>  CSI 108;5u

but it's likely no program yet would understand that. Plus, most kernel's
tty input layers like only one byte for things like EOF (Ctrl-D), so it's
probably best to leave those as they were

  Ctrl-L=> 0x0c

Now we can distinguish all three cases of B:

  é => 0xc3 0xa9
  Alt+C Alt+)   => CSI 67;3u CSI 41;3u
  Esc C Esc )   => ESC C ESC )

We have to stick to the 8bit encoding of CSI in order that this be
unambiguous, but if we do that, we find that all three cases have unique
byte sequences, and any case can be determined only by looking at the
bytes themselves, and not the timing that they arrived at.

We can aim at a partial solution - simply adding recognition into vim for
these new CSIs doesn't prevent older schemes from working. But it does
mean that given a new terminal using the right scheme, that suddenly vim
can recognise any keyboard input. Also, the upshot gained by having
proper representation in structs internally gives instant gains for the
GTK and other GUI cases, independent of any terminal work.

I would like to suggest that a full CSI parser be implemented (or just
use the one from my "libtermkey" library), as this is most
forward-compatible. Over the last 5 years or so I've witnessed much
breakage in any terminal program that doesn't do this (i.e. all of them)
when I press Ctrl-Left in my xterm; because the program didn't have a
full CSI parser, so gave up after CSI 1; rather than read the whole
sequence. It then was left with a raw 5D which it printed as normal
input. If a program had a full CSI parser, then it wouldn't have broken
here. It wouldn't understand the second 5 parameter, it would have just
seen a normal  key press. I think that's a much more graceful
fail

Re: Vertical split issue

[Erik Falor]

On 4/16/08, Zdenek Sekera <[EMAIL PROTECTED]> wrote:
>
>
> No problem when I try 'vim -O a b' this puts both files
> side by side as it should.
> I was surprised to see 'vim -O a a' (note the same file)
> it doesn't put them in a split window. Is this expected?
> On the other hand
>
> vim a
> :vsp a   (inside vim)
>
> will put correctly the same file 'a' side by side.
>
>
> ---Zdenek
>
>
>
$ vim -o a a   #this doesn't  open file a in two horizontal splits

$ vim -p a a   #this doesn't  open file a in two tabpages

Given that this behavior is consistant across three command-line
options, and without having searched for the code, I'd say that Vim
does this on purpose.  I would suspect that opening the same file in two
windows isn't a real common need, especially if each view
of the file starts at the very same line.

If you really want to do this, though, may I suggest:

$ vim a -c "vert sb"

-- 
Erik Falor
Registered Linux User #445632 http://counter.li.org

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Bug? Cannot use 'wildmenu' up-down arrows with :cd :lcd

[Erik Falor]

On 4/16/08, Erik Falor <[EMAIL PROTECTED]> wrote:
>
> On 4/16/08, Erik Falor <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, Apr 16, 2008 at 12:22 PM, Erik Falor <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > On 4/13/08, Tony Mechelynck <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > > On 13/04/08 15:10, Andy Wokula wrote:
> > > > > Tony Mechelynck schrieb:
> > > > >> vim -gNu NONE
> > > > >>  :set wildmenu wildmode=longest:full,full laststatus=2
> > > > >>  :lcd
> > > > >
> > > > > Hmm, this works for me: Press  twice before using the arrow
> > > > keys.
> > > > > The first  just shows the menu without selecting an
> > > > entry.  It
> > > > > would be less confusing if the first entry wasn't highlighted
> > > > > immediately.
> > > > >
> > > >
> > > >
> > > > Doesn't work either. Normally I use  rather than  until
> > > > the
> > > > right entry is both highlighted and filled-in but even with 
> > > > instead I still get a beep when I try to use .
> > > >
> > > >
> > > > Best regards,
> > > > Tony.
> > > >
> > > > --
> > > > Silverman's Law:
> > > > If Murphy's Law can go wrong, it will.
> > > >
> > > >
> > > > > > > >
> > > >
> > > FWIW, I can reproduce this on Windows with Vim 7.1 w/o any patches.
> > > More specifically, directories that show up in the wildmenu as a
> > > result of :e  let you use  and  to enter/exit them.
> > > Directories that show up in the wildmenu as a result of :lcd  do
> > > not work the same way.
> > >
> > > VIM - Vi IMproved 7.1 (2007 May 12, compiled May 12 2007 14:19:39)
> > > MS-Windows 32 bit GUI version with OLE support
> > > Compiled by [EMAIL PROTECTED]
> > >
> > > I see this same confusing behavior on Linux Vim 7.1.244:
> > >
> > > VIM - Vi IMproved 7.1 (2007 May 12, compiled Feb 7 2008 22:31:25)
> > > Included patches: 1-244
> > > Compiled by [EMAIL PROTECTED]
> > > Normal version with GTK2 GUI. Features included (+) or not (-):
> > >
> > > Unfortunately I don't have an unpatched version of GTK2
> > > Vim to play with :(
> > >
> > > --
> > > Erik Falor
> > > Registered Linux User #445632 http://counter.li.org
> >
> >
> > I just had a thought: what if you define a custom command that uses
> > -complete=file and another that uses -complete=dir?  Will they behave the
> > same?  Do the built-in commands use the same code for their completion?
>
>
> These are the results of testing my idea:
>
> complete_test.vim:
> ==
> set history=0 wildmenu wildmode=longest:full,full laststatus=2
> command -nargs=1 -complete=dir CompleteDir echo 
> command -nargs=1 -complete=file CompleteFile echo 
> ==EOF=
>
> C:\Documents and Settings\efalor\Desktop>gvim -NU NONE -u
> complete_test.vim
>
> I just tried completing these two custom commands, and found that they do
> behave differently with regard to  and  keystrokes on a directory 
> name.
>
> I checked this both on lately patched gvims on windows and linux, as well
> as the original 7.1 release of gvim.exe for windows.  All three executables
> behaved the same.
>

I found some code in src/ex_getln.c that looked likely to be the problem and
changed it.  So far, so good.
If you want to help test this, here's the patch.  I diffed this against the
latest SVN sources, revision 1000.

Index: ex_getln.c
===
--- ex_getln.c (revision 1000)
+++ ex_getln.c (working copy)
@@ -532,8 +532,10 @@
xpc.xp_context = EXPAND_NOTHING;
}
}
+
if ((xpc.xp_context == EXPAND_FILES
- || xpc.xp_context == EXPAND_SHELLCMD) && p_wmnu)
+ || xpc.xp_context == EXPAND_SHELLCMD
+ || xpc.xp_context == EXPAND_DIRECTORIES) && p_wmnu)
{
char_u upseg[5];

-- 
Erik Falor
Registered Linux User #445632 http://counter.li.org

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Bug? Cannot use 'wildmenu' up-down arrows with :cd :lcd

[Erik Falor]

On 4/16/08, Erik Falor <[EMAIL PROTECTED]> wrote:
>
> On Wed, Apr 16, 2008 at 12:22 PM, Erik Falor <[EMAIL PROTECTED]> wrote:
>
> >
> > On 4/13/08, Tony Mechelynck <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > On 13/04/08 15:10, Andy Wokula wrote:
> > > > Tony Mechelynck schrieb:
> > > >> vim -gNu NONE
> > > >>  :set wildmenu wildmode=longest:full,full laststatus=2
> > > >>  :lcd
> > > >
> > > > Hmm, this works for me: Press  twice before using the arrow
> > > keys.
> > > > The first  just shows the menu without selecting an entry.  It
> > > > would be less confusing if the first entry wasn't highlighted
> > > > immediately.
> > > >
> > >
> > >
> > > Doesn't work either. Normally I use  rather than  until
> > > the
> > > right entry is both highlighted and filled-in but even with 
> > > instead I still get a beep when I try to use .
> > >
> > >
> > > Best regards,
> > > Tony.
> > >
> > > --
> > > Silverman's Law:
> > > If Murphy's Law can go wrong, it will.
> > >
> > >
> > > > > >
> > >
> > FWIW, I can reproduce this on Windows with Vim 7.1 w/o any patches.
> > More specifically, directories that show up in the wildmenu as a result
> > of :e  let you use  and  to enter/exit them.
> > Directories that show up in the wildmenu as a result of :lcd  do
> > not work the same way.
> >
> > VIM - Vi IMproved 7.1 (2007 May 12, compiled May 12 2007 14:19:39)
> > MS-Windows 32 bit GUI version with OLE support
> > Compiled by [EMAIL PROTECTED]
> >
> > I see this same confusing behavior on Linux Vim 7.1.244:
> >
> > VIM - Vi IMproved 7.1 (2007 May 12, compiled Feb 7 2008 22:31:25)
> > Included patches: 1-244
> > Compiled by [EMAIL PROTECTED]
> > Normal version with GTK2 GUI. Features included (+) or not (-):
> >
> > Unfortunately I don't have an unpatched version of GTK2
> > Vim to play with :(
> >
> > --
> > Erik Falor
> > Registered Linux User #445632 http://counter.li.org
>
>
> I just had a thought: what if you define a custom command that uses
> -complete=file and another that uses -complete=dir?  Will they behave the
> same?  Do the built-in commands use the same code for their completion?


These are the results of testing my idea:

complete_test.vim:
==
set history=0 wildmenu wildmode=longest:full,full laststatus=2
command -nargs=1 -complete=dir CompleteDir echo 
command -nargs=1 -complete=file CompleteFile echo 
==EOF=

C:\Documents and Settings\efalor\Desktop>gvim -NU NONE -u complete_test.vim

I just tried completing these two custom commands, and found that they do
behave differently with regard to  and  keystrokes on a
directory name.

I checked this both on lately patched gvims on windows and linux, as well as
the original 7.1 release of gvim.exe for windows.  All three executables
behaved the same.

-- 
Erik Falor
Registered Linux User #445632 http://counter.li.org

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Bug? Cannot use 'wildmenu' up-down arrows with :cd :lcd

[Erik Falor]

On Wed, Apr 16, 2008 at 12:22 PM, Erik Falor <[EMAIL PROTECTED]> wrote:

>
> On 4/13/08, Tony Mechelynck <[EMAIL PROTECTED]> wrote:
> >
> >
> > On 13/04/08 15:10, Andy Wokula wrote:
> > > Tony Mechelynck schrieb:
> > >> vim -gNu NONE
> > >>  :set wildmenu wildmode=longest:full,full laststatus=2
> > >>  :lcd
> > >
> > > Hmm, this works for me: Press  twice before using the arrow keys.
> > > The first  just shows the menu without selecting an entry.  It
> > > would be less confusing if the first entry wasn't highlighted
> > > immediately.
> > >
> >
> >
> > Doesn't work either. Normally I use  rather than  until the
> > right entry is both highlighted and filled-in but even with 
> > instead I still get a beep when I try to use .
> >
> >
> > Best regards,
> > Tony.
> >
> > --
> > Silverman's Law:
> > If Murphy's Law can go wrong, it will.
> >
> >
> > > >
> >
> FWIW, I can reproduce this on Windows with Vim 7.1 w/o any patches.
> More specifically, directories that show up in the wildmenu as a result of
> :e  let you use  and  to enter/exit them.
> Directories that show up in the wildmenu as a result of :lcd  do not
> work the same way.
>
> VIM - Vi IMproved 7.1 (2007 May 12, compiled May 12 2007 14:19:39)
> MS-Windows 32 bit GUI version with OLE support
> Compiled by [EMAIL PROTECTED]
>
> I see this same confusing behavior on Linux Vim 7.1.244:
>
> VIM - Vi IMproved 7.1 (2007 May 12, compiled Feb 7 2008 22:31:25)
> Included patches: 1-244
> Compiled by [EMAIL PROTECTED]
> Normal version with GTK2 GUI. Features included (+) or not (-):
>
> Unfortunately I don't have an unpatched version of GTK2
> Vim to play with :(
>
> --
> Erik Falor
> Registered Linux User #445632 http://counter.li.org


I just had a thought: what if you define a custom command that uses
-complete=file and another that uses -complete=dir?  Will they behave the
same?  Do the built-in commands use the same code for their completion?


-- 
Erik Falor
Registered Linux User #445632 http://counter.li.org

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Bug? Cannot use 'wildmenu' up-down arrows with :cd :lcd

[Erik Falor]

On 4/13/08, Tony Mechelynck <[EMAIL PROTECTED]> wrote:
>
>
> On 13/04/08 15:10, Andy Wokula wrote:
> > Tony Mechelynck schrieb:
> >> vim -gNu NONE
> >>  :set wildmenu wildmode=longest:full,full laststatus=2
> >>  :lcd
> >
> > Hmm, this works for me: Press  twice before using the arrow keys.
> > The first  just shows the menu without selecting an entry.  It
> > would be less confusing if the first entry wasn't highlighted
> > immediately.
> >
>
>
> Doesn't work either. Normally I use  rather than  until the
> right entry is both highlighted and filled-in but even with 
> instead I still get a beep when I try to use .
>
>
> Best regards,
> Tony.
>
> --
> Silverman's Law:
> If Murphy's Law can go wrong, it will.
>
>
> >
>
FWIW, I can reproduce this on Windows with Vim 7.1 w/o any patches.
More specifically, directories that show up in the wildmenu as a result of
:e  let you use  and  to enter/exit them.
Directories that show up in the wildmenu as a result of :lcd  do not
work the same way.

VIM - Vi IMproved 7.1 (2007 May 12, compiled May 12 2007 14:19:39)
MS-Windows 32 bit GUI version with OLE support
Compiled by [EMAIL PROTECTED]

I see this same confusing behavior on Linux Vim 7.1.244:

VIM - Vi IMproved 7.1 (2007 May 12, compiled Feb 7 2008 22:31:25)
Included patches: 1-244
Compiled by [EMAIL PROTECTED]
Normal version with GTK2 GUI. Features included (+) or not (-):

Unfortunately I don't have an unpatched version of GTK2 Vim to play with :(

-- 
Erik Falor
Registered Linux User #445632 http://counter.li.org

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Updated floating point patch

[Charles E Campbell Jr]

Ben Schmidt wrote:
> Charles E Campbell Jr wrote:
>   
>> Ben Schmidt wrote:
>> 
>>> Ben Schmidt wrote:
>>>   
>>>   
> OTOH, with & there is no ambiguity because the various uses of & are 
> strictly separated:
>   
>   
 Actually, there still is ambiguity unless one requires a decimal point or 
 exponent. Without that restriction

 &123.456

 could still mean 123 (or 123.0) concatenated with 456. But with the 
 restriction

 &123

 is invalid. Not sure whether that's desirable. Probably the lesser of two 
 evils. 
 Of course, it needs to be enforced that printf and such functions either 
 omit the 
 ampersand for floats which happen to be integers (probably undesirable) or 
 always 
 append a '.0' in this case.

 Would wrapping floats in braces be a better syntax? I don't think this 
 would clash 
 with anything: dictionaries require keys followed by colons which don't 
 occur in 
 floats, and a float is also an invalid variable or function name due to 
 starting 
 with a digit or sign (+/-) so couldn't be used as part of curly-brace 
 variable or 
 function names. E.g.

 :let myfloat={12.52}
 :let mybig={1234e56}
 :let myintegerfloat={123}

 To me, this is nicer than a leading &, and avoids the nasty restriction of 
 needing 
 a decimal point all the time/ambiguity of decimal point vs. concatenation.
 
 
>>> Actually, to clarify, my proposal is that a set of curly braces is taken to 
>>> represent a float if and only if it is (1) not preceded by a valid variable 
>>> name 
>>> character and (2) contains a valid float.
>>>
>>> I.e. floats:
>>>
>>> {+123.456}
>>> {-123}
>>> {123e-4}
>>> {123.456}something_to_concatenate
>>>
>>> non-floats:
>>>
>>> {dictionary: 'value'}
>>> variable_name_with_number_{123}
>>> variable_name_with_number_and_variable_e_concatted_and_included_{123e4}
>>> variable_name_with_six_digits_here_{123.456}
>>> {variable_name_from_a_variable}
>>> {10>>
>>> combination!:
>>>
>>> variable_name_with_float_expression_giving_{{0.55}>> variable_name_with_float_that_prints_as_integer_{{123}}
>>>
>>> invalid:
>>>
>>> variable_name_with_punctuation_due_to_float_{{123.456}}
>>>
>>> I think it works unambiguously and sensibly, though, of course, you can 
>>> still do 
>>> dumb things if you try hard enough! But I don't think it breaks anything 
>>> that 
>>> currently works (even if what currently works is dumb)!
>>>   
>>>   
>> let x12=3
>> echo x{1.2}
>>
>> Works quite nicely -- and is ambiguous with respect to floating point 
>> overloading.
>> 
>
> No, it isn't ambiguous. By (1) of my definition, this is not to be 
> interpreted as 
> a float. Furthermore, a variable with name 'x1.2' is invalid. A more 
> confusing 
> example would be
>
> let e=3
> let x132=4
> echo x{1e2}
>
> but it still isn't ambiguous by my definition.
>   
A variable with the name 'x1.2' is invalid, but: 1.2 currently -> 12, 
and x12 is not invalid.  But, as you said, the {} in my example is being 
preceded by a valid variable name character, so my objection is nullified.

Regards,
Chip Campbell


--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Updated floating point patch

[Ben Schmidt]

Charles E Campbell Jr wrote:
 >>> Actually, to clarify, my proposal is that a set of curly braces is
 >>> taken to represent a float if and only if it is (1) not preceded by
 >>> a valid variable name character and (2) contains a valid float.
 >>>
 >>> I.e. floats:
 >>>
 >>> {+123.456}
 >>> {-123}
 >>> {123e-4}
 >>> {123.456}something_to_concatenate
 >>>
 >>> non-floats:
 >>>
 >>> {dictionary: 'value'}
 >>> variable_name_with_number_{123}
 >>> variable_name_with_number_and_variable_e_concatted_and_included_{123e4}
 >>> variable_name_with_six_digits_here_{123.456}
 >>> {variable_name_from_a_variable}
 >>> {10>>
 >>> combination!:
 >>>
 >>> variable_name_with_float_expression_giving_{{0.55}>> variable_name_with_float_that_prints_as_integer_{{123}}
 >>>
 >>> invalid:
 >>>
 >>> variable_name_with_punctuation_due_to_float_{{123.456}}
 >>>
 >>> I think it works unambiguously and sensibly, though, of course, you can 
 >>> still do
 >>> dumb things if you try hard enough! But I don't think it breaks anything 
 >>> that
 >>> currently works (even if what currently works is dumb)!
 >>>
 >>>
 >> let x12=3
 >> echo x{1.2}
 >>
 >> Works quite nicely -- and is ambiguous with respect to floating point
 >> overloading.
 >>
 > Sorry -- forgot about the no leading variable-name characters (ie.
 > [a-zA-Z:_<>]).
 >
 > Regards,
 > Chip Campbell

Cheers.

My later reply to your earlier message was written only because this one
hadn't arrived in my inbox at that stage.

Smiles,

Ben.




--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Updated floating point patch

[Ben Schmidt]

Charles E Campbell Jr wrote:
> Ben Schmidt wrote:
>> Ben Schmidt wrote:
>>   
 OTOH, with & there is no ambiguity because the various uses of & are 
 strictly separated:
   
>>> Actually, there still is ambiguity unless one requires a decimal point or 
>>> exponent. Without that restriction
>>>
>>> &123.456
>>>
>>> could still mean 123 (or 123.0) concatenated with 456. But with the 
>>> restriction
>>>
>>> &123
>>>
>>> is invalid. Not sure whether that's desirable. Probably the lesser of two 
>>> evils. 
>>> Of course, it needs to be enforced that printf and such functions either 
>>> omit the 
>>> ampersand for floats which happen to be integers (probably undesirable) or 
>>> always 
>>> append a '.0' in this case.
>>>
>>> Would wrapping floats in braces be a better syntax? I don't think this 
>>> would clash 
>>> with anything: dictionaries require keys followed by colons which don't 
>>> occur in 
>>> floats, and a float is also an invalid variable or function name due to 
>>> starting 
>>> with a digit or sign (+/-) so couldn't be used as part of curly-brace 
>>> variable or 
>>> function names. E.g.
>>>
>>> :let myfloat={12.52}
>>> :let mybig={1234e56}
>>> :let myintegerfloat={123}
>>>
>>> To me, this is nicer than a leading &, and avoids the nasty restriction of 
>>> needing 
>>> a decimal point all the time/ambiguity of decimal point vs. concatenation.
>>> 
>> Actually, to clarify, my proposal is that a set of curly braces is taken to 
>> represent a float if and only if it is (1) not preceded by a valid variable 
>> name 
>> character and (2) contains a valid float.
>>
>> I.e. floats:
>>
>> {+123.456}
>> {-123}
>> {123e-4}
>> {123.456}something_to_concatenate
>>
>> non-floats:
>>
>> {dictionary: 'value'}
>> variable_name_with_number_{123}
>> variable_name_with_number_and_variable_e_concatted_and_included_{123e4}
>> variable_name_with_six_digits_here_{123.456}
>> {variable_name_from_a_variable}
>> {10>
>> combination!:
>>
>> variable_name_with_float_expression_giving_{{0.55}> variable_name_with_float_that_prints_as_integer_{{123}}
>>
>> invalid:
>>
>> variable_name_with_punctuation_due_to_float_{{123.456}}
>>
>> I think it works unambiguously and sensibly, though, of course, you can 
>> still do 
>> dumb things if you try hard enough! But I don't think it breaks anything 
>> that 
>> currently works (even if what currently works is dumb)!
>>   
> let x12=3
> echo x{1.2}
> 
> Works quite nicely -- and is ambiguous with respect to floating point 
> overloading.

No, it isn't ambiguous. By (1) of my definition, this is not to be interpreted 
as 
a float. Furthermore, a variable with name 'x1.2' is invalid. A more confusing 
example would be

let e=3
let x132=4
echo x{1e2}

but it still isn't ambiguous by my definition.

Ben.





--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Updated floating point patch

[Charles E Campbell Jr]

Charles E Campbell Jr wrote:
> Ben Schmidt wrote:
>   
>> Ben Schmidt wrote:
>>   
>> 
 OTOH, with & there is no ambiguity because the various uses of & are 
 strictly separated:
   
 
>>> Actually, there still is ambiguity unless one requires a decimal point or 
>>> exponent. Without that restriction
>>>
>>> &123.456
>>>
>>> could still mean 123 (or 123.0) concatenated with 456. But with the 
>>> restriction
>>>
>>> &123
>>>
>>> is invalid. Not sure whether that's desirable. Probably the lesser of two 
>>> evils. 
>>> Of course, it needs to be enforced that printf and such functions either 
>>> omit the 
>>> ampersand for floats which happen to be integers (probably undesirable) or 
>>> always 
>>> append a '.0' in this case.
>>>
>>> Would wrapping floats in braces be a better syntax? I don't think this 
>>> would clash 
>>> with anything: dictionaries require keys followed by colons which don't 
>>> occur in 
>>> floats, and a float is also an invalid variable or function name due to 
>>> starting 
>>> with a digit or sign (+/-) so couldn't be used as part of curly-brace 
>>> variable or 
>>> function names. E.g.
>>>
>>> :let myfloat={12.52}
>>> :let mybig={1234e56}
>>> :let myintegerfloat={123}
>>>
>>> To me, this is nicer than a leading &, and avoids the nasty restriction of 
>>> needing 
>>> a decimal point all the time/ambiguity of decimal point vs. concatenation.
>>> 
>>>   
>> Actually, to clarify, my proposal is that a set of curly braces is taken to 
>> represent a float if and only if it is (1) not preceded by a valid variable 
>> name 
>> character and (2) contains a valid float.
>>
>> I.e. floats:
>>
>> {+123.456}
>> {-123}
>> {123e-4}
>> {123.456}something_to_concatenate
>>
>> non-floats:
>>
>> {dictionary: 'value'}
>> variable_name_with_number_{123}
>> variable_name_with_number_and_variable_e_concatted_and_included_{123e4}
>> variable_name_with_six_digits_here_{123.456}
>> {variable_name_from_a_variable}
>> {10>
>> combination!:
>>
>> variable_name_with_float_expression_giving_{{0.55}> variable_name_with_float_that_prints_as_integer_{{123}}
>>
>> invalid:
>>
>> variable_name_with_punctuation_due_to_float_{{123.456}}
>>
>> I think it works unambiguously and sensibly, though, of course, you can 
>> still do 
>> dumb things if you try hard enough! But I don't think it breaks anything 
>> that 
>> currently works (even if what currently works is dumb)!
>>   
>> 
> let x12=3
> echo x{1.2}
>
> Works quite nicely -- and is ambiguous with respect to floating point 
> overloading.
>   
Sorry -- forgot about the no leading variable-name characters (ie. 
[a-zA-Z:_<>]).

Regards,
Chip Campbell


--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Updated floating point patch

[Charles E Campbell Jr]

Ben Schmidt wrote:
> Ben Schmidt wrote:
>   
>>> OTOH, with & there is no ambiguity because the various uses of & are 
>>> strictly separated:
>>>   
>> Actually, there still is ambiguity unless one requires a decimal point or 
>> exponent. Without that restriction
>>
>> &123.456
>>
>> could still mean 123 (or 123.0) concatenated with 456. But with the 
>> restriction
>>
>> &123
>>
>> is invalid. Not sure whether that's desirable. Probably the lesser of two 
>> evils. 
>> Of course, it needs to be enforced that printf and such functions either 
>> omit the 
>> ampersand for floats which happen to be integers (probably undesirable) or 
>> always 
>> append a '.0' in this case.
>>
>> Would wrapping floats in braces be a better syntax? I don't think this would 
>> clash 
>> with anything: dictionaries require keys followed by colons which don't 
>> occur in 
>> floats, and a float is also an invalid variable or function name due to 
>> starting 
>> with a digit or sign (+/-) so couldn't be used as part of curly-brace 
>> variable or 
>> function names. E.g.
>>
>> :let myfloat={12.52}
>> :let mybig={1234e56}
>> :let myintegerfloat={123}
>>
>> To me, this is nicer than a leading &, and avoids the nasty restriction of 
>> needing 
>> a decimal point all the time/ambiguity of decimal point vs. concatenation.
>> 
>
> Actually, to clarify, my proposal is that a set of curly braces is taken to 
> represent a float if and only if it is (1) not preceded by a valid variable 
> name 
> character and (2) contains a valid float.
>
> I.e. floats:
>
> {+123.456}
> {-123}
> {123e-4}
> {123.456}something_to_concatenate
>
> non-floats:
>
> {dictionary: 'value'}
> variable_name_with_number_{123}
> variable_name_with_number_and_variable_e_concatted_and_included_{123e4}
> variable_name_with_six_digits_here_{123.456}
> {variable_name_from_a_variable}
> {10
> combination!:
>
> variable_name_with_float_expression_giving_{{0.55} variable_name_with_float_that_prints_as_integer_{{123}}
>
> invalid:
>
> variable_name_with_punctuation_due_to_float_{{123.456}}
>
> I think it works unambiguously and sensibly, though, of course, you can still 
> do 
> dumb things if you try hard enough! But I don't think it breaks anything that 
> currently works (even if what currently works is dumb)!
>   
let x12=3
echo x{1.2}

Works quite nicely -- and is ambiguous with respect to floating point 
overloading.

Regards,
Chip Campbell



--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Patch to try out: floating point

[Ben Schmidt]

Tony Mechelynck wrote:
> On 09/04/08 17:30, Bram Moolenaar wrote:
>> Tony Mechelynck wrote:
> [...]
>>> Oh, oh.. it had started working (and&1.0e256 multiplied by itself gives
>>> inf, which is correct), but ":echo&1.0e308" crashes gvim (on Linux
>>> i686) with SIGSEGV.
>> Easy to reproduce.  Turns out that this line causes it:
>>
>>  sprintf(tmp, format, f);
>>
>> Here "format" is "%f"  and "f" is your value 1e+308.  The result is an
>> awful long string of numbers.  I suppose it's about 308 digits.  How big
>> does "tmp" need to be to hold any result here?  I don't think %f has a
>> way of specifying a maximal field width.
> [...]
> 
> I suggest a third floating-point format (%g maybe, or something else if 
> that is already taken) which would mean "either %f or %e depending on 
> the size of the exponent" similar, IIRC, to the number output formats 
> available in FORTRAN and/or BASIC. That format would be implicit when 
> ":echo"ing a floating-point number. (Yes, I know, Vim is neither FORTRAN 
> nor BASIC, but I feel this kind of thing would be better than crashing 
> or even than giving an error.)

+1.

Ben.

> IIRC, in FORTRAN, the G output format would give (for different values 
> output under a single format) results like:
> 
> -1.234567E-123 (for a small number)
>   2.25  (with spaces to the same width)
>   342.5682  (with spaces for a large number but not too large)
>   6.02E+023 (for an even bigger number)
> NAN(a special case)
> -INF   (another special case)
> 
> (this from what [I think that] I remember from the time I used FORTRAN 
> on computers whose printers had no lowercase letters).





--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Updated floating point patch

[Ben Schmidt]

Ben Schmidt wrote:
>> OTOH, with & there is no ambiguity because the various uses of & are 
>> strictly separated:
> 
> Actually, there still is ambiguity unless one requires a decimal point or 
> exponent. Without that restriction
> 
> &123.456
> 
> could still mean 123 (or 123.0) concatenated with 456. But with the 
> restriction
> 
> &123
> 
> is invalid. Not sure whether that's desirable. Probably the lesser of two 
> evils. 
> Of course, it needs to be enforced that printf and such functions either omit 
> the 
> ampersand for floats which happen to be integers (probably undesirable) or 
> always 
> append a '.0' in this case.
> 
> Would wrapping floats in braces be a better syntax? I don't think this would 
> clash 
> with anything: dictionaries require keys followed by colons which don't occur 
> in 
> floats, and a float is also an invalid variable or function name due to 
> starting 
> with a digit or sign (+/-) so couldn't be used as part of curly-brace 
> variable or 
> function names. E.g.
> 
> :let myfloat={12.52}
> :let mybig={1234e56}
> :let myintegerfloat={123}
> 
> To me, this is nicer than a leading &, and avoids the nasty restriction of 
> needing 
> a decimal point all the time/ambiguity of decimal point vs. concatenation.

Actually, to clarify, my proposal is that a set of curly braces is taken to 
represent a float if and only if it is (1) not preceded by a valid variable 
name 
character and (2) contains a valid float.

I.e. floats:

{+123.456}
{-123}
{123e-4}
{123.456}something_to_concatenate

non-floats:

{dictionary: 'value'}
variable_name_with_number_{123}
variable_name_with_number_and_variable_e_concatted_and_included_{123e4}
variable_name_with_six_digits_here_{123.456}
{variable_name_from_a_variable}
{10http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: Updated floating point patch

[Ben Schmidt]

> OTOH, with & there is no ambiguity because the various uses of & are 
> strictly separated:

Actually, there still is ambiguity unless one requires a decimal point or 
exponent. Without that restriction

&123.456

could still mean 123 (or 123.0) concatenated with 456. But with the restriction

&123

is invalid. Not sure whether that's desirable. Probably the lesser of two 
evils. 
Of course, it needs to be enforced that printf and such functions either omit 
the 
ampersand for floats which happen to be integers (probably undesirable) or 
always 
append a '.0' in this case.

Would wrapping floats in braces be a better syntax? I don't think this would 
clash 
with anything: dictionaries require keys followed by colons which don't occur 
in 
floats, and a float is also an invalid variable or function name due to 
starting 
with a digit or sign (+/-) so couldn't be used as part of curly-brace variable 
or 
function names. E.g.

:let myfloat={12.52}
:let mybig={1234e56}
:let myintegerfloat={123}

To me, this is nicer than a leading &, and avoids the nasty restriction of 
needing 
a decimal point all the time/ambiguity of decimal point vs. concatenation.

Ben.





--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: vim sources

[Aram Antonyan]

Thanks Vlad :)

On Wed, Apr 16, 2008 at 2:47 PM, Vladimir Marek <[EMAIL PROTECTED]>
wrote:

> Hi,
>
> > I'm new in this list, and new to vim sources. I have several questions.
> Can
> > you please explain me or give me some link with explanation about
> >
> > 1. Is there any documentation which explains .vim files and theirs
> context?
>
> If you ask about vim scripting language, try ':help vim-script-intro'.
> If you ask about what meaning has each directory in ~/.vim/..., just try
> :help name_of_the_directory.
>
>
> > 2. Why was chosen scripting language  instead of object  oriented
> language?
>
> It is object oriented language. See the vim-script-howto help. If you
> compile vim with mzscheme, perl, python, tcl or ruby support, you can
> script vim in those languages. However usually everyone tends to use the
> native scripting I guess.
>
> Hope this helps
>
> --
>Vlad
>



-- 
Best regards,
Aram.

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Re: vim sources

[Vladimir Marek]

Hi,

> I'm new in this list, and new to vim sources. I have several questions. Can
> you please explain me or give me some link with explanation about
> 
> 1. Is there any documentation which explains .vim files and theirs context?

If you ask about vim scripting language, try ':help vim-script-intro'.
If you ask about what meaning has each directory in ~/.vim/..., just try
:help name_of_the_directory.


> 2. Why was chosen scripting language  instead of object  oriented language?

It is object oriented language. See the vim-script-howto help. If you
compile vim with mzscheme, perl, python, tcl or ruby support, you can
script vim in those languages. However usually everyone tends to use the
native scripting I guess.

Hope this helps

-- 
Vlad


pgpwsVysLPM8t.pgp
Description: PGP signature

vim sources

[Aram Antonyan]

Hello everyone,
I'm new in this list, and new to vim sources. I have several questions. Can
you please explain me or give me some link with explanation about

1. Is there any documentation which explains .vim files and theirs context?
2. Why was chosen scripting language  instead of object  oriented language?

Thanks,
-- 
Best regards,
Aram.

--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---

Vertical split issue

[Zdenek Sekera]

No problem when I try 'vim -O a b' this puts both files
side by side as it should.
I was surprised to see 'vim -O a a' (note the same file)
it doesn't put them in a split window. Is this expected?
On the other hand 

vim a
:vsp a   (inside vim)

will put correctly the same file 'a' side by side.

---Zdenek



smime.p7s
Description: S/MIME cryptographic signature