Re: Bug: HTML export fails to set source IDs correctly [8.3.4 (8.3.4-elpa @ /Users/aaron/.emacs.d/elpa/org-20160222/)]

[Aaron Miller <me@aaron-miller.me>]

[-- Attachment #1: Type: text/plain, Size: 2157 bytes --]

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

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

[-- Attachment #2: Type: text/html, Size: 5213 bytes --]