bug#16470: 24.3.50; term mode and newlines with some window configurations

bug#16470: 24.3.50; term mode and newlines with some window configurations

[Constantine Vetoshev]

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)

bug#16470: 24.3.50; term mode and newlines with some window configurations

[Constantine Vetoshev]

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.

bug#16470: 24.3.50; term mode and newlines with some window configurations

[martin rudalics]

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

bug#16470: 24.3.50; term mode and newlines with some window configurations

[Constantine Vetoshev]

[-- 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 --]

bug#16470: 24.3.50; term mode and newlines with some window configurations

[martin rudalics]

 > 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

bug#16470: 24.3.50; term mode and newlines with some window configurations

[Constantine Vetoshev]

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

bug#16470: 24.3.50; term mode and newlines with some window configurations

[martin rudalics]

 >> 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)))

bug#16470: 24.3.50; term mode and newlines with some window configurations

[Constantine Vetoshev]

[-- 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

bug#16470: 24.3.50; term mode and newlines with some window configurations

[martin rudalics]

 > 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

bug#16470: 24.3.50; term mode and newlines with some window configurations

[Constantine Vetoshev]

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.

bug#16470: 24.3.50; term mode and newlines with some window configurations

[martin rudalics]

 > 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

bug#16470: 24.3.50; term mode and newlines with some window configurations

[Constantine Vetoshev]

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.

bug#16470: 24.3.50; term mode and newlines with some window configurations

[martin rudalics]

 > 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

bug#16470: 24.3.50; term mode and newlines with some window configurations

[martin rudalics]

 >  > 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

bug#16470: 24.3.50; term mode and newlines with some window configurations

[Constantine Vetoshev]

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.

bug#16470: 24.3.50; term mode and newlines with some window configurations

[martin rudalics]

 > 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

bug#16470: 24.3.50; term mode and newlines with some window configurations

[Jan Djärv]

[-- 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 --]