From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help,gmane.emacs.devel Subject: Re: emacs coding modes need 'Suspend Disbelief' button Date: Fri, 19 May 2017 12:23:03 -0400 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1495211054 4056 195.159.176.226 (19 May 2017 16:24:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 19 May 2017 16:24:14 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri May 19 18:24:08 2017 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dBkhD-0000m1-E1 for geh-help-gnu-emacs@m.gmane.org; Fri, 19 May 2017 18:24:07 +0200 Original-Received: from localhost ([::1]:59548 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dBkhF-0006Z6-8t for geh-help-gnu-emacs@m.gmane.org; Fri, 19 May 2017 12:24:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48032) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dBkgh-0006Yu-VC for help-gnu-emacs@gnu.org; Fri, 19 May 2017 12:23:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dBkge-0004Cf-MB for help-gnu-emacs@gnu.org; Fri, 19 May 2017 12:23:35 -0400 Original-Received: from [195.159.176.226] (port=49842 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dBkge-0004C2-FZ for help-gnu-emacs@gnu.org; Fri, 19 May 2017 12:23:32 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1dBkgO-0008Dc-Mj for help-gnu-emacs@gnu.org; Fri, 19 May 2017 18:23:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 43 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:TOLeNx6FZv2czgsI/NtXPfudhuw= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:113073 gmane.emacs.devel:214997 Archived-At: > then, when I enter '"' or "'", the rest of the text > would not be colored - this is really annoying and greatly > slows down editing of large files - Normally when you insert " only the current line gets "colored" immediately, and the rest of the buffer is only re-"colored" by jit-lock's contextual highlighting, i.e. after jit-lock-context-time of idle time. So if keep Emacs busy enough until you hit the closing " the rest of the buffer should not be re-"colored" incorrectly even temporarily. This said, even if it is re-"colored", that shouldn't slow anything down (IOW if there's a noticeable slowdown, please report it so we can try and fix it). > The insistence of modern emacs on always unconditionally > syntax checking everything greatly slows down typing and > is a major inhibition to quick editing of large source files. IIUC you're bumping into some performance problems. If so, please report them (with M-x report-emacs-bug and enough details that we can try and reproduce them) so we can try to fix them. > And in some modes, such as shell script mode, and also > cc-mode, it is still possible to core-dump Emacs (latest 25.2 version) Core dumps are serious bugs, so please M-x report-emacs-bug. We try pretty hard to fix those promptly. If they're difficult to reproduce, the best is for you to run Emacs within GDB and then send us the output of "bt" when it crashes. > I have core-dumped emacs several times recently by doing this - > one example that works pretty reliably is to start defining a > function within a function in shell-script - there is a timing > related bug , if you don't enter the opening '{' fast enough, > emacs will core-dump . My best guess here is that maybe your system has a stack-space limit that's lower than what Emacs expects for some reason, so that the code we have to try and check that we don't overflow the stack (e.g. in the regexp matcher) doesn't do its job. Stefan