Re: [AUCTeX-devel] Re: Missing bits and pieces...

[David Kastrup]

Ralf Angeli <address@hidden> writes:

> * David Kastrup (2005-07-21) writes:
>
>> Ralf Angeli <address@hidden> writes:
>>
>>> I'm mostly with you.  But what use are tex-mik.el and tex-fptex.el in
>>> a Unix-style environment?
>>
>> Completeness,
>
> I wouldn't consider an AUCTeX installation on a Unix-style stystem
> incomplete if it was missing files specific to Windows.
>
>> example code, straightforwardness in installation (just
>> make install); and last time I looked, it was not prohibited to share
>> the Emacs tree via Samba or a suitable partition.  That's why it is in
>> /usr/share and not /usr/lib.
>
> Okay, those are more than enough reasons for including them.

It might also be possible to compile on a Unix system an AUCTeX tree
for systems like TeXlive.
>
>>> BTW, regarding tex-jp.el: What happens if tex-jp.elc is included
>>> in an RPM package or something like this and loaded by a non-MULE
>>> XEmacs?  Will this throw an error?
>>
>> I don't think tex-jp is loaded without asking for it, so I don't
>> really care.
>
> Aren't you just a little bit curious? (c;

It is one of the "don't want to think about it" areas...

>>> In general we should include it completely in an accessible and
>>> neutral format (e.g. not for a specific paper size).  That means
>>> besides the info format, the manual should be included either as
>>> plain text or HTML.
>>
>> Uh what?  What use is plain text?  For screen reading, info is more
>> suited, for printing, PostScript or PDF.
>
> Plain text can serve both screen reading and printing.  Besides, you
> don't need a special viewer for it and can print on arbitrary page
> sizes.  It's not the best format for either output device, I know.
> But maybe it's better than including PostScript or PDF files in
> various page sizes.  HTML might be an acceptable compromise if
> nobody has a better idea.

I think that HTML is ok for our online pages, but it seems strange to
use for included docs.

>>> The refcard is somewhat special.  How about providing PDF files both
>>> in A4 and letter format for it?
>>
>> Sounds reasonable.
>>
>> I am still oscillating over the package layout.  IIRC, we don't really
>> need to know where the texmf tree sits at compile time since kpathsea
>> can figure this out at run time, right?
>
> Yes.  We locate files in TeX trees with this function:
>
> (defun TeX-macro-global-internal (latex search default)
>   "Return directories containing the site's TeX macro and style files.
>
>> So maybe the package
>> organization would just need
>>
>> preview-tetex-styles (independent from AUCTeX!)
>>
>> auctex-emacs
>>
>> auctex-xemacs (installs like an XEmacs package, thus has no files in
>> common with auctex-emacs)
>
> I guess this means there won't be packages built with
> --without-texmf-dir

Uh, there will be _only_ packages built with --without-texmf-dir, you
mean?

> but users may choose to install preview.sty independently via
> preview-tetex-styles?

Yes, for LyX users, for example, and because it might be needed for
ps4pdf or whatever.

>> auctex-tetex (?) installs cron scripts regenerating the auto style
>> files regularly, and does so whenever auctex or tetex get updated.
>
> Why not do this in the respective (X)Emacs packages?

It would have a trigger script on tetex, and that would not fire if
you were using TeXlive.  And the regeneration needs to be done only
once for both Emacs and XEmacs, since they share /var/auctex.  And if
people don't like the automatic updates, they can just not install the
package.

That were the ideas behind it.  Maybe some of them are pretty weak.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum