Patch to support negative geometry offsets for right- or bottom-justification

[BMJ-pdx]

roxterm does not honor negative geometry offsets, which are useful for right- or bottom-justification.
E.g., to start a roxterm at the lower-right corner:

roxterm --geometry=80x24-0-0

I have a patch to support that. I've been using it for years to automatically start multiple roxterms, typically two in each of several workspaces. 'dffstat' is:

multitab.c | 56 ++++++++++++++++++++++++++++++++++++++++++++------------
multitab.h | 2 +-
roxterm.c | 4 ++--
3 files changed, 47 insertions(+), 15 deletions(-)

But attempts to add it as an attachment have failed, and if included here inline, the format gets munged (even if quoted or tagged as code).
I don't want to go through the rigamarole of forking the git repository and submitting a pull request.

If someone can fast-track me on how to submit the patch, I would like to get it upstreamed.
Thanks --
-- Bruce Jerrick

[egmontkob]

Hi,

(not a roxterm developer, just chiming in)

Rename or add another extension to the patch so that the filename ends in .txt, attaching should work then.

[BMJ-pdx]

Here's the patch -- many thanks to egmontkob!

roxterm-3.15.2-honor-neg-position.patch.txt

[realh]

Thanks for that. I changed it slightly to avoid the deprecated functions. Please could you test the new version to make sure it still works the same way? It's a bit of a hassle for me to get a chance to test it on X11 and multiple monitors at the moment.

[BMJ-pdx]

I built a Fedora 41 RPM pckage from your 2025-05-18 git commit 15647f4..., and am using it now, with no problems.

I haven't poked at any of the new OSC52 stuff -- have to find out what it is first :) .

My platform is:

• ASUS ROG Strix G18 (aka G814/G834)
• NVIDIA GeForce RTX 4080 Laptop GPU
• Single monitor, native 2560x1600, running as 2048x1280
• Fedora 41
• kernel-6.14.6-200.fc41.x86_64
• nvidia 570.144
• MATE 1.28.0
• gcc-14.2.1-7.fc41.x86_64

I didn't use your roxterm.spec.in, because the Fedora spec files are very, very, very different (as a certain Florida resident might say).
Instead, I modified the roxterm.spec from Fedora 41 roxterm-3.15.2-1.fc41.src.rpm . I can send a diff of it if you want it (but I don't see a Fedora logo on your website :) .

Do you want the packages I built?

• roxterm-3.16.0-12.g15647f4.x86_64.rpm
• roxterm-3.16.0-12.g15647f4.src.rpm

P.S.: 'roxterm --version' would be nice :) .

Update: I see that I goofed on the release string "12.g15647f4' -- your version had a tilde before the "12", not a hyphen. Blame it on no fractional scaling in MATE, and a 168dpi display. (I have to use xrandr to scale it instead.)

[BMJ-pdx]

I just now noticed this from 'roxterm --help':

-g, --geometry=COLUMNSxROWS Set size of terminal

It should mention the position also. Perhaps:

COLUMNSxROWS[+/-XOFFSET+/-YOFFSET]

(Although that "+/-" is a bit messy.)

[realh]

I've updated the help message and the man page. I've just realised I forgot to say it probably only works in X11, but I expect most people interested in the feature would be aware of that already.

OSC52 is a way of giving terminal applications access to the clipboard. The VTE developers are opposed to it because of security risks, but it's extremely useful when using neovim over ssh, so I found a way to hack it in.

I've removed the .spec file because it's probably very outdated, so adapting one from the latest Fedora release seems like a better idea.

[BMJ-pdx]

I've built 3.16.2 (git 84cf2c8...) as a Fedora package and am running it now.
Is that a release? If so, I'll file an RHBZ (Fedora Bugzilla) report, in hope that they'll get it into F43 Rawhide at least.

Update: The man page and --help both say a geometry spec of just +X+Y (or -) can be given without a preceding WxH, but I get a popup saying "Invalid geometry specification" from this:

roxterm --geometry="+100+100"

That also happened in 3.15.2 and 3.16.0 (git 15647f4...).

Update: I'm working on a patch. I may try regex(3). It may be "slow" (but under 1 ms., I'll bet), but I think the code would be simpler than ad-hoc parsing (my credo is "Let the machine do the work").

[realh]

Yes, I decided a release was overdue so I've set 3.16.2 as a releae on github and uploaded it to my PPA too. I'm sure when I tried -geometry=-20-20 it worked the first time, but I noticed afterwards that position on its own doesn't work after all. I corrected the man page, and I thought I'd corrected the output of --help too, but it's still showing the incorrect version for some reason. I might as well do a new release and add the information that it isn't widely supported any more.

[BMJ-pdx]

I have a regex(3) parser working in a test stub. I just have to fold it into multi_win_parse_geometry(). Three or four static subroutines used by that would be eliminated.

Update:
I'm going to abandon this approach. The parsing itself is great -- nice and compact. But sscanf()'ing the subexpressions that regexec() provides is a mess, for two reasons: They're not NUL terminated (just start and end offsets into the original string), and sscanf() can only limit its scan by a constant (e.g. "%3d"), not a variable.
Sute, it can be done, but it's no longer nice and compact.