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
m...@aaron-miller.me
http://aaron-miller.me

> On Feb 25, 2016, at 15:19, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> 
> Hello,
> 
> Aaron Miller <m...@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, make
> sure to replace it with our internal unique and safe label. Hence the
> `and'.
> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou

Reply via email to