Moved aclocal.m4 and macros.texi up

I hope I managed to get everything.  Some changes in the preview
Makefile to make it closer to the top.

The checks for missing macros in configure seem pretty pointless by
now to me: they are probably not used consistently, and apart from
that, they won't help with checking out from CVS, and in the tarball,
at least the default documentation has already been produced.

Should we remove the checks?  If not, somebody has to take the
responsibility and make sure that their results are applied
everywhere.

If this is not done, the checks are just dead weight without a
purpose.

--

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Moved aclocal.m4 and macros.texi up

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

> The checks for missing macros in configure seem pretty pointless by
> now to me: they are probably not used consistently, and apart from
> that, they won't help with checking out from CVS, and in the tarball,
> at least the default documentation has already been produced.

AFAIR Jan-Åke used to be stuck on an outdated Texinfo installation
which was not aware of the macros we are currently checking for
availability.  I don't know if this is still the case.

> Should we remove the checks?  If not, somebody has to take the
> responsibility and make sure that their results are applied
> everywhere.

AFAICS macros.texi is included in all (master) Texinfo files.  And
 <at> MAKEINFO_MACROS <at>  is part of both doc/Makefile.in and
preview/doc/Makefile.in.

--

-- 
Ralf

Re: Moved aclocal.m4 and macros.texi up

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

> * David Kastrup (2005-06-04) writes:
>
>> The checks for missing macros in configure seem pretty pointless by
>> now to me: they are probably not used consistently, and apart from
>> that, they won't help with checking out from CVS, and in the tarball,
>> at least the default documentation has already been produced.
>
> AFAIR Jan-Åke used to be stuck on an outdated Texinfo installation
> which was not aware of the macros we are currently checking for
> availability.  I don't know if this is still the case.
>
>> Should we remove the checks?  If not, somebody has to take the
>> responsibility and make sure that their results are applied
>> everywhere.
>
> AFAICS macros.texi is included in all (master) Texinfo files.  And
>  <at> MAKEINFO_MACROS <at>  is part of both doc/Makefile.in and
> preview/doc/Makefile.in.

But it is not used everywhere where, say, TEXINFOINCLUDES is applied.
And it would seem to be relevant in all those cases.

That's why I suspect that it has been some time since somebody
actually needed those checks: it appears to me like they might not
have been doing their job for a while, and nobody noticed.

I guess we'll have to wait for Jan-Åke's comment.

Re: Moved aclocal.m4 and macros.texi up

David Kastrup wrote:
> That's why I suspect that it has been some time since somebody
> actually needed those checks: it appears to me like they might not
> have been doing their job for a while, and nobody noticed.

I suspect this too. I have convinced my sysadmins that updating once
in a while is not an entirely bad idea, so there should be no problem
here anymore.
/JÅ

Re: Moved aclocal.m4 and macros.texi up

Jan-Åke Larsson <jalar <at> mai.liu.se> writes:

> David Kastrup wrote:
>> That's why I suspect that it has been some time since somebody
>> actually needed those checks: it appears to me like they might not
>> have been doing their job for a while, and nobody noticed.
>
> I suspect this too. I have convinced my sysadmins that updating once
> in a while is not an entirely bad idea, so there should be no problem
> here anymore.

I'll just throw the tests out for now, then.  I can leave the macros
in aclocal.m4 for the time being: they don't do harm there, but I'll
remove their calls from configure.ac.

_If_ somebody complains about that, he'll have to volunteer for
testing the stuff.

--

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

tex-jp.el (was: Re: Regarding directory layout...)

From: David Kastrup <dak <at> gnu.org>
Subject: [AUCTeX-devel] Regarding directory layout...
Date: Sun, 15 May 2005 14:00:05 +0200

Sorry for late reply.  I'm very busy now Xp

(snip)
> "CONTRIB_MULE" contains the Japanese TeX mode: can somebody refresh me
> on the circumstances when it will get loaded/used?
> 
tex-jp.el has two Japanese TeX modes (japanese-latex-mode and japanese-plain-tex-mode).
It is loaded when the class file is for Japanese (jarticle etc...).

Currently, we missed autoloads for Japanese TeX in tex-site.el.

> Just glancing over it, the only use of Japanese (and probably MULE?)
> in tex-jp.el seems to be in the error message catalogue.

tex-jp.el provides some commands and variables for Japanese.
Maybe they can be merged into tex.el and latex.el, except
Japanese error message catalogue.

> If that is the case, we might in some future version remove the error
> message catalogue to a separate file (I already proposed using an info
> file for that because of convenient interfacing, but getting Japanese
> into info files might be even more difficult than getting it into
> Elisp.  So maybe we need language files with our own separate format
> after all).
> 

A real-life problem...

Loading or saving a large file with a few thousand \index entries
takes up about 10 minutes here, which is quite intolerable.  Things
get quite more acceptable with the following:

The question is whether I am going actually overboard here with trying
to keep the order of the lists more or less in-sequence like it was
previously the case.

Does anybody have enough of a clue to tell whether the order is
important here?  If not, one can leave off the sequencing stuff using
`count', maybe making this more efficient.

The best thing would probably be to just have all of those variables
be hash tables in the first place.  If order is not an issue.

--

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

_______________________________________________
auctex-devel mailing list
auctex-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/auctex-devel

Re: A real-life problem...

* David Kastrup (2005-06-07) writes:

> Loading or saving a large file with a few thousand \index entries
> takes up about 10 minutes here, which is quite intolerable.  Things
> get quite more acceptable with the following:
>
>
> --- tex.el	05 Jun 2005 19:07:23 +0200	5.524
> +++ tex.el	07 Jun 2005 04:51:13 +0200	
>  <at>  <at>  -2669,28 +2669,72  <at>  <at> 
>    :group 'TeX-parse)
>    (make-variable-buffer-local 'TeX-auto-x-regexp-list)
>  
> +(defun TeX-regexp-group-count (regexp)
> +  "Return number of groups in a regexp.  This assumes the following
> +heuristic:  Any occurrence of the pattern `\\\\([^?]' is an opening group,
> +so if you want to have something like `\\\\\\\\(', write it as `\\\\\\\\[(]'."

Hm, probably nobody will think about that when writing a regexp.
Couldn't the function recognize such constructs itself and disregard
them?

> +  (let (start (n 0))
> +    (while (string-match "\\\\([^?]" regexp start)
> +      (setq start (1- (match-end 0))
> +	    n (1+ n)))
> +    n))
> +
>  (defun TeX-auto-parse-region (regexp-list beg end)
>    "Parse TeX information according to REGEXP-LIST between BEG and END."

Re: A real-life problem...

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

> * David Kastrup (2005-06-07) writes:
>
>> --- tex.el	05 Jun 2005 19:07:23 +0200	5.524
>> +++ tex.el	07 Jun 2005 04:51:13 +0200	
>>  <at>  <at>  -2669,28 +2669,72  <at>  <at> 
>>    :group 'TeX-parse)
>>    (make-variable-buffer-local 'TeX-auto-x-regexp-list)
>>  
>> +(defun TeX-regexp-group-count (regexp)
>> +  "Return number of groups in a regexp.  This assumes the following
>> +heuristic:  Any occurrence of the pattern `\\\\([^?]' is an opening group,
>> +so if you want to have something like `\\\\\\\\(', write it as `\\\\\\\\[(]'."
>
> Hm, probably nobody will think about that when writing a regexp.
> Couldn't the function recognize such constructs itself and disregard
> them?

Well, I thought about doing this "right" in every case.  And then I
thought about "[\\(]" and decided that I had no real chance.

Maybe something that will work in more cases is reasonably easy to do
and not too inefficient.  I am not sure it will be worth the trouble,
but if somebody else is of a different opinion, I don't mind if he
comes up with something.

> Isn't #'(lambda ...) a pleonasm?  As far as I understand (info
> "(elisp)Anonymous Functions") a bare (lambda ...) should suffice
> because `lambda' already implies `function' and #' is a shorthand

Re: tex-5.502; TeX-command-list - renaming menu entries

David Reitter <david.reitter <at> gmail.com> writes:

> I've configured my TeX-command-list to show me a nicely structured
> menu, and while doing so I've renamed menu entries. For example, I
> have renamed "View" to "View PS",

Wow.  So you use "View PS" to view PDF files.  Talk about intuitive
changes.

> and "LaTeX" to "Compile with LaTeX".
>
> The issue occurs when I then do C-c C-c and accept the default
> command. If it is "LaTeX" or "View", it'll fail with a "wrong type
> argument" error. (Originally reported by Robert Sloan on the Emacs /
> Aquamacs-bugs mailing lists.)

Well, no surprise here.  If you want to play games with the menu
names, you should probably do it at a different point of the code,
where the menus get created from TeX-command-list.

But the menu entries are supposed to give a clue about what to do with
C-c C-c too, so you should likely rather tamper with the help strings
than the menu entries.

> The reason for the given behavior is that you do a string-match over
> the command list, and you try to match a hard-coded string such as
> "View" with the menu entries. That has to fail when TeX-command-list
> is customized.

But I don't want people to have to type