David Kastrup | 1 May 2005 01:04
Picon
Picon

Re: Re: [AUCTeX-diffs] Changes to auctex/doc/todo.texi


Ok, I guess that the worst is over.  Give the current version a solid
testing if possible, do what you think necessary.  I have not yet
looked into the rpm spec, and I am now supposed to take my violin and
go to a general drinking assembly.  So not much more I can do today.
I think the state of the code is rather cute.  Documentation is
lacking behind quite a bit: in particular the installation stuff.  The
most important cases where install-info and texhash should not be run
are now covered automatically.  AUCTeX should create XEmacs packages
pretty well right now, although I don't think that tex-fptex.el and
tex-mik.el are included into the package right now.

It is not easy to get everything right.  But I think the most
important things should be in place now.

--

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Ralf Angeli | 1 May 2005 17:04
Picon

Re: Re: Running out of time...

* David Kastrup (2005-04-30) writes:

> At the current point of time, the main thing would be to check that
> the stuff configures, compiles and installs on the involved platforms.
> That is number one.

Installation seems to work on CVS Emacs and Emacs 21.4.  I don't know
however, if I am supposed to (require 'tex-site) or (load "auctex")
right now.  Both work.

Installation for XEmacs succeeds but after starting XEmacs, the new
installation is shadowed by the old one.  Here is the start of the
output of `list-load-path-shadows':

/usr/share/xemacs21/xemacs-packages/lisp/auctex/tex-bar hides /usr/share/xemacs21/site-packages/lisp/auctex/tex-bar
/usr/share/xemacs21/xemacs-packages/lisp/auctex/toolbar-x hides /usr/share/xemacs21/site-packages/lisp/auctex/toolbar-x
/usr/share/xemacs21/xemacs-packages/lisp/auctex/tex-fold hides /usr/share/xemacs21/site-packages/lisp/auctex/tex-fold
/usr/share/xemacs21/xemacs-packages/lisp/auctex/context-nl hides /usr/share/xemacs21/site-packages/lisp/auctex/context-nl
[...]

auctex.el cannot be located with `locate-library'.

> Number two is making sure that the documentation
> matches the actual installation procedures (like the stuff with
> auctex.el).

A precondition for this is to actually know how the installation is
supposed to work, what changed regarding switches, how the packages
are activated etc. etc.  Personally I am currently completely clueless
about this.
(Continue reading)

David Kastrup | 1 May 2005 18:01
Picon
Picon

Re: Re: Running out of time...

Ralf Angeli <angeli <at> iwi.uni-sb.de> writes:

> * David Kastrup (2005-04-30) writes:
>
>> At the current point of time, the main thing would be to check that
>> the stuff configures, compiles and installs on the involved platforms.
>> That is number one.
>
> Installation seems to work on CVS Emacs and Emacs 21.4.  I don't know
> however, if I am supposed to (require 'tex-site) or (load "auctex")
> right now.  Both work.
>
> Installation for XEmacs succeeds but after starting XEmacs, the new
> installation is shadowed by the old one.  Here is the start of the
> output of `list-load-path-shadows':
>
> /usr/share/xemacs21/xemacs-packages/lisp/auctex/tex-bar hides
> /usr/share/xemacs21/site-packages/lisp/auctex/tex-bar

WHAT?!?

Taking a look at the XEmacs in Ubuntu, I see that xemacs-packages is
_before_ site-packages in the search order.

What idiocy is that?  This is completely insane.  Whoever at Debian is
responsible for that ought to be shot.  XEmacs in Fedora does not have
this sick, sick load order.  Seems to be a Debian special.

> auctex.el cannot be located with `locate-library'.

(Continue reading)

David Kastrup | 1 May 2005 18:09
Picon
Picon

Re: [AUCTeX-commit] auctex Makefile.in

Ralf Angeli <angeli <at> iwi.uni-sb.de> writes:

> CVSROOT:	/cvsroot/auctex
> Module name:	auctex
> Branch: 	
> Changes by:	Ralf Angeli <angeli <at> savannah.gnu.org>	05/05/01 15:13:55
>
> Modified files:
> 	.              : Makefile.in 
>
> Log message:
> 	(clean, distclean): Descend.

You beat me to it.  I was just bitten by old files from an XEmacs
configuration.

I don't think it would make sense to descend for the fine-grained
install-whatever targets: people that use them probably need the fine
amount of control the separate targets in the separate directories
offer.

But the cleanup targets should descend, I guess.

--

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
David Kastrup | 1 May 2005 21:51
Picon
Picon

Hen and egg...


I just realized that the macro "have-preview" is a bad idea: when we
are pregenerating information, we can't know in advance what setting
will be there.

Sigh.

Rewriting the stuff again.

--

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Ralf Angeli | 1 May 2005 21:44
Picon

Re: font-latex extremely slow

* Ralf Angeli (2005-03-23) writes:
               ^^^^^^^^^^
And that's why I include the date in the attribution line.

> * Reiner Steib (2005-03-23) writes:
>
>> On Wed, Mar 23 2005, Ralf Angeli wrote:
>>
>>> * Reiner Steib (2005-03-22) writes:
>>>
>>>> Not much later (font_latex_Emacs-CVS_22.elp in [1]; 21:16), it
>>>> became extremely slow.  After inserting a SPC, I had to wait around
>>>> 15 seconds until it is displayed. :-/
>>>
>>> Hm, did it get better after you typed SPC or something else?  
>>
>> Not at all.  When it happens, Emacs stays unresponsive until I switch
>> off font-lock.  By "unresponsive" I mean, that the insertion and
>> cursor moves take several seconds until they are visible.
>
> Another idea, because font locking just freaked out for me in
> preview.dtx: Do you have a construct in your LaTeX source code which
> could be interpreted as an opening tag without a closing one?  A
> quotation mark, a guillemet or stuff like (from preview.dtx)
> "\item[|[|]"?

Hello?  Is this thing on?

Reiner, could you please customize `font-latex-do-multi-line' to nil
and check if this makes the problem go away?
(Continue reading)

Ralf Angeli | 2 May 2005 09:18
Picon

Re: Re: Running out of time...

* David Kastrup (2005-05-01) writes:

> Ralf Angeli <angeli <at> iwi.uni-sb.de> writes:
>
>> Installation for XEmacs succeeds but after starting XEmacs, the new
>> installation is shadowed by the old one.  Here is the start of the
>> output of `list-load-path-shadows':
>>
>> /usr/share/xemacs21/xemacs-packages/lisp/auctex/tex-bar hides
>> /usr/share/xemacs21/site-packages/lisp/auctex/tex-bar
>
> WHAT?!?
>
> Taking a look at the XEmacs in Ubuntu, I see that xemacs-packages is
> _before_ site-packages in the search order.
>
> What idiocy is that?  This is completely insane.  Whoever at Debian is
> responsible for that ought to be shot.  XEmacs in Fedora does not have
> this sick, sick load order.  Seems to be a Debian special.

Yep.  It seems that this was done at configuration time.  At least
this is what the ./configure string shown in `M-x report-xemacs-bug
RET' suggests.

>> auctex.el cannot be located with `locate-library'.
>
> Well, it is called auto_autoloads.el there...

I see.  Interestingly, after accidently executing `make && make
install' for XEmacs again, it seems to pick up the auto_autoloads.el
(Continue reading)

David Kastrup | 2 May 2005 21:15
Picon
Picon

Re: Re: Running out of time...

Ralf Angeli <angeli <at> iwi.uni-sb.de> writes:

> * David Kastrup (2005-05-01) writes:
>
>> Ralf Angeli <angeli <at> iwi.uni-sb.de> writes:
>>
>>> Installation for XEmacs succeeds but after starting XEmacs, the new
>>> installation is shadowed by the old one.  Here is the start of the
>>> output of `list-load-path-shadows':
>>>
>>> /usr/share/xemacs21/xemacs-packages/lisp/auctex/tex-bar hides
>>> /usr/share/xemacs21/site-packages/lisp/auctex/tex-bar
>>
>> WHAT?!?
>>
>> Taking a look at the XEmacs in Ubuntu, I see that xemacs-packages is
>> _before_ site-packages in the search order.
>>
>> What idiocy is that?  This is completely insane.  Whoever at Debian is
>> responsible for that ought to be shot.  XEmacs in Fedora does not have
>> this sick, sick load order.  Seems to be a Debian special.
>
> Yep.  It seems that this was done at configuration time.  At least
> this is what the ./configure string shown in `M-x report-xemacs-bug
> RET' suggests.

Did you send the report off to Debian then?

>>> auctex.el cannot be located with `locate-library'.
>>
(Continue reading)

David Kastrup | 2 May 2005 23:34
Picon
Picon

Ok, now the intent should be clear.


I overhauled the installation instructions myself.  Now the tarball
building should probably be adapted and stuff.

--

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
David Kastrup | 3 May 2005 10:43
Picon
Picon

Anybody out there?


Folks,

this is my last day at Bachotek, and I am leaving at 14:45.  I am now
quitting this session to start on my traditional run around the lake
(which will take hours given my current fitness level).

This means that I won't be having net access for the next week while I
am in Berlin and Greifswald.  There is a slight chance that in Berlin
I may be able to do some intermittent net access by visiting Sven, a
hard-core vim proponent.  The amount of things I am willing to do for
AUCTeX...

Anyway, I pretty much have my claws of the current source code.  Here
is a list of things that need to get finished for the release:

a) RPM specs need to be created.  The current RPM is Emacs-only and
includes everything and the kitchen sink.  The README and INSTALL
files from preview-latex and AUCTeX conflict: somebody needs to take a
look at what %doc actually does and fix that.  I am still ambiguous
about package distribution, but I think I prefer the
--without-texmf-dir setting.  This means duplication of the LaTeX
stuff.  I can't think of a sane scheme to avoid that except have
separate auctex-emacs-no-styles, auctex-xemacs-no-styles and
preview-styles packages as an alternative to auctex-emacs and
auctex-xemacs, with the obvious necessary conflicts and dependencies.
Then you can choose to install the styles in your distribution's
standard place (and make them generally available) or skip this and
use the integrated styles.  If your distribution comes with its own
preview files in the texmf tree, you would likely be forced to use the
(Continue reading)


Gmane