window manipulation issues

[scandum]

Mintty doesn't handle a few of the \e[ ... t options correctly. I'll use row,col aka y,x for all notations.

My display resolution: 1080, 1920

Easiest issue to test is moving the terminal.

echo -e "\e[3;0;0t"

Instead of moving the terminal to position 0,0 it moves the terminal to position 0,8

When requesting the position of a maximized screen using:

echo -e "\e[13t"

Mintty returns: \e[3;-8;-8t

This should of course return \e[3;0;0t. I assume mintty justifies the screen to the right, this should probably be changed to justifying to the left to address this problem.

There is also an issue with mintty reporting the screen dimensions while maximized:

echo -e "\e[14;2t"

Mintty returns: \e[4;1066;1936t acknowledge the width is larger than 1920.

Mintty reports a correct width of 1920 while in full screen (alt+enter) mode.

Awesome terminal by the way, keep up the great work. :)

[BrianInglis]

Seeing the same type of results - screen 1920x1200 - window 120x60+210+120:

$ xterm_info
window position 3 px 210+120    ^[[13t          ^[[3;210;120t$
window size     4 px 875x881    ^[[14;2t        ^[[4;881;875t$
text position   3 px 219+152    ^[[13;2t        ^[[3;219;152t$
text size       4 px 823x840    ^[[14t          ^[[4;840;823t$
text chars      8 ch 120x60     ^[[18t          ^[[8;60;120t$
char size       6 px 7x14       ^[[16t          ^[[6;14;7t$
screen chars    9 ch 274x85     ^[[19t          ^[[9;85;274t$
screen size     5 px 1920x1200  ^[[15t          ^[[5;1200;1920t$
window status   2 icon          ^[[11t          ^[[2t$

maximized:

$ xterm_info
window position 3 px -8+-8      ^[[13t          ^[[3;-8;-8t$
window size     4 px 1936x1216  ^[[14;2t        ^[[4;1216;1936t$
text position   3 px 1+24       ^[[13;2t        ^[[3;1;24t$
text size       4 px 1884x1175  ^[[14t          ^[[4;1175;1884t$
text chars      8 ch 271x83     ^[[18t          ^[[8;83;271t$
char size       6 px 7x14       ^[[16t          ^[[6;14;7t$
screen chars    9 ch 274x85     ^[[19t          ^[[9;85;274t$
screen size     5 px 1920x1200  ^[[15t          ^[[5;1200;1920t$
window status   2 icon          ^[[11t          ^[[2t$

looks like e.g. twips is being rounded up to 8 pixels but is incrementing the sizes by 8 - missing a decrement before a divide and multiply - something like n/pixel_twips/CHAR_BIT*CHAR_BIT instead of ((n - 1)/pixel_twips - 1)/CHAR_BIT*CHAR_BIT

[mintty]

echo -e "\e[3;0;0t"
Instead of moving the terminal to position 0,0 it moves the terminal to position 0,8

Works fine for me, except with option -B frame (default or -B void work).

When requesting the position of a maximized screen using:
echo -e "\e[13t"
Mintty returns: \e[3;-8;-8t

Fixed the negative case (modulo ushort).
Where the offset comes from, I do not know.
Note, however, that xterm also exhibits some weird deviations under Cygwin/X (not under Linux).

There is also an issue with mintty reporting the screen dimensions while maximized:
echo -e "\e[14;2t"
Mintty returns: \e[4;1066;1936t acknowledge the width is larger than 1920.

That accounts for the border which is outside the screen in this case.

[ghost]

Hello, going to tag along on this issue. While testing Jexer, mintty's response to "CSI 14 t" is "CSI 4; 336; 544 t". This is on a 80x24 window, resulting in text cell width of 6.8 pixels by 14 pixels. This is on mintty 3.0.2 which shipped with today's cygwin 32-bit installer.

When I use "CSI 16 t" mintty reports text cell dimensions of 7x14.

Furthermore, when I run mintty against Jexer, open an image, and drag the image window to a new position, the image jumps/stutters on the screen even when Jexer is emitting no new sixel output. If I exit the Jexer demo app, and launch it again, mintty crashes (even before loading any images) with a stackdump file generated. I'm testing mintty by ssh to a Linux VM, 'java -jar /path/to/jexer.jar'.

[mintty]

CSI 14 t report would include outer padding if I interpret xterm's ctlseqs.txt correctly.
Please try the impact of setting Padding.

About sixel display, I've just fixed a bug that would occur when you output a really large number of sixel images. Maybe that's in fact possible when dragging around an image with such a framework.
This should be a separate issue, and it will help if you describe a completely reproducible test case, cygwin-only preferred if possible.

[ghost]

CSI 14 t report would include outer padding if I interpret xterm's ctlseqs.txt correctly.
Please try the impact of setting Padding.

When run with 'mintty -o Padding=200':

• I can see a larger padded area around the window, so Padding appears to be working.
• The response to "CSI 14 t" is "CSI 4 ; 336 ; 544 t". (Same as before.)

if I interpret xterm's ctlseqs.txt correctly.

Looking into xterm's charproc.c source, I think you are correct:

    case ewGetWinSizePixels:	/* Report the window's size in pixels */
	if (AllowWindowOps(xw, ewGetWinSizePixels)) {
	    ParmType high = (ParmType) Height(screen);
	    ParmType wide = (ParmType) Width(screen);

	    TRACE(("...get window size in pixels\n"));
	    init_reply(ANSI_CSI);
	    reply.a_pintro = 0;
	    reply.a_nparam = 3;
	    reply.a_param[0] = 4;
	    switch (zero_if_default(1)) {
	    case 2:		/* report the shell-window's size */
		xtermGetWinAttrs(screen->display,
				 WMFrameWindow(xw),
				 &win_attrs);
		high = (ParmType) win_attrs.height;
		wide = (ParmType) win_attrs.width;
		/* FALLTHRU */
	    default:
		reply.a_param[1] = high;
		reply.a_param[2] = wide;
		break;
	    }
	    reply.a_inters = 0;
	    reply.a_final = 't';
	    unparseseq(xw, &reply);
	}
	break;

Other calls to Height(screen) in the source looks like it used as a measure of the entire rectangle except border insets/decorations.

So I think if someone adds padding that padding would be included in the total count. However, mintty is currently reporting a number smaller than the text area. For 14x7 character cells, mintty should be reporting at minimum 560x366 pixels vs 544x336. I'm not sure how Padding works, when I set Padding=200 I appear to get about ~10 pixels of padding on all four sides.

I will make another issue for the sixel crash.

[mintty]

If I scale down an 80x24 window to 14x7 cell size (as reported via CSI 16 t), CSI 14 t reports 336x560 for me which looks correct.
Font is DejaVu Sans Mono with an effective Leading of 0, if that matters (what's your's?), no scrollbar.
With scrollbar enabled, there is apparently some incorrect adjustment...

[BrianInglis]

See my previous comment above for my xterm_info output: CSI 14;2 t includes padding for window size; CSI 14 t is text size; font DejaVu Sans Mono 9.
Those give widths of ~117.571 ch @ nom 7 px for 120 ch at ~6.858 px nom 7 px.
It may reflect Windows use of resolution in twips and perhaps also mapping of "logical inches" onscreen?

[mintty]

Released 3.0.3.