* bug#16470: 24.3.50; term mode and newlines with some window configurations
@ 2014-01-16 23:15 Constantine Vetoshev
2014-01-17 4:29 ` Constantine Vetoshev
2014-01-17 7:51 ` martin rudalics
0 siblings, 2 replies; 17+ messages in thread
From: Constantine Vetoshev @ 2014-01-16 23:15 UTC (permalink / raw
To: 16470
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)
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#16470: 24.3.50; term mode and newlines with some window configurations
2014-01-16 23:15 bug#16470: 24.3.50; term mode and newlines with some window configurations Constantine Vetoshev
@ 2014-01-17 4:29 ` Constantine Vetoshev
2014-01-17 7:51 ` martin rudalics
1 sibling, 0 replies; 17+ messages in thread
From: Constantine Vetoshev @ 2014-01-17 4:29 UTC (permalink / raw
To: 16470
I have looked into this further, and I believe the underlying problem is an off-by-one value returned from term-window-width. The following advice is a workaround:
(defadvice term-window-width (after my-advice/term-window-width activate)
(setq ad-return-value (1- ad-return-value)))
I don't really understand some of the logic in term-window-width, though, and I'd still like to know if some more serious underlying reason caused this to start happening in the 24.4 codebase.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#16470: 24.3.50; term mode and newlines with some window configurations
2014-01-16 23:15 bug#16470: 24.3.50; term mode and newlines with some window configurations Constantine Vetoshev
2014-01-17 4:29 ` Constantine Vetoshev
@ 2014-01-17 7:51 ` martin rudalics
2014-01-17 16:52 ` Constantine Vetoshev
1 sibling, 1 reply; 17+ messages in thread
From: martin rudalics @ 2014-01-17 7:51 UTC (permalink / raw
To: Constantine Vetoshev; +Cc: 16470
Trying this on Windows
> 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 =).
(I suppose you mean C-x + instead of C-x = here)
> 4. Put your cursor in the right-most window.
and evaluating
(defun term-window-width ()
(if (and (not (featurep 'xemacs))
(display-graphic-p)
overflow-newline-into-fringe
(/= (frame-parameter nil 'right-fringe) 0))
(window-width)
(1- (window-width))))
(term-window-width)
in the right-most window I get a value of 24 in both Emacs 24.3 and
Emacs 24.4. What do you get?
martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#16470: 24.3.50; term mode and newlines with some window configurations
2014-01-17 7:51 ` martin rudalics
@ 2014-01-17 16:52 ` Constantine Vetoshev
2014-01-17 19:06 ` martin rudalics
2014-01-18 11:36 ` Jan Djärv
0 siblings, 2 replies; 17+ messages in thread
From: Constantine Vetoshev @ 2014-01-17 16:52 UTC (permalink / raw
To: martin rudalics; +Cc: 16470
[-- Attachment #1: Type: text/plain, Size: 783 bytes --]
On Jan 16, 2014, at 23:51, martin rudalics <rudalics@gmx.at> wrote:
> I get a value of 24 in both Emacs 24.3 and
> Emacs 24.4. What do you get?
On Mac OS 10.9.1, I have two different numbers for identically-sized frames, with windows in each equalized using M-x balance-windows. 70 in Emacs 24.3 and 71 in Emacs 24.4. It looks like a problem with the window-width function. Take a look at the attached screenshot: it shows the different return values, but it also shows that both windows wrap the new line at the 70th character.
So I guess term.el has nothing to do with this, it just happens to react particularly badly to the incorrect value returned from window-width. I wonder if this happened because of the change in using the Core text font renderer on OS X.
[-- Attachment #2.1: Type: text/html, Size: 1276 bytes --]
[-- Attachment #2.2: Screen Shot 2014-01-17 at 08.48.14.png --]
[-- Type: image/png, Size: 99833 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#16470: 24.3.50; term mode and newlines with some window configurations
2014-01-17 16:52 ` Constantine Vetoshev
@ 2014-01-17 19:06 ` martin rudalics
2014-01-17 19:26 ` Constantine Vetoshev
2014-01-18 11:36 ` Jan Djärv
1 sibling, 1 reply; 17+ messages in thread
From: martin rudalics @ 2014-01-17 19:06 UTC (permalink / raw
To: Constantine Vetoshev; +Cc: 16470
> On Mac OS 10.9.1, I have two different numbers for identically-sized frames,
> with windows in each equalized using M-x balance-windows. 70 in Emacs 24.3 and
> 71 in Emacs 24.4. It looks like a problem with the window-width function. Take a
> look at the attached screenshot: it shows the different return values, but it
> also shows that both windows wrap the new line at the 70th character.
>
> So I guess term.el has nothing to do with this, it just happens to react
> particularly badly to the incorrect value returned from window-width. I wonder
> if this happened because of the change in using the Core text font renderer on OS X.
I suppose it is a rounding issue. Does it happen only in the right-most
window?
Anyway, please tell me the following values after balancing:
(frame-width) (frame-text-width)
and for each of your three windows
(window-width) (window-total-width) (window-pixel-width)
Thanks, martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#16470: 24.3.50; term mode and newlines with some window configurations
2014-01-17 19:06 ` martin rudalics
@ 2014-01-17 19:26 ` Constantine Vetoshev
2014-01-18 12:07 ` martin rudalics
0 siblings, 1 reply; 17+ messages in thread
From: Constantine Vetoshev @ 2014-01-17 19:26 UTC (permalink / raw
To: martin rudalics; +Cc: 16470
On Jan 17, 2014, at 11:06, martin rudalics <rudalics@gmx.at> wrote:
> I suppose it is a rounding issue. Does it happen only in the right-most
> window?
In 24.3, I have the following window-width results: 71 - 70 - 70
In 24.4, I have 71 - 71 - 71
> Anyway, please tell me the following values after balancing:
>
> (frame-width) (frame-text-width)
>
> and for each of your three windows
>
> (window-width) (window-total-width) (window-pixel-width)
24.3:
(frame-width) returns 223
(frame-text-width) is not defined
- window 1 (left)
(window-width) returns 71
(window-total-width) returns 77
(window-pixel-width) is not defined
This seems to be accurate, the test line wraps at the 71st character.
- window 2 (middle)
(window-width) returns 70
(window-total-width) returns 76
- window 3 (right)
(window-width) returns 70
(window-total-width) returns 76
24.4:
(frame-width) returns 223
(frame-text-width) returns 1561
- window 1 (left)
(window-width) returns 71
(window-text-width) returns 71
(window-pixel-width) returns 533
The the test line here also wraps at the 71st character.
- window 2 (middle)
(window-width) returns 71
(window-text-width) returns 76
(window-pixel-width) returns 532
- window 3 (right)
(window-width) returns 71
(window-text-width) returns 76
(window-pixel-width) returns 532
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#16470: 24.3.50; term mode and newlines with some window configurations
2014-01-17 16:52 ` Constantine Vetoshev
2014-01-17 19:06 ` martin rudalics
@ 2014-01-18 11:36 ` Jan Djärv
1 sibling, 0 replies; 17+ messages in thread
From: Jan Djärv @ 2014-01-18 11:36 UTC (permalink / raw
To: Constantine Vetoshev; +Cc: 16470
[-- Attachment #1: Type: text/plain, Size: 956 bytes --]
17 jan 2014 kl. 17:52 skrev Constantine Vetoshev <vetoshev@gmail.com>:
> On Jan 16, 2014, at 23:51, martin rudalics <rudalics@gmx.at> wrote:
>
>> I get a value of 24 in both Emacs 24.3 and
>> Emacs 24.4. What do you get?
>
> On Mac OS 10.9.1, I have two different numbers for identically-sized frames, with windows in each equalized using M-x balance-windows. 70 in Emacs 24.3 and 71 in Emacs 24.4. It looks like a problem with the window-width function. Take a look at the attached screenshot: it shows the different return values, but it also shows that both windows wrap the new line at the 70th character.
>
> So I guess term.el has nothing to do with this, it just happens to react particularly badly to the incorrect value returned from window-width. I wonder if this happened because of the change in using the Core text font renderer on OS X.
Using the old font backend gives the same result, so it is not that.
Jan D.
[-- Attachment #2: Type: text/html, Size: 1642 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#16470: 24.3.50; term mode and newlines with some window configurations
2014-01-17 19:26 ` Constantine Vetoshev
@ 2014-01-18 12:07 ` martin rudalics
2014-01-18 16:03 ` Constantine Vetoshev
0 siblings, 1 reply; 17+ messages in thread
From: martin rudalics @ 2014-01-18 12:07 UTC (permalink / raw
To: Constantine Vetoshev; +Cc: 16470
>> I suppose it is a rounding issue. Does it happen only in the right-most
>> window?
>
> In 24.3, I have the following window-width results: 71 - 70 - 70
> In 24.4, I have 71 - 71 - 71
Sorry, I meant "does the unwanted wrapping happen only in the right-most
window". But IIUC you below answered that by saying that it's OK only
in the left-most window.
So I still suppose it's a rounding problem. IIRC with Emacs 24.3 the
right-most window could have a pixel width larger than an integer
multiple of its character width so it implicitly rounded _down_ the
character width of any window (Emacs 24.3 was silent about pixel widths
of windows). Emacs 24.4 can round _up_ the character width of any window
such that the sum of the character widths of all siblings invariantly
equals the character width of the parent window. This might fool the
`term-window-width' function in a way I have to find out yet.
Meanwhile please do the following: Evaluate the two functions attached
at the bottom (with Emacs 24.4 only) and do
(1) M-x frame-dump _before_ balancing windows and post the result (from
the buffer *frame-dump*) here.
(2) M-x frame-dump _after_ balancing windows and post the result (from
the buffer *frame-dump*) here.
Thanks, martin
(defun window-dump (window)
"Dump WINDOW."
(insert
(format "%s parent: %s\n" window (window-parent window))
(format "pixel left: %s top: %s size: %s x %s new: %s\n"
(window-pixel-left window) (window-pixel-top window)
(window-size window t t) (window-size window nil t)
(window-new-pixel window))
(format "char left: %s top: %s size: %s x %s new: %s\n"
(window-left-column window) (window-top-line window)
(window-total-size window t) (window-total-size window)
(window-new-total window))
(format "normal: %s x %s new: %s\n"
(window-normal-size window t) (window-normal-size window)
(window-new-normal window)))
(when (window-live-p window)
(insert
(format "body pixel: %s x %s char: %s x %s\n"
(window-body-width window t) (window-body-height window t)
(window-body-width window) (window-body-height window))))
(insert "\n"))
(defun frame-dump (&optional frame)
"Dump frame FRAME to buffer *frame-dump*.
FRAME defaults to the selected frame."
(interactive)
(setq frame (window-normalize-frame frame))
(with-current-buffer (get-buffer-create "*frame-dump*")
(erase-buffer)
(insert
(format "frame pixel: %s x %s cols/lines: %s x %s units: %s x %s\n"
(frame-pixel-width frame) (frame-pixel-height frame)
(frame-total-cols frame) (frame-text-lines frame) ; (frame-total-lines frame)
(frame-char-width frame) (frame-char-height frame))
(format "frame text pixel: %s x %s cols/lines: %s x %s\n"
(frame-text-width frame) (frame-text-height frame)
(frame-text-cols frame) (frame-text-lines frame))
(format "tool: %s scroll: %s fringe: %s border: %s right: %s bottom: %s\n\n"
(tool-bar-height frame t)
(frame-scroll-bar-width frame)
(frame-fringe-width frame)
(frame-border-width frame)
(frame-right-divider-width frame)
(frame-bottom-divider-width frame)))
(walk-window-tree 'window-dump frame t t)))
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#16470: 24.3.50; term mode and newlines with some window configurations
2014-01-18 12:07 ` martin rudalics
@ 2014-01-18 16:03 ` Constantine Vetoshev
2014-01-18 17:24 ` martin rudalics
0 siblings, 1 reply; 17+ messages in thread
From: Constantine Vetoshev @ 2014-01-18 16:03 UTC (permalink / raw
To: martin rudalics; +Cc: 16470
[-- Attachment #1: Type: text/plain, Size: 463 bytes --]
On Jan 18, 2014, at 04:07, martin rudalics <rudalics@gmx.at> wrote:
> Meanwhile please do the following: Evaluate the two functions attached
> at the bottom (with Emacs 24.4 only) and do
>
> (1) M-x frame-dump _before_ balancing windows and post the result (from
> the buffer *frame-dump*) here.
>
> (2) M-x frame-dump _after_ balancing windows and post the result (from
> the buffer *frame-dump*) here.
Results attached. Thanks for looking into this!
[-- Attachment #2: before-balancing.txt --]
[-- Type: text/plain, Size: 1209 bytes --]
frame pixel: 1601 x 424 cols/lines: 229 x 30 units: 7 x 14
frame text pixel: 1561 x 420 cols/lines: 223 x 30
tool: 0 scroll: 15 fringe: 21 border: 2 right: 0 bottom: 0
#<window 5> parent: nil
pixel left: 0 top: 0 size: 1597 x 406 new: 1597
char left: 0 top: 0 size: 228 x 29 new: 228
normal: 1.0 x 1.0 new: nil
#<window 3 on *scratch*> parent: #<window 5>
pixel left: 0 top: 0 size: 400 x 406 new: 400
char left: 0 top: 0 size: 57 x 29 new: 57
normal: 0.25 x 1.0 new: 0.25
body pixel: 364 x 392 char: 52 x 28
#<window 7 on *scratch*> parent: #<window 5>
pixel left: 400 top: 0 size: 399 x 406 new: 399
char left: 57 top: 0 size: 57 x 29 new: 57
normal: 0.25 x 1.0 new: 0.25
body pixel: 363 x 392 char: 52 x 28
#<window 6 on *scratch*> parent: #<window 5>
pixel left: 799 top: 0 size: 798 x 406 new: 798
char left: 114 top: 0 size: 114 x 29 new: 114
normal: 0.5 x 1.0 new: nil
body pixel: 762 x 392 char: 109 x 28
#<window 4 on *Minibuf-0*> parent: nil
pixel left: 0 top: 406 size: 1597 x 14 new: 0
char left: 0 top: 29 size: 228 x 1 new: 228
normal: 1.0 x 1.0 new: 0
body pixel: 1561 x 14 char: 223 x 1
[-- Attachment #3: after-balancing.txt --]
[-- Type: text/plain, Size: 1297 bytes --]
frame pixel: 1601 x 424 cols/lines: 229 x 30 units: 7 x 14
frame text pixel: 1561 x 420 cols/lines: 223 x 30
tool: 0 scroll: 15 fringe: 21 border: 2 right: 0 bottom: 0
#<window 5> parent: nil
pixel left: 0 top: 0 size: 1597 x 406 new: 1597
char left: 0 top: 0 size: 228 x 29 new: 228
normal: 1.0 x 1.0 new: nil
#<window 3 on *scratch*> parent: #<window 5>
pixel left: 0 top: 0 size: 533 x 406 new: 533
char left: 0 top: 0 size: 76 x 29 new: 76
normal: 0.3337507827175955 x 1.0 new: 0.3337507827175955
body pixel: 497 x 392 char: 71 x 28
#<window 7 on *scratch*> parent: #<window 5>
pixel left: 533 top: 0 size: 532 x 406 new: 532
char left: 76 top: 0 size: 76 x 29 new: 76
normal: 0.33312460864120225 x 1.0 new: 0.33312460864120225
body pixel: 496 x 392 char: 71 x 28
#<window 6 on *scratch*> parent: #<window 5>
pixel left: 1065 top: 0 size: 532 x 406 new: 532
char left: 152 top: 0 size: 76 x 29 new: 76
normal: 0.33312460864120225 x 1.0 new: 0.33312460864120225
body pixel: 496 x 392 char: 71 x 28
#<window 4 on *Minibuf-0*> parent: nil
pixel left: 0 top: 406 size: 1597 x 14 new: 0
char left: 0 top: 29 size: 228 x 1 new: 228
normal: 1.0 x 1.0 new: 0
body pixel: 1561 x 14 char: 223 x 1
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#16470: 24.3.50; term mode and newlines with some window configurations
2014-01-18 16:03 ` Constantine Vetoshev
@ 2014-01-18 17:24 ` martin rudalics
2014-01-18 18:43 ` Constantine Vetoshev
2014-01-19 9:31 ` martin rudalics
0 siblings, 2 replies; 17+ messages in thread
From: martin rudalics @ 2014-01-18 17:24 UTC (permalink / raw
To: Constantine Vetoshev; +Cc: 16470
> Results attached.
From these results we see the following: The root window is 1597 pixels
wide which results in 228 columns. (* 7 228) is 1596 pixels so the
rounding of the root window is OK with one pixel left. Now lets look
into the sums of the live windows before and after balancing:
Pixels are (+ 400 399 798) before and (+ 533 532 532) after balancing
both yielding 1697.
Columns are (+ 57 57 114) before and (+ 76 76 76) after balancing both
yielding 228.
Now (* 7 76) is 532 so the sizes of the two right windows are precise
while the left-most window has one pixel left. All these are total
sizes including scrollbars, fringes etc. But we can't draw text into
scrollbars so we have to look at the body widths instead.
For the body widths subtract 15 pixel for the scrollbar and 21 for the
fringes giving (- 533 36) that is 497 pixels for the first window
yielding 71 columns. Next we have (- 532 36) that is 496 pixels rounded
_up_ to 71 for the other two windows. So it seems that the problem is
with rounding up the body width: `window-width' says that the window has
71 columns while it has 70 columns plus 6 pixels, that is one pixel
less. Apparently this one missing pixel causes the problem: The
characters don't fit into the line and some wrapping occurs.
Now `term-window-width' does the following:
(defun term-window-width ()
(if (and (not (featurep 'xemacs))
(display-graphic-p)
overflow-newline-into-fringe
(/= (frame-parameter nil 'right-fringe) 0))
(window-width)
(1- (window-width))))
returning (window-width) IIUC. Now try to use
(defun term-window-width ()
(if (and (not (featurep 'xemacs))
(display-graphic-p)
overflow-newline-into-fringe
(/= (frame-parameter nil 'right-fringe) 0))
(/ (window-body-width nil t) (frame-char-width))
(1- (window-width))))
instead. If this works I shall make the change in window_body_width.
Thanks, martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#16470: 24.3.50; term mode and newlines with some window configurations
2014-01-18 17:24 ` martin rudalics
@ 2014-01-18 18:43 ` Constantine Vetoshev
2014-01-19 9:31 ` martin rudalics
1 sibling, 0 replies; 17+ messages in thread
From: Constantine Vetoshev @ 2014-01-18 18:43 UTC (permalink / raw
To: martin rudalics; +Cc: 16470
On Jan 18, 2014, at 09:24, martin rudalics <rudalics@gmx.at> wrote:
> Now try to use
>
> (defun term-window-width ()
> (if (and (not (featurep 'xemacs))
> (display-graphic-p)
> overflow-newline-into-fringe
> (/= (frame-parameter nil 'right-fringe) 0))
> (/ (window-body-width nil t) (frame-char-width))
> (1- (window-width))))
>
> instead. If this works I shall make the change in window_body_width.
Yes, this change seems to work in my tests.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#16470: 24.3.50; term mode and newlines with some window configurations
2014-01-18 17:24 ` martin rudalics
2014-01-18 18:43 ` Constantine Vetoshev
@ 2014-01-19 9:31 ` martin rudalics
2014-01-19 16:11 ` Constantine Vetoshev
1 sibling, 1 reply; 17+ messages in thread
From: martin rudalics @ 2014-01-19 9:31 UTC (permalink / raw
To: Constantine Vetoshev; +Cc: 16470
> If this works I shall make the change in window_body_width.
Looking into this again, I decided to change `term-window-width'.
The reason is that `window-body-height' already rounds up and
`window-text-height' rounds down. Doing things differently for
`window-body-width' and `window-text-width' doesn't sound like a good
idea.
Committed in revision 116069 on trunk. Please check.
Thanks, martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#16470: 24.3.50; term mode and newlines with some window configurations
2014-01-19 9:31 ` martin rudalics
@ 2014-01-19 16:11 ` Constantine Vetoshev
2014-01-19 17:30 ` martin rudalics
0 siblings, 1 reply; 17+ messages in thread
From: Constantine Vetoshev @ 2014-01-19 16:11 UTC (permalink / raw
To: martin rudalics; +Cc: 16470
On Jan 19, 2014, at 01:31, martin rudalics <rudalics@gmx.at> wrote:
> Looking into this again, I decided to change `term-window-width'.
>
> The reason is that `window-body-height' already rounds up and
> `window-text-height' rounds down. Doing things differently for
> `window-body-width' and `window-text-width' doesn't sound like a good
> idea.
>
> Committed in revision 116069 on trunk. Please check.
Your fix works and makes sense. The documentation of window-width says: "[If] a column at the right of the text area is only partially visible, that counts as a whole column; to exclude partially-visible columns, use `window-text-width'."
However, doesn't that imply that the alternate clause of the if in term-window-width should also use window-text-width? If I turn off fringes using (set-fringe-mode 0), the bug comes back. I know term-window-width already does an explicit decrement from (window-width) in that case, but that does not seem sufficient. Switching that call to (window-text-width) and keeping the decrement works, however.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#16470: 24.3.50; term mode and newlines with some window configurations
2014-01-19 16:11 ` Constantine Vetoshev
@ 2014-01-19 17:30 ` martin rudalics
2014-01-22 10:35 ` martin rudalics
0 siblings, 1 reply; 17+ messages in thread
From: martin rudalics @ 2014-01-19 17:30 UTC (permalink / raw
To: Constantine Vetoshev; +Cc: 16470
> Your fix works and makes sense. The documentation of window-width says: "[If] a column at the right of the text area is only partially visible, that counts as a whole column; to exclude partially-visible columns, use `window-text-width'."
That text was my invention though. I simply adapted the doc-string of
`window-body-height' which says
If PIXELWISE is nil and a line at the bottom of the text area is only
partially visible, that counts as a whole line; to exclude
partially-visible lines, use `window-text-height'.
to the width specification.
> However, doesn't that imply that the alternate clause of the if in term-window-width should also use window-text-width? If I turn off fringes using (set-fringe-mode 0), the bug comes back. I know term-window-width already does an explicit decrement from (window-width) in that case, but that does not seem sufficient. Switching that call to (window-text-width) and keeping the decrement works, however.
Installed in revision 116074. Keep me informed if there are still
problems.
Thanks, martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#16470: 24.3.50; term mode and newlines with some window configurations
2014-01-19 17:30 ` martin rudalics
@ 2014-01-22 10:35 ` martin rudalics
2014-01-22 16:00 ` Constantine Vetoshev
0 siblings, 1 reply; 17+ messages in thread
From: martin rudalics @ 2014-01-22 10:35 UTC (permalink / raw
To: Constantine Vetoshev; +Cc: 16470
> > Your fix works and makes sense. The documentation of window-width
> says: "[If] a column at the right of the text area is only partially
> visible, that counts as a whole column; to exclude partially-visible
> columns, use `window-text-width'."
>
> That text was my invention though. I simply adapted the doc-string of
> `window-body-height' which says
>
> If PIXELWISE is nil and a line at the bottom of the text area is only
> partially visible, that counts as a whole line; to exclude
> partially-visible lines, use `window-text-height'.
>
> to the width specification.
I now restored the old truncation behavior of `window-body-width' and
also that of `term-window-width'. Please tell me if there are any
problems.
martin
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#16470: 24.3.50; term mode and newlines with some window configurations
2014-01-22 10:35 ` martin rudalics
@ 2014-01-22 16:00 ` Constantine Vetoshev
2014-01-23 8:53 ` martin rudalics
0 siblings, 1 reply; 17+ messages in thread
From: Constantine Vetoshev @ 2014-01-22 16:00 UTC (permalink / raw
To: martin rudalics; +Cc: 16470
On Jan 22, 2014, at 02:35, martin rudalics <rudalics@gmx.at> wrote:
> I now restored the old truncation behavior of `window-body-width' and
> also that of `term-window-width'. Please tell me if there are any
> problems.
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.
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#16470: 24.3.50; term mode and newlines with some window configurations
2014-01-22 16:00 ` Constantine Vetoshev
@ 2014-01-23 8:53 ` martin rudalics
0 siblings, 0 replies; 17+ messages in thread
From: martin rudalics @ 2014-01-23 8:53 UTC (permalink / raw
To: Constantine Vetoshev; +Cc: 16470-done
> 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
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2014-01-23 8:53 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-16 23:15 bug#16470: 24.3.50; term mode and newlines with some window configurations Constantine Vetoshev
2014-01-17 4:29 ` Constantine Vetoshev
2014-01-17 7:51 ` martin rudalics
2014-01-17 16:52 ` Constantine Vetoshev
2014-01-17 19:06 ` martin rudalics
2014-01-17 19:26 ` Constantine Vetoshev
2014-01-18 12:07 ` martin rudalics
2014-01-18 16:03 ` Constantine Vetoshev
2014-01-18 17:24 ` martin rudalics
2014-01-18 18:43 ` Constantine Vetoshev
2014-01-19 9:31 ` martin rudalics
2014-01-19 16:11 ` Constantine Vetoshev
2014-01-19 17:30 ` martin rudalics
2014-01-22 10:35 ` martin rudalics
2014-01-22 16:00 ` Constantine Vetoshev
2014-01-23 8:53 ` martin rudalics
2014-01-18 11:36 ` Jan Djärv
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.