From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitrii Korobeinikov Subject: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) Date: Thu, 25 Apr 2019 01:20:42 +0600 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000ac92f805874b9965" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:53076) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJNZQ-0006F7-MP for emacs-orgmode@gnu.org; Wed, 24 Apr 2019 15:28:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJNRv-0007ll-MF for emacs-orgmode@gnu.org; Wed, 24 Apr 2019 15:20:56 -0400 Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:46879) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hJNRv-0007kw-G8 for emacs-orgmode@gnu.org; Wed, 24 Apr 2019 15:20:55 -0400 Received: by mail-wr1-x434.google.com with SMTP id t17so26653098wrw.13 for ; Wed, 24 Apr 2019 12:20:55 -0700 (PDT) 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: emacs-orgmode --000000000000ac92f805874b9965 Content-Type: text/plain; charset="UTF-8" I have written a proposal for buffer lenses which could prove useful in Org-mode, especially for interacting with code. If you are interested, please, see this link: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35419 --000000000000ac92f805874b9965 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have written a proposal for buffer= lenses which could prove useful in Org-mode, especially for interacting wi= th code.
If you are interested, please, see this link:
--000000000000ac92f805874b9965-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Noam Postavsky Subject: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) Date: Wed, 24 Apr 2019 21:37:06 -0400 Message-ID: <87sgu6rhkt.fsf__7720.79582545615$1556157580$gmane$org@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([209.51.188.92]:38396) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJTfC-0006Gj-Oc for emacs-orgmode@gnu.org; Wed, 24 Apr 2019 21:59:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJTPl-0005LQ-2f for emacs-orgmode@gnu.org; Wed, 24 Apr 2019 21:43:05 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: (Dmitrii Korobeinikov's message of "Thu, 25 Apr 2019 00:35:16 +0600") 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: Dmitrii Korobeinikov Cc: 35419@debbugs.gnu.org Dmitrii Korobeinikov writes: > * Implementation > > I am not familiar with Emacs internals to say what's feasible of the > proposed structure. Have you looked at Phil Lord's lentic package? I think it implements a lot of what you're talking about. https://github.com/phillord/lentic From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ihor Radchenko Subject: Re: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) Date: Thu, 25 Apr 2019 11:25:31 +0800 Message-ID: <87v9z2ojf8.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:51642) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJV2K-0000S5-Ol for emacs-orgmode@gnu.org; Wed, 24 Apr 2019 23:27:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJV1t-0004i1-Ar for emacs-orgmode@gnu.org; Wed, 24 Apr 2019 23:26:34 -0400 Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]:42923) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hJV1t-0004gX-2K for emacs-orgmode@gnu.org; Wed, 24 Apr 2019 23:26:33 -0400 Received: by mail-pl1-x634.google.com with SMTP id x15so5973597pln.9 for ; Wed, 24 Apr 2019 20:26:32 -0700 (PDT) In-Reply-To: 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: Dmitrii Korobeinikov , emacs-orgmode --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Dear Dmitrii, I strongly support the proposal. Another use case for me is to speed up agenda creation. I usually do not like to split my org files into too many. However, it results in very large and slow org buffers later. If I can store some parts of the org files externally and only show them if some condition is met (say, for certain todo state of the parent entry), it would speed up my agenda and the buffer navigation quite significantly. Example: #+begin_src org * Projects ** 2019 *** TODO Project 1 :ORG: # the project contents is stored in an external file :PROPERTIES: :ORG-FILE: project1.org :END: # beginning of a lense, which is linked to project1.org **** Heading 1 **** Heading 2 And many headings below # ... # end of the lense *** HOLD Project 2 :ORG: :PROPERTIES: :ORG-FILE: project2.org :END: # beginning of another lense # nothing is included here because the project state is =3DHOLD=3D # end of the lense #+end_src Let me put some historical context to this proposal. There was a discussion of similar feature in emacs-dev last year. The idea was to implement nested buffers: https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00863.html=20 There are also several projects, which implement part of the functionality you described: =2D mmm-mode: https://github.com/purcell/mmm-mode =2D polymode: https://github.com/polymode/polymode Best, Ihor Dmitrii Korobeinikov writes: > I have written a proposal for buffer lenses which could prove useful in > Org-mode, especially for interacting with code. > If you are interested, please, see this link: > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D35419 =2D-=20 Ihor Radchenko, --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERZAHPFbUe3JemmzmZHB2Kn2hHYsFAlzBKKsACgkQZHB2Kn2h HYvhWggAhFWJ0H2Ee1smwohWa3/IZuHyT+DRVrK4Kjg3zf++Akx5Ji+kdaq2/NEl dPjEyU+zg5/vst5vbspqnrxdKwDnT1OXkiNwkOAvsOqrcugaWzn++LgzjyHvlsyA 879XojEaWi4ZqJnvJcOjIcYP4fRlhUYgw9VuB0zTZs7Qz81ArqKpXepcgyTAfSNq VpLiO2fOtYil+RAkBwb8H/+iBs6r6/f80AwMKIASTStV9lyNf+z1Rk3zF94v4ICR g0zIG+Bd1uxHLX9f2/l0GlLkqpvXmJottWurQ7wgzKeU48bzTXfQcLZeoV1Odrfd 14vDeXG7s7pjxph8mRK2kQkSez/wzA== =oQYC -----END PGP SIGNATURE----- --=-=-=-- 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: Thu, 25 Apr 2019 14:40:27 +0600 Message-ID: References: <87sgu6rhkt.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d322c3058756c536" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:60427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJaHW-00084V-6Y for emacs-orgmode@gnu.org; Thu, 25 Apr 2019 05:03:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJa16-00052M-R2 for emacs-orgmode@gnu.org; Thu, 25 Apr 2019 04:46:05 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87sgu6rhkt.fsf@gmail.com> 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: Noam Postavsky Cc: 35419@debbugs.gnu.org --000000000000d322c3058756c536 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Have you looked at Phil Lord's lentic package? I think it implements a > lot of what you're talking about. > https://github.com/phillord/lentic This is nice to see! Indeed, except for embedding, there is a large overlap with what I described as buffer lenses. BTW, judging by this description: "changes percolation now happens incrementally, so only those parts of the buffer are updated. As a result, lentic now cope with long files with little noticable delay", the buffers don't share any data and need to sync with the master [linked] buffer. Is this the best solution? I have imagined that at the low level there is an actual data structure that keeps the raw textual data and it could be directly shared by multiple buffers. I mean, when a buffer is saved to a file, the text doesn't need to be stripped of properties beforehand, right? =D1=87=D1=82, 25 =D0=B0=D0=BF=D1=80. 2019 =D0=B3. =D0=B2 07:37, Noam Postav= sky : > Dmitrii Korobeinikov writes: > > > * Implementation > > > > I am not familiar with Emacs internals to say what's feasible of the > > proposed structure. > > Have you looked at Phil Lord's lentic package? I think it implements a > lot of what you're talking about. > > https://github.com/phillord/lentic > --000000000000d322c3058756c536 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Have you looked at Phil Lord= 9;s lentic package?=C2=A0 I think it implements a
> lot of wha= t you're talking about.

<= div>
This is nice to see!
Indeed, except for embedd= ing, there is a large overlap with what I described as buffer lenses.
=

BTW, judging by this description: "changes percola= tion now happens incrementally, so only those parts of the buffer are updat= ed. As a result, lentic now cope with long files with little noticable dela= y", the buffers don't share any data and need to sync with the mas= ter [linked] buffer.
Is this the best solution? I have imagined t= hat at the low level there is an actual data structure that keeps the raw t= extual data and it could be directly shared by multiple buffers. I mean, wh= en a buffer is saved to a file, the text doesn't need to be stripped of= properties beforehand, right?

=D1=87=D1=82, 25 =D0=B0=D0=BF=D1= =80. 2019 =D0=B3. =D0=B2 07:37, Noam Postavsky <npostavs@gmail.com>:
Dmitrii Korobeinikov <dim1212k@gmail.com> writes:

> * Implementation
>
>=C2=A0 =C2=A0I am not familiar with Emacs internals to say what's f= easible of the
> proposed structure.

Have you looked at Phil Lord's lentic package?=C2=A0 I think it impleme= nts a
lot of what you're talking about.

https://github.com/phillord/lentic
--000000000000d322c3058756c536-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: 'Ihor Radchenko' Subject: bug#35419: Fwd: Re: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) Date: Thu, 25 Apr 2019 15:11:50 +0800 Message-ID: <87lfzyo8y1.fsf__27767.3986785643$1556202430$gmane$org@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> References: <87v9z2ojf8.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="===-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:49854) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJfJ9-0001C2-Vz for emacs-orgmode@gnu.org; Thu, 25 Apr 2019 10:25:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJfJ8-0005IA-Ss for emacs-orgmode@gnu.org; Thu, 25 Apr 2019 10:25:03 -0400 In-Reply-To: Sender: "Debbugs-submit" Resent-Message-ID: Resent-To: 35419@debbugs.gnu.org Resent-Message-ID: <87mukel7bi.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> 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 --===-=-= Content-Type: multipart/mixed; boundary="==-=-=" --==-=-= Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 8bit From: Ihor Radchenko To: Dmitrii Korobeinikov , emacs-orgmode Subject: Re: [O] [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) In-Reply-To: References: Date: Thu, 25 Apr 2019 11:25:31 +0800 Message-ID: <87v9z2ojf8.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Dear Dmitrii, I strongly support the proposal. Another use case for me is to speed up agenda creation. I usually do not like to split my org files into too many. However, it results in very large and slow org buffers later. If I can store some parts of the org files externally and only show them if some condition is met (say, for certain todo state of the parent entry), it would speed up my agenda and the buffer navigation quite significantly. Example: #+begin_src org * Projects ** 2019 *** TODO Project 1 :ORG: # the project contents is stored in an external file :PROPERTIES: :ORG-FILE: project1.org :END: # beginning of a lense, which is linked to project1.org **** Heading 1 **** Heading 2 And many headings below # ... # end of the lense *** HOLD Project 2 :ORG: :PROPERTIES: :ORG-FILE: project2.org :END: # beginning of another lense # nothing is included here because the project state is =3DHOLD=3D # end of the lense #+end_src Let me put some historical context to this proposal. There was a discussion of similar feature in emacs-dev last year. The idea was to implement nested buffers: https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00863.html=20 There are also several projects, which implement part of the functionality you described: =2D mmm-mode: https://github.com/purcell/mmm-mode =2D polymode: https://github.com/polymode/polymode Best, Ihor Dmitrii Korobeinikov writes: > I have written a proposal for buffer lenses which could prove useful in > Org-mode, especially for interacting with code. > If you are interested, please, see this link: > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D35419 =2D-=20 Ihor Radchenko, --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERZAHPFbUe3JemmzmZHB2Kn2hHYsFAlzBKLIACgkQZHB2Kn2h HYtj9Af+KZCoKd0VpVeEIwMqBz6ZR85QivbX4XAmPVYNPPkYtCRhMU57DUqZ07ds jLo17wWoeS5Rxn3rLRZlWc9b1xYM3eLEl9LCiFKXoTALDVUKvyFSlVTqWiyRzEH6 wFSGj+PYwgcholtWD7GXL+S+VI4TG4UdfFhV+PlUtxtHwGk5A5UnwpeuUEngCE5K iJruXKyOioxrUdNbSuqehj56sWDivamacCfPNOPu4AIsjhA3++xivw17mD5Ss7Np dIr1EVCQfIlv3Hg+5LaOMRzwbJJEum7FnYPlI8ez7qyGm/qZATyEsyt4D7alqxq7 AiMfGILsiMtsy+fiycBkfuc8zFf81g== =rJlB -----END PGP SIGNATURE----- --=-=-=-- --==-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable =2D-=20 Ihor Radchenko, --==-=-=-- --===-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERZAHPFbUe3JemmzmZHB2Kn2hHYsFAlzBXbcACgkQZHB2Kn2h HYsdLQgAt+ddSsWcyLYmPVpzUWBB6BEsxrIh1m3LWWzugYJhl5Mw3CHtJbSyAZR0 Xy5a8nXLq0snlgDU6Gfiq3YRmU4fbdotGhmuwOyEgtUWabD0fQJ87cKjOsu6wPin Fk2w3J4SUB5v6zK6bZczL5rYtFVWY+xhwZeKqJRBfv7azVWm2dnuwbuakPhUuTKn Fa8JKtoBfcI7kpuI5JhJb+GMORCskbUv8ryL1XjmdYMGLF2Exdq5cR0V+UVZ6DYN R2F7t1lZRfnIzMZrfuzvBSr4v9C+p34x3EdF1vXIS+VqqRsGG4koyhx5oKKjS7bE ryr+LKp5zAWs/WSwAtpt5t9B+zuFBg== =rpgv -----END PGP SIGNATURE----- --===-=-=-- 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, 26 Apr 2019 03:00:12 +0600 Message-ID: References: <87v9z2ojf8.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000006420f00587611b81" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:51031) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJlUS-0006Is-J0 for emacs-orgmode@gnu.org; Thu, 25 Apr 2019 17:01:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJlUQ-00043g-PA for emacs-orgmode@gnu.org; Thu, 25 Apr 2019 17:01:08 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87v9z2ojf8.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> 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: Ihor Radchenko Cc: 35419@debbugs.gnu.org --0000000000006420f00587611b81 Content-Type: text/plain; charset="UTF-8" Dear Ihor, > Another use case for me is to speed up agenda creation. > I usually do not like to split my org files into too many. However, it > results in very large and slow org buffers later. If I can store some > parts of the org files externally and only show them if some condition > is met (say, for certain todo state of the parent entry), it would speed > up my agenda and the buffer navigation quite significantly. That's a good one! > Let me put some historical context to this proposal. > There was a discussion of similar feature in emacs-dev last year. > The idea was to implement nested buffers: > https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00863.html An interesting read, provides another use-case (collect external data in one place to easily view/edit): https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00890.html > There are also several projects, which implement part of the > functionality you described: > - mmm-mode: https://github.com/purcell/mmm-mode > - polymode: https://github.com/polymode/polymode Pretty cool stuff. For thoroughness, let's discuss how these work. I found a comment which mentions polymode's working principle. https://www.reddit.com/r/emacs/comments/50p34n/polymode_is_awesome/?depth=1 >> Polymode doesn't keep its modes in a single emacs buffer but in several indirect buffers, as many as different modes are there in a file. Consequently, polymode is as fast as switching emacs buffers because it never re-installs major modes like other multi-modes do. Dave Love's multi-mode.el gets full credit for this idea. > It looks like it slows emacs to a crawl in my main org config file. It seems to work fairly well in some of my notes files (though with some weird indenting behavior). Basically, simplicity is in place but at the cost of duplication. Lenses could avoid duplication, while yielding increased functionality and speed. (e.g. in polymode, a syntax checker couldn't yield correct results unless narrowing was constantly used, which is inefficient) Now, to MMM-mode. According to the info file: > Within the file, MMM-mode creates /submode regions/ within which other major modes are in effect. > While the point is in a submode region, the following changes occur: > <...> keymap <...> local variables <...> syntax table and indentation <...> font-lock > The submode regions are represented internally by Emacs Lisp objects known as /overlays/. > A lot of the functionality of MMM Mode---that which makes the major mode > appear to change---is implemented by saving and restoring the values of > local variables, or pseudo-variables. What I don't understand is where the modes of the submode region run and when they are turned on. Are necessary modes just allowed to run at the right time for the whole buffer? But then, how are they limited in their effect to just the necessary region? Narrowing? Could, for example, syntax checking be done efficiently that way? Could someone, please, explain? Best regards, Dmitrii. --0000000000006420f00587611b81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Ihor,

> Another use case for me is to speed up agenda creatio= n.
> I usually do not like to split my org files into too many= . However, it
> results in very large and slow org buffers lat= er. If I can store some
> parts of the org files externally an= d only show them if some condition
> is met (say, for certain = todo state of the parent entry), it would speed
> up my agenda= and the buffer navigation quite significantly.

Th= at's a good one!

> Let me put some historic= al context to this proposal.
> There was a discussion of simil= ar feature in emacs-dev last year.
> The idea was to implement= nested buffers:

An inter= esting read, provides another use-case (collect external data in one place = to easily view/edit):

> There are= also several projects, which implement part of the
> function= ality you described:

Pretty cool stuff. For= thoroughness, let's discuss how these work.

I= found a comment which mentions polymode's working principle.
https://www.reddit.com/r/emacs/comments/50p34n/polymode_is_= awesome/?depth=3D1
>> Polymode doesn't keep its mod= es in a single emacs buffer but in several indirect buffers, as many as dif= ferent modes are there in a file. Consequently, polymode is as fast as swit= ching emacs buffers because it never re-installs major modes like other mul= ti-modes do. Dave Love's multi-mode.el gets full credit for this idea.<= /div>
> It looks like it slows emacs to a crawl in my main org confi= g file. It seems to work fairly well in some of my notes files (though with= some weird indenting behavior).

Basically, simpli= city is in place but at the cost of duplication.
Lenses could avo= id duplication, while yielding increased functionality and speed.
(e.g. in polymode, a syntax checker couldn't yield correct results unl= ess narrowing was constantly used, which is inefficient)

Now, to MMM-mode. According to the info file:

> Within the file, MMM-mode creates /submode regions/ within which ot= her major modes are in effect.

> While the poin= t is in a submode region, the following changes occur:
> <.= ..> keymap <...> local variables <...> syntax table and inde= ntation <...> font-lock

> The submode reg= ions are represented internally by Emacs Lisp objects known as /overlays/.<= /div>

> A lot of the functionality of MMM Mode---that= which makes the major mode
> appear to change---is implemente= d by saving and restoring the values of
> local variables, or = pseudo-variables.

What I don't understand is w= here the modes of the submode region run and when they are turned on.
=
Are necessary modes just allowed to run at the right time for the whol= e buffer? But then, how are they limited in their effect to just the necess= ary region? Narrowing?
Could, for example, syntax checking be don= e efficiently that way?
Could someone, please, explain?

Best regards,
Dmitrii.
--0000000000006420f00587611b81-- 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, 26 Apr 2019 03:14:33 +0600 Message-ID: References: <87sgu6rhkt.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a59a960587614eb9" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:55172) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJlss-0003EY-Tu for emacs-orgmode@gnu.org; Thu, 25 Apr 2019 17:26:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJlhy-0003f1-HI for emacs-orgmode@gnu.org; Thu, 25 Apr 2019 17:15:07 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: 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: Philipp Stephani Cc: Noam Postavsky , 35419@debbugs.gnu.org --000000000000a59a960587614eb9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D1=87=D1=82, 25 =D0=B0=D0=BF=D1=80. 2019 =D0=B3. =D0=B2 23:52, Philipp Ste= phani : > Am Do., 25. Apr. 2019 um 10:41 Uhr schrieb Dmitrii Korobeinikov > : > > I have imagined that at the low level there is an actual data structure > that keeps the raw textual data and it could be directly shared by multip= le > buffers. > > That's what indirect buffers do. Maybe the indirect buffer > functionality could be beefed up to support what you want? > https://www.gnu.org/software/emacs/manual/html_node/emacs/Indirect-Buffers.= html > The text of the indirect buffer is always identical to the text of its base buffer; changes made by editing either one are visible immediately in the other. But in all other respects, the indirect buffer and its base buffer are completely separate. They can have different names, different values of point, different narrowing, different markers, different major modes, and different local variables. Awesome! Looks like we have some solid rails to drive on. BTW what's the purpose of lentic-mode then? To be "providing multiple persistent views"? https://github.com/phillord/lentic --000000000000a59a960587614eb9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=D1=87=D1=82, 25 = =D0=B0=D0=BF=D1=80. 2019 =D0=B3. =D0=B2 23:52, Philipp Stephani <p.stephani2@gmail.com>:
<= /div>
Am Do., 25. Apr. 2019 um 10:41 Uhr schrieb Dmitrii Korobeiniko= v
<dim1212k@gmail.= com>:
> I have imagined that at the low level there is an actual data structur= e that keeps the raw textual data and it could be directly shared by multip= le buffers.

That's what indirect buffers do. Maybe the indirect buffer
functionality could be beefed up to support what you want?
=

> The text o= f the indirect buffer is always identical to the text of its base buffer; c= hanges made by editing either one are visible immediately in the other. But= in all other respects, the indirect buffer and its base buffer are complet= ely separate. They can have different names, different values of point, dif= ferent narrowing, different markers, different major modes, and different l= ocal variables.

Awesome! Looks like we have some s= olid rails to drive on.

BTW what's the purpose= of lentic-mode then? To be "providing multiple persistent views"= ?
--000000000000a59a960587614eb9-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roland Everaert Subject: Re: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) Date: Fri, 26 Apr 2019 14:05:03 +0200 Message-ID: <877ebhnf9s.fsf@gmail.com> References: <87sgu6rhkt.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:37708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJzbO-0001jD-MW for emacs-orgmode@gnu.org; Fri, 26 Apr 2019 08:05:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJzbN-0000ZU-Du for emacs-orgmode@gnu.org; Fri, 26 Apr 2019 08:05:14 -0400 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]:55772) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hJzbN-0000VE-6q for emacs-orgmode@gnu.org; Fri, 26 Apr 2019 08:05:13 -0400 Received: by mail-wm1-x32a.google.com with SMTP id o25so3489778wmf.5 for ; Fri, 26 Apr 2019 05:05:11 -0700 (PDT) In-reply-to: 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: emacs-orgmode@gnu.org Cc: Noam Postavsky , 35419@debbugs.gnu.org I see lens to be useful for the eev mode, too. Roland. Dmitrii Korobeinikov writes: >> Have you looked at Phil Lord's lentic package? I think it implements a >> lot of what you're talking about. > >> https://github.com/phillord/lentic > > This is nice to see! > Indeed, except for embedding, there is a large overlap with what I > described as buffer lenses. > > BTW, judging by this description: "changes percolation now happens > incrementally, so only those parts of the buffer are updated. As a result, > lentic now cope with long files with little noticable delay", the buffers > don't share any data and need to sync with the master [linked] buffer. > Is this the best solution? I have imagined that at the low level there is > an actual data structure that keeps the raw textual data and it could be > directly shared by multiple buffers. I mean, when a buffer is saved to a > file, the text doesn't need to be stripped of properties beforehand, righ= t? > > =D1=87=D1=82, 25 =D0=B0=D0=BF=D1=80. 2019 =D0=B3. =D0=B2 07:37, Noam Post= avsky : > >> Dmitrii Korobeinikov writes: >> >> > * Implementation >> > >> > I am not familiar with Emacs internals to say what's feasible of the >> > proposed structure. >> >> Have you looked at Phil Lord's lentic package? I think it implements a >> lot of what you're talking about. >> >> https://github.com/phillord/lentic >> --=20 Luke, use the FOSS Sent from Emacs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Philipp Stephani Subject: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) Date: Thu, 25 Apr 2019 19:52:34 +0200 Message-ID: References: <87sgu6rhkt.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:40435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJiYQ-00078M-Vs for emacs-orgmode@gnu.org; Thu, 25 Apr 2019 13:53:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJiYQ-0001UW-4p for emacs-orgmode@gnu.org; Thu, 25 Apr 2019 13:53:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: 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: Dmitrii Korobeinikov Cc: Noam Postavsky , 35419@debbugs.gnu.org Am Do., 25. Apr. 2019 um 10:41 Uhr schrieb Dmitrii Korobeinikov : > I have imagined that at the low level there is an actual data structure that keeps the raw textual data and it could be directly shared by multiple buffers. That's what indirect buffers do. Maybe the indirect buffer functionality could be beefed up to support what you want? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitrii Korobeinikov Subject: bug#35419: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) Date: Fri, 3 May 2019 03:24:08 +0600 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000c7c92d0587ee41da" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:34783) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMJCR-0001ew-GI for emacs-orgmode@gnu.org; Thu, 02 May 2019 17:25:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMJCQ-00014z-Cj for emacs-orgmode@gnu.org; Thu, 02 May 2019 17:25:03 -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, reveatwork@gmail.com --000000000000c7c92d0587ee41da Content-Type: text/plain; charset="UTF-8" > I see lens to be useful for the eev mode, too. Never heard of eev, but judging by some demos, it's a way to execute elisp commands interactively. Something like stitching blocks of commands together, or the data to operate on, or embedding a target such as a shell in the same buffer is the use-case idea then? --000000000000c7c92d0587ee41da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0I see lens to= be useful for the eev mode, too.

Never hea= rd of eev, but judging by some demos, it's a way to execute elisp comma= nds interactively.
Something like stitching blocks of commands to= gether, or the data to operate on, or embedding a target such as a shell in= the same buffer is the use-case idea then?
--000000000000c7c92d0587ee41da-- 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-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1 with LMTPS id WMjtJ7k4iV4VUAAAk0OIDg (envelope-from ) for ; Sun, 05 Apr 2020 01:47:37 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id QEWgB7g4iV7KFwAAbx9fmQ (envelope-from ) for ; Sun, 05 Apr 2020 01:47:36 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id F28B0941B6B for ; Sun, 5 Apr 2020 01:47:33 +0000 (UTC) Received: from localhost ([::1]:43736 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKuNn-0001Uu-3Q for larch@yhetil.org; Sat, 04 Apr 2020 21:47:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55669) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKuNL-0001UP-5P for emacs-orgmode@gnu.org; Sat, 04 Apr 2020 21:47:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jKuNK-0003hS-3e for emacs-orgmode@gnu.org; Sat, 04 Apr 2020 21:47:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:33459) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jKuNJ-0003hD-UB; Sat, 04 Apr 2020 21:47:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jKuNJ-0001CV-Rr; Sat, 04 Apr 2020 21:47:01 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#35419: [O] [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, emacs-orgmode@gnu.org Resent-Date: Sun, 05 Apr 2020 01:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35419 X-GNU-PR-Package: emacs,org-mode X-GNU-PR-Keywords: To: Dmitrii Korobeinikov , Ihor Radchenko Received: via spool by 35419-submit@debbugs.gnu.org id=B35419.15860511794459 (code B ref 35419); Sun, 05 Apr 2020 01:47:01 +0000 Received: (at 35419) by debbugs.gnu.org; 5 Apr 2020 01:46:19 +0000 Received: from localhost ([127.0.0.1]:45005 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jKuMc-00019r-UO for submit@debbugs.gnu.org; Sat, 04 Apr 2020 21:46:19 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]:33948) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jKuMb-00019Q-BS for 35419@debbugs.gnu.org; Sat, 04 Apr 2020 21:46:17 -0400 Received: by mail-wr1-f43.google.com with SMTP id 65so13207758wrl.1 for <35419@debbugs.gnu.org>; Sat, 04 Apr 2020 18:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Wj4hoQ++aIkijeQbTJKoFwP01RC2GK08HoB5D3/RkHw=; b=DEINpwY/FRhkcC1gtKkUidAZSDF27enntHlpHuLPdfkIxhZsW4c2S5Y97T7adLugeM fo0KewI+hcofRGHfZmRPtcx2d9xXrjS79rRhB2b6ebQAFEPbF+jt3Q80b+IdX3nqNlVa SnwIBTYvjOMnSKsrG9V6/cUmh751yQLpx03As1uSNAiAk3sh+qlMrLJDkbxXg/vOGshz Ma+JVsWRPoXor/K9c/yTd3UPKi/O/9f5eeoSPRgUCec2vmKSUCdS/I2sCYN1zus12LeW nuevFoP65NpnTEQYHskvJkWehn1WvplGpAKjljXsQ5PSHLHkaoGAf7XDr+EfxKzoqp/x eULg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Wj4hoQ++aIkijeQbTJKoFwP01RC2GK08HoB5D3/RkHw=; b=dhgixSwRL3mBKQVy792UAWkl0tHsRvrsZwLAFSh9zYYxS4VHoIjzoEafUfhfHwIN2C 7e+IUqhrjqq/yEh2olNPi6Or3IIYa88deUv7IS4NVXX/OiNNi0MDUHm/ZBjVPDCFcyiE 1vKA1mbiwz7diWiv/1tn9hxpQI0xWaOUHlBZ4CJdpzT3DTdGCkUwchrcmMtCxa4R8RS6 Uw6FPPakw7nVowKLALDfLENDCuhaDAvF74YvW3UfufL4grcP1STrnxn7h8OOS4FOJsET UaA9hCO8IGTgve0XpQjBAP1WQHNNQNAkdkJY9/Ijqc394977sjR2joPIxZBwayVqjnDd J/aw== X-Gm-Message-State: AGi0PuYrRIkjeik1P+tgnlJSM8qzY4ObaX1fN5Y9RpDbCbzIOQaGRUFr BGAfLY0bct+PnPBiDLYnVD2slCf25r0= X-Google-Smtp-Source: APiQypKfumo2BaMCIAIJj6vUNTl5zWOrIM2QICP29uk1sdn8cjNHTHNn5dLBakHZeWdtbqbXCLrrDQ== X-Received: by 2002:adf:f808:: with SMTP id s8mr7877614wrp.219.1586051170727; Sat, 04 Apr 2020 18:46:10 -0700 (PDT) Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id y22sm199579wma.0.2020.04.04.18.46.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Apr 2020 18:46:10 -0700 (PDT) References: <87v9z2ojf8.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> From: Dmitry Gutov Message-ID: <4bb84e9a-7058-3deb-30f0-b4c8f337b116@yandex.ru> Date: Sun, 5 Apr 2020 04:46:08 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: emacs-orgmode@gnu.org List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 35419@debbugs.gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=default; t=1586051254; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=Wj4hoQ++aIkijeQbTJKoFwP01RC2GK08HoB5D3/RkHw=; b=bRWS0+8cI+jkt0PRCME0A1/qb6Pjab9IzouKA0/7UEramsF0vZvKHR0tErYj+MKDy0Ehvl 5kuh4HKwWraFb/h6hdUUQxL1oWnmtOjlDOECitUqGqMbRQqpvWSl/gTzyYBwRF3CvQDSvH UIMHlfiT5nYOnMvYvcKQ2XcPLi18sHI= ARC-Seal: i=1; s=default; d=yhetil.org; t=1586051254; a=rsa-sha256; cv=none; b=Ki6WSds7IwAC5pxNqc0LEGh1qbueUvbrDxKwOVS5dNP+psZr4ELsiYSzGwxMy8UuxJoDeM 3AasgVIsN95zUkMqSmgxV3L6sCkz341R5npbXapVr+UyJLLrhvGAINoGKtxVls4s17/d5S TtQgmLuy/ynbbZ9ubbSQsnJoW6+/Jxc= ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=gmail.com header.s=20161025 header.b=DEINpwY/; dmarc=fail reason="SPF not aligned (relaxed)" header.from=yandex.ru (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Scanner: scn0 X-Spam-Score: 0.09 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=gmail.com header.s=20161025 header.b=DEINpwY/; dmarc=fail reason="SPF not aligned (relaxed)" header.from=yandex.ru (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Scan-Result: default: False [0.09 / 13.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; GENERIC_REPUTATION(0.00)[-0.58645268137193]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.51.188.0/24:c]; R_DKIM_REJECT(1.00)[gmail.com:s=20161025]; FREEMAIL_FROM(0.00)[yandex.ru]; ARC_SIGNED(0.00)[i=1]; IP_REPUTATION_HAM(0.00)[asn: 22989(0.33), country: US(-0.01), ip: 209.51.188.17(-0.59)]; DKIM_TRACE(0.00)[gmail.com:-]; MX_GOOD(-0.50)[cached: eggs.gnu.org]; MAILLIST(-0.20)[mailman]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_RECIPIENTS_MAILLIST(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:22989, ipnet:209.51.188.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[larch=yhetil.org]; ARC_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[dgutov@yandex.ru,emacs-orgmode-bounces@gnu.org]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[35419@debbugs.gnu.org]; HAS_LIST_UNSUB(-0.01)[]; RCVD_COUNT_SEVEN(0.00)[10]; FORGED_SENDER_MAILLIST(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[yandex.ru : SPF not aligned (relaxed),none] X-TUID: XOne9uxv+NT6 Hi! Some late clarifications about mmm-mode. On 26.04.2019 00:00, Dmitrii Korobeinikov wrote: > > A lot of the functionality of MMM Mode---that which makes the major mode > > appear to change---is implemented by saving and restoring the values of > > local variables, or pseudo-variables. > > What I don't understand is where the modes of the submode region run and > when they are turned on. They are run in an empty temporary buffer, see mmm-update-mode-info. That is true for all the "submodes" in a buffer. The primary major mode is run in the context of that buffer (IIRC). After any of them runs, the code responsible for it collects the values of a certain number of known variables and associates that map with the major mode (this is a bit of a simplification). > Are necessary modes just allowed to run at the right time for the whole > buffer? When you move between the "chunks", no major mode functions are called. Instead, the values of variables are swapped in. Including the value of the 'major-mode' variable. > But then, how are they limited in their effect to just the > necessary region? Narrowing? Usually, yes. Especially when we're talking about font-lock and syntax-propertize-function. See mmm-fontify-region-list for an example. > Could, for example, syntax checking be done efficiently that way? That depends on the combination of modes and how they are used (either they can be nested, like in web templates, or it's a flat list where chunks are largely independent like in Jupyter). But in most cases, I think, you could pick a good strategy. There are no universal ones, though. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1 with LMTPS id qMPREoiuiV6rHAAAk0OIDg (envelope-from ) for ; Sun, 05 Apr 2020 10:10:16 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id mKp6LoauiV6FJgAAB5/wlQ (envelope-from ) for ; Sun, 05 Apr 2020 10:10:14 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 30BCC942684 for ; Sun, 5 Apr 2020 10:06:47 +0000 (UTC) Received: from localhost ([::1]:46458 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jL2Aw-0001fC-0m for larch@yhetil.org; Sun, 05 Apr 2020 06:06:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37197) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jL2AI-0001dI-2n for emacs-orgmode@gnu.org; Sun, 05 Apr 2020 06:06:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jL2AE-0001I7-98 for emacs-orgmode@gnu.org; Sun, 05 Apr 2020 06:06:06 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:33670) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jL2AE-0001Hq-6G; Sun, 05 Apr 2020 06:06:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jL2AD-0007rC-Vp; Sun, 05 Apr 2020 06:06:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#35419: [O] [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) Resent-From: Dmitrii Korobeinikov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, emacs-orgmode@gnu.org Resent-Date: Sun, 05 Apr 2020 10:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35419 X-GNU-PR-Package: emacs,org-mode X-GNU-PR-Keywords: To: Dmitry Gutov Received: via spool by 35419-submit@debbugs.gnu.org id=B35419.158608112730096 (code B ref 35419); Sun, 05 Apr 2020 10:06:01 +0000 Received: (at 35419) by debbugs.gnu.org; 5 Apr 2020 10:05:27 +0000 Received: from localhost ([127.0.0.1]:45216 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jL29f-0007pL-3K for submit@debbugs.gnu.org; Sun, 05 Apr 2020 06:05:27 -0400 Received: from mail-wm1-f48.google.com ([209.85.128.48]:35559) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jL29d-0007ov-Sk for 35419@debbugs.gnu.org; Sun, 05 Apr 2020 06:05:26 -0400 Received: by mail-wm1-f48.google.com with SMTP id i19so12596906wmb.0 for <35419@debbugs.gnu.org>; Sun, 05 Apr 2020 03:05:25 -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:content-transfer-encoding; bh=LgYS1j8Jy35QSeYIOi29s1pGROb3CIAI/he3OBpiFHM=; b=kf6gmJE06Xu6pX0YUfZKKlOmjFC0U+qkcqmmwJVgxQPTRweriSUCEpJsy4tMKjj7E2 /WZeMGUE0C6g3hNicTmSZOfHuR9JW3WkfXGk0wSYeLZ+NbaJDnKu4w7FYtd2ek2MTVM3 MwrarA4X//mF5vNupa5ztWP7gNOXY+OTDOLiSk8EQlorVsY1hnuqPLftbQkG9WrgDQ57 O8BGx3FofgiB/ASubPs9PUwYqw8oYQ+oIZtz42Bal4ZtO/xVWDpA+sk3ouajKlWkuvPs YjowK1Fa+RUi1yHFJxEYylBwcTiaUwa3+gkaUNm93OEHlr2sr0W+PRRpi7MOixBSTR9G y7ww== 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:content-transfer-encoding; bh=LgYS1j8Jy35QSeYIOi29s1pGROb3CIAI/he3OBpiFHM=; b=LA9Ccmzc2bnB4kJXh8eYxTGN1ImcGF8TbyAeHPhHASp5in4uoeD+gO9BWG3wK7wf/w lRNuFtA0UKNMr/o5IhHyURBeuXgKbKsaOlHjt9jOcs5wOB3YGJN6q7Jx6+Vy3KbW5vdz OnP7yDlESYTQsL8g8MaHGEsM9QWsq3gF2OPyFA33ZUTg4h90Oh4EcyndXp6v0dMcYg9O f1MFly8IpTHih77/BLylWbRatJF8IFmXaGvKhSjt1tEkygILs3JR9yxHMcep3n/63Ty9 Ht/nUmiKJB3Z96bWPR8JnH2nUu54x9wT4/GzUZP9YYDmeLOGSustF9u4rTLBtcbPUu0O y3kA== X-Gm-Message-State: AGi0PuZwQKPJjDo0ZqHXoJ21qfwfbCT+uPCjeIxqOj5V1NqsNyQTGDw5 u7eLpRkwDeZCnapkdrROqvtEEjHQ4/NLIjJv8+M= X-Google-Smtp-Source: APiQypLx9bjUiwsVvMqOMCNxyUu9QWcswX+Cj8LJ1ckEGP4DwfYuDAHfJ4Kh4BaRrCUG726Kk77XWfehGBIBEPjOg8E= X-Received: by 2002:a1c:6503:: with SMTP id z3mr7152239wmb.92.1586081120061; Sun, 05 Apr 2020 03:05:20 -0700 (PDT) MIME-Version: 1.0 References: <87v9z2ojf8.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <4bb84e9a-7058-3deb-30f0-b4c8f337b116@yandex.ru> In-Reply-To: <4bb84e9a-7058-3deb-30f0-b4c8f337b116@yandex.ru> From: Dmitrii Korobeinikov Date: Sun, 5 Apr 2020 16:05:08 +0600 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: emacs-orgmode@gnu.org List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ihor Radchenko , 35419@debbugs.gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=default; t=1586081207; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=LgYS1j8Jy35QSeYIOi29s1pGROb3CIAI/he3OBpiFHM=; b=ZjgqazCtYGe6o9aSqHBp8N8bw/J0AjKbBAiNJTntL+/6fLswcOPgiCwG3Rc2g0GIwp5PbF SXfhDRnIODeKcT7M7mVyE48mKX4wzLKpbrKN18KSGLdPlRaSmjYzSrIzA0mP1p8e6/7Lst Hy5QK0nu693QU2pRa4B/bX1eAPoLS+I= ARC-Seal: i=1; s=default; d=yhetil.org; t=1586081207; a=rsa-sha256; cv=none; b=TK2slYwZhsCtr78GYUFc3qWg+s0W8i8jgzl0T/gqDOfTYgv95Ffus4DNlrmkOn0M8dUo6T fNsi3vWm+E4evq0QWVd2E/hkE6NuKUzR+GWBkNfZeRODwNaO/Hwtn41qoxgCeXP46PENtl 76n+ULZU0s1mr8NqnKTg1U5vBNa44Vg= ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=gmail.com header.s=20161025 header.b=kf6gmJE0; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Scanner: scn0 X-Spam-Score: 0.09 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=gmail.com header.s=20161025 header.b=kf6gmJE0; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Scan-Result: default: False [0.09 / 13.00]; GENERIC_REPUTATION(0.00)[-0.58579847071069]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.51.188.0/24:c]; R_DKIM_REJECT(1.00)[gmail.com:s=20161025]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_SIGNED(0.00)[i=1]; IP_REPUTATION_HAM(0.00)[asn: 22989(0.33), country: US(-0.01), ip: 209.51.188.17(-0.59)]; DKIM_TRACE(0.00)[gmail.com:-]; MX_GOOD(-0.50)[cached: eggs.gnu.org]; MAILLIST(-0.20)[mailman]; FREEMAIL_TO(0.00)[yandex.ru]; FORGED_RECIPIENTS_MAILLIST(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:22989, ipnet:209.51.188.0/24, country:US]; FROM_NEQ_ENVFROM(0.00)[dim1212k@gmail.com,emacs-orgmode-bounces@gnu.org]; TAGGED_FROM(0.00)[larch=yhetil.org]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[35419@debbugs.gnu.org]; HAS_LIST_UNSUB(-0.01)[]; FREEMAIL_CC(0.00)[gmail.com,debbugs.gnu.org]; RCVD_COUNT_SEVEN(0.00)[9]; FORGED_SENDER_MAILLIST(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : SPF not aligned (relaxed),none] X-TUID: C7W3wkeW4GBj Thank you for the insight and the references! Quite useful to learn about this stuff. =D0=B2=D1=81, 5 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 07:46, Dmitry Gutov= : > > Hi! > > Some late clarifications about mmm-mode. > > On 26.04.2019 00:00, Dmitrii Korobeinikov wrote: > > > A lot of the functionality of MMM Mode---that which makes the major = mode > > > appear to change---is implemented by saving and restoring the values= of > > > local variables, or pseudo-variables. > > > > What I don't understand is where the modes of the submode region run an= d > > when they are turned on. > > They are run in an empty temporary buffer, see mmm-update-mode-info. > That is true for all the "submodes" in a buffer. The primary major mode > is run in the context of that buffer (IIRC). After any of them runs, the > code responsible for it collects the values of a certain number of known > variables and associates that map with the major mode (this is a bit of > a simplification). > > > Are necessary modes just allowed to run at the right time for the whole > > buffer? > > When you move between the "chunks", no major mode functions are called. > Instead, the values of variables are swapped in. Including the value of > the 'major-mode' variable. > > > But then, how are they limited in their effect to just the > > necessary region? Narrowing? > > Usually, yes. Especially when we're talking about font-lock and > syntax-propertize-function. See mmm-fontify-region-list for an example. > > > Could, for example, syntax checking be done efficiently that way? > > That depends on the combination of modes and how they are used (either > they can be nested, like in web templates, or it's a flat list where > chunks are largely independent like in Jupyter). But in most cases, I > think, you could pick a good strategy. There are no universal ones, thoug= h.