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

_______________________________________________
implementations-list mailing list
[email protected]
https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list

Reply via email to