Tom Gillespie <tgb...@gmail.com> writes:
>> As for lang parameter support in example blocks, would you mind creating >> a separate feature request thread? Extending export blocks export will >> require changing in parser syntax and thus should be discussed carefully >> in a separate thread. > > I would strongly caution against allowing an optional #+begin_example lang > syntax. It will lead to extreme confusion, even when users know to use > org-lint. > The reason for this is that example blocks do not have (and frankly should not > have) full org-babel support. Babel is already complex enough as is without > having to explain to a user that yes they can noweb an example block into > a src block, but that they cannot noweb a source block into an example block. > > One of the most powerful features of src blocks is that they can go from being > dumb examples all the way up to fully executable programs. Example blocks > cannot do that, and adding features that overlap with code blocks is inviting > duplicated effort and will confuse and frustrate users if they have > the misfortune > to start with an example block an then have to change mid way through to a > code block. > > I also think that adding a parameter #+begin_example :lang bash to example > blocks will also lead to confusion because now there are two different ways > to specify what lang a block is. To me the answer should be to just use source > blocks if you need highlighting, example blocks should not highlight at all in > order to make the distinction clear. > +1. I hold the same view. I'm happy if example blocks have a highlighting which distinguishes them as a 'block of something' i.e. slightly different background, smaller or different font etc. However, they don't need font-locking style highlighting or highlighting which is determined by a language setting. If you want that level of highlighting, just use a src block, possibly disabling eval when warranted.
