headers
Vegard Øye | 1 Mar 2011 14:59
Picon
Favicon

Re: Vimpulse and vim-mode

On 2011-02-28 21:57 +0100, Frank Fischer wrote:

> On 2011-02-28 21:45 +0100, Frank Fischer wrote:
>
>> On Mon, Feb 28, 2011 at 04:23:21PM +0100, Vegard Øye wrote:
>>
>>> If it is possible to reliably distinguish linear changes from
>>> non-linear ones in `after-change-functions', we can choose the
>>> appropriate representation accordingly. Any invocation of, e.g.,
>>> `self-insert-command' will be represented as a linear change,
>>> while anything that doesn't fit the linear mold is represented
>>> as keystrokes.
>>
>> Well, but must "linear changes" are very easily covered by the
>> keystrokes version (e.g., insertion of "abc" is just "abc").
>> Others are problematic (note that vim-mode's repeat system is
>> keystroke based and linear changes have never been problems).

I am replying to both of your last two posts.

My point is that auto-completion /is/ a linear change. In fact,
disregard the word "linear" (probably the most abused word in the
mathematical dictionary), and try to think of a series of completion
commands as a kind of "bumbling typist":

    "Now, what is that word I want to type, 'abacus'? So, a-b-a-c-u-s
    [6 letters]. No, that's not right, although the word does start
    with 'ab': Backspace, Backspace, Backspace, Backspace [4 times].
    How about, hm, 'abbreviation'? b-r-e-v-i-a-t-i-o-n. No, that's
    not exactly right either ..."
(Continue reading)

Permalink | Reply | 3 comments |
headers
Frank Fischer | 1 Mar 2011 16:57
Picon

Re: Vimpulse and vim-mode

Am Dienstag, 1. März 2011 schrieb Vegard Øye:

> My point is that auto-completion /is/ a linear change. 

But doesn't this depend on the concrete package? Completion could also 
insert text behind point (I think of some of those snippet packages).

But that was not what I meant. When some of those completion-dialogs 
pops up, the user can keep on typing or use the cursor-keys or whatever 
to select possible completions. How do you realize that these commands 
should *not* be recorded although they may look like, e.g., a motion (I 
just don't know how these packages really work). If this packages 
inserts text behind point it will drop you in the second case, but then 
the sequence of keys just does not represent what has been inserted 
(the sequence may be something like [a b b <down> <down> <up> c d 
<enter>]. There are two cases: if you wait for some time after typing 
the second b you go into completion mode and the motions are mapped to 
completion dialog. But if you do not wait those motions are really 
motions. One would have to realize in which situation we are).

But maybe I'm just too scary of those packages and such strange things 
never happen.

Another point why I would prefer key-sequence as default in all cases is 
that sometimes insertion triggers other changes, too, like indentation. 
I this case repeation of key-sequences does what you want (indent 
according to where the repeation took place) while direct insertion of 
text may fail. This may depend, in this example, on whether the 
additional spaces are inserted just before point.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tim Harper | 1 Mar 2011 18:41
Picon
Gravatar

Re: Vimpulse and vim-mode

On Mon, Feb 28, 2011 at 2:02 AM, Frank Fischer
<frank.fischer <at> mathematik.tu-chemnitz.de> wrote:
>
> I really like the idea of making operators as close to usual emacs
> commands as possible. This is certainly possible for character motions,
> but how do you tell which kind of motion the region belongs to? Call
> different commands depending on the type? Modify point and mark? The
> latter is possible for character and linewise motions, but what about
> block? Furthermore modifying point and mark may be problematic. Several
> commands have rules where to place point after execution depending on
> the original position of point (before modification to respect the
> visual region).

I really like this as well. With the original vimpulse (before Vegard
got involved? My first experience with vimpulse was from a version
posted to the Emacs wi) you had two separate regions, one for vimpulse
visual mode and one for emacs.  This meant that emacs commands
couldn't cooperate with vimpulse commands, and I personally found that
totally repulsive.  I really like how vimpulse's visual mode operates
now, it's wonderfully implemented, despite a few minor shortcomings.

Perhaps it's just me, but if it's a choice between interoperability
with Emacs at the cost of 97% compatibility with vim, and 100%
compatibility with them at the cost of reduced interoperability with
Emacs commands, I would prefer sacrificing the vim compatibility.

If 100% vim compatibility were important to me, I would use vim.  I
don't use vim because I enjoy what emacs provides, and prefer to use
Emacs commands and vim commands interchangeably.  I recognize that
many people consider me a freak for doing so, but I just use whatever
(Continue reading)

Permalink | Reply | 2 comments |
headers
Vegard Øye | 1 Mar 2011 20:42
Picon
Favicon

Re: Vimpulse and vim-mode

On 2011-03-01 16:57 +0100, Frank Fischer wrote:

> Am Dienstag, 1. März 2011 schrieb Vegard Øye:
>
> When some of those completion-dialogs pops up, the user can keep on
> typing or use the cursor-keys or whatever to select possible
> completions. How do you realize that these commands should *not* be
> recorded although they may look like, e.g., a motion (I just don't
> know how these packages really work). If this packages inserts text
> behind point it will drop you in the second case, but then the
> sequence of keys just does not represent what has been inserted (the
> sequence may be something like [a b b <down> <down> <up> c d <enter>].

What kind of command it is can only be determined in
`post-command-hook', after the command has done all its stuff --
completion or otherwise. `after-change-functions' collect info while
the command is executing, and then the hook uses that info to decide.

> Another point why I would prefer key-sequence as default in all
> cases is that sometimes insertion triggers other changes, too, like
> indentation. I this case repeation of key-sequences does what you
> want (indent according to where the repeation took place) while
> direct insertion of text may fail. This may depend, in this example,
> on whether the additional spaces are inserted just before point.

True. It's just a heuristic, and it probably will have to be
supplemented with some hard-coding ("this is an indentation command")
as more complex use cases emerge. I don't see a way around the dreaded
blacklist -- just ways to (hopefully) make the blacklist shorter.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vegard Øye | 1 Mar 2011 20:43
Picon
Favicon

Re: Name

On 2011-03-01 16:57 +0100, Frank Fischer wrote:

> Well, whatever we decide for all those points above, I think it's
> time to start (if we want, I do ;)).
>
> To summarize, I think the follow things have to be done first:
>
> - create gitorious project

We'll need a name, then. ;)

I vote for vimu. Tim Harper votes for evil. Christoph Lange votes
for evil. That means the name will be decided by your vote.

I don't feel strongly either way. Choose what /you/ think is best. :)

--

-- 
Vegard
Permalink | Reply | 7 comments |
headers
Frank Fischer | 1 Mar 2011 21:03
Picon

Re: Name

On Tue, Mar 01, 2011 at 08:43:59PM +0100, Vegard Øye wrote:
> On 2011-03-01 16:57 +0100, Frank Fischer wrote:
> 
> > Well, whatever we decide for all those points above, I think it's
> > time to start (if we want, I do ;)).
> >
> > To summarize, I think the follow things have to be done first:
> >
> > - create gitorious project
> 
> We'll need a name, then. ;)
> 
> I vote for vimu. Tim Harper votes for evil. Christoph Lange votes
> for evil. That means the name will be decided by your vote.
> 
> I don't feel strongly either way. Choose what /you/ think is best. :)

Then it's evil ;)

Frank
Permalink | Reply | 6 comments |
headers
Vegard Øye | 1 Mar 2011 22:48
Picon
Favicon

Evil Gitorious project (was: Re: Name)

On 2011-03-01 21:03 +0100, Frank Fischer wrote:

> Then it's evil ;)

And so it is: http://gitorious.org/evil :)

As a starting point, I have uploaded parts of the development code
I showed you earlier. Please verify that you have commit access by
following these steps:

* Go to Dashboard -> Manage SSH keys > Add SSH keys and upload the
  right file from ~/.ssh/. (If you don't have a SSH key, you can
  generate one with ssh-keygen -C "your <at> email.org".)

* Set up your Git name and e-mail:

    git config --global user.name "Your Name"
    git config --global user.email "your <at> email.org"

* Download the repository:

    git clone git <at> gitorious.org:evil/evil.git

  You'll need the password for your SSH key, of course.
  (Non-committers can do git clone git://gitorious.org/evil/evil.git.)

* Make a change. You can commit it with the command:

    git commit -a
(Continue reading)

Permalink | Reply | 5 comments |
headers
Frank Fischer | 1 Mar 2011 23:05
Picon

Re: Vimpulse and vim-mode

On Tue, Mar 01, 2011 at 08:42:52PM +0100, Vegard Øye wrote:
> Well, the rule does say that keystrokes are the default
> representation. "tx" will be recorded as keystrokes because it doesn't
> trigger an insertion. A command will only be recorded as insertion if
> it inserts or deletes text /and/ it doesn't do something which cannot
> be represented as an insertion. Otherwise, it's all keystrokes.

Well, if keystrokes are the default and this "linear" stuff is just
the special case, then that's fine for me. I just had the feeling that
you want the linear stuff to be the default.

> > It seems to me that the key-sequence approach is almost always the
> > right way. If there weren't those nasty completion things ... ;)
> 
> I agree. We might be overanalyzing this problem. Maybe the blacklist
> is a tolerable solution after all, because the odd completion command
> is all that needs to be listed.
> 
> >>     (vimpulse-define-operator vimpulse-insert (beg end &optional arg)
> >>       "Insert before point."
> >>       (interactive (list current-prefix-arg))
> >>       ...)
> >
> > Perhaps we could extend the string-variant by further chars
> > understood by define-operator? Would make the stuff more readable.
> 
> Seems like a bit of a job, judging by the length of `interactive's
> docstring. I'm not sure it would be worth the effort.

I would propably use a very special rule like "if the interactive
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vegard Øye | 1 Mar 2011 23:10
Picon
Favicon

Re: Vimpulse and vim-mode

On 2011-03-01 18:41 +0100, Tim Harper wrote:

> Perhaps it's just me, but if it's a choice between interoperability
> with Emacs at the cost of 97% compatibility with vim, and 100%
> compatibility with them at the cost of reduced interoperability with
> Emacs commands, I would prefer sacrificing the vim compatibility.
> If 100% vim compatibility were important to me, I would use vim.

Well put. I totally agree.

--

-- 
Vegard
Permalink | Reply | 1 comment |
headers
Frank Fischer | 2 Mar 2011 10:12
Picon

Re: Vimpulse and vim-mode

Am Dienstag, 1. März 2011 schrieb Vegard Øye:
> On 2011-03-01 18:41 +0100, Tim Harper wrote:
> > Perhaps it's just me, but if it's a choice between interoperability
> > with Emacs at the cost of 97% compatibility with vim, and 100%
> > compatibility with them at the cost of reduced interoperability
> > with Emacs commands, I would prefer sacrificing the vim
> > compatibility. If 100% vim compatibility were important to me, I
> > would use vim.
>
> Well put. I totally agree.

I also agree. But I AM one of those who use both, vim and emacs, vim for 
quick changes and emacs for the real stuff, and sometimes even trivial 
differences become, well, not problems but nconveniences, if your 
fingers decide on their own which keys to press. For example, I once 
got a bug-report, because vim-mode placed cursor after a search-word 
command * after the found occurence (inherited from isearch that time) 
while vim puts the cursor at the beginning of that word. The reporter 
was used to type * again to repeat the search which did not work in 
vim-mode because the cursor was not ON the word. I never realized that 
this was problem because I'm used to type n to repeat the search - but 
everyone has its own workflow and so this was a valid bug-report.

I completely agree that we should not focus on 100% vim compatibility 
(even sometimes Vim does things wrong IMO). We should just be prepared 
that sometimes incompatibilities or inconveniences may arise that are 
no problem for one user but are important for the other (and this with 
a good reason as the example above illustrates). So if the effort is 
not too big we should try to be as close as possible to vim without 
overemphasizing this goal.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane