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>> Have you looked at Phil Lord= 9;s lentic package?=C2=A0 I think it implements a</div><div>> lot of wha= t you're talking about.</div><div><br></div><div>> <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: "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.</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'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 <<a href=3D"mailto:nposta= vs@gmail.com">npostavs@gmail.com</a>>:<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 <<a href=3D"mailto:dim121= 2k@gmail.com" target=3D"_blank">dim1212k@gmail.com</a>> writes:<br> <br> > * Implementation<br> ><br> >=C2=A0 =C2=A0I am not familiar with Emacs internals to say what's f= easible of the<br> > proposed structure.<br> <br> Have you looked at Phil Lord's lentic package?=C2=A0 I think it impleme= nts a<br> lot of what you'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--