Carsten Dominik writes: > On Jul 12, 2010, at 10:13 AM, David Maus wrote: > >> SEric Schulte wrote: >>> "Thomas S. Dye" writes: >> >>>> On Jul 8, 2010, at 9:09 AM, Eric Schulte wrote: >>>> >>>>> Sebastian Rose writes: >>>>> >>>>> [...] >>>>>> >>>>>> It can be considered an error, since the docs say: >>>>>> >>>>>> "...This is done with the ‘src’ block, where you also need to >>>>>> specify the name of the major mode that should be used to fontify >>>>>> the example..." >>>>>> >>>>> >>>>> I would vote that this be considered an error as a source block >>>>> doesn't make sense w/o a source language. If others agree with >>>>> this >>>>> interpretation, I would be happy to submit a patch which actively >>>>> raises an errors when this cases is encountered. >>>>> >>>>> Cheers -- Eric >>>> >>>> This seems like the right approach to me. >>>> >>>> Tom >> >>> As promised here's a patch which raises errors when source blocks >>> don't >>> have a specified language. I would prefer if the error could >>> indicate >>> which block caused the problem, but I don't know how to accomplish >>> this. >> >> Maybe we could store a marker in a text property of (source) blocks >> right before they are processed in the input file? > > The problem here is that during export, the source code is taken > from a temporary buffer containing an already modifed copy of the > original buffer. > > Another solution would be to include into the message is short > part of the code itself (maybe the first line...) - this should > make it possible to identify the problematic block reasonably easily. > > - Carsten The following updated patch includes the first line (up to 35 characters) of the code block in the error message. -- Eric