generated to contain a source block has an ID attribute=20= >> matching the source block's name. >>=20 >> Actual: Instead, ID attributes come out with values like "orgsrcblock1". >>=20 >> Test case: >> --- >8 cut here --- >> #+TITLE: bug test case >>=20 >> #+NAME: a-source-block >> #+BEGIN_SRC emacs-lisp :eval never >> ;; hi >> #+END_SRC >> --- 8< cut here --- >>=20 >> Expected result (its salient subset): >> --- >8 cut here --- >>

>> ;; hi
>>

>> --- 8< cut here --- >>=20 >> Actual result (its likewise): >> --- >8 cut here --- >>

>> ;; hi
>>

>> --- 8< cut here --- >>=20 >> Note the erroneous ID attribute value. >=20 > The attribute is intended. >=20 >> The issue here is that, in `org-html-src-block' and=20 >> `org-html-inline-src-block', the fallback behavior for ID attribute=20 >> value is implemented in terms of `and', rather than `or'. Since `and'=20 >> short-circuits only when it encounters a null argument, the desired=20 >> behavior is effectively inverted. >=20 > 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'. >=20 >=20 > Regards, >=20 > --=20 > Nicolas Goaziou --Apple-Mail-A5738259-577C-4DCE-A48F-A300846DE764 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

The difficulty here is that ID attribu= te values are not easily predictable, and dependent on the source block's po= sition in the document. This complicates tasks like styling a specific sourc= e block -- with the previous ID generation method, this could be reliably do= ne with an ID selector; with the current behavior, that's no longer true.&nb= sp;

Can you provide some insight on why the behavio= r was changed? I'd be happy to expand the scope of my bug report to cover wh= atever code relies on the change. Thanks!

Aaron Miller

Mobile: (443)= 902-4702

me@aaron-mi= ller.me

ht= tp://= aaron-miller.me

On Feb 25, 2016, at 15:19,= Nicolas Goaziou <mail@nicolasg= oaziou.fr> wrote:

H= ello,

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 I= D attribute
matching= the source block's name.
<= span>
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_SR= C
--- 8< cut here -= --

Expected result (its salient subset):<= /span>
--- >8 cut here --= -
<pre class=3D"sr= c src-emacs-lisp" id=3D"a-source-block">
;; hi
</pre>
= --- 8< cut here ---

Actual result (its= likewise):
--- >8= cut here ---
<pre= class=3D"src src-emacs-lisp" id=3D"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 f= allback behavior for ID attribute
value is implemented in terms of `and', rather than `or'. Since= `and'
short-circuit= s only when it encounters a null argument, the desired
behavior is effectively inverted.<= br>

Actually this is the desired behaviou= r: when a label is specified, make
sure to replace it with o= ur internal unique and safe label. Hence the
`and'.

Regards,
--
Nicolas Goaziou

= --Apple-Mail-A5738259-577C-4DCE-A48F-A300846DE764--