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

Respect internal window/frame padding #34

Closed
wants to merge 2 commits into from
Closed

Respect internal window/frame padding #34

wants to merge 2 commits into from

Conversation

DivineDominion
Copy link

Inspired by https://github.com/rougier/nano-emacs, I have a internal-border-width (see Frame Layout in the manual) set to 24:

(setq default-frame-alist
      (append (list
               '(font . "Roboto Mono-18")
               '(min-height . 1)  '(height     . 45)
               '(min-width  . 1)  '(width      . 101)
               '(vertical-scroll-bars . nil)
               '(internal-border-width . 24) ;; frame padding around the text
               '(left-fringe    . 0)
               '(right-fringe   . 0))))

I noticed that the effective window width calculations wouldn't work as expected -- as a result, lines would wrap.

This change takes the optional internal-border-width into account.

Examples with internal border of 24 and 48, full screen and windowed:

before (wrapping/truncating) after (fits)
24px
48px Screen Shot 2021-10-30 at 11 18 09 Screen Shot 2021-10-30 at 11 23 03

I noticed that I had to / 2 the border value, otherwise the line would be truncated too much. Still: the larger the internal-border-width, the worse the line actually fits. See the screenshot in the bottom-right at 48px: there's room for 1--2 additional characters.

But I think that's preferable to line-wrapping.

@DivineDominion
Copy link
Author

@purcell Pinging just in case you didn't get a notification from the PR itself to see what you think of this.

@purcell
Copy link
Owner

purcell commented Nov 7, 2021

Hmm, thanks for this, but it's weird — with a recent dev Emacs version, I can't reproduce your wrapping/truncation.

@DivineDominion
Copy link
Author

@purcell Could also be macOS and its font rendering in GUI emacs -- there seems to be a somewhat common problem with width calculations. Not sure though if that's the case and subtracting the internal border offset is just a coincidence.

Question is: do my changes look weird on your machine, e.g. is the line too small then?

@purcell
Copy link
Owner

purcell commented Nov 10, 2021

Question is: do my changes look weird on your machine, e.g. is the line too small then?

No, they actually don't make a difference at all, as far as I can tell, either with or without an internal border.

@purcell
Copy link
Owner

purcell commented Nov 10, 2021

(Which seems suspicious)

@DivineDominion
Copy link
Author

I read up a bit more about frame geometry in Emacs:

https://www.gnu.org/software/emacs/manual/html_node/elisp/Frame-Layout.html
https://www.gnu.org/software/emacs/manual/html_node/elisp/Frame-Size.html

When I query (frame-inner-width nil) and (window-width nil t) I get the same values. So your original approach should just work ™️

I wonder why it's not getting smaller for you though when you use my code. Is (alist-get 'internal-border-width (frame-geometry nil)) not returning the value you set? I updated my code to use that instead of default-frame-alist, too.

@DivineDominion
Copy link
Author

I built Emacs 28 from source and the issue disappears. Might've been a faulty build 🤷

@purcell
Copy link
Owner

purcell commented Nov 22, 2021

Ah, that can happen sometimes. I've frequently experienced subtle breakage in dev versions.

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

Successfully merging this pull request may close these issues.

None yet

2 participants