From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Date: Thu, 02 May 2019 20:41:57 +0300 Message-ID: <8336lwpxcq.fsf@gnu.org> References: <87lfzo274b.fsf@tcd.ie> <83ef5gq1po.fsf@gnu.org> <87imusztof.fsf@tcd.ie> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="1680"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35536@debbugs.gnu.org, maurooaranda@gmail.com, monnier@iro.umontreal.ca To: "Basil L. Contovounesios" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 02 19:43:18 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 1hMFjp-0000JG-LV for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 May 2019 19:43:17 +0200 Original-Received: from localhost ([127.0.0.1]:56588 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMFjo-0000Z4-H0 for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 May 2019 13:43:16 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47723) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMFji-0000Yw-CZ for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 13:43:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMFjf-0002jO-3a for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 13:43:09 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33403) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hMFja-0002fp-7T for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 13:43:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hMFja-0001Y7-02 for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 13:43:02 -0400 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.15568189505918 (code B ref 35536); Thu, 02 May 2019 17:43:01 +0000 Original-Received: (at 35536) by debbugs.gnu.org; 2 May 2019 17:42:30 +0000 Original-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 Original-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 Original-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 Original-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 In-reply-to: <87imusztof.fsf@tcd.ie> (contovob@tcd.ie) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:158656 Archived-At: > 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?