From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package proposal: visual-path-abbrev.el Date: Mon, 04 Mar 2019 20:03:40 +0200 Message-ID: <83h8ciecub.fsf@gnu.org> References: <87tvglpmcx.fsf@gnu.org> <83k1hhh5mb.fsf@gnu.org> <874l8k47fi.fsf@gnu.org> <83imx0f0x0.fsf@gnu.org> <87k1hg6jl3.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="252415"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Tassilo Horn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 04 19:04:03 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 1h0rwZ-0013ZI-O1 for ged-emacs-devel@m.gmane.org; Mon, 04 Mar 2019 19:04:03 +0100 Original-Received: from localhost ([127.0.0.1]:58356 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h0rwY-0000q4-NA for ged-emacs-devel@m.gmane.org; Mon, 04 Mar 2019 13:04:02 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40932) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h0rwQ-0000pz-Tb for emacs-devel@gnu.org; Mon, 04 Mar 2019 13:03:55 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60221) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h0rwN-0007Qf-Dq for emacs-devel@gnu.org; Mon, 04 Mar 2019 13:03:51 -0500 Original-Received: from [176.228.60.248] (port=4136 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h0rwG-00085D-R3; Mon, 04 Mar 2019 13:03:45 -0500 In-reply-to: <87k1hg6jl3.fsf@gnu.org> (message from Tassilo Horn on Sun, 03 Mar 2019 16:52:56 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:233821 Archived-At: > From: Tassilo Horn > Cc: emacs-devel@gnu.org > Date: Sun, 03 Mar 2019 16:52:56 +0100 > > 1. emacs -Q > 2. M-x load-file RET visual-file-name-abbrev.el RET > 3. M-x rgrep RET (defsubst RET *.el RET ~/Repos/el/emacs > 4. In the *grep* buffer: M-x visual-file-name-abbrev-mode > > As a result, the file names are indeed abbreviated but when I move up > and down using C-n/C-p, I'd expect the file name under point to be > displayed normally (so not the 'display spec but the normal text). With > emacs -Q, the problem is even worse than with my usual config. It seems > the conditional display spec is almost never tested, except when the > window is scrolled, but then usually after scrolling point is not on the > file name anymore which is now shown unabbreviated. Yes, this feature is somewhat tricky to use. The basic problem here is that CONDITION is only evaluated when redisplay examines the text on which you put this display spec, because only then the display engine bumps into this spec. And redisplay is extremely conservative in what portions of text it examines, because doing so is generally expensive, and makes Emacs less responsive. So redisplay is full of shortcuts and optimizations meant to avoid examining portions of text where no changes are expected. For your feature to work reliably, you need one or more overlays examined even if the user just moves point, something that triggers a heavily optimized version of redisplay (because moving point is a very frequent operation). You need to disable some of these optimizations. One way of disabling those optimizations is to make some immaterial change in one or more overlays, because overlay changes cause a more thorough redisplay of the buffer. You can, for example, change some overlay property that will have no effect on display. Another possibility is to have a buffer-local variable that you add to the list of variables which trigger thorough redisplay of its buffer, see the end of frame.el for how this is done. Then whenever you want redisplay to re-evaluate one or more of your overlays, you change the value of that variable. Both of those techniques will need to use post-command-hook, I think. Caveat: I didn't try any of my suggestions, so I cannot be sure they will work, although they should, of course. (I did add the above caveats to the ELisp manual, so they are now documented.)