From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dmitrii Korobeinikov <dim1212k@gmail.com>
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: <CA+Yh0SSvQMucaC1EJR9GBxpKeP6haGiHN+Lf2QYo8csNoy0Waw__20013.4291940898$1556183116$gmane$org@mail.gmail.com>
References: <CA+Yh0SQ7yWQBjXhKbJPrCroriNpwhyFyQWAfHsUvxwmojsjKuw@mail.gmail.com>
	<87sgu6rhkt.fsf@gmail.com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="000000000000d322c3058756c536"
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([209.51.188.92]:60427)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) 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 <Debian-debbugs@debbugs.gnu.org>) id 1hJa16-00052M-R2
	for emacs-orgmode@gnu.org; Thu, 25 Apr 2019 04:46:05 -0400
Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
Resent-Message-ID: <handler.35419.B35419.15561816479559@debbugs.gnu.org>
In-Reply-To: <87sgu6rhkt.fsf@gmail.com>
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode/>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
Sender: "Emacs-orgmode"
	<emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
To: Noam Postavsky <npostavs@gmail.com>
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 <npostavs@gmail.com>:

> Dmitrii Korobeinikov <dim1212k@gmail.com> 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

<div dir=3D"ltr"><div dir=3D"ltr"><div>&gt; Have you looked at Phil Lord&#3=
9;s lentic package?=C2=A0 I think it implements a</div><div>&gt; lot of wha=
t you&#39;re talking about.</div><div><br></div><div>&gt; <a href=3D"https:=
//github.com/phillord/lentic">https://github.com/phillord/lentic</a></div><=
div><br></div><div>This is nice to see!</div><div>Indeed, except for embedd=
ing, there is a large overlap with what I described as buffer lenses.</div>=
<div><br></div><div>BTW, judging by this description: &quot;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&quot;, the buffers don&#39;t share any data and need to sync with the mas=
ter [linked] buffer.</div><div>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&#39;t need to be stripped of=
 properties beforehand, right?</div></div></div><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr" class=3D"gmail_attr">=D1=87=D1=82, 25 =D0=B0=D0=BF=D1=
=80. 2019 =D0=B3. =D0=B2 07:37, Noam Postavsky &lt;<a href=3D"mailto:nposta=
vs@gmail.com">npostavs@gmail.com</a>&gt;:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">Dmitrii Korobeinikov &lt;<a href=3D"mailto:dim121=
2k@gmail.com" target=3D"_blank">dim1212k@gmail.com</a>&gt; writes:<br>
<br>
&gt; * Implementation<br>
&gt;<br>
&gt;=C2=A0 =C2=A0I am not familiar with Emacs internals to say what&#39;s f=
easible of the<br>
&gt; proposed structure.<br>
<br>
Have you looked at Phil Lord&#39;s lentic package?=C2=A0 I think it impleme=
nts a<br>
lot of what you&#39;re talking about.<br>
<br>
<a href=3D"https://github.com/phillord/lentic" rel=3D"noreferrer" target=3D=
"_blank">https://github.com/phillord/lentic</a><br>
</blockquote></div>

--000000000000d322c3058756c536--