Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem if increasing font size in Vim (and others) #10

Open
Phyks opened this issue Mar 10, 2014 · 27 comments
Open

Problem if increasing font size in Vim (and others) #10

Phyks opened this issue Mar 10, 2014 · 27 comments

Comments

@Phyks
Copy link

Phyks commented Mar 10, 2014

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
Copy link
Owner

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
Copy link
Author

Phyks commented Mar 11, 2014

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) :
tmp

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
Copy link
Owner

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
Copy link
Owner

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
Copy link
Owner

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

@Phyks
Copy link
Author

Phyks commented Mar 23, 2014

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
Copy link
Owner

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
Copy link
Author

Phyks commented Mar 25, 2014

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
[email protected] 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:
#10 (comment)

@nishantvarma
Copy link

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
Copy link
Owner

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
Copy link

tex commented May 11, 2015

I have the same problem, using i3 window manager.

@tex
Copy link

tex commented May 11, 2015

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

@Phyks
Copy link
Author

Phyks commented May 11, 2015

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

@majutsushi
Copy link
Owner

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
Copy link
Author

Phyks commented May 14, 2015

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-
Copy link

rr- commented Mar 27, 2016

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
Copy link

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
Copy link
Author

Phyks commented May 29, 2016

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
Copy link

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

@Phyks
Copy link
Author

Phyks commented May 29, 2016

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
Copy link
Owner

majutsushi commented Sep 25, 2016

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
Copy link

madduck commented Nov 24, 2016

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

@majutsushi
Copy link
Owner

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
Copy link

shmup commented Jun 23, 2020

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
Copy link

9ary commented Apr 4, 2021

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
Copy link

manwe-pl commented Apr 4, 2021

Works great, thank you!

@crpb
Copy link

crpb commented Oct 18, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants