bug#20369: Rendering problems and fill column

bug#20369: Rendering problems and fill column

[Mark Karpov]

Hello.

I use `fill-column-indicator' package, however, it introduces some
rendering problems, 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. If it's really a regression in Emacs's
display engine, can we hope that it will be fixed in Emacs 25? 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).

What is your opinion on this problem?

Best,

— Mark Karpov

bug#20369: Rendering problems and fill column

[Eli Zaretskii]

> From: Mark Karpov <markkarpov@opmbx.org>
> 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)

bug#20369: Rendering problems and fill column

[Stefan Monnier]

> 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.

We could put the `evaporate' property on those overlays, maybe?


        Stefan

bug#20369: Rendering problems and fill column

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Mark Karpov <markkarpov@opmbx.org>, 20369@debbugs.gnu.org
> Date: Sun, 19 Apr 2015 22:14:42 -0400
> 
> > 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.
> 
> We could put the `evaporate' property on those overlays, maybe?

Maybe.  I really don't have a clear idea of what these overlays should
and should not do.

bug#20369: Rendering problems and fill column

[Eli Zaretskii]

> Date: Mon, 20 Apr 2015 05:36:54 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 20369@debbugs.gnu.org, markkarpov@opmbx.org
> 
> > From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> > Cc: Mark Karpov <markkarpov@opmbx.org>, 20369@debbugs.gnu.org
> > Date: Sun, 19 Apr 2015 22:14:42 -0400
> > 
> > > 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.
> > 
> > We could put the `evaporate' property on those overlays, maybe?
> 
> Maybe.  I really don't have a clear idea of what these overlays should
> and should not do.

Actually, no, this won't work, at least not easily, because those
overlays are empty, so they cannot have the 'evaporate' property
without, well, evaporating on the spot.

bug#20369: Possible inclusion of fci-mode

[Mark Karpov]

In general, I think it's pretty easy to take already working `fci-mode':

https://github.com/alpaker/Fill-Column-Indicator/blob/master/fill-column-indicator.el

make it work smoothly with the rest of Emacs (this means fix that bug
and bug when some lines are shifted in ERC and after
`report-emacs-bug'). Maybe some cosmetic changes… It's too bad that it's
impossible to display overlay when actual line is empty (no idea if it
could be fixed, but it causes some little problems in `ace-window' mode
too, for example). I think it wouldn't hurt if this mode were enabled by
default in Emacs 25. All major editors, for example Atom, have this
fill-column indicator… pretty nice.

In principle I could dig into it, although I only have desire, but no
free time. Probably you can do it much better, if you have time for it.

Regards,

— Mark Karpov

bug#20369: Possible inclusion of fci-mode

[Eli Zaretskii]

> From: Mark Karpov <markkarpov@opmbx.org>
> Date: Mon, 20 Apr 2015 23:52:07 +0600
> 
> In general, I think it's pretty easy to take already working `fci-mode':
> 
> https://github.com/alpaker/Fill-Column-Indicator/blob/master/fill-column-indicator.el
> 
> make it work smoothly with the rest of Emacs (this means fix that bug
> and bug when some lines are shifted in ERC and after
> `report-emacs-bug').

I think it also has (or had?) problems with line-move-visual.

> Maybe some cosmetic changes… It's too bad that it's
> impossible to display overlay when actual line is empty (no idea if it
> could be fixed, but it causes some little problems in `ace-window' mode
> too, for example). I think it wouldn't hurt if this mode were enabled by
> default in Emacs 25. All major editors, for example Atom, have this
> fill-column indicator… pretty nice.

I'd like to see this integrated into the display engine, before we
recommend it, let alone make it the default.  Right now, it plugs
itself into all kinds of hooks, and moves overlays after redisplay,
which generally requires an additional redisplay cycle, with a net
effect of slowing down redisplay.

> In principle I could dig into it, although I only have desire, but no
> free time. Probably you can do it much better, if you have time for it.

Sure, volunteers are welcome.  If needed, I can offer help and
guidance with changes in the display engine.

Thanks.

bug#20369: Possible inclusion of fci-mode

[Stefan Monnier]

> In general, I think it's pretty easy to take already working `fci-mode':

> https://github.com/alpaker/Fill-Column-Indicator/blob/master/fill-column-indicator.el

I'd be happy to see it added to GNU ELPA.  AFAICT its copyright is OK
(Alp already signed the paperwork and the other contributions seem to
be small enough).

> too, for example). I think it wouldn't hurt if this mode were enabled by
> default in Emacs 25.

I don't think this is an option.  AFAICT fci-mode is just not reliable and
efficient enough for that.


        Stefan

bug#20369: Rendering problems and fill column

[Stefan Kangas]

Mark Karpov <markkarpov@opmbx.org> writes:

> Hello.
>
> I use `fill-column-indicator' package, however, it introduces some
> rendering problems, 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. If it's really a regression in Emacs's
> display engine, can we hope that it will be fixed in Emacs 25? 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).
>
> What is your opinion on this problem?

It seems like the author of Fill-Column-Indicator is now recommending
the use of "display-fill-column-indicator":

> The functionality provided by this package has now been implemented
> natively in Emacs as display-fill-column-indicator-mode, available as of
> version 27.0.90. Unless you are forced to use an older Emacs, you should
> use the native implementation instead of fci-mode. It's unaffected by
> most of the compatibility issues that this add-on has.

https://github.com/alpaker/fill-column-indicator

Does that mean that this bug could be closed, or is there more to do
here?

bug#20369: Rendering problems and fill column

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 10 Dec 2020 15:11:43 -0600
> Cc: 20369@debbugs.gnu.org
> 
> It seems like the author of Fill-Column-Indicator is now recommending
> the use of "display-fill-column-indicator":
> 
> > The functionality provided by this package has now been implemented
> > natively in Emacs as display-fill-column-indicator-mode, available as of
> > version 27.0.90. Unless you are forced to use an older Emacs, you should
> > use the native implementation instead of fci-mode. It's unaffected by
> > most of the compatibility issues that this add-on has.
> 
> https://github.com/alpaker/fill-column-indicator
> 
> Does that mean that this bug could be closed, or is there more to do
> here?

I think this should be closed, yes.

bug#20369: Rendering problems and fill column

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> It seems like the author of Fill-Column-Indicator is now recommending
>> the use of "display-fill-column-indicator":
>>
>> > The functionality provided by this package has now been implemented
>> > natively in Emacs as display-fill-column-indicator-mode, available as of
>> > version 27.0.90. Unless you are forced to use an older Emacs, you should
>> > use the native implementation instead of fci-mode. It's unaffected by
>> > most of the compatibility issues that this add-on has.
>>
>> https://github.com/alpaker/fill-column-indicator
>>
>> Does that mean that this bug could be closed, or is there more to do
>> here?
>
> I think this should be closed, yes.

Done.

If anyone disagrees and there is more to do here, please reopen the bug.