The difficulty here is that ID attribute values are not easily predictable, and dependent on the source block's position in the document. This complicates tasks like styling a specific source block -- with the previous ID generation method, this could be reliably done with an ID selector; with the current behavior, that's no longer true.
Can you provide some insight on why the behavior was changed? I'd be happy to expand the scope of my bug report to cover whatever code relies on the change. Thanks!
--
Aaron Miller
Mobile: (443) 902-4702
Hello,Aaron Miller <me@aaron-miller.me> writes:Expected: When exporting an Org document with named source blocks to
HTML, each <pre> generated to contain a source block has an ID attribute
matching the source block's name.
Actual: Instead, ID attributes come out with values like "orgsrcblock1".
Test case:
--- >8 cut here ---
#+TITLE: bug test case
#+NAME: a-source-block
#+BEGIN_SRC emacs-lisp :eval never
;; hi
#+END_SRC
--- 8< cut here ---
Expected result (its salient subset):
--- >8 cut here ---
<pre class="src src-emacs-lisp" id="a-source-block">
;; hi
</pre>
--- 8< cut here ---
Actual result (its likewise):
--- >8 cut here ---
<pre class="src src-emacs-lisp" id="orgsrcblock1">
;; hi
</pre>
--- 8< cut here ---
Note the erroneous ID attribute value.
The attribute is intended.The issue here is that, in `org-html-src-block' and
`org-html-inline-src-block', the fallback behavior for ID attribute
value is implemented in terms of `and', rather than `or'. Since `and'
short-circuits only when it encounters a null argument, the desired
behavior is effectively inverted.
Actually this is the desired behaviour: when a label is specified, makesure to replace it with our internal unique and safe label. Hence the`and'.Regards,-- Nicolas Goaziou