[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AUCTeX-devel] Re: [AUCTeX] Re: Debugging LaTeX warnings

From: David Kastrup
Subject: Re: [AUCTeX-devel] Re: [AUCTeX] Re: Debugging LaTeX warnings
Date: Sat, 05 Nov 2005 19:12:47 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Ralf Angeli <address@hidden> writes:

> * David Kastrup (2005-11-05) writes:
>> I think the functionality is probably a step in the right direction
>> with regard to what the user wants.  But we need to fold the error
>> processing of preview-latex and AUCTeX at one point of time.
> Is that `preview-parse-messages' and related stuff?  That function
> scares me. (c;

Me too.

Anyway, preview-latex does a lot of futzing around with buffer
encodings and starting one process after another (the sort of thing
that would actually be required for latex+dvips+ghostview) and dumping
document preambles with the help of mylatex.ltx, and most of that
stuff actually would be better done in AUCTeX proper.

> Anyway, I don't think that the patch I sent will do much harm when
> it comes to integrating AUCTeX and preview-latex error processing,

Not really.  I just wanted to keep that objective in mind.

> so I guess I'll commit it after it will have received a bit more
> testing.
> After the frenzy in dctt the overhaul of the style system climbed up
> a bit on my priority list.

I agree that this is more urgent.  The other stuff is basically
cleanup and bringing AUCTeX up to the state of the art as in
preview-latex.  The current state is not pretty, and AUCTeX is lagging
a bit behind preview-latex, but it's not like most people have lived
for it for decades without much of a complaint (ok, Peter just

But the style system is a real crock, and it leads to stuff just not
working in case there are name collisions between .dtx, .drv, .bib,
.sty and whatever else files, and the workaround "then don't name them
like that" is pretty much unacceptable.

> So I'll probably look at that first.  But it will take some time to
> get a grip on it.  I'm probably thinking to complicated again.

Sounds like the original design...

> Currently I am wondering if it made sense to distinguish styles in a
> tree-like manner, starting from the file a style is related to.  In
> a file there can then be different style classes, e.g. commands,
> classes, packages, or input files, and related to these classes
> there can be different (ordered) options.  Like this, if you find
> "french" in the style system, you could walk the tree back to its
> roots and describe the style as the first option of package babel in
> file babel.sty.  (I haven't checked if this example is correct with
> respect to reality.)  But I am a bit afraid that handling such data
> structures will end in a nightmare.

I guess that the style subdirectory should probably be accessed only
by \usepackage.  That means that style/babel.el would have to cater on
its own for loading francais.el or similar.

What to do about user styles and so on?  We have an auto subdirectory.
If this is supposed to work with DOS style file names or Unix short
file names (14 characters or so), one might be tempted to create
subdirectories style, input, bibtex and so in them.  But
subdirectories are even more cleanup work.  Another possibility is
filenames like xxx.sty.el, xxx.tex.el xxx.bib.el and so on in the auto
directory.  On short file name systems, it might mean that the .el
gets lost, and this will affect the mode when hand-editing those
files.  Not really an important problem IMO.

>> It would also be nice if errors from AUCTeX could be flagged right
>> in the text in some manner, and preview-latex runs could make use
>> of that: right now preview-latex ignores TeX errors altogether.  If
>> it detected them, it could, for example, refrain from showing
>> previews in the closed form.  Some errors result in one-pixel
>> images (like when math groups get confused), and people wonder
>> where their stuff went.
> Flagged in which text?  In the output buffer?  Probably not, because
> the errors are already there.  Then maybe in the editing buffer.


> Are you thinking of a text property or overlay?

Overlay is the only sensible option for that.  It should not become a
part of the text for yank and paste and saving, and errors are at a
single cursor position anyway.  There are empty overlays, but no empty
text property ranges.

> Why would that be better than looking directly at the output of
> LaTeX in the first place?

Particularly with preview-latex, people rarely if ever look at the
output of LaTeX (and it would be riddled with false alarms, anyway).
They consider this as manipulating the source buffer.

How often do we have to ask people to send the run buffer or just look
into it when they are sending bug reports?

Go figure.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

[Prev in Thread] Current Thread [Next in Thread]