emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: latexenc-find-file-coding-system is slow.


From: Arne Jørgensen
Subject: Re: latexenc-find-file-coding-system is slow.
Date: Fri, 29 Apr 2005 16:57:41 +0200
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/22.0.50 (gnu/linux)

Lute Kamstra <address@hidden> writes:

> Thien-Thi Nguyen <address@hidden> writes:
>
>> Arne Jørgensen <address@hidden> writes:
>>
>>> Richard Stallman <address@hidden> wrote March 4, 2005:
>>> 
>>> > We can now install them.  Could you send me the
>>> > latest version of your changes, with change log
>>> > entries?
>>> 
>>> So now I'm trying to post to list
>>
>> i have installed the files w/ the suggested names;
>> only modification was to re-indent latexenc.el.
>
> Since this change, opening a 117k .texi file takes seconds. 

First of all latexenc-find-file-coding-system shouldn't search .texi
files. I just tested it and in my emacs it is not called on .texi
files, but there could be something wrong with the entry in
file-coding-system-alist:

 ("\\.tex\\|\\.ltx\\|\\.dtx\\|\\.drv\\'" . latexenc-find-file-coding-system)

Does that entry match .texi files?

Secondly the problem will of course still be there on large .tex files
etc. which latexenc-find-file-coding-system is supposed search. See
below.

But my guess is .tex files normally doesn't grow as large as .texi
files. YMMV.

> It used
> to take a fraction of a second.  I did a debug-on-quit during the wait
> a couple of times and that consistently gave me one of these two
> backtraces:

[...]

> I guess the re-searching in latexenc-find-file-coding-system needs to
> be improved.

latexenc-find-file-coding-system re-searches all of the files for an
\inputencoding{...} command and if none is found it re-searches all of
the file for an \usepackage[...]{inputenc} command.

The two re-search-forward's could of course be limited to only search
the first n positions of the buffer. The problem is though to find
decent defaults for these limits.

It would be possible to introduce some variables for these limits and
let people customize them for their individual needs/tastes.

Kind regards,
-- 
Arne Jørgensen <http://arnested.dk/>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]