From unknown Mon Jun 23 20:20:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Resent-From: "Basil L. Contovounesios" Original-Sender: "Debbugs-submit" Resent-CC: rudalics@gmx.at, maurooaranda@gmail.com, monnier@iro.umontreal.ca, bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 May 2019 15:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 35536 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: 35536@debbugs.gnu.org Cc: martin rudalics , Mauro Aranda , Stefan Monnier X-Debbugs-Original-To: bug-gnu-emacs@gnu.org X-Debbugs-Original-Xcc: martin rudalics , Mauro Aranda , Stefan Monnier Received: via spool by submit@debbugs.gnu.org id=B.155681191426390 (code B ref -1); Thu, 02 May 2019 15:46:01 +0000 Received: (at submit) by debbugs.gnu.org; 2 May 2019 15:45:14 +0000 Received: from localhost ([127.0.0.1]:46770 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMDtZ-0006rZ-Sn for submit@debbugs.gnu.org; Thu, 02 May 2019 11:45:14 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49785) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMDtX-0006rG-Ek for submit@debbugs.gnu.org; Thu, 02 May 2019 11:45:12 -0400 Received: from lists.gnu.org ([209.51.188.17]:47678) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hMDtS-0000w9-8g for submit@debbugs.gnu.org; Thu, 02 May 2019 11:45:06 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35931) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMDtQ-0005Uq-DJ for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 11:45:06 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMDtO-0000vI-IB for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 11:45:04 -0400 Received: from mail-ed1-x541.google.com ([2a00:1450:4864:20::541]:39697) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hMDtN-0000uv-Mo for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 11:45:02 -0400 Received: by mail-ed1-x541.google.com with SMTP id e24so2536729edq.6 for ; Thu, 02 May 2019 08:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:user-agent:mime-version; bh=dZ1Fvg7Ch0aUJiPFvis44TXCJKFNMk4UfQ5zNdPMxZE=; b=vbYOsrL2fSBmGcswDWEQvVhnNLXQAMVRvB0srhsFNPM6lVtPl6cJiBqQD71XqQVZL2 +TRhmLsuRV022ZOJWLvyO2lYswc49p9IXxrQ5nKKfORvNhDJT3lJmJvAOf8tRNBmZgeR U6NobTy7/7zQcs9YVrXYDI4uRIiAzxfZo9D5ybwnhxEEpE90CxMLVkWSnGb/6YYLY3Mm YTjnjufynA0hTWR7O2YRhJkcE5Y5/7wdYPuDAA4BIcb1eyPueYsBQuYqs1NeDNu1FGNY NmwfaYiKvKipGgMKzjOJpqin18TyrDwyYOVcwBNDF1VIBkDCeqaYYOiVplpw4sUrnBYg iRhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :mime-version; bh=dZ1Fvg7Ch0aUJiPFvis44TXCJKFNMk4UfQ5zNdPMxZE=; b=fssi1UlWUOQH203j+NRaBG3AddCAAku5V9UNuxbiz1h0FbAs+n3lokLkaQ/YXrhLJn 9pUqLfosKL/x+SGKi5xSfnkfk8J9A9LSNzAGNU/UySWod3d+IOtMJaDv/ZdmJfpKER9I aS4uzj7qDpCqjN4P4mr/5yWK5LLw/zZDvWGnRcp6JEfi0+Ajvkp2iSxGZr0JMrHCqIgS kjK62MuyWEsPqFNu6hd82kuo9M4qVifnnkPg1E5Iv+jzOAOq3AWU+q+9KyU4Uyv6venJ YJRN23ILv6xgUpbbqM1iXkkNi4n6sgKcTz1d+BjrQU6mQjPnSuXVhWUO0jCEYG6REqax 06Zg== X-Gm-Message-State: APjAAAWQ84ba5/WhVZwYHOKMdSiAi1+MJ4CDL5RJHpDwbjs6TdFfs93r 3ZY8qd+zeFA0o7ZD5/AQ6UtIldaLWSI= X-Google-Smtp-Source: APXvYqxv9FKfwVYCPOQs2VlzW5mKbOT84V/VykCngmbDwaxEcnKyXFp53J+Tz+HxjawYLcFV6YoHDQ== X-Received: by 2002:aa7:c919:: with SMTP id b25mr3073926edt.274.1556811899122; Thu, 02 May 2019 08:44:59 -0700 (PDT) Received: from localhost ([2a02:8084:20e2:c380:8cad:ae29:555d:852d]) by smtp.gmail.com with ESMTPSA id e4sm1871551ejm.50.2019.05.02.08.44.57 for (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 02 May 2019 08:44:58 -0700 (PDT) From: "Basil L. Contovounesios" Date: Thu, 02 May 2019 16:44:52 +0100 Message-ID: <87lfzo274b.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::541 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain Severity: wishlist Tags: patch --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-Add-function-marker-list.patch >From c3c864a034ceb5c43fb791721a4b5c40f4122228 Mon Sep 17 00:00:00 2001 From: "Basil L. Contovounesios" Date: Tue, 30 Apr 2019 00:17:02 +0100 Subject: [PATCH] Add function marker-list Suggested by Martin Rudalics in: https://debbugs.gnu.org/18#47 * doc/lispref/markers.texi (Marker Information): Rename from 'Information from Markers'. All references changed. Document marker-list. * etc/NEWS (Changes in Emacs 27.1): Announce marker-list. * src/data.c (syms_of_data): Define Flss symbol for passing to Fsort. * src/marker.c (Fcopy_marker): Fix indentation. (Fbuffer_has_markers_at): Coerce argument to a fixnum before passing it to XFIXNUM. (Fmarker_list): New function for listing markers in a given region. (syms_of_marker): Define subr Smarker_list. * test/src/marker-tests.el (marker-set-window-start-from-other-buffer): Simplify. (marker-list, marker-list-buffer-change): New tests. --- doc/lispref/elisp.texi | 2 +- doc/lispref/markers.texi | 22 +++++++++++------- etc/NEWS | 5 ++++ src/data.c | 1 + src/marker.c | 40 ++++++++++++++++++++++++++------ test/src/marker-tests.el | 50 ++++++++++++++++++++++++++++++++++------ 6 files changed, 97 insertions(+), 23 deletions(-) diff --git a/doc/lispref/elisp.texi b/doc/lispref/elisp.texi index e18759654d..67c3e860aa 100644 --- a/doc/lispref/elisp.texi +++ b/doc/lispref/elisp.texi @@ -1168,7 +1168,7 @@ Top * Overview of Markers:: The components of a marker, and how it relocates. * Predicates on Markers:: Testing whether an object is a marker. * Creating Markers:: Making empty markers or markers at certain places. -* Information from Markers::Finding the marker's buffer or character position. +* Marker Information:: Finding the marker's buffer or character position. * Marker Insertion Types:: Two ways a marker can relocate when you insert where it points. * Moving Markers:: Moving the marker to a new buffer or position. diff --git a/doc/lispref/markers.texi b/doc/lispref/markers.texi index 27fe1414f0..d18cad2eb8 100644 --- a/doc/lispref/markers.texi +++ b/doc/lispref/markers.texi @@ -16,7 +16,7 @@ Markers * Overview of Markers:: The components of a marker, and how it relocates. * Predicates on Markers:: Testing whether an object is a marker. * Creating Markers:: Making empty markers or markers at certain places. -* Information from Markers:: Finding the marker's buffer or character position. +* Marker Information:: Finding the marker's buffer or character position. * Marker Insertion Types:: Two ways a marker can relocate when you insert where it points. * Moving Markers:: Moving the marker to a new buffer or position. @@ -271,12 +271,12 @@ Creating Markers @end group @end example -@node Information from Markers -@section Information from Markers +@node Marker Information +@section Marker Information @cindex marker information - This section describes the functions for accessing the components of a -marker object. +Several functions return information about markers. The next two +functions access components of a marker object. @defun marker-position marker This function returns the position that @var{marker} points to, or @@ -287,8 +287,6 @@ Information from Markers This function returns the buffer that @var{marker} points into, or @code{nil} if it points nowhere. -@c FIXME: The 'buffer' argument of 'set-marker' already defaults to -@c the current buffer, why use '(current-buffer)' explicitly here? @example @group (setq m (make-marker)) @@ -304,7 +302,7 @@ Information from Markers @end group @group -(set-marker m 3770 (current-buffer)) +(set-marker m 3770) @result{} # @end group @group @@ -318,6 +316,14 @@ Information from Markers @end example @end defun +@defun marker-list &optional beg end +This function returns an ordered list of the markers in the accessible +range of the current buffer. If @var{beg} is non-@code{nil}, only +markers pointing at that position are included. If @var{end} is also +non-@code{nil}, all markers in the region @var{beg} through @var{end} +are included. +@end defun + @node Marker Insertion Types @section Marker Insertion Types diff --git a/etc/NEWS b/etc/NEWS index 9e3559d27e..dc5923a293 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -340,6 +340,11 @@ longer. ** Multicolor fonts such as "Noto Color Emoji" can be displayed on Emacs configured with Cairo drawing and linked with cairo >= 1.16.0. ++++ +** New function 'marker-list'. +This function returns a list of markers in the current buffer within a +given region. + * Editing Changes in Emacs 27.1 diff --git a/src/data.c b/src/data.c index 476d28eadb..0bf841e928 100644 --- a/src/data.c +++ b/src/data.c @@ -3852,6 +3852,7 @@ syms_of_data (void) DEFSYM (Qmany, "many"); DEFSYM (Qcdr, "cdr"); + DEFSYM (Qlss, "<"); error_tail = pure_cons (Qerror, Qnil); diff --git a/src/marker.c b/src/marker.c index b58051a8c2..d132a43c09 100644 --- a/src/marker.c +++ b/src/marker.c @@ -712,7 +712,8 @@ see `marker-insertion-type'. */) register Lisp_Object new; if (!NILP (marker)) - CHECK_TYPE (FIXNUMP (marker) || MARKERP (marker), Qinteger_or_marker_p, marker); + CHECK_TYPE (FIXNUMP (marker) || MARKERP (marker), + Qinteger_or_marker_p, marker); new = Fmake_marker (); Fset_marker (new, marker, @@ -749,18 +750,42 @@ DEFUN ("buffer-has-markers-at", Fbuffer_has_markers_at, Sbuffer_has_markers_at, doc: /* Return t if there are markers pointing at POSITION in the current buffer. */) (Lisp_Object position) { - register struct Lisp_Marker *tail; - register ptrdiff_t charpos; + CHECK_FIXNUM_COERCE_MARKER (position); + ptrdiff_t charpos = clip_to_bounds (BEG, XFIXNUM (position), Z); - charpos = clip_to_bounds (BEG, XFIXNUM (position), Z); - - for (tail = BUF_MARKERS (current_buffer); tail; tail = tail->next) - if (tail->charpos == charpos) + for (struct Lisp_Marker *m = BUF_MARKERS (current_buffer); m; m = m->next) + if (m->charpos == charpos) return Qt; return Qnil; } +DEFUN ("marker-list", Fmarker_list, Smarker_list, 0, 2, 0, + doc: /* Return a list of markers in the accessible range of the buffer. +If BEG is non-nil, include only markers pointing at that position. +If END is also non-nil, include all markers in the region BEG +through END. */) + (Lisp_Object beg, Lisp_Object end) +{ + ptrdiff_t b, e; + if (NILP (beg)) + b = BEGV, e = ZV; + else + { + validate_region (&beg, NILP (end) ? &beg : &end); + b = XFIXNAT (beg); + e = NILP (end) ? b : XFIXNAT (end); + } + + Lisp_Object markers = Qnil; + + for (struct Lisp_Marker *m = BUF_MARKERS (current_buffer); m; m = m->next) + if (b <= m->charpos && m->charpos <= e) + markers = Fcons (make_lisp_ptr (m, Lisp_Vectorlike), markers); + + return Fsort (markers, Qlss); +} + #ifdef MARKER_DEBUG /* For debugging -- count the markers in buffer BUF. */ @@ -807,4 +832,5 @@ syms_of_marker (void) defsubr (&Smarker_insertion_type); defsubr (&Sset_marker_insertion_type); defsubr (&Sbuffer_has_markers_at); + defsubr (&Smarker_list); } diff --git a/test/src/marker-tests.el b/test/src/marker-tests.el index 79e298d8c2..cbafabb556 100644 --- a/test/src/marker-tests.el +++ b/test/src/marker-tests.el @@ -29,16 +29,15 @@ (ert-deftest marker-set-window-start-from-other-buffer () "`set-window-start' from other buffer's marker." (let ((text-quoting-style 'curve)) - (describe-function 'describe-function)) - (let* ((help (get-buffer "*Help*")) - (marker (with-current-buffer help - (copy-marker (point-max))))) + (describe-function #'describe-function)) + (let ((marker (with-current-buffer "*Help*" + (copy-marker (point-max))))) (should (set-window-start (selected-window) marker)))) (ert-deftest marker-set-window-point-from-other-buffer () "`set-window-point' from another buffer's marker." (let ((text-quoting-style 'curve)) - (describe-function 'describe-function)) + (describe-function #'describe-function)) (let* ((help (get-buffer "*Help*")) (marker (with-current-buffer help (copy-marker (point-max))))) @@ -48,13 +47,50 @@ (ert-deftest marker-goto-char-from-other-buffer () "`goto-char' from another buffer's marker." (let ((text-quoting-style 'curve)) - (describe-function 'describe-function)) + (describe-function #'describe-function)) (let ((marker-1 (make-marker)) (marker-2 (make-marker))) - (describe-function 'describe-function) + (describe-function #'describe-function) (with-current-buffer "*Help*" (set-marker marker-1 (point-max))) (set-marker marker-2 marker-1) (should (goto-char marker-2)))) +(ert-deftest marker-list () + "Test `marker-list' behavior." + (with-temp-buffer + ;; No markers created yet. + (should-not (marker-list)) + (insert "first\nsecond\n") + (forward-line -1) + (let ((markers (list (point-min-marker) (point-max-marker)))) + ;; Check marker arguments. + (should (equal (apply #'marker-list markers) markers)) + (save-restriction + (narrow-to-region (point) (line-end-position)) + ;; Check accessible range of buffer. + (should-not (marker-list)) + ;; Check invalid region. + (should-error (apply #'marker-list markers) + :type 'args-out-of-range))) + ;; Check single position and that mark is included. + (let ((marker (set-marker (mark-marker) (point)))) + (should (equal (marker-list (point)) (list marker)))) + ;; Check that unchained markers are not included. + (dolist (marker (marker-list)) + (set-marker marker nil)) + (should-not (marker-list)))) + +(ert-deftest marker-list-buffer-change () + "Test `marker-list' behavior across buffer changes." + (with-temp-buffer + (let ((marker (point-marker)) + (markers (marker-list))) + (with-temp-buffer + (set-marker marker (point)) + (should (equal (marker-list) (list marker))) + (should (equal (mapcar #'marker-buffer markers) + (list (current-buffer))))) + (should-not (marker-list))))) + ;;; marker-tests.el ends here. -- 2.20.1 --=-=-= Content-Type: text/plain The question of listing a buffer's markers has been raised before: https://debbugs.gnu.org/18#47 https://lists.gnu.org/archive/html/help-gnu-emacs/2016-06/msg00050.html https://lists.gnu.org/archive/html/emacs-devel/2007-04/msg01391.html I attach a patch implementing this based on BUF_MARKERS, as per Martin's suggestion. Any reasons not to expose such a function? Thanks, -- Basil In GNU Emacs 27.0.50 (build 4, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2019-04-30 built on thunk Repository revision: 910d170771ac74ab76d6dcb2dda3f3167e01b705 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12003000 System Description: Debian GNU/Linux buster/sid --=-=-=-- From unknown Mon Jun 23 20:20:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 May 2019 16:09: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 To: "Basil L. Contovounesios" Cc: 35536@debbugs.gnu.org, maurooaranda@gmail.com, monnier@iro.umontreal.ca Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.155681329528782 (code B ref 35536); Thu, 02 May 2019 16:09:02 +0000 Received: (at 35536) by debbugs.gnu.org; 2 May 2019 16:08:15 +0000 Received: from localhost ([127.0.0.1]:46803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMEFq-0007U9-R9 for submit@debbugs.gnu.org; Thu, 02 May 2019 12:08:15 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55525) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMEFp-0007Tu-3D for 35536@debbugs.gnu.org; Thu, 02 May 2019 12:08:13 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46284) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMEFj-0008MM-Mv; Thu, 02 May 2019 12:08:07 -0400 Received: from [176.228.60.248] (port=4804 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hMEFj-0003U5-99; Thu, 02 May 2019 12:08:07 -0400 Date: Thu, 02 May 2019 19:07:47 +0300 Message-Id: <83ef5gq1po.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87lfzo274b.fsf@tcd.ie> (contovob@tcd.ie) References: <87lfzo274b.fsf@tcd.ie> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: "Basil L. Contovounesios" > Date: Thu, 02 May 2019 16:44:52 +0100 > Cc: Mauro Aranda , > Stefan Monnier > > I attach a patch implementing this based on BUF_MARKERS, as per Martin's > suggestion. Any reasons not to expose such a function? I'm not yet convinced we need something like that, but in any case, is the order important? Because the code you propose produces a list in reverse order. More generally, I think we should discuss the need for this in more detail. Markers are used for several features, and there's internal stuff like conversion from character to byte positions that depends on them. Changing markers could thus easily crash Emacs, especially if it comes in some in-opportune moment. It is possible that people actually need higher-level primitives that manipulate markers internally. We should first identify the use cases where this could be needed, and then see how to help solving those use cases by something like a new marker-related primitive. From unknown Mon Jun 23 20:20:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Resent-From: "Basil L. Contovounesios" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 May 2019 16:52:03 +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 To: Eli Zaretskii Cc: 35536@debbugs.gnu.org, maurooaranda@gmail.com, monnier@iro.umontreal.ca Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.1556815882819 (code B ref 35536); Thu, 02 May 2019 16:52:03 +0000 Received: (at 35536) by debbugs.gnu.org; 2 May 2019 16:51:22 +0000 Received: from localhost ([127.0.0.1]:46873 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMEva-0000D9-Aq for submit@debbugs.gnu.org; Thu, 02 May 2019 12:51:22 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:34727) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMEvY-0000Cr-I7 for 35536@debbugs.gnu.org; Thu, 02 May 2019 12:51:21 -0400 Received: by mail-ed1-f67.google.com with SMTP id w35so1065671edd.1 for <35536@debbugs.gnu.org>; Thu, 02 May 2019 09:51:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=wtakKwjOKDjKMdb0VWryj+ahXINSHwNFc8i+wJUqawg=; b=Kj2cIMNnnN4VzqU+CdOxa2cU1kTHtOYzGKqsA2/fENGOoPvo7AqsP3HXWrcldrwBn9 HXY1fhT+j0ei1IE1677adpMIvFIX9DlFEHMQ3IYWtaLWy5Ir4krdc+GoxaYjIBvgEb6E M2eRyOKK47d2mD7tx0s/iWdeNK2chGsfuNDEgIAxwmu1g8AljhtFvSpxaP9FmobQ5RPA u7R2R9A5FHPcyGZbS8ACFq+zgkX4ndZgLKBS4uxtTxOzZFhKetTSLUPSSTNWQpHxmD5n Q/Tm1qGMihJ9ytaRRxAV/jfsf60TXtFQ42Ic1RIfulEiRqEqal8bgAq3u0lCvxBks08y 1/Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=wtakKwjOKDjKMdb0VWryj+ahXINSHwNFc8i+wJUqawg=; b=dZ2EHW36aNHn6FCZNyUwtlQrqx/BD2XS2Gjzk10HcfjHh31O6DzIeJs6mt4Sr9j8Ve 4wGtJJ/ZRIvQBQscSZVS+jdUTCtJOtYPu478ijW5AA2nm5A72SgiM4JB1ZFRtKlIbYCq riVNE7y/Hahn9HZe5KtoAX3bLotcqH7amX6kYath224uQBygEbCTQA8GS42l5RCOQib6 aESHjBoVl5WlKZ0NCJH6JTxRugGV2olSJYRn8dQpbFg7hF/wMM8ZqcIHpWnqDwj91OM+ +X5TOUTjzqWmoVDbTWoiQt9wzqaYfW9auqVikRvDQltQmqb0iTHZ6D7G//NaWypaOBds KFBw== X-Gm-Message-State: APjAAAW+/ga8EcrNTcBfZkH7jHnnz10Bwr7ePilSYIB9mnNMIQf1OW5g UWD5bRfKHKY8gA3aZyCoHUa+Gw== X-Google-Smtp-Source: APXvYqwzeN3TPNTIlncHWxyq1sh8g43X9JZ5wxXF49cejRYEboouJL6bt87XHA1rzSwOz5y1KqXPfQ== X-Received: by 2002:a05:6402:1499:: with SMTP id e25mr3232637edv.282.1556815874747; Thu, 02 May 2019 09:51:14 -0700 (PDT) Received: from localhost ([2a02:8084:20e2:c380:8cad:ae29:555d:852d]) by smtp.gmail.com with ESMTPSA id l6sm911054eja.91.2019.05.02.09.51.13 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 02 May 2019 09:51:13 -0700 (PDT) From: "Basil L. Contovounesios" References: <87lfzo274b.fsf@tcd.ie> <83ef5gq1po.fsf@gnu.org> Date: Thu, 02 May 2019 17:51:12 +0100 In-Reply-To: <83ef5gq1po.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 2 May 2019 19:07:47 +0300") Message-ID: <87imusztof.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: "Basil L. Contovounesios" >> Date: Thu, 02 May 2019 16:44:52 +0100 >> Cc: Mauro Aranda , >> Stefan Monnier >> >> I attach a patch implementing this based on BUF_MARKERS, as per Martin's >> suggestion. Any reasons not to expose such a function? > > I'm not yet convinced we need something like that, but in any case, is > the order important? Because the code you propose produces a list in > reverse order. The order of the returned list is in increasing buffer position, thanks to the call to Fsort. Is that not a reasonable order? > More generally, I think we should discuss the need for this in more > detail. Markers are used for several features, and there's internal > stuff like conversion from character to byte positions that depends on > them. Changing markers could thus easily crash Emacs, especially if > it comes in some in-opportune moment. Are you saying that BUF_MARKERS could include markers created by internal functions which could crash if these markers are changed across calls to other Lisp functions? If so, that sounds like a valid concern to a non-expert like me, but it also sounds like a bug waiting to happen, given that other C code also traverses and manipulates BUF_MARKERS. If not, I don't see how manipulating markers returned by marker-list is any worse than manipulating those created at the Lisp level, with the usual and documented risks associated with manipulating markers not owned by the caller. > It is possible that people actually need higher-level primitives that > manipulate markers internally. We should first identify the use cases > where this could be needed, and then see how to help solving those use > cases by something like a new marker-related primitive. I have yet to see a use-case for marker-list which can't be engineered in a different way (other than as a replacement for the obsolete buffer-has-markers-at, FWIW). Perhaps some of the CCed parties might have examples. Thanks, -- Basil From unknown Mon Jun 23 20:20:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 May 2019 17:43:01 +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 To: "Basil L. Contovounesios" Cc: 35536@debbugs.gnu.org, maurooaranda@gmail.com, monnier@iro.umontreal.ca Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.15568189505918 (code B ref 35536); Thu, 02 May 2019 17:43:01 +0000 Received: (at 35536) by debbugs.gnu.org; 2 May 2019 17:42:30 +0000 Received: from localhost ([127.0.0.1]:46947 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMFj3-0001XN-S2 for submit@debbugs.gnu.org; Thu, 02 May 2019 13:42:30 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33215) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMFj2-0001XB-93 for 35536@debbugs.gnu.org; Thu, 02 May 2019 13:42:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48452) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMFiw-00028k-Jn; Thu, 02 May 2019 13:42:22 -0400 Received: from [176.228.60.248] (port=2629 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hMFiu-0005yx-IT; Thu, 02 May 2019 13:42:21 -0400 Date: Thu, 02 May 2019 20:41:57 +0300 Message-Id: <8336lwpxcq.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87imusztof.fsf@tcd.ie> (contovob@tcd.ie) References: <87lfzo274b.fsf@tcd.ie> <83ef5gq1po.fsf@gnu.org> <87imusztof.fsf@tcd.ie> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: "Basil L. Contovounesios" > Cc: <35536@debbugs.gnu.org>, , > Date: Thu, 02 May 2019 17:51:12 +0100 > > Eli Zaretskii writes: > > >> From: "Basil L. Contovounesios" > >> Date: Thu, 02 May 2019 16:44:52 +0100 > >> Cc: Mauro Aranda , > >> Stefan Monnier > >> > >> I attach a patch implementing this based on BUF_MARKERS, as per Martin's > >> suggestion. Any reasons not to expose such a function? > > > > I'm not yet convinced we need something like that, but in any case, is > > the order important? Because the code you propose produces a list in > > reverse order. > > The order of the returned list is in increasing buffer position, thanks > to the call to Fsort. Is that not a reasonable order? Sorry, missed the sort. The question whether the order matters still stands, though. > > More generally, I think we should discuss the need for this in more > > detail. Markers are used for several features, and there's internal > > stuff like conversion from character to byte positions that depends on > > them. Changing markers could thus easily crash Emacs, especially if > > it comes in some in-opportune moment. > > Are you saying that BUF_MARKERS could include markers created by > internal functions which could crash if these markers are changed across > calls to other Lisp functions? Please don't forget that nowadays we call Lisp from many places in C, like from redisplay. We need to be very careful with this because I;m quite sure the display code doesn't expect markers to change at least in some of its paths. > If so, that sounds like a valid concern to a non-expert like me, but it > also sounds like a bug waiting to happen, given that other C code > also traverses and manipulates BUF_MARKERS. Emacs being designed using the MVC pattern, assumes that the buffers (and thus markers) don't change while they are being displayed. It has some probes for when this might happen as result of calling some hook, and when that is detected, we restart redisplay. I'm saying that enlarging the potential for such changes will need careful auditing of code that didn't expect such changes until now. It will also necessarily slow down redisplay. The question is: is that worth the hassle? If what is needed is some higher-level features, then exposing markers to Lisp will unnecessarily force us to do all that non-trivial auditing. So I suggest that we discuss the needs before coding, to see whether such low-level access to a central data structure is really needed and justified. > If not, I don't see how manipulating markers returned by marker-list is > any worse than manipulating those created at the Lisp level, with the > usual and documented risks associated with manipulating markers not > owned by the caller. Just reading the markers probably won't but do you really believe this is the last word? How many hours will it take for someone to ask for a primitive to set the C-level markers as well, or request the ability to map a function over all the markers? If it's really needed, sure, let's do it. But is it? Or are we doing that just because we can? > I have yet to see a use-case for marker-list which can't be engineered > in a different way (other than as a replacement for the obsolete > buffer-has-markers-at, FWIW). Well, the discussions you cited did express requirements whose implementation with the existing facilities was either inconvenient or restricted. If these problems are still relevant, then why not try providing some primitives to help them? IOW, let me turn the table and ask: why would a Lisp program want to get a list of all the markers in a buffer, especially those not created from Lisp? From unknown Mon Jun 23 20:20:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 May 2019 20:00: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 To: "Basil L. Contovounesios" Cc: 35536@debbugs.gnu.org, Mauro Aranda , martin rudalics Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.155682718826756 (code B ref 35536); Thu, 02 May 2019 20:00:02 +0000 Received: (at 35536) by debbugs.gnu.org; 2 May 2019 19:59:48 +0000 Received: from localhost ([127.0.0.1]:47071 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMHrw-0006xT-4u for submit@debbugs.gnu.org; Thu, 02 May 2019 15:59:48 -0400 Received: from mail01.iro.umontreal.ca ([132.204.25.201]:52702) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMHrt-0006xG-QU for 35536@debbugs.gnu.org; Thu, 02 May 2019 15:59:46 -0400 Received: from mail01.iro.umontreal.ca (mail01.iro.umontreal.ca [127.0.0.1]) by mail01.iro.umontreal.ca (Postfix) with ESMTP id 55456882C1D0 for <35536@debbugs.gnu.org>; Thu, 2 May 2019 15:59:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; h=content-type:content-type:mime-version:user-agent:in-reply-to :date:date:references:message-id:subject:subject:to:from:from; s=dkim; t=1556827179; x=1557691180; bh=RfA4t6YGgBKz/yNwZl/pZ25Q 1SC9kQzcGC/4HY48/Rg=; b=AwjdzOlObmtvZxSZ7/ivpF+UAjyPxoBDmNBk4PvS bnUpj1V7ouQDpzOlkphNfgDEtwCHsIABsKwRh/Q+78gd0wQgOnyCv+Z2O+lH7mDE QBxACbE0y2VAAZy1M9HdNiI1aZmOqb2/cQVQtLPZ+XLs7ZMZbjGtQUr4bp7LYrnF jw0T9XqyaNhcgbrIobSyEA2BVKo94DQ7nLHUvf9bV8pqBBnvOXd2OY+TcnFRSh97 4SR4P5I0QN0OdYbJ2hQ8lszzm+6Lq4MNIM469zxIW1tMjtPWjASCJEqKUo/qiCJ3 WmCRr/Oxfw7pYxb/SHeY2qcLTvpAv83syqxYZ64g6dU7tg== X-Virus-Scanned: amavisd-new at iro.umontreal.ca Received: from mail01.iro.umontreal.ca ([127.0.0.1]) by mail01.iro.umontreal.ca (mail01.iro.umontreal.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBqCKimCjKxC for <35536@debbugs.gnu.org>; Thu, 2 May 2019 15:59:39 -0400 (EDT) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPS id 7038E882C1BA; Thu, 2 May 2019 15:59:38 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87lfzo274b.fsf@tcd.ie> Date: Thu, 02 May 2019 15:59:38 -0400 In-Reply-To: <87lfzo274b.fsf@tcd.ie> (Basil L. Contovounesios's message of "Thu, 02 May 2019 16:44:52 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I attach a patch implementing this based on BUF_MARKERS, as per Martin's > suggestion. Any reasons not to expose such a function? AFAIK the main reason for such a function is so that you can implement "replace" functions which preserves markers better than "insert+delete" does, right? Arguably `replace-buffer-contents` reduced this need, but this is just one way to "guess" how to preserve the markers and for specific replacements there are surely other approaches which would work better, hence the desire to get access to the marker-list to write ad-hoc solutions. Random thoughts: - I wouldn't expose a `(marker-list)` function but rather `(markers-in BEG END)` so you're not bothered by unrelated markers outside of the region of interest. - The main problem I see is that some of the markers in BUF_MARKERS are "proper" markers, while others are just the markers that we happen to use in the current internal representation of overlays. If you can get your hands on those markers, you might end up breaking some invariants on which the C code relies (e.g. place the overlay-start after the overlay-end, or in a different buffer). - I think the serious risks (e.g. crashes) are solvable. E.g. there's room for an additional boolean field `lisp_marker` which could be used to distinguish those markers which can be safely returned (because they're normal Lisp-level markers already accessible from Lisp anyway) from the internal ones (such as those from overlays). - Then we'd probably want to discussion whether markers used within `save-excursion` and friends should be marked as `lisp_marker` or not. This said, as you say later: > I have yet to see a use-case for marker-list which can't be engineered > in a different way So, whether it's worth the trouble: I don't know. Stefan From unknown Mon Jun 23 20:20:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 May 2019 20:06:01 +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 To: Stefan Monnier Cc: contovob@tcd.ie, 35536@debbugs.gnu.org, maurooaranda@gmail.com Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.155682755027373 (code B ref 35536); Thu, 02 May 2019 20:06:01 +0000 Received: (at 35536) by debbugs.gnu.org; 2 May 2019 20:05:50 +0000 Received: from localhost ([127.0.0.1]:47084 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMHxl-00077Q-UY for submit@debbugs.gnu.org; Thu, 02 May 2019 16:05:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34841) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMHxj-000778-13 for 35536@debbugs.gnu.org; Thu, 02 May 2019 16:05:49 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51077) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMHxd-0003ij-BH; Thu, 02 May 2019 16:05:41 -0400 Received: from [176.228.60.248] (port=3589 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hMHxU-0002p7-NW; Thu, 02 May 2019 16:05:35 -0400 Date: Thu, 02 May 2019 23:05:11 +0300 Message-Id: <83pnp0oc5k.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Stefan Monnier on Thu, 02 May 2019 15:59:38 -0400) References: <87lfzo274b.fsf@tcd.ie> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Date: Thu, 02 May 2019 15:59:38 -0400 > Cc: 35536@debbugs.gnu.org, Mauro Aranda > > AFAIK the main reason for such a function is so that you can implement > "replace" functions which preserves markers better than "insert+delete" > does, right? If this is the use case, perhaps we could provide a function to save markers and then restore them, similar to current-window-configuration and set-window-configuration, but with opaque handles returned to the caller. From unknown Mon Jun 23 20:20:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Resent-From: "Basil L. Contovounesios" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 May 2019 15:51: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 To: Eli Zaretskii Cc: 35536@debbugs.gnu.org, maurooaranda@gmail.com, monnier@iro.umontreal.ca Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.155689862822809 (code B ref 35536); Fri, 03 May 2019 15:51:02 +0000 Received: (at 35536) by debbugs.gnu.org; 3 May 2019 15:50:28 +0000 Received: from localhost ([127.0.0.1]:49376 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMaSB-0005vo-T2 for submit@debbugs.gnu.org; Fri, 03 May 2019 11:50:28 -0400 Received: from mail-ed1-f65.google.com ([209.85.208.65]:42838) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMaS9-0005vc-V3 for 35536@debbugs.gnu.org; Fri, 03 May 2019 11:50:26 -0400 Received: by mail-ed1-f65.google.com with SMTP id l25so6542356eda.9 for <35536@debbugs.gnu.org>; Fri, 03 May 2019 08:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=SZ/nzA/j5M67vi1G/WJPlK+Ny88VHdIAE72RHSNjx90=; b=s0PH8PwgSiXTPprl6u9FYH9d1B7tiifFCBe3bSgR7CJdZyOzI/nazJlIbIz7gSfVN9 CqZ8aWWKD/60/gJBFGyhCxskGWOroXewVCofOU7RC9Cqlu3Esw1UP7bPK34h4Lt9pS1B CjgcTy+VPC2mISLbBU3dTRLccc7gMhNMFmvSF93PIt/NSKyF/tryM9zmSdgluIPdfUAx xQCiCsItM9exlYtnlwmSABkReDZSVPSrEc7UFvdCbBaC1rmw9Va0TQ5rCObGZNYUKfz0 qLRTXZiNr/uhpUmb1Li4h8LhEPpGTDHutKcPn1a0GUQhfamaPEb9BrlZl2l4Uy1whxwK KlHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=SZ/nzA/j5M67vi1G/WJPlK+Ny88VHdIAE72RHSNjx90=; b=EkWweFbzbaitjEeydaYmBUQOsWFFbu9spUUCo8y7RH0LBw4cGs+OUD2ye5KPAiakU5 8k2om8+rREQW1Q1e1AfRKAkCMDVhxrrv1rocwiuKN8dGVKxfKXeMIkaFaU1o03DGnZVQ LXlrDBylkU78+IEKIzXOu3BPyzbx2VYhtX0bUftEO3VioyjLYLNmabTIPj6EA2i364oV Vh0ZFrs9Esj2DiTD8sTOFmcdsQfYP5zDNDiq7objuZPhYAQcC6ZqXqKm+MUgG+wN+itG fX8AKjcQ4C4YclP5VqlA1VAnSNnh9KIL76ASe0MHkWH9ooRUr9kQBkHPWRie7d6pLMg5 NFBw== X-Gm-Message-State: APjAAAVjV4BBR0/T2BNHBSBNcqphENNXE0TG+Yz6xWias1hcr3WCEphB gcx6a5c+PBRF48zk0vQYKHnVjQ== X-Google-Smtp-Source: APXvYqz7Tr6Dyvhwxa5iiyKq3VjVNJ+UzBJhETL9hE1KzDNpdS+dTVGpeFWn8USsUIRdc2KT9wsqmw== X-Received: by 2002:a50:90db:: with SMTP id d27mr9369053eda.50.1556898620037; Fri, 03 May 2019 08:50:20 -0700 (PDT) Received: from localhost ([89.101.223.218]) by smtp.gmail.com with ESMTPSA id e35sm671503eda.2.2019.05.03.08.50.18 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 03 May 2019 08:50:19 -0700 (PDT) From: "Basil L. Contovounesios" References: <87lfzo274b.fsf@tcd.ie> <83ef5gq1po.fsf@gnu.org> <87imusztof.fsf@tcd.ie> <8336lwpxcq.fsf@gnu.org> Date: Fri, 03 May 2019 16:50:17 +0100 In-Reply-To: <8336lwpxcq.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 2 May 2019 20:41:57 +0300") Message-ID: <87sgtvczba.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: "Basil L. Contovounesios" >> Cc: <35536@debbugs.gnu.org>, , >> Date: Thu, 02 May 2019 17:51:12 +0100 >> >> Eli Zaretskii writes: >> >> >> From: "Basil L. Contovounesios" >> >> Date: Thu, 02 May 2019 16:44:52 +0100 >> >> Cc: Mauro Aranda , >> >> Stefan Monnier >> >> >> >> I attach a patch implementing this based on BUF_MARKERS, as per Martin's >> >> suggestion. Any reasons not to expose such a function? >> > >> > I'm not yet convinced we need something like that, but in any case, is >> > the order important? Because the code you propose produces a list in >> > reverse order. >> >> The order of the returned list is in increasing buffer position, thanks >> to the call to Fsort. Is that not a reasonable order? > > Sorry, missed the sort. The question whether the order matters still > stands, though. When asked for a list of markers between BEG and END, it makes sense to me to return a list which ascends from BEG to END. If it really matters, we could either return the order of BUF_MARKERS unchanged, or accept an additional argument which tells the function how to sort. >> > More generally, I think we should discuss the need for this in more >> > detail. Markers are used for several features, and there's internal >> > stuff like conversion from character to byte positions that depends on >> > them. Changing markers could thus easily crash Emacs, especially if >> > it comes in some in-opportune moment. >> >> Are you saying that BUF_MARKERS could include markers created by >> internal functions which could crash if these markers are changed across >> calls to other Lisp functions? > > Please don't forget that nowadays we call Lisp from many places in C, > like from redisplay. We need to be very careful with this because I;m > quite sure the display code doesn't expect markers to change at least > in some of its paths. Noted. >> If so, that sounds like a valid concern to a non-expert like me, but it >> also sounds like a bug waiting to happen, given that other C code >> also traverses and manipulates BUF_MARKERS. > > Emacs being designed using the MVC pattern, assumes that the buffers > (and thus markers) don't change while they are being displayed. It > has some probes for when this might happen as result of calling some > hook, and when that is detected, we restart redisplay. I'm saying > that enlarging the potential for such changes will need careful > auditing of code that didn't expect such changes until now. It will > also necessarily slow down redisplay. The question is: is that worth > the hassle? If what is needed is some higher-level features, then > exposing markers to Lisp will unnecessarily force us to do all that > non-trivial auditing. So I suggest that we discuss the needs before > coding, to see whether such low-level access to a central data > structure is really needed and justified. Thanks for explaining, sounds perfectly reasonable. I'm not convinced adding marker-list is worth the trouble. (FWIW, I'm not eager to blindly expose marker-list; I just opened a ticket to see what reservations there are, and to discuss this question I've seen pop up before. A bit of code always gives discussions a bit more ground, and it was an excuse for me to read a bit of the surrounding code.) >> If not, I don't see how manipulating markers returned by marker-list is >> any worse than manipulating those created at the Lisp level, with the >> usual and documented risks associated with manipulating markers not >> owned by the caller. > > Just reading the markers probably won't but do you really believe this > is the last word? How many hours will it take for someone to ask for > a primitive to set the C-level markers as well, or request the ability > to map a function over all the markers? If it's really needed, sure, > let's do it. But is it? Or are we doing that just because we can? So far, the latter. >> I have yet to see a use-case for marker-list which can't be engineered >> in a different way (other than as a replacement for the obsolete >> buffer-has-markers-at, FWIW). > > Well, the discussions you cited did express requirements whose > implementation with the existing facilities was either inconvenient or > restricted. If these problems are still relevant, then why not try > providing some primitives to help them? 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. > IOW, let me turn the table and ask: why would a Lisp program want to > get a list of all the markers in a buffer, especially those not > created from Lisp? As I say above, I don't have any use-cases which specifically need to expose a buffer's marker list to Lisp, as opposed to using some other approach. The main call for marker-list in bug#18 could probably be better solved with a different primitive. Thanks, -- Basil From unknown Mon Jun 23 20:20:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Resent-From: "Basil L. Contovounesios" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 May 2019 15:52:01 +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 To: Stefan Monnier Cc: 35536@debbugs.gnu.org, Mauro Aranda , martin rudalics Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.155689866622885 (code B ref 35536); Fri, 03 May 2019 15:52:01 +0000 Received: (at 35536) by debbugs.gnu.org; 3 May 2019 15:51:06 +0000 Received: from localhost ([127.0.0.1]:49380 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMaSo-0005x3-Di for submit@debbugs.gnu.org; Fri, 03 May 2019 11:51:06 -0400 Received: from mail-ed1-f51.google.com ([209.85.208.51]:40331) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMaSm-0005wS-7l for 35536@debbugs.gnu.org; Fri, 03 May 2019 11:51:04 -0400 Received: by mail-ed1-f51.google.com with SMTP id e56so6541816ede.7 for <35536@debbugs.gnu.org>; Fri, 03 May 2019 08:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=+pjTjdOw0hHKzFtS/QSrRHxqINdhMLaCLQKRuNMZL5U=; b=cHQyShzl38HUhrZv89abKFjU+OZ+Pd2hNM/PiLErf48XCN8FfV2jQaFUatdkLz/bYk nSLTD/VyhHHP2PqUscSpVBJzkauXrUMQJbMqM0mYF2JHlIGg41tEwMSy/SPs3fG9Mnf6 5pASHKJPwObzuL3cgrjC3o7scwMWrLxyaRJMB+9gHvjXtK9A+1zCMXtPl6YOUjFaEBQT d+ecmAH+kuvVAeoFrt0LHZKD4FW4ngX1Oxheu00BerB+87tpqvL1dQwaNmuZFVlL878F O+yJ7FHERaGMF3BSC/9wFnemu/F0Mq1/5LW1EqBhMBS3pIJ+ibZqnrWJOpiP0tI953fZ fTDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=+pjTjdOw0hHKzFtS/QSrRHxqINdhMLaCLQKRuNMZL5U=; b=CVpTHeG+HGDTcB1N+S0HaMbMbGitZI3pc6sL+ygi+jsq8wa10lVIMayNWeU5dqdWlr 8dYPEBAP9kz2qhBbmE9Jr3nMyFhHqTfCOr/Jr77u9C0C5f4ylhM4NxLUcMyAco4u1Kb1 LlKBTnoYImcHcf2+XOB7ue9CnzpWv2u11iHV2NIZYjgUYv9qd2WoUbAJqstX3BmAQ+Qs ZXwOIH+la3wyGLKDa7ubwKDPikGr18P2mkm9skOW4941kgnzA9f6nPEohexIO1OLaw3S keZ8BDiCfBefBaxIcCiib5yOohdIp0+qcKGJfRw7m11RiyY/sIfxN+WJZks9YABbJHpC 8yrw== X-Gm-Message-State: APjAAAUdinJg3cTVIxR9flj+wkhsEPPexpR6MyyrgPmExDG7dGFAXGTi poJBWYqmcOt1PcFcSN1jbqI6tg== X-Google-Smtp-Source: APXvYqxW3B1LAtDG6cnP9NKXuCU9LAZZhhE146Op9RB4nEfSB0CBb+XKgmbwsn7/JcpzPPOxF1thpQ== X-Received: by 2002:a17:907:1003:: with SMTP id ox3mr6738504ejb.210.1556898658365; Fri, 03 May 2019 08:50:58 -0700 (PDT) Received: from localhost ([89.101.223.218]) by smtp.gmail.com with ESMTPSA id p12sm391231ejr.18.2019.05.03.08.50.57 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 03 May 2019 08:50:57 -0700 (PDT) From: "Basil L. Contovounesios" References: <87lfzo274b.fsf@tcd.ie> Date: Fri, 03 May 2019 16:50:56 +0100 In-Reply-To: (Stefan Monnier's message of "Thu, 02 May 2019 15:59:38 -0400") Message-ID: <87r29fcza7.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: >> I attach a patch implementing this based on BUF_MARKERS, as per Martin's >> suggestion. Any reasons not to expose such a function? > > AFAIK the main reason for such a function is so that you can implement > "replace" functions which preserves markers better than "insert+delete" > does, right? AIUI, yes. > Random thoughts: > - I wouldn't expose a `(marker-list)` function but rather `(markers-in > BEG END)` so you're not bothered by unrelated markers outside of > the region of interest. The patch in the OP accepts optional BEG and END arguments for the caller's typing convenience. > - The main problem I see is that some of the markers in BUF_MARKERS are > "proper" markers, while others are just the markers that we happen to > use in the current internal representation of overlays. > If you can get your hands on those markers, you might end up breaking > some invariants on which the C code relies (e.g. place the > overlay-start after the overlay-end, or in a different buffer). > - I think the serious risks (e.g. crashes) are solvable. E.g. there's > room for an additional boolean field `lisp_marker` which could be used > to distinguish those markers which can be safely returned (because > they're normal Lisp-level markers already accessible from Lisp anyway) > from the internal ones (such as those from overlays). > - Then we'd probably want to discussion whether markers used within > `save-excursion` and friends should be marked as `lisp_marker` or not. > > This said, as you say later: >> I have yet to see a use-case for marker-list which can't be engineered >> in a different way > > So, whether it's worth the trouble: I don't know. Given a sufficiently sufficient save+restore primitive as per Eli's suggestion, it's not looking worth the trouble. Thanks, -- Basil From unknown Mon Jun 23 20:20:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 May 2019 16:39: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 To: "Basil L. Contovounesios" , Eli Zaretskii Cc: 35536@debbugs.gnu.org, maurooaranda@gmail.com, monnier@iro.umontreal.ca Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.155690149627225 (code B ref 35536); Fri, 03 May 2019 16:39:02 +0000 Received: (at 35536) by debbugs.gnu.org; 3 May 2019 16:38:16 +0000 Received: from localhost ([127.0.0.1]:49440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMbCS-000753-2e for submit@debbugs.gnu.org; Fri, 03 May 2019 12:38:16 -0400 Received: from aserp2130.oracle.com ([141.146.126.79]:50402) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMbCP-00074n-JP for 35536@debbugs.gnu.org; Fri, 03 May 2019 12:38:14 -0400 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x43GYDje126106; Fri, 3 May 2019 16:38:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=eb2eLAXiQE+kqTR8uKEwcvVg9KGcM8zaj1Pkwo0Bj8Q=; b=ssuJXUNZeiV4Z8ddrhzWVXhmsDvysKgErkLpgNauj1MN/0/mLxM42x8HHjYkcPkw9wGb VuhF5XXRbuE0Gl/Ki3adv780sEqhAfoB0cyyAZgLbri0vgRDQlBU9pJA6RKCbbfIig+x k41BnedKyQlcfSfn05/PtzXMdzOjvMwscjp+qdUvAbsJYiKUaP0zD/7g6AFrs+C+X4EI e4bFXbD/1rer5iYXstoATR0lRP57qweSxA0K1pklBuxB4VTawjSHEFaE6xF5BigCMLPP 78EdCLdgFA9dTSNuxB9MeJFYqLcdVzBzrzimvFkwRDqzEedt1MD7LDAFBtWXKngAkbia fg== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2130.oracle.com with ESMTP id 2s6xhyqwb4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 May 2019 16:38:07 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x43Gb8pM089737; Fri, 3 May 2019 16:38:06 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3020.oracle.com with ESMTP id 2s6xhhqkhg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 May 2019 16:38:06 +0000 Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x43Gc3H9015392; Fri, 3 May 2019 16:38:03 GMT MIME-Version: 1.0 Message-ID: Date: Fri, 3 May 2019 09:38:02 -0700 (PDT) From: Drew Adams References: <87lfzo274b.fsf@tcd.ie> <83ef5gq1po.fsf@gnu.org> <87imusztof.fsf@tcd.ie> <8336lwpxcq.fsf@gnu.org> <87sgtvczba.fsf@tcd.ie> In-Reply-To: <87sgtvczba.fsf@tcd.ie> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4834.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9245 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905030106 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9245 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905030106 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > When asked for a list of markers between BEG and END, it makes sense to > me to return a list which ascends from BEG to END. ^^^^^^^^^^^^^^^^^^^^^^^ IOW, in buffer-position order. > If it really matters, we could either return the > order of BUF_MARKERS unchanged, Unchanged from what? > or accept an additional argument which tells the > function how to sort. Have not really been following this thread, and not weighing in on whether such a function is needed or whether users need access to markers created by C. But as for the order of such a list: It's trivial for users (any Lisp code) to sort by buffer position or anything else, so why would the default order be by buffer position? What's _not_ available to users or Lisp code, I think, is the order of marker creation or even the order of last setting. I'd think that marker-creation order (either direction) would be a better default sort order for this, no? From unknown Mon Jun 23 20:20:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 May 2019 17:10:01 +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 To: "Basil L. Contovounesios" Cc: 35536@debbugs.gnu.org, Mauro Aranda , martin rudalics Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.155690336530561 (code B ref 35536); Fri, 03 May 2019 17:10:01 +0000 Received: (at 35536) by debbugs.gnu.org; 3 May 2019 17:09:25 +0000 Received: from localhost ([127.0.0.1]:49571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMbgb-0007wq-G9 for submit@debbugs.gnu.org; Fri, 03 May 2019 13:09:25 -0400 Received: from mail01.iro.umontreal.ca ([132.204.25.201]:42300) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMbgY-0007wc-S1 for 35536@debbugs.gnu.org; Fri, 03 May 2019 13:09:23 -0400 Received: from mail01.iro.umontreal.ca (mail01.iro.umontreal.ca [127.0.0.1]) by mail01.iro.umontreal.ca (Postfix) with ESMTP id 5629D885BE68 for <35536@debbugs.gnu.org>; Fri, 3 May 2019 13:09:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; h=content-type:content-type:mime-version:user-agent:in-reply-to :date:date:references:message-id:subject:subject:to:from:from; s=dkim; t=1556903356; x=1557767357; bh=emtCTrlVT/K02H3ONMY85/mu 8Q+nEpjUTlEssvX6zlQ=; b=eRA52tcLBDzV8iy4lW+H6WYmTW2WwdAEdD73QEsk iiG91oMTWm6cyHuXV3Bg4smlV2xNTSNwzumYQwNaWi5x8dIr18txTrxT496spBE9 Mq3fU3tz9tuDlrrjptxsiXOXaLG104qkEs+lcynoHIKqCP6DkGeNMbCi3zdchnak 8T6c9HtQOSGy8mY7v4aYJ4lne5rHqbST0uXYey/0/2v/7QC/ZO86q3BCy7kgw0zk U4s4/qqDm+Z1OJFzW92S/Y2AUWbNVzbG1tcB05nr3nm/8yAVtsbJrE9nNNXPmtX+ qpK+bfYjXsN0UhG09dkI8IoGgc+/CUaARAdyd7z2Upva8w== X-Virus-Scanned: amavisd-new at iro.umontreal.ca Received: from mail01.iro.umontreal.ca ([127.0.0.1]) by mail01.iro.umontreal.ca (mail01.iro.umontreal.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N24jvn_sdZlX for <35536@debbugs.gnu.org>; Fri, 3 May 2019 13:09:16 -0400 (EDT) Received: from alfajor (modemcable157.163-203-24.mc.videotron.ca [24.203.163.157]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 169F1885BE4C; Fri, 3 May 2019 13:09:16 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87lfzo274b.fsf@tcd.ie> <87r29fcza7.fsf@tcd.ie> Date: Fri, 03 May 2019 13:09:15 -0400 In-Reply-To: <87r29fcza7.fsf@tcd.ie> (Basil L. Contovounesios's message of "Fri, 03 May 2019 16:50:56 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Given a sufficiently sufficient save+restore primitive as per Eli's > suggestion, it's not looking worth the trouble. FWIW, I think exposing some new opaque "set of markers" plus primitives to manipulate such objects is likely a lot more work, so I think from a purely pragmatic point of view, `markers-in` might be a better option *assuming* we can make it safe-enough (i.e. it can cause weird behaviors if mis-used but no hard-crashes, and not if used "reasonably", e.g. if it's not used to change the markers's buffers nor their relative ordering). In Emacs, we're generally pretty happy to provide tools powerful enough to shoot yourself in the foot, as long as such mishaps only happen when you're clearly using the tool in a dangerous way. Stefan From unknown Mon Jun 23 20:20:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Resent-From: "Basil L. Contovounesios" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 May 2019 17:23: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 To: Drew Adams Cc: 35536@debbugs.gnu.org, Eli Zaretskii , maurooaranda@gmail.com, monnier@iro.umontreal.ca Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.155690417031740 (code B ref 35536); Fri, 03 May 2019 17:23:02 +0000 Received: (at 35536) by debbugs.gnu.org; 3 May 2019 17:22:50 +0000 Received: from localhost ([127.0.0.1]:49579 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMbtZ-0008Fs-Qj for submit@debbugs.gnu.org; Fri, 03 May 2019 13:22:50 -0400 Received: from mail-ed1-f50.google.com ([209.85.208.50]:32862) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMbtY-0008Ff-3J for 35536@debbugs.gnu.org; Fri, 03 May 2019 13:22:48 -0400 Received: by mail-ed1-f50.google.com with SMTP id n17so6878578edb.0 for <35536@debbugs.gnu.org>; Fri, 03 May 2019 10:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=ON+ka8PY4rGy1ekKR+2RZdLVYdtQQm1i7ghJ0Q4BTk4=; b=FliEoVtYahEqYpy+lw/WuEhqpPV3Vx3oltbrqQayurYQYTxn3da6fyDro2PmZo1z9T YIfkNZVj+VJLiskMS939dZJnAVLfZi5uAqNKYcSvDaI1PYydVuIg7GeWLb4jAIH21sjr Dikfz99KR2A/kF3QohMGjoQUMBicjgeFFWnQxG8ilrefaNTYkvaLhvWx32BQG0vrPWuO A4IJPzfqkohLfgTMTvInRSNsYT2N0bkT+6UKVPyJ/SQxSGMP+lNby84Csv6PD9GUXc6m HKwgNoe3r4rQRdVxlm4p4DH1rU/q9zfmToSqlUbTP+AZi6ZEV97z9AYb815I+QSYJMGD Kl5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=ON+ka8PY4rGy1ekKR+2RZdLVYdtQQm1i7ghJ0Q4BTk4=; b=j0FUUJDYOSWMepxrKmL6gG3eb9A+FM3UUwA2yxzHkMEj5H0HHSLdpbUf1LCa1Q3Rvg FpWtkO3gr/r2OUGrS1pEZzHifgX5q24/8UxfHk0/9mYEzIb6rp29ZkxqEtsFKV/3PfMs jvIlTxIcqUlMnY7rXrNUV4+gNot0FOodU1SNAEql7S1MCHn3qD9VlmVK8zcE6AaXz1J3 2dOx6gHKwpoemEsJ/+9icyp9ww2V8i8C+MMFJUudiEFtRtKpNm2UPjUgPEVqSd+e1nPU H7fp2Yqo2pbIoA95C2e05C+ciYnpTVsvaVlcUuUNDCXWxVgOi4kC3pKPO2gDIJ/HF0wh 581A== X-Gm-Message-State: APjAAAU0RMsSac1jPzcUlGVeY6AqpjQq9ieBBUm8HA9KmhBLT2VNDsWj Nfy1WHdkLIh7nG0FzQNMIGNQdA== X-Google-Smtp-Source: APXvYqyjk/wngfDeXwaq6/bcT0utp3G7lzHp5B8kNeAz+qbkEqrmg396kxb3+bfsboI4BgGnmviYIQ== X-Received: by 2002:a17:906:1dc5:: with SMTP id v5mr7210808ejh.66.1556904162281; Fri, 03 May 2019 10:22:42 -0700 (PDT) Received: from localhost ([89.101.223.218]) by smtp.gmail.com with ESMTPSA id c15sm409405ejb.33.2019.05.03.10.22.41 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 03 May 2019 10:22:41 -0700 (PDT) From: "Basil L. Contovounesios" References: <87lfzo274b.fsf@tcd.ie> <83ef5gq1po.fsf@gnu.org> <87imusztof.fsf@tcd.ie> <8336lwpxcq.fsf@gnu.org> <87sgtvczba.fsf@tcd.ie> Date: Fri, 03 May 2019 18:22:39 +0100 In-Reply-To: (Drew Adams's message of "Fri, 3 May 2019 09:38:02 -0700 (PDT)") Message-ID: <875zqrbggw.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Drew Adams writes: >> When asked for a list of markers between BEG and END, it makes sense to >> me to return a list which ascends from BEG to END. > ^^^^^^^^^^^^^^^^^^^^^^^ > IOW, in buffer-position order. Yes. >> If it really matters, we could either return the >> order of BUF_MARKERS unchanged, > > Unchanged from what? >From the order returned by BUF_MARKERS, i.e. the internal chain of markers pointing to the current buffer. This order presumably reflects, to an extent, the order in which markers were created/chained, but I'm not sure about this. >> or accept an additional argument which tells the >> function how to sort. > > Have not really been following this thread, and > not weighing in on whether such a function is > needed or whether users need access to markers > created by C. > > But as for the order of such a list: It's trivial > for users (any Lisp code) to sort by buffer position > or anything else, so why would the default order > be by buffer position? That is the order I would intuitively expect in any enumeration of a partially ordered set of buffer artifacts in a given region, unless otherwise stated. What other order would make sense when talking about markers within a given region? > What's _not_ available to users or Lisp code, I > think, is the order of marker creation or even the > order of last setting. I'd think that > marker-creation order (either direction) would be > a better default sort order for this, no? Perhaps when enumerating markers pointing at a single position, yes. But I think that ordering would make less sense when talking about markers within a given region. Assuming something like marker-list is deemed a useful addition (which is not yet clear), perhaps there should be two separate functions akin to overlays-in and overlays-at, with different sorting options and/or default policies. Thanks, -- Basil From unknown Mon Jun 23 20:20:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 May 2019 17:32:01 +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 To: "Basil L. Contovounesios" Cc: 35536@debbugs.gnu.org, Eli Zaretskii , maurooaranda@gmail.com, monnier@iro.umontreal.ca Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.155690469132580 (code B ref 35536); Fri, 03 May 2019 17:32:01 +0000 Received: (at 35536) by debbugs.gnu.org; 3 May 2019 17:31:31 +0000 Received: from localhost ([127.0.0.1]:49587 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMc1y-0008TQ-R9 for submit@debbugs.gnu.org; Fri, 03 May 2019 13:31:31 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:43714) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMc1w-0008TA-V2 for 35536@debbugs.gnu.org; Fri, 03 May 2019 13:31:29 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x43HTAOM186124; Fri, 3 May 2019 17:31:22 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=rwNlXFVZQ1S/Op3efAWopFz4Z58f7o+mcgO2AraDlnM=; b=whErprBTn9+8nW2JQWys1s4aP/X5iEpKNnmsxFF6KBX8fvwDEBRnDN2GdDzkmdQWDzSY GPNBGHj42SrTYQOEsgNdUesth5lHJslHsDN76livO+3FY3t7Rb8AS/ZTeU85aRxmv+NX 7TBSzMraNWjfItCQOqmJTXFpbIdJHBn12Jm8kUnIFYsIGqk8iVwVyIy9MDq/oCAROtXS Q3Vgo9zOZvv7+m6UbuD+TaQx7WJiXs8xhKytAOZoF1yEn0VwLqpC9Afs9iTfhOtJVbun uaynPBG9NOuS2LWzSAz4prD0iyG/a4lpEzH9gLP8tWyoeAIhM20ynrzyjFY9db9Em5I0 wg== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 2s6xj007yr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 May 2019 17:31:22 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x43HV8bQ020058; Fri, 3 May 2019 17:31:21 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3020.oracle.com with ESMTP id 2s6xhhrbhd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 May 2019 17:31:21 +0000 Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x43HVJGX016334; Fri, 3 May 2019 17:31:19 GMT MIME-Version: 1.0 Message-ID: <9804fdf3-0f23-43c7-bbf7-123cb8a95f77@default> Date: Fri, 3 May 2019 10:31:17 -0700 (PDT) From: Drew Adams References: <87lfzo274b.fsf@tcd.ie> <83ef5gq1po.fsf@gnu.org> <87imusztof.fsf@tcd.ie> <8336lwpxcq.fsf@gnu.org> <87sgtvczba.fsf@tcd.ie> <875zqrbggw.fsf@tcd.ie> In-Reply-To: <875zqrbggw.fsf@tcd.ie> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4834.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9245 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905030113 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9245 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905030113 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) I don't want to belabor this, but I'll reply once about this. > > But as for the order of such a list: It's trivial > > for users (any Lisp code) to sort by buffer position > > or anything else, so why would the default order > > be by buffer position? >=20 > That is the order I would intuitively expect in any enumeration of a > partially ordered set of buffer artifacts in a given region, unless > otherwise stated. >=20 > What other order would make sense when talking about markers within a > given region? I think the order that makes sense as the (only?) way to get the set of markers (including those from C) is an order that we cannot get otherwise. Creation order is one such otherwise-unavailable order. Anyone can get the buffer-position order at any time. Or it can be provided as a function, if that's deemed important. > > What's _not_ available to users or Lisp code, I > > think, is the order of marker creation or even the > > order of last setting. I'd think that > > marker-creation order (either direction) would be > > a better default sort order for this, no? >=20 > Perhaps when enumerating markers pointing at a single position, yes. > But I think that ordering would make less sense when talking about > markers within a given region. Assuming something like marker-list is > deemed a useful addition (which is not yet clear), perhaps there should > be two separate functions akin to overlays-in and overlays-at, with > different sorting options and/or default policies. It's not about what's most immediately useful for most imagined uses of the markers in a given region. It's about _somehow_ getting a set of markers (wherever, whether within some buffer-position range or not) in their order of creation (or modification). Such relative time information is otherwise lost completely. The markers themselves contain position information. They do not contain time information. Again, though, I'm not saying anything about whether we need such a function at all. I'm just suggesting that if we provide it it should probably provide info that is not otherwise obtainable. Creation time is one such bit of info. From unknown Mon Jun 23 20:20:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 May 2019 17:40: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 To: "Basil L. Contovounesios" Cc: 35536@debbugs.gnu.org, Eli Zaretskii , maurooaranda@gmail.com, Drew Adams Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.1556905167844 (code B ref 35536); Fri, 03 May 2019 17:40:02 +0000 Received: (at 35536) by debbugs.gnu.org; 3 May 2019 17:39:27 +0000 Received: from localhost ([127.0.0.1]:49598 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMc9e-0000DY-QQ for submit@debbugs.gnu.org; Fri, 03 May 2019 13:39:26 -0400 Received: from mail01.iro.umontreal.ca ([132.204.25.201]:47430) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMc9a-0000DH-RY for 35536@debbugs.gnu.org; Fri, 03 May 2019 13:39:25 -0400 Received: from mail01.iro.umontreal.ca (mail01.iro.umontreal.ca [127.0.0.1]) by mail01.iro.umontreal.ca (Postfix) with ESMTP id 875FF885D6F7 for <35536@debbugs.gnu.org>; Fri, 3 May 2019 13:39:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; h=content-type:content-type:mime-version:user-agent:in-reply-to :date:date:references:message-id:subject:subject:to:from:from; s=dkim; t=1556905157; x=1557769158; bh=FNmJQmV7Llv7avs1LKVNWej/ AtLIC2n1s6kX0MryT/A=; b=Z+XZwwpyg6LZjiOdca7TEYdxAbhzBLvYbkU7VVtR 8oJLGLtLja3baCP8JaLufH8ccFoyddBPPmNDGi6hiiYx8RVn9JduubvtkOswDB66 mnniRTcpSoEpPSkm9CEhMDAraingmTKDsU6mQqCCO0SoroXRzqAf/iY3eI4nZnU6 DgfRJh2Q8beGYaom2cKiJitQEgM/0JXoF6JZNmawwPMsam7LlmIq4UhsfEjuqdzr 1jU8UTQKsSSk3HFwCpspTEZQrBnpdscqi2grWosxBy2G4lc18P2DSwYBoRFbi436 +30UVqAJC3kxTX60N7HX1bluFcXteIMlullby3nYfLS1vA== X-Virus-Scanned: amavisd-new at iro.umontreal.ca Received: from mail01.iro.umontreal.ca ([127.0.0.1]) by mail01.iro.umontreal.ca (mail01.iro.umontreal.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Li7rL-m7rB0u for <35536@debbugs.gnu.org>; Fri, 3 May 2019 13:39:17 -0400 (EDT) Received: from alfajor (modemcable157.163-203-24.mc.videotron.ca [24.203.163.157]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5A511885D6D6; Fri, 3 May 2019 13:39:16 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87lfzo274b.fsf@tcd.ie> <83ef5gq1po.fsf@gnu.org> <87imusztof.fsf@tcd.ie> <8336lwpxcq.fsf@gnu.org> <87sgtvczba.fsf@tcd.ie> <875zqrbggw.fsf@tcd.ie> Date: Fri, 03 May 2019 13:39:15 -0400 In-Reply-To: <875zqrbggw.fsf@tcd.ie> (Basil L. Contovounesios's message of "Fri, 03 May 2019 18:22:39 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> What's _not_ available to users or Lisp code, I >> think, is the order of marker creation or even the >> order of last setting. There's no reason for the C code to keep track of those things either. So while the current implementation may happen to have the markers in "creation order", it would be wrong to provide a primitive that promises this ordering unless there's a *good* reason why we'd want to force future Emacsen to also keep track of this info. So far I don't see any such reason. Stefan From unknown Mon Jun 23 20:20:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 May 2019 17:54: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 To: Stefan Monnier , "Basil L. Contovounesios" Cc: 35536@debbugs.gnu.org, Eli Zaretskii , maurooaranda@gmail.com Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.15569060302148 (code B ref 35536); Fri, 03 May 2019 17:54:02 +0000 Received: (at 35536) by debbugs.gnu.org; 3 May 2019 17:53:50 +0000 Received: from localhost ([127.0.0.1]:49614 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMcNa-0000Ya-HZ for submit@debbugs.gnu.org; Fri, 03 May 2019 13:53:50 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:54668) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMcNZ-0000YO-FQ for 35536@debbugs.gnu.org; Fri, 03 May 2019 13:53:49 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x43Hmwt5182259; Fri, 3 May 2019 17:53:43 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=ZV7pjXjl1b2FKFPbdT7A5zUFE7b0elk1m55RlRlgtvI=; b=CFJWC1gOACVcoyLFzGZpwTH7BgTvZUPJZqSQKGIZnLwN/S3+jlVemyZ6FeLz84vj0Xac OE2WgQcvU3KCDbhOLxs0XIuN3+GzDnjACEB0nGVrysYxPSaZAtsIhCmHwonoK6YQhNQz lahBvbgXnasCpdpScgUG5rrouPWLlavH7oAUmxVBTLuaEXrMevd2mrjQw53oNg0UVbH4 YBu8KTuGvjzPgcCdi+jByoXffiFuVeHaZtMkd60f0OVqNaeeJNY45Bm6hn0W7LAEca6x uQm4WpHOClz2fDgWuMUPaWBqyS5GxnPh0zU7MjKnGFaNClUcdEmTmZJEYb0WuTMpZuE0 7g== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 2s6xhyrc32-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 May 2019 17:53:42 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x43Hqnd4091311; Fri, 3 May 2019 17:53:42 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3030.oracle.com with ESMTP id 2s7rtcdtp4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 May 2019 17:53:42 +0000 Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x43HrbqQ009669; Fri, 3 May 2019 17:53:38 GMT MIME-Version: 1.0 Message-ID: <8710b9bd-f945-463b-906c-92564970ab43@default> Date: Fri, 3 May 2019 10:53:36 -0700 (PDT) From: Drew Adams References: <87lfzo274b.fsf@tcd.ie> <83ef5gq1po.fsf@gnu.org> <87imusztof.fsf@tcd.ie> <8336lwpxcq.fsf@gnu.org> <87sgtvczba.fsf@tcd.ie> <875zqrbggw.fsf@tcd.ie> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4834.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9245 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905030116 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9245 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905030116 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > >> What's _not_ available to users or Lisp code, I > >> think, is the order of marker creation or even the > >> order of last setting. >=20 > There's no reason for the C code to keep track of those things either. > So while the current implementation may happen to have the markers in > "creation order", it would be wrong to provide a primitive that promises > this ordering unless there's a *good* reason why we'd want to force > future Emacsen to also keep track of this info. So far I don't see any > such reason. Fair enough. I was thinking it might be a freebie. E.g., I was thinking that the list to be returned would just be created by, say, pushing new markers onto it. If that were the case then that order could be useful, whether or not one could _depend_ on it. Whether or not one should be able to depend on such an order is a separate question. If guaranteeing to provide such a default order is too restrictive (and I agree that it probably would be), but if the current implementation did mostly return the set in such an order, then I'd vote for not reordering it and just saying nothing about the return order. Consider `buffer-list', for example. The order is generally useful but we say nothing much about it, directly. (But we do show, in (elisp) `Buffer List', how you can reorder the underlying buffer list.) We also point out there of saying that `buffer-list' "is not an internal Emacs data structure, and modifying it has no effect on the order of buffers." From unknown Mon Jun 23 20:20:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 May 2019 18:14: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 To: Drew Adams Cc: "Basil L. Contovounesios" , 35536@debbugs.gnu.org, Eli Zaretskii , maurooaranda@gmail.com Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.15569072303981 (code B ref 35536); Fri, 03 May 2019 18:14:02 +0000 Received: (at 35536) by debbugs.gnu.org; 3 May 2019 18:13:50 +0000 Received: from localhost ([127.0.0.1]:49633 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMcgw-000129-9z for submit@debbugs.gnu.org; Fri, 03 May 2019 14:13:50 -0400 Received: from mail01.iro.umontreal.ca ([132.204.25.201]:53376) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMcgv-00011y-6f for 35536@debbugs.gnu.org; Fri, 03 May 2019 14:13:49 -0400 Received: from mail01.iro.umontreal.ca (mail01.iro.umontreal.ca [127.0.0.1]) by mail01.iro.umontreal.ca (Postfix) with ESMTP id 1007C885F53D for <35536@debbugs.gnu.org>; Fri, 3 May 2019 14:13:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; h=content-type:content-type:mime-version:user-agent:in-reply-to :date:date:references:message-id:subject:subject:to:from:from; s=dkim; t=1556907223; x=1557771224; bh=ZAs4D/VQq2dAYOjdMY2t6QLf QSyNsZijbB22fBJ/Eu8=; b=hnMD124WMJyu2WrzhA3ed9Flzg1DSKmEjFCMLOpc lXqSD1nzr6Ptd1pYs0AMLxrteoni2Yx2yhtRafkXnL+m4Iho4UnfpyKBTvqYIE7G jE6CcmdJ+ZGPwuSY9WMT87AFw4JTHDebR44mzhF6/b6kGkwxkfT8XmMESUw83tSQ ZQkzQ8g8WacMD9fWwd3/FR9CAlc7WDf8nsO5l9+vjW0u+9NBjTpMQ37JZ+Q00oYQ dyd9JbVZ8Opzd6QNU6B3DdEVJ0ZuoMNs4ZruUkiN13fjO/H+v9DXFQ8z52j3rIdX dHA2qXUa66xE99oPr+9vye2Qknttqc7efBpPW/I6gPTgdg== X-Virus-Scanned: amavisd-new at iro.umontreal.ca Received: from mail01.iro.umontreal.ca ([127.0.0.1]) by mail01.iro.umontreal.ca (mail01.iro.umontreal.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnTz8xXw_758 for <35536@debbugs.gnu.org>; Fri, 3 May 2019 14:13:43 -0400 (EDT) Received: from alfajor (modemcable157.163-203-24.mc.videotron.ca [24.203.163.157]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5D28D885F523; Fri, 3 May 2019 14:13:42 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87lfzo274b.fsf@tcd.ie> <83ef5gq1po.fsf@gnu.org> <87imusztof.fsf@tcd.ie> <8336lwpxcq.fsf@gnu.org> <87sgtvczba.fsf@tcd.ie> <875zqrbggw.fsf@tcd.ie> <8710b9bd-f945-463b-906c-92564970ab43@default> Date: Fri, 03 May 2019 14:13:41 -0400 In-Reply-To: <8710b9bd-f945-463b-906c-92564970ab43@default> (Drew Adams's message of "Fri, 3 May 2019 10:53:36 -0700 (PDT)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Whether or not one should be able to depend on such > an order is a separate question. I'm fine with a `markers-in` which returns markers in the order found in the C code. But the docstring should state clearly that you can't rely on this ordering. I expect many uses won't care about the ordering anyway, so we don't need to bother `sort`ing, although the performance cost of `sort`ing will likely always be negligible. Stefan From unknown Mon Jun 23 20:20:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 May 2019 20:06:01 +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 To: Stefan Monnier Cc: "Basil L. Contovounesios" , 35536@debbugs.gnu.org, Eli Zaretskii , maurooaranda@gmail.com Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.155691391714321 (code B ref 35536); Fri, 03 May 2019 20:06:01 +0000 Received: (at 35536) by debbugs.gnu.org; 3 May 2019 20:05:17 +0000 Received: from localhost ([127.0.0.1]:49725 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMeQn-0003iu-9f for submit@debbugs.gnu.org; Fri, 03 May 2019 16:05:17 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:47624) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMeQk-0003ie-GP for 35536@debbugs.gnu.org; Fri, 03 May 2019 16:05:15 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x43Jwptx091198; Fri, 3 May 2019 20:05:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=lDd/svtzU072YgnSWQYX+sPku555fyKhpW3Y+U+7HQE=; b=n1ll9JqFEuzLuxS7ik0/UWOgkIRUMBxXcSXvxPYbwVz1CJZCljtfp1vnwDchULw7alvw M8XJt+fufuKkFuyw4CDDewYwAwvRANX+jLi8GJxwA/RTELw7tnOdqZKWc58d0OK4F5HN QLy8HnQBa7EUcQ9slxXK1TXLhH5jGMmDVdCTPdj1RD3Y735gYKXy7Bm5bxL0Fl8sbe6W 3yVncyP/8LqLtXa9xBvH+PUqGJFCL+SHsB1youVFHBbmqpo7Y9hhoyoGikz/hxx/dnd+ EiSqmUi8HJTgMppA8JZADIHfa/JlF/5MVh7ZIJO/PeTdoNdsGJysFm2BQT0PGzxBvNtt BQ== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 2s6xhyryy1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 May 2019 20:05:08 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x43K3ivE026547; Fri, 3 May 2019 20:05:08 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3030.oracle.com with ESMTP id 2s7p8ah99e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 May 2019 20:05:08 +0000 Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x43K52Qm030733; Fri, 3 May 2019 20:05:02 GMT MIME-Version: 1.0 Message-ID: <708325d6-c003-4028-93db-f5d746c258df@default> Date: Fri, 3 May 2019 13:05:01 -0700 (PDT) From: Drew Adams References: <87lfzo274b.fsf@tcd.ie> <83ef5gq1po.fsf@gnu.org> <87imusztof.fsf@tcd.ie> <8336lwpxcq.fsf@gnu.org> <87sgtvczba.fsf@tcd.ie> <875zqrbggw.fsf@tcd.ie> <8710b9bd-f945-463b-906c-92564970ab43@default> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4834.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9245 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=693 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905030132 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9245 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=726 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905030132 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > Whether or not one should be able to depend on such > > an order is a separate question. >=20 > I'm fine with a `markers-in` which returns markers in the order found in > the C code. But the docstring should state clearly that you can't rely > on this ordering. >=20 > I expect many uses won't care about the ordering anyway, so we don't > need to bother `sort`ing, although the performance cost of `sort`ing will > likely always be negligible. Agreed on both counts. From unknown Mon Jun 23 20:20:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Resent-From: Mauro Aranda Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 May 2019 23:02: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 To: "Basil L. Contovounesios" Cc: 35536@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.155692450130206 (code B ref 35536); Fri, 03 May 2019 23:02:02 +0000 Received: (at 35536) by debbugs.gnu.org; 3 May 2019 23:01:41 +0000 Received: from localhost ([127.0.0.1]:49879 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMhBU-0007r8-KZ for submit@debbugs.gnu.org; Fri, 03 May 2019 19:01:40 -0400 Received: from mail-lf1-f67.google.com ([209.85.167.67]:39317) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMhBR-0007qt-QV for 35536@debbugs.gnu.org; Fri, 03 May 2019 19:01:39 -0400 Received: by mail-lf1-f67.google.com with SMTP id d12so5466308lfk.6 for <35536@debbugs.gnu.org>; Fri, 03 May 2019 16:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Krf0D2m+IOGoBW0J++IKXBp5ybwhtiWLJNGcQJ2ZrfM=; b=fH6AvEYP66N6/tcgZk3eWFnsjabGQJ848JkvfrObNtqBmTq4gkDPr5AciRpj/Ic7EK Z+QyNBkSGOeoa39xlIrxNsnoiXA6rD3mYlUOApAqbyIrZYjUxU+ftrmRIZcqkPGsN25C MI4OpXlPNVlOp4L/kZ9RjHiYSJlDVnto1RTdWiYXrsoESstR/QWkVKUqxjcTrbjdDi6z mADq0bw6rO4OS+fdLmT4YzhQC3VuRnYwxqBo5CcKoEalVM952e6s3Y3OO+o+YM2gGfox Q10dj8XebP3eUVZfoNEWuGMe5E5v5ZnRg3I5qzxrpavp1vcLxJt9/o/GOZ8CwkT9aM4/ lz5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Krf0D2m+IOGoBW0J++IKXBp5ybwhtiWLJNGcQJ2ZrfM=; b=Y+xnCHVi7LXBqguZ5KGW14+6FUm4xtfxX5urolx7oxUhcWweAXilz5rBCV6zkiRCYb +C869wle2oS0JOLD+yZzYe2iDzCs9QfoBV6tjxoNKjyuGo3gS23pruIhOYaG8uNsoIzb QqjixbUUmJqcDTXjio7dmbs3wtP1OeExwVQ1GZrEOTdepnP280HCwggdWLH6+wF+Ol6u qFM3xVTadrLGjUxUPIhXu7FBdBa9k+x5XCDKSMZqGZkiw1h82VnUhwxtlWpkWk/LFPag 9H5AcGv9AVvD+SYf+b7VAzSrGlyLDUWKlOveH0ysSQbqC/4zgvm7WTdUpa9hHPFpRQe5 K0Xg== X-Gm-Message-State: APjAAAUMsnP9qTiHKTyq19FZcMRxzLX+Omi27h9hIRCOQ+FWOpMQ08df t0OeIDyNwrm9unmaHt7e2GCZRrHmawuYtjrE+T8= X-Google-Smtp-Source: APXvYqzSAtzXMIbecgaPeEDAc/M08ggZNo2kU0Dd+9IVQgNyYATvFMvCbfQF/Muut6CX73z3UIA75SVmCE5Tw7LbmIk= X-Received: by 2002:ac2:54a1:: with SMTP id w1mr6880577lfk.46.1556924491633; Fri, 03 May 2019 16:01:31 -0700 (PDT) MIME-Version: 1.0 References: <87lfzo274b.fsf@tcd.ie> <83ef5gq1po.fsf@gnu.org> <87imusztof.fsf@tcd.ie> In-Reply-To: <87imusztof.fsf@tcd.ie> From: Mauro Aranda Date: Fri, 3 May 2019 20:01:18 -0300 Message-ID: Content-Type: multipart/alternative; boundary="000000000000441827058803bb28" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000441827058803bb28 Content-Type: text/plain; charset="UTF-8" >>> I have yet to see a use-case for marker-list which can't be engineered >>> in a different way (other than as a replacement for the obsolete >>> buffer-has-markers-at, FWIW). >> >> Well, the discussions you cited did express requirements whose >> implementation with the existing facilities was either inconvenient or >> restricted. If these problems are still relevant, then why not try >> providing some primitives to help them? > > 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. >> IOW, let me turn the table and ask: why would a Lisp program want to >> get a list of all the markers in a buffer, especially those not >> created from Lisp? > > As I say above, I don't have any use-cases which specifically need to > expose a buffer's marker list to Lisp, as opposed to using some other > approach. The main call for marker-list in bug#18 could probably be > better solved with a different primitive. > When I said I didn't find anything at the Lisp level to get the markers, that didn't fully express my thoughts. I didn't mean it as a call for a function to get that information (and certainly, I don't see a use for getting information about markers created internally). What I meant was that I thought about that way of restoring markers, but had no way of working on it (at least not with my current knowledge of C). Best regards, Mauro. --000000000000441827058803bb28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>>> I have yet = to see a use-case for marker-list which can't be engineered
>>= > in a different way (other than as a replacement for the obsolete
&g= t;>> buffer-has-markers-at, FWIW).
>>
>> Well, the = discussions you cited did express requirements whose
>> implementa= tion with the existing facilities was either inconvenient or
>> re= stricted.=C2=A0 If these problems are still relevant, then why not try
&= gt;> providing some primitives to help them?
>
> A save+rest= ore primitive like the one you suggested in your other
> message soun= ds like it might do the trick without having to expose a
> buffer'= ;s marker list to Lisp.

Indeed.=C2=A0 I thought Martin was talking a= bout something like this in his post
in bug#18.=C2=A0 Given a region whe= re text is going to be replaced, save the
positions of markers that woul= d be affected because of the delete+insert,
and then restore them.
>> IOW, let me turn the table and ask: why would a Lisp program wan= t to
>> get a list of all the markers in a buffer, especially thos= e not
>> created from Lisp?
>
> As I say above, I don&= #39;t have any use-cases which specifically need to
> expose a buffer= 's marker list to Lisp, as opposed to using some other
> approach= .=C2=A0 The main call for marker-list in bug#18 could probably be
> b= etter solved with a different primitive.
>
=
When I said I didn't find anything at the Li= sp level to get the markers,
that didn't fully express my thoughts.= =C2=A0 I didn't mean it as a call for a
function to get that informa= tion (and certainly, I don't see a use for
getting information about= markers created internally).=C2=A0 What I meant was
that I thought abo= ut that way of restoring markers, but had no way of
w= orking on it (at least not with my current knowledge of C).

Best regards,
Mauro.
--000000000000441827058803bb28-- From unknown Mon Jun 23 20:20:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp 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 To: Mauro Aranda , "Basil L. Contovounesios" Cc: 35536@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.155699126813636 (code B ref 35536); Sat, 04 May 2019 17:35:02 +0000 Received: (at 35536) by debbugs.gnu.org; 4 May 2019 17:34:28 +0000 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 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 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 References: <87lfzo274b.fsf@tcd.ie> <83ef5gq1po.fsf@gnu.org> <87imusztof.fsf@tcd.ie> From: martin rudalics Message-ID: <7e48a3d5-73c4-b153-8603-376fb9d757d5@gmx.at> Date: Sat, 4 May 2019 19:34:08 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:SH/BZnzgfofVMP6+eqiCca+vIVdAAzIu9MFpxHPHzbJxwDOTIcm Ln7bHs1sdelnf9LmMFLy7anNMd5XXzg7FBPwPiYMyb/PS2r9G+im8bfEeLgFIlOsbxfS0+5 JLEgUDhvJK1vf+L/R3fxF245Yqi40h3qXO5uHoUj//uoZf4gqt9TLtjPbigKCaM3TXJENNQ 86PmwbXwGAV0aWSDLMMSw== X-Spam-Flag: NO 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/FfWnZRV8f49etCFJmyPxt61FSt2KRbsR6U1FRjCO0fXxORv 7+RQj43MATbwGFotAJpjAbskJfW49ZkqesSgpd5HuhXzBQGayU4ViY404TgCmkMcjdPITykg9 K65/zrHO/Iwn+ad7XyFXiDJTffD1Xli11J9bU0e803EUfNaFyQDahqvLLGEAgRFvuTIkAbcFR m/PJLrGI7kw== X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> 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 From unknown Mon Jun 23 20:20:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Resent-From: Richard Stallman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 May 2019 21:27: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 To: Stefan Monnier Cc: contovob@tcd.ie, 35536@debbugs.gnu.org, maurooaranda@gmail.com, drew.adams@oracle.com Reply-To: rms@gnu.org Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.155700516422311 (code B ref 35536); Sat, 04 May 2019 21:27:02 +0000 Received: (at 35536) by debbugs.gnu.org; 4 May 2019 21:26:04 +0000 Received: from localhost ([127.0.0.1]:52512 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hN2AW-0005nn-JO for submit@debbugs.gnu.org; Sat, 04 May 2019 17:26:04 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60256) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hN2AV-0005nK-8a for 35536@debbugs.gnu.org; Sat, 04 May 2019 17:26:03 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34515) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hN2AK-0000wG-4a; Sat, 04 May 2019 17:25:53 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1hN2AB-00065T-0S; Sat, 04 May 2019 17:25:49 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman In-Reply-To: (message from Stefan Monnier on Fri, 03 May 2019 14:13:41 -0400) References: <87lfzo274b.fsf@tcd.ie> <83ef5gq1po.fsf@gnu.org> <87imusztof.fsf@tcd.ie> <8336lwpxcq.fsf@gnu.org> <87sgtvczba.fsf@tcd.ie> <875zqrbggw.fsf@tcd.ie> <8710b9bd-f945-463b-906c-92564970ab43@default> Message-Id: Date: Sat, 04 May 2019 17:25:43 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] I'm still opposed to making the internal list of markers accessible at all. Markers can disappear from that list due to GC. The only reason for having that list is so we can relocate the markers. It is not an interface that naturally should exist. What exactly do people want to do with this list? Let's look for another way. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From unknown Mon Jun 23 20:20:50 2025 X-Loop: help-debbugs@gnu.org Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Sep 2019 21:08: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 To: Richard Stallman Cc: contovob@tcd.ie, 35536@debbugs.gnu.org, Stefan Monnier , drew.adams@oracle.com, maurooaranda@gmail.com Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.156866806213251 (code B ref 35536); Mon, 16 Sep 2019 21:08:02 +0000 Received: (at 35536) by debbugs.gnu.org; 16 Sep 2019 21:07:42 +0000 Received: from localhost ([127.0.0.1]:51201 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i9yDm-0003Rf-E3 for submit@debbugs.gnu.org; Mon, 16 Sep 2019 17:07:42 -0400 Received: from quimby.gnus.org ([80.91.231.51]:39410) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i9yDk-0003RT-Az for 35536@debbugs.gnu.org; Mon, 16 Sep 2019 17:07:40 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i9yDf-0006Rt-5r; Mon, 16 Sep 2019 23:07:37 +0200 From: Lars Ingebrigtsen References: <87lfzo274b.fsf@tcd.ie> <83ef5gq1po.fsf@gnu.org> <87imusztof.fsf@tcd.ie> <8336lwpxcq.fsf@gnu.org> <87sgtvczba.fsf@tcd.ie> <875zqrbggw.fsf@tcd.ie> <8710b9bd-f945-463b-906c-92564970ab43@default> Date: Mon, 16 Sep 2019 23:07:34 +0200 In-Reply-To: (Richard Stallman's message of "Sat, 04 May 2019 17:25:43 -0400") Message-ID: <875zlsq7ah.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Richard Stallman writes: > I'm still opposed to making the internal list of markers accessible at all. > Markers can disappear from that list due to GC. > > The only reason for having that list is so we can relocate the > mar [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Richard Stallman writes: > I'm still opposed to making the internal list of markers accessible at all. > Markers can disappear from that list due to GC. > > The only reason for having that list is so we can relocate the > markers. It is not an interface that naturally should exist. > > What exactly do people want to do with this list? > Let's look for another way. I think the "rough consensus" here (i.e., Eli and Richard) is that we don't really want to expose the marker list. (This was also discussed in a different context a couple of weeks ago, and the conclusion was the same there.) So I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 16 17:07:47 2019 Received: (at control) by debbugs.gnu.org; 16 Sep 2019 21:07:47 +0000 Received: from localhost ([127.0.0.1]:51204 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i9yDq-0003Rw-Ml for submit@debbugs.gnu.org; Mon, 16 Sep 2019 17:07:46 -0400 Received: from quimby.gnus.org ([80.91.231.51]:39428) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i9yDo-0003Rn-Gy for control@debbugs.gnu.org; Mon, 16 Sep 2019 17:07:45 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i9yDl-0006S3-UG for control@debbugs.gnu.org; Mon, 16 Sep 2019 23:07:43 +0200 Date: Mon, 16 Sep 2019 23:07:41 +0200 Message-Id: <874l1cq7aa.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #35536 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 35536 wontfix close 35536 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 35536 wontfix close 35536 quit