From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.bugs Subject: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) Date: Sun, 05 May 2019 14:07:07 +0800 Message-ID: <87muk1fn90.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="228588"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Philipp Stephani , Noam Postavsky To: Dmitrii Korobeinikov , 35419@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun May 05 08:09: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 1hNAKm-000xKj-Le for geb-bug-gnu-emacs@m.gmane.org; Sun, 05 May 2019 08:09:12 +0200 Original-Received: from localhost ([127.0.0.1]:36915 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNAKl-0003nh-FE for geb-bug-gnu-emacs@m.gmane.org; Sun, 05 May 2019 02:09:11 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35027) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNAKf-0003nT-6W for bug-gnu-emacs@gnu.org; Sun, 05 May 2019 02:09:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hNAKd-000302-AG for bug-gnu-emacs@gnu.org; Sun, 05 May 2019 02:09:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39345) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hNAKc-0002zq-N2; Sun, 05 May 2019 02:09:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hNAKc-0005rC-5q; Sun, 05 May 2019 02:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, emacs-orgmode@gnu.org Resent-Date: Sun, 05 May 2019 06:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35419 X-GNU-PR-Package: emacs,org-mode Original-Received: via spool by 35419-submit@debbugs.gnu.org id=B35419.155703649222449 (code B ref 35419); Sun, 05 May 2019 06:09:02 +0000 Original-Received: (at 35419) by debbugs.gnu.org; 5 May 2019 06:08:12 +0000 Original-Received: from localhost ([127.0.0.1]:52889 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hNAJn-0005pz-RK for submit@debbugs.gnu.org; Sun, 05 May 2019 02:08:12 -0400 Original-Received: from mail-pl1-f179.google.com ([209.85.214.179]:45951) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hNAJm-0005pl-2y for 35419@debbugs.gnu.org; Sun, 05 May 2019 02:08:10 -0400 Original-Received: by mail-pl1-f179.google.com with SMTP id o5so4717416pls.12 for <35419@debbugs.gnu.org>; Sat, 04 May 2019 23:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=Y3dGwnfGZ8eYECgKdm6Yf2gfLBGparZ3zXmExkn3K88=; b=QoUjIYx4MZltVbyWs5+MBCoeCVbAKjRIUz+bQxn3w3dailHW05Tmx7VqNAbV6H0Are EzhpHrrJRItEwnK6EU7H/UHiQNUvNQK9iw7+L+ht2YgCWu+rQrm0vOO6MQkTPrDsXQMc DsZwAlSCz5yO8AARQLWkT5WEEtgQx7KVsj0MOjKptqqogYPHh2JmwnzgYq/AGo+R6CoW RNYk+cGHXUUwhWE7NGgOoFOgJ6mJwo9sz4PEaRQU4GiAo2g69KHAiLfKdss9E/oHhRY0 pCA/ksZw3WGDqqMs4YN8pxVvuLxnuxoW2/d0VzPDi02ww6ha/9YvAiDlgNqBjs5sT70C cEFw== 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:in-reply-to:references:date :message-id:mime-version; bh=Y3dGwnfGZ8eYECgKdm6Yf2gfLBGparZ3zXmExkn3K88=; b=DSLjGEwC8tW4vEKZh0Gr5OecrFJsTrpBRQGGmy1glQSdAgQb2nF/LTSX23Kc3ZNwUG pW+tPU7Ik3KhCoLuNotYK61oLSVdE0xMA9HbhZzOHhrtM0/a+Rqgpdx7Q9XkqsErgs0Z 6DGKyGTMAXO4GiCYat6oRhH7KdqxsEd0evCP5ntYoQ1dCVYueuFKw+xb2NHpJzHukNrW Y9hjWGACi2ttOnxS5d8fRgE2IY8Ze4RDrWAGyEmaan/ymZeiTbWlaNrxXxhvT8RRCykv aa5p3RD93FUueu73T56U2z2PT4SwKvWbZ7qcsalZi8O4RDp+n8l6YmqvFVElnrZPwBnD 7+DA== X-Gm-Message-State: APjAAAVlwYadusVLeZ/+f4NLVRUnWSRTOC8qb6+KPt7rYLMJIZQtR1Kn 9t36IN7qUlcZG/7KVYWu+dI= X-Google-Smtp-Source: APXvYqzPJxYw68qQVauOlyqml5kLxfyAKTo61kgcCXIf5N/RdoKWUb8xP4UhtmZsd9cbJLkR29+xWQ== X-Received: by 2002:a17:902:407:: with SMTP id 7mr23039574ple.62.1557036484229; Sat, 04 May 2019 23:08:04 -0700 (PDT) Original-Received: from localhost ([45.41.180.82]) by smtp.gmail.com with ESMTPSA id m16sm10905184pfi.29.2019.05.04.23.08.01 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sat, 04 May 2019 23:08:03 -0700 (PDT) In-Reply-To: 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:158778 Archived-At: Dear Dmitrii, > Indirect buffers give the answer to the issue of sharing some textual data > between several buffer. Note that indirect buffers always share *all* the contents with the master buffer. As a result, it may not be easy to make things like flyspell work on code blocks in org-mode, if these code blocks are treated as lenses. > (1) A question: when an indirect buffer is created and some region is > narrowed to, is the rest of the buffer duplicated in memory somewhere? If > this is so, there could be a useful efficiency-related modification to > indirect buffers, which would allow "hard-narrowing": not duplicating the > rest of the base buffer. There is no duplication of the buffer content in indirect buffers. Internally, indirect buffer's content is a pointer to the main buffer content. If you modify text in any of the indirect buffers or in the main buffer, the text is modified in all of them and in the main buffer. Only the buffer-local variables are duplicated. You can refer to "27.11 Indirect Buffers" in the elisp manual for details. > The next immediately outstanding question is: > (2) how can "embedding" (of a buffer as a part of another buffer as an > area) be done efficiently? This could possibly be approached as two > problems: (i) displaying the area and (ii) interacting with it. > Any ideas? These issues have been discussed in https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00863.html. As I remember, the discussion stopped without a clear conclusion. It was not clear how to separate the main buffer contents from the nested buffer (I treat them as analogue of the buffer lenses). Another issue was how the keymaps and buffer-local variables would interact when the point is within a lense. It was not clear what should be the priority. Best, Ihor Dmitrii Korobeinikov writes: > I found a clarification on how mmm-mode works. > > https://github.com/polymode/polymode/issues/187 >> mmm-mode also allows having multiple major modes depending on cursor > position in the buffer. However, it does not fully replace major mode > locally. This mode is only taking care about keymap, menu, local variables, > font-lock, and indentation. It does not really take care about the minor > modes and does not run the submode hooks either. > > Just to reiterate, polymode's idea is to switch between indirect buffers, > one for each major mode. > > OK, detail largely disregarded, I now can draw a bird-eye view comparison > between lenses and multi-mode modes. > > - Neither polymode nor mmm-mode treat a region as if it were truly on its > own in a seperate buffer. > > Effects: no stuff like seperate truncation options, implied syntax checking > and so on. > > - Moreover, the region must be a part of the buffer. > > Effects: no data sharing between buffers, no possibility of stitching > different buffers together, etc. > > Now, with these out of the way. > > Indirect buffers give the answer to the issue of sharing some textual data > between several buffer. > (1) A question: when an indirect buffer is created and some region is > narrowed to, is the rest of the buffer duplicated in memory somewhere? If > this is so, there could be a useful efficiency-related modification to > indirect buffers, which would allow "hard-narrowing": not duplicating the > rest of the base buffer. > > The next immediately outstanding question is: > (2) how can "embedding" (of a buffer as a part of another buffer as an > area) be done efficiently? This could possibly be approached as two > problems: (i) displaying the area and (ii) interacting with it. > Any ideas? -- Ihor Radchenko,