From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Date: Thu, 02 May 2019 15:59:38 -0400 Message-ID: References: <87lfzo274b.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="8732"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 35536@debbugs.gnu.org, Mauro Aranda To: "Basil L. Contovounesios" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 02 22:00:14 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hMHsM-00028n-AT for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 May 2019 22:00:14 +0200 Original-Received: from localhost ([127.0.0.1]:57968 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMHsL-0006O0-90 for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 May 2019 16:00:13 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48177) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMHsD-0006Nd-HN for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 16:00:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMHsB-00014q-MM for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 16:00:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33527) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hMHsA-00014H-QB for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 16:00:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hMHsA-0006yK-Ml for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 16:00:02 -0400 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.155682718826756 (code B ref 35536); Thu, 02 May 2019 20:00:02 +0000 Original-Received: (at 35536) by debbugs.gnu.org; 2 May 2019 19:59:48 +0000 Original-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 Original-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 Original-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 Original-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) Original-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) In-Reply-To: <87lfzo274b.fsf@tcd.ie> (Basil L. Contovounesios's message of "Thu, 02 May 2019 16:44:52 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:158661 Archived-At: > 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