Repository navigation
Let buffer-face-mode rescale ghostel terminals - #589
Merged
Merged
Conversation
ghostel-mode remaps `default' to `ghostel-default', which was defined as `:inherit default'. `face-remap-add-relative' orders the `default' remappings by how many attributes they leave unspecified, giving the most relative one the highest precedence, and `:inherit default' pins every attribute of `default'. `ghostel-default' therefore outranked and silently masked any face-name remapping added afterwards: plain `M-x buffer-face-mode' (variable-pitch) had no effect at all. Plists such as (:height 240) tied on the sort key and applied only by virtue of `sort' being stable. Drop the inherit. `face-remap-add-relative' already keeps the real `default' face as the base of the remapping entry, and `ghostel--face-hex-color' passes `default' as its INHERIT fallback, so the OSC 10/11 color replies are unchanged. Even where the remapping did apply, the terminal kept its old dimensions: `buffer-face-mode' rescales the font without changing the window's pixel geometry, so `window-size-change-functions' never fires. At (:height 240) the window fit 16x50 while the shell still saw 33x100. Advise it with `ghostel--around-local-font-scale', the wrapper `text-scale-mode' already uses; `buffer-face-set', `buffer-face-toggle' and `variable-pitch-mode' all reach the remapping through it. Verified in a GUI Emacs driving a live bash: `M-x buffer-face-mode' now yields 33x116 (proportional font, narrower average glyph), (:height 240) yields 16x50 and (buffer-face-mode -1) restores 33x100, with `stty size' agreeing in each case; text-scale-set 6/0 still yields 11x31 / 33x100. Closes #588
This branch was previously deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #588 —
buffer-face-modehad no effect in ghostel buffers, for two independent reasons.The face remapping was masked
ghostel-moderemapsdefaulttoghostel-default, which was defined as:inherit default.face-remap-add-relativeorders thedefaultremappings by how many attributes they leave unspecified, giving the most relative one the highest precedence — and:inherit defaultpins every attribute ofdefault. Soghostel-defaultoutranked and silently masked any face-name remapping added afterwards: plainM-x buffer-face-mode(variable-pitch) was a complete no-op. Plists such as(:height 240)tied on the sort key and applied only by virtue ofsortbeing stable.Dropping the inherit is safe:
face-remap-add-relativealready keeps the realdefaultface as the base of the remapping entry, andghostel--face-hex-colorpassesdefaultas its INHERIT fallback, so the OSC 10/11 color replies are unchanged (verified live — anOSC 11 ?query still answersrgb:ffff/ffff/ffffagainst a White-background default).The terminal never resized
Even where the remapping did apply,
buffer-face-moderescales the font without changing the window's pixel geometry, sowindow-size-change-functionsnever fires and the PTY kept its old dimensions: at(:height 240)the window fit 16x50 while the shell still saw33 100. It is now advised withghostel--around-local-font-scale, the same wrappertext-scale-modealready uses;buffer-face-set,buffer-face-toggleandvariable-pitch-modeall reach the remapping throughbuffer-face-mode, so one advice covers every entry point.ghostel--windowsfilters onderived-mode-p 'ghostel-mode, so it is a no-op in other buffers.Verification
make -j8 allclean from scratch, 0 unexpected. Two regression tests added intest/ghostel-modes-test.el.Live GUI Emacs 31 driving a real bash, window 100x35:
stty size33 100M-x buffer-face-mode33 116buffer-face-set '(:height 240)16 50buffer-face-mode -133 100text-scale-set 611 31text-scale-set 033 100Grid and window agree in every row now, and
text-scale-modeis unregressed.Note
M-x buffer-face-modewith its defaultvariable-pitchnow genuinely applies a proportional font. Ghostel resizes correctly for it (100 → 116 columns from the narrower average glyph), but a proportional font in a character grid still renders ragged — that is now the user's choice rather than a silent no-op.Not addressed here:
ghostel--reported-cell-width/-heightstill derive fromframe-char-width/frame-char-height, which are frame-level and blind to any buffer-local remap, so the cell pixel size reported to libghostty (CSI 14 t/CSI 16 t,ws_xpixel/ws_ypixel, kitty/sixel scaling) is stale under buffer-face and under the already-supportedtext-scale-mode. Pre-existing and separate.