On Mon, 30 Dec 2002, Antoine J. Mechelynck wrote:

> If you want to have buffer 3 become buffer 1, a recent discussion in
> this ML told us, from highest authority :-), that it wasn't possible.
> Note that :ls doesn't show 'unlisted' buffers, but :ls! does. What you
> show means that initialization has opened three buffers and delisted
> or wiped the first two (or maybe opened more than three and delisted
> or wiped all of them except number 3).

Hi Antoine,

sorry for the delay! The buffers in question are wiped out afterwards,
thus they didn't show up in the buffer listing. (To create the buffer
listing I used ":ls!".)

> I wonder wat caused buffer 3 (the current [NoFile] buffer) to be
> marked as modified. To see where it comes from, it might be
> instructive to do
>
>         :verbose setlocal modified?
>
> in the buffer in question, with the question mark

I entered

           set nomodified
           verbose setlocal modified? (resp. set verbose=20)
           redir! > c:\vim\log

at the very bottom of the script, but 'log' didn't show any buffer
related information. The buffer in question however again has been
marked 'modified'.

In the meantime I found out that scripts residing in the plugin/
directory (it's the default collection) cannot be responsible for this.
So I'm looking for a new candidate now. ":scrip" told me that it might
be one of these: "filetype.vim", "menu.vim", "syntax.vim",
"synload.vim", "syncolor.vim", "mail.vim"

What do you think?

Klaus

Hi,

I'd like to find out how often a certain character shows up in a line.
To achieve this I tried

    fun! s:N()
      .s/x/&/ge
      return substitute(v:statusmsg, '^\(.\).*', '\1', '')
    endfun

but this didn't work. Obviously v:statusmsg sometimes isn't set. How can
I ensure v:statusmsg is set? Or maybe there's another solution too...

Thanks in advance!

Klaus

On Tue, 31 Dec 2002, Antoine J. Mechelynck wrote:

> Oops! 2nd byte is FA, not F0.

Hi Antoine,

the sequence in question showed up where (normal mode) keystrokes
normally are shown. Are there any commands which could have caused this?
"128" for instance... It denotes the symbol for the european monetary
unit. Isn't it unlikely that a normal mode command contains this
character?

Thanks,

Klaus

On Tue, 31 Dec 2002, Benji Fisher wrote:

> Klaus Bosau wrote:
>
> > [source'ing experiment]
> >
> > Now I'm wondering a bit if there might be something like an upper
> > limit on the amount of source'd material. What do you think?
>
> I suppose that is possible, but I still suspect some sort of conflict
> between the scripts. I would look closely at the parts of the two
> scripts that, when deleted, lead to a working system. Do things start
> working as soon as you delete ANY plugin (such as the standard ones,
> in $VIMRUNTIME/plugin/ )?

Yes. I have to ensure however that the size of the moved material is
about equal to the size of the initially moved plugin. - How large is
the amount of sourced material in your local environment, Benji? Do you
run plugins not shipped with Vim too? And if yes, which ones? (Sorry for
I'm asking so much questions...)

Thanks,

Klaus

Klaus Bosau <kbosau@...> wrote:
> On Mon, 30 Dec 2002, Antoine J. Mechelynck wrote:
[...]
> > I wonder wat caused buffer 3 (the current [NoFile] buffer) to be
> > marked as modified. To see where it comes from, it might be
> > instructive to do
> >
> >         :verbose setlocal modified?
> >
> > in the buffer in question, with the question mark
>
> I entered
>
>           set nomodified
>           verbose setlocal modified? (resp. set verbose=20)
>           redir! > c:\vim\log
>
> at the very bottom of the script, but 'log' didn't show any buffer
> related information. The buffer in question however again has been
> marked 'modified'.

I meant you to type :verbose setlocal modified? yourself as a Vim command,
not enter it into a script; and if you put it before the redir command, it
won't be redirected, but its output (if any) will appear on the
command-line. But apparently even if you get an answer it might be for a
different buffer.
>
> In the meantime I found out that scripts residing in the plugin/
> directory (it's the default collection) cannot be responsible for this.
> So I'm looking for a new candidate now. ":scrip" told me that it might
> be one of these: "filetype.vim", "menu.vim", "syntax.vim",
> "synload.vim", "syncolor.vim", "mail.vim"
>
> What do you think?
>
> Klaus

I'm not sure what I should think. Maybe there is something pertinent to your
case under :help local-options, just before the *:setl* helptag.

Tony.

Klaus Bosau <kbosau@...> wrote:
> On Tue, 31 Dec 2002, Antoine J. Mechelynck wrote:
>
> > Oops! 2nd byte is FA, not F0.
>
> Hi Antoine,
>
> the sequence in question showed up where (normal mode) keystrokes
> normally are shown. Are there any commands which could have caused this?
> "128" for instance... It denotes the symbol for the european monetary
> unit. Isn't it unlikely that a normal mode command contains this
> character?
>
> Thanks,
>
> Klaus

I'm still thinking of something nasty, stack overflow, buffer ovrerun, using
an uninitialized pointer, etc. That bytestring looked to me like an
out-of-contest snippet of program code, possibly for some Intel x86
platform, but too short to be easily understood. In that case your 128 would
be a 0x80 byte somewhere in an instruction, and it cannot be interpreted
without knowing at least where the (possibly multibyte) instruction starts.
And anyway once you start unintentionally handling program code as data, all
hell can break loose anytime.

Tony.

Benji Fisher <benji@...> wrote:
[...]
>       I am surprised that a file is not supposed to contain a raw
> "\xe4".  What is to stop me from doing
>
> > put=\"xe4\"
>
> --Benji Fisher

If your file is in UTF-8, then obviously it must obey UTF-8 encoding rules;
and these rules say (among other things) that:

     - Codepoints from 0000 to 007F are compatible with us-ascii and are
encoded as one byte, with high bit off
     - Codepoints from 0080 upwards are encoded as a string of 2 or more
bytes; the first of those is greater than 0xC0, the other(s) lie in the
range 0x80-0xBF. The number of highbits in the first byte determines the
number of following bytes

So there is a strict separation between single-bytes (0x00-0x7F),
first-bytes (0xC0-0xFF, and not all values in that range are legal) and
following-bytes (0x80-0xBF) to avoid context ambiguity.

Details can be found somewhere on the Unicode site, whose entry page is at
http://www.unicode.org/ . And don't forget that if 'encoding' is set to
utf-8, then all files will be internally represented as UTF-8 while editing,
with translation when reading or writing non-UTF-8 files. So typing (in
Insert mode) Ctrl-V followed by xE4 will enter the 00E4 codepoint into
memory as two bytes, 0xC3 0xA4, but show it as one character, small a with
umlaut; and pressing x once in Normal mode with the cursor on that
chatracter deletes both bytes.

HTH,
Tony.

Bram Moolenaar <Bram@...> wrote:
> Michael Keightley wrote:
>
> > When I start the version of Vim that comes with Red Hat 7.X or 8.0,
> > the cursor is placed on the same line as when I lasted edited the
> > file.  I've compiled up Vim 6.1 or Red Hat 7.1 and Solaris 2.6, but I
> > don't get this behaviour.  The cursor is always at the top of the file
> > when I start Vim.  My .vimrc is the same in both cases.  Is this a
> > compile time option, or is there something in /usr/share/vim on Red
> > Hat that does this?
>
> This must be something in the Red Hat startup script.  Look for the
> "system vimrc file" line in the output of the ":version" command.
>
[...]

Couldn't it just be the f or ' suboption in the 'viminfo' option? (see :help
'viminfo') If f is absent or nonzero, then marks, *including cursor
position,* are saved for all files. If present and zero, marks and cursor
position are not saved. The number of files for which marks (and cursor
position) are remembered is set by the ' (apostrophe) suboption. Check it
with :set viminfo?, check where it was set (latest) by :verbose set viminfo?

HTH,
Tony.

Klaus Bosau <kbosau@...> wrote:
> Hi,
>
> I'd like to find out how often a certain character shows up in a line.
> To achieve this I tried
>
>    fun! s:N()
>      .s/x/&/ge
>      return substitute(v:statusmsg, '^\(.\).*', '\1', '')
>    endfun
>
> but this didn't work. Obviously v:statusmsg sometimes isn't set. How can
> I ensure v:statusmsg is set? Or maybe there's another solution too...
>
> Thanks in advance!
>
> Klaus

you might set it yourself, e.g.

function!...
     let v:statusmsg = ""
     .s/ etc.

HTH,
Tony.

Benji Fisher wrote:

>       Thanks for the reply.  This has been bothering me for a while, and
> I do not think anyone else can help with it.
>
>       The problem is not caused by changing 'encoding' after assigning
> the variable.  I can try
>
>  :set encoding?
>  utf-8
>  :let foo = "\xab"
>  :echo foo =~ foo
>  0
>
>       I would like to have a script insert a character like the one
> given by the digraph "<C-K><<".  According to "ga" (Normal mode) this
> character has code 0xab , so I try
>
>  :let foo = "\xab"
>  :put=foo
>
> and this inserts a single character that looks like "<ab>".  Then I try
>
>  :let foo = iconv("\xab", "latin1", &enc)
>  :put=foo
>
> and I get the "<<" digraph.  Strangely, "ga" tells me these are both
> "Hex 00ab".
>
>       Are the tricks with iconv() supposed to work?  Is there a simpler way?

"ga" shows the ascii value, but it doesn't handle an illegal byte
differently, thus a single "ab" byte will show "00ab" and the two-byte
UTF-8 sequence for the "ab" character will also show "ab".  "g8" shows
what's really there.

We need something to include a character by its hex value in a string.
I first thought of changing "\x" for that, but this would make it
impossible to create specific byte sequences.  Let's add the "\u" item
for this.  Try the patch below.  Your example should now become:

 	 :let foo = "\uab"

*** ../vim61.267/src/eval.c Mon Dec 23 22:54:36 2002
--- src/eval.c Wed Jan  1 12:41:16 2003
***************
*** 2219,2236 ****
  		 case 'r': name[i++] = CR; break;
  		 case 't': name[i++] = TAB; break;

! 			  /* hex: "\x1", "\x12" */
! 	 case 'X':
! 	 case 'x': if (isxdigit(p[1]))
  			   {
! 			      ++p;
! 			      name[i] = hex2nr(*p);
! 			      if (isxdigit(p[1]))
  			       {
  				   ++p;
! 				  name[i] = (name[i] << 4) + hex2nr(*p);
  			       }
! 			      ++i;
  			   }
  			   else
  			       name[i++] = *p;
--- 2219,2251 ----
  		 case 'r': name[i++] = CR; break;
  		 case 't': name[i++] = TAB; break;

! 	 case 'X': /* hex: "\x1", "\x12" */
! 	 case 'x':
! 	 case 'u': /* Unicode: "\u0023" */
! 	 case 'U':
! 			  if (isxdigit(p[1]))
  			   {
! 			      int n, nr;
! 			      int c = toupper(*p);
!
! 			      if (c == 'X')
! 				  n = 2;
! 			      else
! 				  n = 4;
! 			      nr = 0;
! 			      while (--n >= 0 && isxdigit(p[1]))
  			       {
  				   ++p;
! 				  nr = (nr << 4) + hex2nr(*p);
  			       }
! #ifdef FEAT_MBYTE
! 			      /* For "\u" store the number according to
! 			       * 'encoding'. */
! 			      if (c != 'X')
! 				  i += (*mb_char2bytes)(nr, name + i);
! 			      else
! #endif
! 				  name[i++] = nr;
  			   }
  			   else
  			       name[i++] = *p;

--
hundred-and-one symptoms of being an internet addict:
264. You turn to the teletext page "surfing report" and are surprised that it
      is about sizes of waves and a weather forecast for seaside resorts.

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
///          Creator of Vim - Vi IMproved -- http://www.vim.org          \\\
\\\           Project leader for A-A-P -- http://www.a-a-p.org           ///
  \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///

Klaus Bosau wrote:
> On Tue, 31 Dec 2002, Benji Fisher wrote:
>
>
>>Klaus Bosau wrote:
>>
>>
>>>[source'ing experiment]
>>>
>>>Now I'm wondering a bit if there might be something like an upper
>>>limit on the amount of source'd material. What do you think?
>>
>>I suppose that is possible, but I still suspect some sort of conflict
>>between the scripts. I would look closely at the parts of the two
>>scripts that, when deleted, lead to a working system. Do things start
>>working as soon as you delete ANY plugin (such as the standard ones,
>>in $VIMRUNTIME/plugin/ )?
>
>
> Yes. I have to ensure however that the size of the moved material is
> about equal to the size of the initially moved plugin. - How large is
> the amount of sourced material in your local environment, Benji? Do you
> run plugins not shipped with Vim too? And if yes, which ones? (Sorry for
> I'm asking so much questions...)

       Since your answer is "yes," I am coming around to your point of
view.  I do not use all that many plugins.  I do use the LaTeX suite,
http://www.vim.org/script.php?script_id=475
and $VIMRUNTIME/macros/matchit.vim .

       What is your OS?  How many plugins (in KB, say) do you use?  If it
really is an out-of-memory problem, it should be possible to reproduce
with your testmenu.vim and enough dummy functions (defined but not
invoked) of the form

fun! Dummy1()
    echo "This is dummy function #1."
    let foo = 1
    let bar = 2
    if foo == bar
      echo "Problems have started!"
    endif
endfun

How many does it take?

HTH 			 --Benji Fisher

Antoine J. Mechelynck wrote:
> Benji Fisher <benji@...> wrote:
> [...]
>
>>      I am surprised that a file is not supposed to contain a raw
>>"\xe4".  What is to stop me from doing
>>
>>
>>>put=\"xe4\"
>>
>>--Benji Fisher
>
>
> If your file is in UTF-8, then obviously it must obey UTF-8 encoding rules;
> and these rules say (among other things) that:
>
>     - Codepoints from 0000 to 007F are compatible with us-ascii and are
> encoded as one byte, with high bit off
>     - Codepoints from 0080 upwards are encoded as a string of 2 or more
> bytes; the first of those is greater than 0xC0, the other(s) lie in the
> range 0x80-0xBF. The number of highbits in the first byte determines the
> number of following bytes
>
> So there is a strict separation between single-bytes (0x00-0x7F),
> first-bytes (0xC0-0xFF, and not all values in that range are legal) and
> following-bytes (0x80-0xBF) to avoid context ambiguity.
>
> Details can be found somewhere on the Unicode site, whose entry page is at
> http://www.unicode.org/ . And don't forget that if 'encoding' is set to
> utf-8, then all files will be internally represented as UTF-8 while editing,
> with translation when reading or writing non-UTF-8 files. So typing (in
> Insert mode) Ctrl-V followed by xE4 will enter the 00E4 codepoint into
> memory as two bytes, 0xC3 0xA4, but show it as one character, small a with
> umlaut; and pressing x once in Normal mode with the cursor on that
> chatracter deletes both bytes.

       Thanks for the details.  That's already more than I think I need
to know (for now) so I am not going to follow the link.

       Perhaps my :put command should also insert the 00E4 codepoint, the
same as <C-V>xE4 in Insert mode.
<later>
On another thread (multibyte in patterns) Bram suggests a new "\uab"
instead of "\xab".  Maybe that is the way to go...

					 --Benji Fisher

Bram Moolenaar wrote:
> Benji Fisher wrote:
>
>
>>      Thanks for the reply.  This has been bothering me for a while, and
>>I do not think anyone else can help with it.
>>
>>      The problem is not caused by changing 'encoding' after assigning
>>the variable.  I can try
>>
>> :set encoding?
>> utf-8
>> :let foo = "\xab"
>> :echo foo =~ foo
>> 0
>>
>>      I would like to have a script insert a character like the one
>>given by the digraph "<C-K><<".  According to "ga" (Normal mode) this
>>character has code 0xab , so I try
>>
>> :let foo = "\xab"
>> :put=foo
>>
>>and this inserts a single character that looks like "<ab>".  Then I try
>>
>> :let foo = iconv("\xab", "latin1", &enc)
>> :put=foo
>>
>>and I get the "<<" digraph.  Strangely, "ga" tells me these are both
>>"Hex 00ab".
>>
>>      Are the tricks with iconv() supposed to work?  Is there a simpler way?
>
>
> "ga" shows the ascii value, but it doesn't handle an illegal byte
> differently, thus a single "ab" byte will show "00ab" and the two-byte
> UTF-8 sequence for the "ab" character will also show "ab".  "g8" shows
> what's really there.

       Thanks.  That works.

> We need something to include a character by its hex value in a string.
> I first thought of changing "\x" for that, but this would make it
> impossible to create specific byte sequences.  Let's add the "\u" item
> for this.  Try the patch below.  Your example should now become:
>
>   :let foo = "\uab"
[patch snipped]

       I tried this:

:let foo = "\uab"
:let bar = "\xab"
:echo foo bar
« <ab>
:echo foo == bar
0
:echo foo =~ "^" . bar . "$"
1
:echo foo =~ "^" . foo . "$"
1
echo foo == iconv(bar, "latin1", &enc)
1

so it looks pretty good to me.  The second =~ test is a little strange,
but should probably work this way for backward compatibility.

       On the question of changing "\x" or adding "\u":
* Since vim is a *text* editor, I am not convinced that it should be
able to enter invalid bytes into my document.  (I admit that
:put=\"xe4\" does not count as entering a character *easily*.)  Perhaps
it would be better to make "\x" act like the new "\u" after all.
* By habit and because of legacy scripts, people will continue to use
"\x".  I assume that the new "\u" will be recommended for most purposes
(and the docs will mention this).  It will take a while for people to
adjust.  Again, this argues for using "\x" to insert valid bytes, and
adding a new construct for arbitrary bytes.

       Final question:  I want my script to be able to insert "«" without
forcing users to adopt the latest patched vim.  (I am thinking of the
LaTeX suite.)  Instead of

:let foo = "\uab"

with this patch, should

:let foo = iconv("\xab", "latin1", &enc)

have the same effect?  It seems to work, as far as I can tell.

					 --Benji Fisher

Klaus Bosau wrote:
> Hi,
>
> I'd like to find out how often a certain character shows up in a line.
> To achieve this I tried
>
>    fun! s:N()
>      .s/x/&/ge
>      return substitute(v:statusmsg, '^\(.\).*', '\1', '')
>    endfun
>
> but this didn't work. Obviously v:statusmsg sometimes isn't set. How can
> I ensure v:statusmsg is set? Or maybe there's another solution too...

:help 'report'
e +/Count $VIMRUNTIME/macros/matchit.vim

HTH 			 --Benj Fisher

Benji Fisher <benji@...> wrote:
[...]
>       Perhaps my :put command should also insert the 00E4 codepoint, the
> same as <C-V>xE4 in Insert mode.

That would, if done correctly, avoid putting invalid byte-sequences into
UTF-8 files.

> <later>
> On another thread (multibyte in patterns) Bram suggests a new "\uab"
> instead of "\xab".  Maybe that is the way to go...

I saw that message from Bram, and noticed a patch that went with it. I think
it's a good idea; but since I lack a vim-compile facility, I shall wait
until it is incorporated into a (supposedly stable) binary distribution. (At
the moment I am using gvim 6.1.243 +win32 +ole.)

>
> --Benji Fisher

Tony.

Benji Fisher <benji@...> wrote:
[...]
>       On the question of changing "\x" or adding "\u":
> * Since vim is a *text* editor, I am not convinced that it should be
> able to enter invalid bytes into my document.  (I admit that
> > put=\"xe4\" does not count as entering a character *easily*.)  Perhaps
> it would be better to make "\x" act like the new "\u" after all.
> * By habit and because of legacy scripts, people will continue to use
> "\x".  I assume that the new "\u" will be recommended for most purposes
> (and the docs will mention this).  It will take a while for people to
> adjust.  Again, this argues for using "\x" to insert valid bytes, and
> adding a new construct for arbitrary bytes.

Personally I am partisan of leaving the existing \x unchanged on
compatibility grounds. Giving a new meaning (insert Unicode codepoint) to a
hitherto undefined sequence should IMHO create less problems.

>
>       Final question:  I want my script to be able to insert "«" without
> forcing users to adopt the latest patched vim.  (I am thinking of the
> LaTeX suite.)  Instead of
>
> > let foo = "\uab"
>
> with this patch, should
>
> > let foo = iconv("\xab", "latin1", &enc)
>
> have the same effect?  It seems to work, as far as I can tell.

have you tried it with encodings for which there is no equivalent for that
latin-1 character? (Iconv fails: what happens then?)

>
> --Benji Fisher

Best wishes -- and a happy New Year
Tony.

Benji Fisher wrote:

> so it looks pretty good to me.  The second =~ test is a little strange,
> but should probably work this way for backward compatibility.

Thanks for testing.  It's a matter of taste whether foo =~ bar should
result in TRUE of FALSE.  Let's just leave it as it is until someone has
a good reason why it should be different.

>       On the question of changing "\x" or adding "\u":
> * Since vim is a *text* editor, I am not convinced that it should be
> able to enter invalid bytes into my document.  (I admit that
> :put=\"xe4\" does not count as entering a character *easily*.)  Perhaps
> it would be better to make "\x" act like the new "\u" after all.

There are always exceptions, e.g. when 'encoding' is not properly set or
when intentionally creating illegal bytes.  I don't think we have a good
reason to forbid inserting any byte value.

> * By habit and because of legacy scripts, people will continue to use
> "\x".  I assume that the new "\u" will be recommended for most purposes
> (and the docs will mention this).  It will take a while for people to
> adjust.  Again, this argues for using "\x" to insert valid bytes, and
> adding a new construct for arbitrary bytes.

Existing scripts that use "\xab" to insert valid UTF-8 bytes should keep
on working, that's another reason why changing the meaning of "\xab" is
a bad idea.

>       Final question:  I want my script to be able to insert "«" without
> forcing users to adopt the latest patched vim.  (I am thinking of the
> LaTeX suite.)  Instead of
>
> :let foo = "\uab"
>
> with this patch, should
>
> :let foo = iconv("\xab", "latin1", &enc)
>
> have the same effect?  It seems to work, as far as I can tell.

If iconv() is supported it should work.  So long as 'encoding' does
support a character to represent the latin1 "\xab" character (not all
8-bit encodings have it).

--
hundred-and-one symptoms of being an internet addict:
269. You receive an e-mail from the wife of a deceased president, offering
      to send you twenty million dollar, and you are not even surprised.

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
///          Creator of Vim - Vi IMproved -- http://www.vim.org          \\\
\\\           Project leader for A-A-P -- http://www.a-a-p.org           ///
  \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///

Antoine J. Mechelynck wrote:
> Benji Fisher <benji@...> wrote:
>>      Final question:  I want my script to be able to insert "«" without
>>forcing users to adopt the latest patched vim.  (I am thinking of the
>>LaTeX suite.)  Instead of
>>
>>
>>>let foo = "\uab"
>>
>>with this patch, should
>>
>>
>>>let foo = iconv("\xab", "latin1", &enc)
>>
>>have the same effect?  It seems to work, as far as I can tell.
>
>
> have you tried it with encodings for which there is no equivalent for that
> latin-1 character? (Iconv fails: what happens then?)

       No, I have only tried it with utf-8 and latin1.  What other
encodings should I try?

> Best wishes -- and a happy New Year
> Tony.

       Thanks!

					 --Benji Fisher

Benji Fisher <benji@...> wrote:
> Antoine J. Mechelynck wrote:
[...]
> > have you tried it with encodings for which there is no equivalent for
> > that latin-1 character? (Iconv fails: what happens then?)
>
>       No, I have only tried it with utf-8 and latin1.  What other
> encodings should I try?

As many as possible, of course; but this is not really an answer. Maybe you
could start, if you have them, with Central-European and Turkish encodings,
then if it works OK, with more esoteric ones like Greek, Cyrillic, Big5,
sjis, euc-kr,... and wouldn't digraphs << and >> need to be switched around
for right-to-left languages like Hebrew, Farsi and Arabic? -- As you see,
I'm thinking of what the plugin would need to be as general as possible, for
as many users as possible. Also, as could be inferred from Bram's post of a
few minutes ago, mybe there ought to be a fallback if iconv() fails for any
reason, and in particular for if ! has("iconv")...

Tony.

>
> > Best wishes -- and a happy New Year
> > Tony.
>
>       Thanks!
>
> --Benji Fisher

I am not sure if this message found its way to the list:

> I know this is possible to complete arguments of user command with
> files (-complete=file). But is it possible to make it complete only
> files in specific directory?
> Normally it is done with current directory.
> Mikolaj

If I type "yy" I yank one line. If I type "1y" I get no lines. If I
type "2y" I yank three lines.

So how does one yank exactly 2 lines?
--

John Culleton
Able Indexers and Typesetters
Rowse Reviews
Culleton Editorial Services
http://wexfordpress.com

John Culleton <john@...> wrote:
> If I type "yy" I yank one line. If I type "1y" I get no lines. If I
> type "2y" I yank three lines.
>
> So how does one yank exactly 2 lines?
> --
>
> John Culleton
> Able Indexers and Typesetters
> Rowse Reviews
> Culleton Editorial Services
> http://wexfordpress.com

In normal mode, if I type yy I yank one line, if I type 2y I am still in
operator-pending mode (waiting for entry of an object or motion), and if I
type 2yy (with at least one line below the cursor line) I yank two lines
(the one at the cursor and the one below). I'm not sure what 1y does. Done
it (2yy) lots of times.

Tony.

On Wed, 1 Jan 2003, Antoine J. Mechelynck wrote:

> I meant you to type :verbose setlocal modified? yourself as a Vim
> command, not enter it into a script;

Sorry, maybe I misunderstood. I thought you wanted me to trace what
happens after the script referred to is done.

> and if you put it before the redir command, it won't be redirected,
> but its output (if any) will appear on the command-line.

Of course you're right. Must have messed it up when writing it down
again. I took a look a few moments ago but the script showed me the
right order... Sorry!

> But apparently even if you get an answer it might be for a different
> buffer.

Well, I was interested in any kind of information related to this also
cause I realized that restricting the answer on buffer related topics
might be too strong.

> I'm not sure what I should think. Maybe there is something pertinent
> to your case under :help local-options, just before the *:setl*
> helptag.

Thanks! I'll take a look...

Klaus

On Wed, 1 Jan 2003, Benji Fisher wrote:

>       Since your answer is "yes," I am coming around to your point of
> view.  I do not use all that many plugins.  I do use the LaTeX suite,
> http://www.vim.org/script.php?script_id=475
> and $VIMRUNTIME/macros/matchit.vim .

152kB and 34 kB? You're at the edge... ;-)

> What is your OS?

W98 (here)

> How many plugins (in KB, say) do you use?

About 160 kB.

> If it really is an out-of-memory problem, it should be possible to
> reproduce with your testmenu.vim and enough dummy functions (defined
> but not invoked) of the form
>
> fun! Dummy1()
>    echo "This is dummy function #1."
>    let foo = 1
>    let bar = 2
>    if foo == bar
>      echo "Problems have started!"
>    endif
> endfun
>
> How many does it take?

I did a somehow radical experiment with 39179 Dummies (including me)
resp. 5.7 MB of source'd material. This made Vim go crazy a bit. ;-)
Looks not so bad though, but of course this might become easier as soon
as the structures become more complicated. (I actually don't think that
it is a simple allocation problem.) Keep in mind too, the script
referred to didn't contain any active parts as the menu problem showed
up. (It has not yet been started!) Which kind of interference could have
taken place here?

Kind regards,

Klaus

On Wed, 1 Jan 2003, Benji Fisher wrote:

> :help 'report'
> e +/Count $VIMRUNTIME/macros/matchit.vim

Thanks a lot! I turned it in

     fun! s:N()
       let &report=0
       .s/x/&/ge
       return substitute(v:statusmsg, '^\(.\).*', '\1', '')
     endfun

but this seems to work properly only if typed by hand. When put in a
function body v:statusmsg still is not set reliably. The 'matchit'
solution turned out to be quite similiar to the solution I already
found, but due to that this seems to become a bit slow with large
strings I'd actually prefer a working solution based on :s. I wished I'd
know why v:statusmsg isn't set always...

Thanks anyway!

Klaus

On Wed, 1 Jan 2003, Antoine J. Mechelynck wrote:

> you might set it yourself, e.g.
>
> function!...
>     let v:statusmsg = ""
>     .s/ etc.

Hi,

and thanks! I already tried this, but obviously it sometimes isn't set
by :s. I don't know why...

Thanks,

Klaus

I use "yj".

Steve

On Wed, 2003-01-01 at 09:52, John Culleton wrote:
> If I type "yy" I yank one line. If I type "1y" I get no lines. If I
> type "2y" I yank three lines.
>
> So how does one yank exactly 2 lines?
--
Steven Tryon
stryon@...
ICQ 102798975

John Culleton wrote:
> If I type "yy" I yank one line. If I type "1y" I get no lines. If I
> type "2y" I yank three lines.
>
> So how does one yank exactly 2 lines?

2yy,

or am I missing something? :)

Andreas

--
Andreas Schlapbach      schlpbch@...
http://www.iam.unibe.ch/~schlpbch

Hi all,

I have uploaded a Vim plugin (mru.vim) to the Vim online website.
You can download the plugin from:

http://vim.sourceforge.net/script.php?script_id=521

You can use this plugin to access recently opened/used files in
Vim. This plugin can be used from both console and GUI Vim.
This plugin can be used in all the platforms where Vim is
supported.

- Yegappan


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Hi all,
	 I have 2 problems.

1. I have 2 files foo and bar with a word on each line.
foo -> 5000 words
bar -> 2300 words.
Now I want to *find all the words in bar that are missing in foo* and
put them in 3rd file foo.bar.
( So, foo.bar will have a maximum of 2300 words. )
(both the files are sorted)
Please remember I don't want words unique to file foo. I want words in
bar which are not in foo.

2. In another file, I have few lines seperated by a single tab. Now I
want to delete all the lines ( and NOT just the tab ) which start with
a tab. I tried :1,$/^^I/d but managed to delete just one line at a time.
Can someone help me on this?

Thanks a lot for the help in advance and bye.
With warm regards,
-Payal


--
Payal Rathod    <payal at hotpop.com>
"Visit Linux Success Stories"
www.geocities.com/rpayal99