vimpulse C-o not using global marks ?!?

Štěpán Němec stepnem at
Mon Aug 2 13:37:46 CEST 2010

Vegard Øye <vegard_oye at> writes:

> On 2010-07-25 21:18, ??t??p??n N??mec wrote:
>> Vegard ??ye <vegard_oye at> writes:
>>> Where is the conflict/difference?
>> From the POV of implementing Vim-like C-o/C-i, I don't care when
>> `push-mark' is called; I care about the specific commands listed in
>> :h jump-motions and I need an independent global data structure (and
>> most probably advising the relevant commands), because:
>> - behaviour of `push-mark' WRT `global-mark-ring' depends on whether
>>   the last global mark pushed was in the current buffer or not; if
>>   yes, only a local mark is pushed, which is without any use for
>>   jumping between files/buffers
>> - unlike e.g. registers, Emacs markers are useful only as long as
>>   the buffer where they point to exists; that's again not what I
>>   need -- for Vim-like jumps, it's completely legal to jump to a
>>   file which is not visited any more and have the file reopened
> Thanks for the (detailed) exposition; this I can work with. :)
> I've added a /rough/ sketch in commit [70e470f6fe], which utilizes
> both the global mark ring and the ordinary, buffer-local one.
> It's not bound by default, so add

Well from my point of view you don't have to do *anything*. :-) I
currently don't care enough to finish what I began, and obviously
TheLonelyStar doesn't either, judging from absence of any follow up.

>     (define-key viper-vi-basic-map "\C-o" 'vimpulse-jump-backward-globally)
> to .emacs or some such to test it.

OK. I haven't tested it yet, but looking at the code, I'm not
optimistic. :-) AFAICS it doesn't consider any of what I wrote above
(and tried to implement). If you don't like what I wrote or the way I
went about implementing it, that's fine, but I'd like to know _what_ you
don't like and _why_.

> Although, when I come to think of it, wouldn't a separate Git branch
> be better for testy things?

I think it definitely would, yeah.


More information about the implementations-list mailing list