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: Sat, 29 Jun 2019 19:50:13 +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="53576"; 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 Sat Jun 29 19:50:52 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 1hhHUy-000DqW-55 for ged-emacs-devel@m.gmane.org; Sat, 29 Jun 2019 19:50:52 +0200 Original-Received: from localhost ([::1]:41698 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhHUx-0005HR-61 for ged-emacs-devel@m.gmane.org; Sat, 29 Jun 2019 13:50:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37449) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhHUc-0005EH-1Z for emacs-devel@gnu.org; Sat, 29 Jun 2019 13:50:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hhHUa-0008Cf-Sk for emacs-devel@gnu.org; Sat, 29 Jun 2019 13:50:29 -0400 Original-Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]:38978) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hhHUZ-0008At-L3 for emacs-devel@gnu.org; Sat, 29 Jun 2019 13:50:28 -0400 Original-Received: by mail-wr1-x42d.google.com with SMTP id x4so9457427wrt.6 for ; Sat, 29 Jun 2019 10:50:26 -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=x4Npbmrb59OFh/n8uTsYuBizYW+zFOEl7oUHjr1IhJc=; b=XITyPknz416UgL2A0AtVb7CKMS2us0EgLkBpuQ7LgCZkdiRW9HlAEO3NYgtLTrP37U 1m89NLTm4O1NVoZVgpkRKhtjYS3mbG1k8bS7Zgg5ei+fvJjEGKwHfm6B1hRjnnIxlGtx Q/3z/WhLuDKNnzvGcl/oTve6j3SEnLlX0M67HR/A66lc24yO6OsUi4ZaFVPD0SzQZirD ip5rQiOasBiEfcA6KHk2WbVSJycS2WZC1NPEkEEJkBB8FkwW1sU/pOhLZuT5HzXcBzpf ZCnO09J+aNMVy3Pw7Anh2tGx//UCdygbTL0JjRu3bm2JoOutV89FUHX1TXnBNghmrjEM LksQ== 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=x4Npbmrb59OFh/n8uTsYuBizYW+zFOEl7oUHjr1IhJc=; b=Q2xAwyrDrpUr5suoAXvZOjF8dVhpONsWlpWsj7unPzcb1LtkW+bbJOq8oCQRKMnbC+ D7FheKjrr8uM7FygM19Qibm7b7H/SLNfMICSW7U1y9850clR21CvN7mDMFvr0Rhj4KyF cOQjOw9dTrx6LKEEcdT+KXosOwyezbQxNNH7w/zToMxSnoHVbI2+SuebQ028Nm4o8NZX Agu49onYLouyT88o717J+xtVKflmxqG5E2Skt2tUOCjK0UvXezcrO5JJt6tm1W0cFAsJ j/4K+ZoLRXVXC2MOYQBzUaYPlXZrOcXc01O37/L0InRTFBryuuAmd7/yBEwRQjrmPtDS LOqg== X-Gm-Message-State: APjAAAXFQhMeJE7HX93j/QXUIFVRI31kf7iljanKcE/Ozo/Eb1E/lmh1 X6LiyqVbjC5gDTpFYz9/eQMTXNqehz8tfz/YLg== X-Google-Smtp-Source: APXvYqyTPq4nB187GkVfSjZjinvGazRC1vX9BkimxZG9p8YDkb5uXHdniVT+VBrkDGTw0ARHnuQAQ8y8JvPlKKMnV/k= X-Received: by 2002:adf:f3cc:: with SMTP id g12mr9445009wrp.149.1561830624906; Sat, 29 Jun 2019 10:50:24 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::42d 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:238237 Archived-At: Found this answer to my question in the list archives. I'm not subscribed, please CC to me. > Right, here's how I could imagine a "desirable" behavior: > > - everytime some operation may block Emacs, it should "register" > somewhere (probably some let-binding of a global var is all it takes). > - After hitting C-g, a timer is started. > - If this timer is reached before the C-g has had to chance to be > processed, emit a message in the echo area explaining what Emacs is > currently doing (based on the "registered" information above). > - when we reach the Nth C-g in a row within the same "registered" > operation, we abort the operation (e.g. by calling an ad-hoc > function provided while "registering"). 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). Please read on to see a usecase that I feel would be impossible to support with your proposal. My fontification function often extends the fontification region considerably and then returns `(jit-lock-bounds START . END)', as required in the documentation. In my case this makes fontification much faster, because the function itself is very fast and most of the time is spent in various setups (both in fontlocking code and the function itself), not in traversing through the region to be fontified. 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. However, fontlocking code shouldn't discard the results (as otherwise this is pointless). So, I cannot resignal `quit', I have to return normally. But I also don't want to "eat" this signal and hide C-g press from Emacs' monitoring code. So basically, I want font-locking still continue to work for a while, even if C-g has been pressed too many times, but if so, abort soon. 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: (let ((count-C-g-presses t)) ; Instead of "registering" as you proposed, I think we just ; need to tell C-g handler to count presses while inside ; certain blocks of code. (condition-case error (let ((fontified-region (funcall actual-handler ...))) ;; Process the fontified region ...) (error ;; This logs any errors inside the handler, including uncaught ;; `quit' signals. Just as now. ...)) (when (too-many-C-g-recently) ; This would count both C-g that resulted in (signal 'quit ...) ; and those that resulted in `(setq quit-flag t)'. ;; The below forms are roughly what would be "registered" in your ;; proposal. I feel leaving it up to the caller gives more ;; flexibility in actually permorming "abort everything" tasks. (setq font-lock-mode nil) (message "Too many C-g, font-locking disabled"))) I think I could try to implement this myself, but on the other hand I'm certainly not familiar with Emacs internals. So I would gladly give up this task to someone else who would like to do it. Paul