Hi, Daniel, Sorry, I've been absent for a bit.
Daniel Tocoda <[email protected]> writes: > This is the actual item, which is annotated with keywords: > > #+DOWNLOADED: screenshot @ 2026-05-15 13:25:28 > #+attr_org: :width 400px > [[attachment:2026-05-15_13-25-28_screenshot.png]] > > It would feel normal to me to have these three associated items > consecutively aligned. Or optionally(!), if someone prefers, have it > with a separating blank line. Hence, I'd assume both should be > possible. > > Therefore I am still somewhat puzzled, also because this seems to be > like a new markdown syntax rule for me. > > For clarification I'd also like to add that the above entry was > auto-generated by function org-download-clipboard (from org-download > package). > > Would you point towards org-download, namely using outdated syntax > rules for the generated attachment text or can you agree with my > personal flavour, i.e. having these three lines associated with the > actual downloaded attachment, treated somehow like a proper block > (with no separating blank lines)? Well, it's just a warning, and one you can probably ignore, as I don't think there's any risk of /Org/ being confused in /this/ particular case. There are however cases where placing an 'independent' keyword before an 'affiliated' one will cause unintended behavior. (See https://list.orgmode.org/orgmode/87v8ticm0l.fsf@localhost/ in the thread that motivated this and several other additions to org-lint.) I see why it makes sense for you that the DOWNLOADED keyword added by org-download.el should be visually grouped with the following element and keywords affiliated to it, but it is not one of the keywords recognized as 'affiliated'. Ihor will have a better idea than me what the appropriate way for a third-party package to register a new affiliated keyword might be. It hasn't been made easy,[1] and my feeling is it's best avoided if possible. In this case, maybe they could have avoided it. I don't know what org-download.el uses the DOWNLOADED keyword for, but it looks redundant -- in your example, it duplicates information already found in the linked file name. Regards, Christian [1] Affiliated keywords are recognized by the regexp in 'org-element--affiliated-re'. The docstring says not to mess with it but to set the underlying 'org-element-affiliated-keywords' instead. However, since the regexp is constructed and defined as a constant when org-element.el is loaded, you need to re-evaluate the defconstant for any change in 'org-element-affiliated-keywords' to take effect.
