Re: [AUCTeX-devel] Re: Setup mess...

[David Kastrup]

Ralf Angeli <address@hidden> writes:

> * David Kastrup (2005-04-13) writes:
>
>> In addition we have a variable TeX-default-scheme which can be set to
>> 'miktex, 'fptex or 'tetex, maybe 'texlive and which determines the
>> default settings.
>
> Hm.  A big deal of the stuff in tex-mik.el and tex-fptex.el are
> viewers and related options.  I don't think that these are directly
> related to the TeX system.

Last time I looked, Yap was different from Windvi.  

  Especially on X11 you have a plethora of
> choices, kdvi, tkdvi, xdvi, acroread, gpdf, xpdf, whatsitsname.  On
> Windows in contrast mainly `start' is used to get the system default
> for different file types (BTW, we might consider using mailcap or MIME
> where it's available).

We should not merely consider it.  It is definitely something we
should do.  Unfortunately, we can't just use "run-mailcap" or similar
when available since we also have to cater for things like source
specials and stuff.  So we will need to take a look at mailcap
directly.

> So for viewers it would probably make more sense to have an alist of
> them as well as their command line options and a variable to select
> one which is available on the system.

No objection here.  Still the default for that variable could usefully
depend on the general scheme.

>> When Emacs-22 is used, I think we should use "deftheme" for this:
>> this functionality is exactly what is needed, and it is also
>> important for other things like "newbie defaults", "MacOSX
>> defaults", "Windows defaults".  Currently it is heavily
>> underdocumented and pretty much unused.  I think it would be very
>> beneficial to both AUCTeX as well as Emacs in the long run if we
>> tried to push this more into the mainstream.  We'll obviously need
>> backup code for Emacs-21 and XEmacs, but probably we can make do
>> with some wrappers of our own.
>
> Ahem, "some wrappers of our own"?  The custom theme stuff does not
> really look like it would be overly simple.  Are you intending to
> replicate the functionality or provide a really, really dumbed down
> version of it?

Likely the latter.  Some macro level stuff, like the things we use for
transforming menus for XEmacs' sake by renaming some fields and
throwing out others.

>> Now this seems like the right thing to do.  However, I also have the
>> problem that I need to get a workshop-able AUCTeX (including
>> preview-latex) by the end of the month.
>>
>> Is it reasonable to get this working before that?
>
> Currently I have terribly little time and I doubt that this will
> change in the near future.  You might have noticed that I am more or
> less in small-bug-fixing mode.

Yup.  So if I happen to crash through the code thicket in a panic two
nights before the conference, I better only leave bugs to squash
instead of gaping holes.

> I cannot really estimate how much work your or my proposals will
> involve.  Throwing out tex-mik.el and tex-fptex.el and using
> deftheme sounds rather simple, but writing a backup for Emacsen not
> providing it?  And with my proposal, I always have trouble keeping
> it real.

Your proposal needs fleshing out (to make use of source specials and
stuff), and mailcap won't tell us about conversion chains.

But at least mailcap.el exists in all relevant Emacs versions, and we
even use it in preview-latex at one point IIRC.

So configuring the default viewer command to be TeX-view-mailcap
should be easy enough, and that will then leaf through the offered
viewers and pick the one it is most comfortable with.  And if the Mime
commands lead to nothing useful, a default guess like we have
currently is used again.

We really should do this for DVI viewers, PDF viewers and PostScript
viewers.  The current hardcoded stuff is not nice as a default.

> When I think about viewers I think about auxiliary programs in
> general and then I am thinking about connecting them and then I am
> at a point where I want to rip out the whole toolchain stuff and
> write it anew.  So if we go for that we should keep it simple but
> have an eye on future additions.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum