Ralf Angeli <[EMAIL PROTECTED]> 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 complained). 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. Yes. > 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 _______________________________________________ auctex-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/auctex-devel
