On 170420-05:57+0200, Floyd Anderson wrote: > On Do, 13 Apr 21:55:29 +0200 > Miroslav Rovis <[email protected]> wrote: ... > > > >But I forgot floyd has got a "patch to keep the window position while > >resizing the font" and offered it: > > > >https://marc.info/?l=gentoo-user&m=149205691530349&w=2 ... > > Hi Miroslav, > > back from some computer-free holidays, I hope you had good and restful time!
> I haven’t forgotten that I owe
> you a patch. Study my attached approach and if you like, apply the patch
> at your own risk (it should be clean applicable to the currently latest
> upstream commit [1]).
which I just git clone'd, for that purpose.
> If you have any questions or ideas, get back to me.
Don't worry, I will! With my usual excuse for my slowness and relative
inaptitude...
> But keep in mind,
> I’m neither a developer nor a GUI programmer guru.
>
> It has some limits and/or doesn’t resolve certain issues:
> - the patch assumes ‘NorthWest’ as the reference point for the window
> gravity.
NW is just fine, I would expect that, it's the usual default.
> - if terminal background is colourised via escape sequences (as Andrew
> mentioned in [2]),
Yeah, I had marked important that email previously already, but only now
found some time to study the links (and only *some* time)...
And some of these notes of yours below I'll only more fully understand
when I, hopefully, try and apply the patch (more about my plan on that
further below):
> you may notice that a borderless window colourise
> only full cells (of rows/columns), not the gap between a terminal
> cell end and the window edge. Framed windows seems not to be
> affected by this behaviour.
> - window edges flutters/flickers while resizing fonts (independently
> from step-size and also when using escape sequences for resizing)
> - toggling a window between normal -> fullscreen/maximised state ->
> and back, you may notice that the window size has changed. I don’t
> know the reason for this issue (which occurs independently from the
> urxvt-font-size extension and my patch).
> - different window manager (WM) probably produces different
> behaviours. Think about a WM that try to imitate a tiling window
> manager by automatic resizing/positioning within a snapping area
> near the desktop edges.
> - patch is tested to my moderate needs but not fully with all kinds of
> fonts, WMs, multi monitor environment, etc.
> - ...
>
> The patch is too unimportant to solve some/all of the above issues
> and/or bloating up the urxvt extension script. And additionally,
> rxvt-unicode won’t and doesn’t expose all Xlib functions (such as
> XGetWindowAttributes) in urxvtperl, the embedded perl interpreter. So it
$ man urxvtperl # but how cryptic!, how long study that will be... I don't
have all those hours right now...
I hope I'll find a solution with less time to invest,
else...
> will be tricky sometimes, to solve a specific behaviour.
>
> My used and tested urxvt-font-size related Xresource settings:
> URxvt.font-size.keepwin: true
> URxvt.font-size.step: 4
> URxvt.keysym.C-0xffad: font-size:decrease
> URxvt.keysym.C-0xffab: font-size:increase
> URxvt.keysym.C-0xffb0: font-size:reset
>
> Since I use the default keysyms for font-size:{decrease,increase,reset}
> in Vim, I changed those defaults to C-KP_Substract (C-0xffad), C-KP_Add
> (C-0xffab), C-KP_0 (C-0xffb0) like in Firefox and others.
I don't get what these are. Not at this time. And this is my second
reading of your email...
NOTE (at proofreading): Is that 'C-KP_Substract' should read
'C-KP_Subtract'?, the "-" on the keypad? So 'C-KP_Subtract' means
Ctrl-<minus>?, and C-KP_0 means Ctrl-0?
I also compared what I have currently installed:
# eix urxvt-font-size
[I] x11-misc/urxvt-font-size
Available versions: 1.1 **9999
Installed versions: 1.1(13:07:28 22/02/15)
Homepage: https://github.com/majutsushi/urxvt-font-size/
Description: Perl extension for rxvt-unicode to change the font
size on the fly
#
# qlist urxvt-font-size
/usr/lib64/urxvt/perl/font-size
/usr/share/doc/urxvt-font-size-1.1/README.markdown.bz2
#
[I compared what I have currently installed] with the 9999 version, which
is the version that, IIUC, I plan to hopefully try and patch with your
patch...
>
> References:
> [1]
> <https://github.com/majutsushi/urxvt-font-size/commit/0cc2624489fb60fcebf85d5c4dd62f425196c5b0>
That's the the two colons that Jan Larres, the current maintainer left
out, and you reminded him they were missing. Nice of you! (IIUC)
> [2]
> <https://archives.gentoo.org/gentoo-user/message/a4d58e993934aa4a273998eda030d115>
The link that Savchenko gave in that email is puzzling me:
http://rcr.io/words/dynamic-xterm-colors.html
I want to try and figure out that bash script there... It's very
educational.
I need more time to study this. But I do have a question:
I read, somewhere, spender (the author of grsecurity) wrote it, but I
don't recall the entire context, and so I can only vaguely paraphrase
what I remember he wrote, that... Aaargh, can't remember well at all...
I think it wasn't about perl only, or perl wasn't even mentioned
explicity, but it was spender saying how running scripts by using stuff
like:
#!/usr/bin/env [perl|python|...]
(
in the new script it's
#!/usr/bin/env perl
)
instead of the more simple, traditional shebang line:
#!/usr/bin/<interpreter> # perl or python or bash
(
in the old script it's
#!/usr/bin/perl
)
that the former (...env <interpreter>) is not as safe as the latter
(...bin/<interpreter>).
Why was it necessary to introduce that change? I'm referring to Jan's
change, of course.
It can't be it does not bring a tiny bit more into the attack surface,
can it?
I need to try and understand some more of the above, but not
immediately. A couple of hours of work on this today still got me
too inconclusive in my understanding... And I do have other stuff on my
hands that require my efforts and time...
And my plan is... Probably bump the ebuild into my custom overlay, as I
don't install online from git (until it becomes possible to verifiably
install packages while online, I mean: for non-experts like me; it is
possible to verifiably install packages with the old webrsync, also
while online...; OTOH app-crypt/gkeys that Savchenko recommended to me
in an email a month or two ago to try and test, those do bring in
more verifiability when installing from git, but I haven't found time to
study gkeys yet...)
[And my plan is... Probably bump the ebuild into my custom overlay,]
modify it to get the git source served from my local Apache cgit repo
[1] (and urxvt-font-size package is not even PGP-signed, neither tags
nor commits, which is always an important feature missing with the code,
for me...)
[modify it to get the git source from my local Apache cgit repo], put
your patch in /etc/portage/patches/x11-misc/urxvt-font-size/ check that
my /etc/portage/bashrc is ready to apply user patches (I recently
updated it as per the wiki page, gave the link in another email a couple
of days ago, to this list, yeah, it was in the non-replied-to message to
Ian Zimmermann in a 2 emails --so far-- thread split from this one...
which was about window positions as well!... [2]), and...
...And emerge it:
# emerge urxvt-font-size
Courious to read what your opinion is on usage of /env vs plain /bin
scripts security-wise, as I put it further above! And why that change...
Regards!
---
[1] I have actually learned when installing gnunet from
youbroketheinternet-overlay just two days ago that I probably can
use local overlay even without seving it with cgit and Apache,
simply from local filesystem!
[2] openbox window positions
https://lists.gt.net/gentoo/user/325342
(and my reply to it contains digressions, but also simple
questions...)
--
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr
signature.asc
Description: Digital signature
