From: Ihor Radchenko <yantar92@posteo.net>
To: Mehmet Tekman <mtekman89@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [ANN] lisp/ob-tangle-sync.el
Date: Thu, 18 May 2023 10:30:37 +0000 [thread overview]
Message-ID: <87jzx6ylrm.fsf@localhost> (raw)
In-Reply-To: <87a5y3vzpe.fsf@gmail.com>
Mehmet Tekman <mtekman89@gmail.com> writes:
>> See the above 3 examples: (1) "foo.txt" shadowed by "no"; (2) "no"
>> shadowed by "foo.txt"; (3) "no" shadowed by "foo.txt" then shadowed by
>> "yes".
>>
>> You can also consider "foo.txt" shadowed by "bar.txt" and other
>> variations.
>
> I've created a small patch that contains a single ert test function that
> checks an example org file I made (based on the above as well as my own
> toy file) to try to validate the `org-babel-merge-params' rewrite.
>
> I've attached it below in case you want to test it...
Is the patch testing your code?
(Note on the ert tests: we generally prefer `org-test-with-temp-text' -
the old approach with test IDs is not very readable because one needs to
search those IDs manually when debugging test failures.)
> ...but there were a few cases where I wasn't entirely sure what the
> result of the merge was supposed to be:
>
> For example, a document with:
>
>> #+TITLE: Header tests
>> #+PROPERTY: header-args :tangle /tmp/default_tangle.txt
>>
>> * Inherit tangle header from document
>>
>> #+begin_src conf
>> (:tangle . /tmp/default_tangle.txt)
>> #+end_src
>
> I would expect the output of:
>
> (assoc :tangle (nth 2 (org-babel-get-src-block-info)))
>
> within that block to evaluate to the contents written in that
> block. Instead it evaluates to `(:tangle . no)' when run in a vanilla
> Emacs. Is this expected?
You forgot C-c C-c on the PROPERTY line, or re-opening the file.
#+PROPERTY lines are not automatically parsed when you add them. They
are only parsed upon explicit request (C-c C-c) or when opening the
file.
> Another example:
>
>> * Header args overwritten by local header
>> :PROPERTIES:
>> :header-args: :tangle "foo.txt"
>> :END:
>> #+begin_src :tangle yes
>> (:tangle . foo.txt)
>> #+end_src
>>
>> ** Inherited header
>>
>> #+begin_src :tangle "file with spaces.txt"
>> (:tangle . "file with spaces.txt")
>> #+end_src
>
> The first block correctly gives "foo.txt" under vanilla Emacs, but the
> second block also gives "foo.txt". Is this expected behaviour?
You forgot to specify the source block languages. Org sees your example
as two src blocks of language ":tangle" with no proper header arguments.
(See M-x org-lint)
If you add a language, like
#+begin_src conf :tangle yes
(:tangle . foo.txt)
#+end_src
The expected result is (:tangle . "yes") for the first block and
(:tangle . "file with spaces.txt") for the second block.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
next prev parent reply other threads:[~2023-05-18 10:28 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-26 14:48 [ANN] lisp/ob-tangle-sync.el Mehmet Tekman
2023-04-26 16:43 ` John Wiegley
2023-04-26 18:43 ` Mehmet Tekman
2023-04-27 2:55 ` Ruijie Yu via General discussions about Org-mode.
2023-04-27 6:27 ` Mehmet Tekman
2023-04-28 10:57 ` Ruijie Yu via General discussions about Org-mode.
2023-04-28 11:28 ` Mehmet Tekman
2023-05-02 20:43 ` Mehmet Tekman
2023-05-03 2:31 ` Ruijie Yu via General discussions about Org-mode.
2023-05-03 7:53 ` Mehmet Tekman
2023-05-03 8:34 ` Mehmet Tekman
2023-05-03 8:44 ` Ihor Radchenko
2023-05-03 11:43 ` Ihor Radchenko
2023-05-03 13:54 ` Mehmet Tekman
2023-05-03 18:06 ` Ihor Radchenko
2023-05-03 15:05 ` Mehmet Tekman
2023-05-03 15:21 ` Ihor Radchenko
[not found] ` <87lei577g4.fsf@gmail.com>
[not found] ` <87lei5v1fg.fsf@localhost>
[not found] ` <87fs8duyae.fsf@localhost>
2023-05-09 14:03 ` Mehmet Tekman
2023-05-10 9:46 ` Ihor Radchenko
2023-05-10 11:06 ` mtekman89
2023-05-10 11:32 ` Ihor Radchenko
2023-05-10 16:20 ` Mehmet Tekman
2023-05-12 12:33 ` Ihor Radchenko
2023-05-16 12:49 ` Mehmet Tekman
2023-05-16 18:57 ` Ihor Radchenko
2023-05-17 13:45 ` Mehmet Tekman
2023-05-18 10:30 ` Ihor Radchenko [this message]
2023-05-19 7:10 ` Mehmet Tekman
2023-07-15 12:38 ` Ihor Radchenko
2023-07-16 9:42 ` Mehmet Tekman
2023-07-17 11:29 ` Mehmet Tekman
2023-07-18 8:47 ` Ihor Radchenko
2023-07-21 8:48 ` Mehmet Tekman
2023-07-22 8:02 ` Ihor Radchenko
2023-07-25 11:19 ` Mehmet Tekman
2023-07-25 16:19 ` Ihor Radchenko
2023-07-31 13:41 ` Mehmet Tekman
2023-07-31 16:38 ` Ihor Radchenko
2023-07-31 20:11 ` Mehmet Tekman
2023-08-01 7:54 ` Ihor Radchenko
2023-08-01 8:49 ` Mehmet Tekman
2023-08-01 9:30 ` Ihor Radchenko
2023-08-01 18:19 ` Bastien Guerry
2023-08-02 7:29 ` Ihor Radchenko
2023-08-02 14:46 ` Mehmet Tekman
2023-08-03 6:32 ` Mehmet Tekman
2023-08-03 7:35 ` Ihor Radchenko
2023-08-03 8:08 ` Mehmet Tekman
2023-08-03 8:16 ` Ihor Radchenko
[not found] ` <CAHHeYzL6Z5_gGbTUrNzKDh5swgCSQiYsSj3Cs0gFy_d=eXbSBA@mail.gmail.com>
[not found] ` <87o7jo1q2s.fsf@localhost>
2023-08-03 8:46 ` Mehmet Tekman
2023-08-04 7:41 ` Mehmet Tekman
2023-08-04 8:09 ` Ihor Radchenko
2023-08-04 13:14 ` Mehmet Tekman
2023-08-04 16:34 ` Mehmet Tekman
2023-08-06 9:07 ` Ihor Radchenko
2023-08-08 19:41 ` Mehmet Tekman
2023-08-08 19:51 ` Ihor Radchenko
2023-08-08 20:04 ` Mehmet Tekman
2023-08-09 8:04 ` Ihor Radchenko
2023-08-05 8:48 ` Ihor Radchenko
2023-08-05 22:54 ` Mehmet Tekman
2023-11-10 9:41 ` Ihor Radchenko
2023-11-10 9:53 ` Mehmet Tekman
2023-12-11 13:40 ` Ihor Radchenko
2023-12-11 14:28 ` Mehmet Tekman
2024-04-29 5:16 ` João Pedro
2024-04-29 7:43 ` Mehmet Tekman
2024-04-29 16:21 ` João Pedro
2024-05-05 16:47 ` Mehmet Tekman
2024-05-06 1:56 ` João Pedro
2024-05-06 12:53 ` Ihor Radchenko
2024-05-06 16:28 ` Mehmet Tekman
2024-05-06 12:45 ` Ihor Radchenko
2024-06-23 10:48 ` Ihor Radchenko
2024-07-23 8:47 ` Ihor Radchenko
2023-04-27 12:02 ` Ihor Radchenko
2023-04-27 13:01 ` Mehmet Tekman
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=87jzx6ylrm.fsf@localhost \
--to=yantar92@posteo.net \
--cc=emacs-orgmode@gnu.org \
--cc=mtekman89@gmail.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).