Received: (at 35419) by debbugs.gnu.org; 2 Jun 2019 09:10:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jun 02 05:10:06 2019 Received: from localhost ([127.0.0.1]:39443 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hXMVC-0007Va-B7 for submit <at> debbugs.gnu.org; Sun, 02 Jun 2019 05:10:06 -0400 Received: from mail-wm1-f41.google.com ([209.85.128.41]:34748) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dim1212k@HIDDEN>) id 1hXMVA-0007V1-Vb for 35419 <at> debbugs.gnu.org; Sun, 02 Jun 2019 05:10:05 -0400 Received: by mail-wm1-f41.google.com with SMTP id w9so1747160wmd.1 for <35419 <at> debbugs.gnu.org>; Sun, 02 Jun 2019 02:10:04 -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; bh=5kEo7iGeVJvhXibPHhQI4u1BeVKZtiGsToCmK6t23HU=; b=sR7g75X3sOQQX6pRjiprOaeZ4SJyNS0Yy83UpZMUkwLASFdWB97/TvKEfFDObHC4mK Ub6yayRzTgup53mPnEn/KDyScavHaqtt06rrP8vpRwtAVJ+OPc93V8eRLULpXnLCPUKq Itj5ryQobJDQbNYre13ysd3l0i5docoH541Na2aEcgBD+aUF+exdGNYP2wsRNud4q5sB 7FqRPtN/u4RQ4Ex75eGqbDBDwtX3sQCvf+WzUCN2MI0xHKnPpQIkDLryllXt42MMpNID cTpagMhsrYm2b2gxAx8vNMm4UT/JkfyWBGMM/BN4WMRXcs4M4W+YQq+8HlX3a2fao97B 0iCg== 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; bh=5kEo7iGeVJvhXibPHhQI4u1BeVKZtiGsToCmK6t23HU=; b=mci3eUftEZe6hL0+jZroAzD/5waQbDvGQtL3kZVvvvLWct12xbULE7CiW/m90wORb8 KsirDMl+kFM8yPQDzIa94CsaKivwAmF3cZ1FrfLr/3/fzFE1QypAA68YvF8PJTlWpNOf gjQ0V7VgQY0ma6svEF3JjueelZ047U++k6ditghiGA8DxAidvmHuk8EwaX8oWtBxR4xt KqbTlc+spzMz26vfkatAOCCPw/feUKdZHy6ZRGeU45Lf1TH2UarDLfM6njGkgOgEmxAG wwaayufX/rPvoJIgkO4eKM3wFmj9jAmEO0OggIoIGQOhxHmsBeLz+JCjYhaBa3iqdYWG QenA== X-Gm-Message-State: APjAAAU3UdHxpyvCtKr+fB9EoFPcK4CO7+0P/dXjgAHOhNDvW6eYEQQq mJwXYMAv+94VhWD4WFJ1DhjNgklsSjAF43rempE= X-Google-Smtp-Source: APXvYqx37neOVfDRYd7c4lZeLjPXTfY0JURdx93Su4AvMZ7ds17CZhbxDiMqF/3a90gOSNJCzpdGoOM/32tgWBsmDJk= X-Received: by 2002:a05:600c:2182:: with SMTP id e2mr6818049wme.55.1559466599097; Sun, 02 Jun 2019 02:09:59 -0700 (PDT) MIME-Version: 1.0 References: <CA+Yh0SQpFnsE2NZqbRjuzDyS-sQO_RTtTPBKth0F5EhnjNGtBQ@HIDDEN> <87muk1fn90.fsf@HIDDEN> <CA+Yh0STiV-61f2NkixpTmYE8co_ZmkaNgGePP56353eMfQoY2g@HIDDEN> <87v9xpfjhs.fsf@HIDDEN> In-Reply-To: <87v9xpfjhs.fsf@HIDDEN> From: Dmitrii Korobeinikov <dim1212k@HIDDEN> Date: Sun, 2 Jun 2019 15:09:47 +0600 Message-ID: <CA+Yh0SS=uwztoyBA0P=W_e6-CcKm+v_+zTfeCQU6pZSzKWUBOw@HIDDEN> Subject: Re: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) To: Ihor Radchenko <yantar92@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000adaa0d058a539c89" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 35419 Cc: Philipp Stephani <p.stephani2@HIDDEN>, 35419 <at> debbugs.gnu.org, Noam Postavsky <npostavs@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --000000000000adaa0d058a539c89 Content-Type: text/plain; charset="UTF-8" Dear Ihor, > Regarding the question about buffer-lens interaction. Let's take even > more complicated example: To run the command, the user hits some key > combination, which happens to be bound to different commands in the main > buffer and in the lense buffer (i.e. the main buffer is in org-mode, the > lense is in mingus-mode, and the key is C-d). What should be the > behaviour in such a case? run the commands in both the buffers? decide > depending on the point position? It is easy to make up similar > complicated examples if you consider some exotic major modes in the > lense buffer. It's basically a question of customization, a client-side decision. In other words, this really depends on what the user wants to happen. This customization is done through the controller of the lens. To your example. If the desirable behavior (for you, as a user) for C-d is to run in the lens, then add "C-d" to the controller of the lens. And then, whenever the point is in the area, C-d runs in the lens unconditionally. (For the sake of terminology, we can say that the keybinding is "redirected".) If you want C-d to work conditionally (sometimes do the org-mode thing and sometimes the mingus-mode thing), I am afraid there is nothing better than to update the controller yourself on the go. And that's fine, because that's what the user wants (to use the same bind for two different things in the same place at different times). (BTW, the controller could be asked to work "in reverse" and redirect all keybindings, except the ones in its black list.) But speaking of the larger picture and integration, a user can define a list of key combinations for any mode and the list will be added to the controller if the lens runs that mode. I think this should cover the vast majority of use-cases. Of course, there is no reason for the logic of key addition not to be flexible enough to cover anything more exotic. > I think that it would be more effective if someone decide on some basic > approach for the low-level implementation of the lense-mode (which > probably involves modifying emacs C-level source code) and continue the > discussion according to the benefits/limitations of that kind of > implementation. I too look forward to hearing from someone about the low-level implementation possibilities :) I especially hope the approach for the border-case issue (as described in my previous message) can work. Best regards, Dmitrii. --000000000000adaa0d058a539c89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Dear Ihor,<br>=C2=A0 =C2=A0<br>> Regarding the question= about buffer-lens interaction. Let's take even<br>> more complicate= d example: =C2=A0To run the command, the user hits some key<br>> combina= tion, which happens to be bound to different commands in the main<br>> b= uffer and in the lense buffer (i.e. the main buffer is in org-mode, the<br>= > lense is in mingus-mode, and the key is C-d). What should be the<br>&g= t; behaviour in such a case? run the commands in both the buffers? decide<b= r>> depending on the point position? It is easy to make up similar<br>&g= t; complicated examples if you consider some exotic major modes in the<br>&= gt; lense buffer.<br><br>It's basically a question of customization, a = client-side decision.<br>In other words, this really depends on what the us= er wants to happen.<br><br>This customization is done through the controlle= r of the lens.<br><br>To your example.<br>If the desirable behavior=C2=A0(f= or you, as a user)=C2=A0for C-d is to run in the lens, then add "C-d&q= uot; to the controller of the lens.<br>And then, whenever the point is in t= he area, C-d runs in the lens unconditionally.<br>(For the sake of terminol= ogy, we can say that the keybinding is "redirected".)<br><br>If y= ou want C-d to work conditionally (sometimes do the org-mode thing and some= times the mingus-mode thing), I am afraid there is nothing better than to u= pdate the controller yourself on the go.<br>And that's fine, because th= at's what the user wants (to use the same bind for two different things= in the same place at different times).<br><br>(BTW, the controller could b= e asked to work "in reverse" and redirect all keybindings, except= the ones in its black list.)<br><br>But speaking of the larger picture and= integration, a user can define a list of key combinations for any mode and= the list will be added to the controller if the lens runs that mode.<br>I = think this should cover the vast majority of use-cases.<br>Of course, there= is no reason for the logic of key addition not to be flexible enough to co= ver anything more exotic.<br><br>> I think that it would be more effecti= ve if someone decide on some basic<br>> approach for the low-level imple= mentation of the lense-mode (which<br>> probably involves modifying emac= s C-level source code) and continue the<br>> discussion according to the= benefits/limitations of that kind of<br>> implementation.<br><br>I too = look forward to hearing from someone about the low-level implementation pos= sibilities :)<br>I especially hope the approach for the border-case issue= =C2=A0(as described in my previous message)=C2=A0can work.<br><br>Best rega= rds,<br>Dmitrii.<br></div> --000000000000adaa0d058a539c89--
bug-gnu-emacs@HIDDEN, emacs-orgmode@HIDDEN:bug#35419; Package emacs,org-mode.
Full text available.Received: (at 35419) by debbugs.gnu.org; 1 Jun 2019 14:50:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 01 10:50:58 2019 Received: from localhost ([127.0.0.1]:38411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hX5LV-000255-Sd for submit <at> debbugs.gnu.org; Sat, 01 Jun 2019 10:50:58 -0400 Received: from mail-pf1-f178.google.com ([209.85.210.178]:35551) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1hX5LT-00024s-Sx for 35419 <at> debbugs.gnu.org; Sat, 01 Jun 2019 10:50:56 -0400 Received: by mail-pf1-f178.google.com with SMTP id d126so8003577pfd.2 for <35419 <at> debbugs.gnu.org>; Sat, 01 Jun 2019 07:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=Yu7NMccY+7yY2QycIom3/PzjSUDujJ0JqQ+s3+3sKBM=; b=vYgzQJp6bKlp/rWoBjWgwnYRqLoW+moxfR4OYqDS3VFdpGnL+pMuaWr4VUAuseiAZH dHou+91d7e3YoETpaIVHw/5kJTDG8kC3bWh3bOPKDj7hyL4WFe+qCpufiaXpO28r4mb1 f/nqjXjvoPTbR7eUnoIhgzQrQxhd2MgmV1LAKGehj0B5UHG1z0dCzrZB/3tqgOuDowQK mTY4UhTCyPyimMNlPHxaI21rMMv/R0kdFYlyqTJX0ZP46V/u24zt4qVXfBPEaPHFsha0 XE/cYn29VGq0zf9nseXPQxLtFANqxnktIYpWmtjOLpUYJAiUnQdZFdEyuuLxGKfGY4C2 L7KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=Yu7NMccY+7yY2QycIom3/PzjSUDujJ0JqQ+s3+3sKBM=; b=lAF915+t5IxPYtl4tHU7rF+p/mkSgKlrjWM4ATwDm56ZfdwFMLiXKSMEmVYZW688Xu MlXOrpwNMx3qJ9TAFPnaphuEcsy9tP87Dszurh2LZTyoILiyDCvQBcGF26zT1UFnmhgH RCABHwqwkOePfX/hEtbb/sSpujNQvr8l78Is3XxXgzvzbaOZmavItJM/K3RqUxLElSt6 4712zPQF2UPHNqSm5kWQXsGdtavbOhJhwLTHw9B0pKXqEcWSTQaM95eWKaqZwpWHCQ+R c0PKEroI4NVEbUH+M9GRkmTWOqCz9aeNVkGE/mF5IcieIK0t94us+ekEYbYldj3ed7US iNbw== X-Gm-Message-State: APjAAAWRfmaldkwvAbwljlQKhtA3FrRFLLXxAVR9LULGIjfPnRb0uPBB KailtXJTZDJzLK3ZZiuicUg= X-Google-Smtp-Source: APXvYqzzE+tyaH95GTB0IMYeSvAu7pJ3alKL2Hv7yKpHZiPhfFFdMcGCYhoInay5Ho4G92FSDmXWfg== X-Received: by 2002:a65:6284:: with SMTP id f4mr3028671pgv.14.1559400649786; Sat, 01 Jun 2019 07:50:49 -0700 (PDT) Received: from localhost ([2409:8a70:ff2c:bb80:f0f5:854b:57ac:24ef]) by smtp.gmail.com with ESMTPSA id f186sm11074664pfb.5.2019.06.01.07.50.47 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sat, 01 Jun 2019 07:50:48 -0700 (PDT) From: Ihor Radchenko <yantar92@HIDDEN> To: Dmitrii Korobeinikov <dim1212k@HIDDEN> Subject: Re: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) In-Reply-To: <CA+Yh0STiV-61f2NkixpTmYE8co_ZmkaNgGePP56353eMfQoY2g@HIDDEN> References: <CA+Yh0SQpFnsE2NZqbRjuzDyS-sQO_RTtTPBKth0F5EhnjNGtBQ@HIDDEN> <87muk1fn90.fsf@HIDDEN> <CA+Yh0STiV-61f2NkixpTmYE8co_ZmkaNgGePP56353eMfQoY2g@HIDDEN> Date: Sat, 01 Jun 2019 22:49:51 +0800 Message-ID: <87v9xpfjhs.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 35419 Cc: Philipp Stephani <p.stephani2@HIDDEN>, 35419 <at> debbugs.gnu.org, Noam Postavsky <npostavs@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.7 (/) Dear Dmitrii, Regarding the question about buffer-lens interaction. Let's take even more complicated example: To run the command, the user hits some key combination, which happens to be bound to different commands in the main buffer and in the lense buffer (i.e. the main buffer is in org-mode, the lense is in mingus-mode, and the key is C-d). What should be the behaviour in such a case? run the commands in both the buffers? decide depending on the point position? It is easy to make up similar complicated examples if you consider some exotic major modes in the lense buffer. I think that it would be more effective if someone decide on some basic approach for the low-level implementation of the lense-mode (which probably involves modifying emacs C-level source code) and continue the discussion according to the benefits/limitations of that kind of implementation. Best, Ihor Dmitrii Korobeinikov <dim1212k@HIDDEN> writes: > Dear Ihor, > >> Note that indirect buffers always share *all* the contents with the master >> buffer. As a result, it may not be easy to make things like flyspell >> work on code blocks in org-mode, if these code blocks are treated as >> lenses. > > I tried flyspell w/ different dictionaries on 2 buffers. > The dictionary is switched every time I switch into one of the buffers. > You are right, ispell and the like working w/ a file directly would have to > learn to work w/ indirect buffers by managing multiple simultaneous > processes. > Fortunately, that doesn't seem like a big hurdle. > >>> (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. >> >> There is no duplication of the buffer content in indirect buffers. >> Internally, indirect buffer's content is a pointer to the main buffer >> content. If you modify text in any of the indirect buffers or in the >> main buffer, the text is modified in all of them and in the main buffer. >> Only the buffer-local variables are duplicated. >> You can refer to "27.11 Indirect Buffers" in the elisp manual for >> details. > > Bad choice of wording on my side, I didn't mean duplication, but rather > keeping unnecessary info, like text properties in the newly created > indirect buffer, in the regions which were "permanently" chosen to be > narrowed-out. > Anyway, this is a premature optimization for now. > >> > 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? >> >> These issues have been discussed in >> https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00863.html. >> As I remember, the discussion stopped without a clear conclusion. It was >> not clear how to separate the main buffer contents from the nested >> buffer (I treat them as analogue of the buffer lenses). Another issue >> was how the keymaps and buffer-local variables would interact when the >> point is within a lense. It was not clear what should be the priority. > > The short answer is probably that lens-mode looks at the changes to the > buffer and decides what's what. > Here is my vision for this. > > Say, you have an indirect buffer, call it A, it's base has contents: > >> line 1 >> line 2 >> line 3 > > Also, there is a buffer, call it B, where we want to embed A, with contents: > >> word 1 >> instruction: lens that displays A >> word 2 > > Lens-mode decides to identify the second line as a lens and constructs > layout of the file. > >> [text] >> [lens#A] >> [text] > > Now, construct and display the final buffer as: > >> word 1 >> line 1 >> line 2 >> line 3 >> word 2 > > The core question: how is this "displaying" done. > In part, somewhat like how indirect buffers function. > A displayed piece of text is a pointer/reference to the text in the > indirect buffer. > Of course, this should be done in a way so that the modes running in B > don't change the properties of the text (following the layout constructed > by lens-mode as in the example above). Though, this might better&easier be > done at the display unit level. > > What about interaction? > Well, when the cursor is inside the lens, the controller decides what to do > w/ each keybinding, whether to redirect it to the indirect buffer or not. > And what about the case when borders are crossed? > As I see it, any code that executes - does so as is. > For instance, consider a buffer with a lens (contents: "lens"), which looks > like this: "word1 lens word2". > Place the cursor on the first word, run a command to remove 2 words. > Now there are to possibilities here, depending on the implementation of the > function which does the removal: > 1. Implementation identifies the boundaries of deletion and removes the > words as contents of the main buffer. Lens-mode identifies the removal and > deletes the lens altogether. > 2. Delete "word1" -> the cursor is on "lens" -> next deletion command is > redirected to the indirect buffer, which does the removal. Lens-mode > identifies the lens as empty and removes it. > > The second way might not be always desirable, so whenever a function is > called with the cursor outside a lens, as an option, decide to never > redirect the input to a lens while the function runs. > > For another case, consider the first example with lines and, cursor being > in the beginning of the file, remove three lines. > To make this interesting, assume the first kind of implementation runs, > identifying the bounds, never redirecting a command to the lens. > Well, if the implementation of the lens is inspired by how indirect buffers > work, I imagine, the necessary changes in the embedded buffer take place > directly, in which case everything works as desirable. > > Afterwards, lens-mode processes the changes and decides if some lens was > removed or added, updating the file layout. > > Best regards, > Dmitrii.
bug-gnu-emacs@HIDDEN, emacs-orgmode@HIDDEN:bug#35419; Package emacs,org-mode.
Full text available.Received: (at 35419) by debbugs.gnu.org; 14 May 2019 17:43:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 14 13:43:14 2019 Received: from localhost ([127.0.0.1]:49767 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hQbSL-0000Xk-BT for submit <at> debbugs.gnu.org; Tue, 14 May 2019 13:43:13 -0400 Received: from mail-wm1-f46.google.com ([209.85.128.46]:54553) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dim1212k@HIDDEN>) id 1hQbSJ-0000XU-7f for 35419 <at> debbugs.gnu.org; Tue, 14 May 2019 13:43:12 -0400 Received: by mail-wm1-f46.google.com with SMTP id i3so3751979wml.4 for <35419 <at> debbugs.gnu.org>; Tue, 14 May 2019 10:43:11 -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; bh=wJknWIETo/Xfhl2j3U1a/M0fgAUVrl0BF6Km6D2pLik=; b=pmhZ+9yNQrih2ZdT2M5D4N9fX01aVKmQjzlXWhk4JZDa3fWzeFm22LJoA57w0VIDnx ZHjcliBZHeU0UtXYZwDBKIw+6eOZ9KU3XOSknIlN/UQcBF2VPSihNzRNSEOZYOJ+AxWN kpCQkZvVo+lep0BUQ6WTquTmmrqu1DJWWJGic/91LAdKGkBJmymYEQ3chOeL1xr2LpVg Grjp16f8azGP9A+MHBbgbQy4wZMaBJA+wIbPZJLa4+OYnXrBzxVcP+tXnNAQfW0QT4vC 4jYvY1imAGGt4Y6Yg/iFEzkYBAgjKkNSUfZdqvFbwqyIzt56S0ZNzRH8hZjpGczN+T1y AOXw== 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; bh=wJknWIETo/Xfhl2j3U1a/M0fgAUVrl0BF6Km6D2pLik=; b=ruWxvLkg9y6BhrjfhYrhM3i4IG5KW6JgIZrMYbFTWsnS9bvpS8VhrgHSZ02/R8ALaQ xHFf3OWsob9bL2BCenqwEeioBiSjOL47eOlIYUfzCXGrkVZxvkYzxxbyuvgoNZrjC7RI mtURArdgHWO9Fjuf59fwHLvep5X0fYpN1Ey/uCICPXvvNrmwlxBPMYb8IAau5dGlSKsO q7i/4oB80Oym6Log6JKCb+I379+6Ka2MCbgViu4/uNMoiz2WDRaIBNrB/+T2grM1lTuA lwDnBzbyjszF83yiZeCTMh3Z3TQ4JdvR/HPzsPJP8Yrfi4Ka9kXQyqMkm6ea17AftmaX l4aw== X-Gm-Message-State: APjAAAVIFwbsQob1v+FlnpofuyB5ict0KcRDerYHny76GuPPniO8JHBV fX5r/kGV4Kmr3qCsJO8hGCokCamLlSm5QNUODjA= X-Google-Smtp-Source: APXvYqxdORSwk3O9CbNN2xFicKDtZ0oXgc91wWgc5pVRS4jX8GQY9kWUaK4KjZKzFzDQ93MM+yQDbt2p1KeOsYCCRLY= X-Received: by 2002:a1c:9951:: with SMTP id b78mr10662014wme.96.1557855785404; Tue, 14 May 2019 10:43:05 -0700 (PDT) MIME-Version: 1.0 References: <CA+Yh0SQpFnsE2NZqbRjuzDyS-sQO_RTtTPBKth0F5EhnjNGtBQ@HIDDEN> <87muk1fn90.fsf@HIDDEN> In-Reply-To: <87muk1fn90.fsf@HIDDEN> From: Dmitrii Korobeinikov <dim1212k@HIDDEN> Date: Tue, 14 May 2019 23:42:53 +0600 Message-ID: <CA+Yh0STiV-61f2NkixpTmYE8co_ZmkaNgGePP56353eMfQoY2g@HIDDEN> Subject: Re: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) To: Ihor Radchenko <yantar92@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000b3501f0588dc90dc" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 35419 Cc: Philipp Stephani <p.stephani2@HIDDEN>, 35419 <at> debbugs.gnu.org, Noam Postavsky <npostavs@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --000000000000b3501f0588dc90dc Content-Type: text/plain; charset="UTF-8" Dear Ihor, > Note that indirect buffers always share *all* the contents with the master > buffer. As a result, it may not be easy to make things like flyspell > work on code blocks in org-mode, if these code blocks are treated as > lenses. I tried flyspell w/ different dictionaries on 2 buffers. The dictionary is switched every time I switch into one of the buffers. You are right, ispell and the like working w/ a file directly would have to learn to work w/ indirect buffers by managing multiple simultaneous processes. Fortunately, that doesn't seem like a big hurdle. >> (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. > > There is no duplication of the buffer content in indirect buffers. > Internally, indirect buffer's content is a pointer to the main buffer > content. If you modify text in any of the indirect buffers or in the > main buffer, the text is modified in all of them and in the main buffer. > Only the buffer-local variables are duplicated. > You can refer to "27.11 Indirect Buffers" in the elisp manual for > details. Bad choice of wording on my side, I didn't mean duplication, but rather keeping unnecessary info, like text properties in the newly created indirect buffer, in the regions which were "permanently" chosen to be narrowed-out. Anyway, this is a premature optimization for now. > > 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? > > These issues have been discussed in > https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00863.html. > As I remember, the discussion stopped without a clear conclusion. It was > not clear how to separate the main buffer contents from the nested > buffer (I treat them as analogue of the buffer lenses). Another issue > was how the keymaps and buffer-local variables would interact when the > point is within a lense. It was not clear what should be the priority. The short answer is probably that lens-mode looks at the changes to the buffer and decides what's what. Here is my vision for this. Say, you have an indirect buffer, call it A, it's base has contents: > line 1 > line 2 > line 3 Also, there is a buffer, call it B, where we want to embed A, with contents: > word 1 > instruction: lens that displays A > word 2 Lens-mode decides to identify the second line as a lens and constructs layout of the file. > [text] > [lens#A] > [text] Now, construct and display the final buffer as: > word 1 > line 1 > line 2 > line 3 > word 2 The core question: how is this "displaying" done. In part, somewhat like how indirect buffers function. A displayed piece of text is a pointer/reference to the text in the indirect buffer. Of course, this should be done in a way so that the modes running in B don't change the properties of the text (following the layout constructed by lens-mode as in the example above). Though, this might better&easier be done at the display unit level. What about interaction? Well, when the cursor is inside the lens, the controller decides what to do w/ each keybinding, whether to redirect it to the indirect buffer or not. And what about the case when borders are crossed? As I see it, any code that executes - does so as is. For instance, consider a buffer with a lens (contents: "lens"), which looks like this: "word1 lens word2". Place the cursor on the first word, run a command to remove 2 words. Now there are to possibilities here, depending on the implementation of the function which does the removal: 1. Implementation identifies the boundaries of deletion and removes the words as contents of the main buffer. Lens-mode identifies the removal and deletes the lens altogether. 2. Delete "word1" -> the cursor is on "lens" -> next deletion command is redirected to the indirect buffer, which does the removal. Lens-mode identifies the lens as empty and removes it. The second way might not be always desirable, so whenever a function is called with the cursor outside a lens, as an option, decide to never redirect the input to a lens while the function runs. For another case, consider the first example with lines and, cursor being in the beginning of the file, remove three lines. To make this interesting, assume the first kind of implementation runs, identifying the bounds, never redirecting a command to the lens. Well, if the implementation of the lens is inspired by how indirect buffers work, I imagine, the necessary changes in the embedded buffer take place directly, in which case everything works as desirable. Afterwards, lens-mode processes the changes and decides if some lens was removed or added, updating the file layout. Best regards, Dmitrii. --000000000000b3501f0588dc90dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div>Dear <span class=3D= "" id=3D":125.1" tabindex=3D"-1" style=3D"">Ihor</span>,</div><div><br></di= v><div>> Note that indirect buffers always share *all* the contents with= the master</div><div>> buffer. As a result, it may not be easy to make = things like <span class=3D"" id=3D":125.2" tabindex=3D"-1" style=3D"">flysp= ell</span></div><div>> work on code blocks in org-mode, if these code bl= ocks are treated as</div><div>> lenses.=C2=A0</div><div><br></div><div>I= tried <span class=3D"" id=3D":125.3" tabindex=3D"-1" style=3D"">flyspell</= span> w/ different dictionaries on 2 buffers.</div><div>The dictionary is s= witched every time I switch into one of the buffers.</div><div>You are righ= t, <span class=3D"" id=3D":125.4" tabindex=3D"-1" style=3D"">ispell</span> = and the like working w/ a file directly would have to learn to work w/ indi= rect buffers by managing multiple simultaneous processes.</div><div>Fortuna= tely, that doesn't seem like a big hurdle.</div><div><br></div><div>>= ;> (1) A question: when an indirect buffer is created and some region is= </div><div>>> narrowed to, is the rest of the buffer duplicated in me= mory somewhere? If</div><div>>> this is so, there could be a useful e= fficiency-related modification to</div><div>>> indirect buffers, whic= h would allow "hard-narrowing": not duplicating the</div><div>>= ;> rest of the base buffer.</div><div>>=C2=A0</div><div>> There is= no duplication of the buffer content in indirect buffers.</div><div>> I= nternally, indirect buffer's content is a pointer to the main buffer</d= iv><div>> content. If you modify text in any of the indirect buffers or = in the</div><div>> main buffer, the text is modified in all of them and = in the main buffer.</div><div>> Only the buffer-local variables are dupl= icated.</div><div>> You can refer to "27.11 Indirect Buffers" = in the <span class=3D"" id=3D":125.5" tabindex=3D"-1" style=3D"">elisp</spa= n> manual for</div><div>> details.=C2=A0</div><div><br></div><div>Bad ch= oice of wording on my side, I didn't mean duplication, but rather keepi= ng unnecessary info, like text properties in the newly created indirect buf= fer, in the regions which were "permanently" chosen to be narrowe= d-out.</div><div>Anyway, this is a premature optimization for now.</div><di= v><br></div><div>> > The next immediately outstanding question is:</d= iv><div>> > (2) how can "embedding" (of a buffer as a part = of another buffer as an</div><div>> > area) be done efficiently? This= could possibly be approached as two</div><div>> > problems: (i) disp= laying the area and (ii) interacting with it.</div><div>> > Any ideas= ?</div><div>></div><div>> These issues have been discussed in</div><d= iv>> <a href=3D"https://lists.gnu.org/archive/html/">https://lists.gnu.o= rg/archive/html/</a><span class=3D"" id=3D":125.6" tabindex=3D"-1" style=3D= "">emacs</span>-<span class=3D"" id=3D":125.7" tabindex=3D"-1" style=3D"">d= evel</span>/2018-07/msg00863.html.</div><div>> As I remember, the discus= sion stopped without a clear conclusion. It was</div><div>> not clear ho= w to separate the main buffer contents from the nested</div><div>> buffe= r (I treat them as analogue of the buffer lenses). Another issue</div><div>= > was how the <span class=3D"" id=3D":125.8" tabindex=3D"-1" style=3D"">= keymaps</span> and buffer-local variables would interact when the</div><div= >> point is within a <span class=3D"" id=3D":125.9" tabindex=3D"-1" styl= e=3D"">lense</span>. It was not clear what should be the priority.</div><di= v><br></div><div>The short answer is probably that lens-mode looks at the c= hanges to the buffer and decides what's what.</div><div>Here is my visi= on for this.</div><div><br></div><div>Say, you have an indirect buffer, cal= l it A, it's base has contents:</div><div><br></div><div>> line 1</d= iv><div>> line 2</div><div>> line 3</div><div><br></div><div>Also, th= ere is a buffer, call it B, where we want to embed A, with contents:</div><= div><br></div><div>> word 1</div><div>> instruction: lens that displa= ys A</div><div>> word 2</div><div><br></div><div>Lens-mode decides to id= entify the second line as a lens and constructs layout of the file.</div><d= iv><br></div><div>> [text]</div><div>> [lens#A]</div><div>> [text]= </div><div><br></div><div>Now, construct and display the final buffer as:</= div><div><br></div><div>> word 1</div><div>> line 1</div><div>> li= ne 2</div><div>> line 3</div><div>> word 2</div><div><br></div><div>T= he core question: how is this "displaying" done.</div><div>In par= t, somewhat like how indirect buffers function.</div><div>A displayed piece= of text is a pointer/reference to the text in the indirect buffer.</div><d= iv>Of course, this should be done in a way so that the modes running in B d= on't change the properties of the text (following the layout constructe= d by lens-mode as in the example above). Though, this might better&easi= er be done at the display unit level.</div><div><br></div><div>What about i= nteraction?</div><div>Well, when the cursor is inside the lens, the control= ler decides what to do w/ each <span class=3D"" id=3D":125.10" tabindex=3D"= -1" style=3D"">keybinding</span>, whether to redirect it to the indirect bu= ffer or not.</div><div>And what about the case when borders are crossed?</d= iv><div>As I see it, any code that executes - does so as is.</div><div>For = instance, consider a buffer with a lens (contents: "lens"), which= looks like this: "word1 lens word2".</div><div>Place the cursor = on the first word, run a command to remove 2 words.</div><div>Now there are= to possibilities here, depending on the implementation of the function whi= ch does the removal:</div><div>1. Implementation identifies the boundaries = of deletion and removes the words as contents of the main buffer. Lens-mode= identifies the removal and deletes the lens altogether.</div><div>2. Delet= e "word1" -> the cursor is on "lens" -> next dele= tion command is redirected to the indirect buffer, which does the removal. = Lens-mode identifies the lens as empty and removes it.</div><div><br></div>= <div>The second way might not be always desirable, so whenever a function i= s called with the cursor outside a lens, as an option, decide to never redi= rect the input to a lens while the function runs.</div><div><br></div><div>= For another case, consider the first example with lines and, cursor being i= n the beginning of the file, remove three lines.</div><div>To make this int= eresting, assume the first kind of implementation runs, identifying the bou= nds, never redirecting a command to the lens.</div><div>Well, if the implem= entation of the lens is inspired by how indirect buffers work, I imagine, t= he necessary changes in the embedded buffer take place directly, in which c= ase everything works as desirable.</div><div><br></div><div><span class=3D"= " id=3D":125.11" tabindex=3D"-1" style=3D"">Afterwards</span>, lens-mode pr= ocesses the changes and decides if some lens was removed or added, updating= the file layout.</div><div><br></div><div>Best regards,</div><div><span cl= ass=3D"" id=3D":125.12" tabindex=3D"-1" style=3D"">Dmitrii</span>.</div></d= iv></div></div> --000000000000b3501f0588dc90dc--
bug-gnu-emacs@HIDDEN, emacs-orgmode@HIDDEN:bug#35419; Package emacs,org-mode.
Full text available.Received: (at 35419) by debbugs.gnu.org; 5 May 2019 06:08:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 05 02:08:12 2019 Received: from localhost ([127.0.0.1]:52889 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hNAJn-0005pz-RK for submit <at> debbugs.gnu.org; Sun, 05 May 2019 02:08:12 -0400 Received: from mail-pl1-f179.google.com ([209.85.214.179]:45951) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1hNAJm-0005pl-2y for 35419 <at> debbugs.gnu.org; Sun, 05 May 2019 02:08:10 -0400 Received: by mail-pl1-f179.google.com with SMTP id o5so4717416pls.12 for <35419 <at> debbugs.gnu.org>; Sat, 04 May 2019 23:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=Y3dGwnfGZ8eYECgKdm6Yf2gfLBGparZ3zXmExkn3K88=; b=QoUjIYx4MZltVbyWs5+MBCoeCVbAKjRIUz+bQxn3w3dailHW05Tmx7VqNAbV6H0Are EzhpHrrJRItEwnK6EU7H/UHiQNUvNQK9iw7+L+ht2YgCWu+rQrm0vOO6MQkTPrDsXQMc DsZwAlSCz5yO8AARQLWkT5WEEtgQx7KVsj0MOjKptqqogYPHh2JmwnzgYq/AGo+R6CoW RNYk+cGHXUUwhWE7NGgOoFOgJ6mJwo9sz4PEaRQU4GiAo2g69KHAiLfKdss9E/oHhRY0 pCA/ksZw3WGDqqMs4YN8pxVvuLxnuxoW2/d0VzPDi02ww6ha/9YvAiDlgNqBjs5sT70C cEFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=Y3dGwnfGZ8eYECgKdm6Yf2gfLBGparZ3zXmExkn3K88=; b=DSLjGEwC8tW4vEKZh0Gr5OecrFJsTrpBRQGGmy1glQSdAgQb2nF/LTSX23Kc3ZNwUG pW+tPU7Ik3KhCoLuNotYK61oLSVdE0xMA9HbhZzOHhrtM0/a+Rqgpdx7Q9XkqsErgs0Z 6DGKyGTMAXO4GiCYat6oRhH7KdqxsEd0evCP5ntYoQ1dCVYueuFKw+xb2NHpJzHukNrW Y9hjWGACi2ttOnxS5d8fRgE2IY8Ze4RDrWAGyEmaan/ymZeiTbWlaNrxXxhvT8RRCykv aa5p3RD93FUueu73T56U2z2PT4SwKvWbZ7qcsalZi8O4RDp+n8l6YmqvFVElnrZPwBnD 7+DA== X-Gm-Message-State: APjAAAVlwYadusVLeZ/+f4NLVRUnWSRTOC8qb6+KPt7rYLMJIZQtR1Kn 9t36IN7qUlcZG/7KVYWu+dI= X-Google-Smtp-Source: APXvYqzPJxYw68qQVauOlyqml5kLxfyAKTo61kgcCXIf5N/RdoKWUb8xP4UhtmZsd9cbJLkR29+xWQ== X-Received: by 2002:a17:902:407:: with SMTP id 7mr23039574ple.62.1557036484229; Sat, 04 May 2019 23:08:04 -0700 (PDT) Received: from localhost ([45.41.180.82]) by smtp.gmail.com with ESMTPSA id m16sm10905184pfi.29.2019.05.04.23.08.01 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sat, 04 May 2019 23:08:03 -0700 (PDT) From: Ihor Radchenko <yantar92@HIDDEN> To: Dmitrii Korobeinikov <dim1212k@HIDDEN>, 35419 <at> debbugs.gnu.org Subject: Re: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) In-Reply-To: <CA+Yh0SQpFnsE2NZqbRjuzDyS-sQO_RTtTPBKth0F5EhnjNGtBQ@HIDDEN> References: <CA+Yh0SQpFnsE2NZqbRjuzDyS-sQO_RTtTPBKth0F5EhnjNGtBQ@HIDDEN> Date: Sun, 05 May 2019 14:07:07 +0800 Message-ID: <87muk1fn90.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 35419 Cc: Philipp Stephani <p.stephani2@HIDDEN>, Noam Postavsky <npostavs@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.7 (/) Dear Dmitrii, > Indirect buffers give the answer to the issue of sharing some textual data > between several buffer. Note that indirect buffers always share *all* the contents with the master buffer. As a result, it may not be easy to make things like flyspell work on code blocks in org-mode, if these code blocks are treated as lenses. > (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. There is no duplication of the buffer content in indirect buffers. Internally, indirect buffer's content is a pointer to the main buffer content. If you modify text in any of the indirect buffers or in the main buffer, the text is modified in all of them and in the main buffer. Only the buffer-local variables are duplicated. You can refer to "27.11 Indirect Buffers" in the elisp manual for details. > 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? These issues have been discussed in https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00863.html. As I remember, the discussion stopped without a clear conclusion. It was not clear how to separate the main buffer contents from the nested buffer (I treat them as analogue of the buffer lenses). Another issue was how the keymaps and buffer-local variables would interact when the point is within a lense. It was not clear what should be the priority. Best, Ihor Dmitrii Korobeinikov <dim1212k@HIDDEN> writes: > 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? -- Ihor Radchenko,
bug-gnu-emacs@HIDDEN, emacs-orgmode@HIDDEN:bug#35419; Package emacs,org-mode.
Full text available.Received: (at 35419) by debbugs.gnu.org; 3 May 2019 12:07:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 03 08:07:16 2019 Received: from localhost ([127.0.0.1]:47923 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hMWyC-0004WS-Gp for submit <at> debbugs.gnu.org; Fri, 03 May 2019 08:07:16 -0400 Received: from mail-wm1-f50.google.com ([209.85.128.50]:39443) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dim1212k@HIDDEN>) id 1hMWyB-0004WE-AW for 35419 <at> debbugs.gnu.org; Fri, 03 May 2019 08:07:15 -0400 Received: by mail-wm1-f50.google.com with SMTP id n25so6437205wmk.4 for <35419 <at> debbugs.gnu.org>; Fri, 03 May 2019 05:07:15 -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; bh=V1eQ8wk4JcQyDPtxCfXSa9Ht241k728uCcQu/QUfdMA=; b=eex++rljZkDAWOZECesN1BEp80MlL+2yoBhIANPwOU68/8+d29IU3RewjeyllFFbx9 l/I1rsj17tFKJeh7ToNtPKILqrePfh9iI55gd6t1Qz/Flife35Wfwjj5F1hdqoeoktCg qH1pQkq4Dw317/tY+T9x9MIIPxYeY2auphAp58iSIPcegUoZpXArwzXm6eJxI0v3vVGd GWbYu1LQKJxuHcRjEBhePipIzoLhQ8V/u1abAbRL4fjkD9V1+vmfovi7cjEFPJenRrsy WvKMlcxWS5O0uykakuwRVS2MoV0EQAoqTgN0KPfPLVEviZqzzRca2mavehtzUXv92SCC 4D0A== 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; bh=V1eQ8wk4JcQyDPtxCfXSa9Ht241k728uCcQu/QUfdMA=; b=mdqktRB0natrT16PxFa/zW/THCT3jthV3fQXxYkijc/bzUjg0F6TI8xuvRvpG13kvf S6W94/nYCdxuRUIt1BwGHS+tVKKLiHx34nbkWkl/ks79E06Nkifj8VcDNGPmZ0+7r1c9 zHlOxMK5IkV2/MH8QDRc/bjcmyS7U0Bll5Vz2DtPkakQiI2GquQWTTaJ2uBGEMkplE6L KptnhejiJTYNFSaFoN0ETfSNPtFbx9U5Zsc2YfkLZRKdN7p2Hg7hgzsDklQp12M8M5TR LMldCfpQDzOxPb3WW4m6o+NXzM/thrCfOvYIP0zS6i3khRB17A6Pc0nJAMK7pZNIDiEj kIPQ== X-Gm-Message-State: APjAAAVsRyfJMOnb8VOJ9i5COia4aEDOd6v2ilcpqpRASeOKpWvGrz0x 5hhfjEgDf0xaXK/rqX4P2jhdhVB86ciawVMwfD8= X-Google-Smtp-Source: APXvYqz2DqS/oulB9nqK67P3jCUWXRpsbGC5ICcUdZwvVMFH3cvlwWLjhpI5rdwbslkG4zbqyQXNgcqCth1icbRqzEM= X-Received: by 2002:a1c:1c3:: with SMTP id 186mr5831352wmb.77.1556885229514; Fri, 03 May 2019 05:07:09 -0700 (PDT) MIME-Version: 1.0 References: <CA+Yh0STecZHv_dxGEMOuy9F7X_dnxbCfNX5KnekwfZW_hQXYsg@HIDDEN> <87lfzn4x61.fsf@HIDDEN> In-Reply-To: <87lfzn4x61.fsf@HIDDEN> From: Dmitrii Korobeinikov <dim1212k@HIDDEN> Date: Fri, 3 May 2019 18:06:57 +0600 Message-ID: <CA+Yh0SQAD3ut0-opoBP8aUfhJEapSRhn8Y3YdOV_1cEtMLxqVQ@HIDDEN> Subject: Re: [O] bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) To: Roland Everaert <reveatwork@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000000fbe740587fa97c4" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 35419 Cc: 35419 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --0000000000000fbe740587fa97c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Understood, thank you! =D0=BF=D1=82, 3 =D0=BC=D0=B0=D1=8F 2019 =D0=B3. =D0=B2 17:03, Roland Everae= rt <reveatwork@HIDDEN>: > For what I understand of eev (which I discover following this thread), > the idea is to create "notebooks" (=C3=A0 la Jupyter) of commands that ca= n be > executed in > any orders the user want. So, lenses could be useful to apply the > correct mode the block of code at point. > > Dmitrii Korobeinikov writes: > > >> 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? > > > -- > Luke, use the FOSS > > Sent from Emacs > --0000000000000fbe740587fa97c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Understood, thank you!</div><br><div class=3D"gmail_quote"= ><div dir=3D"ltr" class=3D"gmail_attr">=D0=BF=D1=82, 3 =D0=BC=D0=B0=D1=8F 2= 019 =D0=B3. =D0=B2 17:03, Roland Everaert <<a href=3D"mailto:reveatwork@= gmail.com">reveatwork@HIDDEN</a>>:<br></div><blockquote class=3D"gmai= l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20= 4,204);padding-left:1ex">For what I understand of eev (which I discover fol= lowing this thread),<br> the idea is to create "notebooks" (=C3=A0 la Jupyter) of commands= that can be executed in<br> any orders the user want. So, lenses could be useful to apply the<br> correct mode the block of code at point.<br> <br> Dmitrii Korobeinikov writes:<br> <br> >> I see lens to be useful for the eev mode, too.<br> ><br> > Never heard of eev, but judging by some demos, it's a way to execu= te elisp<br> > commands interactively.<br> > Something like stitching blocks of commands together, or the data to<b= r> > operate on, or embedding a target such as a shell in the same buffer i= s the<br> > use-case idea then?<br> <br> <br> -- <br> Luke, use the FOSS<br> <br> Sent from Emacs<br> </blockquote></div> --0000000000000fbe740587fa97c4--
bug-gnu-emacs@HIDDEN, emacs-orgmode@HIDDEN:bug#35419; Package emacs,org-mode.
Full text available.Received: (at 35419) by debbugs.gnu.org; 3 May 2019 11:04:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 03 07:04:05 2019 Received: from localhost ([127.0.0.1]:47836 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hMVz2-0000qd-R5 for submit <at> debbugs.gnu.org; Fri, 03 May 2019 07:04:05 -0400 Received: from mail-wm1-f46.google.com ([209.85.128.46]:40286) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <reveatwork@HIDDEN>) id 1hMVz0-0000q7-DB for 35419 <at> debbugs.gnu.org; Fri, 03 May 2019 07:04:02 -0400 Received: by mail-wm1-f46.google.com with SMTP id h11so6218791wmb.5 for <35419 <at> debbugs.gnu.org>; Fri, 03 May 2019 04:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version:content-transfer-encoding; bh=BR7LgE21XFZkJjSG4W/YnlWzYSy+jRjypzLQ4ReZMJA=; b=ZkoUGGfAHIqlmu5F7rFjhyCx94k/5YmhrplToJKzBXRBPz5hWBl7Gznf4ZX34r6BWR 4331JLjikMWLz08bBGjO7MvEVqbLy8K15a4ctW0wP827wj3K/Pgh6FYY7UoArWXTxFZX p9SUrTjjVhnyv/rWiS2n2uTEw0zDIcWr1E9Ag1AryigCV21/rqolvarW8LrToI8x3iA8 H+vBd6ZQeQmbYy+EVxEb/w5wIV84p3K0f9H56iedfxgfzdy+lwqCTj1rj0hDh86Gueqf HGPacBFipEE3CA1a0Ng30+QH9UNFLgcStEIaKBmSLNskD0abAQzLcya4k8wt2BryrW// K9Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version:content-transfer-encoding; bh=BR7LgE21XFZkJjSG4W/YnlWzYSy+jRjypzLQ4ReZMJA=; b=tQzXQxPLwsGg+4WoKFh5dngbyw3RCTK2HyC0TDuVj9bCFuxkuA3wtP7iRw9nUWQokw uySUVr1mRXeSnzCNhKozpWx/l9c7/x8ZtdrHCZp3DegWpLH7j1CD4vLBuxa+2iOV9Uzh B2c8/jIExOlZKMTgBK+hlX/Znew46SaVwzDhQBPtsSaUTKgrdyIvRtx6cS0191Fwg+53 1zjrrxuNVaPpAqFCSOP3z9u33KkIptUIScIuVcu/KWHJhLw9E7pfmS4yz1PmDQyPJINp E4HTlDKk5l1TBNE/LIf6xVmkyLk5McZuhAdPOkaEMXp+6JpQkyfzOdmvOaeSi38kajQF hHlA== X-Gm-Message-State: APjAAAXAoG96HeGvzri+t4LEqq81+hAlZtdSrVH4uRmMIlwowapH4Qja QbWQ8xMnZT4JGWwAARupuv9t9FBp X-Google-Smtp-Source: APXvYqzhsnTRQNm+nEVjtkK2GHUtmeCqzraPoa2Tjns7oRkDcRT9L9unlEWx6tFpEiynomOGP3O6FQ== X-Received: by 2002:a1c:4905:: with SMTP id w5mr6071049wma.88.1556881436381; Fri, 03 May 2019 04:03:56 -0700 (PDT) Received: from tanko ([85.91.180.112]) by smtp.gmail.com with ESMTPSA id k206sm3682670wmk.16.2019.05.03.04.03.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 03 May 2019 04:03:55 -0700 (PDT) References: <CA+Yh0STecZHv_dxGEMOuy9F7X_dnxbCfNX5KnekwfZW_hQXYsg@HIDDEN> User-agent: mu4e 1.2.0; emacs 26.1 From: Roland Everaert <reveatwork@HIDDEN> To: Dmitrii Korobeinikov <dim1212k@HIDDEN> Subject: Re: [O] bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) In-reply-to: <CA+Yh0STecZHv_dxGEMOuy9F7X_dnxbCfNX5KnekwfZW_hQXYsg@HIDDEN> Date: Fri, 03 May 2019 13:03:50 +0200 Message-ID: <87lfzn4x61.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 35419 Cc: 35419 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) For what I understand of eev (which I discover following this thread), the idea is to create "notebooks" (=C3=A0 la Jupyter) of commands that can = be executed in any orders the user want. So, lenses could be useful to apply the correct mode the block of code at point. Dmitrii Korobeinikov writes: >> 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 t= he > use-case idea then? --=20 Luke, use the FOSS Sent from Emacs
bug-gnu-emacs@HIDDEN, emacs-orgmode@HIDDEN:bug#35419; Package emacs,org-mode.
Full text available.Received: (at 35419) by debbugs.gnu.org; 2 May 2019 21:31:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 02 17:31:28 2019 Received: from localhost ([127.0.0.1]:47170 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hMJId-0000i4-RV for submit <at> debbugs.gnu.org; Thu, 02 May 2019 17:31:28 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:44719) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dim1212k@HIDDEN>) id 1hMJIb-0000hq-ES for 35419 <at> debbugs.gnu.org; Thu, 02 May 2019 17:31:26 -0400 Received: by mail-wr1-f41.google.com with SMTP id c5so5296985wrs.11 for <35419 <at> debbugs.gnu.org>; Thu, 02 May 2019 14:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=5KA8+/5QM2lMDmbixp2ulF9q14GyoakVDF3/KAILhe8=; b=ei2l+srvNKMInC//XbkUN+KyKXAKxuVoPxZjFShgh4PAwyfMYcFG6hdFbk9Ik3bFtx owCYsCAK4xSgURcs04LOE1+/vet6efVmRU1d+isUPiMutXHa7TJHfqZiv5wCSkRrOpWv jc455mGY0CmBItn7Bhu77TaSl324bF+ndCnJc38yjfw92cPMztMxQ0zXD5bnMQb3Nlj5 FceLo9j/H7QV+jrRXORxDArKXghx9H5bGV9W3sDeWHJbYFBO+udvOqLhc1+o4b3vmHKH 6Dokxp3ZWcN6BITIBruq8sX2+zgl3GzodoOgKqPdbGZF2UnapTz+9VErYGQ8f5rdAwe4 4/iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=5KA8+/5QM2lMDmbixp2ulF9q14GyoakVDF3/KAILhe8=; b=ZowCCFc/FOHryFjjc6VSw2/k9fbCcR3yo6uw/v75BzrvXj3dgjdnXmNAGZ12iPjpPD 4FLoQvOlwKqAzF6SjWf7SOZ6sNpKvVEcEeXggguNCB8cktpSd7qZUtfQ7t07CdxAa8Y4 JoReSCB+uxUljY/x4qVxzPqzu7O8N+YvRUIE0/ZfIh9NGYJXlXz5CiHpVi8avyVQyeDl wI65AOKorJg6a4xLm6v33ppYIm10qa7lVdvX/rSgc3kWCC0kj207nd6XRVA86yBzOqoJ PlLzMkCga3nrZScVQUirS5EOaID9u4BgsftEhN/W+CMR7/135TJPN/taVqilhHkfgRmq c6mQ== X-Gm-Message-State: APjAAAUgE6BmRvElFExmquzTq0rFeb1fgDyKWvFZp/wkWmepJY8nRnPU ITooSj8JpeUm4xqarTUpgwofZVshay4Cz7ZIDfz+ddlk X-Google-Smtp-Source: APXvYqy6683benp/Sy41G0h1eqYEDBrt/8NRekvSHI2bG0E5bEOxKPlz/4hKrPW/rC8N4wh/hvGHInbCIb3YFNP6wWU= X-Received: by 2002:a5d:4ccb:: with SMTP id c11mr4099842wrt.295.1556832679371; Thu, 02 May 2019 14:31:19 -0700 (PDT) MIME-Version: 1.0 From: Dmitrii Korobeinikov <dim1212k@HIDDEN> Date: Fri, 3 May 2019 03:31:08 +0600 Message-ID: <CA+Yh0SQpFnsE2NZqbRjuzDyS-sQO_RTtTPBKth0F5EhnjNGtBQ@HIDDEN> Subject: Re: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) To: 35419 <at> debbugs.gnu.org, Ihor Radchenko <yantar92@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000d425750587ee5a78" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 35419 Cc: Philipp Stephani <p.stephani2@HIDDEN>, Noam Postavsky <npostavs@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --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 <div dir=3D"ltr"><div dir=3D"ltr"><div>I found a clarification on how mmm-m= ode works.</div><div><br></div><div><a href=3D"https://github.com/polymode/= polymode/issues/187">https://github.com/polymode/polymode/issues/187</a></d= iv><div>> 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.</div><div><br></div><div>= Just to reiterate, polymode's idea is to switch between indirect buffer= s, one for each major mode.</div><div><br></div><div>OK, detail largely dis= regarded, I now can draw a bird-eye view comparison between lenses and mult= i-mode modes.</div><div><br></div><div>- Neither polymode nor mmm-mode trea= t a region as if it were truly on its own in a seperate buffer.</div><div><= br></div><div>Effects: no stuff like seperate truncation options, implied s= yntax checking and so on.</div><div><br></div><div>- Moreover, the region m= ust be a part of the buffer.</div><div><br></div><div>Effects: no data shar= ing between buffers, no possibility of stitching different buffers together= , etc.</div><div><br></div><div>Now, with these out of the way.</div><div><= br></div><div>Indirect buffers give the answer to the issue of sharing some= textual data between several buffer.</div><div>(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.</di= v><div><br></div><div>The next immediately outstanding question is:=C2=A0</= div><div>(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.</di= v><div>Any ideas?</div></div></div> --000000000000d425750587ee5a78--
bug-gnu-emacs@HIDDEN, emacs-orgmode@HIDDEN:bug#35419; Package emacs,org-mode.
Full text available.Received: (at 35419) by debbugs.gnu.org; 2 May 2019 21:24:27 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 02 17:24:26 2019 Received: from localhost ([127.0.0.1]:47159 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hMJBq-0000Wt-Mr for submit <at> debbugs.gnu.org; Thu, 02 May 2019 17:24:26 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:40107) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dim1212k@HIDDEN>) id 1hMJBp-0000Wf-2F for 35419 <at> debbugs.gnu.org; Thu, 02 May 2019 17:24:25 -0400 Received: by mail-wr1-f41.google.com with SMTP id h4so5292653wre.7 for <35419 <at> debbugs.gnu.org>; Thu, 02 May 2019 14:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=drivAiO6+VSGOozHOSyzpnW0jfSuVGXr/9gEwec5z8o=; b=p9wizZca94q2b4DdUI/gNeMPLryPCTNBNe2eQjGy3rY21WVtbMUjEPMXjMxprcitSB +5x9qGlwR5RNCiR8C1qvq0nm6gAZz5lWph245B7welevL2b5vshraYlyfk/DQacsrqRN SIuo1YSzxVR2ILwRqm577JsSEQrUuOqu+bYQ0zby9WHkoM0fWIVtihOkAk0NVYu5Y4qc 6+6dSFDOjcwq4ok3QxUkIPgL0dkz5mIObKV0Lg1hLFAdeolTnEFVG7lm+q07AChXh/S/ C5L9hNCf5rEAEI1b34uh3CKKA/H5QL+qlrL9TIh5lzo2pyA5g0TaQtcA97b2lBLzCNaL CDeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=drivAiO6+VSGOozHOSyzpnW0jfSuVGXr/9gEwec5z8o=; b=bsqkEG2fJvE+K/FSJ2+pHvSBtxmZXhA6BNOaN4eMt/ftARcv4rVbDQF1Y3+8qRMsxh SwD9NBgbi/5kEeYXLMPAjYeqXNeH5ZYxq506WZv1yLlWVIasqa5ZVRwJBM/2wAjlNuUe DTkQTIyyogW77OFhqCyDrV/5xuf8XT5mg+++lZ9sXoxmd/Yk76xUkXGl2ptpvDWZ9r2+ 66Ki/4A8if0Wo3Oel9YB9LzCkOOYZ14cNhrcclgLXczUMhV01hEU5gCmrDDFOYy6a0Yx cziQSUCRlU0muX7E2bpJd+RnpiF2GK4izNJ+AJehcSDFsF9kV7DEArcGpkvNuQe/y0f7 yVXQ== X-Gm-Message-State: APjAAAXoMdd7kVgnu/NPiPDYNsb75TR1UB/hbxnt+ixSMtvoBJUG/0eR bUu5+UCxRa2vIgpf/31VCuiuIg5JGaKqfJdOJjT9Br98 X-Google-Smtp-Source: APXvYqwAcetqHUh3PkeVWgdcRCJ/TbYW1PCLPU/femCcUGAaX8abhzvZhtYdz1RViXztqvE5DeIW5k4noZQbIlv7vzo= X-Received: by 2002:a5d:4ccb:: with SMTP id c11mr4083678wrt.295.1556832259130; Thu, 02 May 2019 14:24:19 -0700 (PDT) MIME-Version: 1.0 From: Dmitrii Korobeinikov <dim1212k@HIDDEN> Date: Fri, 3 May 2019 03:24:08 +0600 Message-ID: <CA+Yh0STecZHv_dxGEMOuy9F7X_dnxbCfNX5KnekwfZW_hQXYsg@HIDDEN> Subject: Re: [O] bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) To: 35419 <at> debbugs.gnu.org, reveatwork@HIDDEN Content-Type: multipart/alternative; boundary="000000000000c7c92d0587ee41da" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 35419 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --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 <div dir=3D"ltr"><div dir=3D"ltr"><div>>=C2=A0<span style=3D"background-= color:rgb(254,254,254);color:rgb(0,0,0);white-space:pre-wrap">I see lens to= be useful for the eev mode, too.</span></div><div><br></div><div>Never hea= rd of eev, but judging by some demos, it's a way to execute elisp comma= nds interactively.</div><div>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?</div></div></div> --000000000000c7c92d0587ee41da--
bug-gnu-emacs@HIDDEN, emacs-orgmode@HIDDEN:bug#35419; Package emacs,org-mode.
Full text available.Received: (at 35419) by debbugs.gnu.org; 26 Apr 2019 14:32:11 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 26 10:32:11 2019 Received: from localhost ([127.0.0.1]:33339 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hK1ta-0005zH-MC for submit <at> debbugs.gnu.org; Fri, 26 Apr 2019 10:32:11 -0400 Received: from mail-wm1-f51.google.com ([209.85.128.51]:35241) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <reveatwork@HIDDEN>) id 1hJzbQ-00025r-9F for 35419 <at> debbugs.gnu.org; Fri, 26 Apr 2019 08:05:16 -0400 Received: by mail-wm1-f51.google.com with SMTP id y197so4080574wmd.0 for <35419 <at> debbugs.gnu.org>; Fri, 26 Apr 2019 05:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version:content-transfer-encoding; bh=dY4OQlwC8QSchy5HjJQrYpB/TEv5tR8N5NdlPu+pqTY=; b=S8znrufFzepBi+8dmpD0SBAoC98a+Bx2A0UUzkKLiHK2GXNH4Y1HQMpM55+t7BIT1J QJghMGzVyVu5buQg77A9tmDEJJYS9tfs3e5o68urwn2hj4QdO7UW4iEp2QBfz6h+DMGo H+5l0imT4h70peEsZ/exGfYQOGCkqvNraXhS0jNxHnRWW5UPMA47NZxxSRwDhFdpxpsO LJ0Sv5lhSaEzoRwAw+UYel4C6nGmUSKDCFQFq6Q8RrSl8HWUsAkdinlzPmpxUg4PX1oP tE8nw5Ct6yV8dTnYQ2keUcoH/v8DgdRvQDM304Y50wBfrPUaZ/52b8JROMzDtb8Sew01 6vyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version:content-transfer-encoding; bh=dY4OQlwC8QSchy5HjJQrYpB/TEv5tR8N5NdlPu+pqTY=; b=A5rALZoL2Gzp1YCSvuMGnFPTtB2j+tZssEVzokeO8dJehDgE7EU3DkHaWz15MLL79o 3mLBmY0XmnbQktMnDYSs/aG/EHLZiCK5hGELP9r8adauPBrxK8Of4rAewM6lZkfNA7/a elJmWi/NeESLWfE2x84a82JIL5uehGfatyZAN2AUToQ3qKYO8tVq6w+ML9EcejcuMCSR pWXDLX0QDeppb/xFJ+Jm2ZB1c/br0qnulCyF+ALLAcGaJuIku9nmfuXOJJM7GukfT27T P+7RE98DmPxRMiG2j/AagYhd0d6bnxZA++K0BG1XHD1hilSW4LtWAXmtmYMch6GW9eDm Bomg== X-Gm-Message-State: APjAAAUppSRzFkuooxou3rWdEAsSUKiQ84JT6bXoeAwaOV7BpT6AGsbt 4m6e82Pzmkc/wLVcROWQrsn5tpjD X-Google-Smtp-Source: APXvYqySBwlNghIz2GnEsmO3oKaNp9GYCztZujnIJCACdyBVRqpez/hYbY6t4R5Q8u3F6ZmjjLBU6A== X-Received: by 2002:a1c:55c3:: with SMTP id j186mr7019893wmb.127.1556280310374; Fri, 26 Apr 2019 05:05:10 -0700 (PDT) Received: from tanko ([85.91.180.112]) by smtp.gmail.com with ESMTPSA id u189sm32303683wme.25.2019.04.26.05.05.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 26 Apr 2019 05:05:09 -0700 (PDT) References: <CA+Yh0SQ7yWQBjXhKbJPrCroriNpwhyFyQWAfHsUvxwmojsjKuw@HIDDEN> <87sgu6rhkt.fsf@HIDDEN> <CA+Yh0SSvQMucaC1EJR9GBxpKeP6haGiHN+Lf2QYo8csNoy0Waw@HIDDEN> User-agent: mu4e 1.2.0; emacs 26.1 From: Roland Everaert <reveatwork@HIDDEN> To: emacs-orgmode@HIDDEN Subject: Re: [O] bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) In-reply-to: <CA+Yh0SSvQMucaC1EJR9GBxpKeP6haGiHN+Lf2QYo8csNoy0Waw@HIDDEN> Date: Fri, 26 Apr 2019 14:05:03 +0200 Message-ID: <877ebhnf9s.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 35419 X-Mailman-Approved-At: Fri, 26 Apr 2019 10:32:10 -0400 Cc: Noam Postavsky <npostavs@HIDDEN>, 35419 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) 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 <npostavs@HIDDEN>: > >> Dmitrii Korobeinikov <dim1212k@HIDDEN> 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
bug-gnu-emacs@HIDDEN, emacs-orgmode@HIDDEN:bug#35419; Package emacs,org-mode.
Full text available.Received: (at 35419) by debbugs.gnu.org; 25 Apr 2019 21:14:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 25 17:14:52 2019 Received: from localhost ([127.0.0.1]:59474 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hJlhk-0008GX-Hg for submit <at> debbugs.gnu.org; Thu, 25 Apr 2019 17:14:52 -0400 Received: from mail-wm1-f46.google.com ([209.85.128.46]:36442) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dim1212k@HIDDEN>) id 1hJlhi-0008GI-CW for 35419 <at> debbugs.gnu.org; Thu, 25 Apr 2019 17:14:50 -0400 Received: by mail-wm1-f46.google.com with SMTP id h18so1231433wml.1 for <35419 <at> debbugs.gnu.org>; Thu, 25 Apr 2019 14:14:50 -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; bh=+89dsKPl9PbU76GyYH/p1fr0uvqYBe3teqqW7gbHyr0=; b=vWfouVOAonZNoLORcYXEC18JInQrjKmqLcy6cvYdiqLDQC8f1IyhAugdjl8ue/aNBw Z9Iaum/uxzAkAsgaORmYV4xzptbZFnhyZXnomL1QP0u4rdTWh0E2nZlnTlqeNn4gMgBV xk902lr1FsUd4EdDwtRw41SadqNWgcn1hSEsxCt9/u5tjQaEKaSWDqEj2kv6AvARVre5 tOlKQ3iAW1g3UkDLsErsIDDzbpOjlrYrJaa+BFGuLTgpyrvaJYabvJn5kB6paXK7FMhs heM4RtFBMcXvVkcYPHJ2UM3hb6g/SHog2WTwwrrn5+n7k5IV5axcsCZTcsd99A6Et/h4 dKhg== 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; bh=+89dsKPl9PbU76GyYH/p1fr0uvqYBe3teqqW7gbHyr0=; b=TwKMfSQpfdQwfUnP/6JOPKRoawYwZEoBVMZ+ZPWev577Q5TpE2LOJ7yG7POCLQF1W7 kLCJDCDeViAZG4RcDbmKaii4NXYtkhdRgrsxu7MTeBaYX0iI1jLErGAcdTZco8Q7j1iK upFk1UfZFLcioEjFVZDjahx9Kpj2qa3N8XvN0qtbgNC5X0kA89YHSLxHiY73fiY6YXr8 QFYHzx6pH8dg8Oo1GEJ3Tqw4UN0mZLvr2U0/7I9tJFtni4xdhUPw3wfmC3/hy1KlN+ja qANmJAZ63512lMsV6BVY+6ethNClaTBY+fAgZ0eoN5WrOPrfBgCvWcHNS/LKL6IdGBW6 Be8w== X-Gm-Message-State: APjAAAVlizJjj7Y5A5d6QitjC/7xekGBqBy1ydkORmL9AWffGHPXBp/A JJqEQLWY0tGlbS7uA4eY7e9BvdHkESU04R979T8= X-Google-Smtp-Source: APXvYqzyaSl3cySlE3CSY8mvUM3bx6B/B4JbNHBHQOgtJyR89P2IbcDqKoHRRqwt9c0/PRmYQ801opgEcmgKyDbVtuM= X-Received: by 2002:a1c:f910:: with SMTP id x16mr4995909wmh.114.1556226884605; Thu, 25 Apr 2019 14:14:44 -0700 (PDT) MIME-Version: 1.0 References: <CA+Yh0SQ7yWQBjXhKbJPrCroriNpwhyFyQWAfHsUvxwmojsjKuw@HIDDEN> <87sgu6rhkt.fsf@HIDDEN> <CA+Yh0SSvQMucaC1EJR9GBxpKeP6haGiHN+Lf2QYo8csNoy0Waw@HIDDEN> <CAArVCkQcwnjeMyRU6rpiuvGsOCUOsnQTQwQSGdDFKwQz_Sbi3g@HIDDEN> In-Reply-To: <CAArVCkQcwnjeMyRU6rpiuvGsOCUOsnQTQwQSGdDFKwQz_Sbi3g@HIDDEN> From: Dmitrii Korobeinikov <dim1212k@HIDDEN> Date: Fri, 26 Apr 2019 03:14:33 +0600 Message-ID: <CA+Yh0SR60mhZYGsVeiYJYdaG21W6SVPGwK9y_NnSgTciTJ6ZNQ@HIDDEN> Subject: Re: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) To: Philipp Stephani <p.stephani2@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000a59a960587614eb9" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 35419 Cc: Noam Postavsky <npostavs@HIDDEN>, 35419 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --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 <p.stephani2@HIDDEN>: > Am Do., 25. Apr. 2019 um 10:41 Uhr schrieb Dmitrii Korobeinikov > <dim1212k@HIDDEN>: > > 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 <div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div>=D1=87=D1=82, 25 = =D0=B0=D0=BF=D1=80. 2019 =D0=B3. =D0=B2 23:52, Philipp Stephani <<a href= =3D"mailto:p.stephani2@HIDDEN">p.stephani2@HIDDEN</a>>:<br></div><= /div></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty= le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi= ng-left:1ex">Am Do., 25. Apr. 2019 um 10:41 Uhr schrieb Dmitrii Korobeiniko= v<br> <<a href=3D"mailto:dim1212k@HIDDEN" target=3D"_blank">dim1212k@gmail.= com</a>>:<br> > 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.<br> <br> That's what indirect buffers do. Maybe the indirect buffer<br> functionality could be beefed up to support what you want?<br></blockquote>= <div><br></div><div><a href=3D"https://www.gnu.org/software/emacs/manual/ht= ml_node/emacs/Indirect-Buffers.html">https://www.gnu.org/software/emacs/man= ual/html_node/emacs/Indirect-Buffers.html</a><br></div><div>> 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.</div><div><br></div><div>Awesome! Looks like we have some s= olid rails to drive on.</div><div><br></div><div>BTW what's the purpose= of lentic-mode then? To be "providing multiple persistent views"= ?</div><div><a href=3D"https://github.com/phillord/lentic">https://github.c= om/phillord/lentic</a>=C2=A0</div></div></div> --000000000000a59a960587614eb9--
bug-gnu-emacs@HIDDEN, emacs-orgmode@HIDDEN:bug#35419; Package emacs,org-mode.
Full text available.Received: (at 35419) by debbugs.gnu.org; 25 Apr 2019 21:00:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 25 17:00:35 2019 Received: from localhost ([127.0.0.1]:59459 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hJlTu-0007wy-B2 for submit <at> debbugs.gnu.org; Thu, 25 Apr 2019 17:00:35 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:34123) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dim1212k@HIDDEN>) id 1hJlTr-0007we-LY for 35419 <at> debbugs.gnu.org; Thu, 25 Apr 2019 17:00:32 -0400 Received: by mail-wr1-f68.google.com with SMTP id c6so1318365wrm.1 for <35419 <at> debbugs.gnu.org>; Thu, 25 Apr 2019 14:00:31 -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; bh=jFQ2xdWpA9Banxr7zjaj5jyVmUkXBho2HziSlw35aYs=; b=UKhTppIXmydn5iqQodyzftfj1d1hbv7iZzi5NaXdor9APNFETMVInkDIB9DdXy3EWk WT2UdUSIbZt3esenMkzfRMWdT07OKQxYmvaFfVhrk3t8M31Zh5eERYpjZ6a7+H/M8c3f 1qEJn4vRfDLLfECTYESeW1awruuBepQcZcR9CLYttebz8uSnm4TCv5DW+cy5xlawswvO b6KGu8Tx6t5CBzOsPs9OaOfXwLnxAOSIHB90qix62QHbJBTIOpWZrtu3b4ZRAs3ukmDP LFRfDBs8IsEE/eXNFCYNwx+p9HaDMPQM6ck6DaM72LarvDgqV9v6owiSho9WRNwV8IJN Zw4Q== 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; bh=jFQ2xdWpA9Banxr7zjaj5jyVmUkXBho2HziSlw35aYs=; b=n/YmUGbtg1z4HUnAMypHlKS58GEC13s3FgHMLSMoksKJMNHAgysEGJ07GfAnas/cok NnAwc7I/cczNyiB8T+V3c9csKy08KshcnQZUnSX0qLv5f055Q1vXBnr0n66xJr71DcrU DqbVm8AC7wdBgno3+7uZfH8AH3NJtEpJJ4MLDkazytTSADPJ/Nvo/QvfFseKozC/rjRs gTryPem+UbJdKWWXTLHEJ80ONE/6v2GBvkdw8m8nvpx8FKcTI3PdnIkkKoXmQgQqawNr eVwmggRqSZa0FldsdcyTSApoM9Dt0Xd3aZwu9T+IkbM4vmxNGWynz0Fm2Nk/ZcAICV5e jEBA== X-Gm-Message-State: APjAAAVYSZBZ5vnuEBOvYDw1ZSj+8fE2TAJZwAL1fCseQ/m6i+rgpVXE PjPZrzWvnpX6DMKHmYTvxy7R6vPYzNCxnYnmddk= X-Google-Smtp-Source: APXvYqyk6je2ZF00sYqhqp4m+BQdn44064VOKN2Vkw2gEKUy0nSK2B7/aD6OUWDkZ69gRhiuyB6ZQZ4YDOiyZcrn+i8= X-Received: by 2002:a5d:550b:: with SMTP id b11mr12692708wrv.81.1556226024676; Thu, 25 Apr 2019 14:00:24 -0700 (PDT) MIME-Version: 1.0 References: <CA+Yh0SQcwxm8fbDrB7eGTDU2KMRKhNkgSddSufwXvzvY=8zciA@HIDDEN> <87v9z2ojf8.fsf@HIDDEN> In-Reply-To: <87v9z2ojf8.fsf@HIDDEN> From: Dmitrii Korobeinikov <dim1212k@HIDDEN> Date: Fri, 26 Apr 2019 03:00:12 +0600 Message-ID: <CA+Yh0ST+u0s6L-hR2=rs3O_46FqXn8utGotORx+FMDb7Jn0Rfw@HIDDEN> Subject: Re: [O] [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) To: Ihor Radchenko <yantar92@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000006420f00587611b81" X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 35419 Cc: 35419 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.2 (-) --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 <div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div>Dear Ihor,</div><di= v><br></div><div>> Another use case for me is to speed up agenda creatio= n.</div><div>> I usually do not like to split my org files into too many= . However, it</div><div>> results in very large and slow org buffers lat= er. If I can store some</div><div>> parts of the org files externally an= d only show them if some condition</div><div>> is met (say, for certain = todo state of the parent entry), it would speed</div><div>> up my agenda= and the buffer navigation quite significantly.</div><div><br></div><div>Th= at's a good one!</div><div><br></div><div>> Let me put some historic= al context to this proposal.</div><div>> There was a discussion of simil= ar feature in emacs-dev last year.</div><div>> The idea was to implement= nested buffers:</div><div>> <a href=3D"https://lists.gnu.org/archive/ht= ml/emacs-devel/2018-07/msg00863.html">https://lists.gnu.org/archive/html/em= acs-devel/2018-07/msg00863.html</a>=C2=A0</div><div><br></div><div>An inter= esting read, provides another use-case (collect external data in one place = to easily view/edit):</div><div><a href=3D"https://lists.gnu.org/archive/ht= ml/emacs-devel/2018-07/msg00890.html">https://lists.gnu.org/archive/html/em= acs-devel/2018-07/msg00890.html</a></div><div><br></div><div>> There are= also several projects, which implement part of the</div><div>> function= ality you described:</div><div>> - mmm-mode: <a href=3D"https://github.c= om/purcell/mmm-mode">https://github.com/purcell/mmm-mode</a></div><div>>= - polymode: <a href=3D"https://github.com/polymode/polymode">https://githu= b.com/polymode/polymode</a></div><div><br></div><div>Pretty cool stuff. For= thoroughness, let's discuss how these work.</div><div><br></div><div>I= found a comment which mentions polymode's working principle.</div><div= ><a href=3D"https://www.reddit.com/r/emacs/comments/50p34n/polymode_is_awes= ome/?depth=3D1">https://www.reddit.com/r/emacs/comments/50p34n/polymode_is_= awesome/?depth=3D1</a></div><div>>> 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><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).</div><div><br></div><div>Basically, simpli= city is in place but at the cost of duplication.</div><div>Lenses could avo= id duplication, while yielding increased functionality and speed.</div><div= >(e.g. in polymode, a syntax checker couldn't yield correct results unl= ess narrowing was constantly used, which is inefficient)</div><div><br></di= v><div>Now, to MMM-mode. According to the info file:</div><div><br></div><d= iv>> Within the file, MMM-mode creates /submode regions/ within which ot= her major modes are in effect.</div><div><br></div><div>> While the poin= t is in a submode region, the following changes occur:</div><div>> <.= ..> keymap <...> local variables <...> syntax table and inde= ntation <...> font-lock</div><div><br></div><div>> The submode reg= ions are represented internally by Emacs Lisp objects known as /overlays/.<= /div><div><br></div><div>> A lot of the functionality of MMM Mode---that= which makes the major mode</div><div>> appear to change---is implemente= d by saving and restoring the values of</div><div>> local variables, or = pseudo-variables.</div><div><br></div><div>What I don't understand is w= here the modes of the submode region run and when they are turned on.</div>= <div>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?</div><div>Could, for example, syntax checking be don= e efficiently that way?</div><div>Could someone, please, explain?</div><div= ><br></div><div>Best regards,</div><div>Dmitrii.</div></div></div></div> --0000000000006420f00587611b81--
bug-gnu-emacs@HIDDEN, emacs-orgmode@HIDDEN:bug#35419; Package emacs,org-mode.
Full text available.Received: (at 35419) by debbugs.gnu.org; 25 Apr 2019 17:52:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 25 13:52:39 2019 Received: from localhost ([127.0.0.1]:59277 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hJiY3-0001Os-GJ for submit <at> debbugs.gnu.org; Thu, 25 Apr 2019 13:52:39 -0400 Received: from mail-oi1-f180.google.com ([209.85.167.180]:45316) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <p.stephani2@HIDDEN>) id 1hJiY2-0001Og-BD for 35419 <at> debbugs.gnu.org; Thu, 25 Apr 2019 13:52:38 -0400 Received: by mail-oi1-f180.google.com with SMTP id y84so727635oia.12 for <35419 <at> debbugs.gnu.org>; Thu, 25 Apr 2019 10:52:38 -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; bh=amZkr1b0DHWzqhBOPCKvRGzG9WXxwLA6XA5CJzIIdpY=; b=m2O5xnA0IT5IyNyytoVMXFJD29B/z5IB0EA71Ggq7XqT6JXxO6KV1+T50njJeD873h bw7+bCFXA5Qofxj1MzKpMUTrn7+BhhUi2qe/dnIJwtmit1IXL/87+wsP7fJ9zCmDtWBp ohc/n/m0Wx66jiXd1JQbIZjfsn/VrUXSfsFYJq309TMt8SScpd8xSsEH9U/MjAS6zh6O ZZ3p9EiomtRsa2r4N8Jse7Tsjx60R4/QIlxphaR+Y/ZDGp0wrLDyebzAPShboAlGIABq +d6FY3zSAMiixN2jF4C77fofKYE9Ic6y84v/KJqVmlJgCM/nzzgu14lKTiqWZ+GCjQwT E5bA== 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; bh=amZkr1b0DHWzqhBOPCKvRGzG9WXxwLA6XA5CJzIIdpY=; b=eumQ1YT9tb35P1F0RF5IuHvTLFK8Tef1cLN1r/wXhrLhpqXjCcavCywuQh/OoN9alL dkdyMBV+lzcVQ34cJqYdbNm2CPE2wU2+Xuq9wxVorov7cVmAx7gOcyKduidVYUr4Zysu vlI0iK5oift/5YKeso6OsZr6eZTrWuDsRLzYGuHQk6J3M6ZXz6HMxG9opkIYPzjRICqP azfoe53XMEI2kLdcBwDQa3WfbJlUpvrLZIo3TILfcZimISjj0eT/pnm0rpVGwLezvV0q WBlj36MPHW/YiNlPcTg+vSh9eZ75otY6uqSYCCudNsLMYTbS4yhpVtHUHCjKsLNYkpRW z1Fg== X-Gm-Message-State: APjAAAULWImN6EnhN+kQyw1tlLlho0V1H+M4oH+fFvWurjs6YKpxa7Qy 0XWDPNrZdwKvCC3mRRuLMoGy8RNPoC3shfN5PbY= X-Google-Smtp-Source: APXvYqzZ4FQusGpht/txu/uT2yy+rc1p5CHd1PrejgCZZWT6zZDlowQlheyaCkbZYgOxuOqfnah+EFd/+GgM5uvDbrQ= X-Received: by 2002:aca:b3c2:: with SMTP id c185mr4335390oif.98.1556214751016; Thu, 25 Apr 2019 10:52:31 -0700 (PDT) MIME-Version: 1.0 References: <CA+Yh0SQ7yWQBjXhKbJPrCroriNpwhyFyQWAfHsUvxwmojsjKuw@HIDDEN> <87sgu6rhkt.fsf@HIDDEN> <CA+Yh0SSvQMucaC1EJR9GBxpKeP6haGiHN+Lf2QYo8csNoy0Waw@HIDDEN> In-Reply-To: <CA+Yh0SSvQMucaC1EJR9GBxpKeP6haGiHN+Lf2QYo8csNoy0Waw@HIDDEN> From: Philipp Stephani <p.stephani2@HIDDEN> Date: Thu, 25 Apr 2019 19:52:34 +0200 Message-ID: <CAArVCkQcwnjeMyRU6rpiuvGsOCUOsnQTQwQSGdDFKwQz_Sbi3g@HIDDEN> Subject: Re: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) To: Dmitrii Korobeinikov <dim1212k@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 35419 Cc: Noam Postavsky <npostavs@HIDDEN>, 35419 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.8 (/) Am Do., 25. Apr. 2019 um 10:41 Uhr schrieb Dmitrii Korobeinikov <dim1212k@HIDDEN>: > 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?
bug-gnu-emacs@HIDDEN, emacs-orgmode@HIDDEN:bug#35419; Package emacs,org-mode.
Full text available.Received: (at 35419) by debbugs.gnu.org; 25 Apr 2019 14:24:33 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 25 10:24:33 2019 Received: from localhost ([127.0.0.1]:59072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hJfIe-0004gI-Un for submit <at> debbugs.gnu.org; Thu, 25 Apr 2019 10:24:33 -0400 Received: from mail-pg1-f170.google.com ([209.85.215.170]:45456) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1hJbQP-0004jh-Ju for 35419 <at> debbugs.gnu.org; Thu, 25 Apr 2019 06:16:18 -0400 Received: by mail-pg1-f170.google.com with SMTP id y3so10952389pgk.12 for <35419 <at> debbugs.gnu.org>; Thu, 25 Apr 2019 03:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=resent-to:resent-from:resent-date:resent-message-id:from:to:subject :references:date:message-id:mime-version; bh=dOeMOXC0gCi5/T9uPXxMZIXUQvRG7ETcrVQ1Tw+EErU=; b=IytniqdbIklV2carXvxbxzB+r8Kv0pkPAv9Y5FyeeelOuuGkBvTVYcJrh8vioFmM3V sD0HJKEkEYd7qo6oXVgQeCKh3OcIHFIX0ic+zPQE2Sv3Bug0PS0iorai5Z1uYn2ySbp7 mYJaexDGGCmhTMCvMQG60qY0n59u1a/gO5dhToFcgpqL7vBdGLbtz9k/5Bfd9jW8pYVA 7AuKWkZoTLIDakC2qZaMeUZJ4iSPSt4a2/UcA9wl4GRO7ExJ21wiyew0NpfQRTX7qicT tRWwcl9xyyI/wC2RjFWSXqT7e3ViFr/nyzycCgXalJCBICAE4m32THsMywiPS3rDFjJ0 hufw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:resent-to:resent-from:resent-date :resent-message-id:from:to:subject:references:date:message-id :mime-version; bh=dOeMOXC0gCi5/T9uPXxMZIXUQvRG7ETcrVQ1Tw+EErU=; b=EaJYWI1S3R7atHvnHT/hd/xYc8nqkRT4cbUuGutN162CfkmiE4bsDAPiveCGSH/8Mq ZK2+8SeNk26vLKplzHXe0Ni0VObu3CK1z8wYf11egqW5GzPa7wSfLYRsBSLZAgd3Jywv Drfte/A3J1YthvfNbX1wze4exfn2Uj9SYg/PiopZCWD0OkiLh/GAe2yK8XRC5jE1QUxF VgBJWvUwGP/DOTgTgG1EkV73IzZixF8HSFfFpr16hIWDoXKDbcLt4NPiP0hf9SZaXXpB EKQFqpWXVOpB/sgJCe6yPIn+QiTj9Dzhjqbi7KaP+qDK9ZVcqcqZRieB6/qC6pd6siwm vAxg== X-Gm-Message-State: APjAAAVmEKKfQhzAl2kElsMJ6/JeTHLbgdqrdB/fsg3SdQOHY6XbWCCt ++Vu8whxS9r0rkM6zd4fOMrtn1UzdVBOzg== X-Google-Smtp-Source: APXvYqzpg2FdGC/oCqDKAxvYoA1FpRNT40dc1VT0wZA2XKplEr2FfoXOjTNRjEJudiEd0ekwzUX0fw== X-Received: by 2002:aa7:8282:: with SMTP id s2mr38995593pfm.7.1556187371316; Thu, 25 Apr 2019 03:16:11 -0700 (PDT) Received: from localhost ([45.56.183.45]) by smtp.gmail.com with ESMTPSA id a80sm44142448pfj.61.2019.04.25.03.16.09 for <35419 <at> debbugs.gnu.org> (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 25 Apr 2019 03:16:10 -0700 (PDT) Resent-To: 35419 <at> debbugs.gnu.org Resent-From: Ihor Radchenko <yantar92@HIDDEN> Resent-Date: Thu, 25 Apr 2019 18:15:13 +0800 Resent-Message-ID: <87mukel7bi.fsf@HIDDEN> From: 'Ihor Radchenko' <yantar92@HIDDEN> To: 35419 <at> debbugs.gnu.org Subject: Fwd: Re: [O] [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) References: <87v9z2ojf8.fsf@HIDDEN> Date: Thu, 25 Apr 2019 15:11:50 +0800 Message-ID: <87lfzyo8y1.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="===-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 35419 X-Mailman-Approved-At: Thu, 25 Apr 2019 10:24:32 -0400 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.8 (/) --===-=-= Content-Type: multipart/mixed; boundary="==-=-=" --==-=-= Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 8bit From: Ihor Radchenko <yantar92@HIDDEN> To: Dmitrii Korobeinikov <dim1212k@HIDDEN>, emacs-orgmode <emacs-orgmode@HIDDEN> Subject: Re: [O] [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) In-Reply-To: <CA+Yh0SQcwxm8fbDrB7eGTDU2KMRKhNkgSddSufwXvzvY=8zciA@HIDDEN> References: <CA+Yh0SQcwxm8fbDrB7eGTDU2KMRKhNkgSddSufwXvzvY=8zciA@HIDDEN> Date: Thu, 25 Apr 2019 11:25:31 +0800 Message-ID: <87v9z2ojf8.fsf@HIDDEN> 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 <dim1212k@HIDDEN> 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----- --===-=-=--
bug-gnu-emacs@HIDDEN, emacs-orgmode@HIDDEN:bug#35419; Package emacs,org-mode.
Full text available.Received: (at 35419) by debbugs.gnu.org; 25 Apr 2019 08:40:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 25 04:40:47 2019 Received: from localhost ([127.0.0.1]:57389 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hJZvz-0002U7-CO for submit <at> debbugs.gnu.org; Thu, 25 Apr 2019 04:40:47 -0400 Received: from mail-wr1-f42.google.com ([209.85.221.42]:35568) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dim1212k@HIDDEN>) id 1hJZvx-0002Tt-A5 for 35419 <at> debbugs.gnu.org; Thu, 25 Apr 2019 04:40:46 -0400 Received: by mail-wr1-f42.google.com with SMTP id f7so6498096wrs.2 for <35419 <at> debbugs.gnu.org>; Thu, 25 Apr 2019 01:40:45 -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; bh=Dw/H80LBbr+7p0rtr/9cXyN9qwSqgPoZtYKhlbmbTiQ=; b=Kd1VH7DoFTu9CUhmVOlkJDFToIuSPXfQhvB8m9R3Vtgdq6kY2NvvGKPvZHDT4J4+gj H49+ADd1b/RjXH6/jhP2luFTqztrmC1+mX6JrLLuoun2RUrhzttXwf9XKTfEQVxL4B9o H+Eqw80Z3+H/nDFHG6SqDnUcbMPCsFWVv6zm6+E93rXe2S4V8xpMVEgwYeagCnLA5hC+ eAv3Q7vAfGcJ4W/bVTQBMGD6kCpwg0v/1wauqYogmgoCWIi3wAKJGIAZyiG5326MMlIj iyFbgtFBkz+g7TGh8d1CW2k1hhNEY8IO3quvksrrAaWbBvmR+7X7Oo0sHC1JCQ5IeVhh +0Ow== 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; bh=Dw/H80LBbr+7p0rtr/9cXyN9qwSqgPoZtYKhlbmbTiQ=; b=Y2ai41dU9TgdPln6Oku3kkp8voN08bS7vJuzDlvEImGcSllu9j3b8klyxIluDcppk9 Iy1W51U0Z3FfJH1noJ/+BizIXXrgJNzh0Bt700n5QDhaBFqXWUVdhdJUhASi31z2pxad J9CUlFTJVCJ8U3RjYsJ+b/Ti56XYy1V3y3c6ktAX/QDqQnaYSriNtTzIhxwqtnhsnVwq MbOhc3UPr772fb7a8NlmMyZOHDeo7RZ2MhMN0KMUa6WH+9JuhiKv6zgHzRpFT74Y0hdp NicHKBOM0GKV6tejbdOyw3ljNMJcjv3h4xmDzDKPCO4a8yIKiN26rn/97WKkVv7ghCdU cEZQ== X-Gm-Message-State: APjAAAUjd32nhksRHQLvoZHCdNT5p98f/2CibhJGTxmZ7RPNkfRrFHGV IDgT9MDEtciaOdsWgjDFOqOXDeeC+WtmddvCQvo= X-Google-Smtp-Source: APXvYqy+/7gIHRRWJnKzSJOJZ0k6mmzDVlhQMCOh5UIb0zjvi73LUBWUAWHpkTDnwxozMNCMA57l4e54KaaF+lKFIWo= X-Received: by 2002:a5d:550b:: with SMTP id b11mr10044137wrv.81.1556181639437; Thu, 25 Apr 2019 01:40:39 -0700 (PDT) MIME-Version: 1.0 References: <CA+Yh0SQ7yWQBjXhKbJPrCroriNpwhyFyQWAfHsUvxwmojsjKuw@HIDDEN> <87sgu6rhkt.fsf@HIDDEN> In-Reply-To: <87sgu6rhkt.fsf@HIDDEN> From: Dmitrii Korobeinikov <dim1212k@HIDDEN> Date: Thu, 25 Apr 2019 14:40:27 +0600 Message-ID: <CA+Yh0SSvQMucaC1EJR9GBxpKeP6haGiHN+Lf2QYo8csNoy0Waw@HIDDEN> Subject: Re: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) To: Noam Postavsky <npostavs@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000d322c3058756c536" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 35419 Cc: 35419 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --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@HIDDEN>: > Dmitrii Korobeinikov <dim1212k@HIDDEN> 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@HIDDEN">npostavs@HIDDEN</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@HIDDEN" target=3D"_blank">dim1212k@HIDDEN</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--
bug-gnu-emacs@HIDDEN, emacs-orgmode@HIDDEN:bug#35419; Package emacs,org-mode.
Full text available.Received: (at 35419) by debbugs.gnu.org; 25 Apr 2019 01:37:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 24 21:37:18 2019 Received: from localhost ([127.0.0.1]:56952 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1hJTKA-0000oi-K7 for submit <at> debbugs.gnu.org; Wed, 24 Apr 2019 21:37:18 -0400 Received: from mail-qt1-f181.google.com ([209.85.160.181]:39217) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <npostavs@HIDDEN>) id 1hJTK8-0000oW-DR for 35419 <at> debbugs.gnu.org; Wed, 24 Apr 2019 21:37:16 -0400 Received: by mail-qt1-f181.google.com with SMTP id h16so12364630qtk.6 for <35419 <at> debbugs.gnu.org>; Wed, 24 Apr 2019 18:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=3nQY81HY1QID+wNCi7BirCmY8fQFMpnhoJBvAZwmq5Y=; b=qLNwXvive8Ma8TrkdyDGS9Zg14Sby6rGQXXWHHJcIT82YDi031wPoRWPCpj8slv8pq HGQ2B0IgrHNJHcDvV/Rb7cbzvUkJDtRqlQhIohnyDVhbah6s3L/fYuvkyuGHQjV6mIkp AX6GKLtY7P9ut9Nkd5DNFEtDuP4SsNKYxykDvjeL9Fmkn3W5dhcxXDKrj0d5+zxySwet fytst/zxP1gliNrFF7E/OeTkFsyw9v8JMyPD9K174/oIfaCfpaPMtKWYuO1J86gzkgpS Byjw70hq9Fd+zFtNXbhoduASJ+DCJvPdrUwQll5XPdl4SLt9U5p3B3ys6rBvvUqaJEn2 dB3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=3nQY81HY1QID+wNCi7BirCmY8fQFMpnhoJBvAZwmq5Y=; b=MXIsFUjIcEiciNRjkIy5mjIWxkZ6Ivlt9kHKKZYO1OUjk3aft04CwPMqWDLj31ymth s3Xi6bJt5lSFIYacp5WM/a8Fe8rsu0s4rxFW6rIc6QfDl444HtBU2euvmHg5ekZemcVk odEjX0Sq0Y7k932UWhA9I168YYWOz2mb0IvEd9sDwPvfStdyAnaxvswctvMYb6g2N0JK DZ5NQStHfBP10wr1WCny8lpT1ox5OJl9zsw+50OawM8Rq8PUewN8KrmQfxUJk1ALEbxL jAPvgh6WXJGGaOZUwbqrRPAIkkCzWboOCQymowBn8TZwahjFTt+UFY0M8XFp/M7yJ6LE CivQ== X-Gm-Message-State: APjAAAXQfeKcHHcVrcCsk9YLOOcKm+1O06yshn6oUacnHB51urasC2JK ha2sVtnoUgx3M4/NJDKkFTsUglkF X-Google-Smtp-Source: APXvYqzeXeDR63fUjjomSicf91768IKnwUOSWQZkIfRWlFYOZy3AsjrYkxN4zLAVd6ZyGV0xFuhqgA== X-Received: by 2002:aed:26c5:: with SMTP id q63mr22022525qtd.352.1556156228816; Wed, 24 Apr 2019 18:37:08 -0700 (PDT) Received: from minid (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.googlemail.com with ESMTPSA id i20sm10239749qkk.70.2019.04.24.18.37.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 24 Apr 2019 18:37:08 -0700 (PDT) From: Noam Postavsky <npostavs@HIDDEN> To: Dmitrii Korobeinikov <dim1212k@HIDDEN> Subject: Re: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) References: <CA+Yh0SQ7yWQBjXhKbJPrCroriNpwhyFyQWAfHsUvxwmojsjKuw@HIDDEN> Date: Wed, 24 Apr 2019 21:37:06 -0400 In-Reply-To: <CA+Yh0SQ7yWQBjXhKbJPrCroriNpwhyFyQWAfHsUvxwmojsjKuw@HIDDEN> (Dmitrii Korobeinikov's message of "Thu, 25 Apr 2019 00:35:16 +0600") Message-ID: <87sgu6rhkt.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 35419 Cc: 35419 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitrii Korobeinikov <dim1212k@HIDDEN> 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
bug-gnu-emacs@HIDDEN, emacs-orgmode@HIDDEN:bug#35419; Package emacs,org-mode.
Full text available.Glenn Morris <rgm@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Glenn Morris <rgm@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.
Received: (at submit) by debbugs.gnu.org; 24 Apr 2019 18:35:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 24 14:35:55 2019
Received: from localhost ([127.0.0.1]:56488 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1hJMkN-0003QJ-6r
for submit <at> debbugs.gnu.org; Wed, 24 Apr 2019 14:35:55 -0400
Received: from eggs.gnu.org ([209.51.188.92]:55920)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <dim1212k@HIDDEN>) id 1hJMkK-0003Q1-SP
for submit <at> debbugs.gnu.org; Wed, 24 Apr 2019 14:35:53 -0400
Received: from lists.gnu.org ([209.51.188.17]:32788)
by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
(Exim 4.71) (envelope-from <dim1212k@HIDDEN>) id 1hJMkF-0003nh-BL
for submit <at> debbugs.gnu.org; Wed, 24 Apr 2019 14:35:47 -0400
Received: from eggs.gnu.org ([209.51.188.92]:42068)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <dim1212k@HIDDEN>) id 1hJMk9-0005v4-1d
for bug-gnu-emacs@HIDDEN; Wed, 24 Apr 2019 14:35:47 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level:
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM,
HTML_MESSAGE,URIBL_BLOCKED autolearn=disabled version=3.3.2
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <dim1212k@HIDDEN>) id 1hJMk2-0003ao-JC
for bug-gnu-emacs@HIDDEN; Wed, 24 Apr 2019 14:35:41 -0400
Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]:36923)
by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
(Exim 4.71) (envelope-from <dim1212k@HIDDEN>) id 1hJMk1-0003YC-F4
for bug-gnu-emacs@HIDDEN; Wed, 24 Apr 2019 14:35:34 -0400
Received: by mail-wr1-x429.google.com with SMTP id t17so14813338wrr.4
for <bug-gnu-emacs@HIDDEN>; Wed, 24 Apr 2019 11:35:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=aHBkoXfNrn0aJEnzcjCOLqDrTyxit4vkhKYwulyoDEk=;
b=r1vDlqwkktkP9p+kcU1nPWAtvoQcbdMX0LEujYzQDOrmiWgH7HHyLqsJqYzYQhERZx
2T4IE/s7CILvm+JrXipDnoYsfNaTP6SW91sIEN/fR8Y68HOVVq5cb1/x/8dkl5K3pU8N
VknVcvZzMTUq97QgFA5uKSdWFcVcojCKo3P9SNrhC7fW+z6xQQEC30jiJD1CxLiFz7pI
0QWVIj6qscPrxK5TP2Gy1XCUnlrwTFdq9X3LrXQqGXyZaQmtUvrkXfezevjbRWPHrgbI
pn0GsW5xHQtDTj8/hSNfPbEnPST3ZFQeqRDpJPeBIuQ5sgoSkpa9i/bbB4CoI2ptxPdT
dHqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=aHBkoXfNrn0aJEnzcjCOLqDrTyxit4vkhKYwulyoDEk=;
b=nRibqP5IicqU86U7Ek01rUOxgWzGyuXT+v3q28hvwdmgvRALMcGHjFojdHsdzSFR8P
oIWI+r8Q09BKExyBJugDxSHuw85gOw9rinIh1Tp8kJR2r6IvjE/eSowWSrfml4ZFZrtv
R8XXpGrN2l2z7kW0JVPXP+XWYx6vwACZuToq0dCztBnSAePyhbTDFpXKPg1/BZxVw+UC
vqxrASU3LQHaJBBt3RpYHrRzsOJfz42jl3Pn+3nl/lvo6MMt7nsLUYgVqE8ItTCkvfpg
AFX+/kObziZxEzuLLLvfbb7OYhmUwEHGmccshBS32dJyNcPvF1oL+iGaxxioI4Tr6tZy
lCzQ==
X-Gm-Message-State: APjAAAVYInDDz9vM0tGbbm2CyWlSLMt2JZOToIbOTC+iTnYYdPLzpFII
EOOl/QWeqnlsptnCJR6sI5NkcXl3wa9YkKZ42gxjSg==
X-Google-Smtp-Source: APXvYqw3LSBcLVfocLu+eGder4+nYYWJnJAs6dFLYWlb4XR2BFpZVrHA2QF/p90O+ERwZc27w5tHnsu4lrB8QWACjZY=
X-Received: by 2002:a5d:62cf:: with SMTP id o15mr1133650wrv.45.1556130927956;
Wed, 24 Apr 2019 11:35:27 -0700 (PDT)
MIME-Version: 1.0
From: Dmitrii Korobeinikov <dim1212k@HIDDEN>
Date: Thu, 25 Apr 2019 00:35:16 +0600
Message-ID: <CA+Yh0SQ7yWQBjXhKbJPrCroriNpwhyFyQWAfHsUvxwmojsjKuw@HIDDEN>
Subject: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
To: bug-gnu-emacs@HIDDEN
Content-Type: multipart/mixed; boundary="00000000000030860305874af711"
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
recognized.
X-Received-From: 2a00:1450:4864:20::429
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
--00000000000030860305874af711
Content-Type: multipart/alternative; boundary="00000000000030860005874af70f"
--00000000000030860005874af70f
Content-Type: text/plain; charset="UTF-8"
For your convenience, I have attached this e-mail as an org-mode file.
*SUMMARY* /Buffer lens/ is an object inside a buffer which provides that
buffer the lines to display and which is linked to another buffer (from
which it can take and process data), while mapping the input back to that
linked buffer. /Composite lens/ is the extension of this idea to interface
any sources of data (for which text interface is possible). Some Org-mode
problems are addressed, particularly those concerning source block editing
and viewing, syntax checking, completion and reference expansion.
This is a proposal for /lenses/. Hereby, I outline the general idea, the
problems it solves, the features it introduces and its use cases.
* Problem Statement
The problem is that it's hard to treat some area inside a buffer
- as if it ran in a different buffer, with its own set of modes,
- as an object w/ distinct properties and interface.
This proposal is not drawn out of thin air: the bigger part of it is
about applications
(for an immediate example, you could think of an org mode source block.)
* Mechanics
The idea is to embed a buffer inside another buffer.
Have a block of text, a sentence, a table, a word -- some /area/ in your
buffer -- behave as if it were in some other distinct buffer, which has
it's own modes and keybindings.
What's proposed here is to do such a trick using a /buffer lens/.
First, let's form a preliminary, prototype definition (it will be changed
later in this section).
A /buffer lens/ is an object which views its /linked buffer/ and this
buffer can be viewed using /areas/.
An /area/ is a text object, whose properties and contents are controlled
by its /lens/.
The /linked buffer/ is (conceptually) just a regular buffer, whose
contents the lens can use to control its /area/.
Suppose you have opened some buffer - call it a /Working buffer/ or /WB/.
/Lens-mode/ is the mode responsible for all the /lenses/ inside the
/working buffer/.
The goals of the /lens-mode/ are:
- Identify, track and handle all the /lenses/ in the buffer.
- Display each /area/ according to the options of its /lens/ and its own
options.
- Let the user relay the control/input to a /lens/ (say, when the cursor
is in its /area/), which would in turn relay the input to its /linked
buffer/ as if it were in its own window. Either all user actions could be
relayed or just a defined subset (e.g. specific keybindings or commands).
- Let the user define specific maps and user input handling routines for
any specific /lens/ or for any type of /lens/, where type is deduced from
the properties of the lens (by a user-defined function).
- Propagate save commands to the lenses.
(which may signal the /model/ to adapt the changes in the /shared
base/: these will be discussed shortly).
We could also come up with a general description of a /lens/.
Call it a /composite lens/.
A /composite lens/ could consist of these parts: /model/,
/representation/, /linked buffer/, /shared base/, /shared block/, /view/
and /controller/.
This is almost like MVC.
I find it somewhat more intuitive to use the term /area/ instead of
/view/, so let's do that (at least for now).
/Model/ is data (strings, buffers, databases, anything).
/Representation/ is the description of how to build /shared blocks/ and
/shared bases/ using the /model/.
/Shared base/ consists of /shared blocks/.
Each /shared block/ is constructed (through representation) to be:
- either plain text or
- a lens (such as /buffer-lens/) (hence the name /composite-lens/ - it
makes use of other lenses).
/Linked buffer/ is a buffer which views a /shared base/. This buffer is
like a regular buffer (runs its own modes, etc.).
/Area/ is associated w/ one /linked buffer/ and is its contents + some
properties.
/Controller/ maps the user input to the /linked buffer/ of the /area/.
Get a load of this:
The /linked buffer/ views a /shared base/, which consists of /shared
blocks/, which are either plain text or other lenses, being described by
the /representation/ of the /model/, which may be ultimately accessed via
the /controller/, which maps the user input from the /area/.
Plain text for /shared blocks/ is for stuff that doesn't need to be kept
in the /model/ (say, for delimiters which identify the /lens/ as such in
the /working buffer/, where they reside before the /lens-mode/ runs).
The goal of these abstractions is to allow having
- multiple /areas/,
- each having a dedicated buffer (w/ distinct modes and properties),
- which share the same textual data (the /shared base/),
- which is compiled from plain text or other lenses (/shared blocks/),
- which have their own input interface (e.g. /buffer-lenses/).
Since the data is shared between the /areas/ (through /shared base/), if
the user makes some changes in one /area/, the changes immediately appear
in all other /areas/.
As such, a /buffer lens/ is a special case of a /composite lens/, except
- it has no /model/ (and so, needs no /representation/),
- its /shared base/ is a single buffer.
Note, this approach differs from what was described in the beginning of
this section: now there can be multiple /linked buffers/, all sharing one
/shared base/.
This approach is more powerful: it allows multiple /areas/ to behave
differently and reduces data duplication.
One point worth attention is that an /area/ should also have its own set
of properties, such as custom padding, alignment (center, left, right), etc.
Such properties could be arbitrary as long as mapping the user input back
to the /linked buffer/ can be performed.
This will allow visual customizations.
/Representations/ should be modifiable (through some interface).
The usage of /shared blocks/ above is really for explanatory purposes
and, possibly, less of a necessity (but may indeed come in useful when
multiple representations).
Saving is also an important thing to discuss.
The lens should be able to form an area, where the displayed text
/shadows/ the text which actually needs to be saved.
This is doable: in org-mode, when you fold a title, the ellipsis have
arbitrary data hidden in their place.
But the possibilities are:
- use faces/folding or such (I am not too familiar w/ the associated
technicalities, but I think they could work), or
- (what seems like the better solution), the save operation could grab
the /shared base/ which the /area/ uses (or query the lens for what to
save).
And as for the undo behavior, what's clear is that the changes will need
to be tracked to the /shared base/ of all /areas/ of the same
/representation/.
* Practical Applications
** Org-mode
Org-mode, a distinct planescape in the Emacs multiverse, might be the
mode to benefit the most from the use of lenses.
*** 3D Tables
Suppose you have three table:
| 0 | 0 | 0 |
| 0 | A | 0 |
| 0 | 0 | 0 |
| 0 | B | 0 |
| B | 0 | B |
| 0 | B | 0 |
| C | 0 | C |
| 0 | 0 | 0 |
| C | 0 | C |
Say, these tables are just the layers of a 3x3 cube.
You might want to view this cube as a distinct entity:
-**LAYER 1**-
| 0 | 0 | 0 |
| 0 | A | 0 |
| 0 | 0 | 0 |
You could use a composite lens for this.
The /model/ would be three buffers, one table in each.
The /representation/ describes the /view/ as:
- as a string ("-**LAYER 1**-") and
- a /buffer lens/ linking one of the three buffers in the /model/.
One could command the lens to switch to the next layer: just change the
/representation/.
When the cursor is in the /area/, the user input now is handled in its
/linked buffer/.
When the cursor is directly on the table, the input is relayed to the
/buffer lens/ of the table, whose /area's/ /linked buffer/ has org-mode
running.
The tables are identified and replaced when the /lens-mode/ runs for
the first time.
But what should happen when the user saves the buffer?
We want to save all three tables, not just the one which happens to be
currently viewed.
The possible solution, as discussed in [[Mechanics]], could be to
/shadow/ the three tables.
Of course, tables can be explored in any way, not just layer by layer.
https://en.wikipedia.org/wiki/Online_analytical_processing
So, to give a perspective on all this: a table becomes an object and
the modes that run in the /linked buffer/ form the interface to this object.
And, really, a table is a table for example purposes, and, obviously,
anything else could be in its place.
*** Code Blocks and Results: Editing and Viewing
Here I will first discuss all the relevant problems and then propose a
solution.
**** Problems
***** Editing Source Blocks [0/5]
Consider this block:
#+BEGIN_SRC elisp
(defun step (x l)
(case (< x l) 0
t 1))
#+END_SRC
First, 'newline-and-indent doesn't indent the code correctly.
It simply seems to look at the first symbol of the previous line:
- [ ] support for mode-specific editing features is limited,
- [ ] the mode-specific interactive features (say, keybindings) are
disregarded.
Using 'org-edit-src-code helps, but it is a hassle.
What's more, every time 'org-edit-src-code is used:
- [ ] a new buffer is created, which implies initialization of the
buffer modes,
- [ ] the changes need to be written back.
The issues with the points above can be demonstrated by observing the
bugs w/ 'org-comment-dwim:
- the screen is scrolled to show the first line of the block,
- in visual line mode, the cursor jumps to the beginning of the block.
Marks are thrown back to the beginning of the block -- for the same
reason.
Also, the larger the code block, the more work has to be done, so,
- [ ] some lag is to be expected.
(Bug report for the commenting behavior: https:/
sdebbugs.gnu.org/cgi/bugreport.cgi?bug=bug%2334977)
***** Viewing Source Blocks and Results [0/6]
Consider these two blocks:
#+NAME: syntax-tangling-commenting
#+BEGIN_SRC elisp
(defun step (x l)
(case (< x l) 0
t 1))
#+END_SRC
#+BEGIN_SRC elisp :noweb yes
<<syntax-tangling-commenting>>
(step "wrong argument")
#+END_SRC
First and foremost, there is no syntax checking and neither is there
completion:
- [ ] what can be easily done in a separate buffer w/ some mode on
can't be done inline.
And using 'org-edit-src-code is not much of a relief as the syntax
checker and the completer have
- [ ] no way of dealing with references to process code as if tangled
in.
The consequences of this point are farther than those of the missing
syntax checking or completion:
sometimes, looking at code as a coherent whole, and not a series of
disconnect snippets, is what the programmer needs.
In principle, it could be possible for 'org-edit-source-code to
substitute code for each reference, but this is problematic due to the
points made in [[Editing Source Blocks]] section.
Next, when some failed assertion or a runtime error tells you a line
number, looking for it is tough.
But there is no way to show line numbers (absolute, as if references
were expanded).
Or suppose a source block produces a huge table.
This means you will want to truncate lines.
But maybe that's not what you want for the rest of your buffer.
These boil down to:
- [ ] can't view a specific area of a buffer, like :results or a
source block, as if it were in another buffer.
One other nice feature to see would be running the code and seeing the
results from within 'org-edit-src-code.
Currently, if one works using 'org-edit-src-code, running the code is
not an option, because you wouldn't see the :RESULTS anyway.
Currently, switching is necessary from the edit buffer to the main
buffer and back.
This problem could be solved by redirecting the output to some buffer
and split screening, but, then again, updating the original buffer is
required.
- [ ] If the results of execution were to be redirected to a separate
buffer, they would have to be mapped back to the original file for
consistency.
Let's now discuss the visual properties of code blocks and :results.
#+NAME: one-liner
#+BEGIN_SRC elisp
(defun step (x l) (case (< x l) 0 t 1))
#+END_SRC
For two lines of meaningful data, there are four lines of, admittedly,
noise.
Meaningful: the stuff that the programmer concentrates on.
For longer snippets, the noise-to-signal ratio drops, but when you
have a lot of snippets, these extra lines of parameters add up.
And everything starts looking like spiders making love in a bowl of
spaghetti.
I think one way which could help is to have a summary line and hide
the rest:
> [one-liner] (elisp) <other stuff>
> (defun step (x l) (case (< x l) 0 t 1))
And when it is necessary to edit the description of the block, one
could expand it on a key combination:
- the appearance of blocks could be more distinct and less noisy.
To add to this, note how the code in the source blocks is indented two
spaces forward.
Those are hard spaces and they weren't inserted right away, only after
using 'org-edit-src-code.
No doubt, this indentation helps.
However, it would be better for it to be purely visual and to be there
without having to call anything.
In short:
- [ ] a powerful way to customize the view of blocks is needed.
Next, the /ob-async/ package shows that asynchronous execution of
blocks is possible.
Apparently, the way it works is by placing a unique identifier in the
RESULTS and then replacing it.
Another possible scenario: display the current running time in the
footer of a block.
Is the find/search procedure the best one could do?
- [ ] A unified way to update the view of a block / results section
could help.
**** Solution
***** Basis
A source block can be shown via a /composite lens/.
And so can be every noweb reference.
For instance, suppose a buffer (call it /main buffer/) has these blocks
(also used in the following subsections):
#+NAME: block-A
#+BEGIN_SRC python
f = lambda x: x ** x
#+END_SRC
#+NAME: block-B
#+BEGIN_SRC python :noweb yes
<<block-A>>
g = lambda x: f(x) + f(x + 1)
#+END_SRC
So, these lenses are created:
- /block-A/ /composite lens/ containing:
- /buffer-A/ /lens/ (w/ contents "f = lambda x: x ** x")
- begin/end source markers as plain text
- /block-B/ /composite lens/ containing:
- /buffer-A/ /lens/ (w/ contents "f = lambda x: x ** x" shadowing
"<<block-A>>" or just "<<block-A>>")
- /buffer-B/ /buffer lens/ (w/ contents "g = lambda x: f(x) + f(x +
1)")
As you see, the code of block-A appears in two blocks: as code and as a
reference.
A reasonable thing to do is create just one lens for both.
So, this lens should contain the code, but should also be able to show
just the reference.
There are multiple ways to display this lens (that is, to form an
/area/):
show the code/reference which, /optionally/, shadows reference/code.
For example, in block-B, we may choose to show code and shadow the
reference, so that when the document is saved, the text of the reference is
actually saved and not the code.
So, in the end, there is just one lens for /buffer-A/, with two
/areas/, one for /block-B/ and one for /block-A/.
The lens could be either /buffer-lens/ or a /composite-lens/, it's up
to the implementation.
***** Editing
The most important point to remember now is this:
the linked buffer has its own set of modes, independent of the mods in
the working buffer.
Lens-mode offers an important utility (discussed in [[Mechanics]]):
it can redirect keybindings and commands when the cursor is in the area
of the lens.
So, basically, the user can have access to all the features of the
modes which run in the linked buffer.
This immediately implies proper indentation and the resolution of the
bug w/ commenting.
(comment keybinding is forwarded to the /inner buffer/ and the right
thing is done there.)
And what about 'org-edit-src-code?
Just open a buffer and show the /buffer-A/B/ lens there!
No need to write the changes back: all the areas of the lens update in
real time.
***** Viewing
In addition to the two blocks from [[Basis]], let's define:
#+NAME: block-C
#+BEGIN_SRC python :noweb yes
<<block-B>>
h = 10 * f(5) * g(2)
#+END_SRC
#+NAME: block-D
#+BEGIN_SRC python :noweb yes
<<block-B>>
y = g(1)
#+END_SRC
So, the dependency tree is this:
block-A <-- block-B <-- block-C
<-- block-D
First, let's see what can be done about syntax checking, completion and
the possibility of viewing all the code at once.
How can we deal with the noweb references?
Understanding what it is exactly that we want may help us answer the
question.
A rough list of requirements/wishes could be:
(regardless of working in the /main buffer/ or using 'org-edit-src-code)
- (1) have an option to expand the references into code
- (2) have syntax checking and completion:
- (a) which work as if the references were expanded (regardless of
the actual reference expansion options),
- (b) which work as if the code that references the block is seen as
well
- if included by multiple blocks (e.g. in case of ~block-B~, the
usage by ~block-C~ and ~block-D~), prefer the one which ran last.
- (c) and minimize the work done.
OK, all of the above can exploit the functionality of lenses, which,
upon request, can produce the right /area/ based the preferences of the
buffer which contains the /lens/.
(1) is covered: the lenses for references are recursively asked to show
code instead of the reference.
(2) is also covered - let's discuss the details.
What is point (2),(b) all about?
Why would <<block-B>> care about who references it (i.e blocks C and D)?
Wouldn't it be enough for the syntax checker to view just the expanded
<<block-A>> reference?
Indeed, that would almost work, but there are flaws to this approach:
- things like /unused variable/ or /missing a closing bracket/ will
arise,
- it is unnecessarily expensive.
This last point is simple: why run syntax checker in ~block-A~ and
~block-B~, if one could run it in ~block-C~ and map the changes back?
So, the solution is to build source block tree and run syntax checker
on the end nodes, while propagating the results back to the root. If there
is a fork, propagate from the one which the user ran last.
How exactly could this work in our example?
- Keep a buffer which views the ~block-C~ lens and recursively tell the
reference-lenses to show the code.
- Run the syntax checker there and associate the output w/ each lens
(recursively).
- For completion, propagate user input (from lenses A, B and C) to this
same ~block-C~ buffer and deal w/ the result.
OK, so much for the tougher share of the problems.
Now, let's get the rest of the issues.
- View customization is in place: /areas/ may have various properties
and can show/hide/display the begin/end ornamentation in any manner.
(e.g. :RESULTS lens truncates lines, while the buffer that contains
it doesn't, etc., see the [[Problems]] section)
(e.g. the /area/ of the code lens is indented two spaces, as it's
property)
- One could instruct a lens what to do instead of using regexp +
replace.
(e.g. continuosly update a timer)
Results sections can be shown via lenses.
Now, when editing w/ 'ord-edit-src-code, just split the screen and open
:RESULTS in another buffer.
Editing or running the code: everything will be kept in sync w/ the
original buffer.
Some blocks may output several distinct pieces of data, like here:
http://kitchingroup.cheme.cmu.edu/blog/2017/01/29/ob-ipython-and-inline-figures-in-org-mode
Replacing the old results could be just a matter of removing the
existing lens and placing in a new one.
No need to search for the end of the results block.
You could select a portion of the block and narrow it.
Showing the line numbers should be a matter of running nlinum in the
end node buffer (as w/ syntax checking), but I don't know how nlinum works
to say for sure.
To be fair, some of the descriptions here depend on implementation
possibilities, so the level of detail is in accordance.
*** Other uses
**** Inline view of links
One could make some sort of a lens to view a part of a buffer/file
identified by a link.
The buffer could be the same buffer, an external file, anything.
One would not have to follow the link.
When following the link is too cumbersome, copy pasting is prevented.
**** Display Org documents
Sections in an org document could be shown using lenses.
Not that I know why this would be useful (well, maybe for making a
[[Jupyter]] like environment).
But the concept is interesting.
**** Connect several source blocks
(I have proposed this on the Org-mode mailing list, but now that I
think of it, a user-defined way as here is better.)
A quite ordinary workflow is to write a block and then test the block
seperately (or use :epilogue for one-liners).
However, writing out a test seperately is noisy and something like
this could be done instead:
#+NAME: square-1
#+BEGIN_SRC python
square = lambda x: x * x
#+END_SRC
return [square(x) for x in range(10)]
#+END_SRC_TEST
This could be accomplished by lenses: lens-mode would only need to
check for two adjacent blocks <name> and <name>-test and then wrap them in
another lens, showing both like above.
Of course, some way to let org-babel know what's going on would be
necessary.
** Arbitrary Positioning (Window Lenses)
Window lenses are a logical extension of buffer lenses.
Imagine you wanted to stack two images horizontally.
Viewing two images horizontally in Emacs can be done by creating two
windows, one image in each window.
That's what a window lens could do, except it would be shown inside a
buffer.
** Interactive Graphs
This one is tougher than window lenses, but much more interesting.
Say, you wanted to have an interactive graph in your buffer (gnuplot,
matplotlib).
This part of the buffer would require it's own keybindings and all, but
the area of the lens could be customized, through its properties of
padding/centering and such, to adorn and place the graph in a visually
satisfying manner.
In the land where unicorns live, one would be able to view any graphical
window inside Emacs: something that would satisfy the taste of even the
finest gourmets of modern text editing (uGhrHrhmph).
Not that the buffer lenses are the biggest problem here, but they just
might come in useful.
** Fast Timer Updates (Text as an Object)
I have already touched on this topic a bit in the context of Org-Mode,
and now, for the sake of completeness, let's form a general characteristic
of using lenses.
A timer was mentioned: currently, as I understand, if you wanted to put
it in your buffer and see it continuously update, you would have to use
search and replace, which is not efficient.
The solution offered was to use a lens: it would itself update the timer
(as a /shared block/ or some other direct manner).
And the uses are more general: since /lens-mode/ tracks all the lenses,
one could send commands to them.
They can update independently.
So, if there are text objects, they may be accessed easily.
This was one of the goals set in the [[Problem Statement]].
** Bug Trackers & Websites & Databases (Interface Building)
Perhaps, one could work with Gitlab server or similar through lenses.
Building an interface for a website doesn't seem to be out of the
question either.
Accesing a database: why not?
* Jupyter
Jupyter is a reproducible research environment.
https://jupyter.org/
Here is what using it looks like:
http://arogozhnikov.github.io/2016/09/10/jupyter-features.html
Jupyter has a serious flaw.
It doesn't run inside Emacs.
(Listen, all is even worse: it runs in a web browser (yes, I know about
links and eww.))
I haven't used it much, so let's rely on the opinion of someone who has:
https://towardsdatascience.com/5-reasons-why-jupyter-notebooks-suck-4dc201e27086
- 1. It is almost impossible to enable good code versioning (files are
JSON, merging is difficult)
- 2. There is no IDE integration, no linting, no code-style correction
(quite surprising considering the popularity, isn't it?)
- 3. Very hard to test (not the problem of Jupyter, really)
- 4. The non-linear workflow of jupyter
- 5. Jupyter is bad for running long asynchronous tasks
Someone also said that many snippets in Jupyter are hard to manage. I
believe him.
The good stuff about Jupyter:
- 1. easy to use / low entry barrier,
- 2. interactive graphs,
- 3. visually distinct cells.
Plan: Emacs beats Jupyter, Jupyter dies an agonizing death, everyone
starts using Emacs (the last two points may be reversed).
Say, if the stuff in the org-mode section and the interactive graphs (at
least for matplotlib) were implemented, making some special easy mode w/
the intuitive keybindings could convert some Jupyter folks.
The third point on cells is also doable if lenses get some area
customizations like padding and centering. And, if necessary, the whole org
tree could be viewed through lenses.
And org-mode can already export to html, for presentation purposes.
In short: I think making a good reproducible research environment, easily
usable and full of features is a good goal and could lure some people into
using Emacs (if only superficially at first).
* Implementation
I am not familiar with Emacs internals to say what's feasible of the
proposed structure.
And the two major things in [[Mechanics]] that somewhat depend on how
Emacs works are:
- shadowing, and
- making two buffers (w/ different modes) share the same text (/linked
buffers/ share the same /shared base/).
* Discussion
Nothing in this proposal is set in stone, feel free to change it to your
liking.
Some naming is probably flawed.
Some structures might be overly ambitious or unnecessary.
All implementation-related suggestions are just suggestions.
Some explanations could be more clear.
More applications couldn't hurt.
The effects of the implementation are contained within the lens-mode.
Which means users should not notice the difference unless they turn on
the lens-mode.
If the implementation is undertaken, this will be good for testing and
integration.
Overall, I think the applications might be very well worth the effort.
Especially for Org-mode.
--00000000000030860005874af70f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div>For your convenience, I have attache=
d this e-mail as an org-mode file.</div><div><br></div><div>*SUMMARY* /Buff=
er lens/ is an object inside a buffer which provides that buffer the lines =
to display and which is linked to another buffer (from which it can take an=
d process data), while mapping the input back to that linked buffer. /Compo=
site lens/ is the extension of this idea to interface any sources of data (=
for which text interface is possible). Some Org-mode problems are addressed=
, particularly those concerning source block editing and viewing, syntax ch=
ecking, completion and reference expansion.</div><div><br></div><div>This i=
s a proposal for /lenses/. Hereby, I outline the general idea, the problems=
it solves, the features it introduces and its use cases.</div><div><br></d=
iv><div>* Problem Statement</div><div><br></div><div>=C2=A0 The problem is =
that it's hard to treat some area inside a buffer</div><div>=C2=A0 - as=
if it ran in a different buffer, with its own set of modes,</div><div>=C2=
=A0 - as an object w/ distinct properties and interface.</div><div><br></di=
v><div>=C2=A0 This proposal is not drawn out of thin air: the bigger part o=
f it is about applications</div><div>=C2=A0 (for an immediate example, you =
could think of an org mode source block.)</div><div><br></div><div>* Mechan=
ics</div><div><br></div><div>=C2=A0 The idea is to embed a buffer inside an=
other buffer.</div><div>=C2=A0 Have a block of text, a sentence, a table, a=
word -- some /area/ in your buffer -- behave as if it were in some other d=
istinct buffer, which has it's own modes and keybindings.</div><div><br=
></div><div>=C2=A0 What's proposed here is to do such a trick using a /=
buffer lens/.</div><div><br></div><div>=C2=A0 First, let's form a preli=
minary, prototype definition (it will be changed later in this section).</d=
iv><div>=C2=A0 A /buffer lens/ is an object which views its /linked buffer/=
and this buffer can be viewed using /areas/.</div><div>=C2=A0 An /area/ is=
a text object, whose properties and contents are controlled by its /lens/.=
</div><div>=C2=A0 The /linked buffer/ is (conceptually) just a regular buff=
er, whose contents the lens can use to control its /area/.</div><div><br></=
div><div>=C2=A0 Suppose you have opened some buffer - call it a /Working bu=
ffer/ or /WB/.</div><div>=C2=A0 /Lens-mode/ is the mode responsible for all=
the /lenses/ inside the /working buffer/.</div><div><br></div><div>=C2=A0 =
The goals of the /lens-mode/ are:</div><div>=C2=A0 - Identify, track and ha=
ndle all the /lenses/ in the buffer.</div><div>=C2=A0 - Display each /area/=
according to the options of its /lens/ and its own options.</div><div>=C2=
=A0 - Let the user relay the control/input to a /lens/ (say, when the curso=
r is in its /area/), which would in turn relay the input to its /linked buf=
fer/ as if it were in its own window. Either all user actions could be rela=
yed or just a defined subset (e.g. specific keybindings or commands).</div>=
<div>=C2=A0 - Let the user define specific maps and user input handling rou=
tines for any specific /lens/ or for any type of /lens/, where type is dedu=
ced from the properties of the lens (by a user-defined function).</div><div=
>=C2=A0 - Propagate save commands to the lenses.</div><div>=C2=A0 =C2=A0 (w=
hich may signal the /model/ to adapt the changes in the /shared base/: thes=
e will be discussed shortly).</div><div><br></div><div>=C2=A0 We could also=
come up with a general description of a /lens/.</div><div>=C2=A0 Call it a=
/composite lens/.</div><div>=C2=A0=C2=A0</div><div>=C2=A0 A /composite len=
s/ could consist of these parts: /model/, /representation/, /linked buffer/=
, /shared base/, /shared block/, /view/ and /controller/.</div><div>=C2=A0 =
This is almost like MVC.</div><div>=C2=A0 I find it somewhat more intuitive=
to use the term /area/ instead of /view/, so let's do that (at least f=
or now).</div><div><br></div><div>=C2=A0 /Model/ is data (strings, buffers,=
databases, anything).</div><div>=C2=A0 /Representation/ is the description=
of how to build /shared blocks/ and /shared bases/ using the /model/.</div=
><div>=C2=A0 /Shared base/ consists of /shared blocks/.</div><div>=C2=A0 Ea=
ch /shared block/ is constructed (through representation) to be:</div><div>=
=C2=A0 - either plain text or</div><div>=C2=A0 - a lens (such as /buffer-le=
ns/) (hence the name /composite-lens/ - it makes use of other lenses).</div=
><div>=C2=A0 /Linked buffer/ is a buffer which views a /shared base/. This =
buffer is like a regular buffer (runs its own modes, etc.).</div><div>=C2=
=A0 /Area/ is associated w/ one /linked buffer/ and is its contents + some =
properties.</div><div>=C2=A0 /Controller/ maps the user input to the /linke=
d buffer/ of the /area/.=C2=A0</div><div><br></div><div>=C2=A0 Get a load o=
f this:</div><div>=C2=A0 The /linked buffer/ views a /shared base/, which c=
onsists of /shared blocks/, which are either plain text or other lenses, be=
ing described by the /representation/ of the /model/, which may be ultimate=
ly accessed via the /controller/, which maps the user input from the /area/=
.</div><div><br></div><div>=C2=A0 Plain text for /shared blocks/ is for stu=
ff that doesn't need to be kept in the /model/ (say, for delimiters whi=
ch identify the /lens/ as such in the /working buffer/, where they reside b=
efore the /lens-mode/ runs).</div><div><br></div><div>=C2=A0 The goal of th=
ese abstractions is to allow having</div><div>=C2=A0 - multiple /areas/,=C2=
=A0</div><div>=C2=A0 - each having a dedicated buffer (w/ distinct modes an=
d properties),</div><div>=C2=A0 =C2=A0 - which share the same textual data =
(the /shared base/),=C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0 - which is compil=
ed from plain text or other lenses (/shared blocks/),</div><div>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 - which have their own input interface (e.g. /buffer-lens=
es/).</div><div><br></div><div>=C2=A0 Since the data is shared between the =
/areas/ (through /shared base/), if the user makes some changes in one /are=
a/, the changes immediately appear in all other /areas/.</div><div><br></di=
v><div>=C2=A0 As such, a /buffer lens/ is a special case of a /composite le=
ns/, except=C2=A0</div><div>=C2=A0 - it has no /model/ (and so, needs no /r=
epresentation/),=C2=A0</div><div>=C2=A0 - its /shared base/ is a single buf=
fer.</div><div>=C2=A0 Note, this approach differs from what was described i=
n the beginning of this section: now there can be multiple /linked buffers/=
, all sharing one /shared base/.</div><div>=C2=A0 This approach is more pow=
erful: it allows multiple /areas/ to behave differently and reduces data du=
plication.</div><div><br></div><div>=C2=A0 One point worth attention is tha=
t an /area/ should also have its own set of properties, such as custom padd=
ing, alignment (center, left, right), etc.</div><div>=C2=A0 Such properties=
could be arbitrary as long as mapping the user input back to the /linked b=
uffer/ can be performed.</div><div>=C2=A0 This will allow visual customizat=
ions.</div><div><br></div><div>=C2=A0 /Representations/ should be modifiabl=
e (through some interface).</div><div><br></div><div>=C2=A0 The usage of /s=
hared blocks/ above is really for explanatory purposes and, possibly, less =
of a necessity (but may indeed come in useful when multiple representations=
).</div><div><br></div><div>=C2=A0 Saving is also an important thing to dis=
cuss.</div><div>=C2=A0 The lens should be able to form an area, where the d=
isplayed text /shadows/ the text which actually needs to be saved.</div><di=
v>=C2=A0 This is doable: in org-mode, when you fold a title, the ellipsis h=
ave arbitrary data hidden in their place.</div><div>=C2=A0 But the possibil=
ities are:</div><div>=C2=A0 - use faces/folding or such (I am not too famil=
iar w/ the associated technicalities, but I think they could work), or</div=
><div>=C2=A0 - (what seems like the better solution), the save operation co=
uld grab the /shared base/ which the /area/ uses (or query the lens for wha=
t to save).</div><div><br></div><div>=C2=A0 And as for the undo behavior, w=
hat's clear is that the changes will need to be tracked to the /shared =
base/ of all /areas/ of the same /representation/.</div><div><br></div><div=
>* Practical Applications</div><div><br></div><div>** Org-mode</div><div><b=
r></div><div>=C2=A0 Org-mode, a distinct planescape in the Emacs multiverse=
, might be the mode to benefit the most from the use of lenses.</div><div><=
br></div><div>*** 3D Tables</div><div><br></div><div>=C2=A0 =C2=A0 Suppose =
you have three table:</div><div><br></div><div>=C2=A0 =C2=A0 | 0 | 0 | 0 |<=
/div><div>=C2=A0 =C2=A0 | 0 | A | 0 |</div><div>=C2=A0 =C2=A0 | 0 | 0 | 0 |=
</div><div><br></div><div>=C2=A0 =C2=A0 | 0 | B | 0 |</div><div>=C2=A0 =C2=
=A0 | B | 0 | B |</div><div>=C2=A0 =C2=A0 | 0 | B | 0 |</div><div><br></div=
><div>=C2=A0 =C2=A0 | C | 0 | C |</div><div>=C2=A0 =C2=A0 | 0 | 0 | 0 |</di=
v><div>=C2=A0 =C2=A0 | C | 0 | C |</div><div><br></div><div>=C2=A0 =C2=A0 S=
ay, these tables are just the layers of a 3x3 cube.</div><div>=C2=A0 =C2=A0=
You might want to view this cube as a distinct entity:</div><div>=C2=A0 =
=C2=A0=C2=A0</div><div>=C2=A0 =C2=A0 -**LAYER 1**-</div><div>=C2=A0 =C2=A0 =
| 0 | 0 | 0 |</div><div>=C2=A0 =C2=A0 | 0 | A | 0 |</div><div>=C2=A0 =C2=A0=
| 0 | 0 | 0 |</div><div><br></div><div>=C2=A0 =C2=A0 You could use a compo=
site lens for this.</div><div>=C2=A0 =C2=A0 The /model/ would be three buff=
ers, one table in each.</div><div>=C2=A0 =C2=A0 The /representation/ descri=
bes the /view/ as:</div><div>=C2=A0 =C2=A0 - as a string ("-**LAYER 1*=
*-") and</div><div>=C2=A0 =C2=A0 - a /buffer lens/ linking one of the =
three buffers in the /model/.</div><div><br></div><div>=C2=A0 =C2=A0 One co=
uld command the lens to switch to the next layer: just change the /represen=
tation/.</div><div><br></div><div>=C2=A0 =C2=A0 When the cursor is in the /=
area/, the user input now is handled in its /linked buffer/.</div><div>=C2=
=A0 =C2=A0 When the cursor is directly on the table, the input is relayed t=
o the /buffer lens/ of the table, whose /area's/ /linked buffer/ has or=
g-mode running.</div><div><br></div><div>=C2=A0 =C2=A0 The tables are ident=
ified and replaced when the /lens-mode/ runs for the first time.</div><div>=
=C2=A0 =C2=A0 But what should happen when the user saves the buffer?</div><=
div>=C2=A0 =C2=A0 We want to save all three tables, not just the one which =
happens to be currently viewed.</div><div>=C2=A0 =C2=A0 The possible soluti=
on, as discussed in [[Mechanics]], could be to /shadow/ the three tables.</=
div><div><br></div><div>=C2=A0 =C2=A0 Of course, tables can be explored in =
any way, not just layer by layer.</div><div>=C2=A0 =C2=A0 <a href=3D"https:=
//en.wikipedia.org/wiki/Online_analytical_processing" target=3D"_blank">htt=
ps://en.wikipedia.org/wiki/Online_analytical_processing</a></div><div><br><=
/div><div>=C2=A0 =C2=A0 So, to give a perspective on all this: a table beco=
mes an object and the modes that run in the /linked buffer/ form the interf=
ace to this object.</div><div>=C2=A0 =C2=A0 And, really, a table is a table=
for example purposes, and, obviously, anything else could be in its place.=
</div><div><br></div><div>*** Code Blocks and Results: Editing and Viewing<=
/div><div><br></div><div>=C2=A0 =C2=A0 Here I will first discuss all the re=
levant problems and then propose a solution.</div><div><br></div><div>**** =
Problems</div><div>***** Editing Source Blocks [0/5]</div><div><br></div><d=
iv>=C2=A0 =C2=A0 =C2=A0Consider this block:</div><div><br></div><div>=C2=A0=
=C2=A0 =C2=A0#+BEGIN_SRC elisp</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0(defun=
step (x l)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(case (< x l) 0<=
/div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0t 1))</div=
><div>=C2=A0 =C2=A0 =C2=A0#+END_SRC</div><div><br></div><div>=C2=A0 =C2=A0 =
=C2=A0First, 'newline-and-indent doesn't indent the code correctly.=
</div><div>=C2=A0 =C2=A0 =C2=A0It simply seems to look at the first symbol =
of the previous line:</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0- [ ] su=
pport for mode-specific editing features is limited,</div><div>=C2=A0 =C2=
=A0 =C2=A0- [ ] the mode-specific interactive features (say, keybindings) a=
re disregarded.</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0Using 'org=
-edit-src-code helps, but it is a hassle.</div><div><br></div><div>=C2=A0 =
=C2=A0 =C2=A0What's more, every time 'org-edit-src-code is used:</d=
iv><div><br></div><div>=C2=A0 =C2=A0 =C2=A0- [ ] a new buffer is created, w=
hich implies initialization of the buffer modes,</div><div>=C2=A0 =C2=A0 =
=C2=A0- [ ] the changes need to be written back.</div><div><br></div><div>=
=C2=A0 =C2=A0 =C2=A0The issues with the points above can be demonstrated by=
observing the bugs w/ 'org-comment-dwim:</div><div><br></div><div>=C2=
=A0 =C2=A0 =C2=A0- the screen is scrolled to show the first line of the blo=
ck,</div><div>=C2=A0 =C2=A0 =C2=A0- in visual line mode, the cursor jumps t=
o the beginning of the block.</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0=
Marks are thrown back to the beginning of the block -- for the same reason.=
</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0Also, the larger the code blo=
ck, the more work has to be done, so,</div><div><br></div><div>=C2=A0 =C2=
=A0 =C2=A0- [ ] some lag is to be expected.</div><div><br></div><div>=C2=A0=
=C2=A0 =C2=A0(Bug report for the commenting behavior: https:/<a href=3D"ht=
tp://sdebbugs.gnu.org/cgi/bugreport.cgi?bug=3Dbug%2334977" target=3D"_blank=
">sdebbugs.gnu.org/cgi/bugreport.cgi?bug=3Dbug%2334977</a>)</div><div><br><=
/div><div>***** Viewing Source Blocks and Results [0/6]</div><div><br></div=
><div>=C2=A0 =C2=A0 =C2=A0Consider these two blocks:</div><div><br></div><d=
iv>=C2=A0 =C2=A0 =C2=A0#+NAME: syntax-tangling-commenting</div><div>=C2=A0 =
=C2=A0 =C2=A0#+BEGIN_SRC elisp</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0(defun =
step (x l)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(case (< x l) 0</=
div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0t 1))</div>=
<div>=C2=A0 =C2=A0 =C2=A0#+END_SRC</div><div><br></div><div>=C2=A0 =C2=A0 =
=C2=A0#+BEGIN_SRC elisp :noweb yes</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0<=
;<syntax-tangling-commenting>></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0(step "wrong argument")</div><div>=C2=A0 =C2=A0 =C2=A0#+END_SR=
C</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0First and foremost, there is=
no syntax checking and neither is there completion:</div><div><br></div><d=
iv>=C2=A0 =C2=A0 =C2=A0- [ ] what can be easily done in a separate buffer w=
/ some mode on can't be done inline.</div><div><br></div><div>=C2=A0 =
=C2=A0 =C2=A0And using 'org-edit-src-code is not much of a relief as th=
e syntax checker and the completer have=C2=A0</div><div><br></div><div>=C2=
=A0 =C2=A0 =C2=A0- [ ] no way of dealing with references to process code as=
if tangled in.</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0The consequenc=
es of this point are farther than those of the missing syntax checking or c=
ompletion:</div><div>=C2=A0 =C2=A0 =C2=A0sometimes, looking at code as a co=
herent whole, and not a series of disconnect snippets, is what the programm=
er needs.</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0In principle, it cou=
ld be possible for 'org-edit-source-code to substitute code for each re=
ference, but this is problematic due to the points made in [[Editing Source=
Blocks]] section.</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0Next, when =
some failed assertion or a runtime error tells you a line number, looking f=
or it is tough.</div><div>=C2=A0 =C2=A0 =C2=A0But there is no way to show l=
ine numbers (absolute, as if references were expanded).</div><div>=C2=A0 =
=C2=A0 =C2=A0Or suppose a source block produces a huge table.</div><div>=C2=
=A0 =C2=A0 =C2=A0This means you will want to truncate lines.</div><div>=C2=
=A0 =C2=A0 =C2=A0But maybe that's not what you want for the rest of you=
r buffer.</div><div>=C2=A0 =C2=A0 =C2=A0These boil down to:</div><div><br><=
/div><div>=C2=A0 =C2=A0 =C2=A0- [ ] can't view a specific area of a buf=
fer, like :results or a source block, as if it were in another buffer.</div=
><div><br></div><div>=C2=A0 =C2=A0 =C2=A0One other nice feature to see woul=
d be running the code and seeing the results from within 'org-edit-src-=
code.</div><div>=C2=A0 =C2=A0 =C2=A0Currently, if one works using 'org-=
edit-src-code, running the code is not an option, because you wouldn't =
see the :RESULTS anyway.</div><div>=C2=A0 =C2=A0 =C2=A0Currently, switching=
is necessary from the edit buffer to the main buffer and back.</div><div>=
=C2=A0 =C2=A0 =C2=A0This problem could be solved by redirecting the output =
to some buffer and split screening, but, then again, updating the original =
buffer is required.</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0- [ ] If t=
he results of execution were to be redirected to a separate buffer, they wo=
uld have to be mapped back to the original file for consistency.</div><div>=
<br></div><div>=C2=A0 =C2=A0 =C2=A0Let's now discuss the visual propert=
ies of code blocks and :results.</div><div><br></div><div>=C2=A0 =C2=A0 =C2=
=A0#+NAME: one-liner</div><div>=C2=A0 =C2=A0 =C2=A0#+BEGIN_SRC elisp</div><=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0(defun step (x l) (case (< x l) 0 t 1))</=
div><div>=C2=A0 =C2=A0 =C2=A0#+END_SRC</div><div><br></div><div>=C2=A0 =C2=
=A0 =C2=A0For two lines of meaningful data, there are four lines of, admitt=
edly, noise.</div><div>=C2=A0 =C2=A0 =C2=A0Meaningful: the stuff that the p=
rogrammer concentrates on.=C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0For longer s=
nippets, the noise-to-signal ratio drops, but when you have a lot of snippe=
ts, these extra lines of parameters add up.</div><div>=C2=A0 =C2=A0 =C2=A0A=
nd everything starts looking like spiders making love in a bowl of spaghett=
i.</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0I think one way which could=
help is to have a summary line and hide the rest:</div><div><br></div><div=
>=C2=A0 =C2=A0 =C2=A0> [one-liner] (elisp) <other stuff></div><div=
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 (defun step (x l) (case (< x l) 0 t 1))<=
/div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0And when it is necessary to ed=
it the description of the block, one could expand it on a key combination:<=
/div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0- the appearance of blocks cou=
ld be more distinct and less noisy.</div><div><br></div><div>=C2=A0 =C2=A0 =
=C2=A0To add to this, note how the code in the source blocks is indented tw=
o spaces forward.</div><div>=C2=A0 =C2=A0 =C2=A0Those are hard spaces and t=
hey weren't inserted right away, only after using 'org-edit-src-cod=
e.</div><div>=C2=A0 =C2=A0 =C2=A0No doubt, this indentation helps.</div><di=
v>=C2=A0 =C2=A0 =C2=A0However, it would be better for it to be purely visua=
l and to be there without having to call anything.</div><div><br></div><div=
>=C2=A0 =C2=A0 =C2=A0In short:</div><div><br></div><div>=C2=A0 =C2=A0 =C2=
=A0- [ ] a powerful way to customize the view of blocks is needed.</div><di=
v><br></div><div>=C2=A0 =C2=A0 =C2=A0Next, the /ob-async/ package shows tha=
t asynchronous execution of blocks is possible.</div><div>=C2=A0 =C2=A0 =C2=
=A0Apparently, the way it works is by placing a unique identifier in the RE=
SULTS and then replacing it.</div><div>=C2=A0 =C2=A0 =C2=A0Another possible=
scenario: display the current running time in the footer of a block.</div>=
<div>=C2=A0 =C2=A0 =C2=A0Is the find/search procedure the best one could do=
?</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0- [ ] A unified way to updat=
e the view of a block / results section could help.</div><div><br></div><di=
v>**** Solution</div><div>***** Basis</div><div><br></div><div>=C2=A0 =C2=
=A0 A source block can be shown via a /composite lens/.</div><div>=C2=A0 =
=C2=A0 And so can be every noweb reference.</div><div><br></div><div>=C2=A0=
=C2=A0 For instance, suppose a buffer (call it /main buffer/) has these bl=
ocks (also used in the following subsections):</div><div><br></div><div>=C2=
=A0 =C2=A0 #+NAME: block-A</div><div>=C2=A0 =C2=A0 #+BEGIN_SRC python</div>=
<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0f =3D lambda x: x ** x</div><div>=C2=A0 =C2=
=A0 #+END_SRC</div><div><br></div><div>=C2=A0 =C2=A0 #+NAME: block-B</div><=
div>=C2=A0 =C2=A0 #+BEGIN_SRC python :noweb yes</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0<<block-A>></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0g =
=3D lambda x: f(x) + f(x + 1)</div><div>=C2=A0 =C2=A0 #+END_SRC</div><div><=
br></div><div>=C2=A0 =C2=A0 So, these lenses are created:</div><div>=C2=A0 =
=C2=A0 - /block-A/ /composite lens/ containing:</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0- /buffer-A/ /lens/ (w/ contents "f =3D lambda x: x ** x&quo=
t;)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0- begin/end source markers as plai=
n text</div><div>=C2=A0 =C2=A0 - /block-B/ /composite lens/ containing:</di=
v><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0- /buffer-A/ /lens/ (w/ contents "f =
=3D lambda x: x ** x" shadowing "<<block-A>>" or=
just "<<block-A>>")</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0- /buffer-B/ /buffer lens/ (w/ contents "g =3D lambda x: f(x) + =
f(x + 1)")</div><div><br></div><div>=C2=A0 =C2=A0 As you see, the code=
of block-A appears in two blocks: as code and as a reference.</div><div>=
=C2=A0 =C2=A0 A reasonable thing to do is create just one lens for both.</d=
iv><div>=C2=A0 =C2=A0 So, this lens should contain the code, but should als=
o be able to show just the reference.</div><div>=C2=A0 =C2=A0 There are mul=
tiple ways to display this lens (that is, to form an /area/):</div><div>=C2=
=A0 =C2=A0 show the code/reference which, /optionally/, shadows reference/c=
ode.</div><div>=C2=A0 =C2=A0 For example, in block-B, we may choose to show=
code and shadow the reference, so that when the document is saved, the tex=
t of the reference is actually saved and not the code.</div><div><br></div>=
<div>=C2=A0 =C2=A0 So, in the end, there is just one lens for /buffer-A/, w=
ith two /areas/, one for /block-B/ and one for /block-A/.</div><div>=C2=A0 =
=C2=A0 The lens could be either /buffer-lens/ or a /composite-lens/, it'=
;s up to the implementation.</div><div><br></div><div>***** Editing</div><d=
iv><br></div><div>=C2=A0 =C2=A0 The most important point to remember now is=
this:=C2=A0</div><div>=C2=A0 =C2=A0 the linked buffer has its own set of m=
odes, independent of the mods in the working buffer.</div><div><br></div><d=
iv>=C2=A0 =C2=A0 Lens-mode offers an important utility (discussed in [[Mech=
anics]]):=C2=A0</div><div>=C2=A0 =C2=A0 it can redirect keybindings and com=
mands when the cursor is in the area of the lens.</div><div>=C2=A0 =C2=A0 S=
o, basically, the user can have access to all the features of the modes whi=
ch run in the linked buffer.</div><div>=C2=A0 =C2=A0 This immediately impli=
es proper indentation and the resolution of the bug w/ commenting.</div><di=
v>=C2=A0 =C2=A0 (comment keybinding is forwarded to the /inner buffer/ and =
the right thing is done there.)</div><div><br></div><div>=C2=A0 =C2=A0 And =
what about 'org-edit-src-code?</div><div>=C2=A0 =C2=A0 Just open a buff=
er and show the /buffer-A/B/ lens there!</div><div>=C2=A0 =C2=A0 No need to=
write the changes back: all the areas of the lens update in real time.</di=
v><div><br></div><div>***** Viewing</div><div><br></div><div>=C2=A0 =C2=A0 =
In addition to the two blocks from [[Basis]], let's define:</div><div><=
br></div><div>=C2=A0 =C2=A0 #+NAME: block-C</div><div>=C2=A0 =C2=A0 #+BEGIN=
_SRC python :noweb yes</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0<<block-B=
>></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0h =3D 10 * f(5) * g(2)</div><=
div>=C2=A0 =C2=A0 #+END_SRC</div><div><br></div><div>=C2=A0 =C2=A0 #+NAME: =
block-D</div><div>=C2=A0 =C2=A0 #+BEGIN_SRC python :noweb yes</div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0<<block-B>></div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0y =3D g(1)</div><div>=C2=A0 =C2=A0 #+END_SRC</div><div><br></div>=
<div>=C2=A0 =C2=A0 So, the dependency tree is this:</div><div>=C2=A0 =C2=A0=
block-A <-- block-B <-- block-C</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <-- block-D<=
/div><div><br></div><div>=C2=A0 =C2=A0 First, let's see what can be don=
e about syntax checking, completion and the possibility of viewing all the =
code at once.</div><div>=C2=A0 =C2=A0 How can we deal with the noweb refere=
nces?</div><div><br></div><div>=C2=A0 =C2=A0 Understanding what it is exact=
ly that we want may help us answer the question.</div><div>=C2=A0 =C2=A0 A =
rough list of requirements/wishes could be:</div><div><br></div><div>=C2=A0=
=C2=A0 (regardless of working in the /main buffer/ or using 'org-edit-=
src-code)</div><div>=C2=A0 =C2=A0 - (1) have an option to expand the refere=
nces into code</div><div>=C2=A0 =C2=A0 - (2) have syntax checking and compl=
etion:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0- (a) which work as if the refe=
rences were expanded (regardless of the actual reference expansion options)=
,</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0- (b) which work as if the code that=
references the block is seen as well=C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0- if included by multiple blocks (e.g. in case of ~block-B~, t=
he usage by ~block-C~ and ~block-D~), prefer the one which ran last.</div><=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0- (c) and minimize the work done.</div><div>=
<br></div><div>=C2=A0 =C2=A0 OK, all of the above can exploit the functiona=
lity of lenses, which, upon request, can produce the right /area/ based the=
preferences of the buffer which contains the /lens/.</div><div>=C2=A0 =C2=
=A0 (1) is covered: the lenses for references are recursively asked to show=
code instead of the reference.</div><div>=C2=A0 =C2=A0 (2) is also covered=
- let's discuss the details.</div><div><br></div><div>=C2=A0 =C2=A0 Wh=
at is point (2),(b) all about?</div><div>=C2=A0 =C2=A0 Why would <<bl=
ock-B>> care about who references it (i.e blocks C and D)?</div><div>=
=C2=A0 =C2=A0 Wouldn't it be enough for the syntax checker to view just=
the expanded <<block-A>> reference?</div><div>=C2=A0 =C2=A0 In=
deed, that would almost work, but there are flaws to this approach:</div><d=
iv>=C2=A0 =C2=A0 - things like /unused variable/ or /missing a closing brac=
ket/ will arise,</div><div>=C2=A0 =C2=A0 - it is unnecessarily expensive.</=
div><div><br></div><div>=C2=A0 =C2=A0 This last point is simple: why run sy=
ntax checker in ~block-A~ and ~block-B~, if one could run it in ~block-C~ a=
nd map the changes back?</div><div>=C2=A0 =C2=A0 So, the solution is to bui=
ld source block tree and run syntax checker on the end nodes, while propaga=
ting the results back to the root. If there is a fork, propagate from the o=
ne which the user ran last.</div><div>=C2=A0 =C2=A0 How exactly could this =
work in our example?</div><div>=C2=A0 =C2=A0 - Keep a buffer which views th=
e ~block-C~ lens and recursively tell the reference-lenses to show the code=
.=C2=A0</div><div>=C2=A0 =C2=A0 - Run the syntax checker there and associat=
e the output w/ each lens (recursively).</div><div>=C2=A0 =C2=A0 - For comp=
letion, propagate user input (from lenses A, B and C) to this same ~block-C=
~ buffer and deal w/ the result.</div><div><br></div><div>=C2=A0 =C2=A0 OK,=
so much for the tougher share of the problems.</div><div>=C2=A0 =C2=A0 Now=
, let's get the rest of the issues.</div><div><br></div><div>=C2=A0 =C2=
=A0 - View customization is in place: /areas/ may have various properties a=
nd can show/hide/display the begin/end ornamentation in any manner.</div><d=
iv>=C2=A0 =C2=A0 =C2=A0 (e.g. :RESULTS lens truncates lines, while the buff=
er that contains it doesn't, etc., see the [[Problems]] section)</div><=
div>=C2=A0 =C2=A0 =C2=A0 (e.g. the /area/ of the code lens is indented two =
spaces, as it's property)</div><div><br></div><div>=C2=A0 =C2=A0 - One =
could instruct a lens what to do instead of using regexp + replace.</div><d=
iv>=C2=A0 =C2=A0 =C2=A0 (e.g. continuosly update a timer)</div><div><br></d=
iv><div>=C2=A0 =C2=A0 Results sections can be shown via lenses.</div><div>=
=C2=A0 =C2=A0 Now, when editing w/ 'ord-edit-src-code, just split the s=
creen and open :RESULTS in another buffer.</div><div>=C2=A0 =C2=A0 Editing =
or running the code: everything will be kept in sync w/ the original buffer=
.</div><div>=C2=A0 =C2=A0 Some blocks may output several distinct pieces of=
data, like here:</div><div>=C2=A0 =C2=A0 <a href=3D"http://kitchingroup.ch=
eme.cmu.edu/blog/2017/01/29/ob-ipython-and-inline-figures-in-org-mode" targ=
et=3D"_blank">http://kitchingroup.cheme.cmu.edu/blog/2017/01/29/ob-ipython-=
and-inline-figures-in-org-mode</a></div><div>=C2=A0 =C2=A0 Replacing the ol=
d results could be just a matter of removing the existing lens and placing =
in a new one.</div><div>=C2=A0 =C2=A0 No need to search for the end of the =
results block.</div><div><br></div><div>=C2=A0 =C2=A0 You could select a po=
rtion of the block and narrow it.</div><div><br></div><div>=C2=A0 =C2=A0 Sh=
owing the line numbers should be a matter of running nlinum in the end node=
buffer (as w/ syntax checking), but I don't know how nlinum works to s=
ay for sure.</div><div><br></div><div>=C2=A0 =C2=A0 To be fair, some of the=
descriptions here depend on implementation possibilities, so the level of =
detail is in accordance.</div><div><br></div><div>*** Other uses</div><div>=
<br></div><div>**** Inline view of links</div><div><br></div><div>=C2=A0 =
=C2=A0 =C2=A0One could make some sort of a lens to view a part of a buffer/=
file identified by a link.</div><div>=C2=A0 =C2=A0 =C2=A0The buffer could b=
e the same buffer, an external file, anything.</div><div>=C2=A0 =C2=A0 =C2=
=A0One would not have to follow the link.</div><div>=C2=A0 =C2=A0 =C2=A0Whe=
n following the link is too cumbersome, copy pasting is prevented.</div><di=
v><br></div><div>**** Display Org documents</div><div><br></div><div>=C2=A0=
=C2=A0 =C2=A0Sections in an org document could be shown using lenses.</div=
><div>=C2=A0 =C2=A0 =C2=A0Not that I know why this would be useful (well, m=
aybe for making a [[Jupyter]] like environment).</div><div>=C2=A0 =C2=A0 =
=C2=A0But the concept is interesting.</div><div><br></div><div>**** Connect=
several source blocks</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0(I have=
proposed this on the Org-mode mailing list, but now that I think of it, a =
user-defined way as here is better.)</div><div><br></div><div>=C2=A0 =C2=A0=
=C2=A0A quite ordinary workflow is to write a block and then test the bloc=
k seperately (or use :epilogue for one-liners).</div><div>=C2=A0 =C2=A0 =C2=
=A0However, writing out a test seperately is noisy and something like this =
could be done instead:</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0#+NAME:=
square-1</div><div>=C2=A0 =C2=A0 =C2=A0#+BEGIN_SRC python</div><div>=C2=A0=
=C2=A0 =C2=A0 =C2=A0square =3D lambda x: x * x</div><div>=C2=A0 =C2=A0 =C2=
=A0#+END_SRC</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0return [square(x) for x i=
n range(10)]</div><div>=C2=A0 =C2=A0 =C2=A0#+END_SRC_TEST</div><div><br></d=
iv><div>=C2=A0 =C2=A0 =C2=A0This could be accomplished by lenses: lens-mode=
would only need to check for two adjacent blocks <name> and <name=
>-test and then wrap them in another lens, showing both like above.</div=
><div><br></div><div>=C2=A0 =C2=A0 =C2=A0Of course, some way to let org-bab=
el know what's going on would be necessary.</div><div><br></div><div>**=
Arbitrary Positioning (Window Lenses)</div><div><br></div><div>=C2=A0 =C2=
=A0Window lenses are a logical extension of buffer lenses.</div><div>=C2=A0=
=C2=A0Imagine you wanted to stack two images horizontally.</div><div>=C2=
=A0 =C2=A0Viewing two images horizontally in Emacs can be done by creating =
two windows, one image in each window.</div><div>=C2=A0 =C2=A0That's wh=
at a window lens could do, except it would be shown inside a buffer.</div><=
div><br></div><div>** Interactive Graphs</div><div><br></div><div>=C2=A0 =
=C2=A0This one is tougher than window lenses, but much more interesting.</d=
iv><div>=C2=A0 =C2=A0Say, you wanted to have an interactive graph in your b=
uffer (gnuplot, matplotlib).</div><div>=C2=A0 =C2=A0This part of the buffer=
would require it's own keybindings and all, but the area of the lens c=
ould be customized, through its properties of padding/centering and such, t=
o adorn and place the graph in a visually satisfying manner.</div><div><br>=
</div><div>=C2=A0 =C2=A0In the land where unicorns live, one would be able =
to view any graphical window inside Emacs: something that would satisfy the=
taste of even the finest gourmets of modern text editing (uGhrHrhmph).</di=
v><div><br></div><div>=C2=A0 =C2=A0Not that the buffer lenses are the bigge=
st problem here, but they just might come in useful.</div><div><br></div><d=
iv>** Fast Timer Updates (Text as an Object)</div><div><br></div><div>=C2=
=A0 =C2=A0I have already touched on this topic a bit in the context of Org-=
Mode, and now, for the sake of completeness, let's form a general chara=
cteristic of using lenses.</div><div><br></div><div>=C2=A0 =C2=A0A timer wa=
s mentioned: currently, as I understand, if you wanted to put it in your bu=
ffer and see it continuously update, you would have to use search and repla=
ce, which is not efficient.</div><div>=C2=A0 =C2=A0The solution offered was=
to use a lens: it would itself update the timer (as a /shared block/ or so=
me other direct manner).</div><div><br></div><div>=C2=A0 =C2=A0And the uses=
are more general: since /lens-mode/ tracks all the lenses, one could send =
commands to them.</div><div>=C2=A0 =C2=A0They can update independently.</di=
v><div>=C2=A0 =C2=A0So, if there are text objects, they may be accessed eas=
ily.</div><div>=C2=A0 =C2=A0This was one of the goals set in the [[Problem =
Statement]].</div><div><br></div><div>** Bug Trackers & Websites & =
Databases (Interface Building)</div><div><br></div><div>=C2=A0 =C2=A0Perhap=
s, one could work with Gitlab server or similar through lenses.</div><div><=
br></div><div>=C2=A0 =C2=A0Building an interface for a website doesn't =
seem to be out of the question either.</div><div><br></div><div>=C2=A0 =C2=
=A0Accesing a database: why not?</div><div><br></div><div>* Jupyter</div><d=
iv><br></div><div>=C2=A0 Jupyter is a reproducible research environment.</d=
iv><div>=C2=A0 <a href=3D"https://jupyter.org/" target=3D"_blank">https://j=
upyter.org/</a></div><div><br></div><div>=C2=A0 Here is what using it looks=
like:</div><div>=C2=A0 <a href=3D"http://arogozhnikov.github.io/2016/09/10=
/jupyter-features.html" target=3D"_blank">http://arogozhnikov.github.io/201=
6/09/10/jupyter-features.html</a></div><div><br></div><div>=C2=A0 Jupyter h=
as a serious flaw.</div><div>=C2=A0 It doesn't run inside Emacs.</div><=
div>=C2=A0 (Listen, all is even worse: it runs in a web browser (yes, I kno=
w about links and eww.))</div><div><br></div><div>=C2=A0 I haven't used=
it much, so let's rely on the opinion of someone who has:</div><div>=
=C2=A0 <a href=3D"https://towardsdatascience.com/5-reasons-why-jupyter-note=
books-suck-4dc201e27086" target=3D"_blank">https://towardsdatascience.com/5=
-reasons-why-jupyter-notebooks-suck-4dc201e27086</a></div><div>=C2=A0 - 1. =
It is almost impossible to enable good code versioning (files are JSON, mer=
ging is difficult)</div><div>=C2=A0 - 2. There is no IDE integration, no li=
nting, no code-style correction=C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
(quite surprising considering the popularity, isn't it?)</div><div>=C2=
=A0 - 3. Very hard to test (not the problem of Jupyter, really)</div><div>=
=C2=A0 - 4. The non-linear workflow of jupyter</div><div>=C2=A0 - 5. Jupyte=
r is bad for running long asynchronous tasks</div><div><br></div><div>=C2=
=A0 Someone also said that many snippets in Jupyter are hard to manage. I b=
elieve him.=C2=A0</div><div><br></div><div>=C2=A0 The good stuff about Jupy=
ter:</div><div>=C2=A0 - 1. easy to use / low entry barrier,</div><div>=C2=
=A0 - 2. interactive graphs,</div><div>=C2=A0 - 3. visually distinct cells.=
</div><div><br></div><div>=C2=A0 Plan: Emacs beats Jupyter, Jupyter dies an=
agonizing death, everyone starts using Emacs (the last two points may be r=
eversed).</div><div><br></div><div>=C2=A0 Say, if the stuff in the org-mode=
section and the interactive graphs (at least for matplotlib) were implemen=
ted, making some special easy mode w/ the intuitive keybindings could conve=
rt some Jupyter folks.</div><div><br></div><div>=C2=A0 The third point on c=
ells is also doable if lenses get some area customizations like padding and=
centering. And, if necessary, the whole org tree could be viewed through l=
enses.</div><div><br></div><div>=C2=A0 And org-mode can already export to h=
tml, for presentation purposes.</div><div><br></div><div>=C2=A0 In short: I=
think making a good reproducible research environment, easily usable and f=
ull of features is a good goal and could lure some people into using Emacs =
(if only superficially at first).</div><div><br></div><div>* Implementation=
</div><div><br></div><div>=C2=A0 I am not familiar with Emacs internals to =
say what's feasible of the proposed structure.</div><div>=C2=A0=C2=A0</=
div><div>=C2=A0 And the two major things in [[Mechanics]] that somewhat dep=
end on how Emacs works are:</div><div>=C2=A0 - shadowing, and</div><div>=C2=
=A0 - making two buffers (w/ different modes) share the same text (/linked =
buffers/ share the same /shared base/).</div><div>=C2=A0=C2=A0</div><div>* =
Discussion</div><div><br></div><div>=C2=A0 Nothing in this proposal is set =
in stone, feel free to change it to your liking.</div><div><br></div><div>=
=C2=A0 Some naming is probably flawed.</div><div>=C2=A0 Some structures mig=
ht be overly ambitious or unnecessary.</div><div>=C2=A0 All implementation-=
related suggestions are just suggestions.</div><div><br></div><div>=C2=A0 S=
ome explanations could be more clear.</div><div><br></div><div>=C2=A0 More =
applications couldn't hurt.</div><div><br></div><div>=C2=A0 The effects=
of the implementation are contained within the lens-mode.</div><div>=C2=A0=
Which means users should not notice the difference unless they turn on the=
lens-mode.</div><div>=C2=A0 If the implementation is undertaken, this will=
be good for testing and integration.</div><div><br></div><div>=C2=A0 Overa=
ll, I think the applications might be very well worth the effort.</div><div=
>=C2=A0 Especially for Org-mode.</div></div></div>
--00000000000030860005874af70f--
--00000000000030860305874af711
Content-Type: application/octet-stream; name="buffer-lenses.org"
Content-Disposition: attachment; filename="buffer-lenses.org"
Content-Transfer-Encoding: base64
Content-ID: <f_juvk2kea0>
X-Attachment-Id: f_juvk2kea0
IytUSVRMRTogW1Byb3Bvc2FsXSBCdWZmZXIgTGVuc2VzIGFuZCB0aGUgQ2FzZSBvZiBPcmctTW9k
ZSAoYWxzbywgSnVweXRlcikgCiMrQVVUSE9SOiBEbWl0cmlpIEtvcm9iZWluaWtvdgojK0VNQUlM
OiBkaW0xMjEya0BnbWFpbC5jb20KCipTVU1NQVJZKiAvQnVmZmVyIGxlbnMvIGlzIGFuIG9iamVj
dCBpbnNpZGUgYSBidWZmZXIgd2hpY2ggcHJvdmlkZXMgdGhhdCBidWZmZXIgdGhlIGxpbmVzIHRv
IGRpc3BsYXkgYW5kIHdoaWNoIGlzIGxpbmtlZCB0byBhbm90aGVyIGJ1ZmZlciAoZnJvbSB3aGlj
aCBpdCBjYW4gdGFrZSBhbmQgcHJvY2VzcyBkYXRhKSwgd2hpbGUgbWFwcGluZyB0aGUgaW5wdXQg
YmFjayB0byB0aGF0IGxpbmtlZCBidWZmZXIuIC9Db21wb3NpdGUgbGVucy8gaXMgdGhlIGV4dGVu
c2lvbiBvZiB0aGlzIGlkZWEgdG8gaW50ZXJmYWNlIGFueSBzb3VyY2VzIG9mIGRhdGEgKGZvciB3
aGljaCB0ZXh0IGludGVyZmFjZSBpcyBwb3NzaWJsZSkuIFNvbWUgT3JnLW1vZGUgcHJvYmxlbXMg
YXJlIGFkZHJlc3NlZCwgcGFydGljdWxhcmx5IHRob3NlIGNvbmNlcm5pbmcgc291cmNlIGJsb2Nr
IGVkaXRpbmcgYW5kIHZpZXdpbmcsIHN5bnRheCBjaGVja2luZywgY29tcGxldGlvbiBhbmQgcmVm
ZXJlbmNlIGV4cGFuc2lvbi4KClRoaXMgaXMgYSBwcm9wb3NhbCBmb3IgL2xlbnNlcy8uIEhlcmVi
eSwgSSBvdXRsaW5lIHRoZSBnZW5lcmFsIGlkZWEsIHRoZSBwcm9ibGVtcyBpdCBzb2x2ZXMsIHRo
ZSBmZWF0dXJlcyBpdCBpbnRyb2R1Y2VzIGFuZCBpdHMgdXNlIGNhc2VzLgoKKiBQcm9ibGVtIFN0
YXRlbWVudAoKICBUaGUgcHJvYmxlbSBpcyB0aGF0IGl0J3MgaGFyZCB0byB0cmVhdCBzb21lIGFy
ZWEgaW5zaWRlIGEgYnVmZmVyCiAgLSBhcyBpZiBpdCByYW4gaW4gYSBkaWZmZXJlbnQgYnVmZmVy
LCB3aXRoIGl0cyBvd24gc2V0IG9mIG1vZGVzLAogIC0gYXMgYW4gb2JqZWN0IHcvIGRpc3RpbmN0
IHByb3BlcnRpZXMgYW5kIGludGVyZmFjZS4KCiAgVGhpcyBwcm9wb3NhbCBpcyBub3QgZHJhd24g
b3V0IG9mIHRoaW4gYWlyOiB0aGUgYmlnZ2VyIHBhcnQgb2YgaXQgaXMgYWJvdXQgYXBwbGljYXRp
b25zCiAgKGZvciBhbiBpbW1lZGlhdGUgZXhhbXBsZSwgeW91IGNvdWxkIHRoaW5rIG9mIGFuIG9y
ZyBtb2RlIHNvdXJjZSBibG9jay4pCgoqIE1lY2hhbmljcwoKICBUaGUgaWRlYSBpcyB0byBlbWJl
ZCBhIGJ1ZmZlciBpbnNpZGUgYW5vdGhlciBidWZmZXIuCiAgSGF2ZSBhIGJsb2NrIG9mIHRleHQs
IGEgc2VudGVuY2UsIGEgdGFibGUsIGEgd29yZCAtLSBzb21lIC9hcmVhLyBpbiB5b3VyIGJ1ZmZl
ciAtLSBiZWhhdmUgYXMgaWYgaXQgd2VyZSBpbiBzb21lIG90aGVyIGRpc3RpbmN0IGJ1ZmZlciwg
d2hpY2ggaGFzIGl0J3Mgb3duIG1vZGVzIGFuZCBrZXliaW5kaW5ncy4KCiAgV2hhdCdzIHByb3Bv
c2VkIGhlcmUgaXMgdG8gZG8gc3VjaCBhIHRyaWNrIHVzaW5nIGEgL2J1ZmZlciBsZW5zLy4KCiAg
Rmlyc3QsIGxldCdzIGZvcm0gYSBwcmVsaW1pbmFyeSwgcHJvdG90eXBlIGRlZmluaXRpb24gKGl0
IHdpbGwgYmUgY2hhbmdlZCBsYXRlciBpbiB0aGlzIHNlY3Rpb24pLgogIEEgL2J1ZmZlciBsZW5z
LyBpcyBhbiBvYmplY3Qgd2hpY2ggdmlld3MgaXRzIC9saW5rZWQgYnVmZmVyLyBhbmQgdGhpcyBi
dWZmZXIgY2FuIGJlIHZpZXdlZCB1c2luZyAvYXJlYXMvLgogIEFuIC9hcmVhLyBpcyBhIHRleHQg
b2JqZWN0LCB3aG9zZSBwcm9wZXJ0aWVzIGFuZCBjb250ZW50cyBhcmUgY29udHJvbGxlZCBieSBp
dHMgL2xlbnMvLgogIFRoZSAvbGlua2VkIGJ1ZmZlci8gaXMgKGNvbmNlcHR1YWxseSkganVzdCBh
IHJlZ3VsYXIgYnVmZmVyLCB3aG9zZSBjb250ZW50cyB0aGUgbGVucyBjYW4gdXNlIHRvIGNvbnRy
b2wgaXRzIC9hcmVhLy4KCiAgU3VwcG9zZSB5b3UgaGF2ZSBvcGVuZWQgc29tZSBidWZmZXIgLSBj
YWxsIGl0IGEgL1dvcmtpbmcgYnVmZmVyLyBvciAvV0IvLgogIC9MZW5zLW1vZGUvIGlzIHRoZSBt
b2RlIHJlc3BvbnNpYmxlIGZvciBhbGwgdGhlIC9sZW5zZXMvIGluc2lkZSB0aGUgL3dvcmtpbmcg
YnVmZmVyLy4KCiAgVGhlIGdvYWxzIG9mIHRoZSAvbGVucy1tb2RlLyBhcmU6CiAgLSBJZGVudGlm
eSwgdHJhY2sgYW5kIGhhbmRsZSBhbGwgdGhlIC9sZW5zZXMvIGluIHRoZSBidWZmZXIuCiAgLSBE
aXNwbGF5IGVhY2ggL2FyZWEvIGFjY29yZGluZyB0byB0aGUgb3B0aW9ucyBvZiBpdHMgL2xlbnMv
IGFuZCBpdHMgb3duIG9wdGlvbnMuCiAgLSBMZXQgdGhlIHVzZXIgcmVsYXkgdGhlIGNvbnRyb2wv
aW5wdXQgdG8gYSAvbGVucy8gKHNheSwgd2hlbiB0aGUgY3Vyc29yIGlzIGluIGl0cyAvYXJlYS8p
LCB3aGljaCB3b3VsZCBpbiB0dXJuIHJlbGF5IHRoZSBpbnB1dCB0byBpdHMgL2xpbmtlZCBidWZm
ZXIvIGFzIGlmIGl0IHdlcmUgaW4gaXRzIG93biB3aW5kb3cuIEVpdGhlciBhbGwgdXNlciBhY3Rp
b25zIGNvdWxkIGJlIHJlbGF5ZWQgb3IganVzdCBhIGRlZmluZWQgc3Vic2V0IChlLmcuIHNwZWNp
ZmljIGtleWJpbmRpbmdzIG9yIGNvbW1hbmRzKS4KICAtIExldCB0aGUgdXNlciBkZWZpbmUgc3Bl
Y2lmaWMgbWFwcyBhbmQgdXNlciBpbnB1dCBoYW5kbGluZyByb3V0aW5lcyBmb3IgYW55IHNwZWNp
ZmljIC9sZW5zLyBvciBmb3IgYW55IHR5cGUgb2YgL2xlbnMvLCB3aGVyZSB0eXBlIGlzIGRlZHVj
ZWQgZnJvbSB0aGUgcHJvcGVydGllcyBvZiB0aGUgbGVucyAoYnkgYSB1c2VyLWRlZmluZWQgZnVu
Y3Rpb24pLgogIC0gUHJvcGFnYXRlIHNhdmUgY29tbWFuZHMgdG8gdGhlIGxlbnNlcy4KICAgICh3
aGljaCBtYXkgc2lnbmFsIHRoZSAvbW9kZWwvIHRvIGFkYXB0IHRoZSBjaGFuZ2VzIGluIHRoZSAv
c2hhcmVkIGJhc2UvOiB0aGVzZSB3aWxsIGJlIGRpc2N1c3NlZCBzaG9ydGx5KS4KCiAgV2UgY291
bGQgYWxzbyBjb21lIHVwIHdpdGggYSBnZW5lcmFsIGRlc2NyaXB0aW9uIG9mIGEgL2xlbnMvLgog
IENhbGwgaXQgYSAvY29tcG9zaXRlIGxlbnMvLgogIAogIEEgL2NvbXBvc2l0ZSBsZW5zLyBjb3Vs
ZCBjb25zaXN0IG9mIHRoZXNlIHBhcnRzOiAvbW9kZWwvLCAvcmVwcmVzZW50YXRpb24vLCAvbGlu
a2VkIGJ1ZmZlci8sIC9zaGFyZWQgYmFzZS8sIC9zaGFyZWQgYmxvY2svLCAvdmlldy8gYW5kIC9j
b250cm9sbGVyLy4KICBUaGlzIGlzIGFsbW9zdCBsaWtlIE1WQy4KICBJIGZpbmQgaXQgc29tZXdo
YXQgbW9yZSBpbnR1aXRpdmUgdG8gdXNlIHRoZSB0ZXJtIC9hcmVhLyBpbnN0ZWFkIG9mIC92aWV3
Lywgc28gbGV0J3MgZG8gdGhhdCAoYXQgbGVhc3QgZm9yIG5vdykuCgogIC9Nb2RlbC8gaXMgZGF0
YSAoc3RyaW5ncywgYnVmZmVycywgZGF0YWJhc2VzLCBhbnl0aGluZykuCiAgL1JlcHJlc2VudGF0
aW9uLyBpcyB0aGUgZGVzY3JpcHRpb24gb2YgaG93IHRvIGJ1aWxkIC9zaGFyZWQgYmxvY2tzLyBh
bmQgL3NoYXJlZCBiYXNlcy8gdXNpbmcgdGhlIC9tb2RlbC8uCiAgL1NoYXJlZCBiYXNlLyBjb25z
aXN0cyBvZiAvc2hhcmVkIGJsb2Nrcy8uCiAgRWFjaCAvc2hhcmVkIGJsb2NrLyBpcyBjb25zdHJ1
Y3RlZCAodGhyb3VnaCByZXByZXNlbnRhdGlvbikgdG8gYmU6CiAgLSBlaXRoZXIgcGxhaW4gdGV4
dCBvcgogIC0gYSBsZW5zIChzdWNoIGFzIC9idWZmZXItbGVucy8pIChoZW5jZSB0aGUgbmFtZSAv
Y29tcG9zaXRlLWxlbnMvIC0gaXQgbWFrZXMgdXNlIG9mIG90aGVyIGxlbnNlcykuCiAgL0xpbmtl
ZCBidWZmZXIvIGlzIGEgYnVmZmVyIHdoaWNoIHZpZXdzIGEgL3NoYXJlZCBiYXNlLy4gVGhpcyBi
dWZmZXIgaXMgbGlrZSBhIHJlZ3VsYXIgYnVmZmVyIChydW5zIGl0cyBvd24gbW9kZXMsIGV0Yy4p
LgogIC9BcmVhLyBpcyBhc3NvY2lhdGVkIHcvIG9uZSAvbGlua2VkIGJ1ZmZlci8gYW5kIGlzIGl0
cyBjb250ZW50cyArIHNvbWUgcHJvcGVydGllcy4KICAvQ29udHJvbGxlci8gbWFwcyB0aGUgdXNl
ciBpbnB1dCB0byB0aGUgL2xpbmtlZCBidWZmZXIvIG9mIHRoZSAvYXJlYS8uIAoKICBHZXQgYSBs
b2FkIG9mIHRoaXM6CiAgVGhlIC9saW5rZWQgYnVmZmVyLyB2aWV3cyBhIC9zaGFyZWQgYmFzZS8s
IHdoaWNoIGNvbnNpc3RzIG9mIC9zaGFyZWQgYmxvY2tzLywgd2hpY2ggYXJlIGVpdGhlciBwbGFp
biB0ZXh0IG9yIG90aGVyIGxlbnNlcywgYmVpbmcgZGVzY3JpYmVkIGJ5IHRoZSAvcmVwcmVzZW50
YXRpb24vIG9mIHRoZSAvbW9kZWwvLCB3aGljaCBtYXkgYmUgdWx0aW1hdGVseSBhY2Nlc3NlZCB2
aWEgdGhlIC9jb250cm9sbGVyLywgd2hpY2ggbWFwcyB0aGUgdXNlciBpbnB1dCBmcm9tIHRoZSAv
YXJlYS8uCgogIFBsYWluIHRleHQgZm9yIC9zaGFyZWQgYmxvY2tzLyBpcyBmb3Igc3R1ZmYgdGhh
dCBkb2Vzbid0IG5lZWQgdG8gYmUga2VwdCBpbiB0aGUgL21vZGVsLyAoc2F5LCBmb3IgZGVsaW1p
dGVycyB3aGljaCBpZGVudGlmeSB0aGUgL2xlbnMvIGFzIHN1Y2ggaW4gdGhlIC93b3JraW5nIGJ1
ZmZlci8sIHdoZXJlIHRoZXkgcmVzaWRlIGJlZm9yZSB0aGUgL2xlbnMtbW9kZS8gcnVucykuCgog
IFRoZSBnb2FsIG9mIHRoZXNlIGFic3RyYWN0aW9ucyBpcyB0byBhbGxvdyBoYXZpbmcKICAtIG11
bHRpcGxlIC9hcmVhcy8sIAogIC0gZWFjaCBoYXZpbmcgYSBkZWRpY2F0ZWQgYnVmZmVyICh3LyBk
aXN0aW5jdCBtb2RlcyBhbmQgcHJvcGVydGllcyksCiAgICAtIHdoaWNoIHNoYXJlIHRoZSBzYW1l
IHRleHR1YWwgZGF0YSAodGhlIC9zaGFyZWQgYmFzZS8pLCAKICAgICAgLSB3aGljaCBpcyBjb21w
aWxlZCBmcm9tIHBsYWluIHRleHQgb3Igb3RoZXIgbGVuc2VzICgvc2hhcmVkIGJsb2Nrcy8pLAog
ICAgICAgIC0gd2hpY2ggaGF2ZSB0aGVpciBvd24gaW5wdXQgaW50ZXJmYWNlIChlLmcuIC9idWZm
ZXItbGVuc2VzLykuCgogIFNpbmNlIHRoZSBkYXRhIGlzIHNoYXJlZCBiZXR3ZWVuIHRoZSAvYXJl
YXMvICh0aHJvdWdoIC9zaGFyZWQgYmFzZS8pLCBpZiB0aGUgdXNlciBtYWtlcyBzb21lIGNoYW5n
ZXMgaW4gb25lIC9hcmVhLywgdGhlIGNoYW5nZXMgaW1tZWRpYXRlbHkgYXBwZWFyIGluIGFsbCBv
dGhlciAvYXJlYXMvLgoKICBBcyBzdWNoLCBhIC9idWZmZXIgbGVucy8gaXMgYSBzcGVjaWFsIGNh
c2Ugb2YgYSAvY29tcG9zaXRlIGxlbnMvLCBleGNlcHQgCiAgLSBpdCBoYXMgbm8gL21vZGVsLyAo
YW5kIHNvLCBuZWVkcyBubyAvcmVwcmVzZW50YXRpb24vKSwgCiAgLSBpdHMgL3NoYXJlZCBiYXNl
LyBpcyBhIHNpbmdsZSBidWZmZXIuCiAgTm90ZSwgdGhpcyBhcHByb2FjaCBkaWZmZXJzIGZyb20g
d2hhdCB3YXMgZGVzY3JpYmVkIGluIHRoZSBiZWdpbm5pbmcgb2YgdGhpcyBzZWN0aW9uOiBub3cg
dGhlcmUgY2FuIGJlIG11bHRpcGxlIC9saW5rZWQgYnVmZmVycy8sIGFsbCBzaGFyaW5nIG9uZSAv
c2hhcmVkIGJhc2UvLgogIFRoaXMgYXBwcm9hY2ggaXMgbW9yZSBwb3dlcmZ1bDogaXQgYWxsb3dz
IG11bHRpcGxlIC9hcmVhcy8gdG8gYmVoYXZlIGRpZmZlcmVudGx5IGFuZCByZWR1Y2VzIGRhdGEg
ZHVwbGljYXRpb24uCgogIE9uZSBwb2ludCB3b3J0aCBhdHRlbnRpb24gaXMgdGhhdCBhbiAvYXJl
YS8gc2hvdWxkIGFsc28gaGF2ZSBpdHMgb3duIHNldCBvZiBwcm9wZXJ0aWVzLCBzdWNoIGFzIGN1
c3RvbSBwYWRkaW5nLCBhbGlnbm1lbnQgKGNlbnRlciwgbGVmdCwgcmlnaHQpLCBldGMuCiAgU3Vj
aCBwcm9wZXJ0aWVzIGNvdWxkIGJlIGFyYml0cmFyeSBhcyBsb25nIGFzIG1hcHBpbmcgdGhlIHVz
ZXIgaW5wdXQgYmFjayB0byB0aGUgL2xpbmtlZCBidWZmZXIvIGNhbiBiZSBwZXJmb3JtZWQuCiAg
VGhpcyB3aWxsIGFsbG93IHZpc3VhbCBjdXN0b21pemF0aW9ucy4KCiAgL1JlcHJlc2VudGF0aW9u
cy8gc2hvdWxkIGJlIG1vZGlmaWFibGUgKHRocm91Z2ggc29tZSBpbnRlcmZhY2UpLgoKICBUaGUg
dXNhZ2Ugb2YgL3NoYXJlZCBibG9ja3MvIGFib3ZlIGlzIHJlYWxseSBmb3IgZXhwbGFuYXRvcnkg
cHVycG9zZXMgYW5kLCBwb3NzaWJseSwgbGVzcyBvZiBhIG5lY2Vzc2l0eSAoYnV0IG1heSBpbmRl
ZWQgY29tZSBpbiB1c2VmdWwgd2hlbiBtdWx0aXBsZSByZXByZXNlbnRhdGlvbnMpLgoKICBTYXZp
bmcgaXMgYWxzbyBhbiBpbXBvcnRhbnQgdGhpbmcgdG8gZGlzY3Vzcy4KICBUaGUgbGVucyBzaG91
bGQgYmUgYWJsZSB0byBmb3JtIGFuIGFyZWEsIHdoZXJlIHRoZSBkaXNwbGF5ZWQgdGV4dCAvc2hh
ZG93cy8gdGhlIHRleHQgd2hpY2ggYWN0dWFsbHkgbmVlZHMgdG8gYmUgc2F2ZWQuCiAgVGhpcyBp
cyBkb2FibGU6IGluIG9yZy1tb2RlLCB3aGVuIHlvdSBmb2xkIGEgdGl0bGUsIHRoZSBlbGxpcHNp
cyBoYXZlIGFyYml0cmFyeSBkYXRhIGhpZGRlbiBpbiB0aGVpciBwbGFjZS4KICBCdXQgdGhlIHBv
c3NpYmlsaXRpZXMgYXJlOgogIC0gdXNlIGZhY2VzL2ZvbGRpbmcgb3Igc3VjaCAoSSBhbSBub3Qg
dG9vIGZhbWlsaWFyIHcvIHRoZSBhc3NvY2lhdGVkIHRlY2huaWNhbGl0aWVzLCBidXQgSSB0aGlu
ayB0aGV5IGNvdWxkIHdvcmspLCBvcgogIC0gKHdoYXQgc2VlbXMgbGlrZSB0aGUgYmV0dGVyIHNv
bHV0aW9uKSwgdGhlIHNhdmUgb3BlcmF0aW9uIGNvdWxkIGdyYWIgdGhlIC9zaGFyZWQgYmFzZS8g
d2hpY2ggdGhlIC9hcmVhLyB1c2VzIChvciBxdWVyeSB0aGUgbGVucyBmb3Igd2hhdCB0byBzYXZl
KS4KCiAgQW5kIGFzIGZvciB0aGUgdW5kbyBiZWhhdmlvciwgd2hhdCdzIGNsZWFyIGlzIHRoYXQg
dGhlIGNoYW5nZXMgd2lsbCBuZWVkIHRvIGJlIHRyYWNrZWQgdG8gdGhlIC9zaGFyZWQgYmFzZS8g
b2YgYWxsIC9hcmVhcy8gb2YgdGhlIHNhbWUgL3JlcHJlc2VudGF0aW9uLy4KCiogUHJhY3RpY2Fs
IEFwcGxpY2F0aW9ucwoKKiogT3JnLW1vZGUKCiAgT3JnLW1vZGUsIGEgZGlzdGluY3QgcGxhbmVz
Y2FwZSBpbiB0aGUgRW1hY3MgbXVsdGl2ZXJzZSwgbWlnaHQgYmUgdGhlIG1vZGUgdG8gYmVuZWZp
dCB0aGUgbW9zdCBmcm9tIHRoZSB1c2Ugb2YgbGVuc2VzLgoKKioqIDNEIFRhYmxlcwoKICAgIFN1
cHBvc2UgeW91IGhhdmUgdGhyZWUgdGFibGU6CgogICAgfCAwIHwgMCB8IDAgfAogICAgfCAwIHwg
QSB8IDAgfAogICAgfCAwIHwgMCB8IDAgfAoKICAgIHwgMCB8IEIgfCAwIHwKICAgIHwgQiB8IDAg
fCBCIHwKICAgIHwgMCB8IEIgfCAwIHwKCiAgICB8IEMgfCAwIHwgQyB8CiAgICB8IDAgfCAwIHwg
MCB8CiAgICB8IEMgfCAwIHwgQyB8CgogICAgU2F5LCB0aGVzZSB0YWJsZXMgYXJlIGp1c3QgdGhl
IGxheWVycyBvZiBhIDN4MyBjdWJlLgogICAgWW91IG1pZ2h0IHdhbnQgdG8gdmlldyB0aGlzIGN1
YmUgYXMgYSBkaXN0aW5jdCBlbnRpdHk6CiAgICAKICAgIC0qKkxBWUVSIDEqKi0KICAgIHwgMCB8
IDAgfCAwIHwKICAgIHwgMCB8IEEgfCAwIHwKICAgIHwgMCB8IDAgfCAwIHwKCiAgICBZb3UgY291
bGQgdXNlIGEgY29tcG9zaXRlIGxlbnMgZm9yIHRoaXMuCiAgICBUaGUgL21vZGVsLyB3b3VsZCBi
ZSB0aHJlZSBidWZmZXJzLCBvbmUgdGFibGUgaW4gZWFjaC4KICAgIFRoZSAvcmVwcmVzZW50YXRp
b24vIGRlc2NyaWJlcyB0aGUgL3ZpZXcvIGFzOgogICAgLSBhcyBhIHN0cmluZyAoIi0qKkxBWUVS
IDEqKi0iKSBhbmQKICAgIC0gYSAvYnVmZmVyIGxlbnMvIGxpbmtpbmcgb25lIG9mIHRoZSB0aHJl
ZSBidWZmZXJzIGluIHRoZSAvbW9kZWwvLgoKICAgIE9uZSBjb3VsZCBjb21tYW5kIHRoZSBsZW5z
IHRvIHN3aXRjaCB0byB0aGUgbmV4dCBsYXllcjoganVzdCBjaGFuZ2UgdGhlIC9yZXByZXNlbnRh
dGlvbi8uCgogICAgV2hlbiB0aGUgY3Vyc29yIGlzIGluIHRoZSAvYXJlYS8sIHRoZSB1c2VyIGlu
cHV0IG5vdyBpcyBoYW5kbGVkIGluIGl0cyAvbGlua2VkIGJ1ZmZlci8uCiAgICBXaGVuIHRoZSBj
dXJzb3IgaXMgZGlyZWN0bHkgb24gdGhlIHRhYmxlLCB0aGUgaW5wdXQgaXMgcmVsYXllZCB0byB0
aGUgL2J1ZmZlciBsZW5zLyBvZiB0aGUgdGFibGUsIHdob3NlIC9hcmVhJ3MvIC9saW5rZWQgYnVm
ZmVyLyBoYXMgb3JnLW1vZGUgcnVubmluZy4KCiAgICBUaGUgdGFibGVzIGFyZSBpZGVudGlmaWVk
IGFuZCByZXBsYWNlZCB3aGVuIHRoZSAvbGVucy1tb2RlLyBydW5zIGZvciB0aGUgZmlyc3QgdGlt
ZS4KICAgIEJ1dCB3aGF0IHNob3VsZCBoYXBwZW4gd2hlbiB0aGUgdXNlciBzYXZlcyB0aGUgYnVm
ZmVyPwogICAgV2Ugd2FudCB0byBzYXZlIGFsbCB0aHJlZSB0YWJsZXMsIG5vdCBqdXN0IHRoZSBv
bmUgd2hpY2ggaGFwcGVucyB0byBiZSBjdXJyZW50bHkgdmlld2VkLgogICAgVGhlIHBvc3NpYmxl
IHNvbHV0aW9uLCBhcyBkaXNjdXNzZWQgaW4gW1tNZWNoYW5pY3NdXSwgY291bGQgYmUgdG8gL3No
YWRvdy8gdGhlIHRocmVlIHRhYmxlcy4KCiAgICBPZiBjb3Vyc2UsIHRhYmxlcyBjYW4gYmUgZXhw
bG9yZWQgaW4gYW55IHdheSwgbm90IGp1c3QgbGF5ZXIgYnkgbGF5ZXIuCiAgICBodHRwczovL2Vu
Lndpa2lwZWRpYS5vcmcvd2lraS9PbmxpbmVfYW5hbHl0aWNhbF9wcm9jZXNzaW5nCgogICAgU28s
IHRvIGdpdmUgYSBwZXJzcGVjdGl2ZSBvbiBhbGwgdGhpczogYSB0YWJsZSBiZWNvbWVzIGFuIG9i
amVjdCBhbmQgdGhlIG1vZGVzIHRoYXQgcnVuIGluIHRoZSAvbGlua2VkIGJ1ZmZlci8gZm9ybSB0
aGUgaW50ZXJmYWNlIHRvIHRoaXMgb2JqZWN0LgogICAgQW5kLCByZWFsbHksIGEgdGFibGUgaXMg
YSB0YWJsZSBmb3IgZXhhbXBsZSBwdXJwb3NlcywgYW5kLCBvYnZpb3VzbHksIGFueXRoaW5nIGVs
c2UgY291bGQgYmUgaW4gaXRzIHBsYWNlLgoKKioqIENvZGUgQmxvY2tzIGFuZCBSZXN1bHRzOiBF
ZGl0aW5nIGFuZCBWaWV3aW5nCgogICAgSGVyZSBJIHdpbGwgZmlyc3QgZGlzY3VzcyBhbGwgdGhl
IHJlbGV2YW50IHByb2JsZW1zIGFuZCB0aGVuIHByb3Bvc2UgYSBzb2x1dGlvbi4KCioqKiogUHJv
YmxlbXMKKioqKiogRWRpdGluZyBTb3VyY2UgQmxvY2tzIFswLzVdCgogICAgIENvbnNpZGVyIHRo
aXMgYmxvY2s6CgogICAgICMrQkVHSU5fU1JDIGVsaXNwCiAgICAgICAoZGVmdW4gc3RlcCAoeCBs
KQogICAgICAgICAoY2FzZSAoPCB4IGwpIDAKICAgICAgICAgICAgICAgdCAxKSkKICAgICAjK0VO
RF9TUkMKCiAgICAgRmlyc3QsICduZXdsaW5lLWFuZC1pbmRlbnQgZG9lc24ndCBpbmRlbnQgdGhl
IGNvZGUgY29ycmVjdGx5LgogICAgIEl0IHNpbXBseSBzZWVtcyB0byBsb29rIGF0IHRoZSBmaXJz
dCBzeW1ib2wgb2YgdGhlIHByZXZpb3VzIGxpbmU6CgogICAgIC0gWyBdIHN1cHBvcnQgZm9yIG1v
ZGUtc3BlY2lmaWMgZWRpdGluZyBmZWF0dXJlcyBpcyBsaW1pdGVkLAogICAgIC0gWyBdIHRoZSBt
b2RlLXNwZWNpZmljIGludGVyYWN0aXZlIGZlYXR1cmVzIChzYXksIGtleWJpbmRpbmdzKSBhcmUg
ZGlzcmVnYXJkZWQuCgogICAgIFVzaW5nICdvcmctZWRpdC1zcmMtY29kZSBoZWxwcywgYnV0IGl0
IGlzIGEgaGFzc2xlLgoKICAgICBXaGF0J3MgbW9yZSwgZXZlcnkgdGltZSAnb3JnLWVkaXQtc3Jj
LWNvZGUgaXMgdXNlZDoKCiAgICAgLSBbIF0gYSBuZXcgYnVmZmVyIGlzIGNyZWF0ZWQsIHdoaWNo
IGltcGxpZXMgaW5pdGlhbGl6YXRpb24gb2YgdGhlIGJ1ZmZlciBtb2RlcywKICAgICAtIFsgXSB0
aGUgY2hhbmdlcyBuZWVkIHRvIGJlIHdyaXR0ZW4gYmFjay4KCiAgICAgVGhlIGlzc3VlcyB3aXRo
IHRoZSBwb2ludHMgYWJvdmUgY2FuIGJlIGRlbW9uc3RyYXRlZCBieSBvYnNlcnZpbmcgdGhlIGJ1
Z3Mgdy8gJ29yZy1jb21tZW50LWR3aW06CgogICAgIC0gdGhlIHNjcmVlbiBpcyBzY3JvbGxlZCB0
byBzaG93IHRoZSBmaXJzdCBsaW5lIG9mIHRoZSBibG9jaywKICAgICAtIGluIHZpc3VhbCBsaW5l
IG1vZGUsIHRoZSBjdXJzb3IganVtcHMgdG8gdGhlIGJlZ2lubmluZyBvZiB0aGUgYmxvY2suCgog
ICAgIE1hcmtzIGFyZSB0aHJvd24gYmFjayB0byB0aGUgYmVnaW5uaW5nIG9mIHRoZSBibG9jayAt
LSBmb3IgdGhlIHNhbWUgcmVhc29uLgoKICAgICBBbHNvLCB0aGUgbGFyZ2VyIHRoZSBjb2RlIGJs
b2NrLCB0aGUgbW9yZSB3b3JrIGhhcyB0byBiZSBkb25lLCBzbywKCiAgICAgLSBbIF0gc29tZSBs
YWcgaXMgdG8gYmUgZXhwZWN0ZWQuCgogICAgIChCdWcgcmVwb3J0IGZvciB0aGUgY29tbWVudGlu
ZyBiZWhhdmlvcjogaHR0cHM6L3NkZWJidWdzLmdudS5vcmcvY2dpL2J1Z3JlcG9ydC5jZ2k/YnVn
PWJ1ZyUyMzM0OTc3KQoKKioqKiogVmlld2luZyBTb3VyY2UgQmxvY2tzIGFuZCBSZXN1bHRzIFsw
LzZdCgogICAgIENvbnNpZGVyIHRoZXNlIHR3byBibG9ja3M6CgogICAgICMrTkFNRTogc3ludGF4
LXRhbmdsaW5nLWNvbW1lbnRpbmcKICAgICAjK0JFR0lOX1NSQyBlbGlzcAogICAgICAgKGRlZnVu
IHN0ZXAgKHggbCkKICAgICAgICAgKGNhc2UgKDwgeCBsKSAwCiAgICAgICAgICAgICAgIHQgMSkp
CiAgICAgIytFTkRfU1JDCgogICAgICMrQkVHSU5fU1JDIGVsaXNwIDpub3dlYiB5ZXMKICAgICAg
IDw8c3ludGF4LXRhbmdsaW5nLWNvbW1lbnRpbmc+PgogICAgICAgKHN0ZXAgIndyb25nIGFyZ3Vt
ZW50IikKICAgICAjK0VORF9TUkMKCiAgICAgRmlyc3QgYW5kIGZvcmVtb3N0LCB0aGVyZSBpcyBu
byBzeW50YXggY2hlY2tpbmcgYW5kIG5laXRoZXIgaXMgdGhlcmUgY29tcGxldGlvbjoKCiAgICAg
LSBbIF0gd2hhdCBjYW4gYmUgZWFzaWx5IGRvbmUgaW4gYSBzZXBhcmF0ZSBidWZmZXIgdy8gc29t
ZSBtb2RlIG9uIGNhbid0IGJlIGRvbmUgaW5saW5lLgoKICAgICBBbmQgdXNpbmcgJ29yZy1lZGl0
LXNyYy1jb2RlIGlzIG5vdCBtdWNoIG9mIGEgcmVsaWVmIGFzIHRoZSBzeW50YXggY2hlY2tlciBh
bmQgdGhlIGNvbXBsZXRlciBoYXZlIAoKICAgICAtIFsgXSBubyB3YXkgb2YgZGVhbGluZyB3aXRo
IHJlZmVyZW5jZXMgdG8gcHJvY2VzcyBjb2RlIGFzIGlmIHRhbmdsZWQgaW4uCgogICAgIFRoZSBj
b25zZXF1ZW5jZXMgb2YgdGhpcyBwb2ludCBhcmUgZmFydGhlciB0aGFuIHRob3NlIG9mIHRoZSBt
aXNzaW5nIHN5bnRheCBjaGVja2luZyBvciBjb21wbGV0aW9uOgogICAgIHNvbWV0aW1lcywgbG9v
a2luZyBhdCBjb2RlIGFzIGEgY29oZXJlbnQgd2hvbGUsIGFuZCBub3QgYSBzZXJpZXMgb2YgZGlz
Y29ubmVjdCBzbmlwcGV0cywgaXMgd2hhdCB0aGUgcHJvZ3JhbW1lciBuZWVkcy4KCiAgICAgSW4g
cHJpbmNpcGxlLCBpdCBjb3VsZCBiZSBwb3NzaWJsZSBmb3IgJ29yZy1lZGl0LXNvdXJjZS1jb2Rl
IHRvIHN1YnN0aXR1dGUgY29kZSBmb3IgZWFjaCByZWZlcmVuY2UsIGJ1dCB0aGlzIGlzIHByb2Js
ZW1hdGljIGR1ZSB0byB0aGUgcG9pbnRzIG1hZGUgaW4gW1tFZGl0aW5nIFNvdXJjZSBCbG9ja3Nd
XSBzZWN0aW9uLgoKICAgICBOZXh0LCB3aGVuIHNvbWUgZmFpbGVkIGFzc2VydGlvbiBvciBhIHJ1
bnRpbWUgZXJyb3IgdGVsbHMgeW91IGEgbGluZSBudW1iZXIsIGxvb2tpbmcgZm9yIGl0IGlzIHRv
dWdoLgogICAgIEJ1dCB0aGVyZSBpcyBubyB3YXkgdG8gc2hvdyBsaW5lIG51bWJlcnMgKGFic29s
dXRlLCBhcyBpZiByZWZlcmVuY2VzIHdlcmUgZXhwYW5kZWQpLgogICAgIE9yIHN1cHBvc2UgYSBz
b3VyY2UgYmxvY2sgcHJvZHVjZXMgYSBodWdlIHRhYmxlLgogICAgIFRoaXMgbWVhbnMgeW91IHdp
bGwgd2FudCB0byB0cnVuY2F0ZSBsaW5lcy4KICAgICBCdXQgbWF5YmUgdGhhdCdzIG5vdCB3aGF0
IHlvdSB3YW50IGZvciB0aGUgcmVzdCBvZiB5b3VyIGJ1ZmZlci4KICAgICBUaGVzZSBib2lsIGRv
d24gdG86CgogICAgIC0gWyBdIGNhbid0IHZpZXcgYSBzcGVjaWZpYyBhcmVhIG9mIGEgYnVmZmVy
LCBsaWtlIDpyZXN1bHRzIG9yIGEgc291cmNlIGJsb2NrLCBhcyBpZiBpdCB3ZXJlIGluIGFub3Ro
ZXIgYnVmZmVyLgoKICAgICBPbmUgb3RoZXIgbmljZSBmZWF0dXJlIHRvIHNlZSB3b3VsZCBiZSBy
dW5uaW5nIHRoZSBjb2RlIGFuZCBzZWVpbmcgdGhlIHJlc3VsdHMgZnJvbSB3aXRoaW4gJ29yZy1l
ZGl0LXNyYy1jb2RlLgogICAgIEN1cnJlbnRseSwgaWYgb25lIHdvcmtzIHVzaW5nICdvcmctZWRp
dC1zcmMtY29kZSwgcnVubmluZyB0aGUgY29kZSBpcyBub3QgYW4gb3B0aW9uLCBiZWNhdXNlIHlv
dSB3b3VsZG4ndCBzZWUgdGhlIDpSRVNVTFRTIGFueXdheS4KICAgICBDdXJyZW50bHksIHN3aXRj
aGluZyBpcyBuZWNlc3NhcnkgZnJvbSB0aGUgZWRpdCBidWZmZXIgdG8gdGhlIG1haW4gYnVmZmVy
IGFuZCBiYWNrLgogICAgIFRoaXMgcHJvYmxlbSBjb3VsZCBiZSBzb2x2ZWQgYnkgcmVkaXJlY3Rp
bmcgdGhlIG91dHB1dCB0byBzb21lIGJ1ZmZlciBhbmQgc3BsaXQgc2NyZWVuaW5nLCBidXQsIHRo
ZW4gYWdhaW4sIHVwZGF0aW5nIHRoZSBvcmlnaW5hbCBidWZmZXIgaXMgcmVxdWlyZWQuCgogICAg
IC0gWyBdIElmIHRoZSByZXN1bHRzIG9mIGV4ZWN1dGlvbiB3ZXJlIHRvIGJlIHJlZGlyZWN0ZWQg
dG8gYSBzZXBhcmF0ZSBidWZmZXIsIHRoZXkgd291bGQgaGF2ZSB0byBiZSBtYXBwZWQgYmFjayB0
byB0aGUgb3JpZ2luYWwgZmlsZSBmb3IgY29uc2lzdGVuY3kuCgogICAgIExldCdzIG5vdyBkaXNj
dXNzIHRoZSB2aXN1YWwgcHJvcGVydGllcyBvZiBjb2RlIGJsb2NrcyBhbmQgOnJlc3VsdHMuCgog
ICAgICMrTkFNRTogb25lLWxpbmVyCiAgICAgIytCRUdJTl9TUkMgZWxpc3AKICAgICAgIChkZWZ1
biBzdGVwICh4IGwpIChjYXNlICg8IHggbCkgMCB0IDEpKQogICAgICMrRU5EX1NSQwoKICAgICBG
b3IgdHdvIGxpbmVzIG9mIG1lYW5pbmdmdWwgZGF0YSwgdGhlcmUgYXJlIGZvdXIgbGluZXMgb2Ys
IGFkbWl0dGVkbHksIG5vaXNlLgogICAgIE1lYW5pbmdmdWw6IHRoZSBzdHVmZiB0aGF0IHRoZSBw
cm9ncmFtbWVyIGNvbmNlbnRyYXRlcyBvbi4gCiAgICAgRm9yIGxvbmdlciBzbmlwcGV0cywgdGhl
IG5vaXNlLXRvLXNpZ25hbCByYXRpbyBkcm9wcywgYnV0IHdoZW4geW91IGhhdmUgYSBsb3Qgb2Yg
c25pcHBldHMsIHRoZXNlIGV4dHJhIGxpbmVzIG9mIHBhcmFtZXRlcnMgYWRkIHVwLgogICAgIEFu
ZCBldmVyeXRoaW5nIHN0YXJ0cyBsb29raW5nIGxpa2Ugc3BpZGVycyBtYWtpbmcgbG92ZSBpbiBh
IGJvd2wgb2Ygc3BhZ2hldHRpLgoKICAgICBJIHRoaW5rIG9uZSB3YXkgd2hpY2ggY291bGQgaGVs
cCBpcyB0byBoYXZlIGEgc3VtbWFyeSBsaW5lIGFuZCBoaWRlIHRoZSByZXN0OgoKICAgICA+IFtv
bmUtbGluZXJdIChlbGlzcCkgPG90aGVyIHN0dWZmPgogICAgID4gIChkZWZ1biBzdGVwICh4IGwp
IChjYXNlICg8IHggbCkgMCB0IDEpKQoKICAgICBBbmQgd2hlbiBpdCBpcyBuZWNlc3NhcnkgdG8g
ZWRpdCB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIGJsb2NrLCBvbmUgY291bGQgZXhwYW5kIGl0IG9u
IGEga2V5IGNvbWJpbmF0aW9uOgoKICAgICAtIHRoZSBhcHBlYXJhbmNlIG9mIGJsb2NrcyBjb3Vs
ZCBiZSBtb3JlIGRpc3RpbmN0IGFuZCBsZXNzIG5vaXN5LgoKICAgICBUbyBhZGQgdG8gdGhpcywg
bm90ZSBob3cgdGhlIGNvZGUgaW4gdGhlIHNvdXJjZSBibG9ja3MgaXMgaW5kZW50ZWQgdHdvIHNw
YWNlcyBmb3J3YXJkLgogICAgIFRob3NlIGFyZSBoYXJkIHNwYWNlcyBhbmQgdGhleSB3ZXJlbid0
IGluc2VydGVkIHJpZ2h0IGF3YXksIG9ubHkgYWZ0ZXIgdXNpbmcgJ29yZy1lZGl0LXNyYy1jb2Rl
LgogICAgIE5vIGRvdWJ0LCB0aGlzIGluZGVudGF0aW9uIGhlbHBzLgogICAgIEhvd2V2ZXIsIGl0
IHdvdWxkIGJlIGJldHRlciBmb3IgaXQgdG8gYmUgcHVyZWx5IHZpc3VhbCBhbmQgdG8gYmUgdGhl
cmUgd2l0aG91dCBoYXZpbmcgdG8gY2FsbCBhbnl0aGluZy4KCiAgICAgSW4gc2hvcnQ6CgogICAg
IC0gWyBdIGEgcG93ZXJmdWwgd2F5IHRvIGN1c3RvbWl6ZSB0aGUgdmlldyBvZiBibG9ja3MgaXMg
bmVlZGVkLgoKICAgICBOZXh0LCB0aGUgL29iLWFzeW5jLyBwYWNrYWdlIHNob3dzIHRoYXQgYXN5
bmNocm9ub3VzIGV4ZWN1dGlvbiBvZiBibG9ja3MgaXMgcG9zc2libGUuCiAgICAgQXBwYXJlbnRs
eSwgdGhlIHdheSBpdCB3b3JrcyBpcyBieSBwbGFjaW5nIGEgdW5pcXVlIGlkZW50aWZpZXIgaW4g
dGhlIFJFU1VMVFMgYW5kIHRoZW4gcmVwbGFjaW5nIGl0LgogICAgIEFub3RoZXIgcG9zc2libGUg
c2NlbmFyaW86IGRpc3BsYXkgdGhlIGN1cnJlbnQgcnVubmluZyB0aW1lIGluIHRoZSBmb290ZXIg
b2YgYSBibG9jay4KICAgICBJcyB0aGUgZmluZC9zZWFyY2ggcHJvY2VkdXJlIHRoZSBiZXN0IG9u
ZSBjb3VsZCBkbz8KCiAgICAgLSBbIF0gQSB1bmlmaWVkIHdheSB0byB1cGRhdGUgdGhlIHZpZXcg
b2YgYSBibG9jayAvIHJlc3VsdHMgc2VjdGlvbiBjb3VsZCBoZWxwLgoKKioqKiBTb2x1dGlvbgoq
KioqKiBCYXNpcwoKICAgIEEgc291cmNlIGJsb2NrIGNhbiBiZSBzaG93biB2aWEgYSAvY29tcG9z
aXRlIGxlbnMvLgogICAgQW5kIHNvIGNhbiBiZSBldmVyeSBub3dlYiByZWZlcmVuY2UuCgogICAg
Rm9yIGluc3RhbmNlLCBzdXBwb3NlIGEgYnVmZmVyIChjYWxsIGl0IC9tYWluIGJ1ZmZlci8pIGhh
cyB0aGVzZSBibG9ja3MgKGFsc28gdXNlZCBpbiB0aGUgZm9sbG93aW5nIHN1YnNlY3Rpb25zKToK
CiAgICAjK05BTUU6IGJsb2NrLUEKICAgICMrQkVHSU5fU1JDIHB5dGhvbgogICAgICAgZiA9IGxh
bWJkYSB4OiB4ICoqIHgKICAgICMrRU5EX1NSQwoKICAgICMrTkFNRTogYmxvY2stQgogICAgIytC
RUdJTl9TUkMgcHl0aG9uIDpub3dlYiB5ZXMKICAgICAgIDw8YmxvY2stQT4+CiAgICAgICBnID0g
bGFtYmRhIHg6IGYoeCkgKyBmKHggKyAxKQogICAgIytFTkRfU1JDCgogICAgU28sIHRoZXNlIGxl
bnNlcyBhcmUgY3JlYXRlZDoKICAgIC0gL2Jsb2NrLUEvIC9jb21wb3NpdGUgbGVucy8gY29udGFp
bmluZzoKICAgICAgIC0gL2J1ZmZlci1BLyAvbGVucy8gKHcvIGNvbnRlbnRzICJmID0gbGFtYmRh
IHg6IHggKiogeCIpCiAgICAgICAtIGJlZ2luL2VuZCBzb3VyY2UgbWFya2VycyBhcyBwbGFpbiB0
ZXh0CiAgICAtIC9ibG9jay1CLyAvY29tcG9zaXRlIGxlbnMvIGNvbnRhaW5pbmc6CiAgICAgICAt
IC9idWZmZXItQS8gL2xlbnMvICh3LyBjb250ZW50cyAiZiA9IGxhbWJkYSB4OiB4ICoqIHgiIHNo
YWRvd2luZyAiPDxibG9jay1BPj4iIG9yIGp1c3QgIjw8YmxvY2stQT4+IikKICAgICAgIC0gL2J1
ZmZlci1CLyAvYnVmZmVyIGxlbnMvICh3LyBjb250ZW50cyAiZyA9IGxhbWJkYSB4OiBmKHgpICsg
Zih4ICsgMSkiKQoKICAgIEFzIHlvdSBzZWUsIHRoZSBjb2RlIG9mIGJsb2NrLUEgYXBwZWFycyBp
biB0d28gYmxvY2tzOiBhcyBjb2RlIGFuZCBhcyBhIHJlZmVyZW5jZS4KICAgIEEgcmVhc29uYWJs
ZSB0aGluZyB0byBkbyBpcyBjcmVhdGUganVzdCBvbmUgbGVucyBmb3IgYm90aC4KICAgIFNvLCB0
aGlzIGxlbnMgc2hvdWxkIGNvbnRhaW4gdGhlIGNvZGUsIGJ1dCBzaG91bGQgYWxzbyBiZSBhYmxl
IHRvIHNob3cganVzdCB0aGUgcmVmZXJlbmNlLgogICAgVGhlcmUgYXJlIG11bHRpcGxlIHdheXMg
dG8gZGlzcGxheSB0aGlzIGxlbnMgKHRoYXQgaXMsIHRvIGZvcm0gYW4gL2FyZWEvKToKICAgIHNo
b3cgdGhlIGNvZGUvcmVmZXJlbmNlIHdoaWNoLCAvb3B0aW9uYWxseS8sIHNoYWRvd3MgcmVmZXJl
bmNlL2NvZGUuCiAgICBGb3IgZXhhbXBsZSwgaW4gYmxvY2stQiwgd2UgbWF5IGNob29zZSB0byBz
aG93IGNvZGUgYW5kIHNoYWRvdyB0aGUgcmVmZXJlbmNlLCBzbyB0aGF0IHdoZW4gdGhlIGRvY3Vt
ZW50IGlzIHNhdmVkLCB0aGUgdGV4dCBvZiB0aGUgcmVmZXJlbmNlIGlzIGFjdHVhbGx5IHNhdmVk
IGFuZCBub3QgdGhlIGNvZGUuCgogICAgU28sIGluIHRoZSBlbmQsIHRoZXJlIGlzIGp1c3Qgb25l
IGxlbnMgZm9yIC9idWZmZXItQS8sIHdpdGggdHdvIC9hcmVhcy8sIG9uZSBmb3IgL2Jsb2NrLUIv
IGFuZCBvbmUgZm9yIC9ibG9jay1BLy4KICAgIFRoZSBsZW5zIGNvdWxkIGJlIGVpdGhlciAvYnVm
ZmVyLWxlbnMvIG9yIGEgL2NvbXBvc2l0ZS1sZW5zLywgaXQncyB1cCB0byB0aGUgaW1wbGVtZW50
YXRpb24uCgoqKioqKiBFZGl0aW5nCgogICAgVGhlIG1vc3QgaW1wb3J0YW50IHBvaW50IHRvIHJl
bWVtYmVyIG5vdyBpcyB0aGlzOiAKICAgIHRoZSBsaW5rZWQgYnVmZmVyIGhhcyBpdHMgb3duIHNl
dCBvZiBtb2RlcywgaW5kZXBlbmRlbnQgb2YgdGhlIG1vZHMgaW4gdGhlIHdvcmtpbmcgYnVmZmVy
LgoKICAgIExlbnMtbW9kZSBvZmZlcnMgYW4gaW1wb3J0YW50IHV0aWxpdHkgKGRpc2N1c3NlZCBp
biBbW01lY2hhbmljc11dKTogCiAgICBpdCBjYW4gcmVkaXJlY3Qga2V5YmluZGluZ3MgYW5kIGNv
bW1hbmRzIHdoZW4gdGhlIGN1cnNvciBpcyBpbiB0aGUgYXJlYSBvZiB0aGUgbGVucy4KICAgIFNv
LCBiYXNpY2FsbHksIHRoZSB1c2VyIGNhbiBoYXZlIGFjY2VzcyB0byBhbGwgdGhlIGZlYXR1cmVz
IG9mIHRoZSBtb2RlcyB3aGljaCBydW4gaW4gdGhlIGxpbmtlZCBidWZmZXIuCiAgICBUaGlzIGlt
bWVkaWF0ZWx5IGltcGxpZXMgcHJvcGVyIGluZGVudGF0aW9uIGFuZCB0aGUgcmVzb2x1dGlvbiBv
ZiB0aGUgYnVnIHcvIGNvbW1lbnRpbmcuCiAgICAoY29tbWVudCBrZXliaW5kaW5nIGlzIGZvcndh
cmRlZCB0byB0aGUgL2lubmVyIGJ1ZmZlci8gYW5kIHRoZSByaWdodCB0aGluZyBpcyBkb25lIHRo
ZXJlLikKCiAgICBBbmQgd2hhdCBhYm91dCAnb3JnLWVkaXQtc3JjLWNvZGU/CiAgICBKdXN0IG9w
ZW4gYSBidWZmZXIgYW5kIHNob3cgdGhlIC9idWZmZXItQS9CLyBsZW5zIHRoZXJlIQogICAgTm8g
bmVlZCB0byB3cml0ZSB0aGUgY2hhbmdlcyBiYWNrOiBhbGwgdGhlIGFyZWFzIG9mIHRoZSBsZW5z
IHVwZGF0ZSBpbiByZWFsIHRpbWUuCgoqKioqKiBWaWV3aW5nCgogICAgSW4gYWRkaXRpb24gdG8g
dGhlIHR3byBibG9ja3MgZnJvbSBbW0Jhc2lzXV0sIGxldCdzIGRlZmluZToKCiAgICAjK05BTUU6
IGJsb2NrLUMKICAgICMrQkVHSU5fU1JDIHB5dGhvbiA6bm93ZWIgeWVzCiAgICAgICA8PGJsb2Nr
LUI+PgogICAgICAgaCA9IDEwICogZig1KSAqIGcoMikKICAgICMrRU5EX1NSQwoKICAgICMrTkFN
RTogYmxvY2stRAogICAgIytCRUdJTl9TUkMgcHl0aG9uIDpub3dlYiB5ZXMKICAgICAgIDw8Ymxv
Y2stQj4+CiAgICAgICB5ID0gZygxKQogICAgIytFTkRfU1JDCgogICAgU28sIHRoZSBkZXBlbmRl
bmN5IHRyZWUgaXMgdGhpczoKICAgIGJsb2NrLUEgPC0tIGJsb2NrLUIgPC0tIGJsb2NrLUMKICAg
ICAgICAgICAgICAgICAgICAgICAgPC0tIGJsb2NrLUQKCiAgICBGaXJzdCwgbGV0J3Mgc2VlIHdo
YXQgY2FuIGJlIGRvbmUgYWJvdXQgc3ludGF4IGNoZWNraW5nLCBjb21wbGV0aW9uIGFuZCB0aGUg
cG9zc2liaWxpdHkgb2Ygdmlld2luZyBhbGwgdGhlIGNvZGUgYXQgb25jZS4KICAgIEhvdyBjYW4g
d2UgZGVhbCB3aXRoIHRoZSBub3dlYiByZWZlcmVuY2VzPwoKICAgIFVuZGVyc3RhbmRpbmcgd2hh
dCBpdCBpcyBleGFjdGx5IHRoYXQgd2Ugd2FudCBtYXkgaGVscCB1cyBhbnN3ZXIgdGhlIHF1ZXN0
aW9uLgogICAgQSByb3VnaCBsaXN0IG9mIHJlcXVpcmVtZW50cy93aXNoZXMgY291bGQgYmU6Cgog
ICAgKHJlZ2FyZGxlc3Mgb2Ygd29ya2luZyBpbiB0aGUgL21haW4gYnVmZmVyLyBvciB1c2luZyAn
b3JnLWVkaXQtc3JjLWNvZGUpCiAgICAtICgxKSBoYXZlIGFuIG9wdGlvbiB0byBleHBhbmQgdGhl
IHJlZmVyZW5jZXMgaW50byBjb2RlCiAgICAtICgyKSBoYXZlIHN5bnRheCBjaGVja2luZyBhbmQg
Y29tcGxldGlvbjoKICAgICAgIC0gKGEpIHdoaWNoIHdvcmsgYXMgaWYgdGhlIHJlZmVyZW5jZXMg
d2VyZSBleHBhbmRlZCAocmVnYXJkbGVzcyBvZiB0aGUgYWN0dWFsIHJlZmVyZW5jZSBleHBhbnNp
b24gb3B0aW9ucyksCiAgICAgICAtIChiKSB3aGljaCB3b3JrIGFzIGlmIHRoZSBjb2RlIHRoYXQg
cmVmZXJlbmNlcyB0aGUgYmxvY2sgaXMgc2VlbiBhcyB3ZWxsIAogICAgICAgICAtIGlmIGluY2x1
ZGVkIGJ5IG11bHRpcGxlIGJsb2NrcyAoZS5nLiBpbiBjYXNlIG9mIH5ibG9jay1CfiwgdGhlIHVz
YWdlIGJ5IH5ibG9jay1DfiBhbmQgfmJsb2NrLUR+KSwgcHJlZmVyIHRoZSBvbmUgd2hpY2ggcmFu
IGxhc3QuCiAgICAgICAtIChjKSBhbmQgbWluaW1pemUgdGhlIHdvcmsgZG9uZS4KCiAgICBPSywg
YWxsIG9mIHRoZSBhYm92ZSBjYW4gZXhwbG9pdCB0aGUgZnVuY3Rpb25hbGl0eSBvZiBsZW5zZXMs
IHdoaWNoLCB1cG9uIHJlcXVlc3QsIGNhbiBwcm9kdWNlIHRoZSByaWdodCAvYXJlYS8gYmFzZWQg
dGhlIHByZWZlcmVuY2VzIG9mIHRoZSBidWZmZXIgd2hpY2ggY29udGFpbnMgdGhlIC9sZW5zLy4K
ICAgICgxKSBpcyBjb3ZlcmVkOiB0aGUgbGVuc2VzIGZvciByZWZlcmVuY2VzIGFyZSByZWN1cnNp
dmVseSBhc2tlZCB0byBzaG93IGNvZGUgaW5zdGVhZCBvZiB0aGUgcmVmZXJlbmNlLgogICAgKDIp
IGlzIGFsc28gY292ZXJlZCAtIGxldCdzIGRpc2N1c3MgdGhlIGRldGFpbHMuCgogICAgV2hhdCBp
cyBwb2ludCAoMiksKGIpIGFsbCBhYm91dD8KICAgIFdoeSB3b3VsZCA8PGJsb2NrLUI+PiBjYXJl
IGFib3V0IHdobyByZWZlcmVuY2VzIGl0IChpLmUgYmxvY2tzIEMgYW5kIEQpPwogICAgV291bGRu
J3QgaXQgYmUgZW5vdWdoIGZvciB0aGUgc3ludGF4IGNoZWNrZXIgdG8gdmlldyBqdXN0IHRoZSBl
eHBhbmRlZCA8PGJsb2NrLUE+PiByZWZlcmVuY2U/CiAgICBJbmRlZWQsIHRoYXQgd291bGQgYWxt
b3N0IHdvcmssIGJ1dCB0aGVyZSBhcmUgZmxhd3MgdG8gdGhpcyBhcHByb2FjaDoKICAgIC0gdGhp
bmdzIGxpa2UgL3VudXNlZCB2YXJpYWJsZS8gb3IgL21pc3NpbmcgYSBjbG9zaW5nIGJyYWNrZXQv
IHdpbGwgYXJpc2UsCiAgICAtIGl0IGlzIHVubmVjZXNzYXJpbHkgZXhwZW5zaXZlLgoKICAgIFRo
aXMgbGFzdCBwb2ludCBpcyBzaW1wbGU6IHdoeSBydW4gc3ludGF4IGNoZWNrZXIgaW4gfmJsb2Nr
LUF+IGFuZCB+YmxvY2stQn4sIGlmIG9uZSBjb3VsZCBydW4gaXQgaW4gfmJsb2NrLUN+IGFuZCBt
YXAgdGhlIGNoYW5nZXMgYmFjaz8KICAgIFNvLCB0aGUgc29sdXRpb24gaXMgdG8gYnVpbGQgc291
cmNlIGJsb2NrIHRyZWUgYW5kIHJ1biBzeW50YXggY2hlY2tlciBvbiB0aGUgZW5kIG5vZGVzLCB3
aGlsZSBwcm9wYWdhdGluZyB0aGUgcmVzdWx0cyBiYWNrIHRvIHRoZSByb290LiBJZiB0aGVyZSBp
cyBhIGZvcmssIHByb3BhZ2F0ZSBmcm9tIHRoZSBvbmUgd2hpY2ggdGhlIHVzZXIgcmFuIGxhc3Qu
CiAgICBIb3cgZXhhY3RseSBjb3VsZCB0aGlzIHdvcmsgaW4gb3VyIGV4YW1wbGU/CiAgICAtIEtl
ZXAgYSBidWZmZXIgd2hpY2ggdmlld3MgdGhlIH5ibG9jay1DfiBsZW5zIGFuZCByZWN1cnNpdmVs
eSB0ZWxsIHRoZSByZWZlcmVuY2UtbGVuc2VzIHRvIHNob3cgdGhlIGNvZGUuIAogICAgLSBSdW4g
dGhlIHN5bnRheCBjaGVja2VyIHRoZXJlIGFuZCBhc3NvY2lhdGUgdGhlIG91dHB1dCB3LyBlYWNo
IGxlbnMgKHJlY3Vyc2l2ZWx5KS4KICAgIC0gRm9yIGNvbXBsZXRpb24sIHByb3BhZ2F0ZSB1c2Vy
IGlucHV0IChmcm9tIGxlbnNlcyBBLCBCIGFuZCBDKSB0byB0aGlzIHNhbWUgfmJsb2NrLUN+IGJ1
ZmZlciBhbmQgZGVhbCB3LyB0aGUgcmVzdWx0LgoKICAgIE9LLCBzbyBtdWNoIGZvciB0aGUgdG91
Z2hlciBzaGFyZSBvZiB0aGUgcHJvYmxlbXMuCiAgICBOb3csIGxldCdzIGdldCB0aGUgcmVzdCBv
ZiB0aGUgaXNzdWVzLgoKICAgIC0gVmlldyBjdXN0b21pemF0aW9uIGlzIGluIHBsYWNlOiAvYXJl
YXMvIG1heSBoYXZlIHZhcmlvdXMgcHJvcGVydGllcyBhbmQgY2FuIHNob3cvaGlkZS9kaXNwbGF5
IHRoZSBiZWdpbi9lbmQgb3JuYW1lbnRhdGlvbiBpbiBhbnkgbWFubmVyLgogICAgICAoZS5nLiA6
UkVTVUxUUyBsZW5zIHRydW5jYXRlcyBsaW5lcywgd2hpbGUgdGhlIGJ1ZmZlciB0aGF0IGNvbnRh
aW5zIGl0IGRvZXNuJ3QsIGV0Yy4sIHNlZSB0aGUgW1tQcm9ibGVtc11dIHNlY3Rpb24pCiAgICAg
IChlLmcuIHRoZSAvYXJlYS8gb2YgdGhlIGNvZGUgbGVucyBpcyBpbmRlbnRlZCB0d28gc3BhY2Vz
LCBhcyBpdCdzIHByb3BlcnR5KQoKICAgIC0gT25lIGNvdWxkIGluc3RydWN0IGEgbGVucyB3aGF0
IHRvIGRvIGluc3RlYWQgb2YgdXNpbmcgcmVnZXhwICsgcmVwbGFjZS4KICAgICAgKGUuZy4gY29u
dGludW9zbHkgdXBkYXRlIGEgdGltZXIpCgogICAgUmVzdWx0cyBzZWN0aW9ucyBjYW4gYmUgc2hv
d24gdmlhIGxlbnNlcy4KICAgIE5vdywgd2hlbiBlZGl0aW5nIHcvICdvcmQtZWRpdC1zcmMtY29k
ZSwganVzdCBzcGxpdCB0aGUgc2NyZWVuIGFuZCBvcGVuIDpSRVNVTFRTIGluIGFub3RoZXIgYnVm
ZmVyLgogICAgRWRpdGluZyBvciBydW5uaW5nIHRoZSBjb2RlOiBldmVyeXRoaW5nIHdpbGwgYmUg
a2VwdCBpbiBzeW5jIHcvIHRoZSBvcmlnaW5hbCBidWZmZXIuCiAgICBTb21lIGJsb2NrcyBtYXkg
b3V0cHV0IHNldmVyYWwgZGlzdGluY3QgcGllY2VzIG9mIGRhdGEsIGxpa2UgaGVyZToKICAgIGh0
dHA6Ly9raXRjaGluZ3JvdXAuY2hlbWUuY211LmVkdS9ibG9nLzIwMTcvMDEvMjkvb2ItaXB5dGhv
bi1hbmQtaW5saW5lLWZpZ3VyZXMtaW4tb3JnLW1vZGUKICAgIFJlcGxhY2luZyB0aGUgb2xkIHJl
c3VsdHMgY291bGQgYmUganVzdCBhIG1hdHRlciBvZiByZW1vdmluZyB0aGUgZXhpc3RpbmcgbGVu
cyBhbmQgcGxhY2luZyBpbiBhIG5ldyBvbmUuCiAgICBObyBuZWVkIHRvIHNlYXJjaCBmb3IgdGhl
IGVuZCBvZiB0aGUgcmVzdWx0cyBibG9jay4KCiAgICBZb3UgY291bGQgc2VsZWN0IGEgcG9ydGlv
biBvZiB0aGUgYmxvY2sgYW5kIG5hcnJvdyBpdC4KCiAgICBTaG93aW5nIHRoZSBsaW5lIG51bWJl
cnMgc2hvdWxkIGJlIGEgbWF0dGVyIG9mIHJ1bm5pbmcgbmxpbnVtIGluIHRoZSBlbmQgbm9kZSBi
dWZmZXIgKGFzIHcvIHN5bnRheCBjaGVja2luZyksIGJ1dCBJIGRvbid0IGtub3cgaG93IG5saW51
bSB3b3JrcyB0byBzYXkgZm9yIHN1cmUuCgogICAgVG8gYmUgZmFpciwgc29tZSBvZiB0aGUgZGVz
Y3JpcHRpb25zIGhlcmUgZGVwZW5kIG9uIGltcGxlbWVudGF0aW9uIHBvc3NpYmlsaXRpZXMsIHNv
IHRoZSBsZXZlbCBvZiBkZXRhaWwgaXMgaW4gYWNjb3JkYW5jZS4KCioqKiBPdGhlciB1c2VzCgoq
KioqIElubGluZSB2aWV3IG9mIGxpbmtzCgogICAgIE9uZSBjb3VsZCBtYWtlIHNvbWUgc29ydCBv
ZiBhIGxlbnMgdG8gdmlldyBhIHBhcnQgb2YgYSBidWZmZXIvZmlsZSBpZGVudGlmaWVkIGJ5IGEg
bGluay4KICAgICBUaGUgYnVmZmVyIGNvdWxkIGJlIHRoZSBzYW1lIGJ1ZmZlciwgYW4gZXh0ZXJu
YWwgZmlsZSwgYW55dGhpbmcuCiAgICAgT25lIHdvdWxkIG5vdCBoYXZlIHRvIGZvbGxvdyB0aGUg
bGluay4KICAgICBXaGVuIGZvbGxvd2luZyB0aGUgbGluayBpcyB0b28gY3VtYmVyc29tZSwgY29w
eSBwYXN0aW5nIGlzIHByZXZlbnRlZC4KCioqKiogRGlzcGxheSBPcmcgZG9jdW1lbnRzCgogICAg
IFNlY3Rpb25zIGluIGFuIG9yZyBkb2N1bWVudCBjb3VsZCBiZSBzaG93biB1c2luZyBsZW5zZXMu
CiAgICAgTm90IHRoYXQgSSBrbm93IHdoeSB0aGlzIHdvdWxkIGJlIHVzZWZ1bCAod2VsbCwgbWF5
YmUgZm9yIG1ha2luZyBhIFtbSnVweXRlcl1dIGxpa2UgZW52aXJvbm1lbnQpLgogICAgIEJ1dCB0
aGUgY29uY2VwdCBpcyBpbnRlcmVzdGluZy4KCioqKiogQ29ubmVjdCBzZXZlcmFsIHNvdXJjZSBi
bG9ja3MKCiAgICAgKEkgaGF2ZSBwcm9wb3NlZCB0aGlzIG9uIHRoZSBPcmctbW9kZSBtYWlsaW5n
IGxpc3QsIGJ1dCBub3cgdGhhdCBJIHRoaW5rIG9mIGl0LCBhIHVzZXItZGVmaW5lZCB3YXkgYXMg
aGVyZSBpcyBiZXR0ZXIuKQoKICAgICBBIHF1aXRlIG9yZGluYXJ5IHdvcmtmbG93IGlzIHRvIHdy
aXRlIGEgYmxvY2sgYW5kIHRoZW4gdGVzdCB0aGUgYmxvY2sgc2VwZXJhdGVseSAob3IgdXNlIDpl
cGlsb2d1ZSBmb3Igb25lLWxpbmVycykuCiAgICAgSG93ZXZlciwgd3JpdGluZyBvdXQgYSB0ZXN0
IHNlcGVyYXRlbHkgaXMgbm9pc3kgYW5kIHNvbWV0aGluZyBsaWtlIHRoaXMgY291bGQgYmUgZG9u
ZSBpbnN0ZWFkOgoKICAgICAjK05BTUU6IHNxdWFyZS0xCiAgICAgIytCRUdJTl9TUkMgcHl0aG9u
CiAgICAgICBzcXVhcmUgPSBsYW1iZGEgeDogeCAqIHgKICAgICAjK0VORF9TUkMKICAgICAgIHJl
dHVybiBbc3F1YXJlKHgpIGZvciB4IGluIHJhbmdlKDEwKV0KICAgICAjK0VORF9TUkNfVEVTVAoK
ICAgICBUaGlzIGNvdWxkIGJlIGFjY29tcGxpc2hlZCBieSBsZW5zZXM6IGxlbnMtbW9kZSB3b3Vs
ZCBvbmx5IG5lZWQgdG8gY2hlY2sgZm9yIHR3byBhZGphY2VudCBibG9ja3MgPG5hbWU+IGFuZCA8
bmFtZT4tdGVzdCBhbmQgdGhlbiB3cmFwIHRoZW0gaW4gYW5vdGhlciBsZW5zLCBzaG93aW5nIGJv
dGggbGlrZSBhYm92ZS4KCiAgICAgT2YgY291cnNlLCBzb21lIHdheSB0byBsZXQgb3JnLWJhYmVs
IGtub3cgd2hhdCdzIGdvaW5nIG9uIHdvdWxkIGJlIG5lY2Vzc2FyeS4KCioqIEFyYml0cmFyeSBQ
b3NpdGlvbmluZyAoV2luZG93IExlbnNlcykKCiAgIFdpbmRvdyBsZW5zZXMgYXJlIGEgbG9naWNh
bCBleHRlbnNpb24gb2YgYnVmZmVyIGxlbnNlcy4KICAgSW1hZ2luZSB5b3Ugd2FudGVkIHRvIHN0
YWNrIHR3byBpbWFnZXMgaG9yaXpvbnRhbGx5LgogICBWaWV3aW5nIHR3byBpbWFnZXMgaG9yaXpv
bnRhbGx5IGluIEVtYWNzIGNhbiBiZSBkb25lIGJ5IGNyZWF0aW5nIHR3byB3aW5kb3dzLCBvbmUg
aW1hZ2UgaW4gZWFjaCB3aW5kb3cuCiAgIFRoYXQncyB3aGF0IGEgd2luZG93IGxlbnMgY291bGQg
ZG8sIGV4Y2VwdCBpdCB3b3VsZCBiZSBzaG93biBpbnNpZGUgYSBidWZmZXIuCgoqKiBJbnRlcmFj
dGl2ZSBHcmFwaHMKCiAgIFRoaXMgb25lIGlzIHRvdWdoZXIgdGhhbiB3aW5kb3cgbGVuc2VzLCBi
dXQgbXVjaCBtb3JlIGludGVyZXN0aW5nLgogICBTYXksIHlvdSB3YW50ZWQgdG8gaGF2ZSBhbiBp
bnRlcmFjdGl2ZSBncmFwaCBpbiB5b3VyIGJ1ZmZlciAoZ251cGxvdCwgbWF0cGxvdGxpYikuCiAg
IFRoaXMgcGFydCBvZiB0aGUgYnVmZmVyIHdvdWxkIHJlcXVpcmUgaXQncyBvd24ga2V5YmluZGlu
Z3MgYW5kIGFsbCwgYnV0IHRoZSBhcmVhIG9mIHRoZSBsZW5zIGNvdWxkIGJlIGN1c3RvbWl6ZWQs
IHRocm91Z2ggaXRzIHByb3BlcnRpZXMgb2YgcGFkZGluZy9jZW50ZXJpbmcgYW5kIHN1Y2gsIHRv
IGFkb3JuIGFuZCBwbGFjZSB0aGUgZ3JhcGggaW4gYSB2aXN1YWxseSBzYXRpc2Z5aW5nIG1hbm5l
ci4KCiAgIEluIHRoZSBsYW5kIHdoZXJlIHVuaWNvcm5zIGxpdmUsIG9uZSB3b3VsZCBiZSBhYmxl
IHRvIHZpZXcgYW55IGdyYXBoaWNhbCB3aW5kb3cgaW5zaWRlIEVtYWNzOiBzb21ldGhpbmcgdGhh
dCB3b3VsZCBzYXRpc2Z5IHRoZSB0YXN0ZSBvZiBldmVuIHRoZSBmaW5lc3QgZ291cm1ldHMgb2Yg
bW9kZXJuIHRleHQgZWRpdGluZyAodUdockhyaG1waCkuCgogICBOb3QgdGhhdCB0aGUgYnVmZmVy
IGxlbnNlcyBhcmUgdGhlIGJpZ2dlc3QgcHJvYmxlbSBoZXJlLCBidXQgdGhleSBqdXN0IG1pZ2h0
IGNvbWUgaW4gdXNlZnVsLgoKKiogRmFzdCBUaW1lciBVcGRhdGVzIChUZXh0IGFzIGFuIE9iamVj
dCkKCiAgIEkgaGF2ZSBhbHJlYWR5IHRvdWNoZWQgb24gdGhpcyB0b3BpYyBhIGJpdCBpbiB0aGUg
Y29udGV4dCBvZiBPcmctTW9kZSwgYW5kIG5vdywgZm9yIHRoZSBzYWtlIG9mIGNvbXBsZXRlbmVz
cywgbGV0J3MgZm9ybSBhIGdlbmVyYWwgY2hhcmFjdGVyaXN0aWMgb2YgdXNpbmcgbGVuc2VzLgoK
ICAgQSB0aW1lciB3YXMgbWVudGlvbmVkOiBjdXJyZW50bHksIGFzIEkgdW5kZXJzdGFuZCwgaWYg
eW91IHdhbnRlZCB0byBwdXQgaXQgaW4geW91ciBidWZmZXIgYW5kIHNlZSBpdCBjb250aW51b3Vz
bHkgdXBkYXRlLCB5b3Ugd291bGQgaGF2ZSB0byB1c2Ugc2VhcmNoIGFuZCByZXBsYWNlLCB3aGlj
aCBpcyBub3QgZWZmaWNpZW50LgogICBUaGUgc29sdXRpb24gb2ZmZXJlZCB3YXMgdG8gdXNlIGEg
bGVuczogaXQgd291bGQgaXRzZWxmIHVwZGF0ZSB0aGUgdGltZXIgKGFzIGEgL3NoYXJlZCBibG9j
ay8gb3Igc29tZSBvdGhlciBkaXJlY3QgbWFubmVyKS4KCiAgIEFuZCB0aGUgdXNlcyBhcmUgbW9y
ZSBnZW5lcmFsOiBzaW5jZSAvbGVucy1tb2RlLyB0cmFja3MgYWxsIHRoZSBsZW5zZXMsIG9uZSBj
b3VsZCBzZW5kIGNvbW1hbmRzIHRvIHRoZW0uCiAgIFRoZXkgY2FuIHVwZGF0ZSBpbmRlcGVuZGVu
dGx5LgogICBTbywgaWYgdGhlcmUgYXJlIHRleHQgb2JqZWN0cywgdGhleSBtYXkgYmUgYWNjZXNz
ZWQgZWFzaWx5LgogICBUaGlzIHdhcyBvbmUgb2YgdGhlIGdvYWxzIHNldCBpbiB0aGUgW1tQcm9i
bGVtIFN0YXRlbWVudF1dLgoKKiogQnVnIFRyYWNrZXJzICYgV2Vic2l0ZXMgJiBEYXRhYmFzZXMg
KEludGVyZmFjZSBCdWlsZGluZykKCiAgIFBlcmhhcHMsIG9uZSBjb3VsZCB3b3JrIHdpdGggR2l0
bGFiIHNlcnZlciBvciBzaW1pbGFyIHRocm91Z2ggbGVuc2VzLgoKICAgQnVpbGRpbmcgYW4gaW50
ZXJmYWNlIGZvciBhIHdlYnNpdGUgZG9lc24ndCBzZWVtIHRvIGJlIG91dCBvZiB0aGUgcXVlc3Rp
b24gZWl0aGVyLgoKICAgQWNjZXNpbmcgYSBkYXRhYmFzZTogd2h5IG5vdD8KCiogSnVweXRlcgoK
ICBKdXB5dGVyIGlzIGEgcmVwcm9kdWNpYmxlIHJlc2VhcmNoIGVudmlyb25tZW50LgogIGh0dHBz
Oi8vanVweXRlci5vcmcvCgogIEhlcmUgaXMgd2hhdCB1c2luZyBpdCBsb29rcyBsaWtlOgogIGh0
dHA6Ly9hcm9nb3pobmlrb3YuZ2l0aHViLmlvLzIwMTYvMDkvMTAvanVweXRlci1mZWF0dXJlcy5o
dG1sCgogIEp1cHl0ZXIgaGFzIGEgc2VyaW91cyBmbGF3LgogIEl0IGRvZXNuJ3QgcnVuIGluc2lk
ZSBFbWFjcy4KICAoTGlzdGVuLCBhbGwgaXMgZXZlbiB3b3JzZTogaXQgcnVucyBpbiBhIHdlYiBi
cm93c2VyICh5ZXMsIEkga25vdyBhYm91dCBsaW5rcyBhbmQgZXd3LikpCgogIEkgaGF2ZW4ndCB1
c2VkIGl0IG11Y2gsIHNvIGxldCdzIHJlbHkgb24gdGhlIG9waW5pb24gb2Ygc29tZW9uZSB3aG8g
aGFzOgogIGh0dHBzOi8vdG93YXJkc2RhdGFzY2llbmNlLmNvbS81LXJlYXNvbnMtd2h5LWp1cHl0
ZXItbm90ZWJvb2tzLXN1Y2stNGRjMjAxZTI3MDg2CiAgLSAxLiBJdCBpcyBhbG1vc3QgaW1wb3Nz
aWJsZSB0byBlbmFibGUgZ29vZCBjb2RlIHZlcnNpb25pbmcgKGZpbGVzIGFyZSBKU09OLCBtZXJn
aW5nIGlzIGRpZmZpY3VsdCkKICAtIDIuIFRoZXJlIGlzIG5vIElERSBpbnRlZ3JhdGlvbiwgbm8g
bGludGluZywgbm8gY29kZS1zdHlsZSBjb3JyZWN0aW9uIAogICAgICAgKHF1aXRlIHN1cnByaXNp
bmcgY29uc2lkZXJpbmcgdGhlIHBvcHVsYXJpdHksIGlzbid0IGl0PykKICAtIDMuIFZlcnkgaGFy
ZCB0byB0ZXN0IChub3QgdGhlIHByb2JsZW0gb2YgSnVweXRlciwgcmVhbGx5KQogIC0gNC4gVGhl
IG5vbi1saW5lYXIgd29ya2Zsb3cgb2YganVweXRlcgogIC0gNS4gSnVweXRlciBpcyBiYWQgZm9y
IHJ1bm5pbmcgbG9uZyBhc3luY2hyb25vdXMgdGFza3MKCiAgU29tZW9uZSBhbHNvIHNhaWQgdGhh
dCBtYW55IHNuaXBwZXRzIGluIEp1cHl0ZXIgYXJlIGhhcmQgdG8gbWFuYWdlLiBJIGJlbGlldmUg
aGltLiAKCiAgVGhlIGdvb2Qgc3R1ZmYgYWJvdXQgSnVweXRlcjoKICAtIDEuIGVhc3kgdG8gdXNl
IC8gbG93IGVudHJ5IGJhcnJpZXIsCiAgLSAyLiBpbnRlcmFjdGl2ZSBncmFwaHMsCiAgLSAzLiB2
aXN1YWxseSBkaXN0aW5jdCBjZWxscy4KCiAgUGxhbjogRW1hY3MgYmVhdHMgSnVweXRlciwgSnVw
eXRlciBkaWVzIGFuIGFnb25pemluZyBkZWF0aCwgZXZlcnlvbmUgc3RhcnRzIHVzaW5nIEVtYWNz
ICh0aGUgbGFzdCB0d28gcG9pbnRzIG1heSBiZSByZXZlcnNlZCkuCgogIFNheSwgaWYgdGhlIHN0
dWZmIGluIHRoZSBvcmctbW9kZSBzZWN0aW9uIGFuZCB0aGUgaW50ZXJhY3RpdmUgZ3JhcGhzIChh
dCBsZWFzdCBmb3IgbWF0cGxvdGxpYikgd2VyZSBpbXBsZW1lbnRlZCwgbWFraW5nIHNvbWUgc3Bl
Y2lhbCBlYXN5IG1vZGUgdy8gdGhlIGludHVpdGl2ZSBrZXliaW5kaW5ncyBjb3VsZCBjb252ZXJ0
IHNvbWUgSnVweXRlciBmb2xrcy4KCiAgVGhlIHRoaXJkIHBvaW50IG9uIGNlbGxzIGlzIGFsc28g
ZG9hYmxlIGlmIGxlbnNlcyBnZXQgc29tZSBhcmVhIGN1c3RvbWl6YXRpb25zIGxpa2UgcGFkZGlu
ZyBhbmQgY2VudGVyaW5nLiBBbmQsIGlmIG5lY2Vzc2FyeSwgdGhlIHdob2xlIG9yZyB0cmVlIGNv
dWxkIGJlIHZpZXdlZCB0aHJvdWdoIGxlbnNlcy4KCiAgQW5kIG9yZy1tb2RlIGNhbiBhbHJlYWR5
IGV4cG9ydCB0byBodG1sLCBmb3IgcHJlc2VudGF0aW9uIHB1cnBvc2VzLgoKICBJbiBzaG9ydDog
SSB0aGluayBtYWtpbmcgYSBnb29kIHJlcHJvZHVjaWJsZSByZXNlYXJjaCBlbnZpcm9ubWVudCwg
ZWFzaWx5IHVzYWJsZSBhbmQgZnVsbCBvZiBmZWF0dXJlcyBpcyBhIGdvb2QgZ29hbCBhbmQgY291
bGQgbHVyZSBzb21lIHBlb3BsZSBpbnRvIHVzaW5nIEVtYWNzIChpZiBvbmx5IHN1cGVyZmljaWFs
bHkgYXQgZmlyc3QpLgoKKiBJbXBsZW1lbnRhdGlvbgoKICBJIGFtIG5vdCBmYW1pbGlhciB3aXRo
IEVtYWNzIGludGVybmFscyB0byBzYXkgd2hhdCdzIGZlYXNpYmxlIG9mIHRoZSBwcm9wb3NlZCBz
dHJ1Y3R1cmUuCiAgCiAgQW5kIHRoZSB0d28gbWFqb3IgdGhpbmdzIGluIFtbTWVjaGFuaWNzXV0g
dGhhdCBzb21ld2hhdCBkZXBlbmQgb24gaG93IEVtYWNzIHdvcmtzIGFyZToKICAtIHNoYWRvd2lu
ZywgYW5kCiAgLSBtYWtpbmcgdHdvIGJ1ZmZlcnMgKHcvIGRpZmZlcmVudCBtb2Rlcykgc2hhcmUg
dGhlIHNhbWUgdGV4dCAoL2xpbmtlZCBidWZmZXJzLyBzaGFyZSB0aGUgc2FtZSAvc2hhcmVkIGJh
c2UvKS4KICAKKiBEaXNjdXNzaW9uCgogIE5vdGhpbmcgaW4gdGhpcyBwcm9wb3NhbCBpcyBzZXQg
aW4gc3RvbmUsIGZlZWwgZnJlZSB0byBjaGFuZ2UgaXQgdG8geW91ciBsaWtpbmcuCgogIFNvbWUg
bmFtaW5nIGlzIHByb2JhYmx5IGZsYXdlZC4KICBTb21lIHN0cnVjdHVyZXMgbWlnaHQgYmUgb3Zl
cmx5IGFtYml0aW91cyBvciB1bm5lY2Vzc2FyeS4KICBBbGwgaW1wbGVtZW50YXRpb24tcmVsYXRl
ZCBzdWdnZXN0aW9ucyBhcmUganVzdCBzdWdnZXN0aW9ucy4KCiAgU29tZSBleHBsYW5hdGlvbnMg
Y291bGQgYmUgbW9yZSBjbGVhci4KCiAgTW9yZSBhcHBsaWNhdGlvbnMgY291bGRuJ3QgaHVydC4K
CiAgVGhlIGVmZmVjdHMgb2YgdGhlIGltcGxlbWVudGF0aW9uIGFyZSBjb250YWluZWQgd2l0aGlu
IHRoZSBsZW5zLW1vZGUuCiAgV2hpY2ggbWVhbnMgdXNlcnMgc2hvdWxkIG5vdCBub3RpY2UgdGhl
IGRpZmZlcmVuY2UgdW5sZXNzIHRoZXkgdHVybiBvbiB0aGUgbGVucy1tb2RlLgogIElmIHRoZSBp
bXBsZW1lbnRhdGlvbiBpcyB1bmRlcnRha2VuLCB0aGlzIHdpbGwgYmUgZ29vZCBmb3IgdGVzdGlu
ZyBhbmQgaW50ZWdyYXRpb24uCgogIE92ZXJhbGwsIEkgdGhpbmsgdGhlIGFwcGxpY2F0aW9ucyBt
aWdodCBiZSB2ZXJ5IHdlbGwgd29ydGggdGhlIGVmZm9ydC4KICBFc3BlY2lhbGx5IGZvciBPcmct
bW9kZS4K
--00000000000030860305874af711--
Dmitrii Korobeinikov <dim1212k@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#35419; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.