From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Date: Sat, 4 May 2019 19:34:08 +0200 Message-ID: <7e48a3d5-73c4-b153-8603-376fb9d757d5@gmx.at> References: <87lfzo274b.fsf@tcd.ie> <83ef5gq1po.fsf@gnu.org> <87imusztof.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="253358"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35536@debbugs.gnu.org, monnier@iro.umontreal.ca To: Mauro Aranda , "Basil L. Contovounesios" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat May 04 19:35:32 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hMyZP-0013nA-LG for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 May 2019 19:35:31 +0200 Original-Received: from localhost ([127.0.0.1]:59361 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMyZO-0005zj-N0 for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 May 2019 13:35:30 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34067) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMyYx-0005oG-HE for bug-gnu-emacs@gnu.org; Sat, 04 May 2019 13:35:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMyYw-0003PL-Hm for bug-gnu-emacs@gnu.org; Sat, 04 May 2019 13:35:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38622) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hMyYw-0003PH-E7 for bug-gnu-emacs@gnu.org; Sat, 04 May 2019 13:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hMyYw-0003ZA-8l for bug-gnu-emacs@gnu.org; Sat, 04 May 2019 13:35:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 May 2019 17:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35536 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.155699126813636 (code B ref 35536); Sat, 04 May 2019 17:35:02 +0000 Original-Received: (at 35536) by debbugs.gnu.org; 4 May 2019 17:34:28 +0000 Original-Received: from localhost ([127.0.0.1]:52162 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMyYO-0003Xs-6W for submit@debbugs.gnu.org; Sat, 04 May 2019 13:34:28 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:43685) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMyYM-0003Xb-Ea for 35536@debbugs.gnu.org; Sat, 04 May 2019 13:34:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1556991251; bh=oXPAgwDSBGZ9MpwrBeQZ4fRsX9FXx41sRjbR5bdOUKc=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=E8JySURhm0Bnvi2Io0/WEKvlX4h0fCcsUOs98vLR1SPtDzm9HGf7CY8Z+KE1MKzKU eediwzBK1l34IWw+m2CcabMZVfZJ4MAOa0rwR3aN1pGsqAYegqza0+2stbgpN8xYI3 ACDRDMAIV2HhF8hbeCRDti2RcErtUhJwnSuAFUpI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.132]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LtlG5-1gdQYA1a5d-011AXz; Sat, 04 May 2019 19:34:11 +0200 In-Reply-To: Content-Language: de-DE X-Provags-ID: V03:K1:SH/BZnzgfofVMP6+eqiCca+vIVdAAzIu9MFpxHPHzbJxwDOTIcm Ln7bHs1sdelnf9LmMFLy7anNMd5XXzg7FBPwPiYMyb/PS2r9G+im8bfEeLgFIlOsbxfS0+5 JLEgUDhvJK1vf+L/R3fxF245Yqi40h3qXO5uHoUj//uoZf4gqt9TLtjPbigKCaM3TXJENNQ 86PmwbXwGAV0aWSDLMMSw== X-UI-Out-Filterresults: notjunk:1;V03:K0:e/3ndjJ8VFE=:LBVp+vc0RKcBzv2GOzJTq6 aIMw5kCHIZFbB7JoILXu5xjAaD0xdZQ9yuqpi3V0nIvdtauXRaMDiMQTSN7qRQOQI7pPEMLcu y5tSx4rveicE/HNzOmsiNY4DX8ypgQg+xdtM6rEN3rV3kr2SQ229oQAcl3jX7hdxM4nz5+dN+ d58KHREBHx5BVQ+UUTeg/AVKvgK0AKXGfBbsS8ssI4GkMSXRccHbQT0Zjb8HGBLjnSEby+0ug d1r4PiLuGpqzN8PP/oxrJvg1dkxR0xud8jVMKFe1LO96ruN7NUuJNSHQcL3OsZma3g737ZbLC HPb4we39q8FHT/aMHT+sYtlbHFu/Z+bKl8AcYrlEncybdmgNee+n8OwE8pU7YzFx6ZP8NsKrz IGDgAVpz2DrXCHmiLwarAsM0+ZFc+7+VNkGEcEFIfHtrxKFTcrFvoD9bw0mpycj0Xb8X2FEoR yuxcfTao47BHem2EEHdKM/wFJy25g0Rbza1EsRpybvt46W4+LzKhmk4OKaMdWJQukvy8IlxV1 rCzoYMJbQG3f0C2efUFB+wQwlbaHw75fROL5FaT9mIcOE7AZXCeILh9KBKTghddjaN441UPaZ tNDQKX1wzoP2CbZLeKgCadCtAl3u/vF1ukwSFcQksQY+BedhK2GL245crNnvVUDPEPBYbFxPv oio8jJurhjUc0hGFbsWSlIEoiCjC2Vj0LsEENp5IXXkrMZJvNSC4kZLAjl7j8Uk7VCTDvISI1 GRkLTmQyakbiQA16IuxBtMW0w/FfWnZRV8f49etCFJmyPxt61FSt2KRbsR6U1FRjCO0fXxOR X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:158750 Archived-At: >> 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