GNU bug report logs -
#16052
24.3.50; `set-frame-parameter` broken for `tool-bar-lines`
Previous Next
Reported by: Drew Adams <drew.adams <at> oracle.com>
Date: Wed, 4 Dec 2013 15:03:01 UTC
Severity: normal
Found in version 24.3.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16052 in the body.
You can then email your comments to 16052 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16052
; Package
emacs
.
(Wed, 04 Dec 2013 15:03:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Drew Adams <drew.adams <at> oracle.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 04 Dec 2013 15:03:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
emacs -Q
M-x set-variable RET pop-up-frames RET t
M-x tool-bar-mode ; turn it off, to start from zero
M-x pp-eval-expression RET (frame-parameters)
In frame *Pp Eval Output* search for `tool-bar-lines' => 0 (good).
In original frame (do all of the commands here, except isearch):
M-x tool-bar-mode ; turn it on
M-x pp-eval-expression RET (frame-parameters)
In frame *Pp Eval Output* search for `tool-bar-lines' => 2 (wrong).
In original frame (do all of the commands here, except isearch):
M-x pp-eval-expression RET (set-frame-parameter nil 'tool-bar-lines 1)
M-x pp-eval-expression RET (frame-parameters)
In frame *Pp Eval Output* search for `tool-bar-lines' => 2 (wrong).
In original frame (do all of the commands here, except isearch):
M-x pp-eval-expression RET (set-frame-parameter nil 'tool-bar-lines 3)
M-x pp-eval-expression RET (frame-parameters)
In frame *Pp Eval Output* search for `tool-bar-lines' => 2 (wrong).
etc. It seems that the `tool-bar-lines' is always either 0 or 2.
In GNU Emacs 24.3.50.2 (i686-pc-mingw32)
of 2013-11-28 on LEG570
Bzr revision: 115271 rgm <at> gnu.org-20131128203155-qjc1xsp19z2k64b2
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16052
; Package
emacs
.
(Sat, 04 Jan 2014 13:45:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 16052 <at> debbugs.gnu.org (full text, mbox):
> emacs -Q
>
> M-x set-variable RET pop-up-frames RET t
> M-x tool-bar-mode ; turn it off, to start from zero
> M-x pp-eval-expression RET (frame-parameters)
>
> In frame *Pp Eval Output* search for `tool-bar-lines' => 0 (good).
>
> In original frame (do all of the commands here, except isearch):
>
> M-x tool-bar-mode ; turn it on
> M-x pp-eval-expression RET (frame-parameters)
>
> In frame *Pp Eval Output* search for `tool-bar-lines' => 2 (wrong).
>
> In original frame (do all of the commands here, except isearch):
>
> M-x pp-eval-expression RET (set-frame-parameter nil 'tool-bar-lines 1)
> M-x pp-eval-expression RET (frame-parameters)
>
> In frame *Pp Eval Output* search for `tool-bar-lines' => 2 (wrong).
>
> In original frame (do all of the commands here, except isearch):
>
> M-x pp-eval-expression RET (set-frame-parameter nil 'tool-bar-lines 3)
> M-x pp-eval-expression RET (frame-parameters)
>
> In frame *Pp Eval Output* search for `tool-bar-lines' => 2 (wrong).
>
> etc. It seems that the `tool-bar-lines' is always either 0 or 2.
Before using terms like "wrong" in bug reports please consult the Elisp
manual:
On each frame, the frame parameter `tool-bar-lines' controls how
many lines' worth of height to reserve for the tool bar.
What you see is either 0 when `tool-bar-mode' is turned off or 2 which
probably comes from the actual toolbar pixel height divided by the
frame's default line height. Explicitly setting the `tool-bar-lines'
parameter has no effect when `auto-resize-tool-bars' is non-nil (which
it is with emacs -Q).
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16052
; Package
emacs
.
(Sat, 04 Jan 2014 16:09:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 16052 <at> debbugs.gnu.org (full text, mbox):
> > M-x tool-bar-mode ; turn it on
> > M-x pp-eval-expression RET (frame-parameters)
> >
> > In frame *Pp Eval Output* search for `tool-bar-lines' => 2
> > (wrong).
> > M-x pp-eval-expression RET
> > (set-frame-parameter nil 'tool-bar-lines 1)
> > M-x pp-eval-expression RET (frame-parameters)
> >
> > In frame *Pp Eval Output* search for `tool-bar-lines' => 2
> > (wrong).
> Before using terms like "wrong" in bug reports please consult the
> Elisp manual:
>
> On each frame, the frame parameter `tool-bar-lines' controls
> how many lines' worth of height to reserve for the tool bar.
That does not contradict my expectation. Is there some nuanced
interpretation of "reserved" that I need to guess here, such that
perhaps "reserving" that much height does not actually give the
tool bar area that much height?
And actually, node (elisp) `Layout Parameters' says that it is "the
number of lines to USE for the tool bar." Not just reserved but
used.
Furthermore, it says explicitly that "The default is 1 if Tool Bar
mode is enabled, and 0 otherwise." That pretty much describes the
intended default behavior, and it coincides with my uninformed
expectation.
> What you see is either 0 when `tool-bar-mode' is turned off or 2
> which probably comes from the actual toolbar pixel height divided
> by the frame's default line height.
What it really comes from should be *specified* in the manual.
IOW, what is the default number? Otherwise, it is pretty reasonable
to assume (as I did) that the default is one. Whether reasonable or
not, users should not need to guess the default behavior for the
on state.
And see above. The manual in fact DOES say what the default is,
and it is not 2. Is the manual wrong here or is the implementation
bugged in this regard?
> Explicitly setting the `tool-bar-lines' parameter has no effect
> when `auto-resize-tool-bars' is non-nil (which it is with emacs -Q).
Thanks for that explanation of what the implementation does.
However, that too is unlikely to be guessed by users. And the doc
does not say that at all, AFAICT. It says only that the tool bar
gets resized automatically.
All of the info regarding `tool-bar-lines' should be either
documented in the same place or clearly interconnected using cross
references.
Layout parameter `tool-bar-lines' is documented primarily in node
`Layout Parameters' - that it the reference doc for it. At the
very least there needs to be a cross reference from there to node
`Tool Bar' (and vice versa).
And preferably it would be explicitly mentioned at `Layout
Parameters' what the effect is of `auto-resize-tool-bars' on
`tool-bar-lines' (the latter is ignored if the former is non-nil,
i.e., it is IGNORED by DEFAULT).
So if the behavior is as it is intended to be, then the doc is
inadequate. It does not describe the behavior. And what it does
suggest (i.e., by default, setting `tool-bar-lines' would do just
what the `tool-bar-lines' doc says: change the number of tool bar
lines) is something quite different from the actual behavior.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16052
; Package
emacs
.
(Sat, 04 Jan 2014 16:40:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 16052 <at> debbugs.gnu.org (full text, mbox):
>> Before using terms like "wrong" in bug reports please consult the
>> Elisp manual:
>>
>> On each frame, the frame parameter `tool-bar-lines' controls
>> how many lines' worth of height to reserve for the tool bar.
>
> That does not contradict my expectation. Is there some nuanced
> interpretation of "reserved" that I need to guess here, such that
> perhaps "reserving" that much height does not actually give the
> tool bar area that much height?
No. It's the term "lines' worth of height" you should have interpreted
correctly.
>> What you see is either 0 when `tool-bar-mode' is turned off or 2
>> which probably comes from the actual toolbar pixel height divided
>> by the frame's default line height.
>
> What it really comes from should be *specified* in the manual.
Patches welcome. Likely from someone who (1) uses toolbars and (2) on
most relevant platforms.
> IOW, what is the default number?
One as stated.
> Otherwise, it is pretty reasonable
> to assume (as I did) that the default is one. Whether reasonable or
> not, users should not need to guess the default behavior for the
> on state.
>
> And see above. The manual in fact DOES say what the default is,
> and it is not 2.
2 is not the default. It's calculated from the font height you or your
system uses.
> Is the manual wrong here or is the implementation
> bugged in this regard?
Your bug report is bugged.
> So if the behavior is as it is intended to be, then the doc is
> inadequate. It does not describe the behavior. And what it does
> suggest (i.e., by default, setting `tool-bar-lines' would do just
> what the `tool-bar-lines' doc says: change the number of tool bar
> lines) is something quite different from the actual behavior.
If you want to submit a patch, please do. I only asked you to not use
the term "wrong" without consulting the manual first. I read your
report and the manual and found the manual right and your report wrong.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16052
; Package
emacs
.
(Fri, 20 Aug 2021 15:18:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 16052 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> If you want to submit a patch, please do. I only asked you to not use
> the term "wrong" without consulting the manual first. I read your
> report and the manual and found the manual right and your report wrong.
It seems like this is working as designed, so I'm closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
16052 <at> debbugs.gnu.org and Drew Adams <drew.adams <at> oracle.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Fri, 20 Aug 2021 15:18:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 18 Sep 2021 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 274 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.