From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitrii Korobeinikov Subject: Re: [Proposal] Source Blocks with Post-Extensions Date: Thu, 25 Apr 2019 01:05:43 +0600 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000001b848d05874b6430" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:48316) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJNDS-0000Mn-Qc for emacs-orgmode@gnu.org; Wed, 24 Apr 2019 15:06:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJNDR-0007aB-4v for emacs-orgmode@gnu.org; Wed, 24 Apr 2019 15:05:58 -0400 Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]:37936) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hJNDQ-0007WR-T9 for emacs-orgmode@gnu.org; Wed, 24 Apr 2019 15:05:57 -0400 Received: by mail-wr1-x42e.google.com with SMTP id f14so26066558wrj.5 for ; Wed, 24 Apr 2019 12:05:56 -0700 (PDT) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: "Berry, Charles" Cc: emacs-orgmode --0000000000001b848d05874b6430 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry for not answering these two days. You are right, that's an option. But I just don't think that's the best possible one - for usability. Introducing this would imply architectural decisions, so it might not be immediately clear if it's right or not. Especially that the improvement might not seem that big. So, I understand that. I have proposed buffer lenses today and they seem like something that can solve the issue from the user side. Hopefully they will get some traction. =D0=BF=D0=BD, 22 =D0=B0=D0=BF=D1=80. 2019 =D0=B3. =D0=B2 23:31, Berry, Char= les : > > > > On Apr 22, 2019, at 10:15 AM, Dmitrii Korobeinikov > wrote: > > > > Thank you! > > That's a handy technique and it does help. > > As I understand, there's no way to extend that to multiple lines? > > AFAICS, no there is no way to split the :epilogue arg to multiple lines. > > Of course, you can always follow a src block that provides a function wit= h > another src block that imports the code via noweb and then tests the > function with as many lines of code as you need. > > Chuck > > > > --0000000000001b848d05874b6430 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for not answering these two days.

You are right, that's an option.
But I just d= on't think that's the best possible one - for usability.
=
Introducing this would imply architectural decisions, so it = might not be immediately clear if it's right or not.
Especial= ly that the improvement might not seem that big.
So, I understand= that.

I have proposed buffer lenses today and the= y seem like something that can solve the issue from the user side. Hopefull= y they will get some traction.

=D0=BF=D0=BD, 22 =D0=B0=D0=BF=D1=80. 20= 19 =D0=B3. =D0=B2 23:31, Berry, Charles <ccberry@ucsd.edu>:


> On Apr 22, 2019, at 10:15 AM, Dmitrii Korobeinikov <dim1212k@gmail.com> wrote:<= br> >
> Thank you!
> That's a handy technique and it does help.
> As I understand, there's no way to extend that to multiple lines?<= br>
AFAICS, no there is no way to split the :epilogue arg to multiple lines.
Of course, you can always follow a src block that provides a function with = another src block that imports the code via noweb and then tests the functi= on with as many lines of code as you need.

Chuck



--0000000000001b848d05874b6430--