From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Unbearably slow editing in .h files (was: patch: add-log.el: changelog find file under point) Date: Sat, 23 Feb 2008 22:49:01 +0000 Message-ID: <20080223224901.GB3476@muc.de> References: <200801222310.m0MN9cZq011601@sallyv1.ics.uci.edu> <8763xl492o.fsf@jurta.org> <200801230225.m0N2Ptmx012952@sallyv1.ics.uci.edu> <200801271954.m0RJsmBm003714@sallyv1.ics.uci.edu> <479DAC55.8070302@gmx.at> <200801300258.m0U2w9rr005169@sallyv1.ics.uci.edu> <47B9E0B1.1090908@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1203806188 27380 80.91.229.12 (23 Feb 2008 22:36:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Feb 2008 22:36:28 +0000 (UTC) Cc: bug-cc-mode@gnu.org, emacs-devel@gnu.org To: Stefan Monnier , martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 23 23:36:52 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JT2zC-0006vO-Kc for ged-emacs-devel@m.gmane.org; Sat, 23 Feb 2008 23:36:50 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JT2yg-0004Md-M5 for ged-emacs-devel@m.gmane.org; Sat, 23 Feb 2008 17:36:18 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JT2yc-0004MD-J4 for emacs-devel@gnu.org; Sat, 23 Feb 2008 17:36:14 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JT2yb-0004Lh-GG for emacs-devel@gnu.org; Sat, 23 Feb 2008 17:36:13 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JT2yb-0004Ld-6F for emacs-devel@gnu.org; Sat, 23 Feb 2008 17:36:13 -0500 Original-Received: from colin.muc.de ([193.149.48.1] helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JT2ya-0001fd-HY for emacs-devel@gnu.org; Sat, 23 Feb 2008 17:36:12 -0500 Original-Received: (qmail 78336 invoked by uid 3782); 23 Feb 2008 22:36:10 -0000 Original-Received: from acm.muc.de (p57AF623D.dip.t-dialin.net [87.175.98.61]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Sat, 23 Feb 2008 23:36:07 +0100 Original-Received: (qmail 6719 invoked by uid 1000); 23 Feb 2008 22:49:01 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.6-4.9 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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:90171 Archived-At: Hello, Stefan and Martin. On Mon, Feb 18, 2008 at 03:09:42PM -0500, Stefan Monnier wrote: > > The simple approach is based on searching and comparing the result with > > that of `add-log-current-defun'. It works pretty well most of the time > > but may exhibit the nasty behavior described in > > http://lists.gnu.org/archive/html/emacs-devel/2007-10/msg00443.html , whose content is thus: :Try the following: : : emacs -Q src/lisp.h : C-s Fplist_put RET : C-x 4 a : :you should see Emacs get stuck in an infinite loop (not a bad, one: C-g :stops it just fine). : : :Stefan : :PS: BTW, am I the only one who experiences odd slowdowns when editing :src/lisp.h, apparently due to font-lock occasionally taking a lot of time :(like a second or two) to do its job. Not easy to reproduce, sadly. It does a lot of cacheing of things; that second or two is filling up caches, which prevents it from being "reproduced" immediately. ;-) > > On my 1 GHz machine this means that I have to wait some 40 secs until > > I'm told that there are no matches. I can think of two ways to handle > > this: (1) Convince Alan that the behavior of `c-beginning-of-defun' is > > intolerable - AFAICT this has been tried before. ;-) I think that lisp.h is an ill-conditioned file, in some way. Or are you telling me that the slowness happens in a lot of files.h? The intolerability could be due to searching for an unnested brace instead of one at column zero. (2) Fix this within > > `add-log-current-defun' to not use `c-beginning-of-defun' - I'm unable > > to do this myself because I completely fail to understand that part of > > the function. What is add-log-current-defun using c-beginning-of-defun for? How many times does it call c-b-o-d? If it's calling it lots of times, why. OK, cancel that, I've just had a look at the function (in Emacs-22). It's using several sledgehammers to crack some tiny nuts, presumably dating from the era in which the sledgehammer was the only available tool. The bit in add-log-current-defun dealing with C files could usefully use `c-beginning-of-macro' and, in particular, `c-where-wrt-to-brace-construct'. The latter function painstakingly analyses where, in a defun, point is, returning a value such as 'in-header or 'outwith-function. It's a somewhat slow function, is called at the start of every c-{beginning,end}-of-defun call, and its result is not currently cached. Using it directly, instead of the five explicit calls to c-\(beginning\|end\)-of-defun would give a speed up of 5 or 2.5 in C-x 4 a. > Nowadays, I find myself regularly using M-x fundamental-mode in .h files > in order to be able to edit them sanely. We have to do something to > fix it. Alan? Which files.h are you talking about, Stefan? CC Mode seems to work well enough for me in my day job (maintaining typical old "proprietary-quality" C code). Maybe .../src/lisp.h and one or two others are somewhat extreme in their use of macros, or something. A solution might be to set open-paren-in-column-0-is-defun-start in the file local variables list, but I can't remember offhand if CC Mode handles it properly (I suspect it doesn't). > Stefan -- Alan.