* bug#15716: 24.3.50; redisplay bug for display-table update
@ 2013-10-25 15:04 Drew Adams
2013-10-25 15:26 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Drew Adams @ 2013-10-25 15:04 UTC (permalink / raw)
To: 15716
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#15716: 24.3.50; redisplay bug for display-table update
2013-10-25 15:04 Drew Adams
@ 2013-10-25 15:26 ` Eli Zaretskii
0 siblings, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2013-10-25 15:26 UTC (permalink / raw)
To: Drew Adams; +Cc: 15716
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#15716: 24.3.50; redisplay bug for display-table update
[not found] ` <<83eh79gyma.fsf@gnu.org>
@ 2013-10-25 15:53 ` Drew Adams
2013-10-25 18:21 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Drew Adams @ 2013-10-25 15:53 UTC (permalink / raw)
To: Eli Zaretskii, Drew Adams; +Cc: 15716
> `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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#15716: 24.3.50; redisplay bug for display-table update
2013-10-25 15:53 ` Drew Adams
@ 2013-10-25 18:21 ` Eli Zaretskii
0 siblings, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2013-10-25 18:21 UTC (permalink / raw)
To: Drew Adams; +Cc: 15716
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#15716: 24.3.50; redisplay bug for display-table update
[not found] ` <<83d2mtgqik.fsf@gnu.org>
@ 2013-10-25 18:32 ` Drew Adams
2015-12-26 1:10 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Drew Adams @ 2013-10-25 18:32 UTC (permalink / raw)
To: Eli Zaretskii, Drew Adams; +Cc: 15716
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#15716: 24.3.50; redisplay bug for display-table update
2013-10-25 18:32 ` bug#15716: 24.3.50; redisplay bug for display-table update Drew Adams
@ 2015-12-26 1:10 ` Lars Ingebrigtsen
0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2015-12-26 1:10 UTC (permalink / raw)
To: Drew Adams; +Cc: 15716
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-12-26 1:10 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <<a6bb675b-4f86-4611-b023-9a5304a18098@default>
[not found] ` <<83d2mtgqik.fsf@gnu.org>
2013-10-25 18:32 ` bug#15716: 24.3.50; redisplay bug for display-table update Drew Adams
2015-12-26 1:10 ` Lars Ingebrigtsen
[not found] <<5f2f5004-0d43-45c6-8285-dfcf2a3deb5e@default>
[not found] ` <<83eh79gyma.fsf@gnu.org>
2013-10-25 15:53 ` Drew Adams
2013-10-25 18:21 ` Eli Zaretskii
2013-10-25 15:04 Drew Adams
2013-10-25 15:26 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).