Lei Zhe writes:
> Yes, this definitely makes sense, but we need to get rid of the
> `only-this-block` parameter here, since the result of
> `org-babel-tangle-single-block` needs to be a nested list. This must
> be a breaking change that we discussed before.
I have ideas how to avoid that, but le
Hi Ihor,
I’m resending this email because I realized I forgot to include
emacs-orgmode. Apologies.
> Instead, we can handle `org-babel-tangle-use-relative-file-links' in
> `org-babel-tangle-single-block' itself, post-processing the link there.
> Then, we can, say, store the processed link in PARA
Ihor Radchenko writes:
> The easiest solution is thus getting rid of the
> `org-babel-tangle-use-relative-file-links' branch in
> `org-babel-tangle--unbracketed-link'.
> ...
It has been a while since the last message in this thread.
Lei Zhe, do you need any further help with the patch?
--
Ihor
Lei Zhe writes:
>> I'd rather avoid such non-deterministic return value.
>> Having different return values depending on the :tangle parameter is,
>> IMHO, not the best design. I'd rather go with my idea of adding a new
>> optional argument that will turn on the new return value convention and
>>
Hi Ihor, thanks for the review.
> In org-babel-tangle-collect-blocks:
> ob-tangle.el:494:10: Warning: Unused lexical variable ‘buffer-fn’
> In org-babel-tangle--concat-targets:
> ob-tangle.el:572:6: Warning: value from call to ‘remove’ is unused
Fixed, thanks for pointing those out.
> Please add
Lei Zhe writes:
>> how can users of `org-babel-tangle-single-block' figure out which variant of
>> the return value is to expect?
> It returns the correct relative or absolute link that users can expect
> when :tangle is a single path, while it returns an absolute link when
> :tangle is a list.
Lei Zhe writes:
>>> you can simply return multiple (file-name src-lang start-line file link
>>> source-name params body comment) items.
>>> (file-name1 ... link1 ...)
>>> (file-name2 ... link2 ...)
>
> I don't get it, shouldn't it be as shown below? Then the returned
> results got changed.
> ((f
> how can users of `org-babel-tangle-single-block' figure out which variant of
> the return value is to expect?
It returns the correct relative or absolute link that users can expect
when :tangle is a single path, while it returns an absolute link when
:tangle is a list.
It’s a tradeoff, though, b
Lei Zhe writes:
> Thanks for your suggestion. Or, return bare only if :tangle has
> multiple targets in `org-babel-tangle--unbracketed-link', then we
> can leave everything else unchanged.
Then, how can users of `org-babel-tangle-single-block' figure out which
variant of the return value is to e
oops, the logic is incorrect, please check the new patch.
llcc
On Sat, Mar 22, 2025 at 9:13 AM Lei Zhe wrote:
>
> Thanks for your suggestion. Or, return bare only if :tangle has
> multiple targets in `org-babel-tangle--unbracketed-link', then we
> can leave everything else unchanged.
> please fi
Thanks for your suggestion. Or, return bare only if :tangle has
multiple targets in `org-babel-tangle--unbracketed-link', then we
can leave everything else unchanged.
please find the updated patch attached. Let me know your thoughts.
llcc
On Fri, Mar 21, 2025 at 2:48 AM Ihor Radchenko wrote:
>
Lei Zhe writes:
> Then, for the returned value `result' of org-babel-tangle-single-block:
> The original function returns (file-name1 ... link1 ...).
> The proposed function returns ((file-name1 ... link1 ...)).
>
> If we change the function behavior, the difference must be a breaking change.
I
Then, for the returned value `result' of org-babel-tangle-single-block:
The original function returns (file-name1 ... link1 ...).
The proposed function returns ((file-name1 ... link1 ...)).
If we change the function behavior, the difference must be a breaking change.
llcc
On Thu, Mar 20, 2025 a
>> you can simply return multiple (file-name src-lang start-line file link
>> source-name params body comment) items.
>> (file-name1 ... link1 ...)
>> (file-name2 ... link2 ...)
I don't get it, shouldn't it be as shown below? Then the returned
results got changed.
((file-name1 ... link1 ...)
(fi
Lei Zhe writes:
> I realized that it's challenging to handle the error properly if the
> return value of org-babel-tangle-single-block remains unchanged.
>
> Consider your code block:
> #+begin_src emacs-lisp :tangle '("1.el" "2.el")
> (+ 1 2)
> #+end_src
>
> In the org-babel-tangle--unbracke
Thanks.
I realized that it's challenging to handle the error properly if the
return value of org-babel-tangle-single-block remains unchanged.
Consider your code block:
#+begin_src emacs-lisp :tangle '("1.el" "2.el")
(+ 1 2)
#+end_src
In the org-babel-tangle--unbracketed-link function, if
org
Lei Zhe writes:
>>>As for the patch, I tried to run it with simple example and got an error.
> I tested on my side and didn't see any failures. Would you mind
> sharing the error details?
1. git clone ...
2. cd /path/to/org/source
3. apply the patch
4. make repro
5. C-x C-f /tmp/test.org
6. Inse
>>> With this change, ONLY-THIS-BLOCK = nil is ignored. This will cause
>>> problems.
>>> I intended to remove the ONLY-THIS-BLOCK part since it will no longer
>>> be used in the official code.
>> It is still used by `org-babel-tangle' itself.
I meant the signature will be removed throughout the
Thanks Ihor, Phil
I updated the patch to address your comments.
>> You are dropping this logic completely in the patch. Without this part
>> :tangle no may not work.
I restored the logic in the new patch.
>> With this change, ONLY-THIS-BLOCK = nil is ignored. This will cause problems.
I intende
Lei Zhe writes:
>>> With this change, ONLY-THIS-BLOCK = nil is ignored. This will cause
>>> problems.
> I intended to remove the ONLY-THIS-BLOCK part since it will no longer
> be used in the official code.
It is still used by `org-babel-tangle' itself.
> ... However, after searching on GitHub,
References:
User-Agent: mu4e 1.12.8; emacs 30.1
Date: Tue, 11 Mar 2025 21:38:00 +0100
* [2025-03-09 15:12 +0800] Lei Zhe :
Hello Lei,
> It'll make the tangle system more flexible, and I would be glad to
> see it included in the next release.
I would be glad too.
> I wanted to check i
Lei Zhe writes:
> This patch is the first step in resolving the feature for tangling
> source blocks to multiple targets.
> I would appreciate any feedback.
Thanks for the patch!
> - (let* ((info (org-babel-get-src-block-info 'no-eval))
> -(src-lang (nth 0 info))
> -
Since Phil hasn't responded for almost two weeks,
I would like to submit the patch first.
This patch is the first step in resolving the feature for tangling
source blocks to multiple targets.
I would appreciate any feedback.
llcc
On Sun, Feb 23, 2025 at 9:05 PM Lei Zhe wrote:
>
> Hi Phil,
>
> T
Hi Phil,
Thank you for sharing the proposal and patch.
It'll make the tangle system more flexible, and I would be glad to
see it included in the next release. As it has been some time since
your last response, I wanted to check in to see if you’re still planning
to complete the patch. If not, I
Phil writes:
> All right. So I have it working for single blocks by
> modifying only `org-babel-tangle' with :tangle-directory
> accepting a single string or a list, e.g.
>
> :tangle-directory '("dir1" "/ssh:host1:/dir2" "/-::/etc")
>
> The option is ignored for file-wide tangle.
>
> What do you
* [2024-07-12 13:23] Ihor Radchenko:> Phil writes:
To tangle to multiple destinations
a logic extension of the existing tangle mechanism.
1) Introduce :tangle-directory parameter that defines
relative directory to be used as tangle target; this
directory, if defined, will be used instea
Phil writes:
> The ability to tangle to multiple destinations is a very convenient way
> to manage cluster configurations. No, it's more than that: it's an
> *awesome* way to deploy and keep clusters configs and repros well
> organized.
> ...
> #+begin_example
> #+begin_src elisp :n-tangle "hosts
Hi,
The ability to tangle to multiple destinations is a very convenient way
to manage cluster configurations. No, it's more than that: it's an
*awesome* way to deploy and keep clusters configs and repros well
organized.
The following *org-babel-n-tangle*, is just a small derivation
of *org-babel
28 matches
Mail list logo
