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--