On 23/03/10 23:36, Gary Johnson wrote:
On 2010-03-23, Jean Johner<jean.joh...@cea.fr> wrote:
On Mar 23, 6:24 pm, Gary Johnson<garyj...@spocom.com> wrote:
...
Hi Gary,
You are right, there is one column more in insert mode than in normal
mode.
This is clear if you have "set ruler" which indicates column 54 if you
are positionned after the last available column 53 in normal mode.
I guess that is why the option "set virtualedit=onemore" has been
invented.
Indeed setting virtualedit=onemore DOES SOLVE the problem as indicated
previously.
But this solution has unpleasant side-effects in normal mode.
It must be possible to solve the problem differently (by indicating
somehow to .viminfo that the quit has been done with the cursor at the
end of a line in insert mode).
It is the developpers' job to find a solution.
I would say rather that it is the developer's job to determine the
feasibility of a solution. It is not the developer's job to find a
solution to every issue perceived to be a problem by any user.
Nevertheless, I think Vim already contains the components of a
solution to this problem as I will illustrate.
Create a line containing some text like this and leave insert mode.
Mary had a little lamb
Now change that line by appending to the end of it, like this, and
again leave insert mode.
Mary had a little lamb that was white.
Now execute the following command and note the result.
:echo col("'[") col("']") col(".")
27 43 42
The last changed column, 43, is to the right of the current cursor
column, 42. Also, that line has only 42 columns. That indicates
that while Vim was last in insert mode it was appending to the
current line. To restore Vim's state to what it was before leaving
insert mode, the cursor would be moved to column 42 and the 'a'
normal-mode command executed. Alternatively, the :startinsert! ex
command could be executed.
I think someone could use that information to put the appropriate
logic into an appropriate autocommand, perhaps in evim.vim, and get
the behavior you want.
Regards,
Gary
I agree with the above, and to "the developers' job", I'll add that
"the" developer, Bram Moolenaar, has a full-time job which leaves him
little time to fix outright bugs in Vim, let alone add enhancements. We
are all lucky enough that he places such a fine (and oh, how well
documented! :-) ) editor at our disposition, at no cost to us (and yes,
we are encouraged to contribute to Bram's favourite charity, but if any
of us doesn't, his copy of Vim won't stop functioning just as well as it
does for those who do contribute).
The source code of Vim is all available, anyone has access to it; see
for instance by following the two last links of the summary of my Vim
page http://users.skynet.be/antoine.mechelynck/vim/ how I used to
compile Vim when I was on Windows and how I still do now that I'm on
Linux. No-one prevents you (Jean), or anyone else for that matter, from
altering the code to add any feature that suits your whim; once it works
to your satisfaction you can even publish your changes and ask to have
them added to the list of "unofficial patches" at
http://groups.google.com/group/vim_dev/web/vim-patches so that anyone
may profit by it. (Having your changes made part of "official" mainline
Vim requires, among others, convincing Bram that the change is a
valuable addition, that it doesn't beak backwards compatibility, that it
is free of obvious bugs, and that it obeys "Vim coding style". It's not
just any patch that can pass his judgment.)
Best regards,
Tony.
--
Any sufficiently advanced bug is indistinguishable from a feature.
-- Rich Kulawiec
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or
reply to this email with the words "REMOVE ME" as the subject.
