add xterm related changes

[iambumblehead]

This branch attempts to troubleshoot and address issues affecting xterm per discussion here vifm/vifm#419 (comment)

I don't have too much bandwidth today, but wanted to at least start this branch

From wayland Gnome, xterm must be started indirectly using two separate terminal processes, the resulting windows have no decorations and are not resizable or repositionable.

Xwayland :7

DISPLAY=:7 xterm -xrm "XTerm*decTerminalID: vt340" -xrm "XTerm*numColorRegisters: 256"

cc @Mange @xaizek

[iambumblehead]

it looks like it is working... to get this I used the below file directive, using multipliers "8 8"

fileviewer {*.bmp,*.jpg,*.jpeg,*.png,*.gif,*.xpm,*.svg,*.pdf,*.epub,
           \*.ttf,*.otf,*.woff,*.wav,*.mp3,*.flac,*.m4a,*.wma,*.ape,
           \*.ac3,*.og[agx],*.spx,*.opus,*.aac,*.mpga,*.avi,*.mp4,
           \*.wmv,*.dat,*.3gp,*.ogv,*.mkv,*.mpg,*.mpeg,*.vob,
           \*.fl[icv],*.m2v,*.mov,*.webm,*.ts,*.mts,*.m4v,*.r[am],
           \*.qt,*.divx,*.as[fx],*.unknown_video},
         \ render-thumb-for.sh %c %pw %ph 8 8 %pd

sixel image support is disabled relying on this Xresources file, even if the XWayland and the entire host machine have been restarted

XTerm*decTerminalID: vt340
XTerm*numColorRegisters: 256

instead, xterm must be started this way,

DISPLAY=:7 xterm -xrm "XTerm*decTerminalID: vt340" -xrm "XTerm*numColorRegisters: 256"

[iambumblehead]

Maybe we could add a message to the wiki which links to this issue. Without support from a real xterm user, it is perhaps not practical to continue.

[iambumblehead]

a line like this could be added to the README,

xterm is not supported, but can be configured to work with this script. Please see #25

[iambumblehead]

added this to restrict size for xterm

# https://man.freebsd.org/cgi/man.cgi?query=xterm
#
# maxGraphicSize (class MaxGraphicSize)
#  If xterm is configured to support ReGIS or SIXEL graphics, this
#  resource controls the maximum size  of a graph which	can be
#  displayed.
#
#  The default is "1000x1000" (given as width by height).
wh_term_scaled_get () {
    if [[ $TERM =~ xterm ]]; then
        wh_scaled_get "$1" "1000 1000"
    else
        echo "$1"
    fi
}

[iambumblehead]

@Mange yay I can start xterm from within gnome using simply xterm thanks for getting me started

[xaizek]

Without support from a real xterm user, it is perhaps not practical to continue.

It seems to work better on this branch, but yeah, it might not be worth the trouble. Moreover, a bunch of xterm-compatible terminals use its $TERM value and might be negatively affected by such changes.

[iambumblehead]

Moreover, a bunch of xterm-compatible terminals use its $TERM value and might be negatively affected by such changes.

@xaizek there is a way to query the terminal to detect maximum allowed sixel resolution. If that is used maybe we could remove the check for $TERM =~ xterm and directly use max sixel resolution instead.

[iambumblehead]

@xaizek querying maximum allowed resolution and window resolution will require a small delay of 200 or 300 milliseconds (each) and this made me think this script should use a "sessionid" and I want to know what you think of this idea. Something like this,

# -c to use "cellwidth", 20 and 30 will be recognized as columns and rows
# -i is "sessionid"
export sessid=uniquevifmsessid1710163588124
./render-thumb-for.sh -i $sessid -c ./path/to/thumb.png 20 30

The script would store details associated with that sessionid in a file saved to disk. For example, if the sessionid were timestamp 1710163588124, the script would store the terminal's queried maximum sixel resolution and window resolution with that sessionid and subsequent calls to the script using that sessionid could reuse those values returned from the first session to skip the ~500 milliseconds needed to query those values from the terminal.

Additionally, sessionid could associate COLUMNS+LINES combinations for each window resolution, so if sessionid is same but window is resized, the script could detect this and query window resolution again for the new COLUMNS+LINES combination.

This would allow the script to be called multiple separated times by vifm while allowing the script to reuse and share details those calls use for the session. If a user starts vifm in a different terminal or restarts vifm with a new layout or font setting vifm could use a new sessionid and the script would query new values for that.

Maybe I will try to implement this today, what do you think? @Mange also feel free to give your opinion if you wish or ignore me also either way :)

[iambumblehead]

to be clear, if a sessionid were supported and if vifm were to use sessionid, this would require vifm to maintain the sessionid and pass it to each script call.

[iambumblehead]

merging this and planning to make a series of smaller PRs

[xaizek]

Session optimization seems to make sense.

to be clear, if a sessionid were supported and if vifm were to use sessionid, this would require vifm to maintain the sessionid and pass it to each script call.

It's just

let $RTF_SESSION = system('echo vifm-$RANDOM')

and then use $RTF_SESSION in fileviewer command.