From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitrii Korobeinikov 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" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:36028) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMJJI-0004mt-I1 for emacs-orgmode@gnu.org; Thu, 02 May 2019 17:32:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMJJH-0006h1-4U for emacs-orgmode@gnu.org; Thu, 02 May 2019 17:32:08 -0400 In-Reply-To: Sender: "Debbugs-submit" Resent-Message-ID: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: 35419@debbugs.gnu.org, Ihor Radchenko Cc: Philipp Stephani , Noam Postavsky --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--