In the debug log, you did nvim --clean,

I can't find the string nvim --clean in the debug log. I did find nvim --cmd though…

In the screen recording, nvim --clean appears as a suggestion, which might be confused for the actual command that is being ran, because Fish renders suggestions inline.

Even if the pref is enabled, Neovim doesn't like it when I resize the window. There seems to be some issues around resizing in general.

Bug report

I was on previous beta version (unsure which one, exactly). I updated today and noticed that this began misbehaving.

• iTerm2 version: 3.5.5beta1

• OS version: Sonoma 14.6.1 (23G93)

• Attach ~/Library/Preferences/com.googlecode.iterm2.plist here (drag-drop from finder into this window) com.googlecode.iterm2.plist

• Attach a debug log, if possible.

• Attach a screen capture video if it would make the reproduction steps clearer. debuglog.txt

PLEASE ATTACH YOUR PLIST FILE FOR BUG REPORTS! Seriously! I'll probably ask you for it if you don’t.

Detailed steps to reproduce the problem

1. Ensure that the "Adjust window when changing font size" preference is disabled within Settings > General > Window.
2. Send \27;]1337;SetProfile= to set the profile when launching a program (in my case, Neovim). This new terminal profile modifies the font and background color.

Here is the Lua code responsible for sending the directive to iTerm: https://github.com/slice/nixfiles/blob/28f1ad5115e789b8283f2e39303cf4eda41a8847/nvim/lua/skip/assimilate.lua#L7-L9

What happened

Inputting any text does not work correctly. I think iTerm2 isn't noticing that the terminal dimensions need to change when the profile changes, while still keeping the window the same size. If I enable this preference, then it seems to work just fine.

What should have happened

In accordance with the preference being disabled, the terminal should adjust the size of the character grid without touching the size of the actual Cocoa window itself.

ahhhhhhhhhhhhhhhhhh

lgtm otherewise..

are we planning to add future methods to this interface? if not, then could it just be a function instead? (i prefer free functions over classes with single method)

        mailgun_url = f"https://api.mailgun.net/v3/{econfig.MAILGUN_DOMAIN}/messages"

extraneous?

close #196

porra 💯

close #30

haven't tested but lgtm

isn't specific enough, see: frontend!25 (comment 1828988495)

need something like [a-z0-9_.]{2,32}

assuming that the entirety of DISCORD_RE match is used (i don't see any groups here), i think /[a-z0-9_.]{2,32}/i works

oh wait this technically isn't specific enough (e.g. would allow spaces and other disallowed symbols, etc.)

lgtm otherwise

lmfao wtf was i on when i wrote this shitcode

        input(type="text", placeholder="discord.username").form-control#discord

pomelo usernames can't contain capitals, also added a period to make it exceedingly clear that it's a username

Sorry, it's been a while…

I think you have a nonretina mac, is that right?

Sort of, yes; when I originally opened the issue I was using a MacBook Air (M1, 2020) connected to a non-Retina monitor. The issues would manifest there.

I have since upgraded to a MacBook Pro (M3 Max, 2023) and have been using a Studio Display as well as the aforementioned non-Retina monitor as a second display. Since I effectively keep text-heavy windows on the Studio Display, this bug effectively stopped being an personal blocker. Curiously though, when I tried reproducing today, I could not reproduce many of the issues in these scenarios when using iTerm on the non-Retina monitor:

• MacBook Pro connected to Studio Display + non-Retina monitor
• MacBook Pro connected solely to the non-Retina monitor
• The original MacBook Air connected to the non-Retina monitor, with the built-in display active

There were some other rendering inconsistencies between the Pro and the Air for some reason. The Pro is a much newer machine so it might be the case that I messed with some defaults relating to font rendering. I might also suspect that Apple made some changes and the behavior was improved as a result (both machines have since been updated to macOS Sonoma 14.4). If I happen to run into this again in the future, I'll give more details, but this seems to have mysteriously fixed itself for the most part.

@gnachman Thanks for continuing to tackle this problem!

I tried out the adhoc build, but I think the underlying issues remain. The "stray horizontal lines" artifacts remain with PragmataPro Mono Regular 14 (and seemingly only at that size). Here's a debug log of me creating a window with that font: debuglog.txt, and a screenshot:

This issue is subtle; it's only a few pixels there.

Meanwhile though, with the Iosevka Uni Regular 14 font, there appears to be more drastic artifacts by the 0 glyph: , and also b:

Here's a debug log of me creating a window with that font: debuglog.txt

The problem can also worsen with font size; here's Iosevka Uni Regular 20:

This seems somewhat similar to before.

If it helps, I've also recorded a video (and wrote a small Cocoa app to constantly display a timestamp, to help correlate it with a log) here: https://skip.lol/iterm_video-2024-01-21.mp4 (ignore the fiddling with my text editor, I forgot my keybinds!)

And the debug log for that session (143 MB!) is here: https://skip.lol/iterm_video_debuglog_2024-01-21.txt

Alright, here is a frame capture with PragmataPro Mono Regular at 14pt:

iTerm2-frame-capture.zip

Here is another frame capture demonstrating the other issue, with Iosevka Uni Regular at 14pt:

iTerm2-frame-capture.zip