some suggestions

[eylles]

why use tabbed for adding tabs when you can use tmux for that, i just feel slapping tmux on top of tabbed to be rather unnecesary, but i'm part of the window manager crowd so i just use a tabbed layout when the fancier tmux features ain't needed (sessions, completion from tmux buffers and the copy mode

also, it would be a nice idea to add some useful keybinds: Ctrl <Key> 0: set-vt-font(d) \n\ to quickly return to the default font size Shift Ctrl <Key>T: spawn-new-terminal() \n\ to open a new terminal in the current directory

a perhaps useful option is: XTerm*alternateScroll: true which makes the alternate screen behave like a less buffer than be part of the scrollback buffer

in regards to sixel support patch #359 added on 2020/08/17 made sixel support the default so adding: XTerm*decTerminalID : vt340 ain't necesary for xterm(359) and later, on the sixel note adding: XTerm*numColorRegisters: 256 provides no benefit, in fact is quite a detriment as xterm supports true color (well, no but actually yes, xterm doesn't really render truecolor but rather aproximates it from a lower colorspace, 16-bit color i think, but i'm not 100% sure) so when you force 256 color registers it will stop displaying some colors on text.

here's an example, xterm and uxterm side by side, xterm has XTerm*numColorRegisters: 256, on uxterm the zsh command suggestion is properly displayed as a darker color than the text (color 08) meanwhile xterm displays it the same color as the text

also add in the readme the remapping ctr+v to paste breaks visual block in vim as that's the default mapping

there should be no need to set keybinds for maximize and restore inside xterm, as the maximize, minimize and restore actions should be handled by the window manager, every window manager can control those actions with with their own keybinds, setting per program keybinds for those actions breaks user experience consistency, okay not all desktop environments and window managers come pre configured with friendly keybinds for that but those are usually trivial to configure

and finally when you mention tmux-sixel it would be a really good idea to link https://github.com/csdvrx/sixel-tmux in the readme to clarify

please don't take my suggestions the bad way

[csdvrx]

why use tabbed for adding tabs when you can use tmux for that, i just feel slapping tmux on top of tabbed to be rather unnecesary

Because I work on tmux remote sessions. Having a tab for each remote host, then running tmux attach in each host avoids settings different tmux.conf or remembering complex shortcuts.

also, it would be a nice idea to add some useful keybinds: Ctrl <Key> 0: set-vt-font(d) \n\ to quickly return to the default font size

Great idea!

Shift Ctrl <Key>T: spawn-new-terminal() \n\ to open a new terminal in the current directory

C-S-T already opens a new tab with tabbed, a different shortcut could be added to start another xterm, but I would prefer that to be with tabbed (to keep the ability to add more tabs).

I need to think about that a bit more: my default answer would be to add C-S-N to tabbed, to start another identical tabbed using **argv ; however it would not help you since you do not use tabbed. Yet the ability to start another xterm without tabbed for whatever reason would be nice to have - for example when running something that uses the same shortcuts as tabbed, but not wanting to change the configuration or recompile tabbed just for this.

a perhaps useful option is: XTerm*alternateScroll: true which makes the alternate screen behave like a less buffer than be part of the scrollback buffer

Do both buffers scroll independently? How does it play with sixels? I'm curious ; like you I've been bothered by the lack of scrollback of the alternate buffer, even if I don't see a direct usecase (vim manages it own scrollback) I think it could be nice to have if it doesn't break anything.

provides no benefit, in fact is quite a detriment as xterm supports true color (well, no but actually yes, xterm doesn't really render truecolor but rather aproximates it from a lower colorspace, 16-bit color i think, but i'm not 100% sure) so when you force 256 color registers it will stop displaying some colors on text.

Great catch!

I was using a workaround in my zshrc because I didn't get that! THANKS A LOT!!!

also add in the readme the remapping ctr+v to paste breaks visual block in vim as that's the default mapping

Will do, too bad for vim but ctrl-v should paste everywhere in this century :)

setting per program keybinds for those actions breaks user experience consistency

I'm uncertain on that one. Does it cause problems? The way I see it, it should provide 2 different ways to cause the same action. It seems to work fine on Gnome. It seemed to have no drawbacks.

and finally when you mention tmux-sixel it would be a really good idea to link https://github.com/csdvrx/sixel-tmux in the readme to clarify

I will, it's just that the old version currently there is unworthy of a link :)

The new version is so much better, but I want everything to be as polished as possible before I release it!

please don't take my suggestions the bad way

Not at all, quite the opposite!

Providing good defaults is hard. I spent a lot of time doing that, but there were many quirks that still irritated me yet couldn't figure out, like the zsh color.

So thanks a lot for taking the time to explore the issue, detail it, and providing a fix!

[eylles]

i did some more tests with xterm and zsh, programs like w3m or plugins to show colors on vim won't work properly under the 256 color registers option, also did a comparison between the xterm-256color terminfo and the xterm-new terminfo, under xterm-new some colors ain't represented correctly which causes problems inside vim and also will cause zsh-autosuggestions to be "invisible"

uxterm on the left, xterm on the right, xterm is under the xterm-new terminfo and the text from zsh-autosuggestions seems to be set to #000000, the reason you can still tell zsh-autoosuggestions is spitting text is my background color is lighter than #000000 (i use pywal to generate colorschemes for xresources and other programs from the colors of the wallpaper image) so i'd say take a look at the values for fg color 0, 7, 8, and their variations on the terminfo files to track which definition causes this problem.

on a different note to get dynamic terminal titles for xterm here are the shell functions: zsh: case $TERM in rxvt|*term) precmd() { print -Pn "\e]0;%m:%~\a" } preexec () { print -Pn "\e]0;$1\a" } ;; esac

bash: case $TERM in rxvt|*term) set -o functrace trap 'echo -ne "\e]0;"; echo -n $BASH_COMMAND; echo -ne "\007"' DEBUG export PS1="\e]0;$TERM\007$PS1" ;; esac

[takase1121]

Just a sidenote, xterm-new terminfo breaks micro. micro takes a long time to start up (>10 seconds) and the colors are all broken. All light(?) colors (color8 - color15) all displays incorrectly.

[097115]

@eylles

Sorry for some necrobumping, just wanted to clarify a bit if you don't mind :)

You mentioned enabling the alternateScroll option but I can't spot the difference with it being either true or false. Let's say I test it like this:

• open XTerm

• run ls -la

• run Vim

• toggle the alternate screen with this mapping:

  !Shift Ctrl <Key>h:      set-altscreen(toggle) \n\ 
  

• can scroll the alternate screen with these mappings back and forth (no matter what the XTerm*alternateScroll option is set to):

  !Ctrl       <Key>Prior:  scroll-back(1,page) \n\
  !Ctrl       <Key>Next:   scroll-forw(1,page) \n\
  

Am I missing something? (I sure tried to xrdb -merge ~/.Xresources between my tests :)

[eylles]

welp, i'm not sure myself tho, since i do xrdb -load ~/.Xresources as merge will preserve some default values that existed before but will try testing again on this.