From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitrii Korobeinikov Newsgroups: gmane.emacs.bugs Subject: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) Date: Fri, 3 May 2019 03:31:08 +0600 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d425750587ee5a78" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="15262"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Philipp Stephani , Noam Postavsky To: 35419@debbugs.gnu.org, Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 02 23:32:16 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 1hMJJQ-0003m6-4Y for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 May 2019 23:32:16 +0200 Original-Received: from localhost ([127.0.0.1]:58799 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMJJO-0004mv-Tp for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 May 2019 17:32:14 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36002) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMJJF-0004mJ-Mo for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 17:32:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMJJE-0006ek-DS for bug-gnu-emacs@gnu.org; Thu, 02 May 2019 17:32:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33629) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hMJJC-0006db-T9; Thu, 02 May 2019 17:32:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hMJJC-0000iv-J7; Thu, 02 May 2019 17:32:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Dmitrii Korobeinikov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, emacs-orgmode@gnu.org Resent-Date: Thu, 02 May 2019 21:32: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.15568326882737 (code B ref 35419); Thu, 02 May 2019 21:32:02 +0000 Original-Received: (at 35419) by debbugs.gnu.org; 2 May 2019 21:31:28 +0000 Original-Received: from localhost ([127.0.0.1]:47170 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMJId-0000i4-RV for submit@debbugs.gnu.org; Thu, 02 May 2019 17:31:28 -0400 Original-Received: from mail-wr1-f41.google.com ([209.85.221.41]:44719) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hMJIb-0000hq-ES for 35419@debbugs.gnu.org; Thu, 02 May 2019 17:31:26 -0400 Original-Received: by mail-wr1-f41.google.com with SMTP id c5so5296985wrs.11 for <35419@debbugs.gnu.org>; Thu, 02 May 2019 14:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=5KA8+/5QM2lMDmbixp2ulF9q14GyoakVDF3/KAILhe8=; b=ei2l+srvNKMInC//XbkUN+KyKXAKxuVoPxZjFShgh4PAwyfMYcFG6hdFbk9Ik3bFtx owCYsCAK4xSgURcs04LOE1+/vet6efVmRU1d+isUPiMutXHa7TJHfqZiv5wCSkRrOpWv jc455mGY0CmBItn7Bhu77TaSl324bF+ndCnJc38yjfw92cPMztMxQ0zXD5bnMQb3Nlj5 FceLo9j/H7QV+jrRXORxDArKXghx9H5bGV9W3sDeWHJbYFBO+udvOqLhc1+o4b3vmHKH 6Dokxp3ZWcN6BITIBruq8sX2+zgl3GzodoOgKqPdbGZF2UnapTz+9VErYGQ8f5rdAwe4 4/iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=5KA8+/5QM2lMDmbixp2ulF9q14GyoakVDF3/KAILhe8=; b=ZowCCFc/FOHryFjjc6VSw2/k9fbCcR3yo6uw/v75BzrvXj3dgjdnXmNAGZ12iPjpPD 4FLoQvOlwKqAzF6SjWf7SOZ6sNpKvVEcEeXggguNCB8cktpSd7qZUtfQ7t07CdxAa8Y4 JoReSCB+uxUljY/x4qVxzPqzu7O8N+YvRUIE0/ZfIh9NGYJXlXz5CiHpVi8avyVQyeDl wI65AOKorJg6a4xLm6v33ppYIm10qa7lVdvX/rSgc3kWCC0kj207nd6XRVA86yBzOqoJ PlLzMkCga3nrZScVQUirS5EOaID9u4BgsftEhN/W+CMR7/135TJPN/taVqilhHkfgRmq c6mQ== X-Gm-Message-State: APjAAAUgE6BmRvElFExmquzTq0rFeb1fgDyKWvFZp/wkWmepJY8nRnPU ITooSj8JpeUm4xqarTUpgwofZVshay4Cz7ZIDfz+ddlk X-Google-Smtp-Source: APXvYqy6683benp/Sy41G0h1eqYEDBrt/8NRekvSHI2bG0E5bEOxKPlz/4hKrPW/rC8N4wh/hvGHInbCIb3YFNP6wWU= X-Received: by 2002:a5d:4ccb:: with SMTP id c11mr4099842wrt.295.1556832679371; Thu, 02 May 2019 14:31:19 -0700 (PDT) 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:158668 Archived-At: --000000000000d425750587ee5a78 Content-Type: text/plain; charset="UTF-8" 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? --000000000000d425750587ee5a78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I found a clarification on how mmm-m= ode 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 mod= e locally. This mode is only taking care about keymap, menu, local variable= s, 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 buffer= s, one for each major mode.

OK, detail largely dis= regarded, I now can draw a bird-eye view comparison between lenses and mult= i-mode modes.

- Neither polymode nor mmm-mode trea= t a region as if it were truly on its own in a seperate buffer.
<= br>
Effects: no stuff like seperate truncation options, implied s= yntax checking and so on.

- Moreover, the region m= ust be a part of the buffer.

Effects: no data shar= ing between buffers, no possibility of stitching different buffers together= , etc.

Now, with these out of the way.
<= br>
Indirect buffers give the answer to the issue of sharing some= textual data between several buffer.
(1) A question: when an ind= irect 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 usef= ul efficiency-related modification to indirect buffers, which would allow &= quot;hard-narrowing": not duplicating the rest of the base buffer.

The next immediately outstanding question is:=C2=A0
(2) how can "embedding" (of a buffer as a part of anothe= r 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?
--000000000000d425750587ee5a78--