GNU bug report logs -
#16470
24.3.50; term mode and newlines with some window configurations
Previous Next
Reported by: Constantine Vetoshev <vetoshev <at> gmail.com>
Date: Thu, 16 Jan 2014 23:16:02 UTC
Severity: normal
Found in version 24.3.50
Done: martin rudalics <rudalics <at> gmx.at>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Thu, 23 Jan 2014 09:53:05 +0100
with message-id <52E0D871.8080905 <at> gmx.at>
and subject line Re: bug#16470: 24.3.50; term mode and newlines with some window configurations
has caused the debbugs.gnu.org bug report #16470,
regarding 24.3.50; term mode and newlines with some window configurations
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
16470: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16470
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Working with a build from today's Git mirror, revision 41c2162. Running Emacs with -Q.
Something is wrong with term.el's handling of newlines in some window configurations.
The following steps reproduce the bug consistently on my machine:
0. Make sure you have no .zshrc file in your home directory.
1. Start Emacs (with -Q).
2. Stretch the frame so it has enough room for three reasonably large vertical splits.
3. Make 3 equally-sized vertical windows (C-x 3, C-x 3, C-x 3, C-x =).
4. Put your cursor in the right-most window.
5. Run M-x term, then select /bin/zsh as your shell. You should immediately see the inverted '%' which indicates newline oddness with zsh. If you run any command, e.g., ls, you will see '%' at the end of all output.
6. Try running 'unsetopt prompt_sp' in the zsh instance. You'll see the '%' go away, but this is undesirable, because it means that, e.g., 'echo -n hi' does not work properly.
Here is where things get even more strange.
7. exit from the zsh shell and kill the *terminal* buffer.
8. C-x 1 so you have just one empty *scratch* window.
9. M-x term, select /bin/zsh again.
10. No bad '%' behavior occurs now.
To summarize: when you make three vertical windows, term.el's handling of newlines breaks. The behavior seems tied to window splits. I have tried this with term-suppress-hard-newline set to t and nil, and it does not seem to make a difference.
In GNU Emacs 24.3.50.1 (x86_64-apple-darwin13.0.0, NS apple-appkit-1265.00)
of 2014-01-16 on athena.local
Repository revision:
Windowing system distributor `Apple', version 10.3.1265
Configured using:
`configure --with-ns'
Important settings:
value of $LC_COLLATE: C
value of $LC_CTYPE: en_US.UTF-8
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-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
transient-mark-mode: t
Recent input:
<help-echo> C-x <help-echo> 3 <help-echo> <down-mouse-1>
<mouse-1> M-x t e r m <return> <return> l s <return>
e x t i <backspace> <backspace> i t <return> <help-echo>
C-x k <return> C-x 3 C-x + <help-echo> <down-mouse-1>
<mouse-1> s-x M-x t e r m <return> <return> l s <return>
e x i t <return> C-d C-x k <return> <help-echo> C-x
C-g M-x t e r m <return> <return> e x i t <return>
<help-echo> <help-echo> C-x 0 s-x M-x r e p o r t -
<tab> <return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
call-interactively: End of buffer
C-x C-g is undefined
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message 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 term disp-table easymenu ehelp ring
time-date tooltip electric uniquify 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)
[Message part 3 (message/rfc822, inline)]
> I made a build with your latest changes, and it seems to work. window-width and window-text-width now return the same values in all window configurations I tried, and term.el works as expected.
OK. Closing this bug.
> That said, I now don't see any difference between window-body-width, window-text-width, and window-width when the PIXELWISE argument is omitted or nil.
Correct. IIRC this was the case with Emacs 23 as well.
The rationale is the following: Intuitively, the total width of a window
(including scrollbars, fringes, ....) should be larger than its body
width. Now consider two side by side windows whose pixel widths equal
72 and 66 so their parent window has 138 pixels. With a character width
of 8, the parent has 17 total columns and the larger child 9 columns.
I have to give the other window 8 columns since otherwise the sum of the
width of these windows would not match the width of their parent with
unpredictable consequences for functions like `window-edges' whose
return values are often used to check whether two windows are adjacent
to each other.
Now if the smaller of these windows has no scrollbars, fringes, margins,
dividers ... using the previous calculation would give it a body width
of 9 columns (rounding up the result of 66 / 8) exceeding its nominal
total width.
Thanks, martin
This bug report was last modified 11 years and 117 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.