Gabriel Zachmann wrote:
>
> I would like to ask for a slight modification of what `` does in vim.
> Right now, it jumps back to the former position,
> and it places the new current line usually in the center of the window.
>
> However, I think it would make sense to place the new current line
> at the same position within the window where it was before.
>

Having observed the same problem I can only agree with Gabriel's
suggestion. I think it would make sense.

---Zdenek

* Arnaud Launay <alaunay@...> [000205 22:26]:
> Le Fri, Feb 04, 2000 at 05:56:16PM +0100, Bram Moolenaar a écrit:
> > More info on the Beanie Awards at http//www.slasdot.org.
>
> cassis:~$ nslookup www.slasdot.org
> *** citron.launay.org can't find www.slasdot.org: Non-existent host/domain
>
> Bram, just to know, could you please enumerate what you drink ? :)

Actually, it was me who sent the message.  And
the URL is http://www.slashdot.org, of course.

Sven

> -----Original Message-----
> From: Sven Guckes [mailto:guckes@...]
> Sent: Tuesday, February 08, 2000 8:15 AM
> To: Vim Developers
> Subject: Re: Vim gets Beanie Award! -> www.slashdot.org
>
>
> * Arnaud Launay <alaunay@...> [000205 22:26]:
> > Le Fri, Feb 04, 2000 at 05:56:16PM +0100, Bram Moolenaar a écrit:
> > > More info on the Beanie Awards at http//www.slasdot.org.
> >
> > cassis:~$ nslookup www.slasdot.org
> > *** citron.launay.org can't find www.slasdot.org:
> Non-existent host/domain
> >
> > Bram, just to know, could you please enumerate what you drink ? :)
>
> Actually, it was me who sent the message.  And
> the URL is http://www.slashdot.org, of course.
For slashdot non-regulars (like me) you can also check out the article:
http://slashdot.org/articles/00/02/06/1950248.shtml

-Doug

--
  Appl. Product Development S/W Engineer, Dispensing Group FANUC Robotics,
NA.
  Douglas L. Potts   Phone: 248-377-7990    E-mail: pottsdl@...
*Top 20 Replies by Programmers when their programs do not work*
  1. I thought I fixed that.

Matthias wrote:
> This is a first version of the "Virtual Editing" mentioned in the
"Wishes"-
> section of the homepage.

Has anyone tried this?
A couple of points:
1) the 'diff' has been done in reverse, so that added lines appear with a -
and deleted lines with a +
2) Something's gone wrong in changing #ifdef MULTI_BYTE to #ifdef multi_byte
etc.

I applied the patch by hand, and tidied up the code to follow the Vim coding
style etc.

Seems to work OK so far..

Would anyone like me to post the cleaned-up patch?

Vince


Legal Disclaimer: Any views expressed by the sender of this message are
not necessarily those of Application Solutions Ltd. Information in this
e-mail may be confidential and is for the use of the intended recipient
only, no mistake in transmission is intended to waive or compromise such
privilege. Please advise the sender if you receive this e-mail by mistake.

On Tue, 8 Feb 2000, Vince Negri wrote:

> Matthias wrote:
> > This is a first version of the "Virtual Editing" mentioned in the
> "Wishes"-
> > section of the homepage.
>
> Has anyone tried this?
> A couple of points:
> 1) the 'diff' has been done in reverse, so that added lines appear with a -
> and deleted lines with a +
> 2) Something's gone wrong in changing #ifdef MULTI_BYTE to #ifdef multi_byte
> etc.
>
> I applied the patch by hand, and tidied up the code to follow the Vim coding
> style etc.
>
> Seems to work OK so far..
>
> Would anyone like me to post the cleaned-up patch?

I didn't find an explanation in the original patch posting about
what `virtual editing' is. Just had a look at the wishlist, but
the explanation there does not tell me what this feature could
be used for. Can anybody give me some help ?
Sorry if I didn't follow up the discussion.

--
    Johannes

> Johannes Zellner understandably asked:
>
> I didn't find an explanation in the original patch posting about
> what `virtual editing' is. Just had a look at the wishlist, but
> the explanation there does not tell me what this feature could
> be used for. Can anybody give me some help ?
> Sorry if I didn't follow up the discussion.

It allows the cursor to be placed beyond the end of a line. If while in this
position, you start insert mode, enough spaces are added to the end of the
line to
keep the cursor in the right position. Many editors behave in this way
(Multi-edit, DevStudio)

Vince


Legal Disclaimer: Any views expressed by the sender of this message are
not necessarily those of Application Solutions Ltd. Information in this
e-mail may be confidential and is for the use of the intended recipient
only, no mistake in transmission is intended to waive or compromise such
privilege. Please advise the sender if you receive this e-mail by mistake.

Vince Negri wrote:
> Matthias wrote:
> > This is a first version of the "Virtual Editing" mentioned in the
> "Wishes"-
> > section of the homepage.
>
> I applied the patch by hand, and tidied up the code to follow the Vim coding
> style etc.
>
> Seems to work OK so far..
>
> Would anyone like me to post the cleaned-up patch?
>

Yes, please do.

Bram, could this (or similar feature) be included in vim 6 ?
Please, this will eliminate one of the few things in vim that really
annoy me sometimes.

Best regards,
Artem.

Artem Hodyush wrote:
> Bram, could this (or similar feature) be included in vim 6 ?
> Please, this will eliminate one of the few things in vim that really
> annoy me sometimes.

Intreguing. I find that feature very annoying. I sure hope if it's included in
VIM 6 that you can turn it off.

--
Oh, I've seen copies [of Linux Journal] around the terminal room at The Labs.
	 -- Dennis Ritchie

Matthias Kramm wrote:

> This is a first version of the "Virtual Editing" mentioned in the "Wishes"-
> section of the homepage.
>
> Patch included, basing on VIM 5.6 .

Perhaps if there was documentation it would be clear what this does...

Anyway, I don't intend to add "Virtual Editing" (moving the cursor beyond the
end of the line).  It will cause many problems, and it is very un-vi-ish.
Except perhaps in Visual Block mode, where it's useful.

--
So when I saw the post to comp.editors, I rushed over to the FTP site to
grab it.  So I yank apart the tarball, light x candles, where x= the
vim version multiplied by the md5sum of the source divided by the MAC of
my NIC (8A3FA78155A8A1D346C3C4A), put on black robes, dim the lights,
wave a dead chicken over the hard drive, and summon the power of GNU GCC
with the magic words "make config ; make!".
		 [Jason Spence, compiling Vim 5.0]

/-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
\ \   Vim: http://www.vim.org      ICCF Holland: http://www.vim.org/iccf   / /

From: Vince Negri [mailto:vnegri@...]
>
> It allows the cursor to be placed beyond the end of a line. If while in this
> position, you start insert mode, enough spaces are added to the end of the
> line to
> keep the cursor in the right position. Many editors behave in this way
> (Multi-edit, DevStudio)

I didn't look too closely at the patch, but there is an obvious question: has it
been implemented as an option? For 99% of my work, I would definitely *not* want
this on. (For the other 1%, it would be very useful, though, so this isn't a
vote against the feature!)

I guess if you post the cleaned up patch, I'll try it out.

Paul.

Arnaud Launay wrote:

> Le Fri, Feb 04, 2000 at 05:56:16PM +0100, Bram Moolenaar a écrit:
> > More info on the Beanie Awards at http//www.slasdot.org.
>
> cassis:~$ nslookup www.slasdot.org
> *** citron.launay.org can't find www.slasdot.org: Non-existent host/domain

Those guys prefer http://slashdot.org/, without the "www".
Should still work with the "www" though.  Perhaps the site was down for a
moment.

> Bram, just to know, could you please enumerate what you drink ? :)

No, that list would be too long!

--
A law to reduce crime states: "It is mandatory for a motorist with criminal
intentions to stop at the city limits and telephone the chief of police as he
is entering the town.
		 [real standing law in Washington, United States of America]

/-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
\ \   Vim: http://www.vim.org      ICCF Holland: http://www.vim.org/iccf   / /

Robert E. Minsk wrote:

>   I have written several syntax files I would like to contribute to the vim
> source but I do not have much time to maintain them.  How should I go about
> submitting them?

Well, I only include syntax files when there is a maintainer.  Otherwise they
will get outdated or known bugs are not fixed.  Maintenance doesn't take much
time though (unless it's a popular and complicated syntax, like Perl).

--
SIGIRO -- irony detected (iron core dumped)

/-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
\ \   Vim: http://www.vim.org      ICCF Holland: http://www.vim.org/iccf   / /

Arnaud Launay wrote:

> [back to the real discussion]
> Seems like having # lines treated as comments should be fine for
> sysadmins like johannes and me -- not for programmers. What about
> having a variable like "sys" and "prog" which control those
> things out ? in sys mode, # are comments, not in prog.. hm,
> stupid idea.
> What about having # comments when files are located under /etc,
> /usr/etc, etc. ?

Still a large chance of getting the wrong highlighting.  And it's easy to add
yourself if you really want it:

	 au BufNewFile,BufReadPost /etc/*,/usr/etc/* set ft=config

> Another small thing: /etc/bashrc isn't recognize by default as a
> sh file. Could you add /etc/bashrc near /etc/profile in
> filetype.vim ? Also, /etc/inputrc, used for key encodings by the
> readline lib.

I'll add "bashrc".  I assume the directory doesn't really matter.
What language is "inputrc"?  sh, csh, zsh?

--
Lawmakers made it obligatory for everybody to take at least one bath
each week -- on Saturday night.
		 [real standing law in Vermont, United States of America]

/-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
\ \   Vim: http://www.vim.org      ICCF Holland: http://www.vim.org/iccf   / /

On Tue, 8 Feb 2000, Bram Moolenaar wrote:

[...]
> I'll add "bashrc".  I assume the directory doesn't really matter.
> What language is "inputrc"?  sh, csh, zsh?
[...]
actually none of these. inputrc is the description file for
gnu readline and has it's own syntax. My opinion is still
that it would be sufficient to have a syntax file which
highlights lines beginning with a `#' mark as comments.
Or do you really want to have a syntax file for each of
these configuration files ?

I just had a look at my home directory

Files which would be ok with a `#' triggering a comment:
~/.inputrc
~/.faxdir
~/.enscriptrc
~/.lynxrc
~/.lynx/lynx.cfg
~/.mailcap
~/.mime.types
~/.telnetrc
~/.wgetrc


Files which would be ok with a `;' triggering a comment:
~/.kermrc


I also would add
~/.bash_history [sh]
~/.gdb_history  [gdb]
~/.gnuplot*     [gnuplot] (this includes ~/.gnuplot_history)
~/.gv           [xdefaults]
~/.history      [csh]
~/.tidyrc       [cpp]


I (and maybe most of the people reading this list) know well how
to set the stuff up for me, how to use autocommands and howto write
a syntax file which does the job. But 99.9% of the users won't write
their own syntax files. That's why I proposed (28. Jan) to have a
global variable g:enable_system_scripts which enables syntax coloring
with a generic shell like comment syntax file. This way the options
is *off by default*. What is wrong with this ? -- If the usage of
this variable would be documented, the user could use it, beeing
aware of the risk that files get colored false. And users *would*
use this more likely than starting to write their own syntax files.


--
    Johannes

> I applied the patch by hand, and tidied up the code to follow the Vim
coding
> style etc.

What exactly is the Vim coding style? I'm working on something right now,
and can only apply style by example (of other source files).

Is there something somewhere which says anything? At my company, we have
pretty strict rules (columns <= 80, etc etc).

Tim

>
> Seems to work OK so far..
>
> Would anyone like me to post the cleaned-up patch?
>
> Vince
>
>
> Legal Disclaimer: Any views expressed by the sender of this message are
> not necessarily those of Application Solutions Ltd. Information in this
> e-mail may be confidential and is for the use of the intended recipient
> only, no mistake in transmission is intended to waive or compromise such
> privilege. Please advise the sender if you receive this e-mail by mistake.
>
>

Paul Moore wrote:
>
> From: Vince Negri [mailto:vnegri@...]
> >
> > It allows the cursor to be placed beyond the end of a line. If while in this
> > position, you start insert mode, enough spaces are added to the end of the
> > line to
> > keep the cursor in the right position. Many editors behave in this way
> > (Multi-edit, DevStudio)
>
> I didn't look too closely at the patch, but there is an obvious question: has
it
> been implemented as an option? For 99% of my work, I would definitely *not*
want
> this on. (For the other 1%, it would be very useful, though, so this isn't a
> vote against the feature!)
>

Likewise. This should be an option but I'd like to have it.

---Zdenek

> > 1) the 'diff' has been done in reverse, so that added lines appear with
a -
> > > and deleted lines with a +
>
> True.
> 'patch' should detect this, though, and ask for a "assume -R"
automatically.

Yeeess... but it isn't "polite" to ask patch to do all the work! ;)
> > Would anyone like me to post the cleaned-up patch?

> Could you mail it? I'd like to do some improvements.
Yes, and for everyone else who asked.

BTW, Devin & Paul, it _Is_ an option, an it's off by default. :-)

option is called 'virtualedit', short form 've'

>  <<all.diff.gz>>
Legal Disclaimer: Any views expressed by the sender of this message are
not necessarily those of Application Solutions Ltd. Information in this
e-mail may be confidential and is for the use of the intended recipient
only, no mistake in transmission is intended to waive or compromise such
privilege. Please advise the sender if you receive this e-mail by mistake.

> Tim (the man with no surname :) wrote -
>
> What exactly is the Vim coding style? I'm working on something right now,
> and can only apply style by example (of other source files).

> Is there something somewhere which says anything? At my company, we have
> pretty strict rules (columns <= 80, etc etc).

I thought there used to be a file called STYLE in the src
distribution, but I can't find it now...?

Anyway, the existing code (esp if you keep to the machine-independent
parts) gives a fairly clear indication. The main points
are to use old-style function declarations in the MI code
(some people build vim on ancient pre-ANSI compilers)
and do your brackets like this
if (foo)
{
	 bla;
	 bla;
}

..except for oneliners:

if (foo)
	 bla;

..oh and set ts=8 sts=4 sw=4. :)

Vince


Legal Disclaimer: Any views expressed by the sender of this message are
not necessarily those of Application Solutions Ltd. Information in this
e-mail may be confidential and is for the use of the intended recipient
only, no mistake in transmission is intended to waive or compromise such
privilege. Please advise the sender if you receive this e-mail by mistake.

> Anyway, I don't intend to add "Virtual Editing" (moving the cursor beyond
the
> end of the line).  It will cause many problems,
..it doesn't appear to cause problems in MultiEdit, Devstudio, Emacs,
BRIEF, Codewright...

> and it is very un-vi-ish.
it's no more un-vi-ish than
'nostartofline'
or the gj & gk commands,
or 'insertmode',
or visual selections,
or (insert your favourite non-vi feature here)...

Why not wait to see how people get on with this patch before
coming down so hard?

> Except perhaps in Visual Block mode, where it's useful.
Won't it look weird if you can get the cursor beyond the end of a line
in block mode and then it pings back when you exit block mode?

Vince




Legal Disclaimer: Any views expressed by the sender of this message are
not necessarily those of Application Solutions Ltd. Information in this
e-mail may be confidential and is for the use of the intended recipient
only, no mistake in transmission is intended to waive or compromise such
privilege. Please advise the sender if you receive this e-mail by mistake.

On Wed, 09 Feb 2000 09:55:20 GMT, Vince Negri wrote:

>
> I thought there used to be a file called STYLE in the src
> distribution, but I can't find it now...?
>

see:
  :help development
  :help coding-style

Mit freundlichen Gruessen / Kind regards

Ralf Schandl

--
Ralf Schandl                              schandl@...
IBM Deutschland Informationssysteme GmbH  Tel: +49-69-6645-3208
Lyoner Str. 13, 60528 Frankfurt           FAX: +49-69-6645-3224

* Vince Negri <vnegri@...> [000209 10:05]:
> > and it is very un-vi-ish.
> it's no more un-vi-ish than 'nostartofline' or the
> gj & gk commands, or 'insertmode', or visual selections, or ...

Amen!

> > Except perhaps in Visual Block mode, where it's useful.
> Won't it look weird if you can get the cursor beyond the end of a line
> in block mode and then it pings back when you exit block mode?

This sure is a problem.

Maybe virtual editing should be
restricted to insert mode only for now?

At least until someone finds solutions
for the problems involved with other modes...

Sven

On Wed, Feb 09, 2000 at 02:19:09PM +0100,
Sven Guckes <guckes@...> wrote:
>
> * Vince Negri <vnegri@...> [000209 10:05]:
> > > and it is very un-vi-ish.
> > it's no more un-vi-ish than 'nostartofline' or the
> > gj & gk commands, or 'insertmode', or visual selections, or ...
>
> Amen!
>
> > > Except perhaps in Visual Block mode, where it's useful.
> > Won't it look weird if you can get the cursor beyond the end of a line
> > in block mode and then it pings back when you exit block mode?
>
> This sure is a problem.
>
> Maybe virtual editing should be
> restricted to insert mode only for now?

Well, first of all, we need an option for setting this feature :)
Then - how would you handle ^O in insert mode while out there?

> At least until someone finds solutions
> for the problems involved with other modes...

Uhm. Don't know whether this is such a good idea...

> Sven

CU,
Thomas

--
  Thomas Köhler Email:   jean-luc@...     | LCARS - Linux
      <><        WWW:     http://jeanluc-picard.de      | for Computers
                 IRC:             jeanluc               | on All Real
                PGP public key available from Homepage! | Starships

Gabriel Zachmann wrote:

> I would like to ask for a slight modification of what `` does in vim.
> Right now, it jumps back to the former position,
> and it places the new current line usually in the center of the window.
>
> However, I think it would make sense to place the new current line
> at the same position within the window where it was before.

You mean that the relative position of the cursor line in the window is
remembered for the mark?  Since the mark may have been set by a command that
didn't scroll the window, it would be strange if `` does scroll the window.

Also, when `` jumps to a position which is already being displayed, it's
strange that the text will scroll.

> Reason:
> I've got a little autocommand for HTML files,
> which jumps to the end of the file when saving it,
> inserts the current date,
> then jumps back (while vim saves the file).
> It works fine, except that after I've done :w
> the current line is somewhere else on the screen than before,
> which is a little bit irritating.
>
> I think this problem can be generalized: `` can be used often quite
> conveniently in some autocommand to jump back to the position where the
> cursor was before the autocommand was invoked.
> The idea is to hide from the user that an autocommand has been invoked.
> In order to not disturb the user, it would be nice if `` would also
> restore the position on the screen, not only the position in the file.

That can be fixed in another way, without changing the meaning of ``:

	 save position: maHmb
	 restore position: 'bzt`a

> PS:
> Of course, I am pretty sure that this could also be solved by a vim
> script -- but in this case it seems to me that the right place to solve
> it would be the  `` command itself, because it would make things a
> little bit more consistent, IMHO.

But it would make `` incompatible with Vi and previous releases of Vim.  Since
there is another solution, I prefer to keep `` compatible.

--
The Characters and incidents portrayed and the names used are fictitious and
any similarity to the names, characters, or history of any person is entirely
accidental and unintentional.
                                   Signed RICHARD M. NIXON
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
\ \   Vim: http://www.vim.org      ICCF Holland: http://www.vim.org/iccf   / /

Tim wrote:

> I've been noticing some various "problems" with the way Vim (or the syntax
> file, I'm not too familiar with this stuff) some of this. For example:
>
> int foo(
> #ifdef _WIN32
> HWND h )
> #else
> int n )     <-- this bracket is highlighed as an error
> #end
>
> Can we possibly fix that? I'm not sure where to begin...

No, this cannot be fixed.  It's near to impossible to take the preprocessor
into account for syntax highlighting.  Perhaps in the example you give it
could work, but not for this one:

	 int foo(
	 #ifdef _WIN32
	 HWND h )
	 #endif
	 #ifdef UNIX
	 int n )     <-- this bracket is highlighed as an error
	 #end

The best solution is to move the bracket outside of the #ifdef:

int foo(
#ifdef _WIN32
	 HWND h
#else
	 int n
#end
	 )

> Another thing, which I'm sure a lot of people do:
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>     // if cindent (or ai) is on, then these always get indented.
>
> Is it possible, since the protection around C++ is so popular, to exempt
> this? We got around this by defining a macro for extern "C" { - sort of
> hackish...

It is a hack.  I consider this a problem in C++.  One of the reasons I don't
like C++....

I don't really like to handle specific cases like this.  The indenting code is
quite complicated already.  Adding more magic to it makes it more messy.

You could use this trick: put this in a separate file (or at the end of a
header file that's always included):

	 #ifdef __cplusplus
	 # define CPPSTART extern "C" { /* matching } */
	 #else
	 # define CPPSTART /* empty */
	 #endif

And use "CPPSTART" in the file.

> In general, if people do funny things with these ifdefs, Vim will do funny
> things...like if braces or brackets don't "match" because of ifdefs, then %
> on a bracket don't work...

Right.  You can use a bracket in a comment to match it, when needed.  Like in
the example above.

> I'm not sure if this is fixable at all, or how difficult it would be, or
> whether its a syntax file change only, or involves some source changes...
>
> What do you guys think about this? There's prolly more preprocessor
> obscurities that other people have experienced...

The preprocessor is a nice tool to create a mess.  That's why it was banned
when Java was designed.  It's needed for C and C++ though, to make the code
portable.  Java is portable without these tricks.  Java does have other
problems though...

--
(letter from Mark to Mike, about the film's probale certificate)
       For an 'A' we would have to: Lose as may shits as possible Take Jesus
       Christ out, if possible Loose "I fart in your general direction" Lose
       "the oral sex" Lose "oh, fuck off" Lose "We make castanets out of your
       testicles"
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
\ \   Vim: http://www.vim.org      ICCF Holland: http://www.vim.org/iccf   / /

Robert Webb wrote:

> When there's only one match after using Ctrl-] to jump to a tag, using :tn
> or :tp gives no warning or error message.  I think it should at least be a
> warning and say something like "No more tag matches".  Sometimes if there
> are two matches, the code they are in may look very similar, and some tags
> programs will sometimes create two tags for the same line, in these cases
> the fact that the code didn't appear to change wouldn't let you know that
> there are no more tags matches, so the message would be really useful here.

Yes, that makes sense.  I'll find out if this is easy to add.

--
(letter from Mark to Mike, about the film's probale certificate)
       I would like to get back to the Censor and agree to lose the shits, take
       the odd Jesus Christ out and lose Oh fuck off, but to retain 'fart in
       your general direction', 'castanets of your testicles' and 'oral sex'
       and ask him for an 'A' rating on that basis.
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
\ \   Vim: http://www.vim.org      ICCF Holland: http://www.vim.org/iccf   / /

Roy Rodenstein wrote:

> Vim is awesome!

Nobody on this list would disagree with that.  Perhaps try posting in an Emacs
group and see what happens! :-)

> Now, a minor issue. Why does a line that's all whitespace (even just a
> single space) not count as a paragraph separator? If I have
>
>    a
>
>
>    b
>
>
>    c
>
>
> and am below c, I expect '{' to take me below b, not above a. It looks
> like three paragraphs to humans, and I'm not sure why we wouldn't want
> lines with just a single space (or, perhaps, any whitespace, as long as
> the have _only_ whitespace) to separate paragraphs.

This is Vi compatible.  All the good old Vi commands are accurately reproduced
by Vim.  Unless it looks like a bug, but this isn't one.

> Perhaps there's some functionality that relies on this (I suppose, when
> autoindent is on and one is coding, not treating blank-_looking_ lines as
> paragraph separators might be useful), but it seems from what I can tell
> that at least 90% of the time the user wants '{' to go up by what _looks
> like_ a paragraph. I know there is a 'paragraphs' variable, so this might
> already be solvable, but I don't know what to set it to (it'd have to be a
> regex, most likely) to make it separate paragraphs by whitespace-only lines.

True.  Now, there doesn't seem to be a Vim command that works like this.  You
can use "vap" to mark the paragraph, but you can't use "ap" as a movement
command.  Perhaps we should add "g{" and "g}" for this?  If you really want,
you could then map "{" to "g{" and "}" to "g}".

--
INSPECTOR END OF FILM: Move along.  There's nothing to see!  Keep moving!
    [Suddenly he notices the cameras.]
INSPECTOR END OF FILM: (to Camera) All right, put that away sonny.
    [He walks over to it and puts his hand over the lens.]
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
\ \   Vim: http://www.vim.org      ICCF Holland: http://www.vim.org/iccf   / /

This is VEIM. (Virtual Editing IMproved :) )

Changes/fixes:

* Trailing whitespace in a line are now removed as the cursor leaves the
   line/window.
   [tabs are reinserted, too, if the (Virtual editing-independent) option
    pl (packlines) is set.]
* Moving a cursor over the screen boundary now properly updates the screen
   inserting a blankline.
* $/End no longer ignores trailing Whitespaces in a line if VE is OFF.
   [default VIM behaviour] (Hi Vince)
* When VE is ON, Pressing ESC (out of insert)
   will now not longer move the cursor one character left.

Notes:

* :set virtualedit (ve) for virtual editing.
* :set packlines (pl) for packing lines (inserting tabs, removing spaces)

Development notes:

* Every procedure which changes curwin->w_cursor.lnum must now call
   "leave_line" before, as lines may need to be packed.
* update_later: I think this function should remember the cursor position
   that's active by calling time. Otherwise, funny things happen. Just a
   suggestion.

Greetings

Matthias

--- srcold/edit.c Wed Feb  9 12:03:41 2000
+++ src/edit.c Wed Feb  9 17:22:51 2000
@@ -3796,6 +3796,13 @@
  {
      char_u *ptr;

+    if(p_ve)
+    {
+       coladvance(getviscol()+1);
+       curwin->w_set_curswant=TRUE;
+       return OK;
+    }
+
      ptr = ml_get_cursor();
      if (*ptr++ == NUL || *ptr == NUL)
 	 return FAIL;
@@ -3809,7 +3816,7 @@

 	 base = ml_get(curwin->w_cursor.lnum);
 	 if (*(ptr+1) != NUL && IsTrailByte(base, ptr))
-     ++curwin->w_cursor.col;
+            ++curwin->w_cursor.col;
      }
  #endif
      curwin->w_set_curswant = TRUE;
@@ -3820,6 +3827,13 @@
      int
  oneleft()
  {
+    if(p_ve)
+    {
+       if(getviscol())
+       coladvance(getviscol()-1);
+       curwin->w_set_curswant=TRUE;
+       return OK;
+    }
      if (curwin->w_cursor.col == 0)
 	 return FAIL;
      curwin->w_set_curswant = TRUE;
@@ -3838,10 +3852,14 @@
      long n;
      int  upd_topline;     /* When TRUE: update topline */
  {
+
      if (n != 0)
      {
 	 if (curwin->w_cursor.lnum <= 1)
 	     return FAIL;
+
+        leave_line();
+
 	 if (n >= curwin->w_cursor.lnum)
 	     curwin->w_cursor.lnum = 1;
 	 else
@@ -3862,10 +3880,14 @@
      long    n;
      int     upd_topline;     /* When TRUE: update topline */
  {
+
      if (n != 0)
      {
 	 if (curwin->w_cursor.lnum >= curbuf->b_ml.ml_line_count)
 	     return FAIL;
+
+        leave_line();
+
 	 curwin->w_cursor.lnum += n;
 	 if (curwin->w_cursor.lnum > curbuf->b_ml.ml_line_count)
 	     curwin->w_cursor.lnum = curbuf->b_ml.ml_line_count;
@@ -4610,7 +4632,8 @@
  #ifdef RIGHTLEFT
 	     && !revins_on
  #endif
- 			      )
+    				      )
+    if (!p_ve) // virtual editing leaves the cursor where it is.
 	 --curwin->w_cursor.col;

      /* need to position cursor again (e.g. when on a TAB ) */
@@ -4854,7 +4877,8 @@
 		 || curwin->w_cursor.lnum > orig_line_count)
 	     {
 		 temp = gchar_cursor(); /* remember current char */
-  --curwin->w_cursor.lnum;
+                leave_line();
+                --curwin->w_cursor.lnum;
 		 (void)do_join(FALSE, TRUE);
 		 redraw_later(VALID_TO_CURSCHAR);
 		 if (temp == NUL && gchar_cursor() != NUL)
@@ -5188,6 +5212,7 @@
      else if (vim_strchr(p_ww, '[') != NULL && curwin->w_cursor.lnum > 1)
      {
 	 start_arrow(&tpos);
+        leave_line();
 	 --(curwin->w_cursor.lnum);
 	 coladvance(MAXCOL);
 	 curwin->w_set_curswant = TRUE; /* so we stay at the end */
@@ -5204,7 +5229,10 @@
      undisplay_dollar();
      tpos = curwin->w_cursor;
      if ((mod_mask & MOD_MASK_CTRL))
- curwin->w_cursor.lnum = 1;
+    {
+        leave_line();
+        curwin->w_cursor.lnum = 1;
+    }
      curwin->w_cursor.col = 0;
      curwin->w_curswant = 0;
      start_arrow(&tpos);
@@ -5218,7 +5246,10 @@
      undisplay_dollar();
      tpos = curwin->w_cursor;
      if ((mod_mask & MOD_MASK_CTRL))
- curwin->w_cursor.lnum = curbuf->b_ml.ml_line_count;
+    {
+        leave_line();
+        curwin->w_cursor.lnum = curbuf->b_ml.ml_line_count;
+    }
      coladvance(MAXCOL);
      curwin->w_curswant = MAXCOL;
      start_arrow(&tpos);
@@ -5269,6 +5300,7 @@
      {
 	 start_arrow(&curwin->w_cursor);
 	 curwin->w_set_curswant = TRUE;
+        leave_line();
 	 ++curwin->w_cursor.lnum;
 	 curwin->w_cursor.col = 0;
      }
@@ -5745,7 +5777,8 @@
 	     if (i > 0)  /* skip blanks before '{' */
 		 while (--i > 0 && vim_iswhite(ptr[i]))
 		     ;
-     curwin->w_cursor.lnum = pos->lnum;
+     leave_line();
+            curwin->w_cursor.lnum = pos->lnum;
 	     curwin->w_cursor.col = i;
 	     if (ptr[i] == ')' && (pos = findmatch(NULL, '(')) != NULL)
 		 curwin->w_cursor = *pos;
@@ -5769,6 +5802,7 @@
 		 i = get_indent();
 		 while (curwin->w_cursor.lnum > 1)
 		 {
+                    leave_line();
 		     ptr = skipwhite(ml_get(--(curwin->w_cursor.lnum)));

 		     /* ignore empty lines and lines starting with '#'. */
--- srcold/misc1.c Wed Feb  9 12:03:45 2000
+++ src/misc1.c Wed Feb  9 17:57:55 2000
@@ -1478,8 +1478,8 @@
      char_u  *s;
  {
      char_u *oldp, *newp;
-    int  newlen = STRLEN(s);
-    int  oldlen;
+    int newlen = STRLEN(s);
+    int oldlen;
      colnr_t col = curwin->w_cursor.col;
      linenr_t lnum = curwin->w_cursor.lnum;

@@ -1499,28 +1499,120 @@
      changed_cline_bef_curs();
      approximate_botline(); /* w_botline might have changed */
  }
+
+/*
+ * Reformat the current line, snipping trailing whitespace and
+ * un-expanding tabs.
+ */
+    void
+packline(dotabs)
+    int dotabs;
+{
+    char_u      *oldp;
+    int         oldlen;
+    linenr_t    lnum = curwin->w_cursor.lnum;
+    char_u      *newp;
+    char_u      *newp2;
+    int         newlen=0;
+    int i,t=0;
+    int s=0,ws=0;
+    int tablen = (curbuf)->b_p_ts;
+    int oldlinelen=getvislinelen()-1;
+
+    oldp = ml_get(lnum);
+    oldlen = STRLEN(oldp);
+    newp=alloc_check((unsigned)(oldlen)+1);
+    if(!oldp || !oldlen || !newp) return;
+
+    for(i=oldlen-1;i>=0;i--)
+        if(oldp[i]!=' ' && oldp[i]!=TAB) break;
+    ws=oldlen-(i+1);
+    oldlen=i+1;
+
+    if(!dotabs)
+    {
+        mch_memmove(newp,oldp,oldlen+1);
+        newlen=oldlen+1;
+        newp[oldlen]=0;
+
+    }
+    else
+    {
+        for(i=0;i<oldlen;i++)
+        {
+           if((t%tablen==0) && s>0)
+           {
+              if(s>1)
+                  newp[newlen++]=TAB;
+              else
+                  newp[newlen++]=' ';
+              s=0;
+           }
+
+           if(oldp[i]==' ') s++;
+           else
+           {
+              if(oldp[i]==TAB) s+=tablen-(t%tablen);
+              else
+              {
+                 int v;
+                 for(v=0;v<s;v++) newp[newlen++]=' ';
+                 newp[newlen++]=oldp[i];
+                 s=0;
+              }
+           }
+           t+=lbr_chartabsize(&oldp[i],t);
+        }
+        newp[newlen++]=0;
+    }
+
+    newp2 = alloc_check((unsigned)(newlen));
+    if(!newp2) return;
+
+    mch_memmove(newp2,newp,newlen);
+    vim_free(newp);
+    ml_replace(lnum,newp2,FALSE);
+
+    changed_cline_bef_curs();
+    approximate_botline();
+
+    if(ws>0 && ((getvislinelen()/Columns)!=(oldlinelen/Columns)))
+     // we trailed whitespaces, so the linesize may have passed a screenlen
+    redraw_later(VALID_TO_CURSCHAR);
+}

  /*
+ * Do the stuff which has to be done when the cursor leaves a line
+ */
+
+void leave_line()
+{
+    if( p_ve && p_pl) packline(TRUE);
+    if(!p_ve && p_pl) packline(TRUE);
+    if( p_ve && !p_pl) packline(FALSE);
+}
+
+/*
   * Delete one character under the cursor.
   * If 'fixpos' is TRUE, don't leave the cursor on the NUL after the line.
- *
+ *
   * return FAIL for failure, OK otherwise
- */
+ */
      int
  del_char(fixpos)
      int  fixpos;
-{
+{
  #ifdef MULTI_BYTE
      if (is_dbcs)
-    {
- /* delete two-bytes, when the character is an multi-byte character */
- if (AdjustCursorForMultiByteChar())
-     return del_chars(2L, fixpos); /* do BACKSPACE key */
- else
- {
-     char_u *p; /* do DELETE key */
-
-     p = ml_get_cursor();
+    {
+        /* delete two-bytes, when the character is an multi-byte character */
+        if (AdjustCursorForMultiByteChar())
+            return del_chars(2L, fixpos); /* do BACKSPACE key */
+        else
+        {
+            char_u *p; /* do DELETE key */
+
+            p = ml_get_cursor();
 	     if (p == NULL || p[0] == NUL)
 		 return FALSE;
 	     if (p[1] != NUL && IsLeadByte(p[0]))
--- srcold/misc2.c Wed Feb  9 12:03:45 2000
+++ src/misc2.c Wed Feb  9 17:54:36 2000
@@ -16,22 +16,88 @@
  # include <fcntl.h>     /* for chdir() */
  #endif

+/* getlastvalidcol()
+ *
+ * returns the screen position of the last non empty character.
+ *
+ */
+
+int getlastvalidcol()
+{
+    int x = 0;
+    char*ptr = ml_get_curline();
+    int d = strlen(ptr)-1;
+    int t;
+    for(; d >= 0; d--)
+        if((ptr[d]!=' ') && (ptr[d]!='\t')) break;
+
+    for(t = 0; t <= d; t++)
+        x+=lbr_chartabsize(&ptr[t], x);
+
+    x-=1;
+    return x;
+}
+
  /*
- * coladvance(col)
+ * linelen(pos)
   *
- * Try to advance the Cursor to the specified column.
+ * get the (virtual) linelength of the current line
   *
- * return OK if desired column is reached, FAIL if not
   */
-    int
-coladvance(wcol)
-    colnr_t     wcol;
+int getvislinelen()
  {
-    int  idx;
-    char_u *ptr;
-    colnr_t col;
+    int     x = 0;
+    char    *ptr = ml_get_curline();
+    int     t;
+    int d=strlen(ptr);

+    for(t = 0; t < d; t++)
+        x += lbr_chartabsize(&ptr[t], x);
+
+    return x;
+}
+
+/*
+ * coladvance(col)
+ *
+ * Try to advance the Cursor to the specified column.
+ *
+ * return OK if desired column is reached, FAIL if not
+ */
+    int
+coladvance(wcol)
+    colnr_t         wcol;
+{
+    int         idx;
+    char_u      *ptr;
+    colnr_t     col;
+
+    char* ptr2;
+    char* optr, ocol = 0;
+    int added_spaces=0;
+
+    int oldlinelen=getvislinelen()-1;
+
      ptr = ml_get_curline();
+    ptr2 = optr = ptr;
+
+    if(wcol >= MAXCOL && p_ve)
+    {
+        wcol = getlastvalidcol()+1;
+        curwin->w_curswant = wcol;
+    }
+
+    if(p_ve)
+    if((ptr == NULL || *ptr == NUL) && (wcol>0))
+    {
+        char*spaces = malloc(wcol+2);
+        int t;
+        for(t = 0;t<wcol+1;t++) spaces[t] = ' ';
+        spaces[wcol+1] = 0;
+        ml_replace(curwin->w_cursor.lnum, spaces, FALSE);
+
+        ptr = ml_get_curline();
+    }

      /* try to advance to the specified column */
      idx = -1;
@@ -40,9 +106,66 @@
      {
 	 ++idx;
 	 /* Count a tab for what it's worth (if list mode not on) */
+        optr = ptr;
+ ocol = col;
 	 col += lbr_chartabsize(ptr, col);
 	 ++ptr;
      }
+
+    if(p_ve && (col!=(wcol+1)))
+    {
+        if(col <= wcol)
+        {
+            int correct = wcol-col+1;
+            char *newline = alloc((idx+1)+correct+1);
+            int t;
+            for(t = 0; t < idx+1; t++)
+  newline[t] = ptr2[t];
+
+            for(t = 0; t < correct; t++)
+  newline[t+(idx+1)] = ' '
+ 	    ;
+            newline[(idx+1)+correct] = 0;
+
+            ml_replace(curwin->w_cursor.lnum, newline, FALSE);
+            idx+=correct;
+            col+=correct;
+
+            added_spaces=1;
+
+        }
+        else
+        {
+            int tablen = lbr_chartabsize(optr, ocol);
+            int linelen = strlen(ptr2);
+            int correct = wcol-col+1; /*negative!!*/
+            char *newline = alloc(tablen+linelen-1+1);
+            int t, s = 0;
+
+            if((-correct) > tablen)
+  return FAIL;
+
+            for(t = 0; t < linelen; t++)
+            {
+                if(t != idx)
+ 	    newline[s++] = ptr2[t];
+                else
+                {
+                    int v;
+                    for(v = 0; v < tablen; v++)
+ 	 newline[s++] = ' ';
+                }
+
+            }
+
+            newline[tablen+linelen-1] = 0;
+
+            ml_replace(curwin->w_cursor.lnum, newline, FALSE);
+            idx += (tablen -1 + correct);
+            col += correct;
+        }
+    }
+
      /*
       * In Insert mode it is allowed to be one char beyond the end of the line.
       * Also in Visual mode, when 'selection' is not "old".
@@ -58,11 +181,48 @@
      if (is_dbcs)
 	 AdjustCursorForMultiByteChar();
  #endif
+
+    //if(added_spaces)
+    if((getvislinelen()/Columns) != (oldlinelen/Columns))
+    {
+        changed_cline_bef_curs();
+        approximate_botline();
+        redraw_later(VALID_TO_CURSCHAR);
+    }

      if (col <= wcol)
 	 return FAIL;     /* Couldn't reach column */
      else
 	 return OK;     /* Reached column */
+}
+
+/*
+ * getviscol2(pos)
+ *
+ * get the screen position of character number pos on the current line
+ *
+ */
+int getviscol2(int d)
+{
+    int     x = 0;
+    char    *ptr = ml_get_curline();
+    int     t;
+    for(t = 0; t <= d; t++)
+        x += lbr_chartabsize(&ptr[t], x);
+
+    return (x - 1);
+}
+
+/*
+ * getviscol()
+ *
+ * get the screen position of the character the cursor is on
+ *
+ */
+
+int getviscol()
+{
+    return getviscol2(curwin->w_cursor.col);
  }

  /*
--- srcold/option.c Wed Feb  9 12:03:46 2000
+++ src/option.c Wed Feb  9 15:01:14 2000
@@ -842,6 +842,9 @@
 			     {(char_u *)0L, (char_u *)0L}
  #endif
 			     },
+    {"packlines", "pl",     P_BOOL,
+                            (char_u *)&p_pl,
+                            {(char_u *)FALSE, (char_u *)FALSE}},
      {"paragraphs",  "para", P_STRING|P_VI_DEF,
 			     (char_u *)&p_para,
 			     {(char_u *)"IPLPPPQPP LIpplpipbp", (char_u *)0L}},
@@ -1297,6 +1300,9 @@
 			     (char_u *)NULL,
  #endif
 			     {(char_u *)"", (char_u *)0L}},
+    {"virtualedit", "ve",   P_BOOL,
+                            (char_u *)&p_ve,
+                            {(char_u *)FALSE, (char_u *)FALSE}},
      {"visualbell",  "vb",   P_BOOL|P_VI_DEF,
 			     (char_u *)&p_vb,
 			     {(char_u *)FALSE, (char_u *)0L}},
--- srcold/option.h Wed Feb  9 12:03:46 2000
+++ src/option.h Wed Feb  9 15:03:02 2000
@@ -379,6 +379,7 @@
  EXTERN char_u  *p_mousem; /* 'mousemodel' */
  EXTERN long p_mouset; /* 'mousetime' */
  EXTERN int p_more;  /* 'more' */
+EXTERN int p_pl;  /* 'packlines' */
  EXTERN char_u  *p_para;  /* 'paragraphs' */
  EXTERN int p_paste; /* 'paste' */
  EXTERN char_u  *p_pt;  /* 'pastetoggle' */
@@ -480,6 +481,7 @@
  EXTERN char_u  *p_viminfo; /* 'viminfo' */
  #endif
  EXTERN int p_vb;  /* 'visualbell' */
+EXTERN int p_ve;  /* 'virtualedit' */
  EXTERN long p_verbose; /* 'verbose' */
  EXTERN int p_warn;  /* 'warn' */
  #if defined(USE_GUI_MSWIN) || defined(USE_GUI_MOTIF) || defined(LINT) ||
defined (USE_GUI_GTK)
--- srcold/proto/misc1.pro Wed Feb  9 12:03:47 2000
+++ src/proto/misc1.pro Wed Feb  9 15:23:46 2000
@@ -12,6 +12,8 @@
  int plines_m_win __ARGS((WIN *wp, linenr_t first, linenr_t last));
  void ins_char __ARGS((int c));
  void ins_str __ARGS((char_u *s));
+void packline __ARGS((int c));
+void leave_line __ARGS((void));
  int del_char __ARGS((int fixpos));
  int del_chars __ARGS((long count, int fixpos));
  int truncate_line __ARGS((int fixpos));
--- srcold/proto/misc2.pro Wed Feb  9 15:51:31 2000
+++ src/proto/misc2.pro Wed Feb  9 17:48:05 2000
@@ -1,5 +1,7 @@
  /* misc2.c */
  int coladvance __ARGS((colnr_t wcol));
+int getviscol __ARGS((void));
+int getvislinelen __ARGS((void));
  int inc_cursor __ARGS((void));
  int inc __ARGS((FPOS *lp));
  int incl __ARGS((FPOS *lp));
--- runtime/docold/options.txt Wed Feb  9 15:32:32 2000
+++ runtime/doc/options.txt Wed Feb  9 15:21:50 2000
@@ -2605,6 +2605,15 @@
 	 It can affect the pattern matching of the automatic commands.
 	 |autocmd-osfiletypes|

+                                                *'pl'* *'nopl'* *packlines*
+'packlines' 'pl'        boolean (default off)
+                        global
+                        {not in VI}
+        Automatically reformats lines on exit to reduce memory space.
+        This enables VIM to replace multiple SPACEs by TABs, and
+        automatically removes trailing whitespaces at the end of a line.
+        |virtualedit|
+
 						 *'paragraphs'* *'para'*
  'paragraphs' 'para' string (default "IPLPPPQPP LIpplpipbp")
 			 global
@@ -4124,6 +4133,16 @@
 			 previous search and substitute patterns.
 	 no %  The buffer list will not be saved nor read back.
 	 no h  'hlsearch' highlighting will be restored.
+
+                        *'virtualedit'* *'ve'* *'nove'*
+'virtualedit' 've'      boolean (default off)
+                        global
+                        {not in Vi}
+        This allows VIM to insert spaces into buffers and also replace
+        TABs by Spaces. By turning this option on, the cursor may be moved
+        more "freely", through TABs, over the end of the line and vertically
+        between lines with different sizes. When turning this on, the
+        |packlines| option should also be set to allow recreation of TABs.

 			 *'visualbell'* *'vb'* *'novisualbell'* *'novb'* *beep*
  'visualbell' 'vb' boolean (default off)

Matthias Kramm wrote:
>    patch.virtualedit2Name: patch.virtualedit2

Wanted to give it try. But what does this patch agenst? a clean vim 5.6.11? or
do I need to first need to patch in the "all.diff.gz" mentioned erlier in the
thread?

--
Eh, that's it, I guess.  No 300 million dollar unveiling event for this
kernel, I'm afraid, but you're still supposed to think of this as the
"happening of the century" (at least until the next kernel comes along).
Oh, and this is another kernel in that great and venerable "BugFree(tm)"
series of kernels. So be not afraid of bugs, but go out in the streets
and deliver this message of joy to the masses.
	 -- Linus Torvalds, on releasing 1.3.27

On Wed, Feb 09, 2000 at 12:39:40PM -0500, Devin Weaver wrote:
> Matthias Kramm wrote:
> >    patch.virtualedit2Name: patch.virtualedit2
>
> Wanted to give it try. But what does this patch agenst? a clean vim 5.6.11? or
> do I need to first need to patch in the "all.diff.gz" mentioned erlier in the
> thread?
>

The patch assumes Vim 5.6 without anything.

The all.diff.gz-patch is included.

Greetings

Matthias

Hi,

using 5.6 I discovered that the perl.vim has a small buglet.

If you use the =~ binding operator it will turn all text afterwards in
the same colour untill used again.

The problem is I cannot just type the part in and see the problem, which
makes me a bit unable to troubleshoot it correctly.

I have the file handy for anyone who's willing to take a stab at
locating the problem.  It's 80k, and I don't wish to spam the list with
it.

Thanks,

--
Jeroen Ruigrok vd Werven/Asmodai    asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
Looking for the Sun that eclipsed behind black feathered wings...