TheLonelyStar <[email protected]> writes:
Hi,
I use vimpulse. When I do C-o it jumps to the last mark in the current file. Can i somehow make it use global marks?
Hi, let's have this discussion on the vim-emulation list, which I am hereby Cc:-ing (and please remove the help list from the Cc: header when replying; I don't think most people here are interested in this). I consider this to be a problem, too, and even started to implement it before some time, but as I almost never use it and nobody else seemed to ever mention this, it remained a stub, i.e. it sort-of works, but a bit funnily and not quite as in Vim (yet). Here is what I came up with (you can apply the diff provided you use the Git repository, not the single vimpulse.el file): Štěpán
On 2010-07-23 16:16, Štěpán Němec wrote:
I consider this to be a problem, too, and even started to implement it before some time, but as I almost never use it and nobody else seemed to ever mention this, it remained a stub, i.e. it sort-of works, but a bit funnily and not quite as in Vim (yet).
Why not keep the existing code, but extend it to use the global mark ring (C-x C-<SPC>)? There's already a convention for larger movement commands to set the mark (so that C-x C-x jumps back to the previous position). -- Vegard
Vegard Øye <[email protected]> writes:
On 2010-07-23 16:16, Štěpán Němec wrote:
I consider this to be a problem, too, and even started to implement it before some time, but as I almost never use it and nobody else seemed to ever mention this, it remained a stub, i.e. it sort-of works, but a bit funnily and not quite as in Vim (yet).
Why not keep the existing code, but extend it to use the global mark ring (C-x C-<SPC>)? There's already a convention for larger movement commands to set the mark (so that C-x C-x jumps back to the previous position).
Well, yeah -- it again boils down to what we (and the majority of Vimpulse users) really want: Vim compatibility (in that case a rewrite in the direction the stub attempts would be in order), or some other kind of useful behaviour (whatever that means)? I don't care all that much in this case -- Emacs provides both local and global mark commands (i.e. I'm actually currently using C-u C-SPC for what you're using C-o now). *But* if I recollect correctly, when I made those changes, I didn't really see an easy way to use vanilla Emacs functionality to achieve Vim's C-i/C-o, that's why I went for the ring+advice approach. And it actually seemed to work (right? :-)) for the functions defined as jumps in Vim documentation, only the search commands are missing (I think). But you like your local C-i/C-o, don't you? :-) (Also, I'm not sure I understand what you're saying/proposing -- the problem is that in Emacs the buffer-local vs. global marks distinction is fundamental and very clear cut, unlike Vim, where there is an explicitely defined set of jump commands, no matter where they take you (see :h jump-motions), and jumps are independent of marks. I don't see how you want to reconcile the two.) Štěpán
On 2010-07-24 21:42, Štěpán Němec wrote:
Also, I'm not sure I understand what you're saying/proposing -- the problem is that in Emacs the buffer-local vs. global marks distinction is fundamental and very clear cut, unlike Vim, where there is an explicitely defined set of jump commands, no matter where they take you (see :h jump-motions), and jumps are independent of marks. I don't see how you want to reconcile the two.
I'm confused ... Vim's jump list is a list of positions. Emacs' mark rings are also lists of positions. The ordinary mark ring lists positions in the current buffer, while the global mark ring lists positions in all buffers. Every time a command calls `push-mark', it records the present position in these lists. It is customary for larger movement commands to record the position before moving point. Both Emacs' standard commands and those defined by Viper heed this convention. The present implementation of C-o uses the ordinary mark ring and corresponds to Emacs' C-u C-<SPC>. A global implementation could use the global mark ring, corresponding to C-x C-<SPC>. Where is the conflict/difference? -- Vegard
Vegard Øye <[email protected]> writes:
On 2010-07-24 21:42, Štěpán Němec wrote:
Also, I'm not sure I understand what you're saying/proposing -- the problem is that in Emacs the buffer-local vs. global marks distinction is fundamental and very clear cut, unlike Vim, where there is an explicitely defined set of jump commands, no matter where they take you (see :h jump-motions), and jumps are independent of marks. I don't see how you want to reconcile the two.
I'm confused ...
Vim's jump list is a list of positions. Emacs' mark rings are also lists of positions. The ordinary mark ring lists positions in the current buffer, while the global mark ring lists positions in all buffers.
Vim's jump list and Emacs' mark rings are quite different (see below).
Every time a command calls `push-mark', it records the present position in these lists. It is customary for larger movement commands to record the position before moving point. Both Emacs' standard commands and those defined by Viper heed this convention.
That's a rather over-simplifying description (see below).
The present implementation of C-o uses the ordinary mark ring and corresponds to Emacs' C-u C-<SPC>. A global implementation could use the global mark ring, corresponding to C-x C-<SPC>.
AFAICT it couldn't (see below).
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 Štěpán
On 2010-07-25 21:18, ??t??p??n N??mec wrote:
Vegard ??ye <[email protected]> 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 (define-key viper-vi-basic-map "\C-o" 'vimpulse-jump-backward-globally) to .emacs or some such to test it. Although, when I come to think of it, wouldn't a separate Git branch be better for testy things? -- Vegard
Vegard Øye <[email protected]> writes:
On 2010-07-25 21:18, ??t??p??n N??mec wrote:
Vegard ??ye <[email protected]> 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. Štěpán
On 2010-08-02 13:37, Štěpán Němec wrote:
Vegard Øye <[email protected]> writes:
I've added a /rough/ sketch in commit [70e470f6fe], which utilizes both the global mark ring and the ordinary, buffer-local one.
AFAICS it doesn't consider any of what I wrote above (and tried to implement).
It currently doesn't restore buffers, which it should. One way to implement that would be for the advice of `push-mark' to "monitor" newly pushed markers and record the visited file in an association list. Then, when "C-o" encounters a marker in no buffer, it looks up the marker in the list and reopens the associated file, if any.
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_.
I prefer making use of an existing convention (that of calling `push-mark') to introducing a new convention (that of calling `vimpulse-record-jump'). The latter requires more Vimpulse knowledge on the part of extension writers. Then again, the cost of Vimpulse specifics may be justified if the main goal is maximum Vim fidelity. There's something of a philosophical debate here: should Vimpulse emulate Vim as faithfully as possible, or should it just provide a modal interface to Emacs' facilities? Vimpulse's integration with isearch is an example of the latter, since it's not a pixel perfect emulation of Vim's search, but provides functionality which Vim does not. I think it's better, but a "purist" may disagree.
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.
Okay; I've created a "global-marks" branch where "C-o" is global by default (i.e., no need to rebind it). -- Vegard
participants (2)
-
Vegard Øye -
Štěpán Němec