--- Begin Message ---
|
Subject: |
24.3.50; term mode and newlines with some window configurations |
|
Date: |
Thu, 16 Jan 2014 15:15:43 -0800 |
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)
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#16470: 24.3.50; term mode and newlines with some window configurations |
|
Date: |
Thu, 23 Jan 2014 09:53:05 +0100 |
> 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
--- End Message ---