bug#15886: 24.3.50; Incorrect window-text-height with non-zero line-spacing

bug#15886: 24.3.50; Incorrect window-text-height with non-zero line-spacing

[Robert Dallas Gray]

On a graphical display, when `line-spacing' is non-zero,
`window-text-height' reports an incorrect number; equally,
`set-window-text-height' can't be used properly. This impacts on
libraries which use `set-window-text-height' e.g. to attempt to size a
window accurately.

To reproduce:
In a graphical display, `M-: (setq line-spacing 5)', then `M-:
(window-text-height)'. Note the incorrect result. 




In GNU Emacs 24.3.50.1 (x86_64-apple-darwin13.0.0, NS apple-appkit-1265.00)
of 2013-11-10 on Pud.local
Windowing system distributor `Apple', version 10.3.1265
Configured using:
`configure --prefix=/usr/local/Cellar/emacs/HEAD --without-dbus
--enable-locallisppath=/usr/local/share/emacs/site-lisp
--infodir=/usr/local/Cellar/emacs/HEAD/share/info/emacs
--without-gnutls --with-ns --disable-ns-self-contained'

Important settings:
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  flycheck-mode: t
  show-smartparens-mode: t
  smartparens-mode: t
  global-auto-complete-mode: t
  auto-complete-mode: t
  linum-mode: t
  shell-dirtrack-mode: t
  project-persist-mode: t
  global-auto-revert-mode: t
  ido-everywhere: t
  delete-selection-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Recent input:
<C-down> <C-down> <C-down> C-x C-s <C-down> <C-down> 
<C-down> <C-down> <C-down> <C-down> <C-down> <C-up> 
<down> <up> <left> C-c <down> C-c . d e l e t e <return> 
<down-mouse-1> <mouse-1> <down-mouse-1> <mouse-1> <down-mouse-1> 
<mouse-1> <down-mouse-1> <mouse-1> <return> ; ; SPC 
p a c k a g e - d e l e t e SPC h a s SPC d i f f e 
r e n t SPC s i g n a t u r e s SPC d e p e d i n <backspace> 
<backspace> <backspace> n d i n g SPC o n SPC e m a 
c s SPC v e r s i o n , <return> ; ; SPC b u t SPC 
u s i n g SPC t h e SPC f i r s t SPC a r g SPC s h 
o u l d SPC h a n d l e SPC b o t h <right> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <right> <right> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <M-backspace> t 
a k i n g SPC <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <left> SPC f r o m SPC a d v i c e 
<right> C-x C-s C-c <down> C-c <up> C-c <right> C-s 
a d v C-s <right> <right> <down> <down> <down> <down> 
<down> <wheel-up> <double-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <down-mouse-1> <mouse-1> M-x r e 
p o <return>

Recent messages:
FlyC: You should have a section marked ";;; Commentary:"
FlyC: You should have a section marked ";;; Code:"
FlyC: The first line should be of the form: ";;; package --- Summary"
FlyC: You should have a section marked ";;; Commentary:"
FlyC: You should have a section marked ";;; Code:"
Saving file /Users/robertdallasgray/.emacs.d/pallet/test/pallet-test.el...
Wrote /Users/robertdallasgray/.emacs.d/pallet/test/pallet-test.el
Saving file /Users/robertdallasgray/.emacs.d/pallet/test/pallet-test.el...
Wrote /Users/robertdallasgray/.emacs.d/pallet/test/pallet-test.el
Mark saved where search started
scroll-down-command: Beginning of buffer [18 times]

Load-path shadows:
/Users/robertdallasgray/.emacs.d/.cask/24.3.50.1/elpa/flycheck-20131108.1337/.dir-locals hides /Users/robertdallasgray/.emacs.d/.cask/24.3.50.1/elpa/fringe-helper-20130519.1641/.dir-locals
~/.emacs.d/custom hides /usr/local/Cellar/emacs/HEAD/share/emacs/24.3.50/lisp/custom
/Users/robertdallasgray/.emacs.d/.cask/24.3.50.1/elpa/flycheck-20131108.1337/.dir-locals hides /usr/local/Cellar/emacs/HEAD/share/emacs/24.3.50/lisp/gnus/.dir-locals

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
jka-compr misearch multi-isearch pallet loadhist debug macrostep pp
shell-pop term ehelp electric windmove hl-line sr-speedbar speedbar
sb-image ezimage dframe dired org-wl org-w3m org-vm org-rmail org-mhe
org-mew org-irc org-jsinfo org-infojs org-html org-exp ob-exp
org-exp-blocks org-info org-gnus gnus-util org-docview org-bibtex bibtex
org-bbdb org-mobile org-agenda org byte-opt bytecomp byte-compile cconv
ob-tangle ob-ref ob-lob ob-table org-footnote org-src ob-comint ob-keys
org-pcomplete org-list org-faces org-entities org-version ob-emacs-lisp
ob org-compat org-macs ob-eval org-loaddefs format-spec cal-menu
calendar cal-loaddefs markdown-mode noutline outline easy-mmode
make-mode vc-git desktop frameset flycheck find-func help-mode easy-kill
graphene-smartparens-config smartparens-config smartparens-html
smartparens thingatpt auto-complete-config auto-complete popup linum
imenu-anywhere imenu graphene-theme solarized-light-theme
solarized-definitions uniquify readline-complete shell pcomplete comint
ansi-color ring graphene graphene-look graphene-osx-defaults
exec-path-from-shell graphene-keys graphene-projects project-persist
edmacro kmacro graphene-speedbar graphene-env autorevert filenotify smex
ido graphene-editing web-mode disp-table delsel
graphene-helper-functions advice noflet rx info easymenu cask help-fns
cl-macs gv cl cask-bootstrap epl git commander f dash s cl-loaddefs
cl-lib package server time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel ns-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process cocoa ns
multi-tty emacs)

bug#15886: 24.3.50; Incorrect window-text-height with non-zero line-spacing

[Eli Zaretskii]

> From: Robert Dallas Gray <mail@robertdallasgray.com>
> Date: Wed, 13 Nov 2013 19:23:19 +0000
> 
> On a graphical display, when `line-spacing' is non-zero,
> `window-text-height' reports an incorrect number; equally,
> `set-window-text-height' can't be used properly. This impacts on
> libraries which use `set-window-text-height' e.g. to attempt to size a
> window accurately.

Those libraries should use 'window-screen-lines' instead.

I think 'window-text-height' should continue doing what it does, as
many packages, and Emacs itself, depend on its current behavior.

bug#15886: 24.3.50; Incorrect window-text-height with non-zero line-spacing

[Robert Dallas Gray]

On 13 Nov 2013, at 20:32, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Robert Dallas Gray <mail@robertdallasgray.com>
>> Date: Wed, 13 Nov 2013 19:23:19 +0000
>> 
>> On a graphical display, when `line-spacing' is non-zero,
>> `window-text-height' reports an incorrect number; equally,
>> `set-window-text-height' can't be used properly. This impacts on
>> libraries which use `set-window-text-height' e.g. to attempt to size a
>> window accurately.
> 
> Those libraries should use 'window-screen-lines' instead.
> 
> I think 'window-text-height' should continue doing what it does, as
> many packages, and Emacs itself, depend on its current behavior.

OK, but is there a parallel setter method, or some way to set the height of a window in pixels, so that a window could be correctly sized taking into account line-spacing?

Incidentally, the particular library that raised this issue for me was grizzl (https://github.com/d11wtq/grizzl).

bug#15886: 24.3.50; Incorrect window-text-height with non-zero line-spacing

[Eli Zaretskii]

> From: Robert Dallas Gray <mail@robertdallasgray.com>
> Date: Wed, 13 Nov 2013 20:36:14 +0000
> Cc: 15886@debbugs.gnu.org
> 
> 
> On 13 Nov 2013, at 20:32, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> From: Robert Dallas Gray <mail@robertdallasgray.com>
> >> Date: Wed, 13 Nov 2013 19:23:19 +0000
> >> 
> >> On a graphical display, when `line-spacing' is non-zero,
> >> `window-text-height' reports an incorrect number; equally,
> >> `set-window-text-height' can't be used properly. This impacts on
> >> libraries which use `set-window-text-height' e.g. to attempt to size a
> >> window accurately.
> > 
> > Those libraries should use 'window-screen-lines' instead.
> > 
> > I think 'window-text-height' should continue doing what it does, as
> > many packages, and Emacs itself, depend on its current behavior.
> 
> OK, but is there a parallel setter method, or some way to set the height of a window in pixels, so that a window could be correctly sized taking into account line-spacing?

I don't understand: if you need to get a window's height and then use
it to change the height, then why isn't 'window-text-height' and
set-window-text-height' what you want?  They are consistent with one
another.

Perhaps it would help if you explain more about what you want to
accomplish, and why.

bug#15886: 24.3.50; Incorrect window-text-height with non-zero line-spacing

[Robert Dallas Gray]

On 13 Nov 2013, at 20:44, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Robert Dallas Gray <mail@robertdallasgray.com>
>> Date: Wed, 13 Nov 2013 20:36:14 +0000
>> Cc: 15886@debbugs.gnu.org
>> 
>> 
>> On 13 Nov 2013, at 20:32, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>>>> From: Robert Dallas Gray <mail@robertdallasgray.com>
>>>> Date: Wed, 13 Nov 2013 19:23:19 +0000
>>>> 
>>>> On a graphical display, when `line-spacing' is non-zero,
>>>> `window-text-height' reports an incorrect number; equally,
>>>> `set-window-text-height' can't be used properly. This impacts on
>>>> libraries which use `set-window-text-height' e.g. to attempt to size a
>>>> window accurately.
>>> 
>>> Those libraries should use 'window-screen-lines' instead.
>>> 
>>> I think 'window-text-height' should continue doing what it does, as
>>> many packages, and Emacs itself, depend on its current behavior.
>> 
>> OK, but is there a parallel setter method, or some way to set the height of a window in pixels, so that a window could be correctly sized taking into account line-spacing?
> 
> I don't understand: if you need to get a window's height and then use
> it to change the height, then why isn't 'window-text-height' and
> set-window-text-height' what you want?  They are consistent with one
> another.
> 
> Perhaps it would help if you explain more about what you want to
> accomplish, and why.

Well, it's not my library, but the reason it fails (in my setup, where I have line-spacing set to 2), is that it tries to set the height of the minibuffer using 'set-window-text-height' -- which, in my setup, sets the height incorrectly (the bottom of the minibuffer is obscured). I note that 'set-window-text-height' uses 'window-text-height' 

If there's a setter equivalent of 'window-screen-lines' (which there doesn't seem to be), then I can raise that with the maintainer. Otherwise, is there a way to set window height in pixels (which can be easily worked out from the number of lines of text)? If not, then there's no way (that I can see) to accomplish the intended function of 'set-window-text-height' in gui Emacs.

bug#15886: 24.3.50; Incorrect window-text-height with non-zero line-spacing

[Eli Zaretskii]

> From: Robert Dallas Gray <mail@robertdallasgray.com>
> Date: Wed, 13 Nov 2013 20:55:20 +0000
> Cc: 15886@debbugs.gnu.org
> 
> Well, it's not my library, but the reason it fails (in my setup, where I have line-spacing set to 2), is that it tries to set the height of the minibuffer using 'set-window-text-height' -- which, in my setup, sets the height incorrectly (the bottom of the minibuffer is obscured). I note that 'set-window-text-height' uses 'window-text-height' 

The argument passed to 'set-window-text-height' should be scaled by
the ratio of the values returned by 'frame-char-height' and
'default-line-height'.  (By default, this ratio is 1, but in your case
it will be different.)  The result of scaling should then be rounded
up to the nearest integer.

bug#15886: 24.3.50; Incorrect window-text-height with non-zero line-spacing

[Robert Dallas Gray]

On 13 Nov 2013, at 21:16, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Robert Dallas Gray <mail@robertdallasgray.com>
>> Date: Wed, 13 Nov 2013 20:55:20 +0000
>> Cc: 15886@debbugs.gnu.org
>> 
>> Well, it's not my library, but the reason it fails (in my setup, where I have line-spacing set to 2), is that it tries to set the height of the minibuffer using 'set-window-text-height' -- which, in my setup, sets the height incorrectly (the bottom of the minibuffer is obscured). I note that 'set-window-text-height' uses 'window-text-height' 
> 
> The argument passed to 'set-window-text-height' should be scaled by
> the ratio of the values returned by 'frame-char-height' and
> 'default-line-height'.  (By default, this ratio is 1, but in your case
> it will be different.)  The result of scaling should then be rounded
> up to the nearest integer.
> 

OK, but that doesn't really achieve the aim of setting the height of the window *exactly* in terms of the height of an individual line of text ... in the case I'm describing, where the number of lines displayed is changing dynamically, the baseline is going to bounce around because the window isn't being sized accurately.

bug#15886: 24.3.50; Incorrect window-text-height with non-zero line-spacing

[Eli Zaretskii]

> From: Robert Dallas Gray <mail@robertdallasgray.com>
> Date: Wed, 13 Nov 2013 21:27:35 +0000
> Cc: 15886@debbugs.gnu.org
> 
> > The argument passed to 'set-window-text-height' should be scaled by
> > the ratio of the values returned by 'frame-char-height' and
> > 'default-line-height'.  (By default, this ratio is 1, but in your case
> > it will be different.)  The result of scaling should then be rounded
> > up to the nearest integer.
> > 
> 
> OK, but that doesn't really achieve the aim of setting the height of the window *exactly* in terms of the height of an individual line of text ... in the case I'm describing, where the number of lines displayed is changing dynamically, the baseline is going to bounce around because the window isn't being sized accurately.

In a GUI session, a window's height can never be set exactly to the
size of the text, because that size is not constant, it varies
depending on what characters, fonts, and faces (bold etc.) are used
for displaying the text.  Change the text displayed in the window, and
the exact size in pixel changes.

So the goal is to make the window high enough to show all the text you
need to see; any other goal is not attainable _in_principle_, and it
is IMO futile to try to pursue it.

Or maybe I don't understand what "bouncing" you describe.  Can you
give an example?

bug#15886: 24.3.50; Incorrect window-text-height with non-zero line-spacing

[martin rudalics]

 > Well, it's not my library, but the reason it fails (in my setup, where
 > I have line-spacing set to 2), is that it tries to set the height of
 > the minibuffer using 'set-window-text-height'

Could you please tell us more precisely what you are doing?  IIUC you
must have set `resize-mini-windows' to nil in order to be able to apply
`set-window-text-height' to the minibuffer window in the first place.
But setting `resize-mini-windows' to t here resizes the mini window
exactly to the height of the text it displays.  So what am I missing?

 > -- which, in my setup,
 > sets the height incorrectly (the bottom of the minibuffer is
 > obscured).

What is your value of `max-mini-window-height'?

martin

bug#15886: 24.3.50; Incorrect window-text-height with non-zero line-spacing

[Eli Zaretskii]

[You forgot to CC the bug address.]

> Date: Thu, 14 Nov 2013 09:22:14 +0000
> From: Robert Dallas Gray <mail@robertdallasgray.com>
> 
> See the screenshot here:
> 
> https://github.com/d11wtq/grizzl
> 
> >From the bottom, you can see: a text entry area; an information line; and
> then a list of candidate files (this is Grizzl used for completing read
> over project files).
> 
> All three of these elements, if I'm reading the code correctly, are
> contained in the mini buffer window, which resizes dynamically as the list
> of candidate files grows or shrinks.
> 
> For this to look right, it must be possible to set the size of the window
> to a given number of lines as the number of candidates changes. The
> library's maintainer uses 'set-window-text-height' to do this (see
> https://github.com/d11wtq/grizzl/blob/master/grizzl-read.el#L141).

A side question: why does grizzl resize the minibuffer by hand,
instead of letting the display engine do that?

> In the case where line-spacing is non-zero, 'set-window-text-height'
> doesn't size the window correctly, as we've discussed. If we use a 'rough'
> number of lines based on the ratio described by Eli, then much of the time
> the window will also not be sized correctly, and as the list of candidates
> changes size, the baseline of the window (the text entry line) will
> 'bounce'.

This problem cannot be avoided entirely, and if it exists (did you
actually try my suggestion?), then the package has it already.  Those
2 lines, the "information line" and the line showing the best
candidate, they both use special faces, don't they?  If so, the same
problem will happen if one or both of these faces will use a different
font.

IOW, you cannot resize a window "exactly" like you would like to, in a
GUI session, simply because the Emacs display features are too many to
take everything into account, certainly if one works only on the Lisp
level.

You could say that users should not shoot themselves in the foot by
customizing these faces so as to disrupt the display of grizzl, but
then I could tell you the same about using line spacing.

> I can see that it's not possible to give an accurate window-text-height in
> the case of a display where fonts of multiple sizes might be used in the
> same buffer, but should it not at least take into account the global
> setting of line-spacing, and the height of the default font?

I don't see how line-spacing is different from any other feature that
affects the height of a line (except that you use the former, but not
the latter ;-).

> And, if it's impractical to fix this, is there a way to set the
> height of the window in pixels rather than lines so that the same
> effect can be achieved?

What makes you think that setting window height in pixels would solve
this issue?  Granted, the "jitter" would probably be smaller, but a
human eye can easily spot even a 1-pixel jitter, and be no less
annoyed.

What I'm trying to tell is that it is simply impossible to control the
Emacs display in Lisp to such a degree of precision, not with the way
the display engine is currently designed and implemented.  Whoever
designs packages which try to do that should be acutely aware of these
limitations in the first place, and if they don't avert her, at least
mention them in some prominent place.

Btw, I don't really see why there was a need for using the minibuffer
here.  Why not code a customized *Completions* buffer instead?  That
would at least make sure the "text entry area" could simply use the
minibuffer, which would then remain of a constant height, ever.

bug#15886: 24.3.50; Incorrect window-text-height with non-zero line-spacing

[Robert Dallas Gray]

On 14 Nov 2013, at 18:07, Eli Zaretskii <eliz@gnu.org> wrote:

> [You forgot to CC the bug address.]
> 

Apologies.

> A side question: why does grizzl resize the minibuffer by hand,
> instead of letting the display engine do that?
> 

No idea I'm afraid. I've linked to this bug in the issue I've raised on the Github repo, so perhaps the maintainer will drop in and enlighten us.

> This problem cannot be avoided entirely, and if it exists (did you
> actually try my suggestion?), then the package has it already.  Those
> 2 lines, the "information line" and the line showing the best
> candidate, they both use special faces, don't they?  If so, the same
> problem will happen if one or both of these faces will use a different
> font.
> 

I did try the suggestion (or something like it), yes, and it resulted in the 'bouncing' I mentioned.

I agree with your last couple of sentences, which is why my current workaround is to set line-spacing to nil in the minibuffer. But if it were possible to size the window in pixels, even the edge case you describe could be avoided.

> IOW, you cannot resize a window "exactly" like you would like to, in a
> GUI session, simply because the Emacs display features are too many to
> take everything into account, certainly if one works only on the Lisp
> level.
> 

For sure.

> You could say that users should not shoot themselves in the foot by
> customizing these faces so as to disrupt the display of grizzl, but
> then I could tell you the same about using line spacing.
> 
> I don't see how line-spacing is different from any other feature that
> affects the height of a line (except that you use the former, but not
> the latter ;-).
> 

Well, I'd contend (as a former book designer) that line-spacing is *by its nature* an integral part of the height of a line of text (the clue's in the name). 

> 
> What makes you think that setting window height in pixels would solve
> this issue?  Granted, the "jitter" would probably be smaller, but a
> human eye can easily spot even a 1-pixel jitter, and be no less
> annoyed.
> 

We can determine the height of a line of text in the relevant face, and its line-spacing, in pixels, and create a simple algorithm to calculate the total height of a given number of lines.

> What I'm trying to tell is that it is simply impossible to control the
> Emacs display in Lisp to such a degree of precision, not with the way
> the display engine is currently designed and implemented.  Whoever
> designs packages which try to do that should be acutely aware of these
> limitations in the first place, and if they don't avert her, at least
> mention them in some prominent place.
> 

Again, for sure. If it's a hard limitation of Emacs, so be it.

> Btw, I don't really see why there was a need for using the minibuffer
> here.  Why not code a customized *Completions* buffer instead?  That
> would at least make sure the "text entry area" could simply use the
> minibuffer, which would then remain of a constant height, ever.

Again, I dunno. I'm not the author, and I'm crediting him with having done things the way he has for good reasons. Hopefully he'll show up at some point and explain.

In the meantime, I'd suggest we shelve this one. Thanks a lot for taking the time to engage.

bug#15886: 24.3.50; Incorrect window-text-height with non-zero line-spacing

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> And, if it's impractical to fix this, is there a way to set the
>> height of the window in pixels rather than lines so that the same
>> effect can be achieved?
>
> What makes you think that setting window height in pixels would solve
> this issue?  Granted, the "jitter" would probably be smaller, but a
> human eye can easily spot even a 1-pixel jitter, and be no less
> annoyed.
>
> What I'm trying to tell is that it is simply impossible to control the
> Emacs display in Lisp to such a degree of precision, not with the way
> the display engine is currently designed and implemented.  Whoever
> designs packages which try to do that should be acutely aware of these
> limitations in the first place, and if they don't avert her, at least
> mention them in some prominent place.

From skimming this thread, it contains a long discussion that ultimately
ends up in the conclusion that what is requested is fundamentally not
possible to achieve with our current display engine.

So lacking any other updates within 7 years, and seeing nothing
actionable, it seems unlikely that we'll make any progress here.
I'm therefore closing this bug report.

If that conclusion is incorrect and there is more to do here, please
reply to this email (use "Reply to all" in your email client) and we can
reopen the bug report.