4 inline replies:

On 2025-03-15 19:39, Ihor Radchenko wrote:
pinmacs <pinm...@cas.cat> writes:

There is a special case that might need a clarification in the orgmode
implementation and/or the org-syntax [0]

The affiliated keyword, when it's before a dynamic block [1] it does not
work.

Example:

#+NAME: test
#+BEGIN: something-that-generates-a-table
| State | ID | Task    | RESPONSIBLE |
|-------+----+---------+-------------|
| TODO  | T1 | [[file:/tmp/affiliated-keyword-dynamic-block.org::*My
task][My task]] | Laura       |
| TODO  | T2 |
[[file:/tmp/affiliated-keyword-dynamic-block.org::*Task2][Task2]] |
Anna        |
#+END:
What do you mean by "does not work"? It works just fine. You can refer
to it - it is a name for the dynamic block itself.

1/4
OK, sorry I am so export-centric now that I missed that you might want to refer to the dynamic block itself, true.

It must be

#+BEGIN: something-that-generates-a-table
#+NAME: test
| State | ID | Task    | RESPONSIBLE |
|-------+----+---------+-------------|
| TODO  | T1 | [[file:/tmp/affiliated-keyword-dynamic-block.org::*My
task][My task]] | Laura       |
| TODO  | T2 |
[[file:/tmp/affiliated-keyword-dynamic-block.org::*Task2][Task2]] |
Anna        |
#+END:
Maybe we can arrange Org to leave manually added affiliated keywords as
is when updating the dblock, similar to what colview does.

Another idea is https://list.orgmode.org/orgmode/871qaer7bo.fsf@localhost/

2/4
Regretably I could not try the patch, is it because I am using 9.7.10 ? [1]. looks like a nice proposal, that's a neat patch. I only see a problem that some of the affiliated keywords might refer to identify a specific element, such as NAME, then, that would cause ID collisions?

That's what makes me think it's better to have something general on preserving that kind of keywords for the generated elements; that helps in terms of export

#+NAME: my dynamic-block
#+begin: clocktable :scope file :maxlevel 2 :org-dblock-prepend (:attr_latex)
#+NAME: my dynamic-block
#+CAPTION: Clock summary at [2024-01-18 Thu 16:23]
| Headline   | Time    |
|------------+---------|
| *Total time* | *0h 0min* |
#+end:


[1] I would like to switch easily between different orgmode versions nightly, etc.; any suggestion? Something like ~(use-package org :ensure nil :vc (:url "https://git.savannah.gnu.org/cgit/emacs/org-mode.git"; :rev :newest))~ and then ~git checkout~ here and there?


I think it is reasonable to say that a NAME given before a BEGIN dynamic
block element, applies to the thing that the dynamic block generates

The ability to clearly identify elements of exported html document is
nice to improve the visibility of things, for example here I experienced
how a table that represents a kanban might be better visualized using
css and js [2]
Then, it will be impossible to refer to the dynamic block itself.

3/4
Agree, that's true, thanks for your feedback, now I agree, there are two elements to identify, dynamic block and its result

Coming back to the org syntax, I suspect that the table rows are not an
exception, #+NAME before table rows is specifically what I am using to
identify the table, and what does not work when there is in the middle
the dynamic block
May you elaborate?

4/4
In html export (maybe other exporters too), the ~#+NAME: mytable~ results in, some html such as ~<table id="mytable" border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">~; that way, you can identify the table with CSS and Javascript

There are other ways to achieve the same thing: ~#+ATTR_HTML: :id somefixedid~ exports to ~<table id="somefixedid" border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">~

Reply via email to