Hi Christian, thanks for the thorough explanation!
I agree with the duplicated information introduced with the additional keyword. The bottom-line is that org-download should (somehow) register the additional keyword. I'll consider filing the issue there. For a workaround I also consider removing every +:DOWNLOADED... line in my buffers or accept the (repeated) warnings issued by org-lint. Thanks, Daniel Am 29. Mai 2026 11:06:09 MESZ schrieb Christian Moe <[email protected]>: >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. > -- Von /e/OS E-Mail gesendet.
