* transclusion, tangling, flycheck/flymake, etc.
@ 2021-11-03 8:15 Greg Minshall
2021-11-03 12:01 ` Ihor Radchenko
0 siblings, 1 reply; 4+ messages in thread
From: Greg Minshall @ 2021-11-03 8:15 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Noboru Ota, emacs-orgmode
Ihor,
(Noboru Ota -- i do find transclusion very interesting.)
> 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.
in general, i would like to keep bits of my code in a single .org file,
maybe broken into separate source blocks, with preceding/succeeding
commentary. then, pulled together in a tangle by a =:tangle= property
(within a subtree) and/or =<<noweb>>= references.
my thought about flycheck, flymake, whatever, is that (optionally) a
silent, background, =tangle= and/or =<<noweb>> expansion= would take
place to produce a "full source file buffer"[*], then the narrowed
version of that (corresponding to the part where =C-c '= was issued)
buffer is presented for the user's editing convenience.
your thought here, iiuc, is that source files would live in the file
system, and be transcluded into the .org file. i can see the utility of
that. but, i would miss =<<noweb>>= and also the ability to break the
source code into small chunks for purposes of documentation.
obviously, the two approaches are not mutually exclusive. but, partly
to make sure i understand your suggestion, i thought i'd mention it.
cheers, Greg
[*] in my scenario, i would find it convenient for the buffer the user
edits to have a file name, with the tangled file's extension; i have a
'package-in-waiting' which has to do some head standing to figure out
the appropriate language [parser] to send to a program =prettier=.
https://git.sr.ht/~minshall/prettied-diff
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: transclusion, tangling, flycheck/flymake, etc.
2021-11-03 8:15 transclusion, tangling, flycheck/flymake, etc Greg Minshall
@ 2021-11-03 12:01 ` Ihor Radchenko
2021-11-03 12:55 ` Greg Minshall
2021-11-06 10:55 ` Noboru Ota
0 siblings, 2 replies; 4+ messages in thread
From: Ihor Radchenko @ 2021-11-03 12:01 UTC (permalink / raw)
To: Greg Minshall; +Cc: Noboru Ota, emacs-orgmode
Greg Minshall <minshall@umich.edu> writes:
> my thought about flycheck, flymake, whatever, is that (optionally) a
> silent, background, =tangle= and/or =<<noweb>> expansion= would take
> place to produce a "full source file buffer"[*], then the narrowed
> version of that (corresponding to the part where =C-c '= was issued)
> buffer is presented for the user's editing convenience.
You are right. That's what I had in mind. Though noweb <<name()>>-style
references may need to be transcluded without expanding - they may be
computationally expensive.
> your thought here, iiuc, is that source files would live in the file
> system, and be transcluded into the .org file. i can see the utility of
> that. but, i would miss =<<noweb>>= and also the ability to break the
> source code into small chunks for purposes of documentation.
No. I did not imply that source files will be transcluded into the .org
file. Currently, .org file is the source of the code (unless you use
org-babel-detangle). I was thinking that C-c ' will trigger generating a
temporary prog-mode buffer (according to .org file!). It is not a good
idea to associate the temporary buffer with actual file because tangling
may involve expanding noweb references. Noweb sometimes require long
computations or even access to remote servers. I think that it's better
to trigger tangle process manually by default.
Best,
Ihor
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: transclusion, tangling, flycheck/flymake, etc.
2021-11-03 12:01 ` Ihor Radchenko
@ 2021-11-03 12:55 ` Greg Minshall
2021-11-06 10:55 ` Noboru Ota
1 sibling, 0 replies; 4+ messages in thread
From: Greg Minshall @ 2021-11-03 12:55 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Noboru Ota, emacs-orgmode
Ihor,
thanks for the clarification.
maybe, in that ideal world, <<name()>> might expand, optionally.
another point: watching Noboru's "most recent" (9?) video, i see another
feature of his transclusion: a way to say, "this is *exactly* like a
source block -- with language, :results, :tangle, :var, etc.,
... except, the actual code is in some other file: when i hit =C-c C-c=
here, please set up (based on language), include that source, execute
it".
that also might be interesting. if i were to think of that, i'd say the
verb might *not* be =#+transclude=, but, rather, something source
specific (=#+src_ref=?). but, it might allow a =:transclude yes=
property.
cheers, Greg
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: transclusion, tangling, flycheck/flymake, etc.
2021-11-03 12:01 ` Ihor Radchenko
2021-11-03 12:55 ` Greg Minshall
@ 2021-11-06 10:55 ` Noboru Ota
1 sibling, 0 replies; 4+ messages in thread
From: Noboru Ota @ 2021-11-06 10:55 UTC (permalink / raw)
To: Ihor Radchenko, Greg Minshall; +Cc: emacs-orgmode
Ihor Radchenko <yantar92@gmail.com> writes:
> Greg Minshall <minshall@umich.edu> writes:
>
>> my thought about flycheck, flymake, whatever, is that (optionally) a
>> silent, background, =tangle= and/or =<<noweb>> expansion= would take
>> place to produce a "full source file buffer"[*], then the narrowed
>> version of that (corresponding to the part where =C-c '= was issued)
>> buffer is presented for the user's editing convenience.
>
> You are right. That's what I had in mind. Though noweb <<name()>>-style
> references may need to be transcluded without expanding - they may be
> computationally expensive.
>
>> your thought here, iiuc, is that source files would live in the file
>> system, and be transcluded into the .org file. i can see the utility of
>> that. but, i would miss =<<noweb>>= and also the ability to break the
>> source code into small chunks for purposes of documentation.
>
> No. I did not imply that source files will be transcluded into the .org
> file. Currently, .org file is the source of the code (unless you use
> org-babel-detangle). I was thinking that C-c ' will trigger generating a
> temporary prog-mode buffer (according to .org file!). It is not a good
> idea to associate the temporary buffer with actual file because tangling
> may involve expanding noweb references. Noweb sometimes require long
> computations or even access to remote servers. I think that it's better
> to trigger tangle process manually by default.
This part of the discussion is beyond me; apologies for not being able
to engage in a useful way. I don't consider myself a programmer so the
use of Org-transclusion to achieve some elements of IDE (integrated
development environment, I assume) experience is something I cannot
fully address.
As an attempt to clarify my original intent, this use from Greg is what
I had in mind: "source files would live in the file system, and be
transcluded into the .org file". This lets the technical writer (for
example) "break the source code into small chunks for purposes of
documentation." I have had a comment from a user that that's exactly
this person is doing.
So the direction is *from* the source file *to* an org file. What Ihor
seems to be suggesting is the other direction: *from* an org file *to* a
(temporary) source file. I do not think the latter is possible with the
current state of Org-transclusion.
Noboru
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-11-06 10:56 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-03 8:15 transclusion, tangling, flycheck/flymake, etc Greg Minshall
2021-11-03 12:01 ` Ihor Radchenko
2021-11-03 12:55 ` Greg Minshall
2021-11-06 10:55 ` Noboru Ota
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).