all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Mauro Aranda <maurooaranda@gmail.com>,
	"Basil L. Contovounesios" <contovob@tcd.ie>
Cc: 35536@debbugs.gnu.org, monnier@iro.umontreal.ca
Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp
Date: Sat, 4 May 2019 19:34:08 +0200	[thread overview]
Message-ID: <7e48a3d5-73c4-b153-8603-376fb9d757d5@gmx.at> (raw)
In-Reply-To: <CABczVweRE2J_Bh7NOt_4L_gLDQHtc=UEqvfdVp7L6At5abxFNA@mail.gmail.com>

 >> A save+restore primitive like the one you suggested in your other
 >> message sounds like it might do the trick without having to expose a
 >> buffer's marker list to Lisp.
 >
 > Indeed.  I thought Martin was talking about something like this in his post
 > in bug#18.  Given a region where text is going to be replaced, save the
 > positions of markers that would be affected because of the delete+insert,
 > and then restore them.

More precisely I would try to save the contexts of the old marker
positions similar to what we do with bookmarks and try to find these
contexts in the replaced region.  The important aspect is obviously
that this step can be skipped for regions left alone by compareseq (or
whatever was used) because in those (hopefully large) regions markers
are preserved automatically.  Some care would be needed for markers
that sit precisely at the bounds of these region and have the "wrong"
insertion type.  And maybe we should optionally give the cursor a
different color if it was not possible to restore it unequivocally.

The approach would be IMHO useful when reverting buffers after code
has been wrongly reindented or commented in or out.  I'm afraid that
it might not be overly useful for auto-reverted dired buffers and
buffers with many fine-grained modifications.

Which markers should be restored this way and whether the
corresponding code should be provided as a primitive or in Elisp is a
decision I leave to knowledgeable people.  I'd be already happy if
'point-marker' were handled that way.

martin





  reply	other threads:[~2019-05-04 17:34 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-02 15:44 bug#35536: 27.0.50; Expose buffer's marker list to Elisp Basil L. Contovounesios
2019-05-02 16:07 ` Eli Zaretskii
2019-05-02 16:51   ` Basil L. Contovounesios
2019-05-02 17:41     ` Eli Zaretskii
2019-05-03 15:50       ` Basil L. Contovounesios
2019-05-03 16:38         ` Drew Adams
2019-05-03 17:22           ` Basil L. Contovounesios
2019-05-03 17:31             ` Drew Adams
2019-05-03 17:39             ` Stefan Monnier
2019-05-03 17:53               ` Drew Adams
2019-05-03 18:13                 ` Stefan Monnier
2019-05-03 20:05                   ` Drew Adams
2019-05-04 21:25                   ` Richard Stallman
2019-09-16 21:07                     ` Lars Ingebrigtsen
2019-05-03 23:01     ` Mauro Aranda
2019-05-04 17:34       ` martin rudalics [this message]
2019-05-02 19:59 ` Stefan Monnier
2019-05-02 20:05   ` Eli Zaretskii
2019-05-03 15:50   ` Basil L. Contovounesios
2019-05-03 17:09     ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7e48a3d5-73c4-b153-8603-376fb9d757d5@gmx.at \
    --to=rudalics@gmx.at \
    --cc=35536@debbugs.gnu.org \
    --cc=contovob@tcd.ie \
    --cc=maurooaranda@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.