On Fr, 21 Apr 00:12:28 +0200
Miroslav Rovis <miro.ro...@croatiafidelis.hr> wrote:
On 170420-05:57+0200, Floyd Anderson wrote:
On Do, 13 Apr 21:55:29 +0200
Miroslav Rovis <miro.ro...@croatiafidelis.hr> 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!
Yes, thanks, it was like that and I had better stay there because after an update yesterday, xorg-server kills my last nerve while I am fighting with a "Segmentation fault at address 0x0" server error. :-(

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...
Yes it needs investigation. That was the reason why I does not realise firstly, that the changes to my local font-size extension script were made by me (as I mentioned in an earlier reply). I could not believe that I spend my time to those cryptic stuff (have not used Git for this in the past, which had simply shown myself as the author).
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?
Sorry, I was not quite verbose about this. Yes your are right, the "C" means control key and "KP" stands for keypad. Normally you can use those identifier directly in the keysym definitions but those for keypad keys does not work for me, so I used their hexadecimal keycode equivalents. You can find the keycodes with the command `xev` or by looking in the header file "/usr/include/X11/keysymdef.h" near line 202.

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...
Cannot figure out what IIUC is but anyway. Patching will fail with the v1.1-tag commit (two years, four month old).

I would recommend not to hassle portage with those tiny installs (at least on a single user machine). Simply tell rxvt-unicode where it can find your additionally extension script(s) by using for instance:
   URxvt.perl-lib: $HOME/.config/urxvt/ext

in your Xresource file for rxvt-unicode. Have a look at urxvt(1) manual for more alternatives. I see only one disadvantage, you have to apply the patch manually but only once if you are using a local Git repo (as you do and mentioned in your reply).

[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. […]
Not necessary if you rarely use it (in my opinion) but always good to known that it is there when you need it. Becomes probably very handy e.g. for terminal prompt designs, window titling or:
 - quickly change/test fonts, where <type> is one of {710..713} which
   stands for regular, bold, italic, bold-italic and <font> something
   like 9x15, fixed or xft:termminus-12 and so on.
   $ printf '\e]%s;%s\007' "<type>" "<font>"
 - query RGB colour values, where <colournumber> is one of {0..255}
   $ echo -ne "\033]4;<colournumber>;?\007"
 - window sizing/positioning (e.g. 1144x954+0+0 bound to Ctrl+F11) in
   urxvt. Did you remember the syntax? :-)
   URxvt.keysym.C-F11: command:\033[4;1144;954t\033[3;0;0t
 - ...

[…] 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
)
Yes, with commit 83da253a7946c85d65fbf9c3a983bd6ef51420aa the explicit path declaration for perl was removed.

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 do not think so. It is probably rather a portability related decision. Have a look at a blog post by Michał Górny [1] for some light on this.

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...)
Same here. I does not knew app-crypt/gkeys previously and it sounds very interesting. It is totally overdue nowadays to have something like that for the rsync protocol.

[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...)
Maybe a kindly request upstream for signed tags may change this.

[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...)

Your plan with the Apache cgit repo seems to be a nice challenge to learn something but as I noted above, creating and maintaining an overlay for so tiny things is a little bit overkill in my opinion. Fetching the related Git repository from time to time and you are done while an overlay needs probably more significant work.

As an example, I am currently just imagine I have to create overlays for my favourite Vim plugins instead of using well known manager like Vundle, NeoBundle, Dein or what else. That were a lot of work for the overlay solution or did I miss the point?


References:
[1] 
<https://blogs.gentoo.org/mgorny/2016/02/08/a-quick-note-on-portable-shebangs/>

--
Regards,
floyd


Reply via email to