* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
@ 2014-07-25 23:08 Mark Oteiza
2014-07-26 6:42 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: Mark Oteiza @ 2014-07-25 23:08 UTC (permalink / raw
To: 18112
Reproducible on my system with tmux 1.9a:
1. emacs --daemon -Q
2. Start tmux in a term emulator and invoke `emacsclient -t` in
the tmux window
3. Do `C-x 3` in the client
4. Split horizontally the tmux window into two panes: <prefix> "
5. Open a new emacsclient in the new pane, exit the client (^X^C),
and close the new tmux pane (^D)
6. Interact with the first client.
Attaching with gdb the first time:
find_interval (tree=0xed9198, position=732) at intervals.c:681
681 in intervals.c
(gdb) s
683 in intervals.c
(gdb) s
701 in intervals.c
(gdb) s
681 in intervals.c
(gdb) s
683 in intervals.c
(gdb) s
701 in intervals.c
Otherwise, setting a breakpoint at find_interval and continuing,
`position` changes value but I always end up back at find_interval.
In GNU Emacs 24.4.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars)
of 2014-07-24 on holos
Configured using:
`configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
--localstatedir=/var --with-x-toolkit=lucid 'CFLAGS=-march=x86-64
-mtune=generic -O0 -pipe -fstack-protector-strong
--param=ssp-buffer-size=4 -g -fvar-tracking-assignments'
LDFLAGS=-Wl,-O0,--sort-common,--as-needed,-z,relro'
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
Important settings:
value of $LC_COLLATE: C
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
flycheck-mode: t
company-mode: t
winner-mode: t
show-paren-mode: t
tooltip-mode: t
electric-indent-mode: t
mouse-wheel-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
size-indication-mode: t
column-number-mode: t
line-number-mode: t
Recent input:
ESC [ > 0 ; 9 5 ; 0 c ESC x r e p o - e m - b TAB
RET
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Load-path shadows:
/usr/share/emacs/24.4.50/lisp/loaddefs hides /home/mvo/.emacs.d/site-lisp/loaddefs
Features:
(shadow sort gnus-util mail-extr emacsbug message idna dired format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils xterm flycheck find-func
help-mode easymenu rx f dash s company-files company-oddmuse
company-keywords company-etags etags company-gtags company-dabbrev-code
company-dabbrev company-capf company-cmake company-ropemacs
company-xcode company-clang company-semantic company-eclim
company-template company-css company-nxml company-bbdb company pcase
easy-mmode cl-macs gv package windmove edmacro kmacro cl-loaddefs cl-lib
saveplace winner ring time-date paren zenburn-theme tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd 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
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting x-toolkit x multi-tty emacs)
Memory information:
((conses 16 130940 8879)
(symbols 48 21621 0)
(miscs 40 46 141)
(strings 32 22838 6984)
(string-bytes 1 615107)
(vectors 16 17827)
(vector-slots 8 1133415 211358)
(floats 8 92 595)
(intervals 56 205 0)
(buffers 960 11)
(heap 1024 46183 1194))
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-07-25 23:08 bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval Mark Oteiza
@ 2014-07-26 6:42 ` Eli Zaretskii
2014-07-26 7:55 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2014-07-26 6:42 UTC (permalink / raw
To: Mark Oteiza; +Cc: 18112
> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Fri, 25 Jul 2014 19:08:43 -0400
>
> 1. emacs --daemon -Q
> 2. Start tmux in a term emulator and invoke `emacsclient -t` in
> the tmux window
> 3. Do `C-x 3` in the client
> 4. Split horizontally the tmux window into two panes: <prefix> "
> 5. Open a new emacsclient in the new pane, exit the client (^X^C),
> and close the new tmux pane (^D)
> 6. Interact with the first client.
>
> Attaching with gdb the first time:
>
> find_interval (tree=0xed9198, position=732) at intervals.c:681
> 681 in intervals.c
> (gdb) s
> 683 in intervals.c
> (gdb) s
> 701 in intervals.c
> (gdb) s
> 681 in intervals.c
> (gdb) s
> 683 in intervals.c
> (gdb) s
> 701 in intervals.c
>
> Otherwise, setting a breakpoint at find_interval and continuing,
> `position` changes value but I always end up back at find_interval.
Thanks.
Please use the procedure in etc/DEBUG to find out where it loops. The
procedure calls for using the "finish" command until some frame
doesn't return, then stepping with "next" through that frame to see
where and why it loops.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-07-26 6:42 ` Eli Zaretskii
@ 2014-07-26 7:55 ` Eli Zaretskii
2014-07-26 8:06 ` Andreas Schwab
` (4 more replies)
0 siblings, 5 replies; 24+ messages in thread
From: Eli Zaretskii @ 2014-07-26 7:55 UTC (permalink / raw
To: mvoteiza; +Cc: 18112
> Date: Sat, 26 Jul 2014 09:42:25 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 18112@debbugs.gnu.org
>
> Please use the procedure in etc/DEBUG to find out where it loops. The
> procedure calls for using the "finish" command until some frame
> doesn't return, then stepping with "next" through that frame to see
> where and why it loops.
The loop is in redisplay, and the reason seems to be that get_tty_size
returns incorrect size after the second tmux pane is closed with ^D.
We get one line more than tmux leaves us (after usurping 1 line for
its status line).
I don't know enough about TIOCGWINSZ ioctl to tell how to fix this,
sorry. Perhaps some termio expert could chime in.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-07-26 7:55 ` Eli Zaretskii
@ 2014-07-26 8:06 ` Andreas Schwab
2014-07-26 8:15 ` Andreas Schwab
` (3 subsequent siblings)
4 siblings, 0 replies; 24+ messages in thread
From: Andreas Schwab @ 2014-07-26 8:06 UTC (permalink / raw
To: Eli Zaretskii; +Cc: mvoteiza, 18112
Eli Zaretskii <eliz@gnu.org> writes:
> I don't know enough about TIOCGWINSZ ioctl to tell how to fix this,
> sorry. Perhaps some termio expert could chime in.
If TIOCGWINSZ disagrees with the actual size of the terminal then the
bug is in tmux in that it sets the wrong size.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-07-26 7:55 ` Eli Zaretskii
2014-07-26 8:06 ` Andreas Schwab
@ 2014-07-26 8:15 ` Andreas Schwab
2014-07-26 8:22 ` Eli Zaretskii
2014-07-26 9:04 ` Eli Zaretskii
` (2 subsequent siblings)
4 siblings, 1 reply; 24+ messages in thread
From: Andreas Schwab @ 2014-07-26 8:15 UTC (permalink / raw
To: Eli Zaretskii; +Cc: mvoteiza, 18112
Eli Zaretskii <eliz@gnu.org> writes:
> The loop is in redisplay, and the reason seems to be that get_tty_size
> returns incorrect size after the second tmux pane is closed with ^D.
> We get one line more than tmux leaves us (after usurping 1 line for
> its status line).
Does get_tty_size actually look at the correct terminal (the one
connected to the tty frame)?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-07-26 8:15 ` Andreas Schwab
@ 2014-07-26 8:22 ` Eli Zaretskii
0 siblings, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2014-07-26 8:22 UTC (permalink / raw
To: Andreas Schwab; +Cc: mvoteiza, 18112
> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: mvoteiza@udel.edu, 18112@debbugs.gnu.org
> Date: Sat, 26 Jul 2014 10:15:58 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > The loop is in redisplay, and the reason seems to be that get_tty_size
> > returns incorrect size after the second tmux pane is closed with ^D.
> > We get one line more than tmux leaves us (after usurping 1 line for
> > its status line).
>
> Does get_tty_size actually look at the correct terminal (the one
> connected to the tty frame)?
See handle_window_change_signal: we loop through all the tty's, and
call get_tty_size for each one of them.
If this doesn't answer the question, please tell how to check that the
terminal is the correct one, and I will take a look.
Thanks.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-07-26 7:55 ` Eli Zaretskii
2014-07-26 8:06 ` Andreas Schwab
2014-07-26 8:15 ` Andreas Schwab
@ 2014-07-26 9:04 ` Eli Zaretskii
2014-07-26 9:33 ` Eli Zaretskii
2014-07-26 9:17 ` Andreas Schwab
2014-07-26 9:44 ` Andreas Schwab
4 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2014-07-26 9:04 UTC (permalink / raw
To: mvoteiza; +Cc: 18112
> Date: Sat, 26 Jul 2014 10:55:11 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 18112@debbugs.gnu.org
>
> The loop is in redisplay, and the reason seems to be that get_tty_size
> returns incorrect size after the second tmux pane is closed with ^D.
> We get one line more than tmux leaves us (after usurping 1 line for
> its status line).
Actually, I think I was wrong (I forgot to count the line used for the
menu bar). So the reason is probably elsewhere...
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-07-26 7:55 ` Eli Zaretskii
` (2 preceding siblings ...)
2014-07-26 9:04 ` Eli Zaretskii
@ 2014-07-26 9:17 ` Andreas Schwab
2014-07-26 9:44 ` Andreas Schwab
4 siblings, 0 replies; 24+ messages in thread
From: Andreas Schwab @ 2014-07-26 9:17 UTC (permalink / raw
To: Eli Zaretskii; +Cc: mvoteiza, 18112
Eli Zaretskii <eliz@gnu.org> writes:
> The loop is in redisplay, and the reason seems to be that get_tty_size
> returns incorrect size after the second tmux pane is closed with ^D.
Does it? I don't see that here.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-07-26 9:04 ` Eli Zaretskii
@ 2014-07-26 9:33 ` Eli Zaretskii
2014-07-27 13:05 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2014-07-26 9:33 UTC (permalink / raw
To: mvoteiza; +Cc: 18112
> Date: Sat, 26 Jul 2014 12:04:47 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 18112@debbugs.gnu.org
>
> > Date: Sat, 26 Jul 2014 10:55:11 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 18112@debbugs.gnu.org
> >
> > The loop is in redisplay, and the reason seems to be that get_tty_size
> > returns incorrect size after the second tmux pane is closed with ^D.
> > We get one line more than tmux leaves us (after usurping 1 line for
> > its status line).
>
> Actually, I think I was wrong (I forgot to count the line used for the
> menu bar). So the reason is probably elsewhere...
Ok, my original analysis was based on a mistake. Moreover, tmux is
not really related to the problem at all, and neither is "C-x 3".
Here's a simpler way to reproduce the problem:
Open a terminal emulator (e.g., xterm) window, and in that window:
emacs -Q --daemon
emacsclient -t
Now open another terminal emulator window, and make it have a smaller
size. Then, in that window:
emacsclient -t
C-x C-c
Now go back to the first xterm window and resize it (e.g., with a
mouse). Emacs is now stuck in an infloop.
So the important players here are (1) a frame on another tty that has
a different size, and (2) resizing the frame after deleting another
frame on a different tty.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-07-26 7:55 ` Eli Zaretskii
` (3 preceding siblings ...)
2014-07-26 9:17 ` Andreas Schwab
@ 2014-07-26 9:44 ` Andreas Schwab
2014-07-26 11:07 ` Eli Zaretskii
4 siblings, 1 reply; 24+ messages in thread
From: Andreas Schwab @ 2014-07-26 9:44 UTC (permalink / raw
To: Eli Zaretskii; +Cc: mvoteiza, 18112
We never trigger redisplay after do_pending_window_change in
wait_reading_process_output. Why?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-07-26 9:44 ` Andreas Schwab
@ 2014-07-26 11:07 ` Eli Zaretskii
2014-07-26 11:27 ` Andreas Schwab
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2014-07-26 11:07 UTC (permalink / raw
To: Andreas Schwab; +Cc: mvoteiza, 18112
> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: mvoteiza@udel.edu, 18112@debbugs.gnu.org
> Date: Sat, 26 Jul 2014 11:44:13 +0200
>
> We never trigger redisplay after do_pending_window_change in
> wait_reading_process_output. Why?
Probably because redisplay calls do_pending_window_change at its very
beginning.
I also don't see how would triggering redisplay earlier fix the
problem at hand. Am I missing something?
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-07-26 11:07 ` Eli Zaretskii
@ 2014-07-26 11:27 ` Andreas Schwab
0 siblings, 0 replies; 24+ messages in thread
From: Andreas Schwab @ 2014-07-26 11:27 UTC (permalink / raw
To: Eli Zaretskii; +Cc: mvoteiza, 18112
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: mvoteiza@udel.edu, 18112@debbugs.gnu.org
>> Date: Sat, 26 Jul 2014 11:44:13 +0200
>>
>> We never trigger redisplay after do_pending_window_change in
>> wait_reading_process_output. Why?
>
> Probably because redisplay calls do_pending_window_change at its very
> beginning.
What does this have to do with the call in wait_reading_process_output?
Since it doesn't return until the next keypress we have a non-updated
display for a potentially long time.
> I also don't see how would triggering redisplay earlier fix the
> problem at hand. Am I missing something?
It may be part of the problem, who knows. You missed a lot in this
thread already, didn't you?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-07-26 9:33 ` Eli Zaretskii
@ 2014-07-27 13:05 ` Eli Zaretskii
2014-07-27 13:35 ` martin rudalics
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2014-07-27 13:05 UTC (permalink / raw
To: mvoteiza; +Cc: 18112-done
> Date: Sat, 26 Jul 2014 12:33:30 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 18112@debbugs.gnu.org
>
> So the important players here are (1) a frame on another tty that has
> a different size, and (2) resizing the frame after deleting another
> frame on a different tty.
Fixed in revision 117409 on the emacs-24 branch.
(It's amazing what one 99%-correct line of Lisp can do.)
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-07-27 13:05 ` Eli Zaretskii
@ 2014-07-27 13:35 ` martin rudalics
2014-07-27 14:55 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: martin rudalics @ 2014-07-27 13:35 UTC (permalink / raw
To: 18112, eliz, mvoteiza
> (It's amazing what one 99%-correct line of Lisp can do.)
Indeed. Thanks for fixing my 1% blindness.
martin
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-07-27 13:35 ` martin rudalics
@ 2014-07-27 14:55 ` Eli Zaretskii
2014-07-27 18:15 ` martin rudalics
2014-08-08 10:10 ` martin rudalics
0 siblings, 2 replies; 24+ messages in thread
From: Eli Zaretskii @ 2014-07-27 14:55 UTC (permalink / raw
To: martin rudalics; +Cc: mvoteiza, 18112
> Date: Sun, 27 Jul 2014 15:35:37 +0200
> From: martin rudalics <rudalics@gmx.at>
>
> > (It's amazing what one 99%-correct line of Lisp can do.)
>
> Indeed. Thanks for fixing my 1% blindness.
You're welcome.
As long as I have your attention: how about adding some comments
and/or text to respective doc strings to explain what exactly the
following functions do, and why/when are they needed?
window-normal-size
window-new-total
window-new-normal
window-new-pixel
and the corresponding set-* functions. Their doc strings are just
tautological repetition of their names, which isn't helpful. And the
ELisp manual doesn't say a word about them, so the doc strings need to
do a better job, IMO.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-07-27 14:55 ` Eli Zaretskii
@ 2014-07-27 18:15 ` martin rudalics
2014-08-08 10:10 ` martin rudalics
1 sibling, 0 replies; 24+ messages in thread
From: martin rudalics @ 2014-07-27 18:15 UTC (permalink / raw
To: Eli Zaretskii; +Cc: mvoteiza, 18112
> As long as I have your attention: how about adding some comments
> and/or text to respective doc strings to explain what exactly the
> following functions do, and why/when are they needed?
>
> window-normal-size
> window-new-total
> window-new-normal
> window-new-pixel
>
> and the corresponding set-* functions. Their doc strings are just
> tautological repetition of their names, which isn't helpful. And the
> ELisp manual doesn't say a word about them, so the doc strings need to
> do a better job, IMO.
I'll do that.
martin
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-07-27 14:55 ` Eli Zaretskii
2014-07-27 18:15 ` martin rudalics
@ 2014-08-08 10:10 ` martin rudalics
2014-08-08 10:40 ` Eli Zaretskii
1 sibling, 1 reply; 24+ messages in thread
From: martin rudalics @ 2014-08-08 10:10 UTC (permalink / raw
To: Eli Zaretskii; +Cc: mvoteiza, 18112
> As long as I have your attention: how about adding some comments
> and/or text to respective doc strings to explain what exactly the
> following functions do, and why/when are they needed?
>
> window-normal-size
> window-new-total
> window-new-normal
> window-new-pixel
>
> and the corresponding set-* functions. Their doc strings are just
> tautological repetition of their names, which isn't helpful. And the
> ELisp manual doesn't say a word about them, so the doc strings need to
> do a better job, IMO.
I've tried to do that now. Please have a look.
Thanks, martin
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-08-08 10:10 ` martin rudalics
@ 2014-08-08 10:40 ` Eli Zaretskii
2014-08-09 11:14 ` martin rudalics
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2014-08-08 10:40 UTC (permalink / raw
To: martin rudalics; +Cc: mvoteiza, 18112
> Date: Fri, 08 Aug 2014 12:10:02 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 18112@debbugs.gnu.org, mvoteiza@udel.edu
>
> > As long as I have your attention: how about adding some comments
> > and/or text to respective doc strings to explain what exactly the
> > following functions do, and why/when are they needed?
> >
> > window-normal-size
> > window-new-total
> > window-new-normal
> > window-new-pixel
> >
> > and the corresponding set-* functions. Their doc strings are just
> > tautological repetition of their names, which isn't helpful. And the
> > ELisp manual doesn't say a word about them, so the doc strings need to
> > do a better job, IMO.
>
> I've tried to do that now. Please have a look.
Thanks. This is an improvement for the functions that deal with the
"normal" size (which should have been called "normalized", but I guess
that's water under the bridge now).
I see no improvement for the "total" size. The additions to the doc
strings point to window-total-size, but that function's doc string
does not explain what is the semantics of "total" in this respect.
(The doc string of window-total-size references window-total-width and
window-total-height, which do say something about that, but having to
traverse more than 1 hyperlink to find the information is not a good
idea, IMO.)
Also, the way you document the *-new-* functions could be improved.
You say something like
The new pixel size of WINDOW is used by `window-resize-apply' and, if
that function succeeds, will be subsequently returned by the functions
`window-pixel-height' and `window-pixel-width'.
I suggest instead to say something that describes the effect, but not
how the effect is achieved (which is low-level information that
obscures and obfuscates what the reader would like to know):
The new pixel size of WINDOW, if it is valid, will be shortly
installed as WINDOW's size.
Thanks.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-08-08 10:40 ` Eli Zaretskii
@ 2014-08-09 11:14 ` martin rudalics
2014-08-09 15:37 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: martin rudalics @ 2014-08-09 11:14 UTC (permalink / raw
To: Eli Zaretskii; +Cc: mvoteiza, 18112
> I see no improvement for the "total" size. The additions to the doc
> strings point to window-total-size, but that function's doc string
> does not explain what is the semantics of "total" in this respect.
> (The doc string of window-total-size references window-total-width and
> window-total-height, which do say something about that, but having to
> traverse more than 1 hyperlink to find the information is not a good
> idea, IMO.)
>
> Also, the way you document the *-new-* functions could be improved.
> You say something like
>
> The new pixel size of WINDOW is used by `window-resize-apply' and, if
> that function succeeds, will be subsequently returned by the functions
> `window-pixel-height' and `window-pixel-width'.
>
> I suggest instead to say something that describes the effect, but not
> how the effect is achieved (which is low-level information that
> obscures and obfuscates what the reader would like to know):
>
> The new pixel size of WINDOW, if it is valid, will be shortly
> installed as WINDOW's size.
I've tried to follow your advices. Please have another look.
Thanks, martin
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-08-09 11:14 ` martin rudalics
@ 2014-08-09 15:37 ` Eli Zaretskii
2014-08-09 15:56 ` martin rudalics
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2014-08-09 15:37 UTC (permalink / raw
To: martin rudalics; +Cc: mvoteiza, 18112
> Date: Sat, 09 Aug 2014 13:14:15 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 18112@debbugs.gnu.org, mvoteiza@udel.edu
>
> > I see no improvement for the "total" size. The additions to the doc
> > strings point to window-total-size, but that function's doc string
> > does not explain what is the semantics of "total" in this respect.
> > (The doc string of window-total-size references window-total-width and
> > window-total-height, which do say something about that, but having to
> > traverse more than 1 hyperlink to find the information is not a good
> > idea, IMO.)
> >
> > Also, the way you document the *-new-* functions could be improved.
> > You say something like
> >
> > The new pixel size of WINDOW is used by `window-resize-apply' and, if
> > that function succeeds, will be subsequently returned by the functions
> > `window-pixel-height' and `window-pixel-width'.
> >
> > I suggest instead to say something that describes the effect, but not
> > how the effect is achieved (which is low-level information that
> > obscures and obfuscates what the reader would like to know):
> >
> > The new pixel size of WINDOW, if it is valid, will be shortly
> > installed as WINDOW's size.
>
> I've tried to follow your advices. Please have another look.
Thanks, the *-new-* functions are now clearly documented.
The issue with window-total-size is still there, though.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-08-09 15:37 ` Eli Zaretskii
@ 2014-08-09 15:56 ` martin rudalics
2014-08-09 16:29 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: martin rudalics @ 2014-08-09 15:56 UTC (permalink / raw
To: Eli Zaretskii; +Cc: mvoteiza, 18112
> The issue with window-total-size is still there, though.
Which one? Should I copy the descriptions from `window-total-height'
and `window-total-width' to the doc-string of `window-total-size'?
martin
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-08-09 15:56 ` martin rudalics
@ 2014-08-09 16:29 ` Eli Zaretskii
2014-08-10 10:42 ` martin rudalics
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2014-08-09 16:29 UTC (permalink / raw
To: martin rudalics; +Cc: mvoteiza, 18112
> Date: Sat, 09 Aug 2014 17:56:56 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 18112@debbugs.gnu.org, mvoteiza@udel.edu
>
> > The issue with window-total-size is still there, though.
>
> Which one? Should I copy the descriptions from `window-total-height'
> and `window-total-width' to the doc-string of `window-total-size'?
I think just saying what "total" includes, and how it differs from
the corresponding non-"total" dimensions, should be good enough.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-08-09 16:29 ` Eli Zaretskii
@ 2014-08-10 10:42 ` martin rudalics
2014-08-10 14:04 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: martin rudalics @ 2014-08-10 10:42 UTC (permalink / raw
To: Eli Zaretskii; +Cc: mvoteiza, 18112
> I think just saying what "total" includes, and how it differs from
> the corresponding non-"total" dimensions, should be good enough.
I tried to do that.
Thanks, martin
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval
2014-08-10 10:42 ` martin rudalics
@ 2014-08-10 14:04 ` Eli Zaretskii
0 siblings, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2014-08-10 14:04 UTC (permalink / raw
To: martin rudalics; +Cc: mvoteiza, 18112
> Date: Sun, 10 Aug 2014 12:42:08 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 18112@debbugs.gnu.org, mvoteiza@udel.edu
>
> > I think just saying what "total" includes, and how it differs from
> > the corresponding non-"total" dimensions, should be good enough.
>
> I tried to do that.
Thanks, I'm happy now.
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2014-08-10 14:04 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-07-25 23:08 bug#18112: 24.4.50; emacs --daemon infinite loop in find_interval Mark Oteiza
2014-07-26 6:42 ` Eli Zaretskii
2014-07-26 7:55 ` Eli Zaretskii
2014-07-26 8:06 ` Andreas Schwab
2014-07-26 8:15 ` Andreas Schwab
2014-07-26 8:22 ` Eli Zaretskii
2014-07-26 9:04 ` Eli Zaretskii
2014-07-26 9:33 ` Eli Zaretskii
2014-07-27 13:05 ` Eli Zaretskii
2014-07-27 13:35 ` martin rudalics
2014-07-27 14:55 ` Eli Zaretskii
2014-07-27 18:15 ` martin rudalics
2014-08-08 10:10 ` martin rudalics
2014-08-08 10:40 ` Eli Zaretskii
2014-08-09 11:14 ` martin rudalics
2014-08-09 15:37 ` Eli Zaretskii
2014-08-09 15:56 ` martin rudalics
2014-08-09 16:29 ` Eli Zaretskii
2014-08-10 10:42 ` martin rudalics
2014-08-10 14:04 ` Eli Zaretskii
2014-07-26 9:17 ` Andreas Schwab
2014-07-26 9:44 ` Andreas Schwab
2014-07-26 11:07 ` Eli Zaretskii
2014-07-26 11:27 ` Andreas Schwab
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.