From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mauro Aranda Newsgroups: gmane.emacs.bugs Subject: bug#35536: 27.0.50; Expose buffer's marker list to Elisp Date: Fri, 3 May 2019 20:01:18 -0300 Message-ID: References: <87lfzo274b.fsf@tcd.ie> <83ef5gq1po.fsf@gnu.org> <87imusztof.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000441827058803bb28" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="107808"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35536@debbugs.gnu.org, monnier@iro.umontreal.ca To: "Basil L. Contovounesios" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat May 04 01:02:21 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 1hMhC7-000RmL-OH for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 May 2019 01:02:19 +0200 Original-Received: from localhost ([127.0.0.1]:48236 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMhC6-0001UI-Iu for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 May 2019 19:02:18 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46399) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMhBr-0001Tx-Q1 for bug-gnu-emacs@gnu.org; Fri, 03 May 2019 19:02:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMhBq-00025M-IU for bug-gnu-emacs@gnu.org; Fri, 03 May 2019 19:02:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36335) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hMhBq-00025H-Ff for bug-gnu-emacs@gnu.org; Fri, 03 May 2019 19:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hMhBq-0007rl-6z for bug-gnu-emacs@gnu.org; Fri, 03 May 2019 19:02:02 -0400 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 35536-submit@debbugs.gnu.org id=B35536.155692450130206 (code B ref 35536); Fri, 03 May 2019 23:02:02 +0000 Original-Received: (at 35536) by debbugs.gnu.org; 3 May 2019 23:01:41 +0000 Original-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 Original-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 Original-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) In-Reply-To: <87imusztof.fsf@tcd.ie> 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:158727 Archived-At: --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--