emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Noboru Ota <me@nobiot.com>
Cc: orgmode <emacs-orgmode@gnu.org>
Subject: Re: Introducing Org-transclusion
Date: Mon, 01 Nov 2021 21:24:01 +0800	[thread overview]
Message-ID: <87v91c9fgu.fsf@localhost> (raw)
In-Reply-To: <87sfwgme9s.fsf@nobiot.com>

Noboru Ota <me@nobiot.com> writes:

>> You have my +100500 to have this package as part of Org :D
>
> Thank you again :) Is there anything I can/should do to make this
> happen?  I would be happy to email the whole package as a "patch" for
> code review, if this were the way but I feel that might clutter this
> mailing list too much with a large amount of text (?)

Attached patches is the workflow in this mailing list. Do not worry
about cluttering. Clutter is meaningless text, not a patch. We have
recommendations about submitting new patches at
https://orgmode.org/worg/org-contribute.html

Once you submit _something_, core maintainers will be more inclined to
jump in and provide their opinion on including the new feature.

>> 2. A much faster tangle system. If we can directly transclude and sync
>>    contents of source blocks with actual programming language buffer,
>>    C-c ' can trivially support flycheck-mode and provide a more
>>    IDE-like experience while still benefiting from literate programming
>>    style.
>
> It has ":src lang" property and can transclude a specific range of
> source code into Org's source block. It is essentially read-only copy of
> the original, and you can use "C-c C-c" as a normal Org source block to
> execute/evaluate it.

I actually had something slightly different in mind. If we have a way to
copy and sync text between different places, we can as well compile all
the related source blocks into a temporary buffer in the correct
prog-mode. Then, C-c ' can simply jump to that buffer with all the code
from different source blocks bundled together. Changes in the temporary
buffer can then be synced on exit.

> For flycheck-mode, I am not sure; I don't use it (I use built-in
> flymake).  It may be an interesting experiment for me, too.  One thing
> is that transcluded source blocks are read-only.  I think it will
> require a bit of work to get the correction to work on both the
> transclusion and source buffers.

Can be flymake as well. The problem with current implementation of
source blocks is that only the code from individual source block is
visible for flymake. Imagine the following

#+begin_src emacs-lisp
(progn
 (message "A")
#+end_src

#+begin_src emacs-lisp
 (message "B"))
#+end_src

If you open the top source block with C-c ', flymake will report errors
because of unmatched parenthesis. The errors will be correct from
flymake's perspective because all flymake will see is text in the first
source block. However, the code is correct when you tangle the file.

If we can have a single buffer with all the source blocks, C-c ' can
simply jump to that buffer and narrow to region representing the current
source block. flymake will behave correctly because all the code will be
present in the buffer. Moreover, the user may widen the buffer
conveniently see all the code together. Tangling will be mostly a
question of simply saving the temporary buffer.

Trnasclusion is required to correctly keep the temporary code buffer and
actual Org file in sync.

Of course, things like noweb will be tricky. You may need something
similar to bi-directional text transformation like implemented in
lentic, when changes in text are not simply mirrored, but the text is
also transformed when syncing transcluded regions. You implemented
something similar in the :level parameter.

> Org-transclusion might provide some steps forward for some of the
> desired functionality discussed in these threads.  Especially for the
> "cloning" a body of text across multiple buffers, I have factored out
> this part and created a stand-alone library called "Text-clone".  It is
> available in the same repository at
> https://github.com/nobiot/org-transclusion/blob/main/docs/text-clone.md.

I noticed that you are using overlays in text-clone. It may potentially
cause slowdown in large Org buffers. Of course, it does not mean that
org-transclusion should not be accepted. Just something that may be
optimised.

Best,
Ihor


  reply	other threads:[~2021-11-01 13:23 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-30 11:51 Introducing Org-transclusion Noboru Ota
2021-10-30 12:31 ` Juan Manuel Macías
2021-11-01  9:17   ` Noboru Ota
2021-10-30 13:59 ` Ihor Radchenko
2021-11-01  9:11   ` Noboru Ota
2021-11-01 13:24     ` Ihor Radchenko [this message]
2021-11-06 10:43       ` Noboru Ota
2021-11-08 15:07         ` Ihor Radchenko
2021-11-10 21:09           ` Noboru Ota
2021-11-14  8:22             ` Ihor Radchenko
2021-11-14  9:35               ` Ihor Radchenko
2021-11-01 20:07     ` Thomas Paulsen
2021-11-01 21:01       ` Noboru Ota
2021-11-02  5:17     ` Timothy
2021-11-05 19:53       ` Noboru Ota
2021-11-05 21:56         ` Tim Cross
2021-11-05 23:20           ` Timothy
2021-11-06 10:14             ` Noboru Ota
2021-11-06 10:22               ` Tim Cross
2021-11-06 11:49                 ` Noboru Ota
2021-11-05 17:11 ` Uwe Brauer
2021-11-05 19:24   ` Noboru Ota
2021-11-05 20:15     ` Uwe Brauer
2021-11-05 23:02       ` Noboru Ota
2021-11-06 14:01         ` Uwe Brauer
2021-11-06 14:25         ` Ihor Radchenko
2021-11-06 14:54           ` Noboru Ota
2021-11-06 15:49             ` Uwe Brauer
2021-11-07  7:34               ` Ihor Radchenko
2021-11-07  8:07                 ` Uwe Brauer
2021-11-07  8:30                   ` Ihor Radchenko
2021-11-07 13:25                     ` Uwe Brauer
2021-11-07 13:41                       ` Ihor Radchenko
2021-11-07 13:56                         ` Uwe Brauer
2021-11-05 19:59   ` Noboru Ota
2021-11-05 20:13     ` Uwe Brauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v91c9fgu.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=me@nobiot.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).