bug#50112: 28.0.50; ediff help frame does not display text

bug#50112: 28.0.50; ediff help frame does not display text

[David Phillips via Bug reports for GNU Emacs, the Swiss army knife of text editors]

I built emacs this morning from the git master branch.
The latest commit was 9b31ad36094666da6b3281025adc163829d89de8 with
a date stamp of Wed Aug 18 20:02:39 2021 +0300.
I am running the macos GUI version.
First I run /Applications/Emacs/Contents/MacOS/Emacs -Q
then I load two files and run 'ediff-buffers' to compare them.
ediff works just fine except that the frame with the help message
is an empty frame. The '?' command changes the frame size but the
text never renders.


In GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin19.6.0, NS appkit-1894.60 Version 10.15.7 (Build 19H1323))
of 2021-08-18 built on Davids-MacBook-Pro.local
Repository revision: 15a8026cafad4a61a2ba5554c1a3e999244e412c
Repository branch: master
Windowing system distributor 'Apple', version 10.3.1894
System Description:  Mac OS X 10.15.7

Configured using:
'configure --with-ns --prefix=/usr/local AR=/usr/bin/ar
RANLIB=/usr/bin/ranlib 'CFLAGS=-I/usr/local/include
-I/usr/local/opt/libxml2/include -I
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/'
'CPPFLAGS=-I/usr/local/include -I/usr/local/opt/libxml2/include -I
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/
-I/usr/local/opt/qt/include -I/usr/local/opt/readline/include
-I/usr/local/opt/libxml2/include' 'LDFLAGS=-L/usr/local/lib
-L/usr/local/opt/qt/lib -L/usr/local/opt/readline/lib
-L/usr/local/opt/libxml2/lib''

Configured features:
ACL DBUS GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
KQUEUE NS PDUMPER PNG RSVG THREADS TIFF TOOLKIT_SCROLL_BARS XIM ZLIB

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LC_CTYPE: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: BSDmakefile

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils ediff ediff-merg ediff-mult ediff-wind ediff-diff
ediff-help ediff-init ediff-util vc-git diff-mode easy-mmode
vc-dispatcher cl-loaddefs cl-lib seq byte-opt gv bytecomp byte-compile
cconv make-mode iso-transl tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/ns-win ns-win ucs-normalize
mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind kqueue cocoa ns
lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 66017 4644)
(symbols 48 8009 1)
(strings 32 23399 1618)
(string-bytes 1 785876)
(vectors 16 16147)
(vector-slots 8 214546 7009)
(floats 8 29 86)
(intervals 56 615 0)
(buffers 992 14))

bug#50112: 28.0.50; ediff help frame does not display text

[Lars Ingebrigtsen]

David Phillips <dphillips@cfa.harvard.edu> writes:

> I built emacs this morning from the git master branch.
> The latest commit was 9b31ad36094666da6b3281025adc163829d89de8 with
> a date stamp of Wed Aug 18 20:02:39 2021 +0300.
> I am running the macos GUI version.
> First I run /Applications/Emacs/Contents/MacOS/Emacs -Q
> then I load two files and run 'ediff-buffers' to compare them.
> ediff works just fine except that the frame with the help message
> is an empty frame. The '?' command changes the frame size but the
> text never renders.

I can reproduce this problem on Macos, but not in Debian.

I had a brief look at

commit f26a027d6b8e0b894d5d28c446643d411b376ea9
Author: pillule <pillule@riseup.net>
Commit: Martin Rudalics <rudalics@gmx.at>

    Fix ediff3 layouts with window-combination-resize non-nil (Bug#49277)

since that's a recent patch in this area, but it's not immediately clear
why this change should make a difference on Macos, but not Debian.  (I
haven't confirmed that this change is the culprit, mind.)

Perhaps Alan has some insight here; added to the CCs.

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

bug#50112: 28.0.50; ediff help frame does not display text

[martin rudalics]

 > I built emacs this morning from the git master branch.
 > The latest commit was 9b31ad36094666da6b3281025adc163829d89de8 with
 > a date stamp of Wed Aug 18 20:02:39 2021 +0300.
 > I am running the macos GUI version.
 > First I run /Applications/Emacs/Contents/MacOS/Emacs -Q
 > then I load two files and run 'ediff-buffers' to compare them.
 > ediff works just fine except that the frame with the help message
 > is an empty frame. The '?' command changes the frame size but the
 > text never renders.

Assuming that in this situation you have two frames - the main frame and
the help frame: What does evaluating the form

(let ((buffer (window-buffer (frame-root-window (next-frame))))
       (foo (get-buffer-create "*foo*")))
   (with-current-buffer foo
     (insert
      (buffer-name buffer)
      "\n"
      (with-current-buffer buffer
        (buffer-substring 1 (point-max))))))

in the main frame via M-: put into buffer *foo*?

martin

bug#50112: 28.0.50; ediff help frame does not display text

[David Phillips via Bug reports for GNU Emacs, the Swiss army knife of text editors]

I do have two frames (and the help frame has no content). There is a buffer named *Ediff Control Panel* with the help text in it, but it isn’t displayed in the frame labeled Ediff.  When I run ediff-buffers, hit ‘?’, switch back to the main frame, and evaluate the elisp you sent, I get ’nil’ in the mini buffer and the buffer *foo* has the help text in it. However, the help frame is still empty. I’m trying to understand what this means. It seems like the frame has the right buffer assigned to it but that it is in some weird mode so that it isn’t being rendered properly. 
 Thanks for the help!
  David



> On Aug 20, 2021, at 4:18 AM, martin rudalics <rudalics@gmx.at> wrote:
> 
> > I built emacs this morning from the git master branch.
> > The latest commit was 9b31ad36094666da6b3281025adc163829d89de8 with
> > a date stamp of Wed Aug 18 20:02:39 2021 +0300.
> > I am running the macos GUI version.
> > First I run /Applications/Emacs/Contents/MacOS/Emacs -Q
> > then I load two files and run 'ediff-buffers' to compare them.
> > ediff works just fine except that the frame with the help message
> > is an empty frame. The '?' command changes the frame size but the
> > text never renders.
> 
> Assuming that in this situation you have two frames - the main frame and
> the help frame: What does evaluating the form
> 
> (let ((buffer (window-buffer (frame-root-window (next-frame))))
>      (foo (get-buffer-create "*foo*")))
>  (with-current-buffer foo
>    (insert
>     (buffer-name buffer)
>     "\n"
>     (with-current-buffer buffer
>       (buffer-substring 1 (point-max))))))
> 
> in the main frame via M-: put into buffer *foo*?
> 
> martin

bug#50112: 28.0.50; ediff help frame does not display text

[martin rudalics]

 > I do have two frames (and the help frame has no content). There is a
 > buffer named *Ediff Control Panel* with the help text in it, but it
 > isn’t displayed in the frame labeled Ediff.  When I run ediff-buffers,
 > hit ‘?’, switch back to the main frame, and evaluate the elisp you
 > sent, I get ’nil’ in the mini buffer and the buffer *foo* has the help
 > text in it. However, the help frame is still empty. I’m trying to
 > understand what this means. It seems like the frame has the right
 > buffer assigned to it but that it is in some weird mode so that it
 > isn’t being rendered properly.

Is *Ediff Control Panel* the first line of *foo*?  What does *Messages*
show?  Here it contains the four lines

Buffer A: Processing difference region 0 of 1
Buffer B: Processing difference region 0 of 1
Processing difference regions ... done
#<buffer *Ediff Control Panel*>

martin

bug#50112: 28.0.50; ediff help frame does not display text

[David Phillips via Bug reports for GNU Emacs, the Swiss army knife of text editors]

I ran /Applications/Emacs.app/Contents/MacOS/Emacs -Q 
Loaded two files
Ran "ediff-buffers”
Typed ‘?’ to expand the the help frame and then switched back to the main frame. After running the elisp you provided,

*Messages* contains:
--------
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
Buffer A: Processing difference region 0 of 15
Buffer A: Processing difference region 10 of 15
Buffer B: Processing difference region 0 of 15
Buffer B: Processing difference region 10 of 15
Processing difference regions ... done
nil
Mark set
----------
The nil comes from executing the elisp to copy the buffer in the help frame to *foo* and I’d guess is related to things not working correctly.  The "Mark set" was me making sure I had the whole *Messages* buffer.

And *foo* contains:
-----------
*Ediff Control Panel*
    Move around      |      Toggle features      |        Manipulate
=====================|===========================|=============================
p,DEL -previous diff |     | -vert/horiz split   |a/b -copy A/B's region to B/A
n,SPC -next diff     |     h -highlighting       | rx -restore buf X's old diff
    j -jump to diff  |     @ -auto-refinement    |  * -refine current region
   gx -goto X's point|    ## -ignore whitespace  |  ! -update diff regions
  C-l -recenter      |    #c -ignore case        |
  v/V -scroll up/dn  | #f/#h -focus/hide regions | wx -save buf X
  </> -scroll lt/rt  |     X -read-only in buf X | wd -save diff output
    ~ -swap variants |     m -wide display       |
=====================|===========================|=============================
    R -show registry |     = -compare regions    |  M   -show session group
    D -diff output   |     E -browse Ediff manual|  G   -send bug report
    i -status info   |     ? -help off           |  z/q -suspend/quit
-------------------------------------------------------------------------------
For help on a specific command:  Click Button 2 over it; or
              			 Put the cursor over it and type RET.
------------

David


> On Aug 20, 2021, at 11:34 AM, martin rudalics <rudalics@gmx.at> wrote:
> 
> > I do have two frames (and the help frame has no content). There is a
> > buffer named *Ediff Control Panel* with the help text in it, but it
> > isn’t displayed in the frame labeled Ediff.  When I run ediff-buffers,
> > hit ‘?’, switch back to the main frame, and evaluate the elisp you
> > sent, I get ’nil’ in the mini buffer and the buffer *foo* has the help
> > text in it. However, the help frame is still empty. I’m trying to
> > understand what this means. It seems like the frame has the right
> > buffer assigned to it but that it is in some weird mode so that it
> > isn’t being rendered properly.
> 
> Is *Ediff Control Panel* the first line of *foo*?  What does *Messages*
> show?  Here it contains the four lines
> 
> Buffer A: Processing difference region 0 of 1
> Buffer B: Processing difference region 0 of 1
> Processing difference regions ... done
> #<buffer *Ediff Control Panel*>
> 
> martin
> 

bug#50112: 28.0.50; ediff help frame does not display text

[Alan Third]

On Thu, Aug 19, 2021 at 03:33:26PM +0200, Lars Ingebrigtsen wrote:
> David Phillips <dphillips@cfa.harvard.edu> writes:
> 
> > I built emacs this morning from the git master branch.
> > The latest commit was 9b31ad36094666da6b3281025adc163829d89de8 with
> > a date stamp of Wed Aug 18 20:02:39 2021 +0300.
> > I am running the macos GUI version.
> > First I run /Applications/Emacs/Contents/MacOS/Emacs -Q
> > then I load two files and run 'ediff-buffers' to compare them.
> > ediff works just fine except that the frame with the help message
> > is an empty frame. The '?' command changes the frame size but the
> > text never renders.
> 
> I can reproduce this problem on Macos, but not in Debian.
>
<snip>
> 
> Perhaps Alan has some insight here; added to the CCs.

This is a bit weird. When creating the graphics context to draw on we
need to specify a colorspace, so we just use the one that the (OS)
window we're drawing for uses.

However sometimes it seems we get a null from the window instead of a
legit colorspace which causes the graphics context creation to fail. I
don't know why we should ever get a null, but anyway, I've pushed a
change to master that should use a generic colorspace in these
situations.
-- 
Alan Third

bug#50112: 28.0.50; ediff help frame does not display text

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

> However sometimes it seems we get a null from the window instead of a
> legit colorspace which causes the graphics context creation to fail. I
> don't know why we should ever get a null, but anyway, I've pushed a
> change to master that should use a generic colorspace in these
> situations.

I can confirm that this fixes the problem, so I'm closing this bug
report.  

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

bug#50112: 28.0.50; ediff help frame does not display text

[David Phillips via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Thanks! That does indeed fix the problem for me. Now I can have my help frame back and not struggle to remember the keys. 

  Thanks again.
    David

> On Aug 21, 2021, at 8:18 AM, Alan Third <alan@idiocy.org> wrote:
> 
> On Thu, Aug 19, 2021 at 03:33:26PM +0200, Lars Ingebrigtsen wrote:
>> David Phillips <dphillips@cfa.harvard.edu> writes:
>> 
>>> I built emacs this morning from the git master branch.
>>> The latest commit was 9b31ad36094666da6b3281025adc163829d89de8 with
>>> a date stamp of Wed Aug 18 20:02:39 2021 +0300.
>>> I am running the macos GUI version.
>>> First I run /Applications/Emacs/Contents/MacOS/Emacs -Q
>>> then I load two files and run 'ediff-buffers' to compare them.
>>> ediff works just fine except that the frame with the help message
>>> is an empty frame. The '?' command changes the frame size but the
>>> text never renders.
>> 
>> I can reproduce this problem on Macos, but not in Debian.
>> 
> <snip>
>> 
>> Perhaps Alan has some insight here; added to the CCs.
> 
> This is a bit weird. When creating the graphics context to draw on we
> need to specify a colorspace, so we just use the one that the (OS)
> window we're drawing for uses.
> 
> However sometimes it seems we get a null from the window instead of a
> legit colorspace which causes the graphics context creation to fail. I
> don't know why we should ever get a null, but anyway, I've pushed a
> change to master that should use a generic colorspace in these
> situations.
> -- 
> Alan Third