From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Basil L. Contovounesios" Newsgroups: gmane.emacs.bugs Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Date: Fri, 03 May 2019 16:50:17 +0100 Message-ID: <87sgtvczba.fsf@tcd.ie> References: <87lfzo274b.fsf@tcd.ie> <83ef5gq1po.fsf@gnu.org> <87imusztof.fsf@tcd.ie> <8336lwpxcq.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="7290"; 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, maurooaranda@gmail.com, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 03 23:17:13 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 1hMfYB-0017On-6x for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 May 2019 23:16:59 +0200 Original-Received: from localhost ([127.0.0.1]:42570 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMaUM-0003z5-Ck for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 May 2019 11:52:42 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37342) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMaSl-0002iU-OQ for bug-gnu-emacs@gnu.org; Fri, 03 May 2019 11:51:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMaSk-0003P5-D1 for bug-gnu-emacs@gnu.org; Fri, 03 May 2019 11:51:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35832) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hMaSk-0003Oz-8x for bug-gnu-emacs@gnu.org; Fri, 03 May 2019 11:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hMaSk-0005wd-5a for bug-gnu-emacs@gnu.org; Fri, 03 May 2019 11:51:02 -0400 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.155689862822809 (code B ref 35536); Fri, 03 May 2019 15:51:02 +0000 Original-Received: (at 35536) by debbugs.gnu.org; 3 May 2019 15:50:28 +0000 Original-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 Original-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 Original-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) Original-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) In-Reply-To: <8336lwpxcq.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 2 May 2019 20:41:57 +0300") 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:158698 Archived-At: 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