Subject: Re: bug#20369: Rendering problems and fill column

From: Eli Zaretskii <[email-masked]>
Date: Sun, 19 Apr 2015 19:54:53 +0300

> From: Mark Karpov <[email-masked]>
> Date: Sun, 19 Apr 2015 15:57:58 +0600
> 
> I use `fill-column-indicator' package, however, it introduces some
> rendering problems

Which ones, specifically?  They aren't necessarily one and the same
problem, so detailed bug reports with recipes for reproduction are
welcome.

Some of the problems were already discussed, see bug #18417 and the
emacs-devel thread referenced there.

> see this issue for example (other issues are also known):
> 
> https://github.com/alpaker/Fill-Column-Indicator/issues/58
> 
> It may seem to be not a problem of vanilla Emacs, but the author of the
> package says:
> 
> > This appears to be a regression in Emacs's display engine's handling
> > of cursor text properties. I'll look into isolating the underlying
> > issue and filing a bug report. I'll report back here (and close this
> > issue) after doing so.
> 
> Not sure if he did so or not.

He didn't, AFAICS (his last message was posted in November 2014).

> If it's really a regression in Emacs's display engine, can we hope
> that it will be fixed in Emacs 25?

This particular issue not a display problem, it's a genuine problem
with fci-mode vis-à-vis Dired.  Fci-mode puts overlays on the end of
each line; when you invoke dired-revert, that function calls
erase-buffer, which deletes all of the text from the buffer, but
leaves the overlays, all of them now crowded at buffer position 1.
Then Dired re-inserts the directory into the buffer, but fci-mode's
hooks that trigger re-computation of the overlays don't catch this
particular case, so the old overlays are left in place, and redisplay
shows them.

You can work around this by using the quick-and-dirty fix below,
although it's gross: it will trigger re-computation of fci-mode
overlays in all the windows on the frame each time you type 'g'.  So a
better fix is necessary, IMO.

> Also, in my opinion, indication of fill column must be a built-in
> feature, because it's even more important than indication of empty
> lines at the end of file (which is implemented).

I agree; patches to do that are welcome.

Here's the patch I promised:

--- fill-column-indicator.el~	2015-04-19 13:44:54 +0300
+++ fill-column-indicator.el	2015-04-19 15:17:03 +0300
@@ -393,6 +393,7 @@
   '((after-change-functions fci-redraw-region t t)
     (before-change-functions fci-extend-rule-for-deletion nil t)
     (window-scroll-functions fci-update-window-for-scroll nil t)
+    (dired-after-readin-hook fci-redraw-frame)
     (window-configuration-change-hook  fci-redraw-frame)
     (post-command-hook  fci-post-command-check nil t)
     (change-major-mode-hook turn-off-fci-mode nil t)