From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ralf Angeli Newsgroups: gmane.emacs.devel Subject: Re: [cs-usenet@arcor.de: tex-mode: too many _ (underscores) interpreted as subscripts] Date: Tue, 05 Oct 2004 12:16:16 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1096971247 14542 80.91.229.6 (5 Oct 2004 10:14:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 5 Oct 2004 10:14:07 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 05 12:14:01 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CEmKX-0005mC-00 for ; Tue, 05 Oct 2004 12:14:01 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CEmRA-0006er-Nu for ged-emacs-devel@m.gmane.org; Tue, 05 Oct 2004 06:20:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CEmR2-0006em-VU for emacs-devel@gnu.org; Tue, 05 Oct 2004 06:20:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CEmR2-0006ea-Gi for emacs-devel@gnu.org; Tue, 05 Oct 2004 06:20:44 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CEmR2-0006eX-D6 for emacs-devel@gnu.org; Tue, 05 Oct 2004 06:20:44 -0400 Original-Received: from [80.91.229.2] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CEmKJ-000733-Du for emacs-devel@gnu.org; Tue, 05 Oct 2004 06:13:47 -0400 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CEmKI-0005Yq-00 for ; Tue, 05 Oct 2004 12:13:46 +0200 Original-Received: from iwi190.iwi.uni-sb.de ([134.96.72.190]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Oct 2004 12:13:46 +0200 Original-Received: from angeli by iwi190.iwi.uni-sb.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Oct 2004 12:13:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-To: emacs-devel@gnu.org Original-Lines: 39 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: iwi190.iwi.uni-sb.de Mail-Copies-To: nobody User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:XPa9RhQKd+wvDeLR/TltVupS15Y= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:27928 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27928 [My last mail was sent prematurely. Here is the rest of the answer.] * Richard Stallman (2004-10-04) writes: > Meanwhile, why is texmathp so slow? It can happen that `texmathp' has to `re-search-backward' through the whole buffer. We had a bug report in AUCTeX where a file was supplied which demonstrated the problem in a highly exaggerated way which lead to fontification eating up a large amount of CPU resources. The file was about 10,000 lines and repeatedly contained --8<---------------cut here---------------start------------->8--- \newcommand{\mycontent}{\ensuremath{\lambda_{1}}}% \begin{itemize}% \item \begin{align*}% \left\{ \begin{array}{l} b_{c} \text{some long line with $\mycontent$} \end{array} \right\} \end{align*}% \end{itemize}% --8<---------------cut here---------------end--------------->8--- `texmathp' tries to limit the backward search by finding empty lines which may denote a paragraph separation. In the file there were no empty lines, so at the end, it had to search all the way up those 10,000 lines for math environments. The search involves two passes: One for commands and one for environments. The closer match is selected. Currently both passes can be limited only by the empty-line heuristic. One could probably speed the process up by limiting one search by the result of the other. -- Ralf