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: Sun, 30 Jun 2019 01:49:46 +0200 Message-ID: References: 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="96907"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Emacs developers To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 30 01:50:15 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.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hhN6k-000P5M-G0 for ged-emacs-devel@m.gmane.org; Sun, 30 Jun 2019 01:50:14 +0200 Original-Received: from localhost ([::1]:42462 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhN6j-0005NU-1v for ged-emacs-devel@m.gmane.org; Sat, 29 Jun 2019 19:50:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39311) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhN6X-0005N9-1c for emacs-devel@gnu.org; Sat, 29 Jun 2019 19:50:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hhN6V-0006td-Lp for emacs-devel@gnu.org; Sat, 29 Jun 2019 19:50:00 -0400 Original-Received: from mail-wm1-x343.google.com ([2a00:1450:4864:20::343]:52290) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hhN6V-0006rz-8r for emacs-devel@gnu.org; Sat, 29 Jun 2019 19:49:59 -0400 Original-Received: by mail-wm1-x343.google.com with SMTP id s3so12360806wms.2 for ; Sat, 29 Jun 2019 16:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1LTwvDsMpOAVofZsNtElWWL/bUCFtJyHRBcRh6LlPUk=; b=LwQ9CpXfXjXSBvW2mAqC1KHhJ7OY1njV0mqvULr5eZlwxErk6aF0OpycZoJT8myX/5 3nSXQUeIjaL6w7ibzOFdNSAA7eowUDa5zvakx1BfZWiy7+nX8FAFjKg4eKxnQNbmGgBm 1gsP+q7Jvw0Du8sp8M/UsnMdnYsvpI+wVkcyD8yESCW8v/NVWHTdOy4Gqo4mo62jmaEl nD2lTa+qsrZOLTD0fFBsIQHNcbkz+fZoRgsLjyO2j5KyfnKSEt3Xq5t2dVW6yYpJah4a ouK12RvlM43tLbTA0MNTxXM/5DUZTiW1H9mn1igFj3Qt/wlajkxTnJ2rGwJy9TDf7MrB iZ7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1LTwvDsMpOAVofZsNtElWWL/bUCFtJyHRBcRh6LlPUk=; b=sT0aKkZYfwYNtf6pOV2/Bnzw34Z3cWg6ZKpgfhBvJ6APdmMEjGI3vO8XiCpTl2bKu0 9QUWbSTwdqamB0OpC2iIf4yVeHtmjSyA6fkVYcxdZyMn1Gar0FI21aASaXHOh5dX/H27 R5tl8H7zZuSFj+DycQ/nl3YQ9vGu5JnLDLsoaiFwd05Pydjc++gtCNjBTBj9SKwhzT2M QC7vSNwBMVogG0f0ETgWH1gPE2UsHVKiU4Uqc34jDzXhb71WP9MXIoGn0Q+5dWyuXd6n UNc7sTYcJ97ftwVEBax9hiRo4MdMlgtu3v8XUkACpGOQpUMciWuJdGiYukxfWzII8UNo JlqQ== X-Gm-Message-State: APjAAAXdO/Esj/j8PidZTWNdPQKKr/U7gc7CLGWmKyooBDUBuOq8DMNp En2GElevgJzSiVCOWA3TBt19A2pDEcHqPrPtMF15tkA= X-Google-Smtp-Source: APXvYqzxNU/3Gt9EKXxJZd8oXLtbcxy0QhI6Y/Dd2Zd2NOknOtS1Q2KmJr5/NEfFfL/vJ99kB9A7RxV1JrP1mOgUty0= X-Received: by 2002:a1c:c305:: with SMTP id t5mr11441900wmf.163.1561852197495; Sat, 29 Jun 2019 16:49:57 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::343 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:238245 Archived-At: On Sat, 29 Jun 2019 at 23:26, Stefan Monnier wrote: > > > I'm not sure if this is flexible enough. I don't like the idea of C-g > > already invoking some code (that e.g. disables font-locking). > > [...] It definitely wouldn't disable font-locking right away. > > The disabling would only be in response to a "large" number of C-g, > which presumably should only be needed in extreme circumstances > (basically when currently the user ends up killing Emacs instead). So, basically, as I understand, C-g handler in your proposal would look like (I know it is in C code, but...), simplified: (defun handle-C-g (...) (when registered-many-C-g-callback ; variable set by e.g. font-locking code (setq num-C-g-presses (1+ num-C-g-presses)) (when (> num-C-g-presses 3) (funcall registered-many-C-g-callback)))) and font-locking code would be roughly (let ((registered-many-C-g-callback (lambda () (setq font-lock-mode nil)))) ; call fontification function, process its result etc. ) That's what I meant: here `handle-C-g' already invokes some callback that higher level (in this case font-locking) registers. I propose that instead font-locking code simply says "I will process multiple C-g presses somehow, please count them" by let-binding `count-C-g-presses' to t. The idea is to not invoke the "abort" callback immediately when the 3rd C-g is pressed, but instead let the iteration finish gracefully and _then_ let the higher-level code (font-locking) abort or not based on all the information it has by now. Usually this information would be just result of `(too-many-C-g-recently)', but could be anything in the future, so we are more flexible. > > So, I'd like to be able to _handle_ `quit' signal in the function > > itself and stop extending the region and return immediately, so that I > > don't throw away work on a considerable region of text that has been > > done already. > > I don't understand why you say "don't throw away work on a considerable > region of text that has been done already": if you're in the middle of > extending the region, presumably no "work" has been done yet. For example, my function decides to fontify 1000 lines of text and by the time C-g is pressed (triggering the signal) it has already fontified 500 of them (this is already more than what font-locking code wanted, because I extended the requested region). I'd like to be able to notify font-locking code about the work that has been done, even if I planned to do even more. If I raise `quit' signal or let C-g raise it by default, all this work is thrown away. > Could `while-no-input` be usable in this case? This macro uses `with-local-quit', which, as I understand will rethrow signal `quit' after the body. As a result, font-locking code will still see my function terminate non-locally, deem the whole invocation failed and set property `fontified' to nil. So no, to achive what I want I need to let my function return normally somehow. > > > I'm not sure if it is the best solution, but I'd propose C-g to be > > counted not when `quit' signal is caught, but when it would be > > emitted, even if `inhibit-quit' is t. And font-locking code would > > look something like this: [...] > > I think if C-g resulted in (signal 'quit ...), then presumably we exited > this code, so the only really interesting case should be the one where > we just have `quit-flag` set to t. Yes, but the point is in that I want to avoid C-g resulting in the signal by binding `inhibit-quit' inside my fontification function. But still have C-g handler note that C-g is pressed and let fontification code find if it is being pressed too often. > Maybe we should change the C-g code so it sets `quit-flag` to the > number of C-g that are pending. This generally sounds like a good idea: I'm always in favour of having more information. However, in my case it is not enough. I guess it is easier to explain by pseudocode of my fontification function: (defun my--fontify-region (region-start region-end _loudly) ;; Very fast, so always work on large regions to avoid setup overhead. (setq region-end (+ region-start 50000)) ;; Here comes some internal setup. ... (let ((fontified-up-to region-start) (inhibit-quit t)) ;; While `quit' is inhibitted, the below loop will still be aborted on C-g. (while (and (< fontified-up-to region-end) (null quit-flag)) ... ; do some work on the next small chunk of text; this is very fast, ; but as the region is quite big, the loop is iterated many times ) ;; Always exit normally. Font-locking code will find out if we suppressed ;; a C-g through other means, i.e. using (too-many-C-g-recently). (setq quit-flag nil) `(jit-lock-bounds ,region-start . ,fontified-up-to))) Note that the function doesn't suppress any other signals/errors. Paul