From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3 Date: Fri, 3 Apr 2020 17:47:57 +0000 Message-ID: <20200403174757.GA8266@ACM> References: <83h7y63sjj.fsf@gnu.org> <834ku43c61.fsf@gnu.org> <83k12zz6ds.fsf@gnu.org> <054393f3-3873-ab6e-b325-0eca354d8838@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="49716"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eliz@gnu.org, rrandresf@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 03 19:49:24 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jKQRW-000Cna-QT for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Apr 2020 19:49:22 +0200 Original-Received: from localhost ([::1]:59002 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKQRV-0001xc-R5 for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Apr 2020 13:49:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47605) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKQQL-0001EZ-AS for emacs-devel@gnu.org; Fri, 03 Apr 2020 13:48:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jKQQJ-0006Ck-Ra for emacs-devel@gnu.org; Fri, 03 Apr 2020 13:48:09 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:60934 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1jKQQE-00067i-6J for emacs-devel@gnu.org; Fri, 03 Apr 2020 13:48:07 -0400 Original-Received: (qmail 55367 invoked by uid 3782); 3 Apr 2020 17:48:01 -0000 Original-Received: from acm.muc.de (p4FE15C04.dip0.t-ipconnect.de [79.225.92.4]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 03 Apr 2020 19:47:57 +0200 Original-Received: (qmail 8485 invoked by uid 1000); 3 Apr 2020 17:47:57 -0000 Content-Disposition: inline In-Reply-To: <054393f3-3873-ab6e-b325-0eca354d8838@gmx.at> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:246344 Archived-At: On Fri, Apr 03, 2020 at 08:59:54 +0200, martin rudalics wrote: > > Can you pleese explain what you mean? > > What exactly was "removed"? The variable > > 'open-paren-in-column-0-is-defun-start' seems to still exist, and > > its default value seems to be t (my .emacs does not set it and it > > is t). > > > With the argument that people want to comment out larger > > > regions of code by simply putting comment delimiters at the > > > beginning and end of that code. > > You have not said concretely which practice this refers to, but the > > feature of special meaning for open-paren in column zero affects Emacs > > editing commands, not the meaning of the program when executed. > 'open-paren-in-column-0-is-defun-start', if non-nil, conceptually allows > progmodes to avoid scanning an entire buffer in order to get things like > syntax highlighting and code indenting right. Rather, progmodes are > allowed to find the first or next paren in column zero wrt a given > position and base further decisions on the assumption that such a paren > is on the "top level" of its buffer. This assumption proved to be very problematic. The fact is, people put parentheses in column zero inside comments, and nothing we can say or do will stop them. Why should it? these parentheses are perfectly valid in so many languages. Most notoriously was bug #22884, where there were such parentheses in Emacs's own C sources. And there were quite a lot of ostensible bugs in CC Mode caused by these parentheses. > Recent Emacsen either ignore that variable or silently reset it to nil > internally so it doesn't get into their way. The one place which matters where o-p-i-c-0-i-d-s used to be used was in back_comment() in syntax.c. This was removed for the above reasons. > Their progmodes either always scan an entire buffer from its beginning > or use some elaborate, fragile techniques to find such a top level > position. Why do you use the word "fragile" here? Do you have examples of this code failing? It seems to me the current way is somewhat less fragile that the o-p-i-c-0-i-d-s way. > Moreover, our underlying mechanism for syntax highlighting always > marks the entire rest of a buffer as dirty after every single editing > change. I have always been sceptical of the wisdom of this. Why invalidate the entire rest of the buffer, when a typical buffer change will cause at most local changes to the fontification? I think this can only be for ease of coding in the font-lock functions. Another approach would be somehow to divide a buffer into cells, something like one cell per function. A buffer change would then invalidate the fontification only to the end of the current cell, not EOB. This would be faster, but somewhat complicated to implement. > This has the consequence that that entire part has to be continuously > rescanned when some of it is shown in another window. > The basic slowness of Emacs over the past years is a direct consequence > of that policy. Most people don't care because they are using fast > processors that easily compensate the resulting overhead. People with > old and slow hardware suffer from it. How bad is this on your machine, really? > So since you earlier asked for "a switch to turn off the changes" then > my answer is that such a switch already exists but has been deactivated. As already stated, it was deactivated for good reasons. If we were to bring it back, I think we would need to add heuristics around paren-in-column-0 detection to the former rather crass 100% quitting of back_comment when one is encountered. I've considered this quite a bit in the past, and can't conceive of anything both helpful and fast. > martin -- Alan Mackenzie (Nuremberg, Germany).