unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
@ 2024-03-27 20:25 Ramon Diaz-Uriarte
  2024-03-28  5:58 ` Eli Zaretskii
  0 siblings, 1 reply; 21+ messages in thread
From: Ramon Diaz-Uriarte @ 2024-03-27 20:25 UTC (permalink / raw)
  To: 70038; +Cc: Rahguzar, Ramon Diaz-Uriarte

[-- Attachment #1: Type: text/plain, Size: 1824 bytes --]


With some fonts, changing focus (M-x other-window) from a buffer with images, makes the content in the buffer with images to shift up and down.

I am seeing this in Debian, with both the GTK and Lucid builds, under X11.

The code below reproduces the problem. This problem has been identified while debugging a change on focus issue with pdf-tools (https://github.com/vedang/pdf-tools/pull/224#issuecomment-2014151358 and ff.)


How to reproduce

- Copy the images to /tmp  (or place there three reasonably sized images, named image1.png, image2.png, image3.png)

- emacs -Q

- eval the following code

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Place images in /tmp
(progn
  (defun pin-vscroll-down (win)
    (set-window-vscroll win 200 t))
  ;; Any of the following leads to the bug
  (set-frame-font "JuliaMono" nil t)
  ;; (set-frame-font "DM Mono" nil t)
  ;; (set-frame-font "Intel One Mono" nil t)
  (let* ((height (/ (* 2 (frame-pixel-height)) 15))
         (image1 (create-image "/tmp/image1.png" nil nil :height height))
         (image2 (create-image "/tmp/image2.png" nil nil :height height))
         (image3 (create-image "/tmp/image3.png" nil nil :height height)))
    (with-current-buffer (get-buffer-create "*image-scroll-test*")
      (insert " \n \n \n \n \n \n")
      (put-image image1 1)
      (put-image image2 5)
      (put-image image3 9)
      ;; With larger image sizes (goto-char 3)
      ;; also triggers the problem.
      (goto-char 11)
      (add-hook 'pre-redisplay-functions #'pin-vscroll-down nil t))
    (split-window-right)
    (other-window 1)
    (switch-to-buffer "*image-scroll-test*")))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

- M-x other-window

- Notice how the images on the buffer on the right move up and down.



[-- Attachment #2: image1.png --]
[-- Type: image/png, Size: 20327 bytes --]

[-- Attachment #3: image2.png --]
[-- Type: image/png, Size: 22369 bytes --]

[-- Attachment #4: image3.png --]
[-- Type: image/png, Size: 20595 bytes --]

[-- Attachment #5: Type: text/plain, Size: 11753 bytes --]



In GNU Emacs 29.3.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.18.0) of 2024-03-26 built on Phelsuma
Repository revision: 38faacf353fb4c8efb027019a4619a386edfe62c
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
System Description: Debian GNU/Linux trixie/sid

Configured using:
 'configure --disable-silent-rules --with-native-compilation=aot
 --with-json --with-xwidgets --without-xaw3d --with-x-toolkit=gtk3
 --with-xinput2 --with-tree-sitter
 --prefix=/home/ramon/Sources/emacs29-bin 'CFLAGS=-g -O2 -mtune=native
 -march=native' 'CC=ccache gcc''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2
XPM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  dogears-mode: t
  global-jinx-mode: t
  jinx-mode: t
  company-quickhelp-mode: t
  company-quickhelp-local-mode: t
  hideshowvis-minor-mode: t
  rainbow-delimiters-mode: t
  outli-mode: t
  outline-minor-mode: t
  symbol-overlay-mode: t
  display-fill-column-indicator-mode: t
  hl-line-mode: t
  display-line-numbers-mode: t
  company-tng-mode: t
  global-company-mode: t
  company-mode: t
  pixel-scroll-precision-mode: t
  which-function-mode: t
  recentf-mode: t
  vertico-indexed-mode: t
  vertico-prescient-mode: t
  prescient-persist-mode: t
  vertico-multiform-mode: t
  vertico-mode: t
  marginalia-mode: t
  helm-ff-icon-mode: t
  shell-dirtrack-mode: t
  helm-autoresize-mode: 1
  async-bytecomp-package-mode: t
  pulsar-global-mode: t
  pulsar-mode: t
  global-hl-todo-mode: t
  hl-todo-mode: t
  global-aggressive-indent-mode: t
  aggressive-indent-mode: t
  shackle-mode: t
  winner-mode: t
  global-anzu-mode: t
  anzu-mode: t
  savehist-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  electric-pair-mode: t
  which-key-mode: t
  minibuffer-depth-indicate-mode: t
  global-auto-revert-mode: t
  override-global-mode: t
  gcmh-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  context-menu-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  hs-minor-mode: t

Load-path shadows:
/home/ramon/.emacs.d/elpa/ef-themes-1.5.1/theme-loaddefs hides /home/ramon/.emacs.d/elpa/modus-themes-20240303.1023/theme-loaddefs
/home/ramon/.emacs.d/elpa/emacsql-sqlite-builtin-20240119.2314/emacsql-sqlite-builtin hides /home/ramon/.emacs.d/elpa/emacsql-20240124.1601/emacsql-sqlite-builtin
/home/ramon/.emacs.d/elpa/transient-20240226.2332/transient hides /home/ramon/Sources/emacs29-bin/share/emacs/29.3.50/lisp/transient
/home/ramon/.emacs.d/elpa/ef-themes-1.5.1/theme-loaddefs hides /home/ramon/Sources/emacs29-bin/share/emacs/29.3.50/lisp/theme-loaddefs
/home/ramon/.emacs.d/elpa/eldoc-1.15.0/eldoc hides /home/ramon/Sources/emacs29-bin/share/emacs/29.3.50/lisp/emacs-lisp/eldoc

Features:
(shadow sort virtual-auto-fill visual-fill-column adaptive-wrap
writegood-mode mail-extr emacsbug message yank-media puny rfc822 mml
mml-sec epa derived epg rfc6068 epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mule-util tramp-cmds dogears
project bookmark text-property-search add-log jinx company-quickhelp
pos-tip hideshowvis rainbow-delimiters hideshow outli org-faces org-keys
oc org-compat org-version org-macs noutline outline symbol-overlay
display-fill-column-indicator hl-line display-line-numbers
company-abbrev company-dabbrev-code company-dabbrev company-keywords
company-files company-semantic company-template company-yasnippet
company-capf company-tng company pcase pixel-scroll cua-base
rdu-miscell-funcs modus-operandi-theme modus-themes
rdu-emacs-fonts-funcs-0 pdf-macs nerd-icons nerd-icons-faces
nerd-icons-data nerd-icons-data-mdicon nerd-icons-data-flicon
nerd-icons-data-codicon nerd-icons-data-devicon nerd-icons-data-sucicon
nerd-icons-data-wicon nerd-icons-data-faicon nerd-icons-data-powerline
nerd-icons-data-octicon nerd-icons-data-pomicon nerd-icons-data-ipsicon
which-func imenu recentf tree-widget vertico-indexed vertico-prescient
prescient char-fold vertico-multiform vertico marginalia helm-mode
helm-misc helm-files image-dired image-dired-tags image-dired-external
image-dired-util xdg image-mode dired-hide-permissions dired
dired-loaddefs exif tramp tramp-loaddefs trampver tramp-integration
files-x tramp-compat shell pcomplete comint ansi-osc parse-time iso8601
time-date helm-buffers all-the-icons all-the-icons-faces data-material
data-weathericons data-octicons data-fileicons data-faicons
data-alltheicons helm-occur helm-tags helm-locate helm-grep helm-regexp
helm-utils helm-help helm-types helm helm-global-bindings helm-core
async-bytecomp helm-source helm-multi-match helm-lib async
flycheck-grammarly grammarly websocket bindat request mailheader
mail-utils s dom exec-path-from-shell flycheck ansi-color find-func
pulsar pulse color hl-todo aggressive-indent shackle trace winner anzu
advice thingatpt savehist yasnippet transient format-spec compat
elec-pair cus-edit pp wid-edit hydra ring lv which-key pdf-loader
edmacro kmacro use-package-bind-key mb-depth comp comp-cstr warnings
icons rx autorevert filenotify time cus-load cl bind-key easy-mmode gcmh
cl-extra help-mode use-package-ensure use-package-core finder-inf info
ace-jump-zap-autoloads ace-jump-mode-autoloads ace-link-autoloads
ace-window-autoloads aggressive-indent-autoloads all-the-icons-autoloads
anaphora-autoloads anki-editor-autoloads anzu-autoloads
atomic-chrome-autoloads avy-autoloads bicycle-autoloads
buffer-move-autoloads burly-autoloads capf-autosuggest-autoloads
casual-autoloads citar-embark-autoloads citar-autoloads
citeproc-autoloads company-auctex-autoloads auctex-autoloads tex-site
company-math-autoloads company-prescient-autoloads
company-quickhelp-autoloads company-reftex-autoloads
company-shell-autoloads company-stan-autoloads
default-text-scale-autoloads deferred-autoloads deft-autoloads
dogears-autoloads dumb-jump-autoloads dwim-shell-command-autoloads
easy-kill-autoloads ef-themes-autoloads eglot-jl-autoloads
eldoc-box-autoloads eldoc-stan-autoloads elisp-demos-autoloads
emacsql-sqlite-builtin-autoloads embark-consult-autoloads
embark-autoloads eshell-syntax-highlighting-autoloads
eshell-vterm-autoloads ess-autoloads exec-path-from-shell-autoloads
expand-region-autoloads flycheck-grammarly-autoloads
flycheck-stan-autoloads flycheck-autoloads
flyspell-correct-helm-autoloads flyspell-correct-autoloads
gcmh-autoloads git-timemachine-autoloads google-this-autoloads
grammarly-autoloads haskell-mode-autoloads helm-bibtex-autoloads
bibtex-completion-autoloads biblio-autoloads biblio-core-autoloads
helm-c-yasnippet-autoloads helm-company-autoloads company-autoloads
helm-descbinds-autoloads helm-mu-autoloads helm-easymenu
helm-swoop-autoloads helm-autoloads helm-core-autoloads
helpful-autoloads elisp-refs-autoloads hide-mode-line-autoloads
highlight-indent-guides-autoloads hl-todo-autoloads hydra-autoloads
iedit-autoloads imenu-anywhere-autoloads jinx-autoloads
julia-repl-autoloads julia-ts-mode-autoloads julia-mode-autoloads
jump-char-autoloads lsp-latex-autoloads consult-autoloads
lsp-ui-autoloads lsp-mode-autoloads eldoc-autoloads lv-autoloads
magit-autoloads git-commit-autoloads marginalia-autoloads
markdown-toc-autoloads math-symbol-lists-autoloads mixed-pitch-autoloads
modus-themes-autoloads multiple-cursors-autoloads nerd-icons-autoloads
orderless-autoloads org-attach-screenshot-autoloads
org-download-autoloads async-autoloads org-modern-autoloads
org-roam-ui-autoloads org-roam-autoloads magit-section-autoloads
emacsql-autoloads org-side-tree-autoloads org-sidebar-autoloads
org-ql-autoloads f-autoloads org-sticky-header-autoloads
org-super-agenda-autoloads ht-autoloads ov-autoloads parsebib-autoloads
pdf-tools-autoloads pdfgrep-autoloads peg-autoloads poly-R-autoloads
poly-markdown-autoloads markdown-mode-autoloads poly-noweb-autoloads
polymode-autoloads popup-autoloads pos-tip-autoloads posframe-autoloads
pulsar-autoloads puni-autoloads queue-autoloads
rainbow-delimiters-autoloads request-autoloads rg-autoloads
rotate-autoloads scratch-autoloads shackle-autoloads
side-hustle-autoloads simple-httpd-autoloads spinner-autoloads
sr-speedbar-autoloads stan-mode-autoloads stream-autoloads
string-inflection-autoloads symbol-overlay-autoloads tablist-autoloads
transient-autoloads transpose-frame-autoloads ts-autoloads s-autoloads
dash-autoloads vertico-prescient-autoloads vertico-autoloads
prescient-autoloads virtual-auto-fill-autoloads adaptive-wrap-autoloads
visual-fill-column-autoloads vterm-autoloads vundo-autoloads
websocket-autoloads wfnames-autoloads wgrep-ag-autoloads wgrep-autoloads
which-key-autoloads whole-line-or-region-autoloads with-editor-autoloads
compat-autoloads workgroups2-autoloads writegood-mode-autoloads
yasnippet-autoloads zmq-autoloads ztree-autoloads package browse-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x
map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads xwidget-internal dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit
xinput2 x multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 484796 318366)
 (symbols 48 30627 9)
 (strings 32 135401 49483)
 (string-bytes 1 4269554)
 (vectors 16 51708)
 (vector-slots 8 1089854 540164)
 (floats 8 1329 1287)
 (intervals 56 825 472)
 (buffers 984 12))


-- 
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-31
Facultad de Medicina 
Universidad Autónoma de Madrid 
Arzobispo Morcillo, 4
28029 Madrid
Spain

Phone: +34-91-497-2412

Email: rdiaz02@gmail.com
       r.diaz@uam.es
       ramon.diaz@iib.uam.es

https://ligarto.org/rdiaz



^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
  2024-03-27 20:25 bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts Ramon Diaz-Uriarte
@ 2024-03-28  5:58 ` Eli Zaretskii
  2024-03-28  7:52   ` Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-03-28 16:12   ` Ramon Diaz-Uriarte
  0 siblings, 2 replies; 21+ messages in thread
From: Eli Zaretskii @ 2024-03-28  5:58 UTC (permalink / raw)
  To: Ramon Diaz-Uriarte; +Cc: rahguzar, 70038

> Cc: Rahguzar <rahguzar@zohomail.eu>, Ramon Diaz-Uriarte <rdiaz02@gmail.com>
> From: Ramon Diaz-Uriarte <rdiaz02@gmail.com>
> Date: Wed, 27 Mar 2024 21:25:34 +0100
> 
> With some fonts, changing focus (M-x other-window) from a buffer with images, makes the content in the buffer with images to shift up and down.
> 
> I am seeing this in Debian, with both the GTK and Lucid builds, under X11.
> 
> The code below reproduces the problem. This problem has been identified while debugging a change on focus issue with pdf-tools (https://github.com/vedang/pdf-tools/pull/224#issuecomment-2014151358 and ff.)

Crystal ball says that this happens because when a frame loses focus,
we redraw the cursor as a hollow rectangle, and (for boring technical
reasons, which I can explain if someone wants to know) that hollow
cursor can have a different height than the block cursor we draw on a
selected frame.  You can verify this guess of mine if you customize
cursor-type to one of the non-default values -- the problem should go
away for any cursor-type but the default one.

If my guess is correct, fixing this is not easy (but patches are
welcome, of course), and at the time I decided to leave this rare case
be.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
  2024-03-28  5:58 ` Eli Zaretskii
@ 2024-03-28  7:52   ` Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-03-28  8:36     ` Eli Zaretskii
  2024-03-28 16:12   ` Ramon Diaz-Uriarte
  1 sibling, 1 reply; 21+ messages in thread
From: Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-28  7:52 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Ramon Diaz-Uriarte, 70038

Hi Eli,

Eli Zaretskii <eliz@gnu.org> writes:

> Crystal ball says that this happens because when a frame loses focus,
> we redraw the cursor as a hollow rectangle, and (for boring technical
> reasons, which I can explain if someone wants to know) that hollow
> cursor can have a different height than the block cursor we draw on a
> selected frame.  You can verify this guess of mine if you customize
> cursor-type to one of the non-default values -- the problem should go
> away for any cursor-type but the default one.
>
> If my guess is correct, fixing this is not easy (but patches are
> welcome, of course), and at the time I decided to leave this rare case
> be.

The original problem where we encountered this the cursor wasn't shown
at all. So I think this might be different. I have been unable to
reproduce it on my machine (it might be because pgtk build doesn't have
this problem) but from what I can tell the problem is that when the
window is not selected the vscroll gets reset to 0 and trying to set it
again seems to have no effect.

In the minimal reproducer there is a pre-redisplay-function that always
sets vscroll for the window to 200. When the window is deselected, the
function runs and Ramon checked by inserting a message that the vscroll
gets reported to be non-zero however the window gets drawn as if the
vscroll was 0. On selecting the window again, it gets redrawn with the
expected value of rescroll and this causes the jumps.

Rahguzar





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
  2024-03-28  7:52   ` Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-28  8:36     ` Eli Zaretskii
  0 siblings, 0 replies; 21+ messages in thread
From: Eli Zaretskii @ 2024-03-28  8:36 UTC (permalink / raw)
  To: Rahguzar; +Cc: 70038

> From: Rahguzar <rahguzar@zohomail.eu>
> Cc: Ramon Diaz-Uriarte <rdiaz02@gmail.com>, 70038@debbugs.gnu.org
> Date: Thu, 28 Mar 2024 08:52:21 +0100
> 
> The original problem where we encountered this the cursor wasn't shown
> at all. So I think this might be different. I have been unable to
> reproduce it on my machine (it might be because pgtk build doesn't have
> this problem) but from what I can tell the problem is that when the
> window is not selected the vscroll gets reset to 0 and trying to set it
> again seems to have no effect.
> 
> In the minimal reproducer there is a pre-redisplay-function that always
> sets vscroll for the window to 200. When the window is deselected, the
> function runs and Ramon checked by inserting a message that the vscroll
> gets reported to be non-zero however the window gets drawn as if the
> vscroll was 0. On selecting the window again, it gets redrawn with the
> expected value of rescroll and this causes the jumps.

In that case, I don't understand what the font has to do with this: if
redisplay resets the window's vscroll, it should always do that, no?
Also, I don't have the fonts you used, so I cannot try the recipe as
is.  I tried a few monospaced fonts I do have, and couldn't reproduce.
A recipe that doesn't depend on rare fonts would be appreciated.
Bonus points for providing a recipe that doesn't depend on fonts at
all.

Thanks.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
  2024-03-28  5:58 ` Eli Zaretskii
  2024-03-28  7:52   ` Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-28 16:12   ` Ramon Diaz-Uriarte
  2024-03-28 16:59     ` Ramon Diaz-Uriarte
  1 sibling, 1 reply; 21+ messages in thread
From: Ramon Diaz-Uriarte @ 2024-03-28 16:12 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rahguzar, rdiaz02, 70038



> In that case, I don't understand what the font has to do with this: if
> redisplay resets the window's vscroll, it should always do that, no?
> Also, I don't have the fonts you used, so I cannot try the recipe as
> is.  I tried a few monospaced fonts I do have, and couldn't reproduce.
> A recipe that doesn't depend on rare fonts would be appreciated.
> Bonus points for providing a recipe that doesn't depend on fonts at
> all.
> 
> Thanks.

I am afraid I don't get the bonus points, because all simple recipes I've found so far depend on fonts (even more, on the "rare fonts", which I use routinely.)

Best,

R.








^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
  2024-03-28 16:12   ` Ramon Diaz-Uriarte
@ 2024-03-28 16:59     ` Ramon Diaz-Uriarte
  2024-03-28 17:24       ` Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 21+ messages in thread
From: Ramon Diaz-Uriarte @ 2024-03-28 16:59 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rahguzar, 70038

Actually, maybe I can claim those bonus points: this does not depend on fonts, though I am triggering it using the package vertico (so maybe this example is vertico's fault):


Steps:

1. emacs -Q
2. eval this code

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(package-initialize)
(vertico-mode 1)

(progn
  (defun pin-vscroll-down (win)
    (set-window-vscroll win 200 t))
   (let* ((height (/ (* 2 (frame-pixel-height)) 15))
         (image1 (create-image "/tmp/image1.png" nil nil :height height))
         (image2 (create-image "/tmp/image2.png" nil nil :height height))
         (image3 (create-image "/tmp/image3.png" nil nil :height height)))
    (with-current-buffer (get-buffer-create "*image-scroll-test*")
      (insert " \n \n \n \n \n \n")
      (put-image image1 1)
      (put-image image2 5)
      (put-image image3 9)
      ;; With larger image sizes (goto-char 3)
      ;; also consistently triggers the problem.
      (goto-char 11)
      (add-hook 'pre-redisplay-functions #'pin-vscroll-down nil t))
    (split-window-right)
    (other-window 1)
    (switch-to-buffer "*image-scroll-test*")))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

3. Do `M-x` (or C-x b). No need to execute anything or switch buffers, just have the minibuffer show options.

4. `C-x o`  a few times. You'll see the images move up and down.

I am seeing this in Lucid and GTK builds.

Best,

R.




On Thu, 28-March-2024, at 17:12:45, Ramon Diaz-Uriarte <rdiaz02@gmail.com> wrote:
>> In that case, I don't understand what the font has to do with this: if
>> redisplay resets the window's vscroll, it should always do that, no?
>> Also, I don't have the fonts you used, so I cannot try the recipe as
>> is.  I tried a few monospaced fonts I do have, and couldn't reproduce.
>> A recipe that doesn't depend on rare fonts would be appreciated.
>> Bonus points for providing a recipe that doesn't depend on fonts at
>> all.
>> 
>> Thanks.
>
> I am afraid I don't get the bonus points, because all simple recipes I've found so far depend on fonts (even more, on the "rare fonts", which I use routinely.)
>
> Best,
>
> R.

-- 
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-31
Facultad de Medicina 
Universidad Autónoma de Madrid 
Arzobispo Morcillo, 4
28029 Madrid
Spain

Phone: +34-91-497-2412

Email: rdiaz02@gmail.com
       r.diaz@uam.es
       ramon.diaz@iib.uam.es

https://ligarto.org/rdiaz



^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
  2024-03-28 16:59     ` Ramon Diaz-Uriarte
@ 2024-03-28 17:24       ` Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-03-28 19:50         ` Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-06 12:33         ` Eli Zaretskii
  0 siblings, 2 replies; 21+ messages in thread
From: Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-28 17:24 UTC (permalink / raw)
  To: Ramon Diaz-Uriarte; +Cc: Eli Zaretskii, 70038

Hi Ramon,

Ramon Diaz-Uriarte <rdiaz02@gmail.com> writes:

> Actually, maybe I can claim those bonus points: this does not depend on fonts, though I am triggering it using the package vertico (so maybe this example is vertico's fault):
>
>
> Steps:
>
> 1. emacs -Q
> 2. eval this code
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> (package-initialize)
> (vertico-mode 1)
>
> (progn
>   (defun pin-vscroll-down (win)
>     (set-window-vscroll win 200 t))
>    (let* ((height (/ (* 2 (frame-pixel-height)) 15))
>          (image1 (create-image "/tmp/image1.png" nil nil :height height))
>          (image2 (create-image "/tmp/image2.png" nil nil :height height))
>          (image3 (create-image "/tmp/image3.png" nil nil :height height)))
>     (with-current-buffer (get-buffer-create "*image-scroll-test*")
>       (insert " \n \n \n \n \n \n")
>       (put-image image1 1)
>       (put-image image2 5)
>       (put-image image3 9)
>       ;; With larger image sizes (goto-char 3)
>       ;; also consistently triggers the problem.
>       (goto-char 11)
>       (add-hook 'pre-redisplay-functions #'pin-vscroll-down nil t))
>     (split-window-right)
>     (other-window 1)
>     (switch-to-buffer "*image-scroll-test*")))
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> 3. Do `M-x` (or C-x b). No need to execute anything or switch buffers, just have the minibuffer show options.
>
> 4. `C-x o`  a few times. You'll see the images move up and down.
>
> I am seeing this in Lucid and GTK builds.

I can also reproduce this now! And vertico mode can be replaced with the
builtin icomplete-vertical-mode. So, the following recipe starting with
emacs -Q works for me:

1) Paste
(let ((height (/ (* 2 (frame-pixel-height)) 15)))
  (icomplete-vertical-mode)
  (defun pin-vscroll-down (win)
    (set-window-vscroll win (/ height 2) t))
  (let ((image1 (create-image "~/Downloads/image1.png" nil nil :height height))
        (image2 (create-image "~/Downloads/image2.png" nil nil :height height))
        (image3 (create-image "~/Downloads/image3.png" nil nil :height height)))
    (with-current-buffer (get-buffer-create "*image-scroll-test*")
      (insert " \n \n \n \n \n \n")
      (put-image image1 1)
      (put-image image2 5)
      (put-image image3 9)
      ;; With larger image sizes (goto-char 3)
      ;; also consistently triggers the problem.
      (goto-char 11)
      (add-hook 'pre-redisplay-functions #'pin-vscroll-down nil t))
    (split-window-right)
    (other-window 1)
    (switch-to-buffer "*image-scroll-test*")))

into scratch buffer.

2) Evaluate the form above using `C-M-x`.

3) Type M-x t

4) Wait till minibuffer expands to show completions, then type `C-g` to
quit minibuffer.

5) Typing `C-x 0` results in the window with images losing vscroll.

> Best,
>
> R.

Rahguzar





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
  2024-03-28 17:24       ` Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-28 19:50         ` Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-03-31 18:43           ` Ramon Diaz-Uriarte
  2024-04-06 12:33         ` Eli Zaretskii
  1 sibling, 1 reply; 21+ messages in thread
From: Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-28 19:50 UTC (permalink / raw)
  To: Rahguzar; +Cc: Ramon Diaz-Uriarte, Eli Zaretskii, 70038

On further testing,

(setq read-minibuffer-restore-windows nil)

makes the problem go away.

Rahguzar <rahguzar@zohomail.eu> writes:

> Hi Ramon,
>
> Ramon Diaz-Uriarte <rdiaz02@gmail.com> writes:
>
>> Actually, maybe I can claim those bonus points: this does not depend on fonts, though I am triggering it using the package vertico (so maybe this example is vertico's fault):
>>
>>
>> Steps:
>>
>> 1. emacs -Q
>> 2. eval this code
>>
>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>> (package-initialize)
>> (vertico-mode 1)
>>
>> (progn
>>   (defun pin-vscroll-down (win)
>>     (set-window-vscroll win 200 t))
>>    (let* ((height (/ (* 2 (frame-pixel-height)) 15))
>>          (image1 (create-image "/tmp/image1.png" nil nil :height height))
>>          (image2 (create-image "/tmp/image2.png" nil nil :height height))
>>          (image3 (create-image "/tmp/image3.png" nil nil :height height)))
>>     (with-current-buffer (get-buffer-create "*image-scroll-test*")
>>       (insert " \n \n \n \n \n \n")
>>       (put-image image1 1)
>>       (put-image image2 5)
>>       (put-image image3 9)
>>       ;; With larger image sizes (goto-char 3)
>>       ;; also consistently triggers the problem.
>>       (goto-char 11)
>>       (add-hook 'pre-redisplay-functions #'pin-vscroll-down nil t))
>>     (split-window-right)
>>     (other-window 1)
>>     (switch-to-buffer "*image-scroll-test*")))
>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>>
>> 3. Do `M-x` (or C-x b). No need to execute anything or switch buffers, just have the minibuffer show options.
>>
>> 4. `C-x o`  a few times. You'll see the images move up and down.
>>
>> I am seeing this in Lucid and GTK builds.
>
> I can also reproduce this now! And vertico mode can be replaced with the
> builtin icomplete-vertical-mode. So, the following recipe starting with
> emacs -Q works for me:
>
> 1) Paste
> (let ((height (/ (* 2 (frame-pixel-height)) 15)))
>   (icomplete-vertical-mode)
>   (defun pin-vscroll-down (win)
>     (set-window-vscroll win (/ height 2) t))
>   (let ((image1 (create-image "~/Downloads/image1.png" nil nil :height height))
>         (image2 (create-image "~/Downloads/image2.png" nil nil :height height))
>         (image3 (create-image "~/Downloads/image3.png" nil nil :height height)))
>     (with-current-buffer (get-buffer-create "*image-scroll-test*")
>       (insert " \n \n \n \n \n \n")
>       (put-image image1 1)
>       (put-image image2 5)
>       (put-image image3 9)
>       ;; With larger image sizes (goto-char 3)
>       ;; also consistently triggers the problem.
>       (goto-char 11)
>       (add-hook 'pre-redisplay-functions #'pin-vscroll-down nil t))
>     (split-window-right)
>     (other-window 1)
>     (switch-to-buffer "*image-scroll-test*")))
>
> into scratch buffer.
>
> 2) Evaluate the form above using `C-M-x`.
>
> 3) Type M-x t
>
> 4) Wait till minibuffer expands to show completions, then type `C-g` to
> quit minibuffer.
>
> 5) Typing `C-x 0` results in the window with images losing vscroll.
>
>> Best,
>>
>> R.
>
> Rahguzar





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
  2024-03-28 19:50         ` Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-31 18:43           ` Ramon Diaz-Uriarte
  0 siblings, 0 replies; 21+ messages in thread
From: Ramon Diaz-Uriarte @ 2024-03-31 18:43 UTC (permalink / raw)
  To: Rahguzar; +Cc: Ramon Diaz-Uriarte, Eli Zaretskii, 70038


For me, this setting fixes the problem when there is no dependence on fonts:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(setq read-minibuffer-restore-windows nil)
(progn
  (defun pin-vscroll-down (win)
    (set-window-vscroll win 200 t))
   (let* ((height (/ (* 2 (frame-pixel-height)) 5))
         (image1 (create-image "/tmp/image1.png" nil nil :height height))
         (image2 (create-image "/tmp/image2.png" nil nil :height height))
         (image3 (create-image "/tmp/image3.png" nil nil :height height)))
    (with-current-buffer (get-buffer-create "*image-scroll-test*")
      (insert " \n \n \n \n \n \n")
      (put-image image1 1)
      (put-image image2 5)
      (put-image image3 9)
      ;; With larger image sizes (goto-char 3)
      ;; also consistently triggers the problem.
      (goto-char 11)
      (add-hook 'pre-redisplay-functions #'pin-vscroll-down nil t))
    (split-window-right)
    (other-window 1)
    (switch-to-buffer "*image-scroll-test*")))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;


However, it does not solve the problem when I change fonts:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(setq read-minibuffer-restore-windows nil)
(progn
  (defun pin-vscroll-down (win)
    (set-window-vscroll win 200 t))
  ;; Any of the following leads to the bug
  (set-frame-font "JuliaMono" nil t)
  ;; (set-frame-font "DM Mono" nil t)
  ;; (set-frame-font "Intel One Mono" nil t)
  (let* ((height (/ (* 2 (frame-pixel-height)) 15))
         (image1 (create-image "/tmp/image1.png" nil nil :height height))
         (image2 (create-image "/tmp/image2.png" nil nil :height height))
         (image3 (create-image "/tmp/image3.png" nil nil :height height)))
    (with-current-buffer (get-buffer-create "*image-scroll-test*")
      (insert " \n \n \n \n \n \n")
      (put-image image1 1)
      (put-image image2 5)
      (put-image image3 9)
      ;; With larger image sizes (goto-char 3)
      ;; also triggers the problem.
      (goto-char 11)
      (add-hook 'pre-redisplay-functions #'pin-vscroll-down nil t))
    (split-window-right)
    (other-window 1)
    (switch-to-buffer "*image-scroll-test*")))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;


As mentioned initially, this issue was found when trying to solve a similar problem with pdf-tools: https://github.com/vedang/pdf-tools/pull/224#issuecomment-2014151358

Setting

(setq read-minibuffer-restore-windows nil)

solves the pdf-tools continuous scrolling issue when there is no change in font but not when we change font (https://github.com/vedang/pdf-tools/pull/224#issuecomment-2026142343 )


Best,

R.




On Thu, 28-March-2024, at 21:50:49, Rahguzar <rahguzar@zohomail.eu> wrote:
> On further testing,
>
> (setq read-minibuffer-restore-windows nil)
>
> makes the problem go away.
>
> Rahguzar <rahguzar@zohomail.eu> writes:
>
>> Hi Ramon,
>>
>> Ramon Diaz-Uriarte <rdiaz02@gmail.com> writes:
>>
>>> Actually, maybe I can claim those bonus points: this does not depend on fonts, though I am triggering it using the package vertico (so maybe this example is vertico's fault):
>>>
>>>
>>> Steps:
>>>
>>> 1. emacs -Q
>>> 2. eval this code
>>>
>>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>>> (package-initialize)
>>> (vertico-mode 1)
>>>
>>> (progn
>>>   (defun pin-vscroll-down (win)
>>>     (set-window-vscroll win 200 t))
>>>    (let* ((height (/ (* 2 (frame-pixel-height)) 15))
>>>          (image1 (create-image "/tmp/image1.png" nil nil :height height))
>>>          (image2 (create-image "/tmp/image2.png" nil nil :height height))
>>>          (image3 (create-image "/tmp/image3.png" nil nil :height height)))
>>>     (with-current-buffer (get-buffer-create "*image-scroll-test*")
>>>       (insert " \n \n \n \n \n \n")
>>>       (put-image image1 1)
>>>       (put-image image2 5)
>>>       (put-image image3 9)
>>>       ;; With larger image sizes (goto-char 3)
>>>       ;; also consistently triggers the problem.
>>>       (goto-char 11)
>>>       (add-hook 'pre-redisplay-functions #'pin-vscroll-down nil t))
>>>     (split-window-right)
>>>     (other-window 1)
>>>     (switch-to-buffer "*image-scroll-test*")))
>>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>>>
>>> 3. Do `M-x` (or C-x b). No need to execute anything or switch buffers, just have the minibuffer show options.
>>>
>>> 4. `C-x o`  a few times. You'll see the images move up and down.
>>>
>>> I am seeing this in Lucid and GTK builds.
>>
>> I can also reproduce this now! And vertico mode can be replaced with the
>> builtin icomplete-vertical-mode. So, the following recipe starting with
>> emacs -Q works for me:
>>
>> 1) Paste
>> (let ((height (/ (* 2 (frame-pixel-height)) 15)))
>>   (icomplete-vertical-mode)
>>   (defun pin-vscroll-down (win)
>>     (set-window-vscroll win (/ height 2) t))
>>   (let ((image1 (create-image "~/Downloads/image1.png" nil nil :height height))
>>         (image2 (create-image "~/Downloads/image2.png" nil nil :height height))
>>         (image3 (create-image "~/Downloads/image3.png" nil nil :height height)))
>>     (with-current-buffer (get-buffer-create "*image-scroll-test*")
>>       (insert " \n \n \n \n \n \n")
>>       (put-image image1 1)
>>       (put-image image2 5)
>>       (put-image image3 9)
>>       ;; With larger image sizes (goto-char 3)
>>       ;; also consistently triggers the problem.
>>       (goto-char 11)
>>       (add-hook 'pre-redisplay-functions #'pin-vscroll-down nil t))
>>     (split-window-right)
>>     (other-window 1)
>>     (switch-to-buffer "*image-scroll-test*")))
>>
>> into scratch buffer.
>>
>> 2) Evaluate the form above using `C-M-x`.
>>
>> 3) Type M-x t
>>
>> 4) Wait till minibuffer expands to show completions, then type `C-g` to
>> quit minibuffer.
>>
>> 5) Typing `C-x 0` results in the window with images losing vscroll.
>>
>>> Best,
>>>
>>> R.
>>
>> Rahguzar

-- 
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-31
Facultad de Medicina 
Universidad Autónoma de Madrid 
Arzobispo Morcillo, 4
28029 Madrid
Spain


^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
  2024-03-28 17:24       ` Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-03-28 19:50         ` Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-06 12:33         ` Eli Zaretskii
  2024-04-06 14:08           ` Eli Zaretskii
  2024-04-11 13:56           ` Ramon Diaz-Uriarte
  1 sibling, 2 replies; 21+ messages in thread
From: Eli Zaretskii @ 2024-04-06 12:33 UTC (permalink / raw)
  To: Ramon Diaz-Uriarte, Po Lu; +Cc: Rahguzar, rdiaz02, 70038

> From: Rahguzar <rahguzar@zohomail.eu>
> Cc: Eli Zaretskii <eliz@gnu.org>, 70038@debbugs.gnu.org
> Date: Thu, 28 Mar 2024 18:24:32 +0100
> 
> I can also reproduce this now! And vertico mode can be replaced with the
> builtin icomplete-vertical-mode. So, the following recipe starting with
> emacs -Q works for me:
> 
> 1) Paste
> (let ((height (/ (* 2 (frame-pixel-height)) 15)))
>   (icomplete-vertical-mode)
>   (defun pin-vscroll-down (win)
>     (set-window-vscroll win (/ height 2) t))
>   (let ((image1 (create-image "~/Downloads/image1.png" nil nil :height height))
>         (image2 (create-image "~/Downloads/image2.png" nil nil :height height))
>         (image3 (create-image "~/Downloads/image3.png" nil nil :height height)))
>     (with-current-buffer (get-buffer-create "*image-scroll-test*")
>       (insert " \n \n \n \n \n \n")
>       (put-image image1 1)
>       (put-image image2 5)
>       (put-image image3 9)
>       ;; With larger image sizes (goto-char 3)
>       ;; also consistently triggers the problem.
>       (goto-char 11)
>       (add-hook 'pre-redisplay-functions #'pin-vscroll-down nil t))
>     (split-window-right)
>     (other-window 1)
>     (switch-to-buffer "*image-scroll-test*")))
> 
> into scratch buffer.
> 
> 2) Evaluate the form above using `C-M-x`.
> 
> 3) Type M-x t
> 
> 4) Wait till minibuffer expands to show completions, then type `C-g` to
> quit minibuffer.
> 
> 5) Typing `C-x 0` results in the window with images losing vscroll.

Po Lu, I'm looking at this part of redisplay_window:

   force_start:

    /* Handle case where place to start displaying has been specified,
       unless the specified location is outside the accessible range.  */
    if (w->force_start)
      {
	/* We set this later on if we have to adjust point.  */
	int new_vpos = -1;

	w->force_start = false;

	/* The vscroll should be preserved in this case, since
	   `pixel-scroll-precision-mode' must continue working normally
	   when a mini-window is resized.  (bug#55312) */
	if (!w->preserve_vscroll_p || !window_frozen_p (w))  <<<<<<<<<<<<<<<
	  w->vscroll = 0;

	w->preserve_vscroll_p = false;
	w->window_end_valid = false;

where you added the condition for resetting w->vscroll in commit
fd8eaa72a61, and I'm thinking that perhaps the condition should be

	if (!w->preserve_vscroll_p && !window_frozen_p (w))

instead?  If not, can you explain why we use OR and not AND there?

Ramon, if you replace "||" with "&&" in the above condition, does the
problem go away for you also when you change fonts, as you described
in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70038#29 ?





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
  2024-04-06 12:33         ` Eli Zaretskii
@ 2024-04-06 14:08           ` Eli Zaretskii
  2024-04-06 14:20             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-07  8:24             ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-11 13:56           ` Ramon Diaz-Uriarte
  1 sibling, 2 replies; 21+ messages in thread
From: Eli Zaretskii @ 2024-04-06 14:08 UTC (permalink / raw)
  To: martin rudalics; +Cc: luangruo, rahguzar, r.diaz, rdiaz02, 70038

> Cc: Rahguzar <rahguzar@zohomail.eu>, rdiaz02@gmail.com, 70038@debbugs.gnu.org
> Date: Sat, 06 Apr 2024 15:33:59 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Rahguzar <rahguzar@zohomail.eu>
> > Cc: Eli Zaretskii <eliz@gnu.org>, 70038@debbugs.gnu.org
> > Date: Thu, 28 Mar 2024 18:24:32 +0100
> > 
> > I can also reproduce this now! And vertico mode can be replaced with the
> > builtin icomplete-vertical-mode. So, the following recipe starting with
> > emacs -Q works for me:
> > 
> > 1) Paste
> > (let ((height (/ (* 2 (frame-pixel-height)) 15)))
> >   (icomplete-vertical-mode)
> >   (defun pin-vscroll-down (win)
> >     (set-window-vscroll win (/ height 2) t))
> >   (let ((image1 (create-image "~/Downloads/image1.png" nil nil :height height))
> >         (image2 (create-image "~/Downloads/image2.png" nil nil :height height))
> >         (image3 (create-image "~/Downloads/image3.png" nil nil :height height)))
> >     (with-current-buffer (get-buffer-create "*image-scroll-test*")
> >       (insert " \n \n \n \n \n \n")
> >       (put-image image1 1)
> >       (put-image image2 5)
> >       (put-image image3 9)
> >       ;; With larger image sizes (goto-char 3)
> >       ;; also consistently triggers the problem.
> >       (goto-char 11)
> >       (add-hook 'pre-redisplay-functions #'pin-vscroll-down nil t))
> >     (split-window-right)
> >     (other-window 1)
> >     (switch-to-buffer "*image-scroll-test*")))
> > 
> > into scratch buffer.
> > 
> > 2) Evaluate the form above using `C-M-x`.
> > 
> > 3) Type M-x t
> > 
> > 4) Wait till minibuffer expands to show completions, then type `C-g` to
> > quit minibuffer.
> > 
> > 5) Typing `C-x 0` results in the window with images losing vscroll.
> 
> Po Lu, I'm looking at this part of redisplay_window:
> 
>    force_start:
> 
>     /* Handle case where place to start displaying has been specified,
>        unless the specified location is outside the accessible range.  */
>     if (w->force_start)
>       {
> 	/* We set this later on if we have to adjust point.  */
> 	int new_vpos = -1;
> 
> 	w->force_start = false;
> 
> 	/* The vscroll should be preserved in this case, since
> 	   `pixel-scroll-precision-mode' must continue working normally
> 	   when a mini-window is resized.  (bug#55312) */
> 	if (!w->preserve_vscroll_p || !window_frozen_p (w))  <<<<<<<<<<<<<<<
> 	  w->vscroll = 0;
> 
> 	w->preserve_vscroll_p = false;
> 	w->window_end_valid = false;
> 
> where you added the condition for resetting w->vscroll in commit
> fd8eaa72a61, and I'm thinking that perhaps the condition should be
> 
> 	if (!w->preserve_vscroll_p && !window_frozen_p (w))
> 
> instead?  If not, can you explain why we use OR and not AND there?
> 
> Ramon, if you replace "||" with "&&" in the above condition, does the
> problem go away for you also when you change fonts, as you described
> in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70038#29 ?

There's one more aspect of this that bothers me: when we resize the
mini-window, we set the frame's frozen_window_starts flag, but we seem
to never reset it.

Martin, can you help out here?  I don't see shrink_mini_window being
called with non-zero DELTA anywhere, including when the mini-window is
exited and is resized to its normal one-line height.  Instead, this
resizing is performed by restore_window_configuration, called from
read_minibuf, but I don't see FRAME_WINDOWS_FROZEN being reset
anywhere there.  I don't think it's correct for us to leave the
frame's frozen_window_starts flag set forever once it was raised, so I
guess we should do something in minibuffer_unwind to reset that flag?





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
  2024-04-06 14:08           ` Eli Zaretskii
@ 2024-04-06 14:20             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-07  8:24             ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 0 replies; 21+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-06 14:20 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: martin rudalics, r.diaz, 70038, rdiaz02, rahguzar

Eli Zaretskii <eliz@gnu.org> writes:

>> Po Lu, I'm looking at this part of redisplay_window:
>> 
>>    force_start:
>> 
>>     /* Handle case where place to start displaying has been specified,
>>        unless the specified location is outside the accessible range.  */
>>     if (w->force_start)
>>       {
>> 	/* We set this later on if we have to adjust point.  */
>> 	int new_vpos = -1;
>> 
>> 	w->force_start = false;
>> 
>> 	/* The vscroll should be preserved in this case, since
>> 	   `pixel-scroll-precision-mode' must continue working normally
>> 	   when a mini-window is resized.  (bug#55312) */
>> 	if (!w->preserve_vscroll_p || !window_frozen_p (w))  <<<<<<<<<<<<<<<
>> 	  w->vscroll = 0;
>> 
>> 	w->preserve_vscroll_p = false;
>> 	w->window_end_valid = false;
>> 
>> where you added the condition for resetting w->vscroll in commit
>> fd8eaa72a61, and I'm thinking that perhaps the condition should be
>> 
>> 	if (!w->preserve_vscroll_p && !window_frozen_p (w))
>> 
>> instead?  If not, can you explain why we use OR and not AND there?

I think you are correct.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
  2024-04-06 14:08           ` Eli Zaretskii
  2024-04-06 14:20             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-07  8:24             ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-07  9:13               ` Eli Zaretskii
  1 sibling, 1 reply; 21+ messages in thread
From: martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-07  8:24 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: luangruo, rahguzar, r.diaz, rdiaz02, 70038

 > There's one more aspect of this that bothers me: when we resize the
 > mini-window, we set the frame's frozen_window_starts flag, but we seem
 > to never reset it.
 >
 > Martin, can you help out here?  I don't see shrink_mini_window being
 > called with non-zero DELTA anywhere, including when the mini-window is
 > exited and is resized to its normal one-line height.  Instead, this
 > resizing is performed by restore_window_configuration, called from
 > read_minibuf, but I don't see FRAME_WINDOWS_FROZEN being reset
 > anywhere there.  I don't think it's correct for us to leave the
 > frame's frozen_window_starts flag set forever once it was raised,

Just for the record: Here I once used a version of shrink_mini_window
that went as

/** Shrink mini-window W to its minimum height.  */
void
shrink_mini_window (struct window *w)
{
   /* Just attempt to shrink it to zero, grow_mini_window makes sure it
      does not get to small.  */
   FRAME_WINDOWS_FROZEN (WINDOW_XFRAME (w)) = false;
   grow_mini_window (w, -WINDOW_PIXEL_HEIGHT (w));
}

where grow_mini_window took care of the rest.  But I don't call
shrink_mini_window any more and so the flag remains stuck here as well.

 > so I
 > guess we should do something in minibuffer_unwind to reset that flag?

Would that be sufficient?  Don't we freeze also when resizing the echo
area?

martin





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
  2024-04-07  8:24             ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-07  9:13               ` Eli Zaretskii
  2024-04-07 10:12                 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2024-04-07  9:13 UTC (permalink / raw)
  To: martin rudalics; +Cc: luangruo, rahguzar, r.diaz, rdiaz02, 70038

> Date: Sun, 7 Apr 2024 10:24:29 +0200
> Cc: r.diaz@uam.es, luangruo@yahoo.com, rahguzar@zohomail.eu,
>  rdiaz02@gmail.com, 70038@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  > so I
>  > guess we should do something in minibuffer_unwind to reset that flag?
> 
> Would that be sufficient?  Don't we freeze also when resizing the echo
> area?

I guess we do, but where is that resized back to its normal height?





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
  2024-04-07  9:13               ` Eli Zaretskii
@ 2024-04-07 10:12                 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-07 11:28                   ` Eli Zaretskii
  0 siblings, 1 reply; 21+ messages in thread
From: martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-07 10:12 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: luangruo, rahguzar, r.diaz, rdiaz02, 70038

 >> Would that be sufficient?  Don't we freeze also when resizing the echo
 >> area?
 >
 > I guess we do, but where is that resized back to its normal height?

In shrink_mini_window hopefully so this should be covered.  If the only
problem is that of restore_window_configuration, then minibuffer_unwind
looks like the right place.  But maybe read_char_help_form_unwind would
require the same treatment.

martin





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
  2024-04-07 10:12                 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-07 11:28                   ` Eli Zaretskii
  2024-04-08  9:07                     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2024-04-07 11:28 UTC (permalink / raw)
  To: martin rudalics; +Cc: luangruo, rahguzar, r.diaz, rdiaz02, 70038

> Date: Sun, 7 Apr 2024 12:12:55 +0200
> Cc: r.diaz@uam.es, luangruo@yahoo.com, rahguzar@zohomail.eu,
>  rdiaz02@gmail.com, 70038@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  >> Would that be sufficient?  Don't we freeze also when resizing the echo
>  >> area?
>  >
>  > I guess we do, but where is that resized back to its normal height?
> 
> In shrink_mini_window hopefully so this should be covered.  If the only
> problem is that of restore_window_configuration, then minibuffer_unwind
> looks like the right place.  But maybe read_char_help_form_unwind would
> require the same treatment.

Hmm...  read_char_help_form_unwind is called after we invoke
help-form-show, and that one pops up a special buffer:

  (defun help-form-show ()
    "Display the output of a non-nil `help-form'."
    (let ((msg (eval help-form t)))
      (if (stringp msg)
	  (with-output-to-temp-buffer " *Char Help*"
	    (princ msg)))))

Is there a way to make that use the echo-area? if so, can you tell how
to do that?





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
  2024-04-07 11:28                   ` Eli Zaretskii
@ 2024-04-08  9:07                     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-13 10:10                       ` Eli Zaretskii
  0 siblings, 1 reply; 21+ messages in thread
From: martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-08  9:07 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: luangruo, rahguzar, r.diaz, rdiaz02, 70038

IIUC the basic idea of all this is to preserve window start positions
when enlarging a mini window unless that would move a window's point
outside that window.  Once upon a time, resize_mini_window used window
configurations to get back the previous start positions but that was
maybe considered too costly and Gerd decided to "Don't save window
configuration, freeze window starts instead."

A possibly heretical question is in which way freezing start positions
permanently can harm.  IIUC, after a minibuffer interaction, currently
the only way to unfreeze start positions is to resize the minibuffer
window and trigger the corresponding call in shrink_mini_window.  But
setting the start position of any window while a minibuffer interaction
is going on seems to work here without problems.

Let's assume it can harm:

 >> If the only
 >> problem is that of restore_window_configuration, then minibuffer_unwind
 >> looks like the right place.

That was silly.  minibuffer_unwind seems to care only about replacing
one minibuffer with another.  read_minibuf_unwind already should handle
this here (don't ask me what a future_mini_window is)

   /* When we get to the outmost level, make sure we resize the
      mini-window back to its normal size.  */
   if (minibuf_level == 0
       || !EQ (selected_frame, WINDOW_FRAME (XWINDOW (future_mini_window))))
     resize_mini_window (XWINDOW (minibuf_window), 0);

The only problem is that if the mini window was _not_ enlarged,
shrink_mini_window won't unfreeze starts.  Unconditionally unfreezing
start positions there as I mentioned in my first mail should fix that.

 > Hmm...  read_char_help_form_unwind is called after we invoke
 > help-form-show, and that one pops up a special buffer:
 >
 >    (defun help-form-show ()
 >      "Display the output of a non-nil `help-form'."
 >      (let ((msg (eval help-form t)))
 >        (if (stringp msg)
 > 	  (with-output-to-temp-buffer " *Char Help*"
 > 	    (princ msg)))))
 >
 > Is there a way to make that use the echo-area? if so, can you tell how
 > to do that?

IIUC that is called in a situation where the minibuffer is active.
Showing that text in the echo area (albeit shortly) doesn't look like
TRT to me.

IIUC read_char can resize the mini window here

	  if (minibuf_level
	      && EQ (minibuf_window, echo_area_window)
	      /* The case where minibuffer-message-timeout is a number
		 was already handled near the beginning of command_loop_1.  */
	      && !NUMBERP (Vminibuffer_message_timeout))
	    resize_mini_window (XWINDOW (minibuf_window), false);

so this should be covered by read_minibuf_unwind already.

martin





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
  2024-04-06 12:33         ` Eli Zaretskii
  2024-04-06 14:08           ` Eli Zaretskii
@ 2024-04-11 13:56           ` Ramon Diaz-Uriarte
  2024-04-11 15:36             ` Eli Zaretskii
  1 sibling, 1 reply; 21+ messages in thread
From: Ramon Diaz-Uriarte @ 2024-04-11 13:56 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Po Lu, Rahguzar, rdiaz02, 70038

Sorry, I did not see this.

On Sat, 06-April-2024, at 14:33:59, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Rahguzar <rahguzar@zohomail.eu>
>> Cc: Eli Zaretskii <eliz@gnu.org>, 70038@debbugs.gnu.org
>> Date: Thu, 28 Mar 2024 18:24:32 +0100
>> 
>> I can also reproduce this now! And vertico mode can be replaced with the
>> builtin icomplete-vertical-mode. So, the following recipe starting with
>> emacs -Q works for me:
>> 
>> 1) Paste
>> (let ((height (/ (* 2 (frame-pixel-height)) 15)))
>>   (icomplete-vertical-mode)
>>   (defun pin-vscroll-down (win)
>>     (set-window-vscroll win (/ height 2) t))
>>   (let ((image1 (create-image "~/Downloads/image1.png" nil nil :height height))
>>         (image2 (create-image "~/Downloads/image2.png" nil nil :height height))
>>         (image3 (create-image "~/Downloads/image3.png" nil nil :height height)))
>>     (with-current-buffer (get-buffer-create "*image-scroll-test*")
>>       (insert " \n \n \n \n \n \n")
>>       (put-image image1 1)
>>       (put-image image2 5)
>>       (put-image image3 9)
>>       ;; With larger image sizes (goto-char 3)
>>       ;; also consistently triggers the problem.
>>       (goto-char 11)
>>       (add-hook 'pre-redisplay-functions #'pin-vscroll-down nil t))
>>     (split-window-right)
>>     (other-window 1)
>>     (switch-to-buffer "*image-scroll-test*")))
>> 
>> into scratch buffer.
>> 
>> 2) Evaluate the form above using `C-M-x`.
>> 
>> 3) Type M-x t
>> 
>> 4) Wait till minibuffer expands to show completions, then type `C-g` to
>> quit minibuffer.
>> 
>> 5) Typing `C-x 0` results in the window with images losing vscroll.
>
> Po Lu, I'm looking at this part of redisplay_window:
>
>    force_start:
>
>     /* Handle case where place to start displaying has been specified,
>        unless the specified location is outside the accessible range.  */
>     if (w->force_start)
>       {
> 	/* We set this later on if we have to adjust point.  */
> 	int new_vpos = -1;
>
> 	w->force_start = false;
>
> 	/* The vscroll should be preserved in this case, since
> 	   `pixel-scroll-precision-mode' must continue working normally
> 	   when a mini-window is resized.  (bug#55312) */
> 	if (!w->preserve_vscroll_p || !window_frozen_p (w))  <<<<<<<<<<<<<<<
> 	  w->vscroll = 0;
>
> 	w->preserve_vscroll_p = false;
> 	w->window_end_valid = false;
>
> where you added the condition for resetting w->vscroll in commit
> fd8eaa72a61, and I'm thinking that perhaps the condition should be
>
> 	if (!w->preserve_vscroll_p && !window_frozen_p (w))
>
> instead?  If not, can you explain why we use OR and not AND there?
>
> Ramon, if you replace "||" with "&&" in the above condition, does the
> problem go away for you also when you change fonts, as you described
> in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70038#29 ?


Yes: 
the problem goes away (and I do not need to use
(setq read-minibuffer-restore-windows nil)
).

Moreover, the original problem with pdf-tools that lead this bug report (https://github.com/vedang/pdf-tools/pull/224?notification_referrer_id=NT_kwDOABnEI7I3MDQyMzY2MDYwOjE2ODg2MTE#issuecomment-2014151358) also goes away.

Best,

R.

-- 
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-31
Facultad de Medicina 
Universidad Autónoma de Madrid 
Arzobispo Morcillo, 4
28029 Madrid
Spain




^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
  2024-04-11 13:56           ` Ramon Diaz-Uriarte
@ 2024-04-11 15:36             ` Eli Zaretskii
  2024-04-12 16:43               ` Ramon Diaz-Uriarte
  0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2024-04-11 15:36 UTC (permalink / raw)
  To: Ramon Diaz-Uriarte; +Cc: luangruo, rahguzar, rdiaz02, 70038

> From: Ramon Diaz-Uriarte <r.diaz@uam.es>
> Cc: Po Lu <luangruo@yahoo.com>,  rdiaz02@gmail.com,  Rahguzar
>  <rahguzar@zohomail.eu>,  70038@debbugs.gnu.org
> Date: Thu, 11 Apr 2024 15:56:30 +0200
> 
> Sorry, I did not see this.

No sweat.

> On Sat, 06-April-2024, at 14:33:59, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Rahguzar <rahguzar@zohomail.eu>
> >> Cc: Eli Zaretskii <eliz@gnu.org>, 70038@debbugs.gnu.org
> >> Date: Thu, 28 Mar 2024 18:24:32 +0100
> >> 
> > Ramon, if you replace "||" with "&&" in the above condition, does the
> > problem go away for you also when you change fonts, as you described
> > in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70038#29 ?
> 
> 
> Yes: 
> the problem goes away (and I do not need to use
> (setq read-minibuffer-restore-windows nil)
> ).
> 
> Moreover, the original problem with pdf-tools that lead this bug report (https://github.com/vedang/pdf-tools/pull/224?notification_referrer_id=NT_kwDOABnEI7I3MDQyMzY2MDYwOjE2ODg2MTE#issuecomment-2014151358) also goes away.

Thanks for testing.  So I've now installed this change on the emacs-29
branch (soon to be merged to master).





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
  2024-04-11 15:36             ` Eli Zaretskii
@ 2024-04-12 16:43               ` Ramon Diaz-Uriarte
  0 siblings, 0 replies; 21+ messages in thread
From: Ramon Diaz-Uriarte @ 2024-04-12 16:43 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: luangruo, rahguzar, Ramon Diaz-Uriarte, 70038



On Thu, 11-April-2024, at 17:36:48, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Ramon Diaz-Uriarte <r.diaz@uam.es>
>> Cc: Po Lu <luangruo@yahoo.com>,  rdiaz02@gmail.com,  Rahguzar
>>  <rahguzar@zohomail.eu>,  70038@debbugs.gnu.org
>> Date: Thu, 11 Apr 2024 15:56:30 +0200
>>
>> Sorry, I did not see this.
>
> No sweat.
>
>> On Sat, 06-April-2024, at 14:33:59, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> From: Rahguzar <rahguzar@zohomail.eu>
>> >> Cc: Eli Zaretskii <eliz@gnu.org>, 70038@debbugs.gnu.org
>> >> Date: Thu, 28 Mar 2024 18:24:32 +0100
>> >>
>> > Ramon, if you replace "||" with "&&" in the above condition, does the
>> > problem go away for you also when you change fonts, as you described
>> > in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70038#29 ?
>>
>>
>> Yes:
>> the problem goes away (and I do not need to use
>> (setq read-minibuffer-restore-windows nil)
>> ).
>>
>> Moreover, the original problem with pdf-tools that lead this bug report
>> (https://github.com/vedang/pdf-tools/pull/224?notification_referrer_id=NT_kwDOABnEI7I3MDQyMzY2MDYwOjE2ODg2MTE#issuecomment-2014151358)
>> also goes away.
>
> Thanks for testing.  So I've now installed this change on the emacs-29
> branch (soon to be merged to master).


Thanks you!!

--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-31
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain

^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
  2024-04-08  9:07                     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-13 10:10                       ` Eli Zaretskii
  0 siblings, 0 replies; 21+ messages in thread
From: Eli Zaretskii @ 2024-04-13 10:10 UTC (permalink / raw)
  To: martin rudalics; +Cc: luangruo, 70038

> Date: Mon, 8 Apr 2024 11:07:50 +0200
> Cc: r.diaz@uam.es, luangruo@yahoo.com, rahguzar@zohomail.eu,
>  rdiaz02@gmail.com, 70038@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
> A possibly heretical question is in which way freezing start positions
> permanently can harm.  IIUC, after a minibuffer interaction, currently
> the only way to unfreeze start positions is to resize the minibuffer
> window and trigger the corresponding call in shrink_mini_window.  But
> setting the start position of any window while a minibuffer interaction
> is going on seems to work here without problems.

The (slight) harm this does is that it might make redisplay of the
window slightly more expensive, because it disables some
optimizations, like if nothing changed except the position of point.
Another kind of harm is what triggered this bug report: it could cause
us to reset the window's vscroll for now good reason, because when
start positions are frozen, we set the window's force_start flag, and
that sometimes forces us to reset vscroll.

> That was silly.  minibuffer_unwind seems to care only about replacing
> one minibuffer with another.  read_minibuf_unwind already should handle
> this here (don't ask me what a future_mini_window is)
> 
>    /* When we get to the outmost level, make sure we resize the
>       mini-window back to its normal size.  */
>    if (minibuf_level == 0
>        || !EQ (selected_frame, WINDOW_FRAME (XWINDOW (future_mini_window))))
>      resize_mini_window (XWINDOW (minibuf_window), 0);
> 
> The only problem is that if the mini window was _not_ enlarged,
> shrink_mini_window won't unfreeze starts.  Unconditionally unfreezing
> start positions there as I mentioned in my first mail should fix that.

Thanks.

So the patch below is the only change we need to make sure the frame's
frozen_window_starts is reset when the mini-window is resized back?

Should it matter whether, if the minibuffer is active, we do that only
at the outer level of minibuffer?

diff --git a/src/window.c b/src/window.c
index fe26311..0945b24 100644
--- a/src/window.c
+++ b/src/window.c
@@ -5407,13 +5407,13 @@ shrink_mini_window (struct window *w)
 
   eassert (MINI_WINDOW_P (w));
 
+  FRAME_WINDOWS_FROZEN (f) = false;
   if (delta > 0)
     {
       Lisp_Object root = FRAME_ROOT_WINDOW (f);
       struct window *r = XWINDOW (root);
       Lisp_Object grow;
 
-      FRAME_WINDOWS_FROZEN (f) = false;
       grow = call3 (Qwindow__resize_root_window_vertically,
 		    root, make_fixnum (delta), Qt);
 





^ permalink raw reply related	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2024-04-13 10:10 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-27 20:25 bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts Ramon Diaz-Uriarte
2024-03-28  5:58 ` Eli Zaretskii
2024-03-28  7:52   ` Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28  8:36     ` Eli Zaretskii
2024-03-28 16:12   ` Ramon Diaz-Uriarte
2024-03-28 16:59     ` Ramon Diaz-Uriarte
2024-03-28 17:24       ` Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 19:50         ` Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-31 18:43           ` Ramon Diaz-Uriarte
2024-04-06 12:33         ` Eli Zaretskii
2024-04-06 14:08           ` Eli Zaretskii
2024-04-06 14:20             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07  8:24             ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07  9:13               ` Eli Zaretskii
2024-04-07 10:12                 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 11:28                   ` Eli Zaretskii
2024-04-08  9:07                     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-13 10:10                       ` Eli Zaretskii
2024-04-11 13:56           ` Ramon Diaz-Uriarte
2024-04-11 15:36             ` Eli Zaretskii
2024-04-12 16:43               ` Ramon Diaz-Uriarte

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).