bug#15716: 24.3.50; redisplay bug for display-table update

bug#15716: 24.3.50; redisplay bug for display-table update

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]

This seems to be a regression; I have never seen it before.

See attached screenshots, from the same session.  The bad one (NG) was
taken after `C-l', which should have taken care of any redisplay
problem.  The good one (OK) was taken after then iconifying (thumbifying,
actually) and then restoring the frame - that took care of the display
problem.

The part of the displayed buffer that got messed up is the result of
modifying the display table for character ^L - what looks like a sunken
line of text "Section (Printable Page)" is in fact just a ^L character.
The code that does this is here:
http://www.emacswiki.org/emacs-en/download/pp-c-l.el.

This is the part of the code that updates the display table:

(lambda (window)
  (let ((display-table  (or (window-display-table window)
                            (make-display-table))))
    (aset display-table ?\014 (and pretty-control-l-mode
                                   (pp^L-^L-display-table-entry window)))
    (set-window-display-table window display-table)))

BTW/FWIW - I think I have also noticed, with this build (perhaps other
recent builds too?), the need to hit `C-l' more often.  Until now I have
probably used `C-l' only a few times over the last decade or so - hasn't
been needed.  (In the old days it was needed much more often.)

HTH.



In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-10-19 on LEG570
Bzr revision: 114715 rgm@gnu.org-20131019023520-s8mwtib7xcx9e05w
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'

[-- Attachment #2: throw-emacs-redisplay-bug-OK.png --]
[-- Type: image/png, Size: 3312 bytes --]

[-- Attachment #3: throw-emacs-redisplay-bug-NG.png --]
[-- Type: image/png, Size: 3476 bytes --]

bug#15716: 24.3.50; redisplay bug for display-table update

[Eli Zaretskii]

> Date: Fri, 25 Oct 2013 08:04:14 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> See attached screenshots, from the same session.  The bad one (NG) was
> taken after `C-l', which should have taken care of any redisplay
> problem.

`C-l' does not necessarily do a redisplay, at least not by default.
It did so in the past, but ceased to since Emacs 23.1, where `C-l' was
bound to 'recenter-top-bottom' instead of 'recenter'.

> The good one (OK) was taken after then iconifying (thumbifying,
> actually) and then restoring the frame - that took care of the display
> problem.
> 
> The part of the displayed buffer that got messed up is the result of
> modifying the display table for character ^L - what looks like a sunken
> line of text "Section (Printable Page)" is in fact just a ^L character.
> The code that does this is here:
> http://www.emacswiki.org/emacs-en/download/pp-c-l.el.
> 
> This is the part of the code that updates the display table:
> 
> (lambda (window)
>   (let ((display-table  (or (window-display-table window)
>                             (make-display-table))))
>     (aset display-table ?\014 (and pretty-control-l-mode
>                                    (pp^L-^L-display-table-entry window)))
>     (set-window-display-table window display-table)))

Emacswiki seems to be off-line.  But unless you are saying that
turning on this feature _always_ results in garbled display, I will
need a recipe to reproduce the problem, or else it is impossible to
debug it.

> BTW/FWIW - I think I have also noticed, with this build (perhaps other
> recent builds too?), the need to hit `C-l' more often.  Until now I have
> probably used `C-l' only a few times over the last decade or so - hasn't
> been needed.  (In the old days it was needed much more often.)

You read too much into what `C-l' does.  I recommend redraw-display,
if you want to force a thorough redisplay.

Anyway, all those situations should be reported, if they are
reproducible.  You shouldn't need to force redisplay manually.

bug#15716: 24.3.50; redisplay bug for display-table update

[Drew Adams]

> `C-l' does not necessarily do a redisplay, at least not by default.
> It did so in the past, but ceased to since Emacs 23.1, where `C-l'
> was bound to 'recenter-top-bottom' instead of 'recenter'.

OK.  So the only bug is in the display, not in `C-l' not fixing the
problem.

> Emacswiki seems to be off-line.

It's back up.  It was down for a few minutes.  I reported it to the
wiki maintainer.

> But unless you are saying that
> turning on this feature _always_ results in garbled display, I will
> need a recipe to reproduce the problem, or else it is impossible to
> debug it.

No, this feature does not cause the problem.  There is apparently a
display problem that occurred this one time.  I was surprised, as I
said, because I have never seen it before.  (And I mistakenly expected
`C-l' to fix it.)  I do not have a recipe to repro it.  I was hoping 
that perhaps the description, wrt display-table modification, might
ring a bell wrt recent Emacs changes.  If not, I guess there's nothing
you can do at this point.

bug#15716: 24.3.50; redisplay bug for display-table update

[Eli Zaretskii]

> Date: Fri, 25 Oct 2013 08:53:15 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 15716@debbugs.gnu.org
> 
> > Emacswiki seems to be off-line.
> 
> It's back up.  It was down for a few minutes.  I reported it to the
> wiki maintainer.

It seems to be down again.

> > But unless you are saying that
> > turning on this feature _always_ results in garbled display, I will
> > need a recipe to reproduce the problem, or else it is impossible to
> > debug it.
> 
> No, this feature does not cause the problem.  There is apparently a
> display problem that occurred this one time.  I was surprised, as I
> said, because I have never seen it before.  (And I mistakenly expected
> `C-l' to fix it.)  I do not have a recipe to repro it.  I was hoping 
> that perhaps the description, wrt display-table modification, might
> ring a bell wrt recent Emacs changes.  If not, I guess there's nothing
> you can do at this point.

I'll at least try to load the feature and see if I can reproduce the
garbled display.

When (if) it happens next, I suggest to "C-h l" and record both your
keystrokes and what you remember you were doing last.  A list of major
mode and minor modes in effect in that buffer might also be important.

bug#15716: 24.3.50; redisplay bug for display-table update

[Drew Adams]

> I'll at least try to load the feature and see if I can reproduce the
> garbled display.

OK, but I doubt that you will be able to. As I say, I have seen the
problem only once.

> When (if) it happens next, I suggest to "C-h l" and record both your
> keystrokes and what you remember you were doing last.  A list of
> major mode and minor modes in effect in that buffer might also be
> important.

OK.

bug#15716: 24.3.50; redisplay bug for display-table update

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

>> I'll at least try to load the feature and see if I can reproduce the
>> garbled display.
>
> OK, but I doubt that you will be able to. As I say, I have seen the
> problem only once.
>
>> When (if) it happens next, I suggest to "C-h l" and record both your
>> keystrokes and what you remember you were doing last.  A list of
>> major mode and minor modes in effect in that buffer might also be
>> important.
>
> OK.

Apparently this didn't happen the next two years, so I'm closing this
bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no