From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Pogonyshev Newsgroups: gmane.emacs.devel Subject: Re: Signal `quit' in a `font-lock-fontify-region-function' Date: Tue, 28 May 2019 18:24:52 +0200 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="135400"; mail-complaints-to="usenet@blaine.gmane.org" To: Stefan Monnier , Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 28 18:27:47 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hVeww-000Z1C-SW for ged-emacs-devel@m.gmane.org; Tue, 28 May 2019 18:27:43 +0200 Original-Received: from localhost ([127.0.0.1]:39025 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hVewv-0006c1-RK for ged-emacs-devel@m.gmane.org; Tue, 28 May 2019 12:27:41 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hVewi-0006Vx-Un for emacs-devel@gnu.org; Tue, 28 May 2019 12:27:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hVewg-0000Aa-EA for emacs-devel@gnu.org; Tue, 28 May 2019 12:27:28 -0400 Original-Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]:39926) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hVewf-0006cs-Pz for emacs-devel@gnu.org; Tue, 28 May 2019 12:27:26 -0400 Original-Received: by mail-wm1-x32a.google.com with SMTP id z23so3566523wma.4 for ; Tue, 28 May 2019 09:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=kwE1mamCa2FgyBUbGjC7q+SJBBNeHq4e6E86hB/4zzw=; b=JYgyNgPBNUK1vcK5Fqqa8BpJjUAfoB0PZ7c3BcoR3OIgSFe2z+9yHsVfSUbvRXBZC5 cqG66EuyiFsB3r/WnsTRoUdswlHH5Ju+fetVE/qq+C9WEDe0pHpw5DZyLC5k0z9Q6D4A 1QPuXOtFB14Kzk7CyJA/oUgwXSxeL0qOeYnbiynwdoaxpppKTnJQ+7qoVlYnT8wItQtK sspgVKUq7ocx6wX7QD+SkwkRDWgfi/XCrNNxSm7lHV1wDqiUGClP2Q78UDMojf0r8Eks snmH2+ETDf1yDevy3YAIi+kQvDX/caBx0NclzVqN+yzAEgE3HSix2CooHwvlJQk+x3gM dDeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kwE1mamCa2FgyBUbGjC7q+SJBBNeHq4e6E86hB/4zzw=; b=Lc0za2MEEYKgqWp4IQB/VMm4pguk0JEJRpjLo2DA0otGGFeYQCC8wrV5q4/oRXglUh Ug9cILJhVwnz12yMgHzC2K2rXTH/lzTur6fZxmRDwFhVuxRIZfT5LC2maYpyYcLYIQwz Ggzkt2M91uW7AoVgIGXzZ2XF4DsWUWcwA/z5bEZsPKVdwyxjPzTLSBYogwFQluqvHhX1 1dU/spQCzlsQFVLJczPaSjjn+8XcOQZgLfu1k31YUxbgswsLpVt4mo71pVYbq9CXJJWu 72MmLa590u2DQW8WvEpMYTeC9maFkk3IsMeDB5b8vaX2ORd1z0TQPPG9V7hwMx2XugYj wnsA== X-Gm-Message-State: APjAAAWa4ide9p+Q0obHINEWjdWKTM9rE131nXHHqJVWuazpDQMZM88Y ExO55OJLnbXGZgm0CdkdfIeV3qk3vZq3l1L2KQ== X-Google-Smtp-Source: APXvYqwqRBxAu7l9opau2MFn0ai5g7uKbbJphHNIaxT80zfq4iZ/7i7uPuYV0X0Wap/YOHQmIzC7wnNHAbjSjriCFv4= X-Received: by 2002:a1c:e714:: with SMTP id e20mr4126586wmh.143.1559060703288; Tue, 28 May 2019 09:25:03 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::32a X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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 Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:237111 Archived-At: Found this answer to my question in the list archives. I'm not subscribed, please CC to me. > > Error during redisplay: (jit-lock-function ##) signaled (quit) > > This is indeed the behavior I expect (tho I don't really like it, but I never dared to change jit-lock to set inhibit-quit). > > > sometimes it doesn't. Is there a difference in behavior in this respect when you try it in the GUI vs in a tty? How 'bout in another OS? After recompiling with your patch I cannot reproduce it. Maybe it was fixed by some other change, but more likely that I made a mistake and the problem was never there. I could have been confused by my own `message' replacement since it didn't insert at the buffer end, but rather at the point. Anyway, why I needed this. It is not impossible that during development you write a fontification function that is broken and e.g. falls into infinite loop. You can sort of abort it with C-g, but then fontification code marks the whole region as unfontified (since the function never finished), calls the function again, it gets stuck... And the only way you can end this is by killing Emacs process. Or at least I don't know any better way. It is also possible to accidentally stumble into a finite, but extremely long fontification. For example, if you open a megabyte-large minified JavaScript file. I believe also one of the many Python modes was susceptible at some point. I was trying to write some workaround for my own mode, because it targets log files, which can be hundreds of megabytes in size. Additionally, the mode puts filtering into fontification process, meaning that in fontification callback it can hide everything (if the filter is too strict). And then the callback gets called again and again, chewing through all the megabytes with no apparent way to stop it until it finally finishes minutes later. But would it make sense to adjust fontification code to disable fontification in the current buffer if fontification function is killed with C-g several times? I.e. instead of some custom workaround for my mode only, add something generic to Emacs core. This would give the user a chance to kill offending buffer rather than the whole Emacs. Paul