Problem if increasing font size in Vim (and others)

[Phyks]

Hi,

I've a problem with this extension : the aspect of the window is not computed again, in some sort, when I increase the font size in urxvt. I have to manually resize the window for the shape to be correct.

For instance, if I increase the font size in Vim, the bottom of the window disappears and I can't see the prompt anymore. I have to manually resize the window for the Vim window to adapt to my urxvt window.

Is there a way to fix this ? Thanks

[majutsushi]

That's odd, resizing is working fine for me. Maybe your window manager is interfering? What happens when you run the command mentioned in the 'Troubleshooting' section in the README?

[Phyks]

I confirm I have the same behaviour if I use the command mentionned in the Troubleshooting section… Sorry for the wrong issue.

What working setup do you have ? I'm experiencing it with both Gnome-Shell and awesome on arch linux.

I think I found the problem. If my urxvt window is floating, no problem if I change the font size on the fly. But since it has some specific size (maximized, half the screen on gnome-shell), it stops working and I get something like this (Vim opened, after a decrease in font-size) :

My uable urxvt window is the black screen, the transparent one being the full window. Only the black part is usable and taken into account, unless I resize the window itself (demaximize + demaximize for example). Symmetric behaviour if I increase font-size.

Thanks for any ideas you might have :)

[majutsushi]

Interesting, I'm using Awesome myself (on Debian) and it's working fine for me there, both in floating and tiled mode. I don't have Gnome Shell available at the moment to test that unfortunately, but it could be a bug in that. What version of Awesome are you using? And what happens if you press Ctrl-L in Vim?

[majutsushi]

I just had an idea: could you try adding the line

    $term->want_refresh;

at the end of the subroutine fonts_change_size? I could imagine that that might fix it.

[majutsushi]

Have you tried the refresh change? I'm curious whether that actually fixes it.

[Phyks]

Sorry, I missed your answer…

I added it to line 149 of the script, just before the closing braces of fonts_change_size, but it doesn't seem to solve the problem…

Thanks for your help !

[majutsushi]

Oh. Well, in that case I'm not sure I can actually fix this from within the script, sorry. I will have a look whether there's a way to maybe send an X request that does something useful but I can't promise anything.

[Phyks]

OK. I'll update this issue if I find anything else.

Thank you !

On 24 mars 2014 11:46:20 UTC+01:00, Jan Larres notifications@github.com wrote:

Oh. Well, in that case I'm not sure I can actually fix this from within the script, sorry. I will have a look whether there's a way to maybe send an X request that does something useful but I can't promise anything.

---

Reply to this email directly or view it on GitHub: https://github.com/majutsushi/urxvt-font-size/issues/10#issuecomment-38430639

[nishantvarma]

I have the same issue , is there a fix ? All that it is needed is a "refresh" . I use the tabbedex plugin in urxvt and when I change tab and then come back everything resizes perfectly . Please let me know if there is a fix for this ? I think a urxvt refresh after font increase/decrease should solve the problem . Thanks !

[majutsushi]

I still haven't been able to reproduce this unfortunately. Could you give some details about your setup like your window manager, your urxvt and vim configuration and version and such?

[tex]

I have the same problem, using i3 window manager.

[tex]

Switching from stacked to floating and back causes window reshape and text fits to terminal and font color size.

[Phyks]

Same thing, recently moved to i3wm and still having the same problem. Window needs a reshape to recover its state.

[majutsushi]

I've now tried to reproduce it with awesome (3.5), i3 (4.8) and dwm (6.0), all with urxvt 9.21. It worked fine for me in all of them. Maybe it was a bug in urxvt that got fixed?

[Phyks]

I am using urxvt 9.21 (from Arch package) and i3 4.10.2 (idem). I updated the perl font-size script.

Steps:

• Start urxvt
• Run Vim
• Type ":" to see the bottom of the window (command bar)
• Increase the font-size, the window is cropped

Maximizing / restoring the window restore its behaviour, keeping track of the font-size.

Thanks

[rr-]

FWIW, the script works fine here.

arch + urxvt 9.22 + vim 7.4 (patches 1-1639) + bspwm 0.9-126

Perhaps it's a font thing? I'm using Liberation Mono Powerline.

[manwe-pl]

I'm gonna add my .02$ here. Yes, there's a problem. After changing font size, terminal doesn't send to running software "hey, I've changed my size". If you for example run mc and than call perl:font-size:increase, mc doesn't "know" that terminal now has different numer of rows/cols and therefore draws itself outside the screen. You have to resize urxvt or toggle fullscreen, so "size changed" signal is sent.

$term->want_refresh; at the end of fonts_change_size(), is there any other way to force it? maybe resize the window to the same size?

[Phyks]

Ok, some extra info about it. After some tweaks with my .Xresources, it appears this issue only happen when tabbedex extension is loaded also. If I removed tabbedex from my URxvt*perl-ext-common line, everything works fine.

However, I do not know what is specific with tabbedex.

@majutsushi let me know if I can try something more to help you tackling this issue.

[manwe-pl]

Damn, that's true. Without tabbedex everything is OK. Well… tabbedex is more important than this glitch with urxvt-font-size.

[Phyks]

Sure. Still, I'd like to narrow down the issue so that it could be fixed on either side, in tabbedex or urxvt-font-size, whichever is faulty.

[majutsushi]

Interesting, I'm actually finally able to reproduce this with the standard tabbed extension. After looking into it a bit I think this is actually a bug in tabbed (and apparently tabbedex). It's probably lacking proper hook handling for the font-resizing case, since it would have to update its tab size based on the window size and new font size. So as far as I can see there's probably nothing I can do about this from this script.

[madduck]

I also have this issue, but without tabs. I think @manwe-pl's point about signaling the client is correct.

[majutsushi]

Yes, some kind of signalling is missing somewhere. But even after looking through the urxvt Perl API several times and experimenting a bit I haven't found any way to make this work from the context of this script. I'd be happy to be proven wrong, though. The API docs are a bit light on how the X11-derived calls work so it's entirely possible that I missed something.

[shmup]

An old thread, and nothing useful to add here but I will say:

1) this happens for me in 20.04 with urxvt v9.22 2) this happens regardless of being in vim or tmux 3) a resizing does work to fix it, so if you were in i3 for example, a quick pop out/in is a resize that'll reset it and the text will be visible

OH HEY, I LEARNED TO READ

Interesting, I'm actually finally able to reproduce this with the standard tabbed extension. After looking into it a bit I think this is actually a bug in tabbed (and apparently tabbedex). It's probably lacking proper hook handling for the font-resizing case, since it would have to update its tab size based on the window size and new font size. So as far as I can see there's probably nothing I can do about this from this script.

Indeed, disabling tabbedex fixed this problem. Nice.

[9ary]

Sorry for bumping this very old thread, but I have a workaround for this issue. When changing fonts, urxvt asks the window manager to resize the window while keeping the same grid size. Everything is then updated when the WM reconfigures the window with the new size. The following diff makes it resize the grid while keeping the same window size which is the behavior I think we're all after. This makes the font size change feel more like eg browser zoom does. Unfortunately this causes flickering but there isn't much to do about that, the same thing happens when resizing the window normally.

--- src/main.C
+++ src/main.C
@@ -876,9 +876,8 @@
 #endif
     }

-  if (parent)
     {
+      resize_all_windows (szHint.width, szHint.height, 1);
-      resize_all_windows (0, 0, 0);
       scr_remap_chars ();
       scr_touch (true);
     }

[manwe-pl]

Works great, thank you!

[crpb]

thank you @9ary this is just what i needed :-).