Re: [AUCTeX-devel] Feature Request

[Ivan Andrus]

> On Feb 3, 2016, at 2:20 PM, Mosè Giordano <address@hidden> wrote:
> 
> Dear all,
> 
> 2015-12-18 23:05 GMT+01:00 Mosè Giordano <address@hidden>:
>> 2015-12-18 22:53 GMT+01:00 Tassilo Horn <address@hidden>:
>>> Tassilo Horn <address@hidden> writes:
>>> 
>>>>>>> I have been recommended to mail the list with a feature request, I
>>>>>>> hope this is the right place.
>>>>>> 
>>>>>>> Currently if file.tex has \cite{ref2} and ref2 does not exist in the
>>>>>>> bib file, it displays no differently to \cite{ref1} which does.
>>>>>> 
>>>>>>> Is it possible to get some sort of visual indication that ref2
>>>>>>> does not exist in the bib file? A red squiggly line, highlight,
>>>>>>> different colour, something?
>>>> 
>>>> This would be a very nice feature.  RefTeX basically has the
>>>> functionality to know which citations are available in the bib file(s).
>>>> See `reftex-extract-bib-entries' and
>>>> `reftex-extract-bib-entries-from-thebibliography'.
>>>> 
>>>> So we could add some variable like `reftex-known-bibtex-entry-keys'
>>>> containing all known reftex entry keys.  I guess a hash-table would be
>>>> best because we need a fast contains-check.
>>> 
>>> I just had a better idea: We could just collect the _undefined_
>>> references and citations in `TeX-LaTeX-sentinel' and friends.  We
>>> already parse LaTeX output of these forms
>>> 
>>>  LaTeX Warning: Reference `foolabel' on page 1 undefined on input line 6.
>>>  LaTeX Warning: Citation `barcite' on page 1 undefined on input line 8.
>>> 
>>> just don't do much with that information except for noticing that we
>>> have to run bibtex and latex again.
>>> 
>>> Then we could have that feature also without font-lock.  We know the
>>> undefined labels and citations and the lines they are in, so we could
>>> just use overlays (which would make the feature Emacs-specific) and
>>> update them after a LaTeX run (or the last LaTeX run in
>>> `TeX-command-run-all').
>> 
>> Actually, something like this is one of the entry of the wishlist:
>> 
>>    Improvements to error reporting
>>    Fringe indicators for errors in the main text would be nice.
>> 
>> That is, something like flymake/flycheck, but builtin in AUCTeX.  Ok,
>> it won't be on-the-fly,[1] but when I look for errors/warnings after
>> compilation I often miss this feature.
> 
> I thought about this feature, but I came to the conclusion it isn't
> easy to realize with the current implementation of error and warning
> parsing.
> 
> In addition to fringes, it would be useful to have the offending code
> underlined, because in *TeX, contrary to common programming languages,
> we can have very long lines, in that case just a fringe indicator would be
> almost pointless.  However, now we get the whole error/warning
> message, but for all kinds of known errors/warnings we need to extract
> the actual code to be highlighted.  Moreover, a better parsing
> function is needed, file supp-pdf.mkii pops up every now and then in
> my error/warning lists.
> 
> This isn't something I'm going to fix for the time being, but
> volunteer would be warmly welcome.

I’ve worked a little on error parsing before and I was extremely
afraid of breaking things.  I would have really liked a large test
suite to make sure I didn’t introduce some regression.  Something
produced with different binaries (pdftex, luatex, etex), with all
relevant options (at least -file-line-error-style), different
distributions (TeX Live vs MikTeX at least), different packages, etc.
Unfortunately, I don’t have time to work on error parsing right now, 
and when I do have time I’ll probably have forgotten about it.  :-/

Maybe just soliciting output buffers from people would give a large
enough corpus.  It wouldn’t even have to be part of the AUCTeX
repository.  Someone (you can probably talk me into it), could set up
a repository on github (or elsewhere) and start collecting output and
slowly work on scripts.

-Ivan