From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 04 11:14:40 2025 Received: (at submit) by debbugs.gnu.org; 4 Jan 2025 16:14:40 +0000 Received: from localhost ([127.0.0.1]:56833 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tU6nP-0008Nr-AQ for submit@debbugs.gnu.org; Sat, 04 Jan 2025 11:14:40 -0500 Received: from lists.gnu.org ([2001:470:142::17]:54306) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tU6nK-0008NT-Kf for submit@debbugs.gnu.org; Sat, 04 Jan 2025 11:14:37 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tU6n9-0002Tj-Pc for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 11:14:25 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tU6n5-00064M-Ko for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 11:14:23 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 16803240027 for ; Sat, 4 Jan 2025 17:14:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1736007255; bh=cIF3/tlgUTRWNlZ85nKdgoICQNsW/nT7/2/UzlAjO6U=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:From; b=aeeYHIYzuDyBsCLUnaCb9RNmSoVaW69M/MZ3tsxrm5j95iduZHfr5LUORnQdVAPlU AxQT5tjO4k+QDddG/OJdi7p0MPVcG6we32MRzEvm0NGVvc/mOW0CeiRApUsS8IBW7h 0bdh9SOJYT5cDGIlLV8aFVuL79xu3a1BTrFc9RNuwgOmXlU1dHL5Di6hdbtlRH68FS EQFtHt2lZIfw2grEuA462PWztP+cqWHpkmne3KBICQYWeXtmiWavvYorPUEXfuCeKG TtWx39GtWV1pK6wCKjCgSvIsVI4vpqbNj8B8Rcqtu9prR21AcxJPe25vl7WIJaUeku wxc/u68k2Fozw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YQQVl05Nkz6tsg; Sat, 4 Jan 2025 17:14:06 +0100 (CET) From: Thierry Volpiatto To: bug-gnu-emacs@gnu.org Subject: 29.4; eww buffer is not displayed correctly when used from bookmark-jump Date: Sat, 04 Jan 2025 16:20:19 +0000 Message-ID: <87zfk6eekc.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.67.36.65; envelope-from=thievol@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) The eww buffer is displayed in two windows whereas it should be displayed only in other-window when used like this: --8<---------------cut here---------------start------------->8--- (require 'bookmark) (require 'eww) (let ((bookmark-alist '(("La langue fran=C3=A7aise" (location . "https://www.lalanguefrancaise.com/") (handler . eww-bookmark-jump))))) (bookmark-jump (car bookmark-alist) #'switch-to-buffer-other-window)) --8<---------------cut here---------------end--------------->8--- It is not a bug in `bookmark-jump` but in `eww-bookmark-jump` (the eww bookmark handler) which uses wrongly the function `eww` which itself uses `pop-to-buffer-same-window`. Probably a lower level function should be used (if one?). In GNU Emacs 29.4 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars) of 2024-12-26 built on IPad-S340 Windowing system distributor 'The X.Org Foundation', version 11.0.12101004 System Description: Linux Mint 21.3 Configured using: 'configure CFLAGS=3D-O8 --bindir=3D/usr/local/sbin/emacs-29.4 --with-cairo --with-x-toolkit=3Dlucid --with-modules --without-tree-sitter --without-native-compilation' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB Important settings: value of $LANG: fr_FR.UTF-8 locale-coding-system: utf-8-unix Major mode: =EE=A4=88 Minor modes in effect: emms-mode-line-mode: t emms-playing-time-display-mode: t emms-playing-time-mode: t server-mode: t psession-mode: t psession-savehist-mode: t register-preview-mode: t global-git-gutter-mode: t display-time-mode: t winner-mode: t tv-save-place-mode: t helm-epa-mode: t helm-descbinds-mode: t helm-top-poll-mode: t helm-adaptive-mode: t helm-mode: t helm-minibuffer-history-mode: t helm-ff-icon-mode: t shell-dirtrack-mode: t helm-popup-tip-mode: t dired-async-mode: t minibuffer-depth-indicate-mode: t gcmh-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow emacsbug url-http url-gw url-cache url-auth gnus-async gnus-bcklg gnus-ml disp-table nndraft nnmh nnfolder gnus-agent gnus-srvr gnus-score score-mode nnvirtual nntp gnus-cache helm-emms helm-ring tramp-sh cl-print helm-ls-hg vc-hg isl vc-rcs log-view pcvs-util cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs view smerge-mode diff helm-dabbrev cl-indent char-fold shortdoc emacs-news-mode epa-file network-stream nsm mailalias qp epa-mail face-remap gnus-cite smiley w3m-form w3m-symbol config-w3m w3m timezone w3m-hist bookmark-w3m w3m-ems w3m-favicon w3m-image w3m-fb tab-line w3m-proc w3m-util mm-archive mail-extr textsec uni-scripts idna-mapping ucs-normalize uni-confusable textsec-check addressbook-bookmark tv-mu4e-config advice gnus-and-mu4e mu4e-patch mu4e-contrib eshell esh-cmd esh-ext esh-opt esh-proc esh-io esh-arg esh-module esh-groups esh-util mu4e mu4e-org mu4e-notification notifications mu4e-main smtpmail mu4e-view mu4e-mime-parts crm mu4e-headers mu4e-thread mu4e-actions mu4e-compose mu4e-draft gnus-msg mu4e-search mu4e-lists mu4e-bookmarks mu4e-mark mu4e-message flow-fill hl-line mu4e-contacts mu4e-update mu4e-folders mu4e-context mu4e-query-items mu4e-server mu4e-modeline mu4e-vars mu4e-helpers mu4e-config mu4e-window ido mu4e-obsolete helm-skitour helm-command helm-elisp helm-eval edebug debug backtrace helm-x-files helm-for-files helm-bookmark helm-info bookmark image-file image-converter emms-config emms-idapi-browser emms-idapi emms-idapi-musicbrainz emms-mpris emms-librefm-stream emms-librefm-scrobbler emms-playlist-limit emms-i18n emms-history emms-score emms-stream-info emms-metaplaylist-mode emms-bookmarks emms-cue emms-mode-line-icon emms-browser sort emms-volume emms-volume-sndioctl emms-volume-mixerctl emms-volume-pulse emms-volume-amixer emms-playlist-sort emms-last-played emms-player-xine emms-player-mpd tq emms-lyrics emms-url emms-streams emms-show-all emms-tag-editor emms-tag-tracktag emms-mark emms-mode-line emms-cache emms-info-native emms-info-native-spc emms-info-native-mp3 emms-info-native-ogg emms-info-native-opus emms-info-native-flac emms-info-native-vorbis bindat emms-info-exiftool emms-info-tinytag emms-info-metaflac emms-info-opusinfo emms-info-ogginfo emms-info-mp3info emms-playlist-mode emms-player-vlc emms-player-mpv emms-playing-time emms-info emms-later-do emms-player-mplayer emms-player-simple emms-source-playlist emms-source-file locate emms-setup emms emms-compat emms-auto helm-external helm-net tramp-archive tramp-gvfs tramp-cache time-stamp zeroconf ffap helm-ls-git vc-git diff-mode vc vc-dispatcher flymake-shellcheck flymake-proc flymake project warnings sh-script smie treesit executable make-mode org-indent org-element org-persist org-id org-refile avl-tree generator oc-basic ol-eww eww url-queue thingatpt mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig gnus-sum shr pixel-fill kinsoku url-file svg dom gnus-group gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7 nnoo gnus-spec gnus-int gnus-range message sendmail yank-media puny rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus nnheader gnus-util mail-utils range mm-util mail-prsvr ol-docview doc-view jka-compr ol-bibtex bibtex ol-bbdb ol-w3m ol-doi org-link-doi org-config ob-gnuplot org-crypt org-protocol org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-src ob-comint org-pcomplete org-list org-footnote org-faces org-entities noutline outline ob-emacs-lisp ob-core ob-eval org-cycle org-table ol org-fold org-fold-core org-keys oc org-loaddefs find-func org-version org-compat org-macs bug-reference cus-start naquadah-theme solar cal-dst holidays holiday-loaddefs appt diary-lib diary-loaddefs cal-menu calendar cal-loaddefs server bm cl-extra imenu tv-utils psession frameset register-preview pcase git-gutter mule-util dired-extension time winner describe-variable help-fns radix-tree help-mode tv-save-place.el init-helm epa derived epg rfc6068 epg-config helm-epa helm-descbinds cus-edit pp icons wid-edit helm-sys helm-adaptive helm-mode helm-misc helm-files image-dired image-dired-tags image-dired-external image-dired-util xdg image-mode exif filenotify tramp tramp-loaddefs trampver tramp-integration files-x tramp-compat rx shell pcomplete 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 wgrep-helm wgrep grep compile text-property-search comint ansi-osc ring helm-regexp format-spec ansi-color helm-utils helm-help helm-types helm-extensions-autoloads helm-autoloads helm helm-global-bindings helm-easymenu edmacro kmacro helm-core helm-source helm-multi-match helm-lib dired-async async dired-aux dired dired-loaddefs isl-autoloads mb-depth avoid cus-load gcmh easy-mmode all-the-icons-autoloads bash-completion-autoloads info ledger-mode-autoloads markdown-mode-autoloads w3m-load w3m-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 dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo x-toolkit xinput2 x multi-tty make-network-process emacs) Memory information: ((conses 16 1612641 255300) (symbols 48 43903 5) (strings 32 321582 36530) (string-bytes 1 9242506) (vectors 16 125121) (vector-slots 8 2615479 161054) (floats 8 5249 2732) (intervals 56 129833 3766) (buffers 976 196)) <#secure method=3Dpgpmime mode=3Dsign> --=20 Thierry From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 08 02:34:27 2025 Received: (at 75354) by debbugs.gnu.org; 8 Jan 2025 07:34:27 +0000 Received: from localhost ([127.0.0.1]:45825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tVQaB-0003CR-9B for submit@debbugs.gnu.org; Wed, 08 Jan 2025 02:34:27 -0500 Received: from mout02.posteo.de ([185.67.36.66]:36815) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tVQa6-0003C6-OQ for 75354@debbugs.gnu.org; Wed, 08 Jan 2025 02:34:25 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 3E8FC240101 for <75354@debbugs.gnu.org>; Wed, 8 Jan 2025 08:34:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1736321656; bh=3+cMcg/3IhlzhXxj/hX3tmIIJaCAFpbfta1AxXPQAg0=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:From; b=lgM5pV4brFCawo9/Rr5FE+ObT3W3SRYSVsAcDLX5Ev5ZWFPRx2sW3JOSWelPPW5fe g5ydm8QqW/bXrI07bLOdVoVnt8rRfnYr6cbxQUmNdN6LtPkY+9W9abi6X3qYM1HWHe ZAZOqUHXLjdWXBYu5ZjGh2CdEcEobbCNfNBY0/90H5pO24Tidz7fB/Jpe+JcTWAAWY Kbub5+cV7j7ixhyZHiO7xjRj2UxC2cU5LLL/yBmzb0XyJusvM6gmy0/c87Pao4ExkQ YwJ3HtX524bG9m4y4J5xTOSLiKLUHESuWA8k/wZC8fJI6mt5HosK4Xylt3JZA6t/xf X3lfvSE5QaMGg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YSfn238Vsz6twC; Wed, 8 Jan 2025 08:34:14 +0100 (CET) From: Thierry Volpiatto To: 75354@debbugs.gnu.org Subject: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) Date: Wed, 08 Jan 2025 07:40:30 +0000 Message-ID: <87h669vjm9.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75354 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I could fix the problem by modifying bookmark--jump-via: diff --git a/lisp/bookmark.el b/lisp/bookmark.el index 0048330e790..a474bed652e 100644 =2D-- a/lisp/bookmark.el +++ b/lisp/bookmark.el @@ -1261,28 +1261,29 @@ DISPLAY-FUNCTION is called with the current buffer = as argument. After calling DISPLAY-FUNCTION, set window point to the point specified by BOOKMARK-NAME-OR-RECORD, if necessary, run `bookmark-after-jump-hook', and then show any annotations for this bookmark." =2D (bookmark-handle-bookmark bookmark-name-or-record) =2D ;; Store `point' now, because `display-function' might change it. =2D (let ((point (point))) =2D (save-current-buffer =2D (funcall display-function (current-buffer))) =2D (let ((win (get-buffer-window (current-buffer) 0))) =2D (if win (set-window-point win point)))) =2D ;; FIXME: we used to only run bookmark-after-jump-hook in =2D ;; `bookmark-jump' itself, but in none of the other commands. =2D (when bookmark-fringe-mark =2D (let ((overlays (overlays-in (pos-bol) (1+ (pos-bol)))) =2D temp found) =2D (while (and (not found) (setq temp (pop overlays))) =2D (when (eq 'bookmark (overlay-get temp 'category)) =2D (setq found t))) =2D (unless found =2D (bookmark--set-fringe-mark)))) =2D (run-hooks 'bookmark-after-jump-hook) =2D (if bookmark-automatically-show-annotations + (let (buf) + (save-window-excursion + (bookmark-handle-bookmark bookmark-name-or-record) + (setq buf (current-buffer))) + (let ((point (with-current-buffer buf (point)))) + (funcall display-function buf) + (when-let ((win (get-buffer-window buf 0))) + (set-window-point win point))) + ;; FIXME: we used to only run bookmark-after-jump-hook in + ;; `bookmark-jump' itself, but in none of the other commands. + (when bookmark-fringe-mark + (let ((overlays (overlays-in (pos-bol) (1+ (pos-bol)))) + temp found) + (while (and (not found) (setq temp (pop overlays))) + (when (eq 'bookmark (overlay-get temp 'category)) + (setq found t))) + (unless found + (bookmark--set-fringe-mark)))) + (run-hooks 'bookmark-after-jump-hook) + (when bookmark-automatically-show-annotations ;; if there is an annotation for this bookmark, ;; show it in a buffer. =2D (bookmark-show-annotation bookmark-name-or-record))) + (bookmark-show-annotation bookmark-name-or-record)))) =20 =20 ;;;###autoload =2D-=20 Thierry --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHHBAEBCgAxFiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmd+K+8THHRoaWV2b2xA cG9zdGVvLm5ldAAKCRAOxW0UHRbvk0UDC/9KNf2QifiGR/ZsSNc1Ztg3XHGxhXAW NX/2hYbL5fxlB1HZ9VK9VAjv+BsSPjOHJELBBwIrqxX4NBUwpp53GXAzOqM784dE +1iihcx6M8HANuUTVdCGIVeSJ3VjNwuNipZpToFAsIsYsqkCBLRryZ+pvhHXkzP5 EcZhj5PsNmSEYqiT36P+6r44ZHs/b3ijZpUAcMQRuRWXJwDV5zz/UxxOSWy4nUiF +QGhXjVGSvsisq3L6lcbckYKieDCyoCt+ezLD7AWQBfxr0XCyuhajM7lSUuP1RwU MMdMxA6d1CTLYe08vWzLzligNXEAgE2SOme6GRUZQp6ZitR9MOGyidOhkjP+EQ83 O4jpToCcYLW1MmoC7IGDnBrZ95+n/Z95FChl0MAqWGEOY7jiQ3JaE1lV1oRdp7ff 5l9FNU5PJ2fXOIA3d1M3Tyw/JndCs1qC0rOSwRGH6ewPA+q6Ee6+9085nvva1QuK RwElnDiu+gI4lev6fax/dJqmnwK1KvyFJwM= =iEOD -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 08 08:10:25 2025 Received: (at 75354) by debbugs.gnu.org; 8 Jan 2025 13:10:25 +0000 Received: from localhost ([127.0.0.1]:46418 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tVVpI-000262-Ps for submit@debbugs.gnu.org; Wed, 08 Jan 2025 08:10:25 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41354) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tVVpF-00025l-08 for 75354@debbugs.gnu.org; Wed, 08 Jan 2025 08:10:23 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tVVp8-0005G7-U5; Wed, 08 Jan 2025 08:10:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ARzjJF4C9yfn4unyyJhMKBVLk+TJy+ORqzRb1kd3QRw=; b=Svap9TnFzhfV VRqR9R2asACHHOYlnVRQSlW7H4KFBFLdxOovn5nCimxWJAb275C/D8/gxM3yqUBFkk2NbdEaAUGLl W8IfF6X2I8yyZQFo3T1nfDMyjxgNLRXFbG7Vr+hLpNI98H7kiakwjxBxKw8h59t/An4bAjvAz+Zqw b92klZcMLpLO90IIQ5IRxgcIG1Kn1RyZaNJpyiczmM02YB1T713+Z+JKKVANnt/NyPp5I5sEmSTzf WmbiHXdCpSqKao1dwGms1RVTd0drlKCvNdFmaxpJEwDYSEDuztvNpQMXM4r/RM3wj6gdd7Em40EdE UU0x6QEN2oywL2vrlzqPJg==; Date: Wed, 08 Jan 2025 15:10:10 +0200 Message-Id: <8634ht4fkd.fsf@gnu.org> From: Eli Zaretskii To: Thierry Volpiatto In-Reply-To: <87h669vjm9.fsf@posteo.net> (message from Thierry Volpiatto on Wed, 08 Jan 2025 07:40:30 +0000) Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) References: <87zfk6eekc.fsf@posteo.net> <87h669vjm9.fsf@posteo.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75354 Cc: 75354@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Thierry Volpiatto > Date: Wed, 08 Jan 2025 07:40:30 +0000 > > I could fix the problem by modifying bookmark--jump-via: Thanks. This is contrary to what you originally wrote (with which I agree): > It is not a bug in `bookmark-jump` but in `eww-bookmark-jump` (the eww > bookmark handler) which uses wrongly the function `eww` which itself uses > `pop-to-buffer-same-window`. Probably a lower level function should be > used (if one?). By contrast, the change you propose now will affect all the uses of bookmarks, everywhere, which is riskier, given how many different variants of bookmark usage are out there. Why did you change your mind about the preferred way of fixing this? From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 08 08:46:28 2025 Received: (at 75354) by debbugs.gnu.org; 8 Jan 2025 13:46:28 +0000 Received: from localhost ([127.0.0.1]:46494 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tVWOC-0003h2-4Y for submit@debbugs.gnu.org; Wed, 08 Jan 2025 08:46:28 -0500 Received: from mout02.posteo.de ([185.67.36.66]:60649) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tVWO8-0003gV-Ox for 75354@debbugs.gnu.org; Wed, 08 Jan 2025 08:46:26 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 478F7240103 for <75354@debbugs.gnu.org>; Wed, 8 Jan 2025 14:46:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1736343977; bh=1PIlMjHRkY0hdffewNvd4l08joQ1LZF5iMKU0IEfvLc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=UuFeEHimK+hxMgjDzZ2vmmPFP9S3XTVJExGAFygVul0CThvF1T0hl5eS4TcGNTFHH U/GUD+jipzq8CRWaHnMFD7jEFJysWjDsUKSvWvg4TYytJLFQYw7tZJ/itFKZCZvMgk ODw98INPrjgo39rXDj7vjLorZcKYGmbg8nRD3jRFym4m+6gSQyBgRe1K6oAOnNXAGU H6SPta0m1tq9/Ydcue9Q7M1xuNdS8vUbK9fI5NLFRJw8ATwbOu+2+C+IJtVgPVo7a9 H9lq0LffFOHdnJILt1h191q6HWGn+Mwv728wiDmnlKxAr+NawkFmUiGQUwoRsx1BeH lyix+eu/liqxQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YSq2H6nrXz6tvt; Wed, 8 Jan 2025 14:46:15 +0100 (CET) From: Thierry Volpiatto To: Eli Zaretskii Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) In-Reply-To: <8634ht4fkd.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 08 Jan 2025 15:10:10 +0200") References: <87zfk6eekc.fsf@posteo.net> <87h669vjm9.fsf@posteo.net> <8634ht4fkd.fsf@gnu.org> Date: Wed, 08 Jan 2025 13:52:32 +0000 Message-ID: <87sept5s67.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75354 Cc: Thierry Volpiatto , 75354@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Eli Zaretskii writes: >> From: Thierry Volpiatto >> Date: Wed, 08 Jan 2025 07:40:30 +0000 >>=20 >> I could fix the problem by modifying bookmark--jump-via: > > Thanks. > > This is contrary to what you originally wrote (with which I agree): Yes, after deeper search I found that `bookmark--jump-via` is behaving like this AFAIU: - It calls the handler which creates a new buffer related to bookmark. - It then displays the current-buffer (the one before jumping to bmk) in a window according to DISPLAY-FUNCTION and make the bookmark buffer curren= t. This approach is OK as long as the handler fn doesn't try do do one part of the job (window handling) itself, which is not the case at least with eww and w3m. It is as well counter intuitive, DISPLAY-FUNCTION should be called on the buffer generated by bookmark and not the contrary, so this change makes the code simpler and easier to understand. > By contrast, the change you propose now will affect all the uses of > bookmarks, everywhere, Yes, this is intended, in addition of fixing eww, it fixes w3m and also the quit function of eww (actually broken). > which is riskier, given how many different variants of bookmark usage > are out there. Tested here on many different kinds of bookmarks and work as expected unlike the current code. > Why did you change your mind about the preferred way of fixing this? Because I couldn't find a way to fix this correctly by modifying only the handler, thus the change would need to be done on each other handlers which behave unexpectedly. Here is the latest patch attached. Thanks. =2D-=20 Thierry --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-Handle-correctly-DISPLAY-FUNCTION-arg-in-bookmark-ju.patch Content-Transfer-Encoding: quoted-printable From=20b4d99152212744ab1d90c67641cd41576e6e13f3 Mon Sep 17 00:00:00 2001 From: Thierry Volpiatto Date: Wed, 8 Jan 2025 10:45:55 +0100 Subject: [PATCH] Handle correctly DISPLAY-FUNCTION arg in bookmark--jump-via This fix bug #75354 where when jumping to a eww bmk to other window (or frame) the buffer is displayed both in other window and current window. Previously bookmark--jump-via was calling DISPLAY-FUNCTION on the current-buffer from the new buffer created by bookmark handler (e.g. eww) now DISPLAY-FUNCTION is called on the new buffer from the current buffer (winconf is saved when calling handler). In addition to make eww bookmarks displayed properly, this fix as well w3m bookmarks and as a side effect fix the eww quit function which restore properly winconf after quitting (previously leaving two windows open). =2D-- lisp/bookmark.el | 43 ++++++++++++++++++++++--------------------- 1 file changed, 22 insertions(+), 21 deletions(-) diff --git a/lisp/bookmark.el b/lisp/bookmark.el index 0048330e790..248620fbda4 100644 =2D-- a/lisp/bookmark.el +++ b/lisp/bookmark.el @@ -1256,33 +1256,34 @@ Useful for example to unhide text in `outline-mode'= .") =20 (defun bookmark--jump-via (bookmark-name-or-record display-function) "Handle BOOKMARK-NAME-OR-RECORD, then call DISPLAY-FUNCTION. =2DDISPLAY-FUNCTION is called with the current buffer as argument. +DISPLAY-FUNCTION is called with the new buffer as argument. =20 After calling DISPLAY-FUNCTION, set window point to the point specified by BOOKMARK-NAME-OR-RECORD, if necessary, run `bookmark-after-jump-hook', and then show any annotations for this bookmark." =2D (bookmark-handle-bookmark bookmark-name-or-record) =2D ;; Store `point' now, because `display-function' might change it. =2D (let ((point (point))) =2D (save-current-buffer =2D (funcall display-function (current-buffer))) =2D (let ((win (get-buffer-window (current-buffer) 0))) =2D (if win (set-window-point win point)))) =2D ;; FIXME: we used to only run bookmark-after-jump-hook in =2D ;; `bookmark-jump' itself, but in none of the other commands. =2D (when bookmark-fringe-mark =2D (let ((overlays (overlays-in (pos-bol) (1+ (pos-bol)))) =2D temp found) =2D (while (and (not found) (setq temp (pop overlays))) =2D (when (eq 'bookmark (overlay-get temp 'category)) =2D (setq found t))) =2D (unless found =2D (bookmark--set-fringe-mark)))) =2D (run-hooks 'bookmark-after-jump-hook) =2D (if bookmark-automatically-show-annotations + (let (buf) + (save-window-excursion + (bookmark-handle-bookmark bookmark-name-or-record) + (setq buf (current-buffer))) + (let ((point (with-current-buffer buf (point)))) + (funcall display-function buf) + (when-let ((win (get-buffer-window buf 0))) + (set-window-point win point))) + ;; FIXME: we used to only run bookmark-after-jump-hook in + ;; `bookmark-jump' itself, but in none of the other commands. + (when bookmark-fringe-mark + (let ((overlays (overlays-in (pos-bol) (1+ (pos-bol)))) + temp found) + (while (and (not found) (setq temp (pop overlays))) + (when (eq 'bookmark (overlay-get temp 'category)) + (setq found t))) + (unless found + (bookmark--set-fringe-mark)))) + (run-hooks 'bookmark-after-jump-hook) + (when bookmark-automatically-show-annotations ;; if there is an annotation for this bookmark, ;; show it in a buffer. =2D (bookmark-show-annotation bookmark-name-or-record))) + (bookmark-show-annotation bookmark-name-or-record)))) =20 =20 ;;;###autoload =2D-=20 2.34.1 --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHHBAEBCgAxFiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmd+gyATHHRoaWV2b2xA cG9zdGVvLm5ldAAKCRAOxW0UHRbvk9OsC/9eSZanNyjM/pxGDb3pd17SEICJtXFj dAOzPfslKmGnt3a1AK5Kdv4TUK/qgCbNI5217jzHZ9YU4rhaiB66MOwpqdm17z5C TUDQaJq2M4wUtKjnnyB29iHeHIMOutlui8oH5zvrQDaIdds3RU29x9fCHIJkgOxN xO8wdWDTsbPAmm/8RffXoL8IVbU2x2/XZ80a9M5xxYEDb2hjK0q0ag0vsGKrwHua L/ZkrFZ+FCznRNgy0PrBPGrGHAZbT3vqQKTZu+1aOgpjfxBStJHKrSp/0EsNx/8Z Z+zvtLGmALqiPnleO2NWvpkzwExAN1462ZRv35UD0Yp1VWrH0f5nig6calzmWXdy 0QL0WVykJS/HhVfLe174arUoaECz819ps9zEJTszAUep+xoOWMFS+f2+MPm6ChOJ 84CvrFnGykEZeguZoMGc5D3PmrOdrIraXEv6nhv7edfOe52cFLrerO67gJ0R4dIH NIJTa2B+iFkm+20VlvLJdo2oCZBGcanX+zA= =YLLo -----END PGP SIGNATURE----- --==-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 08 09:03:47 2025 Received: (at 75354) by debbugs.gnu.org; 8 Jan 2025 14:03:47 +0000 Received: from localhost ([127.0.0.1]:46520 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tVWex-0004Q1-44 for submit@debbugs.gnu.org; Wed, 08 Jan 2025 09:03:47 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40696) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tVWeu-0004Pm-V3 for 75354@debbugs.gnu.org; Wed, 08 Jan 2025 09:03:46 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tVWep-0000ho-7i; Wed, 08 Jan 2025 09:03:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=2JIdSNRVgXkeXS0Cr1m4wWGyHT3loaL8IOBmqj5mcBI=; b=OJcisYdAivzD lZPTRLa2QXRlLCjYTjSeXskrw93NOCdObiiam8+PKLovucDK2k3ICYduKGbobCvfziFm1p2AnF2kE WR4211w7GrGPEdEjuKUm31G6wcIO9rcZnAfg8psmHM+qemWnLMl3Smc64KIMdM/UhYPmeSgPQKQnr 1tlzUrx0LrqYEfc/vImg4WOPgaI5XcsSxypf9+hQBUTiL5EgubW79pwjBGEEbAd8twUVWHfrLUp4r OQ35UpI7we5oq/tM3RrcBe1pyszcH+/p5HlUB2LAFGtwemF3j+NrrPRYMkoI0vuNRiyjEXx6V7rm/ M23DfqmN2bVGsfrMoWxocg==; Date: Wed, 08 Jan 2025 16:03:34 +0200 Message-Id: <86y0zl2yix.fsf@gnu.org> From: Eli Zaretskii To: Thierry Volpiatto In-Reply-To: <87sept5s67.fsf@posteo.net> (message from Thierry Volpiatto on Wed, 08 Jan 2025 13:52:32 +0000) Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) References: <87zfk6eekc.fsf@posteo.net> <87h669vjm9.fsf@posteo.net> <8634ht4fkd.fsf@gnu.org> <87sept5s67.fsf@posteo.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75354 Cc: 75354@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Thierry Volpiatto > Cc: Thierry Volpiatto , 75354@debbugs.gnu.org > Date: Wed, 08 Jan 2025 13:52:32 +0000 > > > This is contrary to what you originally wrote (with which I agree): > > Yes, after deeper search I found that `bookmark--jump-via` is behaving > like this AFAIU: > - It calls the handler which creates a new buffer related to bookmark. > - It then displays the current-buffer (the one before jumping to bmk) in > a window according to DISPLAY-FUNCTION and make the bookmark buffer current. > > This approach is OK as long as the handler fn doesn't try do do one part > of the job (window handling) itself, which is not the case at least with > eww and w3m. It is as well counter intuitive, DISPLAY-FUNCTION should > be called on the buffer generated by bookmark and not the contrary, so > this change makes the code simpler and easier to understand. > > > By contrast, the change you propose now will affect all the uses of > > bookmarks, everywhere, > > Yes, this is intended, in addition of fixing eww, it fixes w3m and also > the quit function of eww (actually broken). > > > which is riskier, given how many different variants of bookmark usage > > are out there. > > Tested here on many different kinds of bookmarks and work as expected > unlike the current code. OK, thanks. Let's leave this for a few days to give people time to post comments if they have them. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 08 09:41:31 2025 Received: (at 75354) by debbugs.gnu.org; 8 Jan 2025 14:41:31 +0000 Received: from localhost ([127.0.0.1]:46574 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tVXFT-0006GU-4S for submit@debbugs.gnu.org; Wed, 08 Jan 2025 09:41:31 -0500 Received: from mout02.posteo.de ([185.67.36.66]:37571) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tVXFO-0006GB-EH for 75354@debbugs.gnu.org; Wed, 08 Jan 2025 09:41:29 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 15386240101 for <75354@debbugs.gnu.org>; Wed, 8 Jan 2025 15:41:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1736347277; bh=I/7DM1hXTl2pc6dic23DDVrbDspo9fVdn47Y7ddj9VY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=J1J5nzRPIf6jvXMI41d4r+tLsOoSeuKaYTdYzN9BVu3+rrMDI7KzRkofzggveOyy3 WfxDuw6IpPtbKaiuTDMYdJUs19ydqoDms+ywwFr+y+3QB8byONaOT/xxkK51xxHnbp REJtZPxMPkWB5ws3YebxflxOixoLcblRDLrxlBWCve6LyV1Y33rz2TMv8D4pZAGf2r WcjF1l2QSoRzxxAoDdOWOiq0fe0EV+XwAqLa1Z0iMbsfgQciz4l+K9u1E55iMQ0ghS 2nMqZqZ1UBD7llIHnqeKGidwcCRDbfgiqYvQwDJEAmLesZY70jpE8YQLx8AJSpGs3u j5aA5sxez3tTA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YSrFj3FZSz6tvr; Wed, 8 Jan 2025 15:41:12 +0100 (CET) From: Thierry Volpiatto To: Eli Zaretskii Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) In-Reply-To: <86y0zl2yix.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 08 Jan 2025 16:03:34 +0200") References: <87zfk6eekc.fsf@posteo.net> <87h669vjm9.fsf@posteo.net> <8634ht4fkd.fsf@gnu.org> <87sept5s67.fsf@posteo.net> <86y0zl2yix.fsf@gnu.org> Date: Wed, 08 Jan 2025 14:47:26 +0000 Message-ID: <87septicqp.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75354 Cc: Thierry Volpiatto , 75354@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Eli Zaretskii writes: >> From: Thierry Volpiatto >> Cc: Thierry Volpiatto , 75354@debbugs.gnu.org >> Date: Wed, 08 Jan 2025 13:52:32 +0000 >>=20 >> > This is contrary to what you originally wrote (with which I agree): >>=20 >> Yes, after deeper search I found that `bookmark--jump-via` is behaving >> like this AFAIU: >> - It calls the handler which creates a new buffer related to bookmark. >> - It then displays the current-buffer (the one before jumping to bmk) in >> a window according to DISPLAY-FUNCTION and make the bookmark buffer cur= rent. >>=20 >> This approach is OK as long as the handler fn doesn't try do do one part >> of the job (window handling) itself, which is not the case at least with >> eww and w3m. It is as well counter intuitive, DISPLAY-FUNCTION should >> be called on the buffer generated by bookmark and not the contrary, so >> this change makes the code simpler and easier to understand. >>=20 >> > By contrast, the change you propose now will affect all the uses of >> > bookmarks, everywhere, >>=20 >> Yes, this is intended, in addition of fixing eww, it fixes w3m and also >> the quit function of eww (actually broken). >>=20 >> > which is riskier, given how many different variants of bookmark usage >> > are out there. >>=20 >> Tested here on many different kinds of bookmarks and work as expected >> unlike the current code. > > OK, thanks. Let's leave this for a few days to give people time to > post comments if they have them. Ok, I will make changes to commit message (needs * lisp/bookmark.el (...): bla) and also when-let =3D> when-let* to fit with emacs-30+. Thanks. =2D-=20 Thierry --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHHBAEBCgAxFiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmd+j/4THHRoaWV2b2xA cG9zdGVvLm5ldAAKCRAOxW0UHRbvk9URDACfyPYjlXJbYLBA8QgnNFl5uJ1v2fdx Efbofa4WZisWpXttJwAAMipryv7mWs+mB3+E0eyA7AhVdZxaY5mBOoBn0LmqcEBr DANQY4iRNDuSlw5M/ffVF78yomgwR0dABeatf6MSO1L3CeWBIurHPZowSax+WC9I Gyn0nTP1Qjgupeva0BmMs3dwYqeI/+jSxS5XsUDCJjBQjWnSnTKSfO4BwMKyzhF7 M4Qm6vpVeZBsJTwMxFh+GAwBt9kU3qyoPyz5pnVVd8VrCczClhKQGzgePKvUCqiB lWoDQfybEnB/SDSCRR5wC/08W1F3iN/BsT1D7jpTmRyWL062goN9sKB53Zmkqxne 4TcuSoh4l3MBTndHiNxVseHujRmK7us1IqD2WCF90TmSPkLie3Sd/G9N9fWCc5Vl jfaD8l43uMhGCICt6qOnNsWqqTeu8KqYOz8wN/1qg0cOT1Xb5zh2P5u/I9QqGkDe h/Q8D2aDV+VX4qkVHC53EqGTv3mcXoWVivg= =O0uO -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 10 00:50:32 2025 Received: (at 75354) by debbugs.gnu.org; 10 Jan 2025 05:50:33 +0000 Received: from localhost ([127.0.0.1]:56129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tW7ui-0005D6-Ek for submit@debbugs.gnu.org; Fri, 10 Jan 2025 00:50:32 -0500 Received: from mout02.posteo.de ([185.67.36.66]:59315) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tW7uf-0005Cq-Vm for 75354@debbugs.gnu.org; Fri, 10 Jan 2025 00:50:31 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id BC8F8240101 for <75354@debbugs.gnu.org>; Fri, 10 Jan 2025 06:50:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1736488223; bh=4lBEOD3aJkyzE/ej8a7TtnZXBmysgiN/F0luLs9r/D0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=FeeakRKUIy04nFqR+7vQFBRxb/5waI50VtkXx0CnRgOOISm2vAYsV9NAd9Eh9M3n+ I0QGgwzDBp0PWQLH4y85qUcThqbPJQlqMcYN7BHr71j8oSLpSMsXu3Q0S26LxatjtE RrnFAS4hoUNhFL1PAv8vg6bkVg/jepxukE5dwYZ/RNJw+EBXnLmNiw2sTowyj/s9uL 3CdCTzAxQbFV0YP1d3Lh1oT1GITLiY5lLTLE6MWlKJIttDaB1ysRRkOJYd/NgUja60 iVDfnAfN/9961wLNujii2p0beM3todFAj6AnakFISXCC0LGFdE+Fbv+A7etSg9ZTCj geqFz1lk+5ebA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YTrNF3NvFz6tw5; Fri, 10 Jan 2025 06:50:21 +0100 (CET) From: Thierry Volpiatto To: Eli Zaretskii Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) In-Reply-To: <86y0zl2yix.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 08 Jan 2025 16:03:34 +0200") References: <87zfk6eekc.fsf@posteo.net> <87h669vjm9.fsf@posteo.net> <8634ht4fkd.fsf@gnu.org> <87sept5s67.fsf@posteo.net> <86y0zl2yix.fsf@gnu.org> Date: Fri, 10 Jan 2025 05:56:40 +0000 Message-ID: <878qrjnrdz.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75354 Cc: Thierry Volpiatto , 75354@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Find here the last patch attached. =2D-=20 Thierry --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-Handle-correctly-DISPLAY-FUNCTION-arg-in-bookmark-ju.patch Content-Transfer-Encoding: quoted-printable From=20abcdef6fb004cef7dfd5c58ae8da82a80477e1c8 Mon Sep 17 00:00:00 2001 From: Thierry Volpiatto Date: Wed, 8 Jan 2025 10:45:55 +0100 Subject: [PATCH] Handle correctly DISPLAY-FUNCTION arg in bookmark--jump-via * lisp/bookmark.el (bookmark--jump-via): Fix it. This fix bug #75354 where when jumping to a eww bmk to other window (or frame) the buffer is displayed both in other window and current window. Previously bookmark--jump-via was calling DISPLAY-FUNCTION on the current-buffer from the new buffer created by bookmark handler (e.g. eww) now DISPLAY-FUNCTION is called on the new buffer from the current buffer (winconf is saved when calling handler). In addition to make eww bookmarks displayed properly, this fix as well w3m bookmarks and as a side effect fix the eww quit function which restore properly winconf after quitting (previously leaving two windows open). =2D-- lisp/bookmark.el | 43 ++++++++++++++++++++++--------------------- 1 file changed, 22 insertions(+), 21 deletions(-) diff --git a/lisp/bookmark.el b/lisp/bookmark.el index 0048330e790..215377635f7 100644 =2D-- a/lisp/bookmark.el +++ b/lisp/bookmark.el @@ -1256,33 +1256,34 @@ Useful for example to unhide text in `outline-mode'= .") =20 (defun bookmark--jump-via (bookmark-name-or-record display-function) "Handle BOOKMARK-NAME-OR-RECORD, then call DISPLAY-FUNCTION. =2DDISPLAY-FUNCTION is called with the current buffer as argument. +DISPLAY-FUNCTION is called with the new buffer as argument. =20 After calling DISPLAY-FUNCTION, set window point to the point specified by BOOKMARK-NAME-OR-RECORD, if necessary, run `bookmark-after-jump-hook', and then show any annotations for this bookmark." =2D (bookmark-handle-bookmark bookmark-name-or-record) =2D ;; Store `point' now, because `display-function' might change it. =2D (let ((point (point))) =2D (save-current-buffer =2D (funcall display-function (current-buffer))) =2D (let ((win (get-buffer-window (current-buffer) 0))) =2D (if win (set-window-point win point)))) =2D ;; FIXME: we used to only run bookmark-after-jump-hook in =2D ;; `bookmark-jump' itself, but in none of the other commands. =2D (when bookmark-fringe-mark =2D (let ((overlays (overlays-in (pos-bol) (1+ (pos-bol)))) =2D temp found) =2D (while (and (not found) (setq temp (pop overlays))) =2D (when (eq 'bookmark (overlay-get temp 'category)) =2D (setq found t))) =2D (unless found =2D (bookmark--set-fringe-mark)))) =2D (run-hooks 'bookmark-after-jump-hook) =2D (if bookmark-automatically-show-annotations + (let (buf point) + (save-window-excursion + (bookmark-handle-bookmark bookmark-name-or-record) + (setq buf (current-buffer) + point (point))) + (funcall display-function buf) + (when-let* ((win (get-buffer-window buf 0))) + (set-window-point win point)) + (when bookmark-fringe-mark + (let ((overlays (overlays-in (pos-bol) (1+ (pos-bol)))) + temp found) + (while (and (not found) (setq temp (pop overlays))) + (when (eq 'bookmark (overlay-get temp 'category)) + (setq found t))) + (unless found + (bookmark--set-fringe-mark)))) + ;; FIXME: we used to only run bookmark-after-jump-hook in + ;; `bookmark-jump' itself, but in none of the other commands. + (run-hooks 'bookmark-after-jump-hook) + (when bookmark-automatically-show-annotations ;; if there is an annotation for this bookmark, ;; show it in a buffer. =2D (bookmark-show-annotation bookmark-name-or-record))) + (bookmark-show-annotation bookmark-name-or-record)))) =20 =20 ;;;###autoload =2D-=20 2.34.1 --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHHBAEBCgAxFiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmeAtpgTHHRoaWV2b2xA cG9zdGVvLm5ldAAKCRAOxW0UHRbvk9w/C/wNIfF9CgBjuNSL2IRThDMxy2Hno//0 H4Sl1THHVDoZOqCj3rrJGOGDhPHfhZcycsf1aHOZ8jCvgQERBqch5fsz9n7uLVgU fEJDkRYCtmEIVhvUTDOXsZnYvNSES16Y5vUwdMV+Ias6mM2jL7mucW/0GTnuB2M1 fYdKd18mwAwsuho3sKpKCRQHYWUHlmoXVCqAqUUBlYLc5Wpg3Q1VqBUZISNGPKvF YEh0BuO2+mdoll7DM4Kb3lB5EWYSLYKIo9/3JZ4V7itHdX/H4/gsNUSPz7KUuTV3 FwTVGpmiqNYcJV9lH0f15ZLFlVSRz9qewN8W/WaN9AbPh7qbFSeuFbly9p0j+1SP 4YdZH8biKDZtndBe4b6trYnu8uFegwG54QDZt1AgBNGNQYJTQy8RgqiOSmAjkSbk cl5Nkn/WStqUdIcabq7JM06zp/DGv+c8JkJydl7lfd3IKBgrjQcbDYneDP9vJwGD fw+sR/To2PiZQz2UX90YZrFgMZL+lWSppOg= =Xu87 -----END PGP SIGNATURE----- --==-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 15 01:37:24 2025 Received: (at 75354) by debbugs.gnu.org; 15 Jan 2025 06:37:24 +0000 Received: from localhost ([127.0.0.1]:56726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXx1n-0003DY-PH for submit@debbugs.gnu.org; Wed, 15 Jan 2025 01:37:24 -0500 Received: from mout01.posteo.de ([185.67.36.65]:48137) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXx1i-0003DA-88 for 75354@debbugs.gnu.org; Wed, 15 Jan 2025 01:37:21 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id E7678240027 for <75354@debbugs.gnu.org>; Wed, 15 Jan 2025 07:37:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1736923031; bh=kBR9GVJjr2nMDQdiUdAO2y5/VbXlyLi3jb/yoPEgXMU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=imcOgTAK8X6kgdSa85u3ulUYrxsRZcMYd1NxPP+41hsnGmgrx7JsSXYl15u4cooZ2 0PZ9K5GwcAfXaWAa0JrSNYryvk5tSOiDlcsV+DuHxDLozKo9PkgGQw0m0WjKQutW/w ziZg7Tx/bXQU32DHDftajjZsvTbD+nNoJsQ2gJfWLZwTkFKCRLBzECmwMzgxTTUo0y 2rZ1Zy2MyY+2Xt1PrkV9j2EpGMTXMZN5UFQ7STSLdZOM59j/1Y/zzRwe+yIMj7qDJZ Ej5mlb+QhK0+KuK4jVPwIf5PXPNjn6vX2ppkJYqFF5kCGN+62k1SJyHD9KGAe15NwP mpLY1dGza+JdA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YXx9x5ggFz6txv; Wed, 15 Jan 2025 07:37:09 +0100 (CET) From: Thierry Volpiatto To: Eli Zaretskii Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) In-Reply-To: <86y0zl2yix.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 08 Jan 2025 16:03:34 +0200") References: <87zfk6eekc.fsf@posteo.net> <87h669vjm9.fsf@posteo.net> <8634ht4fkd.fsf@gnu.org> <87sept5s67.fsf@posteo.net> <86y0zl2yix.fsf@gnu.org> Date: Wed, 15 Jan 2025 06:43:34 +0000 Message-ID: <87plkoo9ux.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75354 Cc: Thierry Volpiatto , 75354@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Eli Zaretskii writes: >> From: Thierry Volpiatto >> Cc: Thierry Volpiatto , 75354@debbugs.gnu.org >> Date: Wed, 08 Jan 2025 13:52:32 +0000 >>=20 >> > This is contrary to what you originally wrote (with which I agree): >>=20 >> Yes, after deeper search I found that `bookmark--jump-via` is behaving >> like this AFAIU: >> - It calls the handler which creates a new buffer related to bookmark. >> - It then displays the current-buffer (the one before jumping to bmk) in >> a window according to DISPLAY-FUNCTION and make the bookmark buffer cur= rent. >>=20 >> This approach is OK as long as the handler fn doesn't try do do one part >> of the job (window handling) itself, which is not the case at least with >> eww and w3m. It is as well counter intuitive, DISPLAY-FUNCTION should >> be called on the buffer generated by bookmark and not the contrary, so >> this change makes the code simpler and easier to understand. >>=20 >> > By contrast, the change you propose now will affect all the uses of >> > bookmarks, everywhere, >>=20 >> Yes, this is intended, in addition of fixing eww, it fixes w3m and also >> the quit function of eww (actually broken). >>=20 >> > which is riskier, given how many different variants of bookmark usage >> > are out there. >>=20 >> Tested here on many different kinds of bookmarks and work as expected >> unlike the current code. > > OK, thanks. Let's leave this for a few days to give people time to > post comments if they have them. Ping. =2D-=20 Thierry --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHHBAEBCgAxFiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmeHWRYTHHRoaWV2b2xA cG9zdGVvLm5ldAAKCRAOxW0UHRbvk8+mC/417w/csPRg5jAgrc02ngL4aLBaPEX6 B/Ztr1GxxIiX+cQTRjyjvnuXd0YbBKk7fspE2InwSWXbKYkMB4PrfJ9N0GfKNenl f4VEnNYSPbVTyO5a2un+hl2BdQbbQ2yqHwT8tMYDundM4KPVhdE9ZOxb96P28Jmx 4YXZ20LGL3J22wnYEpTY8jhlnVD6AV+6kEMxoaAvbCN7XwfVG8xn61YSagp1u/jC zgCl3bcCGX4XX1666gYNvic+ULCKMNq5Ud3CkyqhXRRnBuzzKEXIOvmswAPh86C1 l0s5gYaVtkiXpINuFTT2Dxsc9F1mNXl2Xaq4q+t+TBZuWCqf9jZYJwwUNb+iN0nS z+I12qMaErbB53urIkQXtY/VSCtyVKrGKGGzKVh0EKK4KoYkSnpUf5mw4qVPzP5K Z+2BF6wj4qNKMlWyvKPFuGC7WqaaDGIoD9hZ89xu16WHACrsLLc8S3MAjs39X+uR aoBqcsJMRUD0wgbXAQTa6dJPV28bNsSYUlQ= =IKXb -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 15 10:01:33 2025 Received: (at 75354) by debbugs.gnu.org; 15 Jan 2025 15:01:33 +0000 Received: from localhost ([127.0.0.1]:58289 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tY4th-0005GF-9d for submit@debbugs.gnu.org; Wed, 15 Jan 2025 10:01:33 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45888) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tY4te-0005Fx-Om for 75354@debbugs.gnu.org; Wed, 15 Jan 2025 10:01:31 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tY4tZ-0002sd-FI; Wed, 15 Jan 2025 10:01:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=IdlJePTY3Lrznfmj6tnqlgM2zNIc3TuvnqQwwoNmysM=; b=dxG0OUpviNCH jr3X57AeNBqrD7vajF68zc3tDC8P478xDSEk2yFjCQB9vEyJZ8RHcdosoAisyU+fahFH4dmBUXi++ aAm8Cu5/T07C+plQUM0bbNF0tnaRZSyvD1NcAHpqRZTIFNO3fDfPDzmPa2h0NtdDyqZinhr2F5fUu 8qYL3cCdh2+GoRfeQu/UDtmhiqjSYf5g27vGQQwl/6KVKYHkSGQkMz/WwUFILuk6yg+IER+uMPUq4 lcNMizNc/J7S1YWR1OfF430fLDwYqC27Y1MM/02+eV9vd6mq0qCvO0w818zW0SH7NprfsXfA7AxFP bt66Tj351ps8qKO5ogrhig==; Date: Wed, 15 Jan 2025 17:01:23 +0200 Message-Id: <86wmewjf3w.fsf@gnu.org> From: Eli Zaretskii To: Thierry Volpiatto In-Reply-To: <87plkoo9ux.fsf@posteo.net> (message from Thierry Volpiatto on Wed, 15 Jan 2025 06:43:34 +0000) Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) References: <87zfk6eekc.fsf@posteo.net> <87h669vjm9.fsf@posteo.net> <8634ht4fkd.fsf@gnu.org> <87sept5s67.fsf@posteo.net> <86y0zl2yix.fsf@gnu.org> <87plkoo9ux.fsf@posteo.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75354 Cc: 75354@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Thierry Volpiatto > Cc: Thierry Volpiatto , 75354@debbugs.gnu.org > Date: Wed, 15 Jan 2025 06:43:34 +0000 > > >> Tested here on many different kinds of bookmarks and work as expected > >> unlike the current code. > > > > OK, thanks. Let's leave this for a few days to give people time to > > post comments if they have them. > > Ping. I didn't forget, don't worry, just waiting for some free time to install. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 15 11:09:43 2025 Received: (at 75354) by debbugs.gnu.org; 15 Jan 2025 16:09:44 +0000 Received: from localhost ([127.0.0.1]:58434 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tY5xf-0008S7-J4 for submit@debbugs.gnu.org; Wed, 15 Jan 2025 11:09:43 -0500 Received: from mout01.posteo.de ([185.67.36.65]:52439) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tY5xc-0008Rr-A3 for 75354@debbugs.gnu.org; Wed, 15 Jan 2025 11:09:41 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 2E9DC240027 for <75354@debbugs.gnu.org>; Wed, 15 Jan 2025 17:09:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1736957372; bh=5DFyeZ14yzcDGvm5hP7J78KSY8v31t2B/k4GVe2qxdU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=hPv2IbpJor3X5zSrcsGyK2a0SFzilX5iwS+DYnNeb1lRHlwUagvH0LoNlQ4dOTzln 6g7xG44dXlCfiYI+KASJEZKrQBUV4Mt79886YrvfFh3wsyWacskowrshuPJZCbjVSK YrxaDvWz46+mx1WD7FuUj9CUG819oxXZImlu05BGPwzGQpZ8TnN5LN0FyIQwiNpTkG Z4qLgzKO9tJuvXpia1/I0mTiZhZGqgy+bPyg3U9C3DOQxup9fncfpzOyXiOnx9lYL5 /rhPA4KHUat5EIGoBrgUsldNPWOvrjRi3Af8MQxmaoovzmZvwbIQA+lfMV35gmJpax 7c9EIPv7OUZxA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YY9tM12pYz6tvZ; Wed, 15 Jan 2025 17:09:31 +0100 (CET) From: Thierry Volpiatto To: Eli Zaretskii Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) In-Reply-To: <86wmewjf3w.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 15 Jan 2025 17:01:23 +0200") References: <87zfk6eekc.fsf@posteo.net> <87h669vjm9.fsf@posteo.net> <8634ht4fkd.fsf@gnu.org> <87sept5s67.fsf@posteo.net> <86y0zl2yix.fsf@gnu.org> <87plkoo9ux.fsf@posteo.net> <86wmewjf3w.fsf@gnu.org> Date: Wed, 15 Jan 2025 16:15:56 +0000 Message-ID: <87jzawnjcz.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75354 Cc: Thierry Volpiatto , 75354@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Eli Zaretskii writes: >> From: Thierry Volpiatto >> Cc: Thierry Volpiatto , 75354@debbugs.gnu.org >> Date: Wed, 15 Jan 2025 06:43:34 +0000 >>=20 >> >> Tested here on many different kinds of bookmarks and work as expected >> >> unlike the current code. >> > >> > OK, thanks. Let's leave this for a few days to give people time to >> > post comments if they have them. >>=20 >> Ping. > > I didn't forget, don't worry, just waiting for some free time to > install. Ok ;-) =2D-=20 Thierry --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHHBAEBCgAxFiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmeH3zwTHHRoaWV2b2xA cG9zdGVvLm5ldAAKCRAOxW0UHRbvkyflC/9VQDf7DHm7+VyloOQtzxYeMzvUdavl y8pbnqcm+0L16jL/MDwQFencbwYaLsPFOyf9p+QXYRFPbRxfJmS6sQQ1lV/RX79E vneZnTbEAgOT1KCD7Uydn/1woZPD5443ktZOwpEcp1fYmkJ0c/EOnxzDvAFF2c6O gG/+0fOr/qN3ohTh/a0PzZmMuvYlZUth+lsc6LqkjkQ3SQj5aJEzkuPYRoTUC4Gp Qmj3uWLTNfbx/B/n5Dw/ySP8Vq/BflOddMKPqa5cTVr3HL0hHFirW78IgP193ctJ n14oQwrHWWhkOXqr1wRJhj7ryAq+RaRvZFgIphAWhWWkEXQDW2U0lvpXJoX04A2i 230qId6klaBpu+UhCnMPMJfCzAWsOfR+jcyq6hdQkfuQdMONm0CAdGXB0IUXt9wr QtipDgOavBAT+2XIEDzMQ1iir1Ohl9hKg1nFJwmb875aknUzeNSnF6q0WWjt1TIb xRR4q7ogUA9J7C/PmkBNUQx30LP7oU8jOSI= =1gYd -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 16 11:43:59 2025 Received: (at 75354-done) by debbugs.gnu.org; 16 Jan 2025 16:43:59 +0000 Received: from localhost ([127.0.0.1]:34428 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tYSyM-0006SN-OE for submit@debbugs.gnu.org; Thu, 16 Jan 2025 11:43:59 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41396) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tYSyJ-0006S6-MG for 75354-done@debbugs.gnu.org; Thu, 16 Jan 2025 11:43:57 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tYSyE-0003pI-62; Thu, 16 Jan 2025 11:43:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=KUCa3OJmM8aWb2lnXu0gSqBFtRjDTwgIKCpnZBVQ4e0=; b=I8dF9DQcAMxf 0i46PC6aEg2ZRrHYh/Rk+au6vsz57K6ys4z9kSDEj2LalZlaepYlqFoebAsCwPareO6JHABMqUNe5 Kr4lcWhLJyfsprftkJ+UoO6rQMp6gEgO2RHDj84eVYP3t57jB48F49+YZlVZBiak1HePXW4ahZkbu UjVYy5cgd55rlHm98spk8XGOp2dsm8yLGTd4zQrO4w6e4WTieFIl+K+CX031kd8CUS5sSmrNSr3tX 7WCfk7wbrbhyeNVLuF+wZEtTbxSaW54wBj3e4OBOukty1T10SKgNbLu1F2u8uKsa3MnkiT6M9sXi/ uy+MTWav633eBgOVmfg2NQ==; Date: Thu, 16 Jan 2025 18:43:47 +0200 Message-Id: <864j1yhfp8.fsf@gnu.org> From: Eli Zaretskii To: Thierry Volpiatto In-Reply-To: <878qrjnrdz.fsf@posteo.net> (message from Thierry Volpiatto on Fri, 10 Jan 2025 05:56:40 +0000) Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) References: <87zfk6eekc.fsf@posteo.net> <87h669vjm9.fsf@posteo.net> <8634ht4fkd.fsf@gnu.org> <87sept5s67.fsf@posteo.net> <86y0zl2yix.fsf@gnu.org> <878qrjnrdz.fsf@posteo.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75354-done Cc: 75354-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Thierry Volpiatto > Cc: Thierry Volpiatto , 75354@debbugs.gnu.org > Date: Fri, 10 Jan 2025 05:56:40 +0000 > > Find here the last patch attached. Thanks, installed on the master branch, and closing the bug. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 16 12:14:31 2025 Received: (at 75354-done) by debbugs.gnu.org; 16 Jan 2025 17:14:31 +0000 Received: from localhost ([127.0.0.1]:34487 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tYTRv-0007pC-1L for submit@debbugs.gnu.org; Thu, 16 Jan 2025 12:14:31 -0500 Received: from mout02.posteo.de ([185.67.36.66]:48159) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tYTRs-0007os-FR for 75354-done@debbugs.gnu.org; Thu, 16 Jan 2025 12:14:29 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id D6535240104 for <75354-done@debbugs.gnu.org>; Thu, 16 Jan 2025 18:14:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1737047661; bh=y133mQvA1fnqVgtD6IKl1iNfy+4BodxZXah2YNszTPU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=eJQ5Etl7aNS7r8FAUKTlDT7f7qs7XKqTHE/XPVT5N9GN0x3O7pZzNmAZiuq7jdmOM DrD6/19zswo+efLTMivzmLP7QtXDMgvh8425hyQaraUCPzM5C/3NRbE1kxehsQ1Tjx w8Cecwul+ots7Dd1qxWMZ2XNYPQyhuMzqFyyjoWUXGBFRkSW/mSbUCdnXepfWiCZx/ 6nDEduKSY8BaqJyE3HZvgGuEiyXczGaTaVN2zc2bcn3L25Mr1OiVdhHj9XV8QJiOTo GfQOXo8uWofYGTZ6XebzW7YG5NuUeHYj7c/ZX8Vxlxh/QqZEuZZMvMsGVtpcn5SQ65 6JRN/47oRIStQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YYqGg3pnyz6twV; Thu, 16 Jan 2025 18:14:19 +0100 (CET) From: Thierry Volpiatto To: Eli Zaretskii Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) In-Reply-To: <864j1yhfp8.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 16 Jan 2025 18:43:47 +0200") References: <87zfk6eekc.fsf@posteo.net> <87h669vjm9.fsf@posteo.net> <8634ht4fkd.fsf@gnu.org> <87sept5s67.fsf@posteo.net> <86y0zl2yix.fsf@gnu.org> <878qrjnrdz.fsf@posteo.net> <864j1yhfp8.fsf@gnu.org> Date: Thu, 16 Jan 2025 17:20:44 +0000 Message-ID: <87v7uebrpv.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75354-done Cc: Thierry Volpiatto , 75354-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Eli Zaretskii writes: >> From: Thierry Volpiatto >> Cc: Thierry Volpiatto , 75354@debbugs.gnu.org >> Date: Fri, 10 Jan 2025 05:56:40 +0000 >>=20 >> Find here the last patch attached. > > Thanks, installed on the master branch, and closing the bug. Great thanks! =2D-=20 Thierry --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHHBAEBCgAxFiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmeJP+wTHHRoaWV2b2xA cG9zdGVvLm5ldAAKCRAOxW0UHRbvk5iuDACVe8JVyxubKyU1Xw2hj5X1DaGUgJE3 9VpZhwd02TEclZhr93uhDviH1mtNb/u8GJXWcINml7w9bkwdhpeKtu9SmFpxZZ/8 wgxt9b34963kbIOtAhnO4tz5UO1Mrkm1BJZ4SBEN8BxwqDP4/5XDSskKPkw1Axrj Dk74BSjcaV9tHHXKPk79qM14So3YFQn7204TPVUSJTqv/UpbfEZSE0FY3w/ifDhp zAj4xXto51d24CNGoH85nBPWL1vT7k7lgBjOc5IUUOvSHPcVCC5cq124yJYEWvF0 247unW9S11L9AKnMMosK+uR2u5WvBNw23ITkKRKNpGowYU1DyjpA8Yua0rEBiZHg BxKdym9H7zdqB+4eB20t1fdyFO6SSlxL+LX1xMFA3GsgVnidxLww/MKTXSmolN+Z VUBsRjZMUuudrV3u+5YO/3Vx9f8hkepyndgwCv30TiGYugM00vwCCnziRv9r+UoE S07CV3QYdOICg51G3pxlgosUw4xtg/3yuW0= =CdLq -----END PGP SIGNATURE----- --=-=-=-- From unknown Sat Jun 21 05:14:57 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 14 Feb 2025 12:24:16 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 13 14:53:49 2025 Received: (at control) by debbugs.gnu.org; 13 Mar 2025 18:53:49 +0000 Received: from localhost ([127.0.0.1]:58131 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tsnge-0003Dr-D0 for submit@debbugs.gnu.org; Thu, 13 Mar 2025 14:53:49 -0400 Received: from mail-ua1-x931.google.com ([2607:f8b0:4864:20::931]:43010) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tsngb-0003DY-Eu for control@debbugs.gnu.org; Thu, 13 Mar 2025 14:53:41 -0400 Received: by mail-ua1-x931.google.com with SMTP id a1e0cc1a2514c-860f0e91121so2159799241.0 for ; Thu, 13 Mar 2025 11:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741892015; x=1742496815; darn=debbugs.gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=2eO0hEo0kgFquc/pB/jLqV7t4Wk2n/AuzaKRUA0ErSQ=; b=kF6lVJYWMk1WhilhqNzG9qShDsR3sF5aZnJoFJQO9lyJxS4zwTOymIFqf3+seSI8q7 WPYfQDy9NJRsnM6CUGo1vmTjjHgBLSGcdW/uMONevdfxqfaarZjGEwRuNjN4lXcscgqc cqDev/rvbbR95NkwhshTWRPkWlTlA+jfXDt3G4xfodTq6ZpbjKILc+Qd0KS/mtMDKK5G qLt59evePtRVXMqxhub6Bbvn+oPc3Y/WwoUXXX6R67IMK5oSH/aIbtWHeeX4zevtyP2/ rCToZlDbq8VcVUzcC7yM1CJJ4Xg6t7rlGG5yNtWhXsxrieNBCrsWa/paqS7Lpi23Ztdh ZzPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741892015; x=1742496815; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=2eO0hEo0kgFquc/pB/jLqV7t4Wk2n/AuzaKRUA0ErSQ=; b=or7KiIEPEUXy3hAlDfMyws6zVrtpTmMV2dgtnVTGVSBLtij189h0nLAEIIZVvqxK7W zidCpYmerZese4OuK3Pl2+QFKaEXQon1cbuphAcZusd9d73STuCu4MKFkP4ZcoDNtLl/ 5MuY+52SiDR3cAx+jPT8z31O0ULoSyQ5OW/mH0O80JGkqqcoBD7MrDFXlOjosEB1+KN4 yMP38EUzLx9FiMZEfSMHFxPZgK/ST8EIqXqeLozX0S2bbeOzvKJ5uIjHy70IfHNyIbab 5dPbiJLM9qXfRyfTnhUdyiFo6JQnWW05Co9U8ddPKOvB0JTlK8KNFE3m646ViofyHr9y uqrQ== X-Gm-Message-State: AOJu0Yxhb7jCGMwXPmcxoJllxAhSH7FLwOzvaD8ztzhFRwfoc80BeQWq w10FgeCNmMG5fn50AVo7HWGyMjxgSh6PzmpXWKz8H8+fOA5Zw6AJxAHgwyK7aJ3FLOeVN0nRMUi 7Iczpo1H078DddoBjg6Xk4QZ/0QFET6rs X-Gm-Gg: ASbGncsk7masoaXg5rtPc3VSfsDhQ4qfe4Jd5KOlQo2FlZ4/sXLnnKfDBW0Gt7iqctl iOxjwydxYqQfxN24MDyV2TmX6hws/eNS0qjZ+Zb5qVZTvYQdQr+zsVh+HQJWU4i9v4eVrAGSgZX RQ465a8oefWDb6poZ5IoOT274ipA== X-Google-Smtp-Source: AGHT+IE7nXXzhbbdoduy+RiIva0Z35jLXBpjT6kArLJLKTBI74gekqbRPwg1fE1cB3xT/inHpnT4g/Pab7N+l590FrM= X-Received: by 2002:a05:6102:3752:b0:4c2:fccb:a647 with SMTP id ada2fe7eead31-4c371bc66a6mr4516401137.5.1741892015408; Thu, 13 Mar 2025 11:53:35 -0700 (PDT) MIME-Version: 1.0 From: Ship Mints Date: Thu, 13 Mar 2025 14:53:24 -0400 X-Gm-Features: AQ5f1Jr0vZRofX-rE7fJ7h-YCiPRYg3V5UqzYXEA28RRaKyrqlcjUvbOJgeu_Es Message-ID: Subject: To: control@debbugs.gnu.org Content-Type: multipart/alternative; boundary="000000000000d0cc8806303dd6b9" X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: unarchive 75354 unarchive 75354 Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2607:f8b0:4864:20:0:0:0:931 listed in] [list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (shipmints[at]gmail.com) 0.0 HTML_MESSAGE BODY: HTML included in message 2.0 BLANK_SUBJECT Subject is present but empty 0.0 TVD_SPACE_RATIO No description available. X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) --000000000000d0cc8806303dd6b9 Content-Type: text/plain; charset="UTF-8" unarchive 75354 --000000000000d0cc8806303dd6b9 Content-Type: text/html; charset="UTF-8"
unarchive 75354
--000000000000d0cc8806303dd6b9-- From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 13 15:22:07 2025 Received: (at submit) by debbugs.gnu.org; 13 Mar 2025 19:22:07 +0000 Received: from localhost ([127.0.0.1]:58207 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tso86-0007qJ-PJ for submit@debbugs.gnu.org; Thu, 13 Mar 2025 15:22:07 -0400 Received: from lists.gnu.org ([2001:470:142::17]:52378) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tso85-0007pZ-CY for submit@debbugs.gnu.org; Thu, 13 Mar 2025 15:22:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tso7z-0002CR-NL for bug-gnu-emacs@gnu.org; Thu, 13 Mar 2025 15:21:59 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tso7x-0000mE-2L for bug-gnu-emacs@gnu.org; Thu, 13 Mar 2025 15:21:58 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id A452D240103 for ; Thu, 13 Mar 2025 20:21:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1741893712; bh=Z2EpcISl3Bxhv3gLEvi6qKiVwqO7lBsAXzJS7nDXv5w=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=CWRWpLwggjRU+GiFKaudkF5G/9+ABlJ8hcVjFNX+nFbhM15IE6aGrBgU/rkptL09I sk3DT7y8G3CCG7Vo1fCXcFmqYU+1H9gE0Hvqg2PqAe7DUZ4LHLV9n8idalioqBGJhC V31hhCbSDJgfZo4ngKmct+/y1RZnnqrlMX32qnQ4lLB1vKE3aQuDOMW6XeM9CY7gNu b4kmYohGS5yAD6X6tNbbhHuefu9lqy3+9GkkBFEV8j9tWzklFChBwhmG+bFE3oeid6 GQFtclE2rmwOF4RflYQ/Hc7qfZaiaX64grNZv//BXVUbDTuAwM1RSxyEQRtB4KuIB+ lpQPBuLiwWmGQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4ZDHRy18lQz9rxP; Thu, 13 Mar 2025 20:21:49 +0100 (CET) From: Thierry Volpiatto To: Ship Mints Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) In-Reply-To: (Ship Mints's message of "Thu, 13 Mar 2025 14:50:44 -0400") References: Date: Thu, 13 Mar 2025 19:29:13 +0000 Message-ID: <874izwn306.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=185.67.36.66; envelope-from=thievol@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Thierry Volpiatto , Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ship Mints writes: >> From: Thierry Volpiatto >> Cc: Thierry Volpiatto , 75354@debbugs.gnu.org >> Date: Wed, 08 Jan 2025 13:52:32 +0000 >>=20 >> > This is contrary to what you originally wrote (with which I agree): >>=20 >> Yes, after deeper search I found that `bookmark--jump-via` is behaving >> like this AFAIU: >> - It calls the handler which creates a new buffer related to bookmark. >> - It then displays the current-buffer (the one before jumping to bmk) in >> a window according to DISPLAY-FUNCTION and make the bookmark buffer cur= rent. >>=20 >> This approach is OK as long as the handler fn doesn't try do do one part >> of the job (window handling) itself, which is not the case at least with >> eww and w3m. It is as well counter intuitive, DISPLAY-FUNCTION should >> be called on the buffer generated by bookmark and not the contrary, so >> this change makes the code simpler and easier to understand. >>=20 >> > By contrast, the change you propose now will affect all the uses of >> > bookmarks, everywhere, >>=20 >> Yes, this is intended, in addition of fixing eww, it fixes w3m and also >> the quit function of eww (actually broken). >>=20 >> > which is riskier, given how many different variants of bookmark usage >> > are out there. >>=20 >> Tested here on many different kinds of bookmarks and work as expected >> unlike the current code. > > It took me a while to find time to focus on some bugs with Emacs 31 in > my workflow (reverting to Emacs 30 until I had time). > > I discovered that this change breaks all bookmark handlers that rely > on managing window-state or window-configuration. Which bookmark handlers? > I have no workaround yet this until we fix it, I have to do screwy > things to make 'bookmark--jump-via' ignore 'save-window-excursion'. > > What's the rationale for wrapping 'bookmark-handle-bookmark' with > 'save-window-excursion'? 1) The bookmark handler function setup a buffer. 2) When this buffer is ready we jump to this buffer with DISPLAY-FUNCTION. If you don't save the window excursion in 1) and buffer is not ready, the DISPLAY-FUNCTION may run from the buffer that was current before calling the handler function. Previously we were calling DISPLAY-FUNCTION on current-buffer, assuming the handler fn had switched to a new buffer which should be current, when the new buffer was not current we were swicthing to the current-buffer the one that was current just before as explained above. So this change has fixed not only eww but some other bookmarks (like w3m). =20=20 > If this behavior is truly necessary (I'd like understand the use > case), I suggest binding a new defvar to bind and trigger this > behavior rather than affect all bookmark handlers. Unless eww can be > fixed. It could handle window configuration management in its own > bookmark handler. That's the point, you should not handle window management in your bookmark handler, this defeat bookmark--jump-via DISPLAY-FUNCTION. This change also fixes old bugs where people were trying various things in their bookmark handlers to get things right including polling or running code under a timer etc... > I'm happy to provide a patch once we agree on an approach. > > -Stephane =2D-=20 Thierry --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHHBAEBCgAxFiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmfTMgoTHHRoaWV2b2xA cG9zdGVvLm5ldAAKCRAOxW0UHRbvk00BDAC8xJF6qWMr1uvE2jXJuI6beXFTp2VO b2tV6CmqCV5Dvh7I/6YzBYmipYeZdDeQkMD2VfgOXDqz9UQP5ZEn15Q0gUuRgkz5 hS4dRksgSIWWzQMmojxh1JxaN+wLO4xLoOLfRLNF9qKmspppb+PiGUitquY+7q+r BEXB8xFQqEQ76wDS4hPRCt7fX1Vjvj3tIDTMsVUgufmqcZmEUt6+Y2qCoR9S9jyS bQhM3G+bWxAiN6H7LZa2nbmLqKfiWzQS1oUKk4mMJgKOTQdc9ft+tFkRtiZyeDje CFXt+AhtqXje6ayRWfOAXnBoHTdJVyVYaq0mrYmWw4BBUbZQwrdmklK24esUhEsx RH+2FG+mZDiTybLVF79DbKd7k9zaWFFxGCyiHg4We4qTiAbCXXVHJz5+V8T+8v19 8jULCuHccsekzknc6lPkWrJ7iIStfX/unYYr9wPgWyZ9SRzg51Qah1fBfaRsUMBb 5SZboS1mZ/AY04pGJBbiqpfDmPOpxf3Epro= =hKrH -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 13 15:35:04 2025 Received: (at submit) by debbugs.gnu.org; 13 Mar 2025 19:35:04 +0000 Received: from localhost ([127.0.0.1]:58245 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tsoKd-0008U3-8f for submit@debbugs.gnu.org; Thu, 13 Mar 2025 15:35:04 -0400 Received: from lists.gnu.org ([2001:470:142::17]:37874) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tsoKZ-0008TF-N7 for submit@debbugs.gnu.org; Thu, 13 Mar 2025 15:35:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tsoJy-0006qe-9t for bug-gnu-emacs@gnu.org; Thu, 13 Mar 2025 15:34:33 -0400 Received: from mail-ua1-x934.google.com ([2607:f8b0:4864:20::934]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tsoJv-0002Om-OI; Thu, 13 Mar 2025 15:34:21 -0400 Received: by mail-ua1-x934.google.com with SMTP id a1e0cc1a2514c-86d5e42c924so1216172241.3; Thu, 13 Mar 2025 12:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741894457; x=1742499257; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=VDHN6eQUxlHP8Jk10H9yQ2MoWsCuSPSbFmnilaaybYc=; b=U3N2N9XCAIRVl62UA6g9NXTmkksO9gvyY6LqqcvpY7zuDxsGM8hZzF7dbAiJxCzt9P ElYo1A9Pkxo1QYgOWF2dYh1LXpKna1J9RPhtiDy7VRfrlNZbmZ6plQKQ/Tecpgsye9YL knBHwY5fNLKyafYU3QEG5v0JFxs1I+Lx0TZbt5uhp1cyu51eKQ8LrLh9JNTD0eqIvJAw qUlDQLvdMzlpoAjwE0Z9vDV2aWzINQBdPLvRkTAjxIQAKVweGZE3+ejwyrB8ELNllPVd 5jwJ6DoUBcAYj0HMc6E1Mite+BnCNU4a/np1zw1Ft3jjLOmcqux1rhIL0wKEGujq719a JLxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741894457; x=1742499257; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VDHN6eQUxlHP8Jk10H9yQ2MoWsCuSPSbFmnilaaybYc=; b=Srg4VoPl846pmHa7/zQGH6map2KtsGrsIl8S8zieSqtRfdcct6aT8a1l0yV+ZysTTJ FcRQ8LHvXYpiiLL6r0HyDHVUGhF34YhiBFTkVSwmzts2WZWtwEIwOPpi+PSs4bUiKj7y qskXxYxC0WtdSbEPbLvEkBP7uEzjJ4Pr6AfrhxmvGKx0pMi617Lqnvd46Z0TcV39EwX+ NIGxF6nwPl2tkK4erKIvzs6BIakTXhU9UeSPflzMVWCb0t7zMfe7CZ+tXrO5kdEXAT91 5KzojIM57LR3Ka5ca9WejVvc2OVLm9ZBHCLRGbFDTBInCBHjrmZnwbPTQaJwkF42YDML lZww== X-Forwarded-Encrypted: i=1; AJvYcCU1Lz3xhdU8pOaohN2NTC+De9I87nZlq3H4iVzxxd1q1TnVbXPyawCUfVzp5dbwC5HelJkvairCGHQ0sqaS@gnu.org X-Gm-Message-State: AOJu0Yy+wWWRBjSD40EX8HSwt/3dujaTgm1+jJItnAJwE88tjgq619W9 Ly4JH7XMrT27mNG3sn6AIPX8k0waOR89puN05VKVzCt+XWQrxpqngIV/PqYjQIMZMLWTxb7qY4U KJHlzQ6fxUlzmCn6PEMuRVp8ndJI= X-Gm-Gg: ASbGncvFXLj0u08hLAW52gS+jN9ouOplAUneUfCLlBxITE8wR07A8q8h9blz9g9ataT CLDCCX7OlmDj/pMLKM+UlgzadHgqiXOBrJAytJIjLoOkvBM/DTl344lJ/0XWBh3a++xxEEMgzb2 dOTmwTD/7V0B1FfEIUUHqsk5xf6w== X-Google-Smtp-Source: AGHT+IGnwc7nBJuTjk3fNFyoLDVaQyfzZHfJauGDlI4mmjm4OEHxRiwvyPKhtRiIAkUAcM869gA/6maUSZ+4v7axGu8= X-Received: by 2002:a05:6102:442c:b0:4c3:6544:c250 with SMTP id ada2fe7eead31-4c37ee3f892mr2153711137.23.1741894457031; Thu, 13 Mar 2025 12:34:17 -0700 (PDT) MIME-Version: 1.0 References: <874izwn306.fsf@posteo.net> In-Reply-To: <874izwn306.fsf@posteo.net> From: Ship Mints Date: Thu, 13 Mar 2025 15:34:04 -0400 X-Gm-Features: AQ5f1Job9ESzjuqBGrvoTHoX2_JR01dia4ZGSiSrW0oMOhnWso-PlJH3lP77VJk Message-ID: Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) To: Thierry Volpiatto Content-Type: multipart/alternative; boundary="00000000000059045f06303e68a6" Received-SPF: pass client-ip=2607:f8b0:4864:20::934; envelope-from=shipmints@gmail.com; helo=mail-ua1-x934.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --00000000000059045f06303e68a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 13, 2025 at 3:21=E2=80=AFPM Thierry Volpiatto wrote: > Ship Mints writes: > > >> From: Thierry Volpiatto > >> Cc: Thierry Volpiatto , 75354@debbugs.gnu.org > >> Date: Wed, 08 Jan 2025 13:52:32 +0000 > >> > >> > This is contrary to what you originally wrote (with which I agree): > >> > >> Yes, after deeper search I found that `bookmark--jump-via` is behaving > >> like this AFAIU: > >> - It calls the handler which creates a new buffer related to bookmark= . > >> - It then displays the current-buffer (the one before jumping to bmk) > in > >> a window according to DISPLAY-FUNCTION and make the bookmark buffer > current. > >> > >> This approach is OK as long as the handler fn doesn't try do do one pa= rt > >> of the job (window handling) itself, which is not the case at least wi= th > >> eww and w3m. It is as well counter intuitive, DISPLAY-FUNCTION should > >> be called on the buffer generated by bookmark and not the contrary, so > >> this change makes the code simpler and easier to understand. > >> > >> > By contrast, the change you propose now will affect all the uses of > >> > bookmarks, everywhere, > >> > >> Yes, this is intended, in addition of fixing eww, it fixes w3m and als= o > >> the quit function of eww (actually broken). > >> > >> > which is riskier, given how many different variants of bookmark usag= e > >> > are out there. > >> > >> Tested here on many different kinds of bookmarks and work as expected > >> unlike the current code. > > > > It took me a while to find time to focus on some bugs with Emacs 31 in > > my workflow (reverting to Emacs 30 until I had time). > > > > I discovered that this change breaks all bookmark handlers that rely > > on managing window-state or window-configuration. > > Which bookmark handlers? At least these packages rely on bookmarks that store window state and their handlers restore window state. There are workarounds I have considered but they are distasteful, to say the least. bufferlo activities burly I help maintain bufferlo and this change broke bookmarks for all our users who have tried master, including me. > I have no workaround yet this until we fix it, I have to do screwy > > things to make 'bookmark--jump-via' ignore 'save-window-excursion'. > > > > What's the rationale for wrapping 'bookmark-handle-bookmark' with > > 'save-window-excursion'? > > 1) The bookmark handler function setup a buffer. > 2) When this buffer is ready we jump to this buffer with > DISPLAY-FUNCTION. > > If you don't save the window excursion in 1) and buffer is not ready, > the DISPLAY-FUNCTION may run from the buffer that was current before > calling the handler function. > Emacs is single threaded. What does it mean for a buffer to "not be ready?= " Previously we were calling DISPLAY-FUNCTION on current-buffer, assuming > the handler fn had switched to a new buffer which should be current, > when the new buffer was not current we were swicthing to the > current-buffer the one that was current just before as explained above. > > So this change has fixed not only eww but some other bookmarks (like > w3m). > Yes, you said in the original bug report. > If this behavior is truly necessary (I'd like understand the use > > case), I suggest binding a new defvar to bind and trigger this > > behavior rather than affect all bookmark handlers. Unless eww can be > > fixed. It could handle window configuration management in its own > > bookmark handler. > > That's the point, you should not handle window management in your > bookmark handler, this defeat bookmark--jump-via DISPLAY-FUNCTION. > Yes, we should handle window configurations. Bookmarks are not limited to just files or URLs. Any new limitations imposed on bookmarks that assume so makes bookmarks worse, not better. This change also fixes old bugs where people were trying various things > in their bookmark handlers to get things right including polling or > running code under a timer etc... > Right. Those are some of the distasteful workarounds that Adam Porter had to resort to for activities in an effort to work around display-function and now he has to deal with window-save-excursion restoring the the window configuration *from our own calling sites*. If you think the new behavior should be limited to interactive use, I could perhaps understand that, but I still would suggest a defvar to control this so those of us who use bookmarks programmatically can still do so. -Stephane --00000000000059045f06303e68a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Thu, Mar 13, 2025 at 3:21=E2=80=AFPM Thierry Volpiatto <thievol@posteo.net> wrote:
Ship Mints <shipmints@gmail.com> writes:

>> From: Thierry Volpiatto <thievol@posteo.net>
>> Cc: Thierry Volpiatto <thievol@posteo.net>,=C2=A0 75354@debbugs.gnu.org
>> Date: Wed, 08 Jan 2025 13:52:32 +0000
>>
>> > This is contrary to what you originally wrote (with which I a= gree):
>>
>> Yes, after deeper search I found that `bookmark--jump-via` is beha= ving
>> like this AFAIU:
>>=C2=A0 - It calls the handler which creates a new buffer related to= bookmark.
>>=C2=A0 - It then displays the current-buffer (the one before jumpin= g to bmk) in
>>=C2=A0 a window according to DISPLAY-FUNCTION and make the bookmark= buffer current.
>>
>> This approach is OK as long as the handler fn doesn't try do d= o one part
>> of the job (window handling) itself, which is not the case at leas= t with
>> eww and w3m.=C2=A0 It is as well counter intuitive, DISPLAY-FUNCTI= ON should
>> be called on the buffer generated by bookmark and not the contrary= , so
>> this change makes the code simpler and easier to understand.
>>
>> > By contrast, the change you propose now will affect all the u= ses of
>> > bookmarks, everywhere,
>>
>> Yes, this is intended, in addition of fixing eww, it fixes w3m and= also
>> the quit function of eww (actually broken).
>>
>> > which is riskier, given how many different variants of bookma= rk usage
>> > are out there.
>>
>> Tested here on many different kinds of bookmarks and work as expec= ted
>> unlike the current code.
>
> It took me a while to find time to focus on some bugs with Emacs 31 in=
> my workflow (reverting to Emacs 30 until I had time).
>
> I discovered that this change breaks all bookmark handlers that rely > on managing window-state or window-configuration.

Which bookmark handlers?

At least these packages rely on bookma= rks that store window state and their handlers restore window state.=C2=A0 = There are workarounds I have considered but they are distasteful, to say th= e least.

bufferlo
activities
burly

I help maintain bufferlo and this c= hange broke bookmarks for all our users who have tried master, including me= .

> I have no workaround yet this until we fix it, I have to do screwy
> things to make 'bookmark--jump-via' ignore 'save-window-ex= cursion'.
>
> What's the rationale for wrapping 'bookmark-handle-bookmark= 9; with
> 'save-window-excursion'?

1) The bookmark handler function setup a buffer.
2) When this buffer is ready we jump to this buffer with
DISPLAY-FUNCTION.

If you don't save the window excursion in 1) and buffer is not ready, the DISPLAY-FUNCTION may run from the buffer that was current before
calling the handler function.

Emacs is single threade= d.=C2=A0 What does it mean for a buffer to "not be ready?"
<= /div>

Previously we were calling DISPLAY-FUNCTION on current-buffer, assuming
the handler fn had switched to a new buffer which should be current,
when the new buffer was not current we were swicthing to the
current-buffer the one that was current just before as explained above.

So this change has fixed not only eww but some other bookmarks (like
w3m).

Yes, you said in the original bug report.

> If this behavior is truly necessary (I'd like understand the use > case), I suggest binding a new defvar to bind and trigger this
> behavior rather than affect all bookmark handlers.=C2=A0 Unless eww ca= n be
> fixed.=C2=A0 It could handle window configuration management in its ow= n
> bookmark handler.

That's the point, you should not handle window management in your
bookmark handler, this defeat bookmark--jump-via DISPLAY-FUNCTION.

Yes, we should handle window configurations.=C2=A0 Bookmarks = are not limited to just files or URLs.=C2=A0 Any new limitations imposed on= bookmarks that assume so makes bookmarks worse, not better.

This change also fixes old bugs where people were trying various things
in their bookmark handlers to get things right including polling or
running code under a timer etc...

Right.=C2=A0 Those are s= ome of the distasteful workarounds that Adam Porter had to resort to for ac= tivities in an effort to work around display-function and now he has to dea= l with window-save-excursion restoring the the window configuration *from o= ur own calling sites*.=C2=A0 If you think the new behavior should be limite= d to interactive use, I could perhaps understand that, but I still would su= ggest a defvar to control this so those of us who use bookmarks programmati= cally can still do so.

-Stephane
--00000000000059045f06303e68a6-- From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 13 15:48:38 2025 Received: (at submit) by debbugs.gnu.org; 13 Mar 2025 19:48:38 +0000 Received: from localhost ([127.0.0.1]:58271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tsoXl-0000oC-Db for submit@debbugs.gnu.org; Thu, 13 Mar 2025 15:48:38 -0400 Received: from lists.gnu.org ([2001:470:142::17]:39368) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tsoXi-0000nq-G3 for submit@debbugs.gnu.org; Thu, 13 Mar 2025 15:48:35 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tsoXY-0004gl-K1 for bug-gnu-emacs@gnu.org; Thu, 13 Mar 2025 15:48:26 -0400 Received: from mail-ua1-x92b.google.com ([2607:f8b0:4864:20::92b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tsoXT-0003vq-Rs; Thu, 13 Mar 2025 15:48:21 -0400 Received: by mail-ua1-x92b.google.com with SMTP id a1e0cc1a2514c-8670fd79990so559406241.3; Thu, 13 Mar 2025 12:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741895297; x=1742500097; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FaTmSR7CHBqSO80NZmIf3zb54kJIhYewEts/pgN+VrE=; b=RSX/VqDZeOc3Ci3hy7BYCMXlEvZFE+L4WJiGncB8UwrxLJLwTV65HnwRKKtSUmHXSm v4izPdJgcD5CWALePknd72Jwxfa+Vfhzq1kvhZ1BiIAUhEGZLo2lujYXKD2Q/AWubdLk 6w2AIYI9Vi84q3HdaqTyT/sAu46h5K4wXV4+8/5sP2wbncjP+78L4MWp5XHsgzvva2Dg Ya5gj7cnP0OWrC4bV0nnrkELLTFMg8QqSSzKABY7YbQI7h4CvuF661C/OWARaZqvxxNh aJFQZ5MFrwS0q7H9w+n3mcLLMbgddlkcN613ACHwymVW8HklsyyYeVFlcm7DPaHWtBZx IS5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741895297; x=1742500097; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FaTmSR7CHBqSO80NZmIf3zb54kJIhYewEts/pgN+VrE=; b=NeNSP2AuXmuvr0MZjcf7QHajlNrZW+kSmioq3DR+By9TyWiJfOYjKE2fGCFEb2W60S JoLGhc3KCQ6ang8uarp29S7UM3zNHd1H2n6fMf9OUJ1v8eCekTKXuxa3xqO6mmlyZdIb weFNKVikH+/9g8mfBET7zEDcJUX+IdmT7jdQm0SpwTYr9nRYVeqecFl5Y/SUiFWx1Akc ZprWZvgQ+viHYiVNsciXTA/xUWdgvzDQb4sBWCSCau2dbhfKnrj//bgHXWPNbfatmWYi 9ZU92n0l3DIX/WDSUjOQuniRUspX0JQ8MMbHjHav2N58wNDFEOAojbIkZfeGF71YZjM5 fvnw== X-Forwarded-Encrypted: i=1; AJvYcCUvYgYa1ktCsvAdxhiOuDR95XEjXgnyG5gS0FFDHBH1F6iFkMAsAWUyYi1bzmOwZ1RDxLzhYcWFC/MN6Ndn@gnu.org X-Gm-Message-State: AOJu0YxgP2OGRNPEDuPnfNlWqXWlDYRTguaT9DVXycbzbZCWNK8GABRK B4cvmA5wWn8UQYdW0bDmRyjhmN2jrJlR8n36euNqDo2TAeDIFncmQvw3d8IzGk/E/dadRcz2mUG 0xlFPm0Mzcn4Q1/+1Blh8vyoXrGl2Kg== X-Gm-Gg: ASbGnctq6VF4RmPAifFGS94ZtbuSeJfGQ98fVqhzD7plMkmX9QzZPQ68RiIQN2hMYgP 9CmuFeZihDe3HZf5DGdHj1jfJ02yVmWbFHpl03ddrKVmcAdg7ju/1ODG3CBMypx4Hv7UG+H+av2 kK8JBaptH7g9VtO4OjET275RBLsg== X-Google-Smtp-Source: AGHT+IGHEMzVVrzAKDh+tsseeRqlBkSQuLaduJcdNHaUGAFT4IJ6DrApbAZ9iv4nUfTRSwka0MYyrsm96tmOPOov5n8= X-Received: by 2002:a05:6102:8028:b0:4c2:4b08:12e3 with SMTP id ada2fe7eead31-4c37ec7fab6mr2090827137.14.1741895296876; Thu, 13 Mar 2025 12:48:16 -0700 (PDT) MIME-Version: 1.0 References: <874izwn306.fsf@posteo.net> In-Reply-To: From: Ship Mints Date: Thu, 13 Mar 2025 15:48:04 -0400 X-Gm-Features: AQ5f1JpXUzS4Rk4AwhPJ2Z8-54uKJQ2CgY0ROlbLFSJG6ByiGLbiCq20ANJH4eE Message-ID: Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) To: Thierry Volpiatto Content-Type: multipart/alternative; boundary="00000000000068061206303e9a30" Received-SPF: pass client-ip=2607:f8b0:4864:20::92b; envelope-from=shipmints@gmail.com; helo=mail-ua1-x92b.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --00000000000068061206303e9a30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 13, 2025 at 3:34=E2=80=AFPM Ship Mints wr= ote: > On Thu, Mar 13, 2025 at 3:21=E2=80=AFPM Thierry Volpiatto > wrote: > >> Ship Mints writes: >> >> >> From: Thierry Volpiatto >> >> Cc: Thierry Volpiatto , 75354@debbugs.gnu.org >> >> Date: Wed, 08 Jan 2025 13:52:32 +0000 >> >> >> >> > This is contrary to what you originally wrote (with which I agree): >> >> >> >> Yes, after deeper search I found that `bookmark--jump-via` is behavin= g >> >> like this AFAIU: >> >> - It calls the handler which creates a new buffer related to bookmar= k. >> >> - It then displays the current-buffer (the one before jumping to bmk= ) >> in >> >> a window according to DISPLAY-FUNCTION and make the bookmark buffer >> current. >> >> >> >> This approach is OK as long as the handler fn doesn't try do do one >> part >> >> of the job (window handling) itself, which is not the case at least >> with >> >> eww and w3m. It is as well counter intuitive, DISPLAY-FUNCTION shoul= d >> >> be called on the buffer generated by bookmark and not the contrary, s= o >> >> this change makes the code simpler and easier to understand. >> >> >> >> > By contrast, the change you propose now will affect all the uses of >> >> > bookmarks, everywhere, >> >> >> >> Yes, this is intended, in addition of fixing eww, it fixes w3m and al= so >> >> the quit function of eww (actually broken). >> >> >> >> > which is riskier, given how many different variants of bookmark usa= ge >> >> > are out there. >> >> >> >> Tested here on many different kinds of bookmarks and work as expected >> >> unlike the current code. >> > >> > It took me a while to find time to focus on some bugs with Emacs 31 in >> > my workflow (reverting to Emacs 30 until I had time). >> > >> > I discovered that this change breaks all bookmark handlers that rely >> > on managing window-state or window-configuration. >> >> Which bookmark handlers? > > > At least these packages rely on bookmarks that store window state and > their handlers restore window state. There are workarounds I have > considered but they are distasteful, to say the least. > > bufferlo > activities > burly > > I help maintain bufferlo and this change broke bookmarks for all our user= s > who have tried master, including me. > > > I have no workaround yet this until we fix it, I have to do screwy >> > things to make 'bookmark--jump-via' ignore 'save-window-excursion'. >> > >> > What's the rationale for wrapping 'bookmark-handle-bookmark' with >> > 'save-window-excursion'? >> >> 1) The bookmark handler function setup a buffer. >> 2) When this buffer is ready we jump to this buffer with >> DISPLAY-FUNCTION. >> >> If you don't save the window excursion in 1) and buffer is not ready, >> the DISPLAY-FUNCTION may run from the buffer that was current before >> calling the handler function. >> > > Emacs is single threaded. What does it mean for a buffer to "not be > ready?" > > Previously we were calling DISPLAY-FUNCTION on current-buffer, assuming >> the handler fn had switched to a new buffer which should be current, >> when the new buffer was not current we were swicthing to the >> current-buffer the one that was current just before as explained above. >> >> So this change has fixed not only eww but some other bookmarks (like >> w3m). >> > > Yes, you said in the original bug report. > > > If this behavior is truly necessary (I'd like understand the use >> > case), I suggest binding a new defvar to bind and trigger this >> > behavior rather than affect all bookmark handlers. Unless eww can be >> > fixed. It could handle window configuration management in its own >> > bookmark handler. >> >> That's the point, you should not handle window management in your >> bookmark handler, this defeat bookmark--jump-via DISPLAY-FUNCTION. >> > > Yes, we should handle window configurations. Bookmarks are not limited t= o > just files or URLs. Any new limitations imposed on bookmarks that assume > so makes bookmarks worse, not better. > > This change also fixes old bugs where people were trying various things >> in their bookmark handlers to get things right including polling or >> running code under a timer etc... >> > > Right. Those are some of the distasteful workarounds that Adam Porter ha= d > to resort to for activities in an effort to work around display-function > and now he has to deal with window-save-excursion restoring the the windo= w > configuration *from our own calling sites*. If you think the new behavio= r > should be limited to interactive use, I could perhaps understand that, bu= t > I still would suggest a defvar to control this so those of us who use > bookmarks programmatically can still do so. > In fact, it would be even better to optionally inhibit both save-window-excursion and display-function. As it is, programmatically, we invoke bookmark-jump with #'ignore as the display-function. --00000000000068061206303e9a30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Thu, Mar 13, 2025 at 3:34=E2=80=AFPM Ship Mints <shipmints@gmail.com> wrote:
On = Thu, Mar 13, 2025 at 3:21=E2=80=AFPM Thierry Volpiatto <thievol@posteo.net> wrote:
Ship Mints <shipmints@gmail.com> writes:

>> From: Thierry Volpiatto <thievol@posteo.net>
>> Cc: Thierry Volpiatto <thievol@posteo.net>,=C2=A0 75354@debbugs.gnu.org
>> Date: Wed, 08 Jan 2025 13:52:32 +0000
>>
>> > This is contrary to what you originally wrote (with which I a= gree):
>>
>> Yes, after deeper search I found that `bookmark--jump-via` is beha= ving
>> like this AFAIU:
>>=C2=A0 - It calls the handler which creates a new buffer related to= bookmark.
>>=C2=A0 - It then displays the current-buffer (the one before jumpin= g to bmk) in
>>=C2=A0 a window according to DISPLAY-FUNCTION and make the bookmark= buffer current.
>>
>> This approach is OK as long as the handler fn doesn't try do d= o one part
>> of the job (window handling) itself, which is not the case at leas= t with
>> eww and w3m.=C2=A0 It is as well counter intuitive, DISPLAY-FUNCTI= ON should
>> be called on the buffer generated by bookmark and not the contrary= , so
>> this change makes the code simpler and easier to understand.
>>
>> > By contrast, the change you propose now will affect all the u= ses of
>> > bookmarks, everywhere,
>>
>> Yes, this is intended, in addition of fixing eww, it fixes w3m and= also
>> the quit function of eww (actually broken).
>>
>> > which is riskier, given how many different variants of bookma= rk usage
>> > are out there.
>>
>> Tested here on many different kinds of bookmarks and work as expec= ted
>> unlike the current code.
>
> It took me a while to find time to focus on some bugs with Emacs 31 in=
> my workflow (reverting to Emacs 30 until I had time).
>
> I discovered that this change breaks all bookmark handlers that rely > on managing window-state or window-configuration.

Which bookmark handlers?

At least these packages rely on bookmarks that store window st= ate and their handlers restore window state.=C2=A0 There are workarounds I = have considered but they are distasteful, to say the least.

bufferlo
activities
burly

I hel= p maintain bufferlo and this change broke bookmarks for all our users who h= ave tried master, including me.

> I have no workaround yet this until we fix it, I have to do screwy
> things to make 'bookmark--jump-via' ignore 'save-window-ex= cursion'.
>
> What's the rationale for wrapping 'bookmark-handle-bookmark= 9; with
> 'save-window-excursion'?

1) The bookmark handler function setup a buffer.
2) When this buffer is ready we jump to this buffer with
DISPLAY-FUNCTION.

If you don't save the window excursion in 1) and buffer is not ready, the DISPLAY-FUNCTION may run from the buffer that was current before
calling the handler function.

Emacs is single threaded.=C2=A0 What does it me= an for a buffer to "not be ready?"

Previously we were calling DISPLAY-FUNCTION on current-buffer, assuming
the handler fn had switched to a new buffer which should be current,
when the new buffer was not current we were swicthing to the
current-buffer the one that was current just before as explained above.

So this change has fixed not only eww but some other bookmarks (like
w3m).

Y= es, you said in the original bug report.

> If this behavior is truly necessary (I'd like understand the use > case), I suggest binding a new defvar to bind and trigger this
> behavior rather than affect all bookmark handlers.=C2=A0 Unless eww ca= n be
> fixed.=C2=A0 It could handle window configuration management in its ow= n
> bookmark handler.

That's the point, you should not handle window management in your
bookmark handler, this defeat bookmark--jump-via DISPLAY-FUNCTION.

Yes, we sh= ould handle window configurations.=C2=A0 Bookmarks are not limited to just = files or URLs.=C2=A0 Any new limitations imposed on bookmarks that assume s= o makes bookmarks worse, not better.

This change also fixes old bugs where people were trying various things
in their bookmark handlers to get things right including polling or
running code under a timer etc...

Right.=C2=A0 Those are some of the distasteful w= orkarounds that Adam Porter had to resort to for activities in an effort to= work around display-function and now he has to deal with window-save-excur= sion restoring the the window configuration *from our own calling sites*.= =C2=A0 If you think the new behavior should be limited to interactive use, = I could perhaps understand that, but I still would suggest a defvar to cont= rol this so those of us who use bookmarks programmatically can still do so.=

In fact, it would be even better to optiona= lly inhibit both save-window-excursion and display-function.=C2=A0 As it is= , programmatically, we invoke bookmark-jump with #'ignore as the displa= y-function.
--00000000000068061206303e9a30-- From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 13 15:56:42 2025 Received: (at submit) by debbugs.gnu.org; 13 Mar 2025 19:56:42 +0000 Received: from localhost ([127.0.0.1]:58291 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tsofZ-0001Gl-4Q for submit@debbugs.gnu.org; Thu, 13 Mar 2025 15:56:42 -0400 Received: from lists.gnu.org ([2001:470:142::17]:57392) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tsofW-0001GQ-2X for submit@debbugs.gnu.org; Thu, 13 Mar 2025 15:56:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tsofQ-0006oW-HB for bug-gnu-emacs@gnu.org; Thu, 13 Mar 2025 15:56:32 -0400 Received: from mail-ua1-x931.google.com ([2607:f8b0:4864:20::931]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tsofO-0005Bs-7Q; Thu, 13 Mar 2025 15:56:32 -0400 Received: by mail-ua1-x931.google.com with SMTP id a1e0cc1a2514c-867129fdb0aso1192442241.1; Thu, 13 Mar 2025 12:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741895787; x=1742500587; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0eILgSg+ZbQkNCpr4tklzJPjXfZErUDyEpeIo4pT/MY=; b=EIyDCH4AY7LNIbbUpvAXJ6meyYn+wXh0TAZvIjp0KL3qKj45t6Ic/GMm+ofBbUxYc7 VqRgCLK17UovpLHsbWcu/gBWNA7bccDl2PQuNQn1frYrkkYbX+3apAVYwhrqXtj+BDZ4 F6npP94iz/vX891a1Bs0xFYKpalG9r8rftkNBy+j+yK7I7cL/8Ez8f9sm/n95rIJSs7l QFsWoaB7rqqvh1U3cg6ZzGuWzWLfF12n4cxT8hnobhgfPFuG5hOVt68HBrCYv77sfDhD h3jRl+4GfI1e3TM4I2BWTbSZiGo5YbNsD5fWKMSP+Li1F4elEkEnQauCOkeZHtPja4ax a67g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741895787; x=1742500587; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0eILgSg+ZbQkNCpr4tklzJPjXfZErUDyEpeIo4pT/MY=; b=hWHG+IceHlr/nMLQqIqgNpGKICoj8L66wezmdIaY/A+KSpZGEasBzj6bJu0s+blkZN sglz876KBGHdLnNjtm68BOb6xxTXpHE0ixjGJ9PFrmw3ZwUhNIVDbV/4maR6zMGNtxDh 7xDJNqxxFnl3xCA612LdLJVPCeeUH0HkQUckkSDxNiO2+Lqq+1qyivGeJMnGqFUCVd4y Tjx6PA8aGeTz0Lg5T6Ek7k1xO2CqRdtcN2hbqIJ4HSiYUxVxlFnnXCRHFCdhtwByZkNq H3rMau5Fqf4ZGXYauUX4b1aRBSRs4wG6eMagmp2go4SHQlGTXPTktMX0RqU1jNSer9p9 s8yA== X-Forwarded-Encrypted: i=1; AJvYcCXzsqP1GX/libkWOkbeGX2c3/LoO/eQ0r+ETUZRqJVfsYc+c2/wl5Ga5gWiULw73C3NEQ0MPK9Cc4G4wPqg@gnu.org X-Gm-Message-State: AOJu0YzTFR8HiKVdmmP0CGGMnX0sGLFrqvN/h13l721cFA9d+TK3K95z 8T0cQZk8y3Gx/uTIe7UCqAUGc73baRFxw9tpABb/srm3agy17rrE1ZaEwnWYxtRDyGR8H+lpZ+2 xdtsztCwCbL80sAEUl2BMYorplQBDkA== X-Gm-Gg: ASbGncurWOJ8W6H6h8hluwJNBL9vIEnbmQuERFIi7x3P7/oCB/xtJnqiHk3708xWc/Z 930kHVhF8H5z7F0kVQeWLN9bsSUnwYsZ5XOwwtobvlwrOuesjDTSYiNDhDcrnGLE2LJouVEYEHb dip16k+f9QCU66i0R1vI/lnffCXQ== X-Google-Smtp-Source: AGHT+IGafpibtwkCW2RY9qbqRdB0TWnw+uHmsR4eq/ADnnXDzps37vgPyaHrAe0nH1EqQ1Uk3S0r4hVkfLdnhYFFJIQ= X-Received: by 2002:a05:6102:1505:b0:4bb:cbbc:4c with SMTP id ada2fe7eead31-4c34d1f80d0mr17280728137.2.1741895787643; Thu, 13 Mar 2025 12:56:27 -0700 (PDT) MIME-Version: 1.0 References: <874izwn306.fsf@posteo.net> In-Reply-To: From: Ship Mints Date: Thu, 13 Mar 2025 15:56:15 -0400 X-Gm-Features: AQ5f1JqhyMu3ew-4Xc19CeXvuHpcHzdZsJFfyVq-BzOntauMW-y-KdNSJr8618A Message-ID: Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) To: Thierry Volpiatto Content-Type: multipart/alternative; boundary="000000000000a88c2106303eb7d7" Received-SPF: pass client-ip=2607:f8b0:4864:20::931; envelope-from=shipmints@gmail.com; helo=mail-ua1-x931.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --000000000000a88c2106303eb7d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 13, 2025 at 3:48=E2=80=AFPM Ship Mints wr= ote: > On Thu, Mar 13, 2025 at 3:34=E2=80=AFPM Ship Mints = wrote: > >> On Thu, Mar 13, 2025 at 3:21=E2=80=AFPM Thierry Volpiatto >> wrote: >> >>> Ship Mints writes: >>> >>> >> From: Thierry Volpiatto >>> >> Cc: Thierry Volpiatto , 75354@debbugs.gnu.org >>> >> Date: Wed, 08 Jan 2025 13:52:32 +0000 >>> >> >>> >> > This is contrary to what you originally wrote (with which I agree)= : >>> >> >>> >> Yes, after deeper search I found that `bookmark--jump-via` is behavi= ng >>> >> like this AFAIU: >>> >> - It calls the handler which creates a new buffer related to >>> bookmark. >>> >> - It then displays the current-buffer (the one before jumping to >>> bmk) in >>> >> a window according to DISPLAY-FUNCTION and make the bookmark buffer >>> current. >>> >> >>> >> This approach is OK as long as the handler fn doesn't try do do one >>> part >>> >> of the job (window handling) itself, which is not the case at least >>> with >>> >> eww and w3m. It is as well counter intuitive, DISPLAY-FUNCTION shou= ld >>> >> be called on the buffer generated by bookmark and not the contrary, = so >>> >> this change makes the code simpler and easier to understand. >>> >> >>> >> > By contrast, the change you propose now will affect all the uses o= f >>> >> > bookmarks, everywhere, >>> >> >>> >> Yes, this is intended, in addition of fixing eww, it fixes w3m and >>> also >>> >> the quit function of eww (actually broken). >>> >> >>> >> > which is riskier, given how many different variants of bookmark >>> usage >>> >> > are out there. >>> >> >>> >> Tested here on many different kinds of bookmarks and work as expecte= d >>> >> unlike the current code. >>> > >>> > It took me a while to find time to focus on some bugs with Emacs 31 i= n >>> > my workflow (reverting to Emacs 30 until I had time). >>> > >>> > I discovered that this change breaks all bookmark handlers that rely >>> > on managing window-state or window-configuration. >>> >>> Which bookmark handlers? >> >> >> At least these packages rely on bookmarks that store window state and >> their handlers restore window state. There are workarounds I have >> considered but they are distasteful, to say the least. >> >> bufferlo >> activities >> burly >> >> I help maintain bufferlo and this change broke bookmarks for all our >> users who have tried master, including me. >> >> > I have no workaround yet this until we fix it, I have to do screwy >>> > things to make 'bookmark--jump-via' ignore 'save-window-excursion'. >>> > >>> > What's the rationale for wrapping 'bookmark-handle-bookmark' with >>> > 'save-window-excursion'? >>> >>> 1) The bookmark handler function setup a buffer. >>> 2) When this buffer is ready we jump to this buffer with >>> DISPLAY-FUNCTION. >>> >>> If you don't save the window excursion in 1) and buffer is not ready, >>> the DISPLAY-FUNCTION may run from the buffer that was current before >>> calling the handler function. >>> >> >> Emacs is single threaded. What does it mean for a buffer to "not be >> ready?" >> >> Previously we were calling DISPLAY-FUNCTION on current-buffer, assuming >>> the handler fn had switched to a new buffer which should be current, >>> when the new buffer was not current we were swicthing to the >>> current-buffer the one that was current just before as explained above. >>> >>> So this change has fixed not only eww but some other bookmarks (like >>> w3m). >>> >> >> Yes, you said in the original bug report. >> >> > If this behavior is truly necessary (I'd like understand the use >>> > case), I suggest binding a new defvar to bind and trigger this >>> > behavior rather than affect all bookmark handlers. Unless eww can be >>> > fixed. It could handle window configuration management in its own >>> > bookmark handler. >>> >>> That's the point, you should not handle window management in your >>> bookmark handler, this defeat bookmark--jump-via DISPLAY-FUNCTION. >>> >> >> Yes, we should handle window configurations. Bookmarks are not limited >> to just files or URLs. Any new limitations imposed on bookmarks that >> assume so makes bookmarks worse, not better. >> >> This change also fixes old bugs where people were trying various things >>> in their bookmark handlers to get things right including polling or >>> running code under a timer etc... >>> >> >> Right. Those are some of the distasteful workarounds that Adam Porter >> had to resort to for activities in an effort to work around >> display-function and now he has to deal with window-save-excursion >> restoring the the window configuration *from our own calling sites*. If >> you think the new behavior should be limited to interactive use, I could >> perhaps understand that, but I still would suggest a defvar to control t= his >> so those of us who use bookmarks programmatically can still do so. >> > > In fact, it would be even better to optionally inhibit both > save-window-excursion and display-function. As it is, programmatically, = we > invoke bookmark-jump with #'ignore as the display-function. > One other point on this is that bufferlo and activities users, can use bookmark-bmenu-list to invoke these bookmarks and the new save-window-excursion wrapper will interfere with those uses also. We could recommend that those users stick to the native package invocation functions but that would be a limitation that bookmarks did not themselves have. --000000000000a88c2106303eb7d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Thu, Mar 13, 2025 at 3:48=E2=80=AFPM Ship Mints <shipmints@gmail.com> wrote:
On = Thu, Mar 13, 2025 at 3:34=E2=80=AFPM Ship Mints <shipmints@gmail.com> wrote:=
On Thu, Ma= r 13, 2025 at 3:21=E2=80=AFPM Thierry Volpiatto <thievol@posteo.net> wrote:
Ship Mints <shipmints@gmail.com> writes:

>> From: Thierry Volpiatto <thievol@posteo.net>
>> Cc: Thierry Volpiatto <thievol@posteo.net>,=C2=A0 75354@debbugs.gnu.org
>> Date: Wed, 08 Jan 2025 13:52:32 +0000
>>
>> > This is contrary to what you originally wrote (with which I a= gree):
>>
>> Yes, after deeper search I found that `bookmark--jump-via` is beha= ving
>> like this AFAIU:
>>=C2=A0 - It calls the handler which creates a new buffer related to= bookmark.
>>=C2=A0 - It then displays the current-buffer (the one before jumpin= g to bmk) in
>>=C2=A0 a window according to DISPLAY-FUNCTION and make the bookmark= buffer current.
>>
>> This approach is OK as long as the handler fn doesn't try do d= o one part
>> of the job (window handling) itself, which is not the case at leas= t with
>> eww and w3m.=C2=A0 It is as well counter intuitive, DISPLAY-FUNCTI= ON should
>> be called on the buffer generated by bookmark and not the contrary= , so
>> this change makes the code simpler and easier to understand.
>>
>> > By contrast, the change you propose now will affect all the u= ses of
>> > bookmarks, everywhere,
>>
>> Yes, this is intended, in addition of fixing eww, it fixes w3m and= also
>> the quit function of eww (actually broken).
>>
>> > which is riskier, given how many different variants of bookma= rk usage
>> > are out there.
>>
>> Tested here on many different kinds of bookmarks and work as expec= ted
>> unlike the current code.
>
> It took me a while to find time to focus on some bugs with Emacs 31 in=
> my workflow (reverting to Emacs 30 until I had time).
>
> I discovered that this change breaks all bookmark handlers that rely > on managing window-state or window-configuration.

Which bookmark handlers?

At least these packages rely on bookmarks that store window st= ate and their handlers restore window state.=C2=A0 There are workarounds I = have considered but they are distasteful, to say the least.

bufferlo
activities
burly

I hel= p maintain bufferlo and this change broke bookmarks for all our users who h= ave tried master, including me.

> I have no workaround yet this until we fix it, I have to do screwy
> things to make 'bookmark--jump-via' ignore 'save-window-ex= cursion'.
>
> What's the rationale for wrapping 'bookmark-handle-bookmark= 9; with
> 'save-window-excursion'?

1) The bookmark handler function setup a buffer.
2) When this buffer is ready we jump to this buffer with
DISPLAY-FUNCTION.

If you don't save the window excursion in 1) and buffer is not ready, the DISPLAY-FUNCTION may run from the buffer that was current before
calling the handler function.

Emacs is single threaded.=C2=A0 What does it me= an for a buffer to "not be ready?"

Previously we were calling DISPLAY-FUNCTION on current-buffer, assuming
the handler fn had switched to a new buffer which should be current,
when the new buffer was not current we were swicthing to the
current-buffer the one that was current just before as explained above.

So this change has fixed not only eww but some other bookmarks (like
w3m).

Y= es, you said in the original bug report.

> If this behavior is truly necessary (I'd like understand the use > case), I suggest binding a new defvar to bind and trigger this
> behavior rather than affect all bookmark handlers.=C2=A0 Unless eww ca= n be
> fixed.=C2=A0 It could handle window configuration management in its ow= n
> bookmark handler.

That's the point, you should not handle window management in your
bookmark handler, this defeat bookmark--jump-via DISPLAY-FUNCTION.

Yes, we sh= ould handle window configurations.=C2=A0 Bookmarks are not limited to just = files or URLs.=C2=A0 Any new limitations imposed on bookmarks that assume s= o makes bookmarks worse, not better.

This change also fixes old bugs where people were trying various things
in their bookmark handlers to get things right including polling or
running code under a timer etc...

Right.=C2=A0 Those are some of the distasteful w= orkarounds that Adam Porter had to resort to for activities in an effort to= work around display-function and now he has to deal with window-save-excur= sion restoring the the window configuration *from our own calling sites*.= =C2=A0 If you think the new behavior should be limited to interactive use, = I could perhaps understand that, but I still would suggest a defvar to cont= rol this so those of us who use bookmarks programmatically can still do so.=

In fact, it would be even better to optionally inhibit both save-wi= ndow-excursion and display-function.=C2=A0 As it is, programmatically, we i= nvoke bookmark-jump with #'ignore as the display-function.
<= /div>

One other point on this is that bufferlo and activities = users, can use bookmark-bmenu-list=C2=A0to invoke these bookmarks and the n= ew save-window-excursion wrapper will interfere with those uses also.=C2=A0= We could recommend that those users stick to the native package invocation= functions but that would be a limitation that bookmarks did not themselves= have.
--000000000000a88c2106303eb7d7-- From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 13 16:46:30 2025 Received: (at submit) by debbugs.gnu.org; 13 Mar 2025 20:46:30 +0000 Received: from localhost ([127.0.0.1]:58424 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tspRl-0004Ep-QX for submit@debbugs.gnu.org; Thu, 13 Mar 2025 16:46:30 -0400 Received: from lists.gnu.org ([2001:470:142::17]:46246) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tspRi-0004Dv-KQ for submit@debbugs.gnu.org; Thu, 13 Mar 2025 16:46:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tspRM-0001gC-7I for bug-gnu-emacs@gnu.org; Thu, 13 Mar 2025 16:46:05 -0400 Received: from mail-vk1-xa34.google.com ([2607:f8b0:4864:20::a34]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tspRJ-0004GQ-EE; Thu, 13 Mar 2025 16:46:03 -0400 Received: by mail-vk1-xa34.google.com with SMTP id 71dfb90a1353d-524125f6cadso801993e0c.2; Thu, 13 Mar 2025 13:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741898758; x=1742503558; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zCnAUqZPXaUZgwh+1KQO7qKuoX1hkkn8J35hkmztkvQ=; b=gt8wgorxItMP7I2fD7L0p3Q3EsgDUhhNfnu/a/I5Xywu7IFURoBE14r9n9LVFRPJB/ kuOc3A1NS3PaE3OaGbTtPImAhETmqQBqbbBau4gbGNJNO7D7mKHq5GQwA8YfhtT7PndY vK32DdxOIF+vaUakaxPeYXrPCDSM68KPreW5gTRu5lJs4KVNCTqLhtzojuTu52/FWZeH AnzQ6pnvvoTjmy5qyxCKS/phLFAlAInqc7in5gQ62ToVajbpMjA0GsA7YdjwyoW0b5e+ 5lMsDW8wxCRPY2e2nZ7UmHDvF+yK9NaSMiHyelYAtwgnVWv18lRi1zrJFmQwRVI/3fBE xYXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741898758; x=1742503558; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zCnAUqZPXaUZgwh+1KQO7qKuoX1hkkn8J35hkmztkvQ=; b=Il8tbi8hcXx/tcvPYQSoqchfcpzCMB28r5JTIWmOrj7dzaKR4gcvej/McyYaQe7b60 4sU3OFx7LbrWjUZ9tqL+stcb7kwJ5lfj/Yaz7y1v+qocZ5uvn2405xmOw4diMQTcNDL6 bxbRNygzBlZaEy9E0UN1LG6ij8rsaWNSM6oL2mcNGvuPSp4963bsS4Vno/xIm9EKMerS 4wyHuolO8LBpiqrXFH+rjJyZoYqK81VsCw1/5N6KnihhQrK51MlDRnnftaLCbu7cwZBU rmm+UpEf8vEApp2gSORk1Oy1UwVu9nUcXj9b5js2ryjPdMqLVhgoY1i+oTSJoD+raHwp Nlqg== X-Forwarded-Encrypted: i=1; AJvYcCUjWo7yKiU+Xxh9dS7cCoBWw+rRmfvufZMGcQXTrlv4laDlSdw1BqW1wYsUr0YjaCiJedOwpiTZsSuCyE/t@gnu.org X-Gm-Message-State: AOJu0Yw7PleIdUCERmNuXEOk+G7jkGKq9fVbnZF9dIFvoH4Ib2ehkfZw eJpEzos2uPX6ykxGGAA6pVa+FuDSt/XORZNfqfJCIkW2Ibwjk22WAs3dOjKI0UCz2DSojJc2QB8 ei9Rd40vLspdu1ioRnIzRixfEAS8= X-Gm-Gg: ASbGncv7HsVLOoSa7QsWqr1XaLjwV9BjQkEtA7Qz9URsfajmyUNmQg5qZhlO/dwoRa5 PTzqWvG7OVv/7ceF3uwwvR2jlbJgR3GwMZZQJYE+2oqx1HNtr8kHz0/JAO6/nc9SU+GuLPWwXEE OE6ua9rftNkOkvBMukz7swgr7u+zvOjgZ5n6Jj X-Google-Smtp-Source: AGHT+IEJpe3OJEgU6oIpuQDoBHFCGb8W5CRIcEV8obHO2QCWFQ0CxswK71jlihEPBaE5KhOnbwXImFcZp/FhrDIrFw4= X-Received: by 2002:a05:6122:660f:b0:520:60c2:3f3 with SMTP id 71dfb90a1353d-524498ba1b1mr206709e0c.4.1741898758181; Thu, 13 Mar 2025 13:45:58 -0700 (PDT) MIME-Version: 1.0 References: <874izwn306.fsf@posteo.net> In-Reply-To: From: Ship Mints Date: Thu, 13 Mar 2025 16:45:46 -0400 X-Gm-Features: AQ5f1Jphl0JyKWeJYaoWxgnYjYMN8_8q8s9tJmS4NWBwPgY5_FOnfX0opt8hJVo Message-ID: Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) To: Thierry Volpiatto Content-Type: multipart/alternative; boundary="000000000000b75c6106303f68ff" Received-SPF: pass client-ip=2607:f8b0:4864:20::a34; envelope-from=shipmints@gmail.com; helo=mail-vk1-xa34.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --000000000000b75c6106303f68ff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 13, 2025 at 3:56=E2=80=AFPM Ship Mints wr= ote: > On Thu, Mar 13, 2025 at 3:48=E2=80=AFPM Ship Mints = wrote: > >> On Thu, Mar 13, 2025 at 3:34=E2=80=AFPM Ship Mints = wrote: >> >>> On Thu, Mar 13, 2025 at 3:21=E2=80=AFPM Thierry Volpiatto >>> wrote: >>> >>>> Ship Mints writes: >>>> >>>> >> From: Thierry Volpiatto >>>> >> Cc: Thierry Volpiatto , 75354@debbugs.gnu.org >>>> >> Date: Wed, 08 Jan 2025 13:52:32 +0000 >>>> >> >>>> >> > This is contrary to what you originally wrote (with which I agree= ): >>>> >> >>>> >> Yes, after deeper search I found that `bookmark--jump-via` is >>>> behaving >>>> >> like this AFAIU: >>>> >> - It calls the handler which creates a new buffer related to >>>> bookmark. >>>> >> - It then displays the current-buffer (the one before jumping to >>>> bmk) in >>>> >> a window according to DISPLAY-FUNCTION and make the bookmark buffe= r >>>> current. >>>> >> >>>> >> This approach is OK as long as the handler fn doesn't try do do one >>>> part >>>> >> of the job (window handling) itself, which is not the case at least >>>> with >>>> >> eww and w3m. It is as well counter intuitive, DISPLAY-FUNCTION >>>> should >>>> >> be called on the buffer generated by bookmark and not the contrary, >>>> so >>>> >> this change makes the code simpler and easier to understand. >>>> >> >>>> >> > By contrast, the change you propose now will affect all the uses = of >>>> >> > bookmarks, everywhere, >>>> >> >>>> >> Yes, this is intended, in addition of fixing eww, it fixes w3m and >>>> also >>>> >> the quit function of eww (actually broken). >>>> >> >>>> >> > which is riskier, given how many different variants of bookmark >>>> usage >>>> >> > are out there. >>>> >> >>>> >> Tested here on many different kinds of bookmarks and work as expect= ed >>>> >> unlike the current code. >>>> > >>>> > It took me a while to find time to focus on some bugs with Emacs 31 = in >>>> > my workflow (reverting to Emacs 30 until I had time). >>>> > >>>> > I discovered that this change breaks all bookmark handlers that rely >>>> > on managing window-state or window-configuration. >>>> >>>> Which bookmark handlers? >>> >>> >>> At least these packages rely on bookmarks that store window state and >>> their handlers restore window state. There are workarounds I have >>> considered but they are distasteful, to say the least. >>> >>> bufferlo >>> activities >>> burly >>> >>> I help maintain bufferlo and this change broke bookmarks for all our >>> users who have tried master, including me. >>> >>> > I have no workaround yet this until we fix it, I have to do screwy >>>> > things to make 'bookmark--jump-via' ignore 'save-window-excursion'. >>>> > >>>> > What's the rationale for wrapping 'bookmark-handle-bookmark' with >>>> > 'save-window-excursion'? >>>> >>>> 1) The bookmark handler function setup a buffer. >>>> 2) When this buffer is ready we jump to this buffer with >>>> DISPLAY-FUNCTION. >>>> >>>> If you don't save the window excursion in 1) and buffer is not ready, >>>> the DISPLAY-FUNCTION may run from the buffer that was current before >>>> calling the handler function. >>>> >>> >>> Emacs is single threaded. What does it mean for a buffer to "not be >>> ready?" >>> >>> Previously we were calling DISPLAY-FUNCTION on current-buffer, assuming >>>> the handler fn had switched to a new buffer which should be current, >>>> when the new buffer was not current we were swicthing to the >>>> current-buffer the one that was current just before as explained above= . >>>> >>>> So this change has fixed not only eww but some other bookmarks (like >>>> w3m). >>>> >>> >>> Yes, you said in the original bug report. >>> >>> > If this behavior is truly necessary (I'd like understand the use >>>> > case), I suggest binding a new defvar to bind and trigger this >>>> > behavior rather than affect all bookmark handlers. Unless eww can b= e >>>> > fixed. It could handle window configuration management in its own >>>> > bookmark handler. >>>> >>>> That's the point, you should not handle window management in your >>>> bookmark handler, this defeat bookmark--jump-via DISPLAY-FUNCTION. >>>> >>> >>> Yes, we should handle window configurations. Bookmarks are not limited >>> to just files or URLs. Any new limitations imposed on bookmarks that >>> assume so makes bookmarks worse, not better. >>> >>> This change also fixes old bugs where people were trying various things >>>> in their bookmark handlers to get things right including polling or >>>> running code under a timer etc... >>>> >>> >>> Right. Those are some of the distasteful workarounds that Adam Porter >>> had to resort to for activities in an effort to work around >>> display-function and now he has to deal with window-save-excursion >>> restoring the the window configuration *from our own calling sites*. I= f >>> you think the new behavior should be limited to interactive use, I coul= d >>> perhaps understand that, but I still would suggest a defvar to control = this >>> so those of us who use bookmarks programmatically can still do so. >>> >> >> In fact, it would be even better to optionally inhibit both >> save-window-excursion and display-function. As it is, programmatically,= we >> invoke bookmark-jump with #'ignore as the display-function. >> > > One other point on this is that bufferlo and activities users, can use > bookmark-bmenu-list to invoke these bookmarks and the new > save-window-excursion wrapper will interfere with those uses also. We > could recommend that those users stick to the native package invocation > functions but that would be a limitation that bookmarks did not themselve= s > have. > Perhaps we can also consider introducing bookmark-record keys that influence bookmark-jump behavior so specialized bookmark-record makers can indicate what they need. --000000000000b75c6106303f68ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Thu, Mar 13, 2025 at 3:56=E2=80=AFPM Ship Mints <shipmints@gmail.com> wrote:
On = Thu, Mar 13, 2025 at 3:48=E2=80=AFPM Ship Mints <shipmints@gmail.com> wrote:=
On Thu, Ma= r 13, 2025 at 3:34=E2=80=AFPM Ship Mints <shipmints@gmail.com> wrote:
<= /div>
On Thu, Mar 13, 2= 025 at 3:21=E2=80=AFPM Thierry Volpiatto <thievol@posteo.net> wrote:
Ship Mints <shipmints@gmail.com> writes:

>> From: Thierry Volpiatto <thievol@posteo.net>
>> Cc: Thierry Volpiatto <thievol@posteo.net>,=C2=A0 75354@debbugs.gnu.org
>> Date: Wed, 08 Jan 2025 13:52:32 +0000
>>
>> > This is contrary to what you originally wrote (with which I a= gree):
>>
>> Yes, after deeper search I found that `bookmark--jump-via` is beha= ving
>> like this AFAIU:
>>=C2=A0 - It calls the handler which creates a new buffer related to= bookmark.
>>=C2=A0 - It then displays the current-buffer (the one before jumpin= g to bmk) in
>>=C2=A0 a window according to DISPLAY-FUNCTION and make the bookmark= buffer current.
>>
>> This approach is OK as long as the handler fn doesn't try do d= o one part
>> of the job (window handling) itself, which is not the case at leas= t with
>> eww and w3m.=C2=A0 It is as well counter intuitive, DISPLAY-FUNCTI= ON should
>> be called on the buffer generated by bookmark and not the contrary= , so
>> this change makes the code simpler and easier to understand.
>>
>> > By contrast, the change you propose now will affect all the u= ses of
>> > bookmarks, everywhere,
>>
>> Yes, this is intended, in addition of fixing eww, it fixes w3m and= also
>> the quit function of eww (actually broken).
>>
>> > which is riskier, given how many different variants of bookma= rk usage
>> > are out there.
>>
>> Tested here on many different kinds of bookmarks and work as expec= ted
>> unlike the current code.
>
> It took me a while to find time to focus on some bugs with Emacs 31 in=
> my workflow (reverting to Emacs 30 until I had time).
>
> I discovered that this change breaks all bookmark handlers that rely > on managing window-state or window-configuration.

Which bookmark handlers?

At least these packages rely on bookmarks that store window st= ate and their handlers restore window state.=C2=A0 There are workarounds I = have considered but they are distasteful, to say the least.

bufferlo
activities
burly

I hel= p maintain bufferlo and this change broke bookmarks for all our users who h= ave tried master, including me.

> I have no workaround yet this until we fix it, I have to do screwy
> things to make 'bookmark--jump-via' ignore 'save-window-ex= cursion'.
>
> What's the rationale for wrapping 'bookmark-handle-bookmark= 9; with
> 'save-window-excursion'?

1) The bookmark handler function setup a buffer.
2) When this buffer is ready we jump to this buffer with
DISPLAY-FUNCTION.

If you don't save the window excursion in 1) and buffer is not ready, the DISPLAY-FUNCTION may run from the buffer that was current before
calling the handler function.

Emacs is single threaded.=C2=A0 What does it me= an for a buffer to "not be ready?"

Previously we were calling DISPLAY-FUNCTION on current-buffer, assuming
the handler fn had switched to a new buffer which should be current,
when the new buffer was not current we were swicthing to the
current-buffer the one that was current just before as explained above.

So this change has fixed not only eww but some other bookmarks (like
w3m).

Y= es, you said in the original bug report.

> If this behavior is truly necessary (I'd like understand the use > case), I suggest binding a new defvar to bind and trigger this
> behavior rather than affect all bookmark handlers.=C2=A0 Unless eww ca= n be
> fixed.=C2=A0 It could handle window configuration management in its ow= n
> bookmark handler.

That's the point, you should not handle window management in your
bookmark handler, this defeat bookmark--jump-via DISPLAY-FUNCTION.

Yes, we sh= ould handle window configurations.=C2=A0 Bookmarks are not limited to just = files or URLs.=C2=A0 Any new limitations imposed on bookmarks that assume s= o makes bookmarks worse, not better.

This change also fixes old bugs where people were trying various things
in their bookmark handlers to get things right including polling or
running code under a timer etc...

Right.=C2=A0 Those are some of the distasteful w= orkarounds that Adam Porter had to resort to for activities in an effort to= work around display-function and now he has to deal with window-save-excur= sion restoring the the window configuration *from our own calling sites*.= =C2=A0 If you think the new behavior should be limited to interactive use, = I could perhaps understand that, but I still would suggest a defvar to cont= rol this so those of us who use bookmarks programmatically can still do so.=

In fact, it would be even better to optionally inhibit both save-wi= ndow-excursion and display-function.=C2=A0 As it is, programmatically, we i= nvoke bookmark-jump with #'ignore as the display-function.
<= /div>

One o= ther point on this is that bufferlo and activities users, can use bookmark-= bmenu-list=C2=A0to invoke these bookmarks and the new save-window-excursion= wrapper will interfere with those uses also.=C2=A0 We could recommend that= those users stick to the native package invocation functions but that woul= d be a limitation that bookmarks did not themselves have.
=

Perhaps we can also consider introducing bookmark-record keys= that influence bookmark-jump behavior so specialized bookmark-record maker= s can indicate what they need.
--000000000000b75c6106303f68ff-- From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 14 00:47:01 2025 Received: (at submit) by debbugs.gnu.org; 14 Mar 2025 04:47:01 +0000 Received: from localhost ([127.0.0.1]:59393 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tswwn-0003X2-ER for submit@debbugs.gnu.org; Fri, 14 Mar 2025 00:47:01 -0400 Received: from lists.gnu.org ([2001:470:142::17]:33488) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tswwk-0003Wf-Oq for submit@debbugs.gnu.org; Fri, 14 Mar 2025 00:46:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tswwM-00055o-Ow for bug-gnu-emacs@gnu.org; Fri, 14 Mar 2025 00:46:45 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tswwI-0000d9-Qa for bug-gnu-emacs@gnu.org; Fri, 14 Mar 2025 00:46:33 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 4A6E8240101 for ; Fri, 14 Mar 2025 05:46:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1741927586; bh=JHEqO19iGCkcIACn3n/6j9JKzAMDHRMqbuy86zTxfBE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=Rghnp9A6h6KmOHawSSnql+bIbcBDJvyXPGnktkDm5fjbsfJgGlC6ls1goMTCgXwhg l9JHARyD9w43oDYtVgg/gY3hUztFIkB2iqrn/gOEXepYpYiACOngitNxYLu/Ax88QN TKf8PSigmcBaFrxCWYg7GJSbddvHuIHH3MrzJbnAdmoTmIqQfMkP0sNsb+RZmHvh9Y p4ktl47TaC80B40/s/VScErUszvaCF+HhqOUs7zrxCtIFJSy8LUw76ZDvELBaUtggF 2IOr97+L3WbgTENDZOa0u5CMHZtWB7aUilucIX6ORVTvNdg+fS+S6ZXubagIovUIVq nkOy5TrWDC04g== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4ZDWzN1l4jz6v09; Fri, 14 Mar 2025 05:46:24 +0100 (CET) From: Thierry Volpiatto To: Ship Mints Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) In-Reply-To: (Ship Mints's message of "Thu, 13 Mar 2025 15:34:04 -0400") References: <874izwn306.fsf@posteo.net> Date: Fri, 14 Mar 2025 04:53:49 +0000 Message-ID: <87y0x8kyaq.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=185.67.36.66; envelope-from=thievol@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Thierry Volpiatto , Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ship Mints writes: > Which bookmark handlers? > > At least these packages rely on bookmarks that store window state and > their handlers restore window state.=C2=A0 There are workarounds I have > considered but they are distasteful, to say the least. > > bufferlo > activities > burly After a quick look at source code of activities I see that it tries hard to fix the bug this change fixed, there is even comments, so I suggest these packages adapt their bookmark code to new bookmark--jump-via, IMO this will reduce the code and make it simpler. =2D-=20 Thierry --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHHBAEBCgAxFiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmfTtl0THHRoaWV2b2xA cG9zdGVvLm5ldAAKCRAOxW0UHRbvk+6LC/0Wf039uZdT/r8+rBJjG8LkBsiIfOs3 RuLkXdiGaEBH9CIHxgP8Z9uaGin1a3+uEskxEZl4yCSCgBJQoQTCORTT/QO+vQ9J Ht62vw+XBwr/TIiNXoza6hv77FOr9qpaNkgsv/vNEpLSzU0DGVu4mrzgZGkAycCO PUZmDLZ/iB43MDlOlmVBJMCVWMp0PUqNTlQBJu0YcEYCvOPuDxTfjE+xCTrU8ard lnLXtukJlkZCSL0n/4w7nNSOVvWyGS8pR8kFiJZVROuyCZ8uH3XrUlmgFhWUkcpJ CfcNtXR36CUD2qrCFQ2oIuU5PWeTI6HKEgWD1pGkvQrLxmTKdKHZ5tZdohsxxnhq K2S07IlzflvUNrcvalmRJ4sZCniY+ryZYQKVeoskIo4FWdYFshKcbu1xgwvVHK6l 3lLgcxvDdULAbRww8buqeow2iTkMOz7HgeCvn+scrLTzIT3XbeF7G+2mrlVSjBmJ HFwMOwPedqbu8J0P4WaGsnQw1Lq2qadlcag= =BN3s -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 14 06:50:27 2025 Received: (at submit) by debbugs.gnu.org; 14 Mar 2025 10:50:27 +0000 Received: from localhost ([127.0.0.1]:60247 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tt2cV-0003Mw-8S for submit@debbugs.gnu.org; Fri, 14 Mar 2025 06:50:27 -0400 Received: from lists.gnu.org ([2001:470:142::17]:52268) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tt2cT-0003Mb-4C for submit@debbugs.gnu.org; Fri, 14 Mar 2025 06:50:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tt2cK-0003hF-TB for bug-gnu-emacs@gnu.org; Fri, 14 Mar 2025 06:50:16 -0400 Received: from mail-ua1-x930.google.com ([2607:f8b0:4864:20::930]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tt2cI-0008T5-P9; Fri, 14 Mar 2025 06:50:16 -0400 Received: by mail-ua1-x930.google.com with SMTP id a1e0cc1a2514c-86d42f08135so833065241.0; Fri, 14 Mar 2025 03:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741949413; x=1742554213; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9m/VSmK3Dwn5I/gZP22xFcGj++/7Gp2dUXoy/C4wH+A=; b=L8z7Lo9Fney2y/OyoRk42TZ9S9r5yLTMxtNLc3iXDO/0JYLvZ15DpH3oUXh9K8NLUa JqgKxhkYLG/zOO1Fl5ArxovJnHCM/tl4ZIJUAghP2kTlbjfotwi1VrqHSu75QTsxarPe 4Ulgd7cA8qj4Lx12zQJlNhae+LgDGkOG0cs8PeRJVilzQrEt1D/gOkhZPqE8Wn1EThOd cjTy31cGvCoP3vtKOdhKGfb+bP6zNeWx9vloQZr51NG0DSuAVFvAeCZo+X5FFuzr8aCV fPMfUY2sGJrMW1zKZy9fViGc3rvaP4WEgDwV5Pqpj07+/1z5KMoQKA5IQp1riEGNxSsr Gkug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741949413; x=1742554213; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9m/VSmK3Dwn5I/gZP22xFcGj++/7Gp2dUXoy/C4wH+A=; b=CnGgFcRZ9W/NU/iIWjqLSN96t73k8tVOR8O217cbvC+XdAXJQFLNLyD4XO2UbKt4gK YZHtMWCy6yvgWKVUXidAIMOwiwNEjVswD3vuVUTNWzxfWzrqgwE1xs8U4Fc2KETf6u17 3wQU6dnpw1Xi7k+g94O1vJHw0kB+OjJpubmL88pWRoeXFzto4lCp5AEdE6hSz73gWmS4 4Uk/KSSUt8/XcdFeYY8V0gMirBnQvXkONwU/rc4ozyxtYq9ES5C5LaioHXNUWVEwX1hS zTtpFw+X+8iOdqDKN3LWPNI1HHkJxqykfC1XLXETbexBEKdzz8Zq1K0OgwgZV/8FEelf q1Rw== X-Forwarded-Encrypted: i=1; AJvYcCXkUya+uwvG9WiwZhVL13F7SvW5YPg7p0qRewUGarl8vIbeqtQCJ6z1Kk9AM9ydtUfR7yQN1YQ91qB5u4LC@gnu.org X-Gm-Message-State: AOJu0Yz3daI0Cp4DkeEnChpxr7NNtrzdEoWcVZ3EZju2qIykL32iiI3D R4ZdQLVn0zddMUedTQRXA6+ik+mAXh6ash8+S/phJ00INQuW3NU2kJEViTlUunTrIPfIE85skcL T8QPhsZCcsUtdOdtD5joio5Oa5ZMHhJmT X-Gm-Gg: ASbGncuL+AiqzMr3+sTgwIttSqTZTnDYwB+OyUzjOjK6e9NINbcJzNBuo4M4PDoEfDh fqTPeYLLQKpFvbE3zC4J/3UuXxvGZDZPvZdK166O6nqMuebEmQEi1CBxJWzfYKHe6sCkQ0aXNpe zT4DNyuYUu4/f7bT4G05CpIL2Jag== X-Google-Smtp-Source: AGHT+IFyLCm+/VDt5ZuPGsQZaUp/CTSrR5fMwbCbybpyIsFI8Mg82KLibiSFYX3PYosSoPfVhJJgR9WFk28hvjNwNC0= X-Received: by 2002:a05:6102:511e:b0:4c1:801e:deb2 with SMTP id ada2fe7eead31-4c38313e3bcmr774698137.7.1741949413210; Fri, 14 Mar 2025 03:50:13 -0700 (PDT) MIME-Version: 1.0 References: <874izwn306.fsf@posteo.net> <87y0x8kyaq.fsf@posteo.net> In-Reply-To: <87y0x8kyaq.fsf@posteo.net> From: Ship Mints Date: Fri, 14 Mar 2025 06:50:02 -0400 X-Gm-Features: AQ5f1Jr2K55XpWunr9mENsAzY23OPp5SjfIWetjm6uBCPV_uvnyV6ikO5OGXAIU Message-ID: Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) To: Thierry Volpiatto Content-Type: multipart/alternative; boundary="000000000000fdc07706304b3356" Received-SPF: pass client-ip=2607:f8b0:4864:20::930; envelope-from=shipmints@gmail.com; helo=mail-ua1-x930.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --000000000000fdc07706304b3356 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 14, 2025 at 12:46=E2=80=AFAM Thierry Volpiatto wrote: > Ship Mints writes: > > > Which bookmark handlers? > > > > At least these packages rely on bookmarks that store window state and > > their handlers restore window state. There are workarounds I have > > considered but they are distasteful, to say the least. > > > > bufferlo > > activities > > burly > > After a quick look at source code of activities I see that it tries hard > to fix the bug this change fixed, there is even comments, so I suggest > these packages adapt their bookmark code to new bookmark--jump-via, IMO > this will reduce the code and make it simpler. > Thanks for taking a look. Those are just the ones that immediately came to mind. There may be many other users. I stand by my suggestions that we either or both: - Add defcustoms and/or defvars to control this new behavior that breaks bookmarks. bookmarks are *not* documented to be merely for files, not documented to avoid window and frame behavior (some of our bookmarks also perform frame operations compounding the issue with this new behavior). - Add bookmark-record properties/keys to control bookmark behavior so that bookmark-record-make functions can decide for themselves which behavior to trigger. - Add a defustom to set the default display-func so that pop-to-buffer-same-window can be overridden. I consider that this is missing as an oversight in the implementation that does not forbid common use cases for which bookmarks have been adopted. I'm happy to submit patches for this to make everyone's bookmark use more general and less painful. In the same vein, I've submitted patches to correct an oversight in window-state-get that makes using bookmark-records that contain window-state objects more reliable. Don't you agree this is a better approach than a wholesale behavior change? --000000000000fdc07706304b3356 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Fri, Mar 14, 2025 at 12:46=E2=80=AFAM Thierry Volpiatto <thievol@posteo.net> wrote:
Ship Mints <shipmints@gmail.com> writes:

>=C2=A0 =C2=A0 =C2=A0Which bookmark handlers?
>
> At least these packages rely on bookmarks that store window state and<= br> > their handlers restore window state.=C2=A0 There are workarounds I hav= e
> considered but they are distasteful, to say the least.
>
> bufferlo
> activities
> burly

After a quick look at source code of activities I see that it tries hard to fix the bug this change fixed, there is even comments, so I suggest
these packages adapt their bookmark code to new bookmark--jump-via, IMO
this will reduce the code and make it simpler.

Thanks for = taking a look.=C2=A0 Those are just the ones that immediately came to mind.= =C2=A0 There may be many other users.=C2=A0 I stand by my suggestions that = we either or both:

- Add defcustoms and/or defvars to control this new behavior that bre= aks bookmarks.=C2=A0 bookmarks are *not* documented to be merely for files,= not documented to avoid window and frame behavior (some of our bookmarks a= lso perform frame operations compounding the issue with this new behavior).=

- Add bookma= rk-record properties/keys to control bookmark behavior so that bookmark-rec= ord-make functions can decide for themselves which behavior to trigger.

- Add a defustom= =C2=A0to set the default display-func so that pop-to-buffer-same-window can= be overridden.=C2=A0 I consider that this is missing as an oversight in th= e implementation that=C2=A0does=C2=A0not forbid common use cases for which = bookmarks have been adopted.

I'm happy to submit patches for this to make everyone&#= 39;s bookmark use more general and less painful.=C2=A0 In the same vein, I&= #39;ve submitted patches to correct an oversight in window-state-get that m= akes using bookmark-records that contain window-state objects more reliable= .

Don't y= ou agree this is a better approach than a wholesale behavior change?
<= div class=3D"gmail_default" style=3D"font-family:monospace">
--000000000000fdc07706304b3356-- From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 14 07:57:22 2025 Received: (at submit) by debbugs.gnu.org; 14 Mar 2025 11:57:22 +0000 Received: from localhost ([127.0.0.1]:60412 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tt3fG-0001RM-9A for submit@debbugs.gnu.org; Fri, 14 Mar 2025 07:57:22 -0400 Received: from lists.gnu.org ([2001:470:142::17]:45012) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tt3fC-0001R3-El for submit@debbugs.gnu.org; Fri, 14 Mar 2025 07:57:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tt3f6-00037s-LV for bug-gnu-emacs@gnu.org; Fri, 14 Mar 2025 07:57:12 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tt3f3-0000mj-T4 for bug-gnu-emacs@gnu.org; Fri, 14 Mar 2025 07:57:12 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id D9AC2240104 for ; Fri, 14 Mar 2025 12:57:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1741953426; bh=BINoO/z+lB1UspSTpwHu1d4VMIhQS7EntcmgOoPzBWY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=pQinfOo+3u0oV6hJjkpOpOq6IhnTZFaR9v24YiHeumQGzjKcUkDdYcWZ/ItQ8STus c2ZGobBRksUG1HSjna+cnaVvaWqWS64kfbCjhnZ8KKCYXHse/CdukU7QAJWjq61HLJ XMfHAEO9bBq0ExY6aO8NT3EdIDtfGCrRE+xxYEzSo7tZPK+nqYZCBrI9S44DkqYtzT c/ivLBISDxpKPOD1ttSzt6EjR8RVNMhlo/Wg0a24YFftnKTzhCdzVx4e2W1cTALCKj 42cthUQ6RBINqpSwjAZx3otNDoA2H2yOKAdhc/MaDEu7WLMuGgoiMJCLd9GSY7cB9q kdrgnwKGelP8Q== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4ZDjXH45sMz9rxN; Fri, 14 Mar 2025 12:57:03 +0100 (CET) From: Thierry Volpiatto To: Ship Mints Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) In-Reply-To: (Ship Mints's message of "Fri, 14 Mar 2025 06:50:02 -0400") References: <874izwn306.fsf@posteo.net> <87y0x8kyaq.fsf@posteo.net> Date: Fri, 14 Mar 2025 12:04:27 +0000 Message-ID: <877c4r6cok.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=185.67.36.66; envelope-from=thievol@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Thierry Volpiatto , Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ship Mints writes: > 1. ( ) text/plain (*) text/html=20=20=20=20=20=20=20=20=20=20=20 > > On Fri, Mar 14, 2025 at 12:46=E2=80=AFAM Thierry Volpiatto wrote: > > Ship Mints writes: >=20=20=20=20 > >=C2=A0 =C2=A0 =C2=A0Which bookmark handlers? > > > > At least these packages rely on bookmarks that store window state a= nd > > their handlers restore window state.=C2=A0 There are workarounds I = have > > considered but they are distasteful, to say the least. > > > > bufferlo > > activities > > burly >=20=20=20=20 > After a quick look at source code of activities I see that it tries h= ard > to fix the bug this change fixed, there is even comments, so I suggest > these packages adapt their bookmark code to new bookmark--jump-via, I= MO > this will reduce the code and make it simpler. > > Thanks for taking a look.=C2=A0 Those are just the ones that immediately = came to mind.=C2=A0 There may be many other users.=C2=A0 I stand by my sugg= estions that we either or both: > > - Add defcustoms and/or defvars to control this new behavior that breaks = bookmarks.=C2=A0 bookmarks are *not* documented to be merely for files, not= documented to avoid window and frame > behavior (some of our bookmarks also perform frame operations compounding= the issue with this new behavior). > > - Add bookmark-record properties/keys to control bookmark behavior so tha= t bookmark-record-make functions can decide for themselves which behavior t= o trigger. The old behavior was wrong, working by chance in many places, so no I don't think bookmark handlers should relay on it anymore. > - Add a defustom=C2=A0to set the default display-func so that pop-to-buff= er-same-window can be overridden.=C2=A0 I consider that this is missing as = an oversight in the implementation that=C2=A0does=C2=A0not > forbid common use cases for which bookmarks have been adopted. > > I'm happy to submit patches for this to make everyone's bookmark use more= general and less painful.=C2=A0 In the same vein, I've submitted patches t= o correct an oversight in window-state-get > that makes using bookmark-records that contain window-state objects more = reliable. > > Don't you agree this is a better approach than a wholesale behavior chang= e? No, I still think you should fix your code according to the new behavior. The old bookmark handlers (yours included) are implemented on a buggy bookmark--jump-via, they should be rewrited to fit with new code. But this is just my opinion, let see what others think. =2D-=20 Thierry --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHHBAEBCgAxFiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmfUG0sTHHRoaWV2b2xA cG9zdGVvLm5ldAAKCRAOxW0UHRbvk5BEC/9+4Dj/bgFEDoeJC174ihEnyv7GBuX3 3/e6JFATZPgH+4JfrjcBtuRrdnzmtYVV1PjTyBodl6lFxiu7133s4M/YsxrPiEmM vugah6SUkiZdTIZm/KTqfPWLf4qY502mO4PvHpbDo+E7QoIQJb1Un5jkSeuuZgFm Rt6BLxf+3A0qyRkZvB9fdOxqEOOHqDgAx4oUS0uuXSZkkfI6acpmPfWGC2Pj+Nmo cVlHXzIMJ7hit7CJnxYToY+0jk0na/ldtrkSceSaUF87pdKWBGnal55CdWx7fH7e XJmHYtqPpMsOqXgV94Orh3rVp73IuyfV9CDK889KVcsuvWGTJLaPtwoC6hEf2Kw9 kBArTijF7qJ5yKia6eDBxbk04Hr5GWg1KD3/Ag1ZJU4MTHWhuqaM75RY8oe2uHJo 2gNvLqzzTGOQzhHtHJ7AonjrDdXrk2s7sJU9FFSaCtTvxDaVsPXieayQXHCcnoau wvLddnmDrSdweumEHqvT0asQr7tEspNAcls= =tYlr -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 14 16:40:23 2025 Received: (at submit) by debbugs.gnu.org; 14 Mar 2025 20:40:23 +0000 Received: from localhost ([127.0.0.1]:36446 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ttBpO-0004se-Gj for submit@debbugs.gnu.org; Fri, 14 Mar 2025 16:40:23 -0400 Received: from lists.gnu.org ([2001:470:142::17]:42546) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ttBpI-0004rl-AZ for submit@debbugs.gnu.org; Fri, 14 Mar 2025 16:40:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ttBp6-0004sj-Mu for bug-gnu-emacs@gnu.org; Fri, 14 Mar 2025 16:40:05 -0400 Received: from mail-ua1-x936.google.com ([2607:f8b0:4864:20::936]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ttBp2-0005mM-PP; Fri, 14 Mar 2025 16:40:03 -0400 Received: by mail-ua1-x936.google.com with SMTP id a1e0cc1a2514c-86d42f08135so1064974241.0; Fri, 14 Mar 2025 13:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741984797; x=1742589597; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JHS8/BwDgT+1t7uRjDRcTSFU9ssQu6aJH4IPReTdblw=; b=LEkxnKeE7vEEkAZk2T6piNsjApBABt+N1Sb3bLUqnXNQ0W6bYGCBLappcMwNtAYsLE HGXaDNxu83aIap1eiP2DpsVySmsDIkUyjMCKWvxBy5L6mKsTjgD7u0AIbRqLqZlpzFAD ji0lQ05ABsjpcqHPijNJkuA/oaeik1E1b/kZzTK31j9/dEno8fgL7qeeFPB1KbtjoJUO 7nzdSVUJGazBEI2BCnYpvePGcxzqRpny9EVvVSszyFohAzIik4j281LTWFkKcNhrxKDz H1YE6C7jsyMfcAwD1oYZRYqIPdMzBN8CxuD1BxpKAItvxhxXreq86X7U6X78Q2/ObZWV D/7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741984797; x=1742589597; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JHS8/BwDgT+1t7uRjDRcTSFU9ssQu6aJH4IPReTdblw=; b=STyjSBrlCnsIXLi31Rk2iSZCA8M7hm219OYqIRpxPta+nEsTV76T2UDsI+QrTSK9Xj 4dM0CYYZmSAjOCzPyLrhki8RbWI3C5mmO+8l/AIIpKiBKA325XJ7QTf5ghMbrNYpVUNN s55gSoznGbTSkAjHZg+8osUw0PwgR7C486mZNnFzdm5AuLaCu5zqzHfflAJxcbB4xK3j XjC/b3E67wuXS0KpxdoVuRTvLw64yQe+7TLnbuYySeei7RvIazzGFLjWHXuSnKuzQeok 3TYG1/P7EbHJ0EF8b6ax1M7FyIVkS7/D3Lv5rqwGHfeZVF4CuNltNkR+KqqxdGRF7IiP zKzg== X-Forwarded-Encrypted: i=1; AJvYcCUQnO6bOADN/QX9tcvruTY2uDIp0DDRg0PBzfG7O5M/tDsaDbJ9fMuRsQoiYvSptmKYR5HFXRKTE4nabvhD@gnu.org X-Gm-Message-State: AOJu0YxyiDe7UxXxJXuGOO8sp1hEWvqh5RroGfLPCBupmyA9CrVPq8dB q0AmNq0F5SpIzLN7Jdbu/XQ39GXi93ZWEJ88ijJ6VxhC7+Dvffn1m+HzHow5KxjCmf+L0xBmSmp 7HHDP1L18ffrPEEc0/M1obobBIlc= X-Gm-Gg: ASbGncu9zGIWeHpBQ7qfgoutVTR856GK3xVdGbCe4o4M/dfwL54Sl1GQ+DRaKLPr1ZM OOAnYUMorYkh6ejZkMKv8jyv9+ncTaNC5jtXh/T1KeTcWES6PWQQSg+y7G/R4I0u9Th9g4ad3ea tN60s7uuVHkf0qiaZBny7w8GAssg== X-Google-Smtp-Source: AGHT+IENlkaL/JYThSdjnnfBc/NRSDLdmpSph1ZO4diokLHe2cYDnttilSx/nky0Zw3tCe9ebnDZTTANv3AFS6Nbgvw= X-Received: by 2002:a05:6102:2ac7:b0:4c1:a049:27c7 with SMTP id ada2fe7eead31-4c383163e85mr3485366137.13.1741984796993; Fri, 14 Mar 2025 13:39:56 -0700 (PDT) MIME-Version: 1.0 References: <874izwn306.fsf@posteo.net> <87y0x8kyaq.fsf@posteo.net> <877c4r6cok.fsf@posteo.net> In-Reply-To: <877c4r6cok.fsf@posteo.net> From: Ship Mints Date: Fri, 14 Mar 2025 16:39:44 -0400 X-Gm-Features: AQ5f1JrvPeElks1-I7VPggJABxXOKvQqKaVxNWUhcBNb4rbKwiaTL2UVx3_nw8g Message-ID: Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) To: Thierry Volpiatto Content-Type: multipart/alternative; boundary="000000000000076e5b0630537117" Received-SPF: pass client-ip=2607:f8b0:4864:20::936; envelope-from=shipmints@gmail.com; helo=mail-ua1-x936.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --000000000000076e5b0630537117 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 14, 2025 at 7:57=E2=80=AFAM Thierry Volpiatto wrote: > Ship Mints writes: > > > 1. ( ) text/plain (*) text/html > > > > On Fri, Mar 14, 2025 at 12:46=E2=80=AFAM Thierry Volpiatto > wrote: > > > > Ship Mints writes: > > > > > Which bookmark handlers? > > > > > > At least these packages rely on bookmarks that store window state > and > > > their handlers restore window state. There are workarounds I hav= e > > > considered but they are distasteful, to say the least. > > > > > > bufferlo > > > activities > > > burly > > > > After a quick look at source code of activities I see that it tries > hard > > to fix the bug this change fixed, there is even comments, so I > suggest > > these packages adapt their bookmark code to new bookmark--jump-via, > IMO > > this will reduce the code and make it simpler. > > > > Thanks for taking a look. Those are just the ones that immediately cam= e > to mind. There may be many other users. I stand by my suggestions that = we > either or both: > > > > - Add defcustoms and/or defvars to control this new behavior that break= s > bookmarks. bookmarks are *not* documented to be merely for files, not > documented to avoid window and frame > > behavior (some of our bookmarks also perform frame operations > compounding the issue with this new behavior). > > > > - Add bookmark-record properties/keys to control bookmark behavior so > that bookmark-record-make functions can decide for themselves which > behavior to trigger. > > The old behavior was wrong, working by chance in many places, so no I > don't think bookmark handlers should relay on it anymore. > > > - Add a defustom to set the default display-func so that > pop-to-buffer-same-window can be overridden. I consider that this is > missing as an oversight in the implementation that does not > > forbid common use cases for which bookmarks have been adopted. > > > > I'm happy to submit patches for this to make everyone's bookmark use > more general and less painful. In the same vein, I've submitted patches = to > correct an oversight in window-state-get > > that makes using bookmark-records that contain window-state objects mor= e > reliable. > > > > Don't you agree this is a better approach than a wholesale behavior > change? > > No, I still think you should fix your code according to the new > behavior. The old bookmark handlers (yours included) are implemented on > a buggy bookmark--jump-via, they should be rewrited to fit with new > code. But this is just my opinion, let see what others think. > I have workarounds that work only for the most simplistic cases. Many of our bookmarks themselves contain embedded bookmarks and bookmark references (which are individually addressable so can be used separately) with window-states we need to restore in tab-bar tabs that they represent. When jumping to the outermost bookmark, that window-configuration that was saved in that context gets restored when control returns to the outermost call, frustrating attempts to manage these at lower levels. These use cases are legitimate uses of bookmarks and I have software that has depended on bookmarks being able to contain any objects for a long time. bookmark--jump-via save-window-excursion behavior needs to be optional. Please. I stand by my suggestions to handle this. --000000000000076e5b0630537117 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Fri, Mar 14, 2025 at 7:57=E2=80=AFAM Thierry Volpiatto <thievol@posteo.net> wrote:
Ship Mints <shipmints@gmail.com> writes:

> 1.=C2=A0 ( ) text/plain=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (*) text/htm= l=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>
> On Fri, Mar 14, 2025 at 12:46=E2=80=AFAM Thierry Volpiatto <thievol@posteo.net>= wrote:
>
>=C2=A0 =C2=A0 =C2=A0Ship Mints <shipmints@gmail.com> writes:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Which bookmark handlers? >=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> At least these packages rely on bookmarks that= store window state and
>=C2=A0 =C2=A0 =C2=A0> their handlers restore window state.=C2=A0 The= re are workarounds I have
>=C2=A0 =C2=A0 =C2=A0> considered but they are distasteful, to say th= e least.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> bufferlo
>=C2=A0 =C2=A0 =C2=A0> activities
>=C2=A0 =C2=A0 =C2=A0> burly
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0After a quick look at source code of activities I s= ee that it tries hard
>=C2=A0 =C2=A0 =C2=A0to fix the bug this change fixed, there is even com= ments, so I suggest
>=C2=A0 =C2=A0 =C2=A0these packages adapt their bookmark code to new boo= kmark--jump-via, IMO
>=C2=A0 =C2=A0 =C2=A0this will reduce the code and make it simpler.
>
> Thanks for taking a look.=C2=A0 Those are just the ones that immediate= ly came to mind.=C2=A0 There may be many other users.=C2=A0 I stand by my s= uggestions that we either or both:
>
> - Add defcustoms and/or defvars to control this new behavior that brea= ks bookmarks.=C2=A0 bookmarks are *not* documented to be merely for files, = not documented to avoid window and frame
> behavior (some of our bookmarks also perform frame operations compound= ing the issue with this new behavior).
>
> - Add bookmark-record properties/keys to control bookmark behavior so = that bookmark-record-make functions can decide for themselves which behavio= r to trigger.

The old behavior was wrong, working by chance in many places, so no I
don't think bookmark handlers should relay on it anymore.

> - Add a defustom=C2=A0to set the default display-func so that pop-to-b= uffer-same-window can be overridden.=C2=A0 I consider that this is missing = as an oversight in the implementation that=C2=A0does=C2=A0not
> forbid common use cases for which bookmarks have been adopted.
>
> I'm happy to submit patches for this to make everyone's bookma= rk use more general and less painful.=C2=A0 In the same vein, I've subm= itted patches to correct an oversight in window-state-get
> that makes using bookmark-records that contain window-state objects mo= re reliable.
>
> Don't you agree this is a better approach than a wholesale behavio= r change?

No, I still think you should fix your code according to the new
behavior.=C2=A0 The old bookmark handlers (yours included) are implemented = on
a buggy bookmark--jump-via, they should be rewrited to fit with new
code.=C2=A0 But this is just my opinion, let see what others think.

I have workarounds that work only for the most simplistic cases.= =C2=A0 Many of our=C2=A0bookmarks themselves contain embedded bookmarks and= bookmark references (which are individually addressable so can be used sep= arately) with window-states we need to restore in tab-bar tabs that they re= present.=C2=A0 When jumping to the outermost bookmark, that window-configur= ation that was saved in that context gets restored when control returns to = the outermost call,=C2=A0frustrating attempts to manage these at lower leve= ls.=C2=A0 These use cases are legitimate uses of bookmarks and I have softw= are that has depended on bookmarks being able to contain any objects for a = long time.

bo= okmark--jump-via save-window-excursion behavior needs to be optional.
=

Please.

I stand by my suggestio= ns to handle this.
--000000000000076e5b0630537117-- From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 15 01:37:41 2025 Received: (at submit) by debbugs.gnu.org; 15 Mar 2025 05:37:41 +0000 Received: from localhost ([127.0.0.1]:37741 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ttKDN-0007g8-8V for submit@debbugs.gnu.org; Sat, 15 Mar 2025 01:37:41 -0400 Received: from lists.gnu.org ([2001:470:142::17]:39824) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ttKDL-0007ft-5j for submit@debbugs.gnu.org; Sat, 15 Mar 2025 01:37:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ttKDF-00048L-8I for bug-gnu-emacs@gnu.org; Sat, 15 Mar 2025 01:37:33 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ttKD8-0007gF-Jd for bug-gnu-emacs@gnu.org; Sat, 15 Mar 2025 01:37:28 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 52D52240029 for ; Sat, 15 Mar 2025 06:37:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1742017039; bh=g/z0dRbC12W95XGUgF77S0ZX33uT/Z2KYDDLkJT6SM8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=ZnznxSlk6qpC8qnQMFJdXpVkrSuEYH8kbQSGna9hu5q8SV6pt4Nfl2Um4ul1sja8r 0dWjEARjetSWbZn44OmERPM11DwUxAg3LubqL46ucYTBwPUY+tKUB9LN86Ib4SfOfH ZUu8SNPvPP8+6jcyTwqD5yYqtM+oeMeCyk+nMICzhcOpp4SDpd9skYhlSSYLqHBjhZ Oqh0huZTrDSN5fyI39nTxB2XWbWTJ+ev+iHkdTBc/lDUJim1X+OCgP03dzZypE/1JH cK5wRsAz3URYIO/OF83WinNJvX1/QLNFVtRtpW715DxNTr+3CLCwpYQKSHmb8m/jFD E5rxZlKidmzdQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4ZF93d39Jdz6v0Z; Sat, 15 Mar 2025 06:37:17 +0100 (CET) From: Thierry Volpiatto To: Ship Mints Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) In-Reply-To: (Ship Mints's message of "Fri, 14 Mar 2025 16:39:44 -0400") References: <874izwn306.fsf@posteo.net> <87y0x8kyaq.fsf@posteo.net> <877c4r6cok.fsf@posteo.net> Date: Sat, 15 Mar 2025 05:44:42 +0000 Message-ID: <871puy6e5x.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=185.67.36.65; envelope-from=thievol@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Thierry Volpiatto , Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ship Mints writes: > I have workarounds that work only for the most simplistic cases.=C2=A0 Ma= ny > of our=C2=A0bookmarks themselves contain embedded bookmarks and bookmark > references (which are individually addressable so can be used > separately) with window-states we need to restore in tab-bar tabs that > they represent. I don't really understand what your packages are doing or are intended doing, but FWICS in bufferlo: You are using in some places (bookmark-jump name #'ignore); why don't you do all this work (restore window-states in tab) in DISPLAY-FUNCTION instead of using `ignore`? Your handler would be much simpler by moving the window-state-put and alike calls in DISPLAY-FUNCTION: (bookmark-jump name #'your_function_restoring_window_or_frame_state)=20=20 Using (bookmark-jump name #'ignore) with all the code that jump to frame/tab etc... in the handler is just a workaround to fix the previous buggy behavior of bookmark--jump-via. IMO. It would be good to start with a good example or recipe to see if we can find a good solution. Thanks. =2D-=20 Thierry --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHHBAEBCgAxFiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmfVE8oTHHRoaWV2b2xA cG9zdGVvLm5ldAAKCRAOxW0UHRbvk2fnC/49Mhp7Dr+ShdI8Vx9pMxT72LWWZdW6 2gcLzSkyW6FMIrkPdg2Rdp20SjYSF8tYl/pboAQ8L0qR6a7gWua/Dx5GzG5kCEW/ cd8V3wSCnq6pEj2SFCPQezoD328kheKWJmI4GsIZV4sveq9TOaPhahoa9etumn/Q fYLBwDzet72SOuGE/0cRgXpkrR+qeLTDh5fehREbOf+Z3AElkohFqNKBtUQ78efU FW5yJZNJUob9qZFDd9RoNOwEQakgKcHgwjw4xGDLO5wNljdfkmBI40FdQCM25/ad +jI4crnoQDuA87XyXsFfqYSfSd+EjIlNh201fdlSU+jKkbxcT+7FhVEbK2T8KlOw DZysqk+zlW5WNR5DKKuw3Ov7aD6M5T0v1RTLkymaI0q1pvN0fUljk8Z9oeWNqhbb 1lQzC3Z4r+MEb3xRhMWNKoPgjhCvdhKnDFeCSOc6zwH5SBJPwtLn5otmJ19UdD5R AQe8Gd9QlZaNBah7xnI8HsEiZ//eMy873TE= =2UXZ -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 15 10:19:29 2025 Received: (at submit) by debbugs.gnu.org; 15 Mar 2025 14:19:29 +0000 Received: from localhost ([127.0.0.1]:43022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ttSMK-0008Sh-PP for submit@debbugs.gnu.org; Sat, 15 Mar 2025 10:19:29 -0400 Received: from lists.gnu.org ([2001:470:142::17]:59312) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ttSME-0008RJ-IH for submit@debbugs.gnu.org; Sat, 15 Mar 2025 10:19:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ttSLv-0003MG-Fu for bug-gnu-emacs@gnu.org; Sat, 15 Mar 2025 10:19:04 -0400 Received: from mail-vk1-xa33.google.com ([2607:f8b0:4864:20::a33]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ttSLg-0002yL-Ex; Sat, 15 Mar 2025 10:18:50 -0400 Received: by mail-vk1-xa33.google.com with SMTP id 71dfb90a1353d-523d8c024dfso1238654e0c.3; Sat, 15 Mar 2025 07:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742048327; x=1742653127; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/Md0ayjzzGkgrwkd3x70P7YUg8sy0wGwUKmA/S+6sxc=; b=L/ObmXhWMXjPkAKkKZE1diuJAzAMnxNIwVGqShgSBtO3MCneEF2fVbVY8PbtpbdUS3 u/DuOyGxeFMR8LNh8sB/WnSnh6I22QogRgo3jzipl6y/8n9fcUtXcy8/IU8aJslGftSp jPqnHCGw1FEQ2DASLr9SI45RsD2BDbqbCpYgLxW3l5edMdT+77mdS/6NvoEytPA4p8Id 5fyQ5sOQUq8u/CSC9rrU7GvmlhQ3cF73JLRPJ8/xasSK93cCLy473TJpXR2TFmOx6ybu SNZPf9TKHDxxx58Ej6yL2fN4XcaiK1lA7qMO/bgvvSAXiD1o4W1aT0jy/Q+WIo52x8Wr 7Ucw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742048327; x=1742653127; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/Md0ayjzzGkgrwkd3x70P7YUg8sy0wGwUKmA/S+6sxc=; b=t1Dga3oZgjp9WTuWSVLC2pS3Oouqg5LBytYVaAio98Lc//KW7pwPOycb0xD3+5et8S dquULipF0vZSl+MB5eBTwVMOLhTsJ9S2QifEE6hjc99k7EZnz2Ed7JDw5SWYGYyIRmCg 9y4p+JwfqHLv8UA8hhvwbHLJVWMkugJ0EXzdNDFprUMzRw7gxeFBuEQOfVC2DK2tE0cn 6KrHMPMqeFqTlKuv6OM8a5nB0H5QY1b66tJ48D0yxmnXKwsQyy8jKm+6qAbnHu+HnIKX qK60BAxDfj+zlb+KYWdR7TQjWTm1igt3LFdSupjb/Hdsi6lDcXH3zW+vSyQCcM+1UDCI Zlqg== X-Forwarded-Encrypted: i=1; AJvYcCWcjdnSwfB6Nn4LvrTNBNijZit9Xozo4a0CYVikMw3AgWH9Qqkcy6YcXjMthMMOxJ49v0V+xCBTOnAHcfEq@gnu.org X-Gm-Message-State: AOJu0YxHe1LE4s5x7dvNqSTDfDwSC+plvXk4kowkaf++ZN40GytPZdiu +WRqVGBwjVKlZ6V2Z2EgZhroCirgwjheg9lPfZ/bwXq+qaEGVODGY8Q2aYuMwkkH9Ml0P84m2z9 7l9VVuV6vFm8x/uLfjO9abWnjmWA= X-Gm-Gg: ASbGncv7pSJAjzpJwuRAadHxJQ5KXSF8mG+EUdDprEHT88nZRDvVKjjOfPti8RK8Qg5 a69vVnO3aWHuwFtpUdP8JYgjwnyCkeErryXtl/QNegE/l3a2NG1vBjjrHig4POXkNAugi71T2qp PDO33oK5IDM4kC4zRNJt6/xK8Z5tB3Sz5KIkqrhQ== X-Google-Smtp-Source: AGHT+IGGSoz5JPjz/amifCcz0JWxGbjPlxc7x6gjdMnxVfCSstvoB7knz7zo7QBdTaRFOxsFFOlUEQPAvOxo51T1s0I= X-Received: by 2002:a05:6122:90c:b0:523:e9d2:404d with SMTP id 71dfb90a1353d-524499fd2f2mr4132925e0c.11.1742048326609; Sat, 15 Mar 2025 07:18:46 -0700 (PDT) MIME-Version: 1.0 References: <874izwn306.fsf@posteo.net> <87y0x8kyaq.fsf@posteo.net> <877c4r6cok.fsf@posteo.net> <871puy6e5x.fsf@posteo.net> In-Reply-To: <871puy6e5x.fsf@posteo.net> From: Ship Mints Date: Sat, 15 Mar 2025 10:18:34 -0400 X-Gm-Features: AQ5f1JqT3WDubjpK-_Md9SrFMUp8x4C2qr-yxsloK2SwU_Cqu3y0kvTIBqERoZs Message-ID: Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) To: Thierry Volpiatto Content-Type: multipart/alternative; boundary="000000000000b073d50630623bf9" Received-SPF: pass client-ip=2607:f8b0:4864:20::a33; envelope-from=shipmints@gmail.com; helo=mail-vk1-xa33.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --000000000000b073d50630623bf9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Mar 15, 2025 at 1:37=E2=80=AFAM Thierry Volpiatto wrote: > Ship Mints writes: > > > I have workarounds that work only for the most simplistic cases. Many > > of our bookmarks themselves contain embedded bookmarks and bookmark > > references (which are individually addressable so can be used > > separately) with window-states we need to restore in tab-bar tabs that > > they represent. > > I don't really understand what your packages are doing or are intended > doing, but FWICS in bufferlo: You are using in some places > (bookmark-jump name #'ignore); why don't you do all this work (restore > window-states in tab) in DISPLAY-FUNCTION instead of using `ignore`? > Your handler would be much simpler by moving the window-state-put and > alike calls in DISPLAY-FUNCTION: > > (bookmark-jump name #'your_function_restoring_window_or_frame_state) > > Using (bookmark-jump name #'ignore) with all the code that jump to > frame/tab etc... in the handler is just a workaround to fix the previous > buggy behavior of bookmark--jump-via. IMO. > > It would be good to start with a good example or recipe to see if we can > find a good solution. > We need the bookmarks to work from the bookmark menu where no display-function overrides are supported. I suggest we add bookmark-record keys that indicate to bookmark-jump to inhibit/or allow messing with window-configurations. The bufferlo bookmarks (and Adam's if he wants) would contain these hint keys. '(bookmark-jump-inhibit-window-actions . t) ; or whatever we come up with I can contrive an example, if necessary, but I believe y'all get the point. Nested bookmarks whose handlers expect their window-configurations not to be messed with up the chain, will always be broken without additional controls. --000000000000b073d50630623bf9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Sat, Mar 15, 2025 at 1:37=E2=80=AFAM Thierry Volpiatto <thievol@posteo.net> wrote:
Ship Mints <shipmints@gmail.com> writes:

> I have workarounds that work only for the most simplistic cases.=C2=A0= Many
> of our=C2=A0bookmarks themselves contain embedded bookmarks and bookma= rk
> references (which are individually addressable so can be used
> separately) with window-states we need to restore in tab-bar tabs that=
> they represent.

I don't really understand what your packages are doing or are intended<= br> doing, but FWICS in bufferlo: You are using in some places
(bookmark-jump name #'ignore); why don't you do all this work (rest= ore
window-states in tab) in DISPLAY-FUNCTION instead of using `ignore`?
Your handler would be much simpler by moving the window-state-put and
alike calls in DISPLAY-FUNCTION:

(bookmark-jump name #'your_function_restoring_window_or_frame_state)=C2= =A0

Using (bookmark-jump name #'ignore) with all the code that jump to
frame/tab etc... in the handler is just a workaround to fix the previous buggy behavior of bookmark--jump-via. IMO.

It would be good to start with a good example or recipe to see if we can find a good solution.

We need the bookmarks to work from t= he bookmark menu where no display-function overrides are supported.

I suggest we add boo= kmark-record keys that indicate to bookmark-jump to inhibit/or allow messin= g with window-configurations.=C2=A0 The bufferlo bookmarks (and Adam's = if he wants) would contain these hint keys.

'(bookmark-jump-inhibit-window-actions .= t) ; or whatever we come up with

I can contrive an example, if necessary, but I belie= ve y'all get the point.=C2=A0 Nested bookmarks whose handlers expect th= eir window-configurations not to be messed with up the chain,=C2=A0will alw= ays be broken without additional controls.
--000000000000b073d50630623bf9-- From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 16 17:11:25 2025 Received: (at submit) by debbugs.gnu.org; 16 Mar 2025 21:11:26 +0000 Received: from localhost ([127.0.0.1]:50997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ttvGV-0001tG-42 for submit@debbugs.gnu.org; Sun, 16 Mar 2025 17:11:25 -0400 Received: from lists.gnu.org ([2001:470:142::17]:58114) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ttvGQ-0001rK-SE for submit@debbugs.gnu.org; Sun, 16 Mar 2025 17:11:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ttvGJ-0000wr-DY for bug-gnu-emacs@gnu.org; Sun, 16 Mar 2025 17:11:11 -0400 Received: from mail-ua1-x934.google.com ([2607:f8b0:4864:20::934]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ttvGH-0008GB-D2; Sun, 16 Mar 2025 17:11:11 -0400 Received: by mail-ua1-x934.google.com with SMTP id a1e0cc1a2514c-86b9ea43955so1554890241.2; Sun, 16 Mar 2025 14:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742159467; x=1742764267; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0xSob1D+KGbsGZZvm0S6VzjckmJtBl768lWt1exkov0=; b=R/Ii5W2TGbIwSVvDmDgRoi4kAwp2jsxyxdhFi1FfX65S/JnT/2NQ/OOYMlPahSb+jh PPq87xORd5SvNiNReYAmO9wMgxd7vaFkB+vzZ0GdrXLWFHuewgLdh883qJ6xdQJsCz1y yZUCCoVR8r8kjzyG5RwlIzmPCPLWwuoLoX/dZigfySRr7uSl0+j+GpmKvlrbWfugxnip IC3xF7d2seZWboAiFEbX94ok5/qjfRwNs5t6QzihFt2VTqCOOY4aOGS+zpvPuHHckSAh PqnUBmbXF6v83xosVHMwKQ2iV/vEinpVHSySAJ1XxXtvmJMMADL5u1rE9IKW2QCsrego J/pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742159467; x=1742764267; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0xSob1D+KGbsGZZvm0S6VzjckmJtBl768lWt1exkov0=; b=h3gPusvc1ZEoE5wPsrTM1qW/kiRMRfb6ruyEaEFXImVM3erWMaqJaTNc8kRoIdO8re WaiEt/Da4t5p++nuEUDHTzyZ2ZASVSDxWD+lYpzRrLN1PkPIGCCuWab2Nwsg+fr4urez QrNih68JQcqkVLNDiMDWDLoQTBPNcg3GF30IA/aNzG9AJI3fGhKHWAhgXO6ycPRyLS14 5vBLIJqP7z7YFleKbNRtytA4CvZ6SS3mISc59/CHHMatfP8N5+mFcF57qA+7Z+30kgof zAjnZWXnEPDEnxZMNRk7ed1su4M6STGBfLOdsIFA8d5ZOC5Xf4+OTmciduoMb0Dv1Beo AKYQ== X-Forwarded-Encrypted: i=1; AJvYcCVJFJyMon123MA6B+PinxRDSmS9On8Idso/I80ZdxGTMMU7YYJtK51mAuMxDZg+OXHKdjaWDtydKJtb/RpT@gnu.org X-Gm-Message-State: AOJu0YwyJ4EXG2ZbY5JF7SsT2aw404PQvS+34N5j2Hl2q6yi9W4MxMSm f9RFeXRVqp5A67jJHSZ368lNXBz5WvpW5DrhxshtHELqlNU/KWoteRifPzCN8Y+SIwwY7P/MPwz O7fKhCJiPfw0oEDG5z1MfTph/UJ0BBA== X-Gm-Gg: ASbGnctclAxAMSf/qLheAf3aSksqbb+5A55RZRBkatbBo1evOf3+qqW31Mp8SmhPqfn ZgZhx7G35BEYASuwcOtwLmcruZqD/l89PbvzizfmNNg+uNE6BAfFVgK3OrGH/J9bgv7UwNsoLXv Hyy1K61QolUyc/jL5mmJxCJjkA6g== X-Google-Smtp-Source: AGHT+IFZui6HQd8rzq+fkWF0kRJ+Ww1T1nANJwkbgzpD2sQHXoHs2povMGamHnlNOy3m53ePue1sTuhCifFH0kaDY9s= X-Received: by 2002:a05:6102:3f09:b0:4c1:91e0:d5d6 with SMTP id ada2fe7eead31-4c383161faamr6614568137.12.1742159467564; Sun, 16 Mar 2025 14:11:07 -0700 (PDT) MIME-Version: 1.0 References: <874izwn306.fsf@posteo.net> <87y0x8kyaq.fsf@posteo.net> <877c4r6cok.fsf@posteo.net> <871puy6e5x.fsf@posteo.net> In-Reply-To: From: Ship Mints Date: Sun, 16 Mar 2025 17:10:56 -0400 X-Gm-Features: AQ5f1JqGS2RkwXxxVftLvcL4YPIcMzn2X7kUqfUrXk6fjUgLAmcrLAqKTVxKpEI Message-ID: Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) To: Thierry Volpiatto Content-Type: multipart/mixed; boundary="00000000000034fa7b06307c1cc0" Received-SPF: pass client-ip=2607:f8b0:4864:20::934; envelope-from=shipmints@gmail.com; helo=mail-ua1-x934.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --00000000000034fa7b06307c1cc0 Content-Type: multipart/alternative; boundary="00000000000034fa7606307c1cbe" --00000000000034fa7606307c1cbe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Mar 15, 2025 at 10:18=E2=80=AFAM Ship Mints w= rote: > On Sat, Mar 15, 2025 at 1:37=E2=80=AFAM Thierry Volpiatto > wrote: > >> Ship Mints writes: >> >> > I have workarounds that work only for the most simplistic cases. Many >> > of our bookmarks themselves contain embedded bookmarks and bookmark >> > references (which are individually addressable so can be used >> > separately) with window-states we need to restore in tab-bar tabs that >> > they represent. >> >> I don't really understand what your packages are doing or are intended >> doing, but FWICS in bufferlo: You are using in some places >> (bookmark-jump name #'ignore); why don't you do all this work (restore >> window-states in tab) in DISPLAY-FUNCTION instead of using `ignore`? >> Your handler would be much simpler by moving the window-state-put and >> alike calls in DISPLAY-FUNCTION: >> >> (bookmark-jump name #'your_function_restoring_window_or_frame_state) >> >> Using (bookmark-jump name #'ignore) with all the code that jump to >> frame/tab etc... in the handler is just a workaround to fix the previous >> buggy behavior of bookmark--jump-via. IMO. >> >> It would be good to start with a good example or recipe to see if we can >> find a good solution. >> > > We need the bookmarks to work from the bookmark menu where no > display-function overrides are supported. > > I suggest we add bookmark-record keys that indicate to bookmark-jump to > inhibit/or allow messing with window-configurations. The bufferlo > bookmarks (and Adam's if he wants) would contain these hint keys. > > '(bookmark-jump-inhibit-window-actions . t) ; or whatever we come up with > > I can contrive an example, if necessary, but I believe y'all get the > point. Nested bookmarks whose handlers expect their window-configuration= s > not to be messed with up the chain, will always be broken without > additional controls. > The attached patch implements such a scheme that works for us, and is transparent to other bookmark uses. -Stephane --00000000000034fa7606307c1cbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Sat, Mar 15, 2025 at 10:18=E2=80=AFAM Ship Mints <shipmints@gmail.com> wrote:
On= Sat, Mar 15, 2025 at 1:37=E2=80=AFAM Thierry Volpiatto <thievol@posteo.net> wrote:<= /span>
Ship Mints <shipmints@gmail.com> writes:

> I have workarounds that work only for the most simplistic cases.=C2=A0= Many
> of our=C2=A0bookmarks themselves contain embedded bookmarks and bookma= rk
> references (which are individually addressable so can be used
> separately) with window-states we need to restore in tab-bar tabs that=
> they represent.

I don't really understand what your packages are doing or are intended<= br> doing, but FWICS in bufferlo: You are using in some places
(bookmark-jump name #'ignore); why don't you do all this work (rest= ore
window-states in tab) in DISPLAY-FUNCTION instead of using `ignore`?
Your handler would be much simpler by moving the window-state-put and
alike calls in DISPLAY-FUNCTION:

(bookmark-jump name #'your_function_restoring_window_or_frame_state)=C2= =A0

Using (bookmark-jump name #'ignore) with all the code that jump to
frame/tab etc... in the handler is just a workaround to fix the previous buggy behavior of bookmark--jump-via. IMO.

It would be good to start with a good example or recipe to see if we can find a good solution.

We need the bookmarks to work from the bookmark menu where n= o display-function overrides are supported.

I suggest we add = bookmark-record keys that indicate to bookmark-jump to inhibit/or allow mes= sing with window-configurations.=C2=A0 The bufferlo bookmarks (and Adam'= ;s if he wants) would contain these hint keys.

'(bookmark= -jump-inhibit-window-actions . t) ; or whatever we come up with

I can contrive an example, if necessary, but I believe y'all get the= point.=C2=A0 Nested bookmarks whose handlers expect their window-configura= tions not to be messed with up the chain,=C2=A0will always be broken withou= t additional controls.

The attached patch im= plements such a scheme that works for us, and is transparent to other=C2=A0= bookmark=C2=A0uses.

-Stephane
--00000000000034fa7606307c1cbe-- --00000000000034fa7b06307c1cc0 Content-Type: application/octet-stream; name="0001-Consult-bookmark-property-inhibit-bookmark-jump-wind.patch" Content-Disposition: attachment; filename="0001-Consult-bookmark-property-inhibit-bookmark-jump-wind.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_m8c4r6rn0 RnJvbSBiMTA5NTg3OWRiN2I3MDAyNjYzMWE2MWM5ZGI3MTc0NGRjN2NkYTRlIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBzaGlwbWludHMgPHNoaXBtaW50c0BnbWFpbC5jb20+CkRhdGU6 IFN1biwgMTYgTWFyIDIwMjUgMTc6MDM6MTggLTA0MDAKU3ViamVjdDogW1BBVENIXSBDb25zdWx0 IGJvb2ttYXJrIHByb3BlcnR5CiAnaW5oaWJpdC1ib29rbWFyay1qdW1wLXdpbmRvdy1hY3Rpb25z CgpUaGlzIGFsbG93cyBwYWNrYWdlcyB3aXRoIGN1c3RvbSBib29rbWFya3MgdGhhdCBwZXJmb3Jt IHRoZWlyIG93biB3aW5kb3cKb3IgZnJhbWUgYWN0aW9ucyB0byBpbmRpY2F0ZSB0byBib29rbWFy ay1qdW1wIHRoYXQgdGhvc2UgYWN0aW9ucyBzaG91bGQKYmUgZGVsZWdhdGVkIHRvIHRoZSBib29r bWFyayBoYW5kbGVyLiAgVGhpcyBpcyBiYWNrd2FyZCBjb21wYXRpYmxlIHdpdGgKbG9uZy1zdGFu ZGluZyBib29rbWFyayBiZWhhdmlvci4KCiogbGlzcC9ib29rbWFyay5lbAooYm9va21hcmstLWp1 bXAtdmlhKTogSW5oaWJpdCAnc2F2ZS13aW5kb3ctZXhjdXJzaW9uJyB3aGVuIHRoZSBib29rbWFy awpoYXMgYSBub24tbmlsIHByb3BlcnR5ICdpbmhpYml0LWJvb2ttYXJrLWp1bXAtd2luZG93LWFj dGlvbnMuCihib29rbWFyay1qdW1wKTogTWVudGlvbiAnaW5oaWJpdC1ib29rbWFyay1qdW1wLXdp bmRvdy1hY3Rpb25zIGluIHRoZQpkb2NzdHJpbmcuCi0tLQogbGlzcC9ib29rbWFyay5lbCB8IDI3 ICsrKysrKysrKysrKysrKysrKysrLS0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDIwIGluc2VydGlv bnMoKyksIDcgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvbGlzcC9ib29rbWFyay5lbCBiL2xp c3AvYm9va21hcmsuZWwKaW5kZXggOTliYjI2ZTgzY2MuLjhiMDZkMWMzNzY5IDEwMDY0NAotLS0g YS9saXNwL2Jvb2ttYXJrLmVsCisrKyBiL2xpc3AvYm9va21hcmsuZWwKQEAgLTEyNjUsMTIgKzEy NjUsMjEgQEAgYm9va21hcmstLWp1bXAtdmlhCiAKIEFmdGVyIGNhbGxpbmcgRElTUExBWS1GVU5D VElPTiwgc2V0IHdpbmRvdyBwb2ludCB0byB0aGUgcG9pbnQgc3BlY2lmaWVkCiBieSBCT09LTUFS Sy1OQU1FLU9SLVJFQ09SRCwgaWYgbmVjZXNzYXJ5LCBydW4gYGJvb2ttYXJrLWFmdGVyLWp1bXAt aG9vaycsCi1hbmQgdGhlbiBzaG93IGFueSBhbm5vdGF0aW9ucyBmb3IgdGhpcyBib29rbWFyay4i Ci0gIChsZXQgKGJ1ZiBwb2ludCkKLSAgICAoc2F2ZS13aW5kb3ctZXhjdXJzaW9uCi0gICAgICAo Ym9va21hcmstaGFuZGxlLWJvb2ttYXJrIGJvb2ttYXJrLW5hbWUtb3ItcmVjb3JkKQotICAgICAg KHNldHEgYnVmIChjdXJyZW50LWJ1ZmZlcikKLSAgICAgICAgICAgIHBvaW50IChwb2ludCkpKQor YW5kIHRoZW4gc2hvdyBhbnkgYW5ub3RhdGlvbnMgZm9yIHRoaXMgYm9va21hcmsuCisKK0lmIHRo ZSBib29rbWFyayByZWNvcmQgYXNzb2NpYXRlZCB3aXRoIEJPT0tNQVJLLU5BTUUtT1ItUkVDT1JE IGNvbnRhaW5zCithIG5vbi1uaWwgcHJvcGVydHkgXFw9J2luaGliaXQtYm9va21hcmstanVtcC13 aW5kb3ctYWN0aW9ucywgd2luZG93CithY3Rpb25zIGFyZSBwcmVzdW1lZCB0byBiZSBoYW5kbGVk IGJ5IHRoZSBib29rbWFyaydzIGhhbmRsZXIuIgorICAobGV0ICgoaW5oaWJpdC13aW5kb3ctYWN0 aW9ucworICAgICAgICAgKGJvb2ttYXJrLXByb3AtZ2V0IGJvb2ttYXJrLW5hbWUtb3ItcmVjb3Jk CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgJ2luaGliaXQtYm9va21hcmstanVtcC13aW5k b3ctYWN0aW9ucykpCisgICAgICAgIGJ1ZiBwb2ludCkKKyAgICAoaWYgaW5oaWJpdC13aW5kb3ct YWN0aW9ucworICAgICAgICAoYm9va21hcmstaGFuZGxlLWJvb2ttYXJrIGJvb2ttYXJrLW5hbWUt b3ItcmVjb3JkKQorICAgICAgKHNhdmUtd2luZG93LWV4Y3Vyc2lvbgorICAgICAgICAoYm9va21h cmstaGFuZGxlLWJvb2ttYXJrIGJvb2ttYXJrLW5hbWUtb3ItcmVjb3JkKSkpCisgICAgKHNldHEg YnVmIChjdXJyZW50LWJ1ZmZlcikKKyAgICAgICAgICBwb2ludCAocG9pbnQpKQogICAgIChmdW5j YWxsIGRpc3BsYXktZnVuY3Rpb24gYnVmKQogICAgICh3aGVuLWxldCogKCh3aW4gKGdldC1idWZm ZXItd2luZG93IGJ1ZiAwKSkpCiAgICAgICAoc2V0LXdpbmRvdy1wb2ludCB3aW4gcG9pbnQpKQpA QCAtMTMwOSw3ICsxMzE4LDExIEBAIGJvb2ttYXJrLWp1bXAKIAogSWYgRElTUExBWS1GVU5DIGlz IG5vbi1uaWwsIGl0IGlzIGEgZnVuY3Rpb24gdG8gaW52b2tlIHRvIGRpc3BsYXkgdGhlCiBib29r bWFyay4gIEl0IGRlZmF1bHRzIHRvIGBwb3AtdG8tYnVmZmVyLXNhbWUtd2luZG93Jy4gIEEgdHlw aWNhbCB2YWx1ZSBmb3IKLURJU1BMQVktRlVOQyB3b3VsZCBiZSBgc3dpdGNoLXRvLWJ1ZmZlci1v dGhlci13aW5kb3cnLiIKK0RJU1BMQVktRlVOQyB3b3VsZCBiZSBgc3dpdGNoLXRvLWJ1ZmZlci1v dGhlci13aW5kb3cnLgorCitJZiB0aGUgQk9PS01BUksgcmVjb3JkIGNvbnRhaW5zIGEgbm9uLW5p bCBwcm9wZXJ0eQorXFw9J2luaGliaXQtYm9va21hcmstanVtcC13aW5kb3ctYWN0aW9ucywgd2lu ZG93IGFjdGlvbnMgYXJlIHByZXN1bWVkIHRvCitiZSBoYW5kbGVkIGJ5IHRoZSBib29rbWFyaydz IGhhbmRsZXIuIgogICAoaW50ZXJhY3RpdmUKICAgIChsaXN0IChib29rbWFyay1jb21wbGV0aW5n LXJlYWQgIkp1bXAgdG8gYm9va21hcmsiCiAJCQkJICAgYm9va21hcmstY3VycmVudC1ib29rbWFy aykpKQotLSAKMi40Ny4xCgo= --00000000000034fa7b06307c1cc0-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 17 06:35:44 2025 Received: (at submit) by debbugs.gnu.org; 17 Mar 2025 10:35:44 +0000 Received: from localhost ([127.0.0.1]:55902 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tu7or-0006NQ-OT for submit@debbugs.gnu.org; Mon, 17 Mar 2025 06:35:43 -0400 Received: from lists.gnu.org ([2001:470:142::17]:41322) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tu7om-0006Lt-J4 for submit@debbugs.gnu.org; Mon, 17 Mar 2025 06:35:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tu7od-0002QP-Fu for bug-gnu-emacs@gnu.org; Mon, 17 Mar 2025 06:35:29 -0400 Received: from mail-vk1-xa35.google.com ([2607:f8b0:4864:20::a35]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tu7oa-0005xv-19; Mon, 17 Mar 2025 06:35:26 -0400 Received: by mail-vk1-xa35.google.com with SMTP id 71dfb90a1353d-523f670ca99so1784818e0c.1; Mon, 17 Mar 2025 03:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742207722; x=1742812522; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oUeD3zPfoPWMO4U2lue+McdGUjeW1xRJ8sj21EgowcU=; b=aHIuI40+ha6+pS9aJQ0U2EtdhGHIvqUGv6wKKnX+SBmQagnN4Yhj1zX8oLCQvgpEeU 5RioOxwZXgv3FszjYk0zJa+4sAEBTtfbtSdjc90r5WxTTxW913EmRRXikH7WUc5wDhrb wS/OzqNjd3muT7GIEfgVqtO1Bo+/j1Mslsw/X6ccOebsWiJnQlqAJNMOxBHH0abr2u9r jjiKvnY6y4MFAJUGk+ZZsph7cKRr0PL00EcqP92sFrObtTLWqaWBGIUQgSmR9zKeBNsV G2vSXP04i8lDH8DDhbMNxVpEOZJoqLAoU1IVWv2uq7xStsc31D/m/dWi5NiCqyWb7b67 lLYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742207722; x=1742812522; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oUeD3zPfoPWMO4U2lue+McdGUjeW1xRJ8sj21EgowcU=; b=SX9m9L+gluUCEBfWF9r2BQ2c9F2UxrViepV0UDdCdYIINFLibW8mmql1v4jpv4eD0c Ws8izKWdR5h5ZPfD31xXm60SuwUpWYgtCLGhNoywOs2+9MXBWKks6wVJneYNJBWVCSQs dngLT3/AX6vdW/EDsYlBoGh58lasOTVkR7sFf+TW1/GO1rlefx8Cc/6I6ApVRbfBVonj lYvcn34IfpkYmpgecfLw8oKmWYpOC1S8VO4G3CLQD1JQJstoc4kzjr1Tor0s6eIUV6Bi RWuUbGY0BUkAFX5LBBaPnEDYlmltP+8ow0BZ/CxaG/av71iRtgqnQ1IcFF/6Sk58YM+b L+8w== X-Forwarded-Encrypted: i=1; AJvYcCVRP0Y27zMW0lz41HLFfmDwZAysPDhoYflfWLaeCsNw167LY81FoOTtL4DxS+z1zy2ncDULLX7NBP7GXe7G@gnu.org X-Gm-Message-State: AOJu0Yx+4hVJuWB068cDDxXDWUSD1eO7zqSNWQZoaRUcQb2l4IvhOC+Y /SBOP5v4T0ewKZBrAjIgXHPLDkdxH0f9yZrwF7bP/25HdlY+kMFTd9qXkG9MEIy0NlenBk404xz IoH91kQGoOK24zrUghg6cY2KBlI6idjyS X-Gm-Gg: ASbGncsUwJWLDBcfdmLowL14Rlwi4d45zbeGS2SQO5UnXo+A0/EDnlc7mcRKY5kiD5Z T/FIOXOvLF9HAQ6Yq3Sd6KDp/fPmXvsd+PYlq1ZH3VtePFkgZ615XDJNXwkT8EDKYH9qMhEnFa5 29exameEbs3zgkoJez1tUqYgcXVw== X-Google-Smtp-Source: AGHT+IF/qB9KTOLdgSLnrDUQxDWOZVeYR67eR+l6abWudoDH5y9P5e/acEzs7/sYK52d0u/w7ZHmjRVqxT+ZhkKNGfk= X-Received: by 2002:a05:6122:438a:b0:518:a0ac:1f42 with SMTP id 71dfb90a1353d-524498b1aa5mr5823312e0c.1.1742207722650; Mon, 17 Mar 2025 03:35:22 -0700 (PDT) MIME-Version: 1.0 References: <874izwn306.fsf@posteo.net> <87y0x8kyaq.fsf@posteo.net> <877c4r6cok.fsf@posteo.net> <871puy6e5x.fsf@posteo.net> In-Reply-To: From: Ship Mints Date: Mon, 17 Mar 2025 06:35:10 -0400 X-Gm-Features: AQ5f1JpoyrTdZ7S8Rog8pn_m5BjZpgIP_13TzCLj6Az6Kw4liHp3KV_7Otie3uQ Message-ID: Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) To: Thierry Volpiatto Content-Type: multipart/alternative; boundary="0000000000006f03330630875839" Received-SPF: pass client-ip=2607:f8b0:4864:20::a35; envelope-from=shipmints@gmail.com; helo=mail-vk1-xa35.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --0000000000006f03330630875839 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Mar 16, 2025 at 5:10=E2=80=AFPM Ship Mints wr= ote: > On Sat, Mar 15, 2025 at 10:18=E2=80=AFAM Ship Mints = wrote: > >> On Sat, Mar 15, 2025 at 1:37=E2=80=AFAM Thierry Volpiatto >> wrote: >> >>> Ship Mints writes: >>> >>> > I have workarounds that work only for the most simplistic cases. Man= y >>> > of our bookmarks themselves contain embedded bookmarks and bookmark >>> > references (which are individually addressable so can be used >>> > separately) with window-states we need to restore in tab-bar tabs tha= t >>> > they represent. >>> >>> I don't really understand what your packages are doing or are intended >>> doing, but FWICS in bufferlo: You are using in some places >>> (bookmark-jump name #'ignore); why don't you do all this work (restore >>> window-states in tab) in DISPLAY-FUNCTION instead of using `ignore`? >>> Your handler would be much simpler by moving the window-state-put and >>> alike calls in DISPLAY-FUNCTION: >>> >>> (bookmark-jump name #'your_function_restoring_window_or_frame_state) >>> >>> Using (bookmark-jump name #'ignore) with all the code that jump to >>> frame/tab etc... in the handler is just a workaround to fix the previou= s >>> buggy behavior of bookmark--jump-via. IMO. >>> >>> It would be good to start with a good example or recipe to see if we ca= n >>> find a good solution. >>> >> >> We need the bookmarks to work from the bookmark menu where no >> display-function overrides are supported. >> >> I suggest we add bookmark-record keys that indicate to bookmark-jump to >> inhibit/or allow messing with window-configurations. The bufferlo >> bookmarks (and Adam's if he wants) would contain these hint keys. >> >> '(bookmark-jump-inhibit-window-actions . t) ; or whatever we come up wit= h >> >> I can contrive an example, if necessary, but I believe y'all get the >> point. Nested bookmarks whose handlers expect their window-configuratio= ns >> not to be messed with up the chain, will always be broken without >> additional controls. >> > > The attached patch implements such a scheme that works for us, and is > transparent to other bookmark uses. > Perhaps we should restore bookmark--jump-via to its previous behavior and better document the "rules of the road" for bookmark handlers. For simple file- and point-based bookmarks, handlers need to ensure that when they return, the selected window and current buffer are what's intended. For bookmark handlers that perform other actions, those rules need not apply to leverage the bookmark infrastructure. eww's handler could simply do this itself since it seems eww's url opening behavior warrants this: (defun eww-bookmark-jump (bookmark) "Default bookmark handler for EWW buffers." (save-window-excursion (eww (bookmark-prop-get bookmark 'location)))) I'd also suggest that we recommend adding an additional property to a bookmark-handler function that could inhibit bookmark--jump-via's call to display-func entirely. In our case, when called programmatically, we use #'ignore, but when the bookmark menu is used, we'd prefer to skip the default pop-to-buffer-same-window. --0000000000006f03330630875839 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Sun, Mar 16, 2025 at 5:10=E2=80=AFPM Ship Mints <shipmints@gmail.com> wrote:
On = Sat, Mar 15, 2025 at 10:18=E2=80=AFAM Ship Mints <shipmints@gmail.com> wrote:
On Sat, M= ar 15, 2025 at 1:37=E2=80=AFAM Thierry Volpiatto <thievol@posteo.net> wrote:<= /div>
Ship Mints <shipmints@gmail.com> writes:

> I have workarounds that work only for the most simplistic cases.=C2=A0= Many
> of our=C2=A0bookmarks themselves contain embedded bookmarks and bookma= rk
> references (which are individually addressable so can be used
> separately) with window-states we need to restore in tab-bar tabs that=
> they represent.

I don't really understand what your packages are doing or are intended<= br> doing, but FWICS in bufferlo: You are using in some places
(bookmark-jump name #'ignore); why don't you do all this work (rest= ore
window-states in tab) in DISPLAY-FUNCTION instead of using `ignore`?
Your handler would be much simpler by moving the window-state-put and
alike calls in DISPLAY-FUNCTION:

(bookmark-jump name #'your_function_restoring_window_or_frame_state)=C2= =A0

Using (bookmark-jump name #'ignore) with all the code that jump to
frame/tab etc... in the handler is just a workaround to fix the previous buggy behavior of bookmark--jump-via. IMO.

It would be good to start with a good example or recipe to see if we can find a good solution.

We need the bookmarks to work from the bookmark menu where n= o display-function overrides are supported.

I suggest we add = bookmark-record keys that indicate to bookmark-jump to inhibit/or allow mes= sing with window-configurations.=C2=A0 The bufferlo bookmarks (and Adam'= ;s if he wants) would contain these hint keys.

'(bookmark= -jump-inhibit-window-actions . t) ; or whatever we come up with

I can contrive an example, if necessary, but I believe y'all get the= point.=C2=A0 Nested bookmarks whose handlers expect their window-configura= tions not to be messed with up the chain,=C2=A0will always be broken withou= t additional controls.

The attached patch implements such a scheme t= hat works for us, and is transparent to other=C2=A0bookmark=C2=A0uses.

Perhaps we should restore bookmark--jump-vi= a to its previous behavior and better document the "rules of the road&= quot; for bookmark handlers.=C2=A0 For simple file- and point-based bookmar= ks, handlers need to ensure that when they return, the selected window and = current buffer are what's intended.=C2=A0 For bookmark handlers that pe= rform other actions, those rules need not apply to leverage the bookmark in= frastructure.

eww's handler could simply do this itself since it seems=C2=A0eww'= s=C2=A0url opening behavior warrants this:

(defun eww-bookmark-jump (bookmark)
=C2=A0 "Defau= lt bookmark handler for EWW buffers."
=C2=A0 (save-window-excursion
=C2=A0 = =C2=A0 (eww (bookmark-prop-get bookmark 'location))))

I'd also suggest tha= t we recommend adding an additional property to a bookmark-handler function= that could inhibit bookmark--jump-via's call to display-func entirely.= =C2=A0 In our case, when called programmatically, we use #'ignore, but = when the bookmark menu is used, we'd prefer to skip the default pop-to-= buffer-same-window.
--0000000000006f03330630875839-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 17 06:42:01 2025 Received: (at submit) by debbugs.gnu.org; 17 Mar 2025 10:42:02 +0000 Received: from localhost ([127.0.0.1]:55925 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tu7ux-0007Nd-2B for submit@debbugs.gnu.org; Mon, 17 Mar 2025 06:42:01 -0400 Received: from lists.gnu.org ([2001:470:142::17]:58238) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tu7ut-0007M3-2u for submit@debbugs.gnu.org; Mon, 17 Mar 2025 06:41:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tu7ul-0003qz-TD for bug-gnu-emacs@gnu.org; Mon, 17 Mar 2025 06:41:49 -0400 Received: from mail-vk1-xa2e.google.com ([2607:f8b0:4864:20::a2e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tu7uj-0006kq-LV; Mon, 17 Mar 2025 06:41:47 -0400 Received: by mail-vk1-xa2e.google.com with SMTP id 71dfb90a1353d-51eb18130f9so2008643e0c.3; Mon, 17 Mar 2025 03:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742208104; x=1742812904; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=09A5D8XhnUD5AZIqxM6/HQJDtwKqrkb5zDk11uXcj3k=; b=EL+frf3hBicFkypM7qX7jYDWlB8h5hjlqI8J1yu5zQ/3VNlnB1eM7HKrbyCtIZcdIB dAQOSoosSaQuC1gsxqVqlFbBbVz0SQsAR7tBQNw97Nfi9M7DRtomiWeIUQWWoVWZ9hs2 pzmJW55o6ig/jP1BKI8/TDYl1Ics2c650lI4bkl17q/z+2JJDs01E7b1E9pazhDuhE+Q xLgSS6Yke6gFv+dV7u1n+/ypdC5SlvasV8Lnf7LAMNk4JS/FxpmJFlsWKslrNowHcNsZ S4THpjgfZKnMo/XEKE/40PpAmeN/vLeQQV2MbFErFNDJg7eE6tB+mh7LPwLDOroKKOnO KjGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742208104; x=1742812904; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=09A5D8XhnUD5AZIqxM6/HQJDtwKqrkb5zDk11uXcj3k=; b=sMuNLVBA6nhuItyNmbr88nXjLJ8VcrLcnmO7M8ugUXZjdW645sHC6b1rCtmJyw9Vd3 M4r8mKo9+B2f1k01ovtPO8b9A1HrpASBX3zUiBBIY3mG6Pnh+Tv0meLKN6phfT/WLqSm /jDGQcXROcrtuinmKUZWIqwZHeOCl9vbRoERblZHUpnq/A74dxxWat0u39NiMgRAl/Xp MMNWQibBkFXUEDbTZAyBz+hDg0X5uelDbWvMd3Nqn800G+Vdndpup2XS1PRr8z0Mm7D9 yiYinymnJc6Qrt+x6NSnIQmK8wD1XlFDpQqEE5pLJUDjFUQmmTn8FgqrA2gIxpaKO4jJ GJAg== X-Forwarded-Encrypted: i=1; AJvYcCWJNAN0wyPqp07DpwdxlOt0Cc9wwEgKGW9/8XAplssO089JK0EvMTRlTWpxkAlTAz9zyyGcV9xdVpm/sXZJ@gnu.org X-Gm-Message-State: AOJu0Yw1oItwfd9+xEaPObfqdJq+syPU1hbrjYCBAZZqQ4UeNiMJX4yE Wv7ULihPK2z03RlPOdrJaYVdwiThyuiHmjTHraPy1NY+fmyBQdJexbeYAbmfczVujUIzUcbBfSm WLZ6E6Th3h+6kbjnG5LX/hMr8Cyb9kila X-Gm-Gg: ASbGncvZc6gp0dT8kbfajfUf0UqKelyiOQc9hwlZcp8wP+I+AVp50tzH4eCJwBJfuvt 0k8ja9l7XD1vmiqp6LbejcEsXTJ5TXq6OTdn8CmqFegBhut9p6N0BoOWA9EY+uLY/GsxEPY2S2/ RUtybJsqUxZXXgcuPw2ktHijIECYxSO3QPeXpM X-Google-Smtp-Source: AGHT+IErSru3NM0q7j3CuXW8mISjgNqTkk2LWDx92pxiLdektHcrEWDU8Ss+sbo6Lltt9CBVO/IWiHfevfQZL/V7K3w= X-Received: by 2002:a05:6102:3f53:b0:4c1:9f48:617e with SMTP id ada2fe7eead31-4c383226b89mr7611019137.21.1742208104144; Mon, 17 Mar 2025 03:41:44 -0700 (PDT) MIME-Version: 1.0 References: <874izwn306.fsf@posteo.net> <87y0x8kyaq.fsf@posteo.net> <877c4r6cok.fsf@posteo.net> <871puy6e5x.fsf@posteo.net> In-Reply-To: From: Ship Mints Date: Mon, 17 Mar 2025 06:41:32 -0400 X-Gm-Features: AQ5f1JryRcoj4gTUkBAKuGjR4KTiYATiX6VsZSHZ5LW1jB8k7l5cux1kdjWd-g4 Message-ID: Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) To: Thierry Volpiatto Content-Type: multipart/alternative; boundary="0000000000002c24980630876f16" Received-SPF: pass client-ip=2607:f8b0:4864:20::a2e; envelope-from=shipmints@gmail.com; helo=mail-vk1-xa2e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --0000000000002c24980630876f16 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 17, 2025 at 6:35=E2=80=AFAM Ship Mints wr= ote: > On Sun, Mar 16, 2025 at 5:10=E2=80=AFPM Ship Mints = wrote: > >> On Sat, Mar 15, 2025 at 10:18=E2=80=AFAM Ship Mints wrote: >> >>> On Sat, Mar 15, 2025 at 1:37=E2=80=AFAM Thierry Volpiatto >>> wrote: >>> >>>> Ship Mints writes: >>>> >>>> > I have workarounds that work only for the most simplistic cases. Ma= ny >>>> > of our bookmarks themselves contain embedded bookmarks and bookmark >>>> > references (which are individually addressable so can be used >>>> > separately) with window-states we need to restore in tab-bar tabs th= at >>>> > they represent. >>>> >>>> I don't really understand what your packages are doing or are intended >>>> doing, but FWICS in bufferlo: You are using in some places >>>> (bookmark-jump name #'ignore); why don't you do all this work (restore >>>> window-states in tab) in DISPLAY-FUNCTION instead of using `ignore`? >>>> Your handler would be much simpler by moving the window-state-put and >>>> alike calls in DISPLAY-FUNCTION: >>>> >>>> (bookmark-jump name #'your_function_restoring_window_or_frame_state) >>>> >>>> Using (bookmark-jump name #'ignore) with all the code that jump to >>>> frame/tab etc... in the handler is just a workaround to fix the previo= us >>>> buggy behavior of bookmark--jump-via. IMO. >>>> >>>> It would be good to start with a good example or recipe to see if we c= an >>>> find a good solution. >>>> >>> >>> We need the bookmarks to work from the bookmark menu where no >>> display-function overrides are supported. >>> >>> I suggest we add bookmark-record keys that indicate to bookmark-jump to >>> inhibit/or allow messing with window-configurations. The bufferlo >>> bookmarks (and Adam's if he wants) would contain these hint keys. >>> >>> '(bookmark-jump-inhibit-window-actions . t) ; or whatever we come up wi= th >>> >>> I can contrive an example, if necessary, but I believe y'all get the >>> point. Nested bookmarks whose handlers expect their window-configurati= ons >>> not to be messed with up the chain, will always be broken without >>> additional controls. >>> >> >> The attached patch implements such a scheme that works for us, and is >> transparent to other bookmark uses. >> > > Perhaps we should restore bookmark--jump-via to its previous behavior and > better document the "rules of the road" for bookmark handlers. For simpl= e > file- and point-based bookmarks, handlers need to ensure that when they > return, the selected window and current buffer are what's intended. For > bookmark handlers that perform other actions, those rules need not apply = to > leverage the bookmark infrastructure. > > eww's handler could simply do this itself since it seems eww's url openin= g > behavior warrants this: > > (defun eww-bookmark-jump (bookmark) > "Default bookmark handler for EWW buffers." > (save-window-excursion > (eww (bookmark-prop-get bookmark 'location)))) > > I'd also suggest that we recommend adding an additional property to a > bookmark-handler function that could inhibit bookmark--jump-via's call to > display-func entirely. In our case, when called programmatically, we use > #'ignore, but when the bookmark menu is used, we'd prefer to skip the > default pop-to-buffer-same-window. > Here's an example of another handler in the wild that handles its own save-window-excursion: https://github.com/emacsmirror/info-plus/blob/c6e26367abd2e99791f6e85fced23= 83de9ec605a/info%2B.el#L7025C1-L7039C98 (defun Info-bookmark-jump (bookmark) "Handler function for record returned by `Info-bookmark-make-record'. BOOKMARK is a bookmark name or a bookmark record. If `Info-bookmark-use-only-node-not-file-flag' is nil, and the recorded Info file is readable, then use it. If not, then go to the recorded Info node in the manual for the current Emacs version." (let* ((absfile (bookmark-prop-get bookmark 'filename)) (file (if (or Info-bookmark-use-only-node-not-file-flag (not (file-readable-p absfile))) (file-name-nondirectory absfile) absfile)) (info-node (bookmark-prop-get bookmark 'info-node)) (buf (save-window-excursion ; Vanilla FIXME: doesn't work with frames! (Info-find-node file info-node) (current-buffer)))) (bookmark-default-handler `("" (buffer . ,buf) . ,(bookmark-get-bookmark-record bookmark))))) --0000000000002c24980630876f16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Mon, Mar 17, 2025 at 6:35=E2=80=AFAM Ship Mints <shipmints@gmail.com> wrote:
On = Sun, Mar 16, 2025 at 5:10=E2=80=AFPM Ship Mints <shipmints@gmail.com> wrote:=
On Sat, Ma= r 15, 2025 at 10:18=E2=80=AFAM Ship Mints <shipmints@gmail.com> wrote:
=
On Sat, Mar 15, = 2025 at 1:37=E2=80=AFAM Thierry Volpiatto <thievol@posteo.net> wrote:
Ship Mints <shipmints@gmail.com> writes:

> I have workarounds that work only for the most simplistic cases.=C2=A0= Many
> of our=C2=A0bookmarks themselves contain embedded bookmarks and bookma= rk
> references (which are individually addressable so can be used
> separately) with window-states we need to restore in tab-bar tabs that=
> they represent.

I don't really understand what your packages are doing or are intended<= br> doing, but FWICS in bufferlo: You are using in some places
(bookmark-jump name #'ignore); why don't you do all this work (rest= ore
window-states in tab) in DISPLAY-FUNCTION instead of using `ignore`?
Your handler would be much simpler by moving the window-state-put and
alike calls in DISPLAY-FUNCTION:

(bookmark-jump name #'your_function_restoring_window_or_frame_state)=C2= =A0

Using (bookmark-jump name #'ignore) with all the code that jump to
frame/tab etc... in the handler is just a workaround to fix the previous buggy behavior of bookmark--jump-via. IMO.

It would be good to start with a good example or recipe to see if we can find a good solution.

We need the bookmarks to work from the bookmark menu where n= o display-function overrides are supported.

I suggest we add = bookmark-record keys that indicate to bookmark-jump to inhibit/or allow mes= sing with window-configurations.=C2=A0 The bufferlo bookmarks (and Adam'= ;s if he wants) would contain these hint keys.

'(bookmark= -jump-inhibit-window-actions . t) ; or whatever we come up with

I can contrive an example, if necessary, but I believe y'all get the= point.=C2=A0 Nested bookmarks whose handlers expect their window-configura= tions not to be messed with up the chain,=C2=A0will always be broken withou= t additional controls.

The attached patch implements such a scheme t= hat works for us, and is transparent to other=C2=A0bookmark=C2=A0uses.

Perhaps we should restore bookmark--jump-via to its previous behavi= or and better document the "rules of the road" for bookmark handl= ers.=C2=A0 For simple file- and point-based bookmarks, handlers need to ens= ure that when they return, the selected window and current buffer are what&= #39;s intended.=C2=A0 For bookmark handlers that perform other actions, tho= se rules need not apply to leverage the bookmark infrastructure.

eww's handler could simply do this itself since it seems=C2=A0eww&#= 39;s=C2=A0url opening behavior warrants this:

(defun eww-book= mark-jump (bookmark)
=C2=A0 "= ;Default bookmark handler for EWW buffers."
=C2=A0 (save-window-excursion
=C2=A0 =C2=A0 (eww (bookma= rk-prop-get bookmark 'location))))

I'd also sug= gest that we recommend adding an additional property to a bookmark-handler = function that could inhibit bookmark--jump-via's call to display-func e= ntirely.=C2=A0 In our case, when called programmatically, we use #'igno= re, but when the bookmark menu is used, we'd prefer to skip the default= pop-to-buffer-same-window.

Here's an ex= ample of another handler in the wild that handles its own save-window-excur= sion:
https://github.com/emacsmirror= /info-plus/blob/c6e26367abd2e99791f6e85fced2383de9ec605a/info%2B.el#L7025C1= -L7039C98

(defun Info-bookmark-jump (bookmark)
=C2=A0 "Handler function for = record returned by `Info-bookmark-make-record'.
BOOKMARK is a bookma= rk name or a bookmark record.

If `Info-bookmark-use-only-node-not-fi= le-flag' is nil, and the
recorded Info file is readable, then use it= .=C2=A0 If not, then go to the
recorded Info node in the manual for the = current Emacs version."
=C2=A0 (let* ((absfile =C2=A0 =C2=A0(bookma= rk-prop-get bookmark 'filename))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(= file =C2=A0 =C2=A0 =C2=A0 (if (or Info-bookmark-use-only-node-not-file-flag= =C2=A0(not (file-readable-p absfile)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(file-name-nondi= rectory absfile)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0absfile))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= (info-node =C2=A0(bookmark-prop-get bookmark 'info-node))
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0(buf =C2=A0 =C2=A0 =C2=A0 =C2=A0(save-window-excurs= ion ; Vanilla FIXME: doesn't work with frames!
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(Info-find-no= de file info-node) (current-buffer))))
=C2=A0 =C2=A0 (bookmark-default-h= andler `("" (buffer . ,buf) . ,(bookmark-get-bookmark-record book= mark)))))

--0000000000002c24980630876f16-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 17 06:44:36 2025 Received: (at submit) by debbugs.gnu.org; 17 Mar 2025 10:44:37 +0000 Received: from localhost ([127.0.0.1]:55937 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tu7xQ-0007kk-Ny for submit@debbugs.gnu.org; Mon, 17 Mar 2025 06:44:36 -0400 Received: from lists.gnu.org ([2001:470:142::17]:38394) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tu7xJ-0007im-LJ for submit@debbugs.gnu.org; Mon, 17 Mar 2025 06:44:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tu7xE-00059f-9q for bug-gnu-emacs@gnu.org; Mon, 17 Mar 2025 06:44:20 -0400 Received: from mail-vk1-xa32.google.com ([2607:f8b0:4864:20::a32]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tu7xA-00072X-5d; Mon, 17 Mar 2025 06:44:18 -0400 Received: by mail-vk1-xa32.google.com with SMTP id 71dfb90a1353d-523fa0df55dso4818734e0c.1; Mon, 17 Mar 2025 03:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742208254; x=1742813054; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9Q4koufevaM+qTGuAlhFuPj7d51783/NZM8A76qZZ0I=; b=DDarrH/QnJqVKegOhenQdmGPAyW7T7IKF5U0T0ZbUVbqOD3L4m2/B0QeHDRYMDFgKD +5zUq4U2Eco4BBdemLpMwMtsYd3fskx0L4tP2l83fvdf3ClO3IBe4xouFnaAPuXtQIg8 rxvXo2icC7ivDTDCgKiS/p5FoRN6zSFqvhdZ6S8hb6qb6qRNBfzRA635dFGgFKdKV6m/ FRRGJ5mR6rlgEqUKoRt3/YK0YUiz7uGY8Nb0zEP4N5jILr9GZXBO2VIYRzIBFdcoauvX Q9DqKig+veJcEz0b1wGcM8dfN65K/86BNgQ8vFIxGEoEt9nwgtLE//ZsjZyyj87/TVWk 4qdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742208254; x=1742813054; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9Q4koufevaM+qTGuAlhFuPj7d51783/NZM8A76qZZ0I=; b=aXEyX/K4nFID2zGb/3NrHazfHVJQPFgyKtGH2YZDm9yyG8R8EKzyemSi0HH8kn/wrJ XSMdi3B+i3zIfpVADb65JerAyFuNs7agMy+dLa/Bt9VbaulGm7dOSAnrHGWA4xA9SQmS K38fywd0UBWxDjJUgRC5wYHXdVmDaxGO3UD+8bK2PUQzlnuNjjX9McjgEf8DZZTu2aHM ifSKksoL+ANTM6HjLoBL58s6+fAJM/MLZf61aD3rd13GopZSzmA6U528jxnbTEzY/jrT LdADANp4O0GeCMsT6stumMEpz55PTOdU2/l/k8vxS6KK59J575lPuoLg8p6cok76QO8Y Zirw== X-Forwarded-Encrypted: i=1; AJvYcCVRfS6o6e8QjFKwEVEeMQ1GTo05GWEnEAP6xXftpofH2Ul3QgsBYagrVE1t9/JdwvwJhvlsCuVKOJiz/ig4@gnu.org X-Gm-Message-State: AOJu0YzrxbhsYJfEVplLDTzxG2Wn1yjyZaa9l306hlXI2d9A5UBfhEGC RFcTV7cZhDgWNBDBIiguNh91LDM+VXeYxdDoKmHiFDcmunqHqm/Rx5C8ej87WPzCnT6umej1l+R DrBw4cn3+z2gy0NlfDmiCzQou9Z5hG5ZA X-Gm-Gg: ASbGncvHO88maNS9ZTJLqDrnMGCHXzirwbZsNRbKozBXXI8n1uzoOuCzfDHoP7BTW5R bYVbAJBWhZT25sXpEPwiLpPrx8os+ypFlWA4hd4l/VRBYLXFd7hUBK0fQ30D+Rldc6Bp+KPrdC9 K4i0e87EslZ4NsJn9CN8R8M4daYHDp3jkOhHD4 X-Google-Smtp-Source: AGHT+IE4d21W29F69anKvqelomTiu4eZ9/3/S9FTcAjGRTGEM8VdNhMd4U56gsjoIHgBsRRc4jRn7E1C4dxUSPBv8nw= X-Received: by 2002:a05:6102:2b89:b0:4c3:243:331a with SMTP id ada2fe7eead31-4c371bc6d7dmr12389594137.6.1742208254151; Mon, 17 Mar 2025 03:44:14 -0700 (PDT) MIME-Version: 1.0 References: <874izwn306.fsf@posteo.net> <87y0x8kyaq.fsf@posteo.net> <877c4r6cok.fsf@posteo.net> <871puy6e5x.fsf@posteo.net> In-Reply-To: From: Ship Mints Date: Mon, 17 Mar 2025 06:44:02 -0400 X-Gm-Features: AQ5f1JoeIaU7g0SE-eptkb6k2DASMBfBIQgh_rSSIMWcZW3lFCaKq5MSqaYd7pg Message-ID: Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) To: Thierry Volpiatto Content-Type: multipart/alternative; boundary="0000000000001d151906308778d3" Received-SPF: pass client-ip=2607:f8b0:4864:20::a32; envelope-from=shipmints@gmail.com; helo=mail-vk1-xa32.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --0000000000001d151906308778d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 17, 2025 at 6:41=E2=80=AFAM Ship Mints wr= ote: > On Mon, Mar 17, 2025 at 6:35=E2=80=AFAM Ship Mints = wrote: > >> On Sun, Mar 16, 2025 at 5:10=E2=80=AFPM Ship Mints = wrote: >> >>> On Sat, Mar 15, 2025 at 10:18=E2=80=AFAM Ship Mints wrote: >>> >>>> On Sat, Mar 15, 2025 at 1:37=E2=80=AFAM Thierry Volpiatto >>>> wrote: >>>> >>>>> Ship Mints writes: >>>>> >>>>> > I have workarounds that work only for the most simplistic cases. >>>>> Many >>>>> > of our bookmarks themselves contain embedded bookmarks and bookmark >>>>> > references (which are individually addressable so can be used >>>>> > separately) with window-states we need to restore in tab-bar tabs >>>>> that >>>>> > they represent. >>>>> >>>>> I don't really understand what your packages are doing or are intende= d >>>>> doing, but FWICS in bufferlo: You are using in some places >>>>> (bookmark-jump name #'ignore); why don't you do all this work (restor= e >>>>> window-states in tab) in DISPLAY-FUNCTION instead of using `ignore`? >>>>> Your handler would be much simpler by moving the window-state-put and >>>>> alike calls in DISPLAY-FUNCTION: >>>>> >>>>> (bookmark-jump name #'your_function_restoring_window_or_frame_state) >>>>> >>>>> Using (bookmark-jump name #'ignore) with all the code that jump to >>>>> frame/tab etc... in the handler is just a workaround to fix the >>>>> previous >>>>> buggy behavior of bookmark--jump-via. IMO. >>>>> >>>>> It would be good to start with a good example or recipe to see if we >>>>> can >>>>> find a good solution. >>>>> >>>> >>>> We need the bookmarks to work from the bookmark menu where no >>>> display-function overrides are supported. >>>> >>>> I suggest we add bookmark-record keys that indicate to bookmark-jump t= o >>>> inhibit/or allow messing with window-configurations. The bufferlo >>>> bookmarks (and Adam's if he wants) would contain these hint keys. >>>> >>>> '(bookmark-jump-inhibit-window-actions . t) ; or whatever we come up >>>> with >>>> >>>> I can contrive an example, if necessary, but I believe y'all get the >>>> point. Nested bookmarks whose handlers expect their window-configurat= ions >>>> not to be messed with up the chain, will always be broken without >>>> additional controls. >>>> >>> >>> The attached patch implements such a scheme that works for us, and is >>> transparent to other bookmark uses. >>> >> >> Perhaps we should restore bookmark--jump-via to its previous behavior an= d >> better document the "rules of the road" for bookmark handlers. For simp= le >> file- and point-based bookmarks, handlers need to ensure that when they >> return, the selected window and current buffer are what's intended. For >> bookmark handlers that perform other actions, those rules need not apply= to >> leverage the bookmark infrastructure. >> >> eww's handler could simply do this itself since it seems eww's url >> opening behavior warrants this: >> >> (defun eww-bookmark-jump (bookmark) >> "Default bookmark handler for EWW buffers." >> (save-window-excursion >> (eww (bookmark-prop-get bookmark 'location)))) >> >> I'd also suggest that we recommend adding an additional property to a >> bookmark-handler function that could inhibit bookmark--jump-via's call t= o >> display-func entirely. In our case, when called programmatically, we us= e >> #'ignore, but when the bookmark menu is used, we'd prefer to skip the >> default pop-to-buffer-same-window. >> > > Here's an example of another handler in the wild that handles its own > save-window-excursion: > > > https://github.com/emacsmirror/info-plus/blob/c6e26367abd2e99791f6e85fced= 2383de9ec605a/info%2B.el#L7025C1-L7039C98 > > (defun Info-bookmark-jump (bookmark) > "Handler function for record returned by `Info-bookmark-make-record'. > BOOKMARK is a bookmark name or a bookmark record. > > If `Info-bookmark-use-only-node-not-file-flag' is nil, and the > recorded Info file is readable, then use it. If not, then go to the > recorded Info node in the manual for the current Emacs version." > (let* ((absfile (bookmark-prop-get bookmark 'filename)) > (file (if (or Info-bookmark-use-only-node-not-file-flag > (not (file-readable-p absfile))) > (file-name-nondirectory absfile) > absfile)) > (info-node (bookmark-prop-get bookmark 'info-node)) > (buf (save-window-excursion ; Vanilla FIXME: doesn't work > with frames! > (Info-find-node file info-node) (current-buffer)))= ) > (bookmark-default-handler `("" (buffer . ,buf) . > ,(bookmark-get-bookmark-record bookmark))))) > And another that handles its own windows which the change to bookmark--jump-via will break: https://github.com/sunrise-commander/sunrise-commander/blob/16e6df7e86c7a38= 3fb4400fae94af32baf9cb24e/sunrise-checkpoint.el#L83 (defun sunrise-checkpoint-handler (&optional bookmark) "Handler for a checkpoint BOOKMARK." (sunrise-ensure-running) (sunrise-select-window 'left) (let ((dirs (cdr (assq 'sunrise-directories (cdr bookmark)))) (missing '())) (mapc (lambda (x) (if (file-directory-p x) (sunrise-save-aspect (dired x) (sunrise-bookmark-jump)) (setq missing (cons sunrise-selected-window missing))) (sunrise-change-window)) dirs) (if missing (sunrise-checkpoint-relocate bookmark (reverse missing))))) https://github.com/sunrise-commander/sunrise-commander/blob/16e6df7e86c7a38= 3fb4400fae94af32baf9cb24e/sunrise.el#L2371 (defun sunrise-change-window() "Change to the other Sunrise pane." (interactive) (sunrise-select-window (sunrise-other-side)) (setq sunrise-selected-window-width nil)) --0000000000001d151906308778d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Mon, Mar 17, 2025 at 6:41=E2=80=AFAM Ship Mints <shipmints@gmail.com> wrote:
On = Mon, Mar 17, 2025 at 6:35=E2=80=AFAM Ship Mints <shipmints@gmail.com> wrote:=
On Sun, Ma= r 16, 2025 at 5:10=E2=80=AFPM Ship Mints <shipmints@gmail.com> wrote:
<= /div>
On Sat, Mar 15, 2= 025 at 10:18=E2=80=AFAM Ship Mints <shipmints@gmail.com> wrote:
<= div class=3D"gmail_quote">
On Sat, Mar 15, 2025 at= 1:37=E2=80=AFAM Thierry Volpiatto <thievol@posteo.net> wrote:
S= hip Mints <ship= mints@gmail.com> writes:

> I have workarounds that work only for the most simplistic cases.=C2=A0= Many
> of our=C2=A0bookmarks themselves contain embedded bookmarks and bookma= rk
> references (which are individually addressable so can be used
> separately) with window-states we need to restore in tab-bar tabs that=
> they represent.

I don't really understand what your packages are doing or are intended<= br> doing, but FWICS in bufferlo: You are using in some places
(bookmark-jump name #'ignore); why don't you do all this work (rest= ore
window-states in tab) in DISPLAY-FUNCTION instead of using `ignore`?
Your handler would be much simpler by moving the window-state-put and
alike calls in DISPLAY-FUNCTION:

(bookmark-jump name #'your_function_restoring_window_or_frame_state)=C2= =A0

Using (bookmark-jump name #'ignore) with all the code that jump to
frame/tab etc... in the handler is just a workaround to fix the previous buggy behavior of bookmark--jump-via. IMO.

It would be good to start with a good example or recipe to see if we can find a good solution.

We need the bookmarks to work from the bookmark menu where n= o display-function overrides are supported.

I suggest we add = bookmark-record keys that indicate to bookmark-jump to inhibit/or allow mes= sing with window-configurations.=C2=A0 The bufferlo bookmarks (and Adam'= ;s if he wants) would contain these hint keys.

'(bookmark= -jump-inhibit-window-actions . t) ; or whatever we come up with

I can contrive an example, if necessary, but I believe y'all get the= point.=C2=A0 Nested bookmarks whose handlers expect their window-configura= tions not to be messed with up the chain,=C2=A0will always be broken withou= t additional controls.

The attached patch implements such a scheme t= hat works for us, and is transparent to other=C2=A0bookmark=C2=A0uses.

Perhaps we should restore bookmark--jump-via to its previous behavi= or and better document the "rules of the road" for bookmark handl= ers.=C2=A0 For simple file- and point-based bookmarks, handlers need to ens= ure that when they return, the selected window and current buffer are what&= #39;s intended.=C2=A0 For bookmark handlers that perform other actions, tho= se rules need not apply to leverage the bookmark infrastructure.

eww's handler could simply do this itself since it seems=C2=A0eww&#= 39;s=C2=A0url opening behavior warrants this:

(defun eww-book= mark-jump (bookmark)
=C2=A0 "= ;Default bookmark handler for EWW buffers."
=C2=A0 (save-window-excursion
=C2=A0 =C2=A0 (eww (bookma= rk-prop-get bookmark 'location))))

I'd also sug= gest that we recommend adding an additional property to a bookmark-handler = function that could inhibit bookmark--jump-via's call to display-func e= ntirely.=C2=A0 In our case, when called programmatically, we use #'igno= re, but when the bookmark menu is used, we'd prefer to skip the default= pop-to-buffer-same-window.

Here's an example of another handler= in the wild that handles its own save-window-excursion:


(defun Info-bookmark-jump = (bookmark)
=C2=A0 "Handler function for record returned by `Info-bo= okmark-make-record'.
BOOKMARK is a bookmark name or a bookmark recor= d.

If `Info-bookmark-use-only-node-not-file-flag' is nil, and th= e
recorded Info file is readable, then use it.=C2=A0 If not, then go to = the
recorded Info node in the manual for the current Emacs version."= ;
=C2=A0 (let* ((absfile =C2=A0 =C2=A0(bookmark-prop-get bookmark 'f= ilename))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(file =C2=A0 =C2=A0 =C2=A0 (= if (or Info-bookmark-use-only-node-not-file-flag =C2=A0(not (file-readable-= p absfile)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(file-name-nondirectory absfile)
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0absfile))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(info-node =C2=A0(bookmar= k-prop-get bookmark 'info-node))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(= buf =C2=A0 =C2=A0 =C2=A0 =C2=A0(save-window-excursion ; Vanilla FIXME: does= n't work with frames!
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(Info-find-node file info-node) (curr= ent-buffer))))
=C2=A0 =C2=A0 (bookmark-default-handler `("" (b= uffer . ,buf) . ,(bookmark-get-bookmark-record bookmark)))))

And another that handles its own windows which the change = to bookmark--jump-via will break:

https://github.com/sunrise-commander/sunrise-commander/blob/16e= 6df7e86c7a383fb4400fae94af32baf9cb24e/sunrise-checkpoint.el#L83

(defun sunrise-check= point-handler (&optional bookmark)
=C2=A0 "Handler for a checkp= oint BOOKMARK."
=C2=A0 (sunrise-ensure-running)
=C2=A0 (sunrise-= select-window 'left)
=C2=A0 (let ((dirs (cdr (assq 'sunrise-dire= ctories (cdr bookmark))))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (missing '()))=
=C2=A0 =C2=A0 (mapc (lambda (x)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 (if (file-directory-p x)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 (sunrise-save-aspect (dired x) (sunrise-bookmark-jump))=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (setq missing (cons sunr= ise-selected-window missing)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= (sunrise-change-window))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dirs)
= =C2=A0 =C2=A0 (if missing (sunrise-checkpoint-relocate bookmark (reverse mi= ssing)))))

https://github.com/sun= rise-commander/sunrise-commander/blob/16e6df7e86c7a383fb4400fae94af32baf9cb= 24e/sunrise.el#L2371

(defun sunrise-change-window()
=C2=A0 "Change to the ot= her Sunrise pane."
=C2=A0 (interactive)
=C2=A0 (sunrise-select-w= indow (sunrise-other-side))
=C2=A0 (setq sunrise-selected-window-width n= il))
--0000000000001d151906308778d3-- From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 18 02:56:24 2025 Received: (at submit) by debbugs.gnu.org; 18 Mar 2025 06:56:24 +0000 Received: from localhost ([127.0.0.1]:35670 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tuQs8-00005z-Lo for submit@debbugs.gnu.org; Tue, 18 Mar 2025 02:56:24 -0400 Received: from lists.gnu.org ([2001:470:142::17]:35072) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tuQru-0008UI-M4 for submit@debbugs.gnu.org; Tue, 18 Mar 2025 02:56:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tuQrn-0006xO-Ah for bug-gnu-emacs@gnu.org; Tue, 18 Mar 2025 02:55:59 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tuQrk-0001he-RS for bug-gnu-emacs@gnu.org; Tue, 18 Mar 2025 02:55:59 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id EACE1240027 for ; Tue, 18 Mar 2025 07:55:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1742280952; bh=+QtTPWbHhGIN46vrRKLHaC0qtcNs6EFgLydCRSVRcsM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=Jx76zIpuHe5oNPiCIZxMjWlJ3KszzYrHiFfQEfPa6wjqjDJ3jkK/d9KsrIBOvd0sH S0kVprEoZdBBaTrnzMHqU6C9m8/82iijrZwNMc+6tzT9Ye7qqm0/fn/erQw41dgnrC kqPq6PsekVhfoZU1Ew0p4Kss2oRhezZpos/URR/zk4KBOW7e46DPDws7XDaL6QpVL7 zJYfW0thZ1U5QPtqkDure/9RXFnQGpBdwad+j1/EKynzFPDhzBPw8DmE/yPf1fNDx5 3wumsQuy61xwjdVZt6M20lSzwQIeYeNTzvYdiDtnoQ2wdg9S/ReWkTzlTRthkPnwpr TasBn7AD2mCig== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4ZH2fv1wGlz9rxD; Tue, 18 Mar 2025 07:55:51 +0100 (CET) From: Thierry Volpiatto To: Ship Mints Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) In-Reply-To: (Ship Mints's message of "Mon, 17 Mar 2025 06:35:10 -0400") References: <874izwn306.fsf@posteo.net> <87y0x8kyaq.fsf@posteo.net> <877c4r6cok.fsf@posteo.net> <871puy6e5x.fsf@posteo.net> Date: Tue, 18 Mar 2025 07:03:17 +0000 Message-ID: <87v7s6om6i.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=185.67.36.65; envelope-from=thievol@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Thierry Volpiatto , Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry for late reply, was busy. Ship Mints writes: > On Sun, Mar 16, 2025 at 5:10=E2=80=AFPM Ship Mints = wrote: > > On Sat, Mar 15, 2025 at 10:18=E2=80=AFAM Ship Mints wrote: >=20=20=20=20 > On Sat, Mar 15, 2025 at 1:37=E2=80=AFAM Thierry Volpiatto wrote: >=20=20=20=20=20=20=20=20 > Ship Mints writes: >=20=20=20=20=20=20=20=20=20=20=20=20 > > I have workarounds that work only for the most simplistic c= ases.=C2=A0 Many > > of our=C2=A0bookmarks themselves contain embedded bookmarks= and bookmark > > references (which are individually addressable so can be us= ed > > separately) with window-states we need to restore in tab-ba= r tabs that > > they represent. >=20=20=20=20=20=20=20=20=20=20=20=20 > I don't really understand what your packages are doing or are= intended > doing, but FWICS in bufferlo: You are using in some places > (bookmark-jump name #'ignore); why don't you do all this work= (restore > window-states in tab) in DISPLAY-FUNCTION instead of using `i= gnore`? > Your handler would be much simpler by moving the window-state= -put and > alike calls in DISPLAY-FUNCTION: >=20=20=20=20=20=20=20=20=20=20=20=20 > (bookmark-jump name #'your_function_restoring_window_or_frame= _state)=C2=A0 >=20=20=20=20=20=20=20=20=20=20=20=20 > Using (bookmark-jump name #'ignore) with all the code that ju= mp to > frame/tab etc... in the handler is just a workaround to fix t= he previous > buggy behavior of bookmark--jump-via. IMO. >=20=20=20=20=20=20=20=20=20=20=20=20 > It would be good to start with a good example or recipe to se= e if we can > find a good solution. > > We need the bookmarks to work from the bookmark menu where no dis= play-function overrides are supported. >=20=20=20=20=20=20=20=20 > I suggest we add bookmark-record keys that indicate to bookmark-j= ump to inhibit/or allow messing with window-configurations.=C2=A0 The buffe= rlo bookmarks (and Adam's if he wants) would > contain these hint keys. >=20=20=20=20=20=20=20=20 > '(bookmark-jump-inhibit-window-actions . t) ; or whatever we come= up with >=20=20=20=20=20=20=20=20 > I can contrive an example, if necessary, but I believe y'all get = the point.=C2=A0 Nested bookmarks whose handlers expect their window-config= urations not to be messed with up the > chain,=C2=A0will always be broken without additional controls. > > The attached patch implements such a scheme that works for us, and is= transparent to other=C2=A0bookmark=C2=A0uses. > > Perhaps we should restore bookmark--jump-via to its previous behavior > and better document the "rules of the road" for bookmark handlers.=C2=A0 > For simple file- and point-based bookmarks, handlers need to ensure > that when they return, the selected window and current buffer are > what's intended.=C2=A0 For bookmark handlers that perform other actions, > those rules need not apply to leverage the bookmark infrastructure. What we could do is propose a more flexible solution so that you could use whatever you want for bookmark--jump-via; With what you have proposed so far, you still have the problem of DISPLAY-FUNCTION which will always run (I see there is comments about this problem in your mentionned packages), with the patch below you could define a display-function entry in your bookmark-record e.g. (display-function . ignore) and then add a special method for bookmark--jump-via: (cl-defmethod bookmark--jump-via (bookmark-name-or-record (_ (eql 'ignore))) (do_watever_you_want_here)) ; e.g. run only the handler fn. NOTE: I used 'ignore as example but you could use whatever you want. Here the patch: diff --git a/lisp/bookmark.el b/lisp/bookmark.el index 99bb26e83cc..e594387f364 100644 =2D-- a/lisp/bookmark.el +++ b/lisp/bookmark.el @@ -1259,7 +1259,7 @@ it to the name of the bookmark currently being set, a= dvancing "Hook run after `bookmark-jump' jumps to a bookmark. Useful for example to unhide text in `outline-mode'.") =20 =2D(defun bookmark--jump-via (bookmark-name-or-record display-function) +(cl-defgeneric bookmark--jump-via (bookmark-name-or-record display-functio= n) "Handle BOOKMARK-NAME-OR-RECORD, then call DISPLAY-FUNCTION. DISPLAY-FUNCTION is called with the new buffer as argument. =20 @@ -1319,8 +1319,12 @@ DISPLAY-FUNC would be `switch-to-buffer-other-window= '." ;; Don't use `switch-to-buffer' because it would let the ;; window-point override the bookmark's point when ;; `switch-to-buffer-preserve-window-point' is non-nil. =2D (bookmark--jump-via bookmark (or display-func 'pop-to-buffer-same-wind= ow))) + (bookmark-jump-1 bookmark display-func)) =20 +(defun bookmark-jump-1 (bookmark display-func) + (let ((dfn (or (bookmark-prop-get bookmark 'display-function) + display-func 'pop-to-buffer-same-window))) + (bookmark--jump-via bookmark dfn))) =20 ;;;###autoload (defun bookmark-jump-other-window (bookmark) @@ -2303,7 +2307,7 @@ the related behaviors of `bookmark-save' and `bookmar= k-bmenu-save'." (pop-up-windows t)) (delete-other-windows) (switch-to-buffer (other-buffer) nil t) =2D (bookmark--jump-via bmrk 'pop-to-buffer) + (bookmark-jump-1 bmrk 'pop-to-buffer) (bury-buffer menu))) =20 =20 @@ -2317,7 +2321,7 @@ the related behaviors of `bookmark-save' and `bookmar= k-bmenu-save'." "Select this line's bookmark in other window, leaving bookmark menu visi= ble." (interactive nil bookmark-bmenu-mode) (let ((bookmark (bookmark-bmenu-bookmark))) =2D (bookmark--jump-via bookmark 'switch-to-buffer-other-window))) + (bookmark-jump-1 bookmark 'switch-to-buffer-other-window))) =20 =20 (defun bookmark-bmenu-other-frame () @@ -2333,7 +2337,7 @@ The current window remains selected." (interactive nil bookmark-bmenu-mode) (let ((bookmark (bookmark-bmenu-bookmark)) (fun (lambda (b) (display-buffer b t)))) =2D (bookmark--jump-via bookmark fun))) + (bookmark-jump-1 bookmark fun))) =20 (defun bookmark-bmenu-other-window-with-mouse (event) "Jump to bookmark at mouse EVENT position in other window. Also I guess trying to call bookmark-jump-other-window and friends is failing with your special bookmarks, with this it would run just as bookmark-jump without (possible) errors. WDYT? =2D-=20 Thierry --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHHBAEBCgAxFiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmfZGrYTHHRoaWV2b2xA cG9zdGVvLm5ldAAKCRAOxW0UHRbvk9C9DACd7Zeuy4BA7FjeyVRxTIkPnLyiYgUt UPnRZ2u55cTfYpXIr9lHimbr5RZAGd2C7uqLpfebQBzcYZiC1nHw/IB5mn7IWTro K4w9HGW8LbpGMHcmpCiUjJIsfiXarX8WxFv640Px9nfqnon5oKJypcCDMnar+HpS UCiEM4NpwzWWoEaon59OLqwfLT9vvNto439NVFwMDjZnNwr+I3MAmyew+4AJ0rPQ Vlj5gPRro187xGNKlZc3+UHqG2edib6Af92L5X4fSr7SA0kzqayvQDEgRgwGUtYk CmeP634Mk26giytjwYXcKFlci8KgMHHXN2HeZUXF2rZHuw4S20BRSgKYB61HGTjP uqAKBSBYvfJBZckqx26F42cyo43ZStPlcRYbYwi0g4z1tE6i606ym/7YsHKwKvC5 IVYWk/6t9Uqr7siM1XHLsr1u9r6mnf0xr6E3Hvxi2GTFiPh9yYs4ssxk950od3cp +hWNJiIw1Hs/22R+Hkraj+n4bANbBrqrE7k= =GThd -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 18 11:03:12 2025 Received: (at submit) by debbugs.gnu.org; 18 Mar 2025 15:03:12 +0000 Received: from localhost ([127.0.0.1]:42120 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tuYTF-0000wX-OF for submit@debbugs.gnu.org; Tue, 18 Mar 2025 11:03:12 -0400 Received: from lists.gnu.org ([2001:470:142::17]:57010) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tuYTB-0000uF-RY for submit@debbugs.gnu.org; Tue, 18 Mar 2025 11:03:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tuYSz-0005uh-ET for bug-gnu-emacs@gnu.org; Tue, 18 Mar 2025 11:02:53 -0400 Received: from mail-qt1-x835.google.com ([2607:f8b0:4864:20::835]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tuYSw-0002zO-JG; Tue, 18 Mar 2025 11:02:53 -0400 Received: by mail-qt1-x835.google.com with SMTP id d75a77b69052e-47677b77725so55984101cf.3; Tue, 18 Mar 2025 08:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742310168; x=1742914968; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KH/sOHeRDCY0f9hKyHe3BaOur1nYjCvTu/133vA3XKo=; b=WoQtVLl79Ux+VUU4YPz6k5jcr0S9+KKtO9QjqOWPGBXRUzhq0LxpRAfOyuZrrqY7dJ sW8fYdQf4ODJwvKLzJ3ivBLvOCWFzKzIzALNxvCJrTc1mc8P8aghznus515MOX1DVkAN Pkq2PsGb+JnXj6jalxzD/74vm0+RAGnUWY8ZNYHde2O1574C0ypjR0pl22knmiQtYayD yZpVQW0RguT21w8blKPU4E+1tZFSvFsNF+6DiTCmAqi0ZEWpXLsnTTVas05V878aoklh C1SFfTdgyuY7I8tlO0/Gu4lcTcCJix90tUZzhwJdwHVWA5XKHmJjqRzO7Sqf761YJmCM Hq7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742310168; x=1742914968; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KH/sOHeRDCY0f9hKyHe3BaOur1nYjCvTu/133vA3XKo=; b=MlJlhbzsOSvFUi4X82jMlWtrBrebivIelB5Q+iezysf+tWt1S6uIsv9eTK5cy7HkOj kmqh+KoF8J2Td0Q9DTnJoL+ZmlRTIbXJNbpC4b/hW7E0ofLyXCVDy6qYmnko6FwDYCbg b/uqPVWtnNV64AAwtHhGbFv55ZjM2QGdvUmW++HgGU+QVt4va/Skx/0tpXwIeJ3OdwKN PIi/GwDCzQPm2RvkMAtUaw4Bnr3/s1/Ikx63FyZvbf8nQF0k4JiFD0VW42NRBqqij/v7 2IjfOKBEpQa8LkBNllsLnjS2gszDqpatjuo8govoVSafPHsNwEVQpuP+pAupUdiDXjry kUFQ== X-Forwarded-Encrypted: i=1; AJvYcCUSNPR2ftbXaz9B2fW9eJYaMYG1QipwjIlCJwxyGQuCKNPXWnMEKMbvbJvN+Mr6vPCRTWlToPOzKPAZVcvf@gnu.org X-Gm-Message-State: AOJu0YyB9ogtHXzZAX73Fjy3NRzEmPh5oM+ppY7ey19+3cmekVUURSAO 6me0/ARmBFF5azMNdWokeZDDP2l2dAH0AC+3ALddA41dNiKXhJoetup7wwvIA6gy4bvZCrwy2AZ kdxkSDvpgGDWQsYfW303zVT5L5g4= X-Gm-Gg: ASbGnctMq7Vj/ouPIPob5Fv+ZtjbYxjBt9/nkmofAhPhHnc3odyaxDodLgtf9wQGUnG BaBQHSeBVjylNZJoNCwAMGctEhk9EW5L5n46EsvY4M3I4L3+3UqwEDwJkG78W9oKtgdG59JkIBg H8t8hdkyxeMaLnhUqLEKuGP+B4GQ== X-Google-Smtp-Source: AGHT+IH649PhBboYcjkSXL5WTi1YCwVwP1HjAoNKLPLsbGNjS45cO3ukdcCnhuG2y+07j9O/6ZZSFhi+DYq3YptMIbE= X-Received: by 2002:a05:622a:155:b0:476:6a3d:de39 with SMTP id d75a77b69052e-476c81d3198mr209416261cf.36.1742310167493; Tue, 18 Mar 2025 08:02:47 -0700 (PDT) MIME-Version: 1.0 References: <874izwn306.fsf@posteo.net> <87y0x8kyaq.fsf@posteo.net> <877c4r6cok.fsf@posteo.net> <871puy6e5x.fsf@posteo.net> <87v7s6om6i.fsf@posteo.net> In-Reply-To: <87v7s6om6i.fsf@posteo.net> From: Ship Mints Date: Tue, 18 Mar 2025 11:02:35 -0400 X-Gm-Features: AQ5f1Jp6tHBMLIV0Xb-QwsO-u83fDA80BabtdbWqH6TPGVThKHleodpm_0C6n2E Message-ID: Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) To: Thierry Volpiatto Content-Type: multipart/alternative; boundary="0000000000009f41d906309f3261" Received-SPF: pass client-ip=2607:f8b0:4864:20::835; envelope-from=shipmints@gmail.com; helo=mail-qt1-x835.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --0000000000009f41d906309f3261 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 18, 2025 at 2:55=E2=80=AFAM Thierry Volpiatto wrote: > > Sorry for late reply, was busy. > > Ship Mints writes: > > > On Sun, Mar 16, 2025 at 5:10=E2=80=AFPM Ship Mints wrote: > > > > On Sat, Mar 15, 2025 at 10:18=E2=80=AFAM Ship Mints > wrote: > > > > On Sat, Mar 15, 2025 at 1:37=E2=80=AFAM Thierry Volpiatto < > thievol@posteo.net> wrote: > > > > Ship Mints writes: > > > > > I have workarounds that work only for the most simplistic > cases. Many > > > of our bookmarks themselves contain embedded bookmarks an= d > bookmark > > > references (which are individually addressable so can be > used > > > separately) with window-states we need to restore in > tab-bar tabs that > > > they represent. > > > > I don't really understand what your packages are doing or > are intended > > doing, but FWICS in bufferlo: You are using in some places > > (bookmark-jump name #'ignore); why don't you do all this > work (restore > > window-states in tab) in DISPLAY-FUNCTION instead of using > `ignore`? > > Your handler would be much simpler by moving the > window-state-put and > > alike calls in DISPLAY-FUNCTION: > > > > (bookmark-jump name > #'your_function_restoring_window_or_frame_state) > > > > Using (bookmark-jump name #'ignore) with all the code that > jump to > > frame/tab etc... in the handler is just a workaround to fix > the previous > > buggy behavior of bookmark--jump-via. IMO. > > > > It would be good to start with a good example or recipe to > see if we can > > find a good solution. > > > > We need the bookmarks to work from the bookmark menu where no > display-function overrides are supported. > > > > I suggest we add bookmark-record keys that indicate to > bookmark-jump to inhibit/or allow messing with window-configurations. Th= e > bufferlo bookmarks (and Adam's if he wants) would > > contain these hint keys. > > > > '(bookmark-jump-inhibit-window-actions . t) ; or whatever we > come up with > > > > I can contrive an example, if necessary, but I believe y'all ge= t > the point. Nested bookmarks whose handlers expect their > window-configurations not to be messed with up the > > chain, will always be broken without additional controls. > > > > The attached patch implements such a scheme that works for us, and > is transparent to other bookmark uses. > > > > Perhaps we should restore bookmark--jump-via to its previous behavior > > and better document the "rules of the road" for bookmark handlers. > > For simple file- and point-based bookmarks, handlers need to ensure > > that when they return, the selected window and current buffer are > > what's intended. For bookmark handlers that perform other actions, > > those rules need not apply to leverage the bookmark infrastructure. > > What we could do is propose a more flexible solution so that you could > use whatever you want for bookmark--jump-via; With what you have proposed > so > far, you still have the problem of DISPLAY-FUNCTION which will always > run (I see there is comments about this problem in your mentionned > packages), with the patch below you could define a display-function > entry in your bookmark-record e.g. (display-function . ignore) and then > add a special method for bookmark--jump-via: > > (cl-defmethod bookmark--jump-via (bookmark-name-or-record (_ (eql > 'ignore))) > (do_watever_you_want_here)) ; e.g. run only the handler fn. > > NOTE: I used 'ignore as example but you could use whatever you want. > > Here the patch: > > diff --git a/lisp/bookmark.el b/lisp/bookmark.el > index 99bb26e83cc..e594387f364 100644 > --- a/lisp/bookmark.el > +++ b/lisp/bookmark.el > @@ -1259,7 +1259,7 @@ it to the name of the bookmark currently being set, > advancing > "Hook run after `bookmark-jump' jumps to a bookmark. > Useful for example to unhide text in `outline-mode'.") > > -(defun bookmark--jump-via (bookmark-name-or-record display-function) > +(cl-defgeneric bookmark--jump-via (bookmark-name-or-record > display-function) > "Handle BOOKMARK-NAME-OR-RECORD, then call DISPLAY-FUNCTION. > DISPLAY-FUNCTION is called with the new buffer as argument. > > @@ -1319,8 +1319,12 @@ DISPLAY-FUNC would be > `switch-to-buffer-other-window'." > ;; Don't use `switch-to-buffer' because it would let the > ;; window-point override the bookmark's point when > ;; `switch-to-buffer-preserve-window-point' is non-nil. > - (bookmark--jump-via bookmark (or display-func > 'pop-to-buffer-same-window))) > + (bookmark-jump-1 bookmark display-func)) > > +(defun bookmark-jump-1 (bookmark display-func) > + (let ((dfn (or (bookmark-prop-get bookmark 'display-function) > + display-func 'pop-to-buffer-same-window))) > + (bookmark--jump-via bookmark dfn))) > > ;;;###autoload > (defun bookmark-jump-other-window (bookmark) > @@ -2303,7 +2307,7 @@ the related behaviors of `bookmark-save' and > `bookmark-bmenu-save'." > (pop-up-windows t)) > (delete-other-windows) > (switch-to-buffer (other-buffer) nil t) > - (bookmark--jump-via bmrk 'pop-to-buffer) > + (bookmark-jump-1 bmrk 'pop-to-buffer) > (bury-buffer menu))) > > > @@ -2317,7 +2321,7 @@ the related behaviors of `bookmark-save' and > `bookmark-bmenu-save'." > "Select this line's bookmark in other window, leaving bookmark menu > visible." > (interactive nil bookmark-bmenu-mode) > (let ((bookmark (bookmark-bmenu-bookmark))) > - (bookmark--jump-via bookmark 'switch-to-buffer-other-window))) > + (bookmark-jump-1 bookmark 'switch-to-buffer-other-window))) > > > (defun bookmark-bmenu-other-frame () > @@ -2333,7 +2337,7 @@ The current window remains selected." > (interactive nil bookmark-bmenu-mode) > (let ((bookmark (bookmark-bmenu-bookmark)) > (fun (lambda (b) (display-buffer b t)))) > - (bookmark--jump-via bookmark fun))) > + (bookmark-jump-1 bookmark fun))) > > (defun bookmark-bmenu-other-window-with-mouse (event) > "Jump to bookmark at mouse EVENT position in other window. > > Also I guess trying to call bookmark-jump-other-window and friends is > failing with your special bookmarks, with this it would run just as > bookmark-jump without (possible) errors. > > WDYT? > Thanks for the continuing discussion. The concept will work but it feels a bit over-engineered. Perhaps that's a matter of taste, and certainly not a dig at the idea. The approach of ignoring save-window-excursion and display-func via bookmark-record entries or using properties on the handler seem less intrusive or a mix, if we feel that's appropriate. Why not just fix the eww bookmark handler to do its own save-window-excursion, again, rather than make a default bookmark jump behavior policy change? We'd still need a method to inhibit display-func in the interactive bookmark menu case. -Stephane --0000000000009f41d906309f3261 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Tue, Mar 18, 2025 at 2:55=E2=80=AFAM Thierry Volpiatto <thievol@posteo.net> wrote:

Sorry for late reply, was busy.

Ship Mints <shi= pmints@gmail.com> writes:

> On Sun, Mar 16, 2025 at 5:10=E2=80=AFPM Ship Mints <shipmints@gmail.com> wrote= :
>
>=C2=A0 =C2=A0 =C2=A0On Sat, Mar 15, 2025 at 10:18=E2=80=AFAM Ship Mints= <shipmints@gma= il.com> wrote:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, Mar 15, 2025 at 1:37=E2=80=AF= AM Thierry Volpiatto <thievol@posteo.net> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ship Mints <shipmints@gmail.com&g= t; writes:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I have workarounds= that work only for the most simplistic cases.=C2=A0 Many
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> of our=C2=A0bookma= rks themselves contain embedded bookmarks and bookmark
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> references (which = are individually addressable so can be used
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> separately) with w= indow-states we need to restore in tab-bar tabs that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> they represent. >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I don't really unde= rstand what your packages are doing or are intended
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0doing, but FWICS in buf= ferlo: You are using in some places
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(bookmark-jump name #&#= 39;ignore); why don't you do all this work (restore
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0window-states in tab) i= n DISPLAY-FUNCTION instead of using `ignore`?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Your handler would be m= uch simpler by moving the window-state-put and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alike calls in DISPLAY-= FUNCTION:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(bookmark-jump name #&#= 39;your_function_restoring_window_or_frame_state)=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Using (bookmark-jump na= me #'ignore) with all the code that jump to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0frame/tab etc... in the= handler is just a workaround to fix the previous
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0buggy behavior of bookm= ark--jump-via. IMO.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It would be good to sta= rt with a good example or recipe to see if we can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0find a good solution. >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We need the bookmarks to work from th= e bookmark menu where no display-function overrides are supported.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I suggest we add bookmark-record keys= that indicate to bookmark-jump to inhibit/or allow messing with window-con= figurations.=C2=A0 The bufferlo bookmarks (and Adam's if he wants) woul= d
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0contain these hint keys.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'(bookmark-jump-inhibit-window-ac= tions . t) ; or whatever we come up with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I can contrive an example, if necessa= ry, but I believe y'all get the point.=C2=A0 Nested bookmarks whose han= dlers expect their window-configurations not to be messed with up the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0chain,=C2=A0will always be broken wit= hout additional controls.
>
>=C2=A0 =C2=A0 =C2=A0The attached patch implements such a scheme that wo= rks for us, and is transparent to other=C2=A0bookmark=C2=A0uses.
>
> Perhaps we should restore bookmark--jump-via to its previous behavior<= br> > and better document the "rules of the road" for bookmark han= dlers.=C2=A0
> For simple file- and point-based bookmarks, handlers need to ensure > that when they return, the selected window and current buffer are
> what's intended.=C2=A0 For bookmark handlers that perform other ac= tions,
> those rules need not apply to leverage the bookmark infrastructure.
What we could do is propose a more flexible solution so that you could
use whatever you want for bookmark--jump-via; With what you have proposed s= o
far, you still have the problem of DISPLAY-FUNCTION which will always
run (I see there is comments about this problem in your mentionned
packages), with the patch below you could define a display-function
entry in your bookmark-record e.g. (display-function . ignore) and then
add a special method for bookmark--jump-via:

(cl-defmethod bookmark--jump-via (bookmark-name-or-record (_ (eql 'igno= re)))
=C2=A0 (do_watever_you_want_here)) ; e.g. run only the handler fn.

NOTE: I used 'ignore as example but you could use whatever you want.
Here the patch:

diff --git a/lisp/bookmark.el b/lisp/bookmark.el
index 99bb26e83cc..e594387f364 100644
--- a/lisp/bookmark.el
+++ b/lisp/bookmark.el
@@ -1259,7 +1259,7 @@ it to the name of the bookmark currently being set, a= dvancing
=C2=A0 =C2=A0"Hook run after `bookmark-jump' jumps to a bookmark.<= br> =C2=A0Useful for example to unhide text in `outline-mode'.")

-(defun bookmark--jump-via (bookmark-name-or-record display-function)
+(cl-defgeneric bookmark--jump-via (bookmark-name-or-record display-functio= n)
=C2=A0 =C2=A0"Handle BOOKMARK-NAME-OR-RECORD, then call DISPLAY-FUNCTI= ON.
=C2=A0DISPLAY-FUNCTION is called with the new buffer as argument.

@@ -1319,8 +1319,12 @@ DISPLAY-FUNC would be `switch-to-buffer-other-window= '."
=C2=A0 =C2=A0;; Don't use `switch-to-buffer' because it would let t= he
=C2=A0 =C2=A0;; window-point override the bookmark's point when
=C2=A0 =C2=A0;; `switch-to-buffer-preserve-window-point' is non-nil. -=C2=A0 (bookmark--jump-via bookmark (or display-func 'pop-to-buffer-sa= me-window)))
+=C2=A0 (bookmark-jump-1 bookmark display-func))

+(defun bookmark-jump-1 (bookmark display-func)
+=C2=A0 (let ((dfn (or (bookmark-prop-get bookmark 'display-function) +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0display-func= 'pop-to-buffer-same-window)))
+=C2=A0 =C2=A0 (bookmark--jump-via bookmark dfn)))

=C2=A0;;;###autoload
=C2=A0(defun bookmark-jump-other-window (bookmark)
@@ -2303,7 +2307,7 @@ the related behaviors of `bookmark-save' and `boo= kmark-bmenu-save'."
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(pop-up-windows t))
=C2=A0 =C2=A0 =C2=A0(delete-other-windows)
=C2=A0 =C2=A0 =C2=A0(switch-to-buffer (other-buffer) nil t)
-=C2=A0 =C2=A0 (bookmark--jump-via bmrk 'pop-to-buffer)
+=C2=A0 =C2=A0 (bookmark-jump-1 bmrk 'pop-to-buffer)
=C2=A0 =C2=A0 =C2=A0(bury-buffer menu)))


@@ -2317,7 +2321,7 @@ the related behaviors of `bookmark-save' and `boo= kmark-bmenu-save'."
=C2=A0 =C2=A0"Select this line's bookmark in other window, leaving= bookmark menu visible."
=C2=A0 =C2=A0(interactive nil bookmark-bmenu-mode)
=C2=A0 =C2=A0(let ((bookmark (bookmark-bmenu-bookmark)))
-=C2=A0 =C2=A0 (bookmark--jump-via bookmark 'switch-to-buffer-other-win= dow)))
+=C2=A0 =C2=A0 (bookmark-jump-1 bookmark 'switch-to-buffer-other-window= )))


=C2=A0(defun bookmark-bmenu-other-frame ()
@@ -2333,7 +2337,7 @@ The current window remains selected."
=C2=A0 =C2=A0(interactive nil bookmark-bmenu-mode)
=C2=A0 =C2=A0(let ((bookmark (bookmark-bmenu-bookmark))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (fun (lambda (b) (display-buffer b t))))
-=C2=A0 =C2=A0 (bookmark--jump-via bookmark fun)))
+=C2=A0 =C2=A0 (bookmark-jump-1 bookmark fun)))

=C2=A0(defun bookmark-bmenu-other-window-with-mouse (event)
=C2=A0 =C2=A0"Jump to bookmark at mouse EVENT position in other window= .

Also I guess trying to call bookmark-jump-other-window and friends is
failing with your special bookmarks, with this it would run just as
bookmark-jump without (possible) errors.

WDYT?

Thanks for the continuing=C2=A0discussion.

The concept will work = but it feels a bit over-engineered.=C2=A0 Perhaps that's a matter of ta= ste, and certainly not a dig at the idea.

The approach of ignoring save-window-excursion= and display-func via bookmark-record entries or using properties on the ha= ndler seem less intrusive or a mix,=C2=A0if we feel that's appropriate.=

Why not just= fix the eww bookmark handler to do its own save-window-excursion, again, r= ather than make a default bookmark jump behavior policy change?=C2=A0 We= 9;d still need a method to inhibit display-func in the interactive bookmark= menu case.

-= Stephane
--0000000000009f41d906309f3261-- From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 18 11:15:27 2025 Received: (at submit) by debbugs.gnu.org; 18 Mar 2025 15:15:28 +0000 Received: from localhost ([127.0.0.1]:42234 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tuYf9-0002ks-40 for submit@debbugs.gnu.org; Tue, 18 Mar 2025 11:15:27 -0400 Received: from lists.gnu.org ([2001:470:142::17]:40370) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tuYf5-0002jO-FF for submit@debbugs.gnu.org; Tue, 18 Mar 2025 11:15:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tuYey-0000Xn-V2 for bug-gnu-emacs@gnu.org; Tue, 18 Mar 2025 11:15:16 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tuYev-0006mW-E9 for bug-gnu-emacs@gnu.org; Tue, 18 Mar 2025 11:15:16 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 6C848240101 for ; Tue, 18 Mar 2025 16:15:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1742310911; bh=nQTgQ34lHaKnGlPp/7c+RpLc6a5Uq83Z5GpuGseaGac=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=TmOKXXc71zMRvihNQ+FZqNh//cOIKpD7wjQCasuFjn30EUcbvcKXF9SmcA/fRHVLp B1dDIH4IdMNINQZ+PzBXmGlvf+Z/4PPPiDmqGTCM84ETp5fPXjM0Wpl1fxVHtk6dh4 uKjYhi8PN8x8OlN527Wlye6feAW18Xhij8rd9Cb0mHWIhjW02x6dbtSUD3NBQw7y9C Vr13b48RVwTXdxJ7OoZ1iq0Dnzavt0ck3gb89e8JcWzTbvdOAuP1FTmTHU/bcH5NjK vOUYute3c/vPUvNm9sX4FwR+O5WGvsD0Kt7PkuqbFRzdbC7nHqeIus9WsTA9QkCurz FXgQp/2g8D17Q== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4ZHFl04S4Qz9rxD; Tue, 18 Mar 2025 16:15:08 +0100 (CET) From: Thierry Volpiatto To: Ship Mints Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) In-Reply-To: (Ship Mints's message of "Tue, 18 Mar 2025 11:02:35 -0400") References: <874izwn306.fsf@posteo.net> <87y0x8kyaq.fsf@posteo.net> <877c4r6cok.fsf@posteo.net> <871puy6e5x.fsf@posteo.net> <87v7s6om6i.fsf@posteo.net> Date: Tue, 18 Mar 2025 15:22:35 +0000 Message-ID: <87ecyul5xg.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=185.67.36.66; envelope-from=thievol@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Thierry Volpiatto , Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ship Mints writes: > 1. ( ) text/plain (*) text/html=20=20=20=20=20=20=20=20=20=20=20 > > On Tue, Mar 18, 2025 at 2:55=E2=80=AFAM Thierry Volpiatto wrote: > > Sorry for late reply, was busy. >=20=20=20=20 > Ship Mints writes: >=20=20=20=20 > > On Sun, Mar 16, 2025 at 5:10=E2=80=AFPM Ship Mints wrote: > > > >=C2=A0 =C2=A0 =C2=A0On Sat, Mar 15, 2025 at 10:18=E2=80=AFAM Ship Mi= nts wrote: > >=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, Mar 15, 2025 at 1:37=E2=80= =AFAM Thierry Volpiatto wrote: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ship Mints writes: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I have workarounds= that work only for the most simplistic cases.=C2=A0 Many > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> of our=C2=A0bookma= rks themselves contain embedded bookmarks and bookmark > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> references (which = are individually addressable so can be used > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> separately) with w= indow-states we need to restore in tab-bar tabs that > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> they represent. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I don't really under= stand what your packages are doing or are intended > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0doing, but FWICS in = bufferlo: You are using in some places > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(bookmark-jump name = #'ignore); why don't you do all this work (restore > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0window-states in tab= ) in DISPLAY-FUNCTION instead of using `ignore`? > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Your handler would b= e much simpler by moving the window-state-put and > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alike calls in DISPL= AY-FUNCTION: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(bookmark-jump name = #'your_function_restoring_window_or_frame_state)=C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Using (bookmark-jump= name #'ignore) with all the code that jump to > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0frame/tab etc... in = the handler is just a workaround to fix the previous > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0buggy behavior of bo= okmark--jump-via. IMO. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It would be good to = start with a good example or recipe to see if we can > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0find a good solution. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We need the bookmarks to work from= the bookmark menu where no display-function overrides are supported. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I suggest we add bookmark-record k= eys that indicate to bookmark-jump to inhibit/or allow messing with window-= configurations.=C2=A0 The bufferlo bookmarks (and Adam's if he wants) > would > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0contain these hint keys. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'(bookmark-jump-inhibit-window-act= ions . t) ; or whatever we come up with > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I can contrive an example, if nece= ssary, but I believe y'all get the point.=C2=A0 Nested bookmarks whose hand= lers expect their window-configurations not to be messed with up the > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0chain,=C2=A0will always be broken = without additional controls. > > > >=C2=A0 =C2=A0 =C2=A0The attached patch implements such a scheme that= works for us, and is transparent to other=C2=A0bookmark=C2=A0uses. > > > > Perhaps we should restore bookmark--jump-via to its previous behavi= or > > and better document the "rules of the road" for bookmark handlers.= =C2=A0 > > For simple file- and point-based bookmarks, handlers need to ensure > > that when they return, the selected window and current buffer are > > what's intended.=C2=A0 For bookmark handlers that perform other act= ions, > > those rules need not apply to leverage the bookmark infrastructure. >=20=20=20=20 > What we could do is propose a more flexible solution so that you could > use whatever you want for bookmark--jump-via; With what you have prop= osed so > far, you still have the problem of DISPLAY-FUNCTION which will always > run (I see there is comments about this problem in your mentionned > packages), with the patch below you could define a display-function > entry in your bookmark-record e.g. (display-function . ignore) and th= en > add a special method for bookmark--jump-via: >=20=20=20=20 > (cl-defmethod bookmark--jump-via (bookmark-name-or-record (_ (eql 'ig= nore))) > =C2=A0 (do_watever_you_want_here)) ; e.g. run only the handler fn. >=20=20=20=20 > NOTE: I used 'ignore as example but you could use whatever you want. >=20=20=20=20 > Here the patch: >=20=20=20=20 > diff --git a/lisp/bookmark.el b/lisp/bookmark.el > index 99bb26e83cc..e594387f364 100644 > --- a/lisp/bookmark.el > +++ b/lisp/bookmark.el > @@ -1259,7 +1259,7 @@ it to the name of the bookmark currently being = set, advancing > =C2=A0 =C2=A0"Hook run after `bookmark-jump' jumps to a bookmark. > =C2=A0Useful for example to unhide text in `outline-mode'.") >=20=20=20=20 > -(defun bookmark--jump-via (bookmark-name-or-record display-function) > +(cl-defgeneric bookmark--jump-via (bookmark-name-or-record display-f= unction) > =C2=A0 =C2=A0"Handle BOOKMARK-NAME-OR-RECORD, then call DISPLAY-FUNCT= ION. > =C2=A0DISPLAY-FUNCTION is called with the new buffer as argument. >=20=20=20=20 > @@ -1319,8 +1319,12 @@ DISPLAY-FUNC would be `switch-to-buffer-other-= window'." > =C2=A0 =C2=A0;; Don't use `switch-to-buffer' because it would let the > =C2=A0 =C2=A0;; window-point override the bookmark's point when > =C2=A0 =C2=A0;; `switch-to-buffer-preserve-window-point' is non-nil. > -=C2=A0 (bookmark--jump-via bookmark (or display-func 'pop-to-buffer-= same-window))) > +=C2=A0 (bookmark-jump-1 bookmark display-func)) >=20=20=20=20 > +(defun bookmark-jump-1 (bookmark display-func) > +=C2=A0 (let ((dfn (or (bookmark-prop-get bookmark 'display-function) > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0displa= y-func 'pop-to-buffer-same-window))) > +=C2=A0 =C2=A0 (bookmark--jump-via bookmark dfn))) >=20=20=20=20 > =C2=A0;;;###autoload > =C2=A0(defun bookmark-jump-other-window (bookmark) > @@ -2303,7 +2307,7 @@ the related behaviors of `bookmark-save' and `b= ookmark-bmenu-save'." > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(pop-up-windows t)) > =C2=A0 =C2=A0 =C2=A0(delete-other-windows) > =C2=A0 =C2=A0 =C2=A0(switch-to-buffer (other-buffer) nil t) > -=C2=A0 =C2=A0 (bookmark--jump-via bmrk 'pop-to-buffer) > +=C2=A0 =C2=A0 (bookmark-jump-1 bmrk 'pop-to-buffer) > =C2=A0 =C2=A0 =C2=A0(bury-buffer menu))) > > @@ -2317,7 +2321,7 @@ the related behaviors of `bookmark-save' and `b= ookmark-bmenu-save'." > =C2=A0 =C2=A0"Select this line's bookmark in other window, leaving bo= okmark menu visible." > =C2=A0 =C2=A0(interactive nil bookmark-bmenu-mode) > =C2=A0 =C2=A0(let ((bookmark (bookmark-bmenu-bookmark))) > -=C2=A0 =C2=A0 (bookmark--jump-via bookmark 'switch-to-buffer-other-w= indow))) > +=C2=A0 =C2=A0 (bookmark-jump-1 bookmark 'switch-to-buffer-other-wind= ow))) > > =C2=A0(defun bookmark-bmenu-other-frame () > @@ -2333,7 +2337,7 @@ The current window remains selected." > =C2=A0 =C2=A0(interactive nil bookmark-bmenu-mode) > =C2=A0 =C2=A0(let ((bookmark (bookmark-bmenu-bookmark)) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 (fun (lambda (b) (display-buffer b t)))) > -=C2=A0 =C2=A0 (bookmark--jump-via bookmark fun))) > +=C2=A0 =C2=A0 (bookmark-jump-1 bookmark fun))) >=20=20=20=20 > =C2=A0(defun bookmark-bmenu-other-window-with-mouse (event) > =C2=A0 =C2=A0"Jump to bookmark at mouse EVENT position in other windo= w. >=20=20=20=20 > Also I guess trying to call bookmark-jump-other-window and friends is > failing with your special bookmarks, with this it would run just as > bookmark-jump without (possible) errors. >=20=20=20=20 > WDYT? > > Thanks for the continuing=C2=A0discussion. > > The concept will work but it feels a bit over-engineered. It is not, it is quite simple. > The approach of ignoring save-window-excursion and display-func via > bookmark-record entries or using properties on the handler seem less > intrusive or a mix,=C2=A0if we feel that's appropriate. I proposed this solution to help you cleaning up your code which is full of workarounds for the current behavior (prior 31). Of course if you don't want to make an effort to update your code, what you propose is simpler (i.e. you have nothing to change on your side), but generally we (external emacs extensions developers) try to adapt ourselves to Emacs source and not the contrary. > > > Why not just fix the eww bookmark handler to do its own > save-window-excursion, again, rather than make a default bookmark jump > behavior policy change? Because the problem is not just about eww, but more generally on how bookmark handlers work. > =C2=A0 We'd still need a method to inhibit display-func in the interactive > bookmark menu case. No. =2D-=20 Thierry --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHHBAEBCgAxFiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmfZj7wTHHRoaWV2b2xA cG9zdGVvLm5ldAAKCRAOxW0UHRbvk7ZrC/4vlhtgg2KT575decY9c4+jw1dklW/a y3D+Ml+HrP0VuhrQ7bbXfQ0vW8GNKyeALz/FdBPGGnd6eSl+bpEkrjcyZjo3Igny 9B42L491QsPZPbapIrRms65RbzgC+CAVo363psAAcgt/zcbGF5SOaIwdg5vBDGiq TXmbkVXzsbQM6qyM6w4VIx9e+l1Jv36QC/gnR5+UsYEHopDLX7cp13+OJm0NwPrN 4QSl08a60HPJuyUBvgIoJ1EPPq7EmKTOFDWfeaPOiULjAagmrXYs+gwuvKPHsxtl 9gHJa2YgJFBca1ELqpQIzy5siAluPzlmI8WkUve8NmKDR60Sr6r4eBjO0pIbA4MN GB1vYkhGkZ5D4IJxOE+we0uMuqE/d6t2/7LfvUsrWnTaPdnB84XGazSuRR2sR0lM pi/1sIVEChysMJkEcjAViFX/VJNf5lLQwzTiucgNnOhNtJttUKZ9bSveDZxRyxkr vC2tPn4jh3ffYe5PsUDvrZnEP9qaejIzjMg= =Ye+d -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 18 11:28:15 2025 Received: (at submit) by debbugs.gnu.org; 18 Mar 2025 15:28:15 +0000 Received: from localhost ([127.0.0.1]:42344 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tuYrV-0004VC-06 for submit@debbugs.gnu.org; Tue, 18 Mar 2025 11:28:15 -0400 Received: from lists.gnu.org ([2001:470:142::17]:60372) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tuYrQ-0004T0-AE for submit@debbugs.gnu.org; Tue, 18 Mar 2025 11:28:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tuYrH-0003g4-68 for bug-gnu-emacs@gnu.org; Tue, 18 Mar 2025 11:27:59 -0400 Received: from mail-ua1-x92a.google.com ([2607:f8b0:4864:20::92a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tuYrE-000253-HH; Tue, 18 Mar 2025 11:27:58 -0400 Received: by mail-ua1-x92a.google.com with SMTP id a1e0cc1a2514c-86b9d1f7249so5266248241.2; Tue, 18 Mar 2025 08:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742311675; x=1742916475; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4i5NWlds5ChDYh+qB9De+s1/P/eSQcy1/IvodtnMEzA=; b=QbtSMZYR/moo5aDSsjG2Q9/gb7VP8qWdZt5/yC7sSNwSxF7AGelIl9sN/LrK+ykRgP N/GI9IK8ptXfZWpAAjNEB6de/ggE0B9x5xHMrM3Sz2W232RIIsAwnkxNOnITZeS7s3UK FTwoUrdsWJVEd6wbZmAK46iBRxs2Z2lcViEX5tnPyYDX1xFvAJM3VYGn3wC6qakxNNMz 3n/3qwRp5/QCfc0ahUa/9XIUzeMW6kz5BBw7CjKODNvwdCF388y0mYM1GE6iwQvMhuBA ashJNqqyay9iDNFjuG7539akHf9Yo4kJvN47eBw/np+YETU2X7KWQpdEayKVmHgpZaFe +TYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742311675; x=1742916475; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4i5NWlds5ChDYh+qB9De+s1/P/eSQcy1/IvodtnMEzA=; b=dfzmtaAdALbxikPNt6oLVppDXkh2qqemgIhR530YX0UY4UucwsQVy55X/xI+dhUfJE M2xBxSaeTKte/m5CkLLac4FPqp9/rpyPA4oEeDCETYdP8R4aAKp5fD483vbN2RYnzpki OoLWgV4dnZyrMmcNESfXju0whDBYXfzA9YiMIDt/eU+epBkecwUtlggiW6v1iNTO+1XJ mEwGnJkxftofppl2+i/Sa+GgOUJzq9V4stUpSDjxoCLJtRlDMwA/fPqt1oZubfL5whhD o+aNGsdN8lpCFptcTc+qFrbT8lw/LsNyec+VHZUJRCnzcTrIWG7o9Ne3cBo37ycHG43R zMgA== X-Forwarded-Encrypted: i=1; AJvYcCU5NuRDF6/U7ZjwXtjjMQijdVonnnvZ9aML//ngp0EdL60wg71OdSJ4P9WlHGpp7eVclTmn0UQjps74MbPL@gnu.org X-Gm-Message-State: AOJu0Yz4d5ru34RWGj+jQm0CJTE/67WcZ7MKqeujiOhl3AP/fDLjnXVU EL+fJQLR894yped7n9KqK4sVYPDTa0pcFTQ/7qtsFUhKcvk1o/Wsa0DQN4kLYLCT6obngeaICG5 beHzC0+4ULTZugbTBGK1ZMCEDzOg= X-Gm-Gg: ASbGncvazXsE7WDBf4HiZFWbsQwvl4N3egjv4vHv6iVckpW6TboIUXSJCL+4rl/FylF UimG98+D12NzS+oYF67CbSPw7aw81HeC4O+S2+LSRXc7lJntnx7GNwfbOWJhtRoXHQNfhNrv58Q Z9VrhRgiT6fWthjwZ+lRjmn/FVCw== X-Google-Smtp-Source: AGHT+IESKXhtZVHGX0oKmyuWKjt4ZXQLi1Ml4ffLXBpA5ZrMzyModgKjwD5YqcR2kkj7t7XS3jEqB2lSalHRbY5HzU0= X-Received: by 2002:a05:6102:2907:b0:4bb:e80b:473d with SMTP id ada2fe7eead31-4c4d9061292mr3023149137.6.1742311674685; Tue, 18 Mar 2025 08:27:54 -0700 (PDT) MIME-Version: 1.0 References: <874izwn306.fsf@posteo.net> <87y0x8kyaq.fsf@posteo.net> <877c4r6cok.fsf@posteo.net> <871puy6e5x.fsf@posteo.net> <87v7s6om6i.fsf@posteo.net> <87ecyul5xg.fsf@posteo.net> In-Reply-To: <87ecyul5xg.fsf@posteo.net> From: Ship Mints Date: Tue, 18 Mar 2025 11:27:42 -0400 X-Gm-Features: AQ5f1Jq9ozWUudarCndN7aw5I1I3RoknGMA2mQVmYJstBE9NTSyBf4LL3Of0X1g Message-ID: Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) To: Thierry Volpiatto Content-Type: multipart/alternative; boundary="0000000000007532f006309f8ce2" Received-SPF: pass client-ip=2607:f8b0:4864:20::92a; envelope-from=shipmints@gmail.com; helo=mail-ua1-x92a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --0000000000007532f006309f8ce2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 18, 2025 at 11:15=E2=80=AFAM Thierry Volpiatto wrote: > Ship Mints writes: > > > 1. ( ) text/plain (*) text/html > > > > On Tue, Mar 18, 2025 at 2:55=E2=80=AFAM Thierry Volpiatto > wrote: > > > > Sorry for late reply, was busy. > > > > Ship Mints writes: > > > > > On Sun, Mar 16, 2025 at 5:10=E2=80=AFPM Ship Mints > wrote: > > > > > > On Sat, Mar 15, 2025 at 10:18=E2=80=AFAM Ship Mints < > shipmints@gmail.com> wrote: > > > > > > On Sat, Mar 15, 2025 at 1:37=E2=80=AFAM Thierry Volpiatto= < > thievol@posteo.net> wrote: > > > > > > Ship Mints writes: > > > > > > > I have workarounds that work only for the most > simplistic cases. Many > > > > of our bookmarks themselves contain embedded > bookmarks and bookmark > > > > references (which are individually addressable so > can be used > > > > separately) with window-states we need to restore i= n > tab-bar tabs that > > > > they represent. > > > > > > I don't really understand what your packages are doin= g > or are intended > > > doing, but FWICS in bufferlo: You are using in some > places > > > (bookmark-jump name #'ignore); why don't you do all > this work (restore > > > window-states in tab) in DISPLAY-FUNCTION instead of > using `ignore`? > > > Your handler would be much simpler by moving the > window-state-put and > > > alike calls in DISPLAY-FUNCTION: > > > > > > (bookmark-jump name > #'your_function_restoring_window_or_frame_state) > > > > > > Using (bookmark-jump name #'ignore) with all the code > that jump to > > > frame/tab etc... in the handler is just a workaround > to fix the previous > > > buggy behavior of bookmark--jump-via. IMO. > > > > > > It would be good to start with a good example or > recipe to see if we can > > > find a good solution. > > > > > > We need the bookmarks to work from the bookmark menu wher= e > no display-function overrides are supported. > > > > > > I suggest we add bookmark-record keys that indicate to > bookmark-jump to inhibit/or allow messing with window-configurations. Th= e > bufferlo bookmarks (and Adam's if he wants) > > would > > > contain these hint keys. > > > > > > '(bookmark-jump-inhibit-window-actions . t) ; or whatever > we come up with > > > > > > I can contrive an example, if necessary, but I believe > y'all get the point. Nested bookmarks whose handlers expect their > window-configurations not to be messed with up the > > > chain, will always be broken without additional controls. > > > > > > The attached patch implements such a scheme that works for us= , > and is transparent to other bookmark uses. > > > > > > Perhaps we should restore bookmark--jump-via to its previous > behavior > > > and better document the "rules of the road" for bookmark handlers= . > > > For simple file- and point-based bookmarks, handlers need to ensu= re > > > that when they return, the selected window and current buffer are > > > what's intended. For bookmark handlers that perform other action= s, > > > those rules need not apply to leverage the bookmark infrastructur= e. > > > > What we could do is propose a more flexible solution so that you > could > > use whatever you want for bookmark--jump-via; With what you have > proposed so > > far, you still have the problem of DISPLAY-FUNCTION which will alwa= ys > > run (I see there is comments about this problem in your mentionned > > packages), with the patch below you could define a display-function > > entry in your bookmark-record e.g. (display-function . ignore) and > then > > add a special method for bookmark--jump-via: > > > > (cl-defmethod bookmark--jump-via (bookmark-name-or-record (_ (eql > 'ignore))) > > (do_watever_you_want_here)) ; e.g. run only the handler fn. > > > > NOTE: I used 'ignore as example but you could use whatever you want= . > > > > Here the patch: > > > > diff --git a/lisp/bookmark.el b/lisp/bookmark.el > > index 99bb26e83cc..e594387f364 100644 > > --- a/lisp/bookmark.el > > +++ b/lisp/bookmark.el > > @@ -1259,7 +1259,7 @@ it to the name of the bookmark currently bein= g > set, advancing > > "Hook run after `bookmark-jump' jumps to a bookmark. > > Useful for example to unhide text in `outline-mode'.") > > > > -(defun bookmark--jump-via (bookmark-name-or-record display-functio= n) > > +(cl-defgeneric bookmark--jump-via (bookmark-name-or-record > display-function) > > "Handle BOOKMARK-NAME-OR-RECORD, then call DISPLAY-FUNCTION. > > DISPLAY-FUNCTION is called with the new buffer as argument. > > > > @@ -1319,8 +1319,12 @@ DISPLAY-FUNC would be > `switch-to-buffer-other-window'." > > ;; Don't use `switch-to-buffer' because it would let the > > ;; window-point override the bookmark's point when > > ;; `switch-to-buffer-preserve-window-point' is non-nil. > > - (bookmark--jump-via bookmark (or display-func > 'pop-to-buffer-same-window))) > > + (bookmark-jump-1 bookmark display-func)) > > > > +(defun bookmark-jump-1 (bookmark display-func) > > + (let ((dfn (or (bookmark-prop-get bookmark 'display-function) > > + display-func 'pop-to-buffer-same-window))) > > + (bookmark--jump-via bookmark dfn))) > > > > ;;;###autoload > > (defun bookmark-jump-other-window (bookmark) > > @@ -2303,7 +2307,7 @@ the related behaviors of `bookmark-save' and > `bookmark-bmenu-save'." > > (pop-up-windows t)) > > (delete-other-windows) > > (switch-to-buffer (other-buffer) nil t) > > - (bookmark--jump-via bmrk 'pop-to-buffer) > > + (bookmark-jump-1 bmrk 'pop-to-buffer) > > (bury-buffer menu))) > > > > @@ -2317,7 +2321,7 @@ the related behaviors of `bookmark-save' and > `bookmark-bmenu-save'." > > "Select this line's bookmark in other window, leaving bookmark > menu visible." > > (interactive nil bookmark-bmenu-mode) > > (let ((bookmark (bookmark-bmenu-bookmark))) > > - (bookmark--jump-via bookmark 'switch-to-buffer-other-window))) > > + (bookmark-jump-1 bookmark 'switch-to-buffer-other-window))) > > > > (defun bookmark-bmenu-other-frame () > > @@ -2333,7 +2337,7 @@ The current window remains selected." > > (interactive nil bookmark-bmenu-mode) > > (let ((bookmark (bookmark-bmenu-bookmark)) > > (fun (lambda (b) (display-buffer b t)))) > > - (bookmark--jump-via bookmark fun))) > > + (bookmark-jump-1 bookmark fun))) > > > > (defun bookmark-bmenu-other-window-with-mouse (event) > > "Jump to bookmark at mouse EVENT position in other window. > > > > Also I guess trying to call bookmark-jump-other-window and friends = is > > failing with your special bookmarks, with this it would run just as > > bookmark-jump without (possible) errors. > > > > WDYT? > > > > Thanks for the continuing discussion. > > > > The concept will work but it feels a bit over-engineered. > > It is not, it is quite simple. > > > The approach of ignoring save-window-excursion and display-func via > > bookmark-record entries or using properties on the handler seem less > > intrusive or a mix, if we feel that's appropriate. > > I proposed this solution to help you cleaning up your code which is full > of workarounds for the current behavior (prior 31). Of course if you > don't want to make an effort to update your code, what you propose is > simpler (i.e. you have nothing to change on your side), but generally we > (external emacs extensions developers) try to adapt ourselves to Emacs > source and not the contrary. > Thanks for the input. The idea that I "don't want to make an effort" is insulting. Perhaps a little less coffee. > > Why not just fix the eww bookmark handler to do its own > > save-window-excursion, again, rather than make a default bookmark jump > > behavior policy change? > > Because the problem is not just about eww, but more generally on how > bookmark handlers work. > Curious to know which other ones are broken? I read eww and w3m. > We'd still need a method to inhibit display-func in the interactive > > bookmark menu case. > > No. > If we do not go the cl-defgeneric route, we will. What do the Emacs maintainers think about this as a matter of taste, easy adoption for other bookmark users, and idiomatic usage? I'm open. --0000000000007532f006309f8ce2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Tue, Mar 18, 2025 at 11:15=E2=80=AFAM Thierry Volpiatto <thievol@posteo.net> wrote:
Ship Mints <shipmints@gmail.com> writes:

> 1.=C2=A0 ( ) text/plain=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (*) text/htm= l=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>
> On Tue, Mar 18, 2025 at 2:55=E2=80=AFAM Thierry Volpiatto <thievol@posteo.net>= wrote:
>
>=C2=A0 =C2=A0 =C2=A0Sorry for late reply, was busy.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0Ship Mints <shipmints@gmail.com> writes:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0> On Sun, Mar 16, 2025 at 5:10=E2=80=AFPM Ship M= ints <shipmints= @gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0On Sat, Mar 15, 2025 at 10:= 18=E2=80=AFAM Ship Mints <shipmints@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, Mar 1= 5, 2025 at 1:37=E2=80=AFAM Thierry Volpiatto <thievol@posteo.net> wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Ship Mints <= shipmints@gmail.com> writes:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> I have workarounds that work only for the most simplistic cases.=C2= =A0 Many
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> of our=C2=A0bookmarks themselves contain embedded bookmarks and boo= kmark
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> references (which are individually addressable so can be used
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> separately) with window-states we need to restore in tab-bar tabs t= hat
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0> they represent.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0I don't really understand what your packages are doing or are intend= ed
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0doing, but FWICS in bufferlo: You are using in some places
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0(bookmark-jump name #'ignore); why don't you do all this work (r= estore
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0window-states in tab) in DISPLAY-FUNCTION instead of using `ignore`?
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Your handler would be much simpler by moving the window-state-put and >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0alike calls in DISPLAY-FUNCTION:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0(bookmark-jump name #'your_function_restoring_window_or_frame_state)= =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Using (bookmark-jump name #'ignore) with all the code that jump to >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0frame/tab etc... in the handler is just a workaround to fix the previous=
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0buggy behavior of bookmark--jump-via. IMO.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0It would be good to start with a good example or recipe to see if we can=
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0find a good solution.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We need the b= ookmarks to work from the bookmark menu where no display-function overrides= are supported.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I suggest we = add bookmark-record keys that indicate to bookmark-jump to inhibit/or allow= messing with window-configurations.=C2=A0 The bufferlo bookmarks (and Adam= 's if he wants)
>=C2=A0 =C2=A0 =C2=A0would
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0contain these= hint keys.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'(bookmar= k-jump-inhibit-window-actions . t) ; or whatever we come up with
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I can contriv= e an example, if necessary, but I believe y'all get the point.=C2=A0 Ne= sted bookmarks whose handlers expect their window-configurations not to be = messed with up the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0chain,=C2=A0w= ill always be broken without additional controls.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0The attached patch implemen= ts such a scheme that works for us, and is transparent to other=C2=A0bookma= rk=C2=A0uses.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Perhaps we should restore bookmark--jump-via t= o its previous behavior
>=C2=A0 =C2=A0 =C2=A0> and better document the "rules of the roa= d" for bookmark handlers.=C2=A0
>=C2=A0 =C2=A0 =C2=A0> For simple file- and point-based bookmarks, ha= ndlers need to ensure
>=C2=A0 =C2=A0 =C2=A0> that when they return, the selected window and= current buffer are
>=C2=A0 =C2=A0 =C2=A0> what's intended.=C2=A0 For bookmark handle= rs that perform other actions,
>=C2=A0 =C2=A0 =C2=A0> those rules need not apply to leverage the boo= kmark infrastructure.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0What we could do is propose a more flexible solutio= n so that you could
>=C2=A0 =C2=A0 =C2=A0use whatever you want for bookmark--jump-via; With = what you have proposed so
>=C2=A0 =C2=A0 =C2=A0far, you still have the problem of DISPLAY-FUNCTION= which will always
>=C2=A0 =C2=A0 =C2=A0run (I see there is comments about this problem in = your mentionned
>=C2=A0 =C2=A0 =C2=A0packages), with the patch below you could define a = display-function
>=C2=A0 =C2=A0 =C2=A0entry in your bookmark-record e.g. (display-functio= n . ignore) and then
>=C2=A0 =C2=A0 =C2=A0add a special method for bookmark--jump-via:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0(cl-defmethod bookmark--jump-via (bookmark-name-or-= record (_ (eql 'ignore)))
>=C2=A0 =C2=A0 =C2=A0=C2=A0 (do_watever_you_want_here)) ; e.g. run only = the handler fn.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0NOTE: I used 'ignore as example but you could u= se whatever you want.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0Here the patch:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0diff --git a/lisp/bookmark.el b/lisp/bookmark.el >=C2=A0 =C2=A0 =C2=A0index 99bb26e83cc..e594387f364 100644
>=C2=A0 =C2=A0 =C2=A0--- a/lisp/bookmark.el
>=C2=A0 =C2=A0 =C2=A0+++ b/lisp/bookmark.el
>=C2=A0 =C2=A0 =C2=A0@@ -1259,7 +1259,7 @@ it to the name of the bookmar= k currently being set, advancing
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0"Hook run after `bookmark-jump= 9; jumps to a bookmark.
>=C2=A0 =C2=A0 =C2=A0=C2=A0Useful for example to unhide text in `outline= -mode'.")
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0-(defun bookmark--jump-via (bookmark-name-or-record= display-function)
>=C2=A0 =C2=A0 =C2=A0+(cl-defgeneric bookmark--jump-via (bookmark-name-o= r-record display-function)
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0"Handle BOOKMARK-NAME-OR-RECORD, = then call DISPLAY-FUNCTION.
>=C2=A0 =C2=A0 =C2=A0=C2=A0DISPLAY-FUNCTION is called with the new buffe= r as argument.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0@@ -1319,8 +1319,12 @@ DISPLAY-FUNC would be `switc= h-to-buffer-other-window'."
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0;; Don't use `switch-to-buffer'= ; because it would let the
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0;; window-point override the bookmark&= #39;s point when
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0;; `switch-to-buffer-preserve-window-p= oint' is non-nil.
>=C2=A0 =C2=A0 =C2=A0-=C2=A0 (bookmark--jump-via bookmark (or display-fu= nc 'pop-to-buffer-same-window)))
>=C2=A0 =C2=A0 =C2=A0+=C2=A0 (bookmark-jump-1 bookmark display-func)) >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0+(defun bookmark-jump-1 (bookmark display-func)
>=C2=A0 =C2=A0 =C2=A0+=C2=A0 (let ((dfn (or (bookmark-prop-get bookmark = 'display-function)
>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0display-func 'pop-to-buffer-same-window)))
>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 (bookmark--jump-via bookmark dfn)))<= br> >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0=C2=A0;;;###autoload
>=C2=A0 =C2=A0 =C2=A0=C2=A0(defun bookmark-jump-other-window (bookmark)<= br> >=C2=A0 =C2=A0 =C2=A0@@ -2303,7 +2307,7 @@ the related behaviors of `boo= kmark-save' and `bookmark-bmenu-save'."
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(pop-up-windows t= ))
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0(delete-other-windows)
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0(switch-to-buffer (other-buffer= ) nil t)
>=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0 (bookmark--jump-via bmrk 'pop-to= -buffer)
>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 (bookmark-jump-1 bmrk 'pop-to-bu= ffer)
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0(bury-buffer menu)))
>
>=C2=A0 =C2=A0 =C2=A0@@ -2317,7 +2321,7 @@ the related behaviors of `boo= kmark-save' and `bookmark-bmenu-save'."
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0"Select this line's bookmark = in other window, leaving bookmark menu visible."
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(interactive nil bookmark-bmenu-mode)<= br> >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(let ((bookmark (bookmark-bmenu-bookma= rk)))
>=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0 (bookmark--jump-via bookmark 'sw= itch-to-buffer-other-window)))
>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 (bookmark-jump-1 bookmark 'switc= h-to-buffer-other-window)))
>
>=C2=A0 =C2=A0 =C2=A0=C2=A0(defun bookmark-bmenu-other-frame ()
>=C2=A0 =C2=A0 =C2=A0@@ -2333,7 +2337,7 @@ The current window remains se= lected."
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(interactive nil bookmark-bmenu-mode)<= br> >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(let ((bookmark (bookmark-bmenu-bookma= rk))
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 (fun (lambda (b) (displ= ay-buffer b t))))
>=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0 (bookmark--jump-via bookmark fun)))<= br> >=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 (bookmark-jump-1 bookmark fun)))
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0=C2=A0(defun bookmark-bmenu-other-window-with-mouse= (event)
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0"Jump to bookmark at mouse EVENT = position in other window.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0Also I guess trying to call bookmark-jump-other-win= dow and friends is
>=C2=A0 =C2=A0 =C2=A0failing with your special bookmarks, with this it w= ould run just as
>=C2=A0 =C2=A0 =C2=A0bookmark-jump without (possible) errors.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0WDYT?
>
> Thanks for the continuing=C2=A0discussion.
>
> The concept will work but it feels a bit over-engineered.

It is not, it is quite simple.

> The approach of ignoring save-window-excursion and display-func via > bookmark-record entries or using properties on the handler seem less > intrusive or a mix,=C2=A0if we feel that's appropriate.

I proposed this solution to help you cleaning up your code which is full of workarounds for the current behavior (prior 31).=C2=A0 Of course if you<= br> don't want to make an effort to update your code, what you propose is simpler (i.e. you have nothing to change on your side), but generally we (external emacs extensions developers) try to adapt ourselves to Emacs
source and not the contrary.

Thanks for the input.

<= div class=3D"gmail_default" style=3D"font-family:monospace">The idea that I= "don't want to make an effort" is insulting.=C2=A0 Perhaps a= little less coffee.
= =C2=A0
> W= hy not just fix the eww bookmark handler to do its own
> save-window-excursion, again, rather than make a default bookmark jump=
> behavior policy change?

Because the problem is not just about eww, but more generally on how
bookmark handlers work.

Curious to know which other ones a= re broken?=C2=A0 I read eww and w3m.

> =C2=A0 We'd still need a method to inhibit display-func in the int= eractive
> bookmark menu case.

No.

If we do not go the cl-defgeneric route, we will.

What do the Emacs= maintainers think about this as a matter of taste, easy adoption for other= bookmark users, and idiomatic usage?=C2=A0 I'm open.
--0000000000007532f006309f8ce2-- From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 18 11:56:19 2025 Received: (at submit) by debbugs.gnu.org; 18 Mar 2025 15:56:20 +0000 Received: from localhost ([127.0.0.1]:42551 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tuZIe-00005h-HM for submit@debbugs.gnu.org; Tue, 18 Mar 2025 11:56:19 -0400 Received: from lists.gnu.org ([2001:470:142::17]:35330) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tuZIb-0008Vy-EK for submit@debbugs.gnu.org; Tue, 18 Mar 2025 11:56:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tuZIV-0002yC-Ao for bug-gnu-emacs@gnu.org; Tue, 18 Mar 2025 11:56:07 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tuZIP-0002X0-D9 for bug-gnu-emacs@gnu.org; Tue, 18 Mar 2025 11:56:06 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 8FF7D240101 for ; Tue, 18 Mar 2025 16:55:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1742313358; bh=4DpCfk3Vh0vTQKWiPfLeSuPXHRycbhZq9TP6dehNGJM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=kApmno59O6m7QEJPyeR30iZOy4h4rxanyqzNy8f57B0EjKeXFRdI69Er1tiJ2EWn7 J9UBnWrF4sNGxrIWR02I2AjN1rgPdKC0vAgthVsAijmPnTvxa7+QH0twSQWYZMs6sS 9tbVN4UPiXtZu+mXIzAhr7qYaxVT1Xs7BkSDbj3633ppmirmZjqqrfkbxrcAY3eOXz BDXKUKIkHh8mL2wwZ0XNPpc4KtAEeJ9jEJyQcEMEnwhEkzjkjb7d0iz39el2q1LsiK /tPT4hsEFXDcIxJoOY2idWN1UC4cZvYzjrsPucxQc02q9twpUw6lTJZkn/6YzwWlFe o22kQR8rYsbvA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4ZHGf31QRRz9rxD; Tue, 18 Mar 2025 16:55:54 +0100 (CET) From: Thierry Volpiatto To: Ship Mints Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) In-Reply-To: (Ship Mints's message of "Tue, 18 Mar 2025 11:27:42 -0400") References: <874izwn306.fsf@posteo.net> <87y0x8kyaq.fsf@posteo.net> <877c4r6cok.fsf@posteo.net> <871puy6e5x.fsf@posteo.net> <87v7s6om6i.fsf@posteo.net> <87ecyul5xg.fsf@posteo.net> Date: Tue, 18 Mar 2025 16:03:22 +0000 Message-ID: <878qp2l41h.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=185.67.36.66; envelope-from=thievol@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Thierry Volpiatto , Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 U2hpcCBNaW50cyA8c2hpcG1pbnRzQGdtYWlsLmNvbT4gd3JpdGVzOg0KDQo+IDEuICAoICkgdGV4 dC9wbGFpbiAgICAgICAgICAoKikgdGV4dC9odG1sICAgICAgICAgICANCj4NCj4gT24gVHVlLCBN YXIgMTgsIDIwMjUgYXQgMTE6MTXigK9BTSBUaGllcnJ5IFZvbHBpYXR0byA8dGhpZXZvbEBwb3N0 ZW8ubmV0PiB3cm90ZToNCj4NCj4gICAgIFNoaXAgTWludHMgPHNoaXBtaW50c0BnbWFpbC5jb20+ IHdyaXRlczoNCj4gICAgDQo+ICAgICA+IDEuwqAgKCApIHRleHQvcGxhaW7CoCDCoCDCoCDCoCDC oCAoKikgdGV4dC9odG1swqAgwqAgwqAgwqAgwqAgwqANCj4gICAgID4NCj4gICAgID4gT24gVHVl LCBNYXIgMTgsIDIwMjUgYXQgMjo1NeKAr0FNIFRoaWVycnkgVm9scGlhdHRvIDx0aGlldm9sQHBv c3Rlby5uZXQ+IHdyb3RlOg0KPiAgICAgPg0KPiAgICAgPsKgIMKgIMKgU29ycnkgZm9yIGxhdGUg cmVwbHksIHdhcyBidXN5Lg0KPiAgICAgPsKgIMKgDQo+ICAgICA+wqAgwqAgwqBTaGlwIE1pbnRz IDxzaGlwbWludHNAZ21haWwuY29tPiB3cml0ZXM6DQo+ICAgICA+wqAgwqANCj4gICAgID7CoCDC oCDCoD4gT24gU3VuLCBNYXIgMTYsIDIwMjUgYXQgNToxMOKAr1BNIFNoaXAgTWludHMgPHNoaXBt aW50c0BnbWFpbC5jb20+IHdyb3RlOg0KPiAgICAgPsKgIMKgIMKgPg0KPiAgICAgPsKgIMKgIMKg PsKgIMKgIMKgT24gU2F0LCBNYXIgMTUsIDIwMjUgYXQgMTA6MTjigK9BTSBTaGlwIE1pbnRzIDxz aGlwbWludHNAZ21haWwuY29tPiB3cm90ZToNCj4gICAgID7CoCDCoCDCoD7CoCDCoA0KPiAgICAg PsKgIMKgIMKgPsKgIMKgIMKgIMKgIMKgT24gU2F0LCBNYXIgMTUsIDIwMjUgYXQgMTozN+KAr0FN IFRoaWVycnkgVm9scGlhdHRvIDx0aGlldm9sQHBvc3Rlby5uZXQ+IHdyb3RlOg0KPiAgICAgPsKg IMKgIMKgPsKgIMKgIMKgIMKgDQo+ICAgICA+wqAgwqAgwqA+wqAgwqAgwqAgwqAgwqAgwqAgwqBT aGlwIE1pbnRzIDxzaGlwbWludHNAZ21haWwuY29tPiB3cml0ZXM6DQo+ICAgICA+wqAgwqAgwqA+ wqAgwqAgwqAgwqAgwqAgwqANCj4gICAgID7CoCDCoCDCoD7CoCDCoCDCoCDCoCDCoCDCoCDCoD4g SSBoYXZlIHdvcmthcm91bmRzIHRoYXQgd29yayBvbmx5IGZvciB0aGUgbW9zdCBzaW1wbGlzdGlj IGNhc2VzLsKgIE1hbnkNCj4gICAgID7CoCDCoCDCoD7CoCDCoCDCoCDCoCDCoCDCoCDCoD4gb2Yg b3VywqBib29rbWFya3MgdGhlbXNlbHZlcyBjb250YWluIGVtYmVkZGVkIGJvb2ttYXJrcyBhbmQg Ym9va21hcmsNCj4gICAgID7CoCDCoCDCoD7CoCDCoCDCoCDCoCDCoCDCoCDCoD4gcmVmZXJlbmNl cyAod2hpY2ggYXJlIGluZGl2aWR1YWxseSBhZGRyZXNzYWJsZSBzbyBjYW4gYmUgdXNlZA0KPiAg ICAgPsKgIMKgIMKgPsKgIMKgIMKgIMKgIMKgIMKgIMKgPiBzZXBhcmF0ZWx5KSB3aXRoIHdpbmRv dy1zdGF0ZXMgd2UgbmVlZCB0byByZXN0b3JlIGluIHRhYi1iYXIgdGFicyB0aGF0DQo+ICAgICA+ wqAgwqAgwqA+wqAgwqAgwqAgwqAgwqAgwqAgwqA+IHRoZXkgcmVwcmVzZW50Lg0KPiAgICAgPsKg IMKgIMKgPsKgIMKgIMKgIMKgIMKgIMKgDQo+ICAgICA+wqAgwqAgwqA+wqAgwqAgwqAgwqAgwqAg wqAgwqBJIGRvbid0IHJlYWxseSB1bmRlcnN0YW5kIHdoYXQgeW91ciBwYWNrYWdlcyBhcmUgZG9p bmcgb3IgYXJlIGludGVuZGVkDQo+ICAgICA+wqAgwqAgwqA+wqAgwqAgwqAgwqAgwqAgwqAgwqBk b2luZywgYnV0IEZXSUNTIGluIGJ1ZmZlcmxvOiBZb3UgYXJlIHVzaW5nIGluIHNvbWUgcGxhY2Vz DQo+ICAgICA+wqAgwqAgwqA+wqAgwqAgwqAgwqAgwqAgwqAgwqAoYm9va21hcmstanVtcCBuYW1l ICMnaWdub3JlKTsgd2h5IGRvbid0IHlvdSBkbyBhbGwgdGhpcyB3b3JrIChyZXN0b3JlDQo+ICAg ICA+wqAgwqAgwqA+wqAgwqAgwqAgwqAgwqAgwqAgwqB3aW5kb3ctc3RhdGVzIGluIHRhYikgaW4g RElTUExBWS1GVU5DVElPTiBpbnN0ZWFkIG9mIHVzaW5nIGBpZ25vcmVgPw0KPiAgICAgPsKgIMKg IMKgPsKgIMKgIMKgIMKgIMKgIMKgIMKgWW91ciBoYW5kbGVyIHdvdWxkIGJlIG11Y2ggc2ltcGxl ciBieSBtb3ZpbmcgdGhlIHdpbmRvdy1zdGF0ZS1wdXQgYW5kDQo+ICAgICA+wqAgwqAgwqA+wqAg wqAgwqAgwqAgwqAgwqAgwqBhbGlrZSBjYWxscyBpbiBESVNQTEFZLUZVTkNUSU9OOg0KPiAgICAg PsKgIMKgIMKgPsKgIMKgIMKgIMKgIMKgIMKgDQo+ICAgICA+wqAgwqAgwqA+wqAgwqAgwqAgwqAg wqAgwqAgwqAoYm9va21hcmstanVtcCBuYW1lICMneW91cl9mdW5jdGlvbl9yZXN0b3Jpbmdfd2lu ZG93X29yX2ZyYW1lX3N0YXRlKcKgDQo+ICAgICA+wqAgwqAgwqA+wqAgwqAgwqAgwqAgwqAgwqAN Cj4gICAgID7CoCDCoCDCoD7CoCDCoCDCoCDCoCDCoCDCoCDCoFVzaW5nIChib29rbWFyay1qdW1w IG5hbWUgIydpZ25vcmUpIHdpdGggYWxsIHRoZSBjb2RlIHRoYXQganVtcCB0bw0KPiAgICAgPsKg IMKgIMKgPsKgIMKgIMKgIMKgIMKgIMKgIMKgZnJhbWUvdGFiIGV0Yy4uLiBpbiB0aGUgaGFuZGxl ciBpcyBqdXN0IGEgd29ya2Fyb3VuZCB0byBmaXggdGhlIHByZXZpb3VzDQo+ICAgICA+wqAgwqAg wqA+wqAgwqAgwqAgwqAgwqAgwqAgwqBidWdneSBiZWhhdmlvciBvZiBib29rbWFyay0tanVtcC12 aWEuIElNTy4NCj4gICAgID7CoCDCoCDCoD7CoCDCoCDCoCDCoCDCoCDCoA0KPiAgICAgPsKgIMKg IMKgPsKgIMKgIMKgIMKgIMKgIMKgIMKgSXQgd291bGQgYmUgZ29vZCB0byBzdGFydCB3aXRoIGEg Z29vZCBleGFtcGxlIG9yIHJlY2lwZSB0byBzZWUgaWYgd2UgY2FuDQo+ICAgICA+wqAgwqAgwqA+ wqAgwqAgwqAgwqAgwqAgwqAgwqBmaW5kIGEgZ29vZCBzb2x1dGlvbi4NCj4gICAgID7CoCDCoCDC oD4NCj4gICAgID7CoCDCoCDCoD7CoCDCoCDCoCDCoCDCoFdlIG5lZWQgdGhlIGJvb2ttYXJrcyB0 byB3b3JrIGZyb20gdGhlIGJvb2ttYXJrIG1lbnUgd2hlcmUgbm8gZGlzcGxheS1mdW5jdGlvbiBv dmVycmlkZXMgYXJlIHN1cHBvcnRlZC4NCj4gICAgID7CoCDCoCDCoD7CoCDCoCDCoCDCoA0KPiAg ICAgPsKgIMKgIMKgPsKgIMKgIMKgIMKgIMKgSSBzdWdnZXN0IHdlIGFkZCBib29rbWFyay1yZWNv cmQga2V5cyB0aGF0IGluZGljYXRlIHRvIGJvb2ttYXJrLWp1bXAgdG8gaW5oaWJpdC9vciBhbGxv dyBtZXNzaW5nIHdpdGggd2luZG93LWNvbmZpZ3VyYXRpb25zLsKgIFRoZSBidWZmZXJsbyBib29r bWFya3MgKGFuZCBBZGFtJ3MgaWYgaGUNCj4gICAgIHdhbnRzKQ0KPiAgICAgPsKgIMKgIMKgd291 bGQNCj4gICAgID7CoCDCoCDCoD7CoCDCoCDCoCDCoCDCoGNvbnRhaW4gdGhlc2UgaGludCBrZXlz Lg0KPiAgICAgPsKgIMKgIMKgPsKgIMKgIMKgIMKgDQo+ICAgICA+wqAgwqAgwqA+wqAgwqAgwqAg wqAgwqAnKGJvb2ttYXJrLWp1bXAtaW5oaWJpdC13aW5kb3ctYWN0aW9ucyAuIHQpIDsgb3Igd2hh dGV2ZXIgd2UgY29tZSB1cCB3aXRoDQo+ICAgICA+wqAgwqAgwqA+wqAgwqAgwqAgwqANCj4gICAg ID7CoCDCoCDCoD7CoCDCoCDCoCDCoCDCoEkgY2FuIGNvbnRyaXZlIGFuIGV4YW1wbGUsIGlmIG5l Y2Vzc2FyeSwgYnV0IEkgYmVsaWV2ZSB5J2FsbCBnZXQgdGhlIHBvaW50LsKgIE5lc3RlZCBib29r bWFya3Mgd2hvc2UgaGFuZGxlcnMgZXhwZWN0IHRoZWlyIHdpbmRvdy1jb25maWd1cmF0aW9ucyBu b3QgdG8gYmUgbWVzc2VkIHdpdGggdXANCj4gICAgIHRoZQ0KPiAgICAgPsKgIMKgIMKgPsKgIMKg IMKgIMKgIMKgY2hhaW4swqB3aWxsIGFsd2F5cyBiZSBicm9rZW4gd2l0aG91dCBhZGRpdGlvbmFs IGNvbnRyb2xzLg0KPiAgICAgPsKgIMKgIMKgPg0KPiAgICAgPsKgIMKgIMKgPsKgIMKgIMKgVGhl IGF0dGFjaGVkIHBhdGNoIGltcGxlbWVudHMgc3VjaCBhIHNjaGVtZSB0aGF0IHdvcmtzIGZvciB1 cywgYW5kIGlzIHRyYW5zcGFyZW50IHRvIG90aGVywqBib29rbWFya8KgdXNlcy4NCj4gICAgID7C oCDCoCDCoD4NCj4gICAgID7CoCDCoCDCoD4gUGVyaGFwcyB3ZSBzaG91bGQgcmVzdG9yZSBib29r bWFyay0tanVtcC12aWEgdG8gaXRzIHByZXZpb3VzIGJlaGF2aW9yDQo+ICAgICA+wqAgwqAgwqA+ IGFuZCBiZXR0ZXIgZG9jdW1lbnQgdGhlICJydWxlcyBvZiB0aGUgcm9hZCIgZm9yIGJvb2ttYXJr IGhhbmRsZXJzLsKgDQo+ICAgICA+wqAgwqAgwqA+IEZvciBzaW1wbGUgZmlsZS0gYW5kIHBvaW50 LWJhc2VkIGJvb2ttYXJrcywgaGFuZGxlcnMgbmVlZCB0byBlbnN1cmUNCj4gICAgID7CoCDCoCDC oD4gdGhhdCB3aGVuIHRoZXkgcmV0dXJuLCB0aGUgc2VsZWN0ZWQgd2luZG93IGFuZCBjdXJyZW50 IGJ1ZmZlciBhcmUNCj4gICAgID7CoCDCoCDCoD4gd2hhdCdzIGludGVuZGVkLsKgIEZvciBib29r bWFyayBoYW5kbGVycyB0aGF0IHBlcmZvcm0gb3RoZXIgYWN0aW9ucywNCj4gICAgID7CoCDCoCDC oD4gdGhvc2UgcnVsZXMgbmVlZCBub3QgYXBwbHkgdG8gbGV2ZXJhZ2UgdGhlIGJvb2ttYXJrIGlu ZnJhc3RydWN0dXJlLg0KPiAgICAgPsKgIMKgDQo+ICAgICA+wqAgwqAgwqBXaGF0IHdlIGNvdWxk IGRvIGlzIHByb3Bvc2UgYSBtb3JlIGZsZXhpYmxlIHNvbHV0aW9uIHNvIHRoYXQgeW91IGNvdWxk DQo+ICAgICA+wqAgwqAgwqB1c2Ugd2hhdGV2ZXIgeW91IHdhbnQgZm9yIGJvb2ttYXJrLS1qdW1w LXZpYTsgV2l0aCB3aGF0IHlvdSBoYXZlIHByb3Bvc2VkIHNvDQo+ICAgICA+wqAgwqAgwqBmYXIs IHlvdSBzdGlsbCBoYXZlIHRoZSBwcm9ibGVtIG9mIERJU1BMQVktRlVOQ1RJT04gd2hpY2ggd2ls bCBhbHdheXMNCj4gICAgID7CoCDCoCDCoHJ1biAoSSBzZWUgdGhlcmUgaXMgY29tbWVudHMgYWJv dXQgdGhpcyBwcm9ibGVtIGluIHlvdXIgbWVudGlvbm5lZA0KPiAgICAgPsKgIMKgIMKgcGFja2Fn ZXMpLCB3aXRoIHRoZSBwYXRjaCBiZWxvdyB5b3UgY291bGQgZGVmaW5lIGEgZGlzcGxheS1mdW5j dGlvbg0KPiAgICAgPsKgIMKgIMKgZW50cnkgaW4geW91ciBib29rbWFyay1yZWNvcmQgZS5nLiAo ZGlzcGxheS1mdW5jdGlvbiAuIGlnbm9yZSkgYW5kIHRoZW4NCj4gICAgID7CoCDCoCDCoGFkZCBh IHNwZWNpYWwgbWV0aG9kIGZvciBib29rbWFyay0tanVtcC12aWE6DQo+ICAgICA+wqAgwqANCj4g ICAgID7CoCDCoCDCoChjbC1kZWZtZXRob2QgYm9va21hcmstLWp1bXAtdmlhIChib29rbWFyay1u YW1lLW9yLXJlY29yZCAoXyAoZXFsICdpZ25vcmUpKSkNCj4gICAgID7CoCDCoCDCoMKgIChkb193 YXRldmVyX3lvdV93YW50X2hlcmUpKSA7IGUuZy4gcnVuIG9ubHkgdGhlIGhhbmRsZXIgZm4uDQo+ ICAgICA+wqAgwqANCj4gICAgID7CoCDCoCDCoE5PVEU6IEkgdXNlZCAnaWdub3JlIGFzIGV4YW1w bGUgYnV0IHlvdSBjb3VsZCB1c2Ugd2hhdGV2ZXIgeW91IHdhbnQuDQo+ICAgICA+wqAgwqANCj4g ICAgID7CoCDCoCDCoEhlcmUgdGhlIHBhdGNoOg0KPiAgICAgPsKgIMKgDQo+ICAgICA+wqAgwqAg wqBkaWZmIC0tZ2l0IGEvbGlzcC9ib29rbWFyay5lbCBiL2xpc3AvYm9va21hcmsuZWwNCj4gICAg ID7CoCDCoCDCoGluZGV4IDk5YmIyNmU4M2NjLi5lNTk0Mzg3ZjM2NCAxMDA2NDQNCj4gICAgID7C oCDCoCDCoC0tLSBhL2xpc3AvYm9va21hcmsuZWwNCj4gICAgID7CoCDCoCDCoCsrKyBiL2xpc3Av Ym9va21hcmsuZWwNCj4gICAgID7CoCDCoCDCoEBAIC0xMjU5LDcgKzEyNTksNyBAQCBpdCB0byB0 aGUgbmFtZSBvZiB0aGUgYm9va21hcmsgY3VycmVudGx5IGJlaW5nIHNldCwgYWR2YW5jaW5nDQo+ ICAgICA+wqAgwqAgwqDCoCDCoCJIb29rIHJ1biBhZnRlciBgYm9va21hcmstanVtcCcganVtcHMg dG8gYSBib29rbWFyay4NCj4gICAgID7CoCDCoCDCoMKgVXNlZnVsIGZvciBleGFtcGxlIHRvIHVu aGlkZSB0ZXh0IGluIGBvdXRsaW5lLW1vZGUnLiIpDQo+ICAgICA+wqAgwqANCj4gICAgID7CoCDC oCDCoC0oZGVmdW4gYm9va21hcmstLWp1bXAtdmlhIChib29rbWFyay1uYW1lLW9yLXJlY29yZCBk aXNwbGF5LWZ1bmN0aW9uKQ0KPiAgICAgPsKgIMKgIMKgKyhjbC1kZWZnZW5lcmljIGJvb2ttYXJr LS1qdW1wLXZpYSAoYm9va21hcmstbmFtZS1vci1yZWNvcmQgZGlzcGxheS1mdW5jdGlvbikNCj4g ICAgID7CoCDCoCDCoMKgIMKgIkhhbmRsZSBCT09LTUFSSy1OQU1FLU9SLVJFQ09SRCwgdGhlbiBj YWxsIERJU1BMQVktRlVOQ1RJT04uDQo+ICAgICA+wqAgwqAgwqDCoERJU1BMQVktRlVOQ1RJT04g aXMgY2FsbGVkIHdpdGggdGhlIG5ldyBidWZmZXIgYXMgYXJndW1lbnQuDQo+ICAgICA+wqAgwqAN Cj4gICAgID7CoCDCoCDCoEBAIC0xMzE5LDggKzEzMTksMTIgQEAgRElTUExBWS1GVU5DIHdvdWxk IGJlIGBzd2l0Y2gtdG8tYnVmZmVyLW90aGVyLXdpbmRvdycuIg0KPiAgICAgPsKgIMKgIMKgwqAg wqA7OyBEb24ndCB1c2UgYHN3aXRjaC10by1idWZmZXInIGJlY2F1c2UgaXQgd291bGQgbGV0IHRo ZQ0KPiAgICAgPsKgIMKgIMKgwqAgwqA7OyB3aW5kb3ctcG9pbnQgb3ZlcnJpZGUgdGhlIGJvb2tt YXJrJ3MgcG9pbnQgd2hlbg0KPiAgICAgPsKgIMKgIMKgwqAgwqA7OyBgc3dpdGNoLXRvLWJ1ZmZl ci1wcmVzZXJ2ZS13aW5kb3ctcG9pbnQnIGlzIG5vbi1uaWwuDQo+ICAgICA+wqAgwqAgwqAtwqAg KGJvb2ttYXJrLS1qdW1wLXZpYSBib29rbWFyayAob3IgZGlzcGxheS1mdW5jICdwb3AtdG8tYnVm ZmVyLXNhbWUtd2luZG93KSkpDQo+ICAgICA+wqAgwqAgwqArwqAgKGJvb2ttYXJrLWp1bXAtMSBi b29rbWFyayBkaXNwbGF5LWZ1bmMpKQ0KPiAgICAgPsKgIMKgDQo+ICAgICA+wqAgwqAgwqArKGRl ZnVuIGJvb2ttYXJrLWp1bXAtMSAoYm9va21hcmsgZGlzcGxheS1mdW5jKQ0KPiAgICAgPsKgIMKg IMKgK8KgIChsZXQgKChkZm4gKG9yIChib29rbWFyay1wcm9wLWdldCBib29rbWFyayAnZGlzcGxh eS1mdW5jdGlvbikNCj4gICAgID7CoCDCoCDCoCvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGRp c3BsYXktZnVuYyAncG9wLXRvLWJ1ZmZlci1zYW1lLXdpbmRvdykpKQ0KPiAgICAgPsKgIMKgIMKg K8KgIMKgIChib29rbWFyay0tanVtcC12aWEgYm9va21hcmsgZGZuKSkpDQo+ICAgICA+wqAgwqAN Cj4gICAgID7CoCDCoCDCoMKgOzs7IyMjYXV0b2xvYWQNCj4gICAgID7CoCDCoCDCoMKgKGRlZnVu IGJvb2ttYXJrLWp1bXAtb3RoZXItd2luZG93IChib29rbWFyaykNCj4gICAgID7CoCDCoCDCoEBA IC0yMzAzLDcgKzIzMDcsNyBAQCB0aGUgcmVsYXRlZCBiZWhhdmlvcnMgb2YgYGJvb2ttYXJrLXNh dmUnIGFuZCBgYm9va21hcmstYm1lbnUtc2F2ZScuIg0KPiAgICAgPsKgIMKgIMKgwqAgwqAgwqAg wqAgwqAocG9wLXVwLXdpbmRvd3MgdCkpDQo+ICAgICA+wqAgwqAgwqDCoCDCoCDCoChkZWxldGUt b3RoZXItd2luZG93cykNCj4gICAgID7CoCDCoCDCoMKgIMKgIMKgKHN3aXRjaC10by1idWZmZXIg KG90aGVyLWJ1ZmZlcikgbmlsIHQpDQo+ICAgICA+wqAgwqAgwqAtwqAgwqAgKGJvb2ttYXJrLS1q dW1wLXZpYSBibXJrICdwb3AtdG8tYnVmZmVyKQ0KPiAgICAgPsKgIMKgIMKgK8KgIMKgIChib29r bWFyay1qdW1wLTEgYm1yayAncG9wLXRvLWJ1ZmZlcikNCj4gICAgID7CoCDCoCDCoMKgIMKgIMKg KGJ1cnktYnVmZmVyIG1lbnUpKSkNCj4gICAgID4NCj4gICAgID7CoCDCoCDCoEBAIC0yMzE3LDcg KzIzMjEsNyBAQCB0aGUgcmVsYXRlZCBiZWhhdmlvcnMgb2YgYGJvb2ttYXJrLXNhdmUnIGFuZCBg Ym9va21hcmstYm1lbnUtc2F2ZScuIg0KPiAgICAgPsKgIMKgIMKgwqAgwqAiU2VsZWN0IHRoaXMg bGluZSdzIGJvb2ttYXJrIGluIG90aGVyIHdpbmRvdywgbGVhdmluZyBib29rbWFyayBtZW51IHZp c2libGUuIg0KPiAgICAgPsKgIMKgIMKgwqAgwqAoaW50ZXJhY3RpdmUgbmlsIGJvb2ttYXJrLWJt ZW51LW1vZGUpDQo+ICAgICA+wqAgwqAgwqDCoCDCoChsZXQgKChib29rbWFyayAoYm9va21hcmst Ym1lbnUtYm9va21hcmspKSkNCj4gICAgID7CoCDCoCDCoC3CoCDCoCAoYm9va21hcmstLWp1bXAt dmlhIGJvb2ttYXJrICdzd2l0Y2gtdG8tYnVmZmVyLW90aGVyLXdpbmRvdykpKQ0KPiAgICAgPsKg IMKgIMKgK8KgIMKgIChib29rbWFyay1qdW1wLTEgYm9va21hcmsgJ3N3aXRjaC10by1idWZmZXIt b3RoZXItd2luZG93KSkpDQo+ICAgICA+DQo+ICAgICA+wqAgwqAgwqDCoChkZWZ1biBib29rbWFy ay1ibWVudS1vdGhlci1mcmFtZSAoKQ0KPiAgICAgPsKgIMKgIMKgQEAgLTIzMzMsNyArMjMzNyw3 IEBAIFRoZSBjdXJyZW50IHdpbmRvdyByZW1haW5zIHNlbGVjdGVkLiINCj4gICAgID7CoCDCoCDC oMKgIMKgKGludGVyYWN0aXZlIG5pbCBib29rbWFyay1ibWVudS1tb2RlKQ0KPiAgICAgPsKgIMKg IMKgwqAgwqAobGV0ICgoYm9va21hcmsgKGJvb2ttYXJrLWJtZW51LWJvb2ttYXJrKSkNCj4gICAg ID7CoCDCoCDCoMKgIMKgIMKgIMKgIChmdW4gKGxhbWJkYSAoYikgKGRpc3BsYXktYnVmZmVyIGIg dCkpKSkNCj4gICAgID7CoCDCoCDCoC3CoCDCoCAoYm9va21hcmstLWp1bXAtdmlhIGJvb2ttYXJr IGZ1bikpKQ0KPiAgICAgPsKgIMKgIMKgK8KgIMKgIChib29rbWFyay1qdW1wLTEgYm9va21hcmsg ZnVuKSkpDQo+ICAgICA+wqAgwqANCj4gICAgID7CoCDCoCDCoMKgKGRlZnVuIGJvb2ttYXJrLWJt ZW51LW90aGVyLXdpbmRvdy13aXRoLW1vdXNlIChldmVudCkNCj4gICAgID7CoCDCoCDCoMKgIMKg Ikp1bXAgdG8gYm9va21hcmsgYXQgbW91c2UgRVZFTlQgcG9zaXRpb24gaW4gb3RoZXIgd2luZG93 Lg0KPiAgICAgPsKgIMKgDQo+ICAgICA+wqAgwqAgwqBBbHNvIEkgZ3Vlc3MgdHJ5aW5nIHRvIGNh bGwgYm9va21hcmstanVtcC1vdGhlci13aW5kb3cgYW5kIGZyaWVuZHMgaXMNCj4gICAgID7CoCDC oCDCoGZhaWxpbmcgd2l0aCB5b3VyIHNwZWNpYWwgYm9va21hcmtzLCB3aXRoIHRoaXMgaXQgd291 bGQgcnVuIGp1c3QgYXMNCj4gICAgID7CoCDCoCDCoGJvb2ttYXJrLWp1bXAgd2l0aG91dCAocG9z c2libGUpIGVycm9ycy4NCj4gICAgID7CoCDCoA0KPiAgICAgPsKgIMKgIMKgV0RZVD8NCj4gICAg ID4NCj4gICAgID4gVGhhbmtzIGZvciB0aGUgY29udGludWluZ8KgZGlzY3Vzc2lvbi4NCj4gICAg ID4NCj4gICAgID4gVGhlIGNvbmNlcHQgd2lsbCB3b3JrIGJ1dCBpdCBmZWVscyBhIGJpdCBvdmVy LWVuZ2luZWVyZWQuDQo+ICAgIA0KPiAgICAgSXQgaXMgbm90LCBpdCBpcyBxdWl0ZSBzaW1wbGUu DQo+ICAgIA0KPiAgICAgPiBUaGUgYXBwcm9hY2ggb2YgaWdub3Jpbmcgc2F2ZS13aW5kb3ctZXhj dXJzaW9uIGFuZCBkaXNwbGF5LWZ1bmMgdmlhDQo+ICAgICA+IGJvb2ttYXJrLXJlY29yZCBlbnRy aWVzIG9yIHVzaW5nIHByb3BlcnRpZXMgb24gdGhlIGhhbmRsZXIgc2VlbSBsZXNzDQo+ICAgICA+ IGludHJ1c2l2ZSBvciBhIG1peCzCoGlmIHdlIGZlZWwgdGhhdCdzIGFwcHJvcHJpYXRlLg0KPiAg ICANCj4gICAgIEkgcHJvcG9zZWQgdGhpcyBzb2x1dGlvbiB0byBoZWxwIHlvdSBjbGVhbmluZyB1 cCB5b3VyIGNvZGUgd2hpY2ggaXMgZnVsbA0KPiAgICAgb2Ygd29ya2Fyb3VuZHMgZm9yIHRoZSBj dXJyZW50IGJlaGF2aW9yIChwcmlvciAzMSkuwqAgT2YgY291cnNlIGlmIHlvdQ0KPiAgICAgZG9u J3Qgd2FudCB0byBtYWtlIGFuIGVmZm9ydCB0byB1cGRhdGUgeW91ciBjb2RlLCB3aGF0IHlvdSBw cm9wb3NlIGlzDQo+ICAgICBzaW1wbGVyIChpLmUuIHlvdSBoYXZlIG5vdGhpbmcgdG8gY2hhbmdl IG9uIHlvdXIgc2lkZSksIGJ1dCBnZW5lcmFsbHkgd2UNCj4gICAgIChleHRlcm5hbCBlbWFjcyBl eHRlbnNpb25zIGRldmVsb3BlcnMpIHRyeSB0byBhZGFwdCBvdXJzZWx2ZXMgdG8gRW1hY3MNCj4g ICAgIHNvdXJjZSBhbmQgbm90IHRoZSBjb250cmFyeS4NCj4NCj4gVGhhbmtzIGZvciB0aGUgaW5w dXQuDQo+DQo+IFRoZSBpZGVhIHRoYXQgSSAiZG9uJ3Qgd2FudCB0byBtYWtlIGFuIGVmZm9ydCIg aXMgaW5zdWx0aW5nLg0KDQpTb3JyeSBpZiB5b3UgdGFrZSBpdCBsaWtlIHRoaXMsIGl0IHdhcyBu b3QgdGhlIGludGVudGlvbi4NCg0KPiDCoCBQZXJoYXBzIGEgbGl0dGxlIGxlc3MgY29mZmVlLg0K DQpJIGRvbid0IGRyaW5rIGNvZmZlZS4NCg0KPiAgICAgPiBXaHkgbm90IGp1c3QgZml4IHRoZSBl d3cgYm9va21hcmsgaGFuZGxlciB0byBkbyBpdHMgb3duDQo+ICAgICA+IHNhdmUtd2luZG93LWV4 Y3Vyc2lvbiwgYWdhaW4sIHJhdGhlciB0aGFuIG1ha2UgYSBkZWZhdWx0IGJvb2ttYXJrIGp1bXAN Cj4gICAgID4gYmVoYXZpb3IgcG9saWN5IGNoYW5nZT8NCj4gICAgDQo+ICAgICBCZWNhdXNlIHRo ZSBwcm9ibGVtIGlzIG5vdCBqdXN0IGFib3V0IGV3dywgYnV0IG1vcmUgZ2VuZXJhbGx5IG9uIGhv dw0KPiAgICAgYm9va21hcmsgaGFuZGxlcnMgd29yay4NCj4NCj4gQ3VyaW91cyB0byBrbm93IHdo aWNoIG90aGVyIG9uZXMgYXJlIGJyb2tlbj/CoCBJIHJlYWQgZXd3IGFuZCB3M20uDQoNCkl0IGlz IG5vdCBvbmx5IGFib3V0IGV3dyBBTkQgdzNtLiAgVGhlIHBvaW50IGlzIG5vdCBpZiB0aGluZ3Mg YXJlIGJyb2tlbg0Kb3Igbm90LCBpdCBpcyB0byBwcm92aWRlIGEgZ29vZCBBUEkgZm9yIGFsbCBi b29rbWFya3MgKGFuZCBmdXR1cmUga2luZA0Kb2YgYm9va21hcmtzKS4NCg0KDQo+IFdoYXQgZG8g dGhlIEVtYWNzIG1haW50YWluZXJzIHRoaW5rIGFib3V0IHRoaXMgYXMgYSBtYXR0ZXIgb2YgdGFz dGUsDQo+IGVhc3kgYWRvcHRpb24gZm9yIG90aGVyIGJvb2ttYXJrIHVzZXJzLCBhbmQgaWRpb21h dGljIHVzYWdlPw0KDQpOb3cgRWxpIGFuZCBvdGhlciBtYWludGFpbmVycyB3aWxsIGRlY2lkZSB3 aGF0IGlzIHRoZSBiZXN0IGZvciBlbWFjcy4NCg0KLS0gDQpUaGllcnJ5DQo= --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHHBAEBCgAxFiEEI9twfRN7r3nig/xwDsVtFB0W75MFAmfZmUsTHHRoaWV2b2xA cG9zdGVvLm5ldAAKCRAOxW0UHRbvk2R4C/0fYghJCZNXGtSPuPKDhEMpOgWEMkdV AUIYxyPx7DXjEccGjwuyaYJLnvXGk8P+u0G6YRxSnUVC5vW/o358+dyw8Gbp3Clm w0p7o9scTDjB81/zSVQ5NfeDYzoCEWa198v0jJgQTdXYdnLXe8DiZWesYldrWLjD mKNjU9JaLRAZbhOnPiuFM+VK7smt59i9fKy6qBCHiljCLY4AQ208CYX89QcfZvmP MZryBYWMVhEV2dlnWLobxfzhDWsHTDtBWU6fcxO1/R11EdKOForGaW+58/ja4uUC IbV/wIplANjfnpNhC7KYikkrK4ldVYQn/MYU3E00C4AD0aNUMC7dXYaAz8HHRoeB 89+Ak8y36v278DhY3ix3MjZxcbKD7n3LQHtsOvHl1W1rDq+O6gKX1Fl6Gu0j/i0c f8K1vI3zdr+P3uoY1xhIQM/J+xAUYMpjtzu9uSvxglQmrzNdl9XNrDrc2wvGoEo7 GmfH3BxzcGBFbyo7fcdIbixj781709+q0bM= =4Fst -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 18 12:28:54 2025 Received: (at submit) by debbugs.gnu.org; 18 Mar 2025 16:28:55 +0000 Received: from localhost ([127.0.0.1]:42702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tuZoD-0005AQ-9Z for submit@debbugs.gnu.org; Tue, 18 Mar 2025 12:28:54 -0400 Received: from lists.gnu.org ([2001:470:142::17]:48822) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tuZo3-00057e-05 for submit@debbugs.gnu.org; Tue, 18 Mar 2025 12:28:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tuZnw-0004XS-Ei for bug-gnu-emacs@gnu.org; Tue, 18 Mar 2025 12:28:36 -0400 Received: from mail-vk1-xa33.google.com ([2607:f8b0:4864:20::a33]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tuZns-0002RA-57; Tue, 18 Mar 2025 12:28:36 -0400 Received: by mail-vk1-xa33.google.com with SMTP id 71dfb90a1353d-523b7013dc8so2452716e0c.0; Tue, 18 Mar 2025 09:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742315309; x=1742920109; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SFnaUaj+LgXEvHSjMWpXW3bGYSSYJL2TLMBNofkATPM=; b=Pb5Prsgoz22ZPECFcsKKEoGyeivcL058FT1X9qw5j7dqkiPwj9HY1TLDj5xuseZWh5 MXnSPCsvMoH40Iq1dhkgHyfMti992e1FVWcCNPQrG0BDOzYMfZCVIBaLGVeC8kqnmqJL K0E5DNu9WlZ/K+UO1w6+NdpPe4DldrazUPVGDS4G80gBmdoDlZCZykm0bt80kGHiWG19 6DiA/wYmLYaXK431VzYlFmvaprhw59X3y7+DMOmWrdYID4tHbRt8FUjP4z31VhP4tsDs ZO3mr2HXYs2hKo6qnkdL934ayh83DlIXs5DnClocEjiOtV526kqER5op4QpQbpWVNBnz f8MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742315309; x=1742920109; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SFnaUaj+LgXEvHSjMWpXW3bGYSSYJL2TLMBNofkATPM=; b=e5sCWeokcY0SrrvlguZB/nmr9P1XzB8S1sp+lavNjJchnAYck+T1ZiZAt23sm2nceA 5/TXAvSj5GVy13DxjT7qQ2uWzIG2Ou5EIQRcTgyryY3x4dcg/sWHI1rqRx7NwYWSHdGY u6EZ5sJBGy/bi12c8r8BG/xSwYqToZ3iiEPRoz5jTrP4HhlOsetodiMeX5MkI759hv5w cbrvSNZO88tTq6YY85sDFoNGnRtdSCw0hSP4fIXqOYf70u8YI30Ry3CtVBpi/SPMpmeN d41NlrHGwv8Us1Jx+XhwXe6XQ9S00ywSEkl8o282AuVuP/HvX1PRV/5faXZ12EBFS+Na YBpQ== X-Forwarded-Encrypted: i=1; AJvYcCWUayP2O4bDzaFuyCIGC3bK8gcMXoY4a3ihjTX9/Jnq1RQAAcDbYhZSG5EWyN0WusBJegtuOzs7JGIi3ybj@gnu.org X-Gm-Message-State: AOJu0YzVQMJS9ltwx+6SoWv1ur/s1f1OBVQQO+edCi+gGOZlVD15lz9g CX7jxSVb4+6xeDdHOQR9yisRG65YgrWX9LFXKxrF+34J6VrNTNtrRprZiBYifZK3627us6EXKLI b0nAiwpF9UG9Om4Qz1VM+v+K6drmO3Wv5 X-Gm-Gg: ASbGnctrapUVxHoA+fSQSkBGdnMR46Kp3qK6MSEwlNJFEHw8frEZYhM90gKVxPGssve teDvph2G8jGSMb/O9VW20gZ+bXVjqbfUhj3mTleTwItjqoNV/JUnqgQ2plr9zOb5MSE6x+olyii T67o0FEnct88fXCi3wmyGmRLWhpQ== X-Google-Smtp-Source: AGHT+IHTiCdjvvCKrflLSNBB8YviOxud6g/lr6T67twCEAR/pdyNSJOFwvSP/LufPrKyJsL8uLT6gaUrZXrdPnRg93U= X-Received: by 2002:a05:6122:547:b0:50d:a31c:678c with SMTP id 71dfb90a1353d-52480dfd3f2mr4218459e0c.2.1742315309080; Tue, 18 Mar 2025 09:28:29 -0700 (PDT) MIME-Version: 1.0 References: <874izwn306.fsf@posteo.net> <87y0x8kyaq.fsf@posteo.net> <877c4r6cok.fsf@posteo.net> <871puy6e5x.fsf@posteo.net> <87v7s6om6i.fsf@posteo.net> <87ecyul5xg.fsf@posteo.net> <878qp2l41h.fsf@posteo.net> In-Reply-To: <878qp2l41h.fsf@posteo.net> From: Ship Mints Date: Tue, 18 Mar 2025 12:28:17 -0400 X-Gm-Features: AQ5f1JpwGlB3kA00IUJ_h2gs0Ogph1E6_5Ryxt7KWZliQFUp5UWf5k6bCcjfaQI Message-ID: Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) To: Thierry Volpiatto Content-Type: multipart/alternative; boundary="00000000000015a85b0630a065cf" Received-SPF: pass client-ip=2607:f8b0:4864:20::a33; envelope-from=shipmints@gmail.com; helo=mail-vk1-xa33.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --00000000000015a85b0630a065cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 18, 2025 at 11:55=E2=80=AFAM Thierry Volpiatto wrote: > Ship Mints writes: > > > 1. ( ) text/plain (*) text/html > > > > On Tue, Mar 18, 2025 at 11:15=E2=80=AFAM Thierry Volpiatto > wrote: > > > > Ship Mints writes: > > > > > 1. ( ) text/plain (*) text/html > > > > > > On Tue, Mar 18, 2025 at 2:55=E2=80=AFAM Thierry Volpiatto < > thievol@posteo.net> wrote: > > > > > > Sorry for late reply, was busy. > > > > > > Ship Mints writes: > > > > > > > On Sun, Mar 16, 2025 at 5:10=E2=80=AFPM Ship Mints < > shipmints@gmail.com> wrote: > > > > > > > > On Sat, Mar 15, 2025 at 10:18=E2=80=AFAM Ship Mints < > shipmints@gmail.com> wrote: > > > > > > > > On Sat, Mar 15, 2025 at 1:37=E2=80=AFAM Thierry Vol= piatto < > thievol@posteo.net> wrote: > > > > > > > > Ship Mints writes: > > > > > > > > > I have workarounds that work only for the mos= t > simplistic cases. Many > > > > > of our bookmarks themselves contain embedded > bookmarks and bookmark > > > > > references (which are individually addressabl= e > so can be used > > > > > separately) with window-states we need to > restore in tab-bar tabs that > > > > > they represent. > > > > > > > > I don't really understand what your packages ar= e > doing or are intended > > > > doing, but FWICS in bufferlo: You are using in > some places > > > > (bookmark-jump name #'ignore); why don't you do > all this work (restore > > > > window-states in tab) in DISPLAY-FUNCTION > instead of using `ignore`? > > > > Your handler would be much simpler by moving th= e > window-state-put and > > > > alike calls in DISPLAY-FUNCTION: > > > > > > > > (bookmark-jump name > #'your_function_restoring_window_or_frame_state) > > > > > > > > Using (bookmark-jump name #'ignore) with all th= e > code that jump to > > > > frame/tab etc... in the handler is just a > workaround to fix the previous > > > > buggy behavior of bookmark--jump-via. IMO. > > > > > > > > It would be good to start with a good example o= r > recipe to see if we can > > > > find a good solution. > > > > > > > > We need the bookmarks to work from the bookmark men= u > where no display-function overrides are supported. > > > > > > > > I suggest we add bookmark-record keys that indicate > to bookmark-jump to inhibit/or allow messing with window-configurations. > The bufferlo bookmarks (and Adam's if he > > wants) > > > would > > > > contain these hint keys. > > > > > > > > '(bookmark-jump-inhibit-window-actions . t) ; or > whatever we come up with > > > > > > > > I can contrive an example, if necessary, but I > believe y'all get the point. Nested bookmarks whose handlers expect thei= r > window-configurations not to be messed with up > > the > > > > chain, will always be broken without additional > controls. > > > > > > > > The attached patch implements such a scheme that works > for us, and is transparent to other bookmark uses. > > > > > > > > Perhaps we should restore bookmark--jump-via to its previou= s > behavior > > > > and better document the "rules of the road" for bookmark > handlers. > > > > For simple file- and point-based bookmarks, handlers need t= o > ensure > > > > that when they return, the selected window and current > buffer are > > > > what's intended. For bookmark handlers that perform other > actions, > > > > those rules need not apply to leverage the bookmark > infrastructure. > > > > > > What we could do is propose a more flexible solution so that > you could > > > use whatever you want for bookmark--jump-via; With what you > have proposed so > > > far, you still have the problem of DISPLAY-FUNCTION which wil= l > always > > > run (I see there is comments about this problem in your > mentionned > > > packages), with the patch below you could define a > display-function > > > entry in your bookmark-record e.g. (display-function . ignore= ) > and then > > > add a special method for bookmark--jump-via: > > > > > > (cl-defmethod bookmark--jump-via (bookmark-name-or-record (_ > (eql 'ignore))) > > > (do_watever_you_want_here)) ; e.g. run only the handler fn. > > > > > > NOTE: I used 'ignore as example but you could use whatever yo= u > want. > > > > > > Here the patch: > > > > > > diff --git a/lisp/bookmark.el b/lisp/bookmark.el > > > index 99bb26e83cc..e594387f364 100644 > > > --- a/lisp/bookmark.el > > > +++ b/lisp/bookmark.el > > > @@ -1259,7 +1259,7 @@ it to the name of the bookmark currentl= y > being set, advancing > > > "Hook run after `bookmark-jump' jumps to a bookmark. > > > Useful for example to unhide text in `outline-mode'.") > > > > > > -(defun bookmark--jump-via (bookmark-name-or-record > display-function) > > > +(cl-defgeneric bookmark--jump-via (bookmark-name-or-record > display-function) > > > "Handle BOOKMARK-NAME-OR-RECORD, then call DISPLAY-FUNCTIO= N. > > > DISPLAY-FUNCTION is called with the new buffer as argument. > > > > > > @@ -1319,8 +1319,12 @@ DISPLAY-FUNC would be > `switch-to-buffer-other-window'." > > > ;; Don't use `switch-to-buffer' because it would let the > > > ;; window-point override the bookmark's point when > > > ;; `switch-to-buffer-preserve-window-point' is non-nil. > > > - (bookmark--jump-via bookmark (or display-func > 'pop-to-buffer-same-window))) > > > + (bookmark-jump-1 bookmark display-func)) > > > > > > +(defun bookmark-jump-1 (bookmark display-func) > > > + (let ((dfn (or (bookmark-prop-get bookmark > 'display-function) > > > + display-func 'pop-to-buffer-same-window))) > > > + (bookmark--jump-via bookmark dfn))) > > > > > > ;;;###autoload > > > (defun bookmark-jump-other-window (bookmark) > > > @@ -2303,7 +2307,7 @@ the related behaviors of `bookmark-save= ' > and `bookmark-bmenu-save'." > > > (pop-up-windows t)) > > > (delete-other-windows) > > > (switch-to-buffer (other-buffer) nil t) > > > - (bookmark--jump-via bmrk 'pop-to-buffer) > > > + (bookmark-jump-1 bmrk 'pop-to-buffer) > > > (bury-buffer menu))) > > > > > > @@ -2317,7 +2321,7 @@ the related behaviors of `bookmark-save= ' > and `bookmark-bmenu-save'." > > > "Select this line's bookmark in other window, leaving > bookmark menu visible." > > > (interactive nil bookmark-bmenu-mode) > > > (let ((bookmark (bookmark-bmenu-bookmark))) > > > - (bookmark--jump-via bookmark > 'switch-to-buffer-other-window))) > > > + (bookmark-jump-1 bookmark > 'switch-to-buffer-other-window))) > > > > > > (defun bookmark-bmenu-other-frame () > > > @@ -2333,7 +2337,7 @@ The current window remains selected." > > > (interactive nil bookmark-bmenu-mode) > > > (let ((bookmark (bookmark-bmenu-bookmark)) > > > (fun (lambda (b) (display-buffer b t)))) > > > - (bookmark--jump-via bookmark fun))) > > > + (bookmark-jump-1 bookmark fun))) > > > > > > (defun bookmark-bmenu-other-window-with-mouse (event) > > > "Jump to bookmark at mouse EVENT position in other window. > > > > > > Also I guess trying to call bookmark-jump-other-window and > friends is > > > failing with your special bookmarks, with this it would run > just as > > > bookmark-jump without (possible) errors. > > > > > > WDYT? > > > > > > Thanks for the continuing discussion. > > > > > > The concept will work but it feels a bit over-engineered. > > > > It is not, it is quite simple. > > > > > The approach of ignoring save-window-excursion and display-func v= ia > > > bookmark-record entries or using properties on the handler seem > less > > > intrusive or a mix, if we feel that's appropriate. > > > > I proposed this solution to help you cleaning up your code which is > full > > of workarounds for the current behavior (prior 31). Of course if y= ou > > don't want to make an effort to update your code, what you propose = is > > simpler (i.e. you have nothing to change on your side), but > generally we > > (external emacs extensions developers) try to adapt ourselves to > Emacs > > source and not the contrary. > > > > Thanks for the input. > > > > The idea that I "don't want to make an effort" is insulting. > > Sorry if you take it like this, it was not the intention. > > > Perhaps a little less coffee. > > I don't drink coffee. > > > > Why not just fix the eww bookmark handler to do its own > > > save-window-excursion, again, rather than make a default bookmark > jump > > > behavior policy change? > > > > Because the problem is not just about eww, but more generally on ho= w > > bookmark handlers work. > > > > Curious to know which other ones are broken? I read eww and w3m. > > It is not only about eww AND w3m. The point is not if things are broken > or not, it is to provide a good API for all bookmarks (and future kind > of bookmarks). > > > > What do the Emacs maintainers think about this as a matter of taste, > > easy adoption for other bookmark users, and idiomatic usage? > > Now Eli and other maintainers will decide what is the best for emacs. > You may not have seen it but there is already precedent for bookmark-handler properties in bookmark.el in bookmark-insert for the 'bookmark-inhibit property on a handler. It could contain a list of inhibitions. --00000000000015a85b0630a065cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Mar 18, 2025 at 11:= 55=E2=80=AFAM Thierry Volpiatto <t= hievol@posteo.net> wrote:
Ship Mints <shipmints@gmail.com> writes:

> 1.=C2=A0 ( ) text/plain=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (*) text/htm= l=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>
> On Tue, Mar 18, 2025 at 11:15=E2=80=AFAM Thierry Volpiatto <thievol@posteo.net>= wrote:
>
>=C2=A0 =C2=A0 =C2=A0Ship Mints <shipmints@gmail.com> writes:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0> 1.=C2=A0 ( ) text/plain=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 (*) text/html=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Tue, Mar 18, 2025 at 2:55=E2=80=AFAM Thierr= y Volpiatto <thi= evol@posteo.net> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Sorry for late reply, was b= usy.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Ship Mints <shipmints@gmail.com> wr= ites:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> On Sun, Mar 16, 2025 a= t 5:10=E2=80=AFPM Ship Mints <shipmints@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0On = Sat, Mar 15, 2025 at 10:18=E2=80=AFAM Ship Mints <shipmints@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0On Sat, Mar 15, 2025 at 1:37=E2=80=AFAM Thierry Volpiatto <= thievol@posteo.net<= /a>> wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Ship Mints <shipmints@gmail.com> writes:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> I have workarounds that work only for the m= ost simplistic cases.=C2=A0 Many
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> of our=C2=A0bookmarks themselves contain em= bedded bookmarks and bookmark
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> references (which are individually addressa= ble so can be used
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> separately) with window-states we need to r= estore in tab-bar tabs that
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> they represent.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0I don't really understand what your packages= are doing or are intended
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0doing, but FWICS in bufferlo: You are using in s= ome places
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0(bookmark-jump name #'ignore); why don't= you do all this work (restore
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0window-states in tab) in DISPLAY-FUNCTION instea= d of using `ignore`?
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Your handler would be much simpler by moving the= window-state-put and
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0alike calls in DISPLAY-FUNCTION:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0(bookmark-jump name #'your_function_restorin= g_window_or_frame_state)=C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Using (bookmark-jump name #'ignore) with all= the code that jump to
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0frame/tab etc... in the handler is just a workar= ound to fix the previous
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0buggy behavior of bookmark--jump-via. IMO.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0It would be good to start with a good example or= recipe to see if we can
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0find a good solution.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0We need the bookmarks to work from the bookmark menu where no = display-function overrides are supported.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0I suggest we add bookmark-record keys that indicate to bookmar= k-jump to inhibit/or allow messing with window-configurations.=C2=A0 The bu= fferlo bookmarks (and Adam's if he
>=C2=A0 =C2=A0 =C2=A0wants)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0would
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0contain these hint keys.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0'(bookmark-jump-inhibit-window-actions . t) ; or whatever = we come up with
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0I can contrive an example, if necessary, but I believe y'a= ll get the point.=C2=A0 Nested bookmarks whose handlers expect their window= -configurations not to be messed with up
>=C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0chain,=C2=A0will always be broken without additional controls.=
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0The= attached patch implements such a scheme that works for us, and is transpar= ent to other=C2=A0bookmark=C2=A0uses.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Perhaps we should rest= ore bookmark--jump-via to its previous behavior
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> and better document th= e "rules of the road" for bookmark handlers.=C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> For simple file- and p= oint-based bookmarks, handlers need to ensure
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> that when they return,= the selected window and current buffer are
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> what's intended.= =C2=A0 For bookmark handlers that perform other actions,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> those rules need not a= pply to leverage the bookmark infrastructure.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0What we could do is propose= a more flexible solution so that you could
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0use whatever you want for b= ookmark--jump-via; With what you have proposed so
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0far, you still have the pro= blem of DISPLAY-FUNCTION which will always
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0run (I see there is comment= s about this problem in your mentionned
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0packages), with the patch b= elow you could define a display-function
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0entry in your bookmark-reco= rd e.g. (display-function . ignore) and then
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0add a special method for bo= okmark--jump-via:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0(cl-defmethod bookmark--jum= p-via (bookmark-name-or-record (_ (eql 'ignore)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 (do_watever_you_want= _here)) ; e.g. run only the handler fn.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0NOTE: I used 'ignore as= example but you could use whatever you want.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Here the patch:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0diff --git a/lisp/bookmark.= el b/lisp/bookmark.el
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0index 99bb26e83cc..e594387f= 364 100644
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--- a/lisp/bookmark.el
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+++ b/lisp/bookmark.el
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0@@ -1259,7 +1259,7 @@ it to= the name of the bookmark currently being set, advancing
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0"Hook run= after `bookmark-jump' jumps to a bookmark.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0Useful for example to= unhide text in `outline-mode'.")
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-(defun bookmark--jump-via = (bookmark-name-or-record display-function)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+(cl-defgeneric bookmark--j= ump-via (bookmark-name-or-record display-function)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0"Handle B= OOKMARK-NAME-OR-RECORD, then call DISPLAY-FUNCTION.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0DISPLAY-FUNCTION is c= alled with the new buffer as argument.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0@@ -1319,8 +1319,12 @@ DISP= LAY-FUNC would be `switch-to-buffer-other-window'."
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0;; Don't u= se `switch-to-buffer' because it would let the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0;; window-poin= t override the bookmark's point when
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0;; `switch-to-= buffer-preserve-window-point' is non-nil.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-=C2=A0 (bookmark--jump-via= bookmark (or display-func 'pop-to-buffer-same-window)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 (bookmark-jump-1 bo= okmark display-func))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+(defun bookmark-jump-1 (bo= okmark display-func)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 (let ((dfn (or (boo= kmark-prop-get bookmark 'display-function)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0display-func 'pop-to-buffer-same-= window)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 (bookmark--j= ump-via bookmark dfn)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0;;;###autoload
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0(defun bookmark-jump-= other-window (bookmark)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0@@ -2303,7 +2307,7 @@ the r= elated behaviors of `bookmark-save' and `bookmark-bmenu-save'."= ;
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0(pop-up-windows t))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0(delete= -other-windows)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0(switch= -to-buffer (other-buffer) nil t)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0 (bookmark--j= ump-via bmrk 'pop-to-buffer)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 (bookmark-ju= mp-1 bmrk 'pop-to-buffer)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0(bury-b= uffer menu)))
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0@@ -2317,7 +2321,7 @@ the r= elated behaviors of `bookmark-save' and `bookmark-bmenu-save'."= ;
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0"Select t= his line's bookmark in other window, leaving bookmark menu visible.&quo= t;
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(interactive n= il bookmark-bmenu-mode)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(let ((bookmar= k (bookmark-bmenu-bookmark)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0 (bookmark--j= ump-via bookmark 'switch-to-buffer-other-window)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 (bookmark-ju= mp-1 bookmark 'switch-to-buffer-other-window)))
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0(defun bookmark-bmenu= -other-frame ()
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0@@ -2333,7 +2337,7 @@ The c= urrent window remains selected."
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(interactive n= il bookmark-bmenu-mode)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(let ((bookmar= k (bookmark-bmenu-bookmark))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0= (fun (lambda (b) (display-buffer b t))))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0 (bookmark--j= ump-via bookmark fun)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 (bookmark-ju= mp-1 bookmark fun)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0(defun bookmark-bmenu= -other-window-with-mouse (event)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0"Jump to = bookmark at mouse EVENT position in other window.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Also I guess trying to call= bookmark-jump-other-window and friends is
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0failing with your special b= ookmarks, with this it would run just as
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0bookmark-jump without (poss= ible) errors.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0WDYT?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Thanks for the continuing=C2=A0discussion.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The concept will work but it feels a bit over-= engineered.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0It is not, it is quite simple.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0> The approach of ignoring save-window-excursion= and display-func via
>=C2=A0 =C2=A0 =C2=A0> bookmark-record entries or using properties on= the handler seem less
>=C2=A0 =C2=A0 =C2=A0> intrusive or a mix,=C2=A0if we feel that's= appropriate.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0I proposed this solution to help you cleaning up yo= ur code which is full
>=C2=A0 =C2=A0 =C2=A0of workarounds for the current behavior (prior 31).= =C2=A0 Of course if you
>=C2=A0 =C2=A0 =C2=A0don't want to make an effort to update your cod= e, what you propose is
>=C2=A0 =C2=A0 =C2=A0simpler (i.e. you have nothing to change on your si= de), but generally we
>=C2=A0 =C2=A0 =C2=A0(external emacs extensions developers) try to adapt= ourselves to Emacs
>=C2=A0 =C2=A0 =C2=A0source and not the contrary.
>
> Thanks for the input.
>
> The idea that I "don't want to make an effort" is insult= ing.

Sorry if you take it like this, it was not the intention.

> =C2=A0 Perhaps a little less coffee.

I don't drink coffee.

>=C2=A0 =C2=A0 =C2=A0> Why not just fix the eww bookmark handler to d= o its own
>=C2=A0 =C2=A0 =C2=A0> save-window-excursion, again, rather than make= a default bookmark jump
>=C2=A0 =C2=A0 =C2=A0> behavior policy change?
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0Because the problem is not just about eww, but more= generally on how
>=C2=A0 =C2=A0 =C2=A0bookmark handlers work.
>
> Curious to know which other ones are broken?=C2=A0 I read eww and w3m.=

It is not only about eww AND w3m.=C2=A0 The point is not if things are brok= en
or not, it is to provide a good API for all bookmarks (and future kind
of bookmarks).


> What do the Emacs maintainers think about this as a matter of taste, > easy adoption for other bookmark users, and idiomatic usage?

Now Eli and other maintainers will decide what is the best for emacs.

You may not have seen it but there is already precedent for boo= kmark-handler properties in bookmark.el in bookmark-insert for the 'boo= kmark-inhibit property on a handler.=C2=A0 It could contain a list of inhib= itions.
<= br>

<= /div>
--00000000000015a85b0630a065cf-- From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 18 14:13:07 2025 Received: (at submit) by debbugs.gnu.org; 18 Mar 2025 18:13:07 +0000 Received: from localhost ([127.0.0.1]:43179 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tubR4-0002Rv-1M for submit@debbugs.gnu.org; Tue, 18 Mar 2025 14:13:07 -0400 Received: from lists.gnu.org ([2001:470:142::17]:38744) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tubQs-0002Pf-V4 for submit@debbugs.gnu.org; Tue, 18 Mar 2025 14:13:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tubQm-00020X-GL for bug-gnu-emacs@gnu.org; Tue, 18 Mar 2025 14:12:48 -0400 Received: from mail-ua1-x936.google.com ([2607:f8b0:4864:20::936]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tubQj-0000Hp-GJ; Tue, 18 Mar 2025 14:12:48 -0400 Received: by mail-ua1-x936.google.com with SMTP id a1e0cc1a2514c-86911fd168dso2240144241.1; Tue, 18 Mar 2025 11:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742321564; x=1742926364; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=VZU6EoDk0bR0KuYC2cc2V17XLDGsgL+68/+wjIJ5erU=; b=VvQFOQy7Ka5gBkbc76mEvQ3TET0qVTK4j05hsc8n98QjBBwC+rhd4R8E0h8LUe7WLr XhsiRdkELCXzvd5v72vdy4jKR0kzmDfYsU6g1qaxS4yzSYFTz+90r2YF6q5IX2zlljEc eav/tsaI8oDYjMz8oD0uDH35otBd2D6GMeFKdckmjOIAyQal7xrYYQD6EssBFfo7A0dG 1s7nEDqh95RAWGzzQf+Y3xB6H8mD3gXoyCsDqaIBGtVocrrBCQpn9hDGPeaYvjfpiuAx Bktroh/E5iTD1ROFBw1nTBfoY+enmFQPttpyhCgFX99khyxdvJY/5thm0gmKB6Wd1IOi Xe1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742321564; x=1742926364; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VZU6EoDk0bR0KuYC2cc2V17XLDGsgL+68/+wjIJ5erU=; b=ai5zP9/rjN0/wk3mKHAFxfCPM9JI24eUEWc1dMYnu+UOYniaRYCRLcZkj6aDrwbrKY ZI65MgyqUy7e4eD9huMKBb1e969Sv2G1hYo4lLpejsSNzOOG2ZR2wSFRkf/1yjN9ZBd/ LHouTiY/bKRaIsQJMS7cgZUcNcJYxbQ/u9FjInySwmLmNyUxFb8s6yPuyT4U9Ak1RKN+ d3tyB8Gn8rEw2QRqPAL1qkT7GsPcKgtCKhGunKylg3h14XbBAZvRHc47/8xYIPqdFfMF cQ1vfmj+G41D12KrXP3NzLY/OyF75VFLQhgn66elTN3Aeu+6hYfFecn9tccQZAjQjtz3 Hjyg== X-Forwarded-Encrypted: i=1; AJvYcCUis1DLdcNNyZcXffOkPZcPlH6vODwajyzeGsAxWf9Ffhj+1h5sH0Y4ETBddNVFwy3p2VUykjNCiHFiXwu/@gnu.org X-Gm-Message-State: AOJu0YxId+CGBoRMrufTxLSHjVzoC2PqhLlBpI8urx5X/zd8HKTLsoqF S2SLls9CERC1IsJAE6e5coq2gGu3HapB/kViP+sugaWOnvfLmtFh+UUvAnSzO0Dx69hjP7vFj56 T0Bfw7CJHp+S5+Va9O/qZf+C2xsAiiA== X-Gm-Gg: ASbGncu+SbGuvAxTVKuSkWO1S9IgrJ2iHn2Oyo+RBHLqJwNZ2VGakFxa9ujVsZyunKB iK2WWhsfsEqwke2jv4jzhOrHyvApdS9gQDk4SvIz9g3nm5HzQ2fElnrAbUhTfryUQFbz+GbGM8N SI3ZSi24vVXIbWcbvRf1oL6rA5PH+iowAMFsGbCQrcOX+1J37AzBsE/4N9 X-Google-Smtp-Source: AGHT+IGG+Lh6o9WFQ2bkGqvH9nA+dcuoFrinX0Jeo9l9hM8GS+zFDQQoFsoc2e4IETcPDShABeWBAMoEqbgBHdoJWx8= X-Received: by 2002:a05:6102:5126:b0:4ba:974c:891e with SMTP id ada2fe7eead31-4c3831f882emr12053182137.17.1742321563885; Tue, 18 Mar 2025 11:12:43 -0700 (PDT) MIME-Version: 1.0 References: <874izwn306.fsf@posteo.net> <87y0x8kyaq.fsf@posteo.net> <877c4r6cok.fsf@posteo.net> <871puy6e5x.fsf@posteo.net> <87v7s6om6i.fsf@posteo.net> <87ecyul5xg.fsf@posteo.net> <878qp2l41h.fsf@posteo.net> In-Reply-To: From: Ship Mints Date: Tue, 18 Mar 2025 14:12:32 -0400 X-Gm-Features: AQ5f1JoMRJFzINH73w1PPg_rTgVqYC6771Ut0IXF2XOji7SSY45ViqqaxaQWgog Message-ID: Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) To: Thierry Volpiatto Content-Type: multipart/alternative; boundary="000000000000e668590630a1d9d6" Received-SPF: pass client-ip=2607:f8b0:4864:20::936; envelope-from=shipmints@gmail.com; helo=mail-ua1-x936.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --000000000000e668590630a1d9d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 18, 2025 at 12:28 Ship Mints wrote: > > On Tue, Mar 18, 2025 at 11:55=E2=80=AFAM Thierry Volpiatto > wrote: > >> Ship Mints writes: >> >> > 1. ( ) text/plain (*) text/html >> > >> > On Tue, Mar 18, 2025 at 11:15=E2=80=AFAM Thierry Volpiatto >> wrote: >> > >> > Ship Mints writes: >> > >> > > 1. ( ) text/plain (*) text/html >> > > >> > > On Tue, Mar 18, 2025 at 2:55=E2=80=AFAM Thierry Volpiatto < >> thievol@posteo.net> wrote: >> > > >> > > Sorry for late reply, was busy. >> > > >> > > Ship Mints writes: >> > > >> > > > On Sun, Mar 16, 2025 at 5:10=E2=80=AFPM Ship Mints < >> shipmints@gmail.com> wrote: >> > > > >> > > > On Sat, Mar 15, 2025 at 10:18=E2=80=AFAM Ship Mints < >> shipmints@gmail.com> wrote: >> > > > >> > > > On Sat, Mar 15, 2025 at 1:37=E2=80=AFAM Thierry Vo= lpiatto < >> thievol@posteo.net> wrote: >> > > > >> > > > Ship Mints writes: >> > > > >> > > > > I have workarounds that work only for the >> most simplistic cases. Many >> > > > > of our bookmarks themselves contain embedded >> bookmarks and bookmark >> > > > > references (which are individually >> addressable so can be used >> > > > > separately) with window-states we need to >> restore in tab-bar tabs that >> > > > > they represent. >> > > > >> > > > I don't really understand what your packages >> are doing or are intended >> > > > doing, but FWICS in bufferlo: You are using in >> some places >> > > > (bookmark-jump name #'ignore); why don't you d= o >> all this work (restore >> > > > window-states in tab) in DISPLAY-FUNCTION >> instead of using `ignore`? >> > > > Your handler would be much simpler by moving >> the window-state-put and >> > > > alike calls in DISPLAY-FUNCTION: >> > > > >> > > > (bookmark-jump name >> #'your_function_restoring_window_or_frame_state) >> > > > >> > > > Using (bookmark-jump name #'ignore) with all >> the code that jump to >> > > > frame/tab etc... in the handler is just a >> workaround to fix the previous >> > > > buggy behavior of bookmark--jump-via. IMO. >> > > > >> > > > It would be good to start with a good example >> or recipe to see if we can >> > > > find a good solution. >> > > > >> > > > We need the bookmarks to work from the bookmark >> menu where no display-function overrides are supported. >> > > > >> > > > I suggest we add bookmark-record keys that indicat= e >> to bookmark-jump to inhibit/or allow messing with window-configurations. >> The bufferlo bookmarks (and Adam's if he >> > wants) >> > > would >> > > > contain these hint keys. >> > > > >> > > > '(bookmark-jump-inhibit-window-actions . t) ; or >> whatever we come up with >> > > > >> > > > I can contrive an example, if necessary, but I >> believe y'all get the point. Nested bookmarks whose handlers expect the= ir >> window-configurations not to be messed with up >> > the >> > > > chain, will always be broken without additional >> controls. >> > > > >> > > > The attached patch implements such a scheme that works >> for us, and is transparent to other bookmark uses. >> > > > >> > > > Perhaps we should restore bookmark--jump-via to its >> previous behavior >> > > > and better document the "rules of the road" for bookmark >> handlers. >> > > > For simple file- and point-based bookmarks, handlers need >> to ensure >> > > > that when they return, the selected window and current >> buffer are >> > > > what's intended. For bookmark handlers that perform other >> actions, >> > > > those rules need not apply to leverage the bookmark >> infrastructure. >> > > >> > > What we could do is propose a more flexible solution so that >> you could >> > > use whatever you want for bookmark--jump-via; With what you >> have proposed so >> > > far, you still have the problem of DISPLAY-FUNCTION which >> will always >> > > run (I see there is comments about this problem in your >> mentionned >> > > packages), with the patch below you could define a >> display-function >> > > entry in your bookmark-record e.g. (display-function . >> ignore) and then >> > > add a special method for bookmark--jump-via: >> > > >> > > (cl-defmethod bookmark--jump-via (bookmark-name-or-record (_ >> (eql 'ignore))) >> > > (do_watever_you_want_here)) ; e.g. run only the handler fn= . >> > > >> > > NOTE: I used 'ignore as example but you could use whatever >> you want. >> > > >> > > Here the patch: >> > > >> > > diff --git a/lisp/bookmark.el b/lisp/bookmark.el >> > > index 99bb26e83cc..e594387f364 100644 >> > > --- a/lisp/bookmark.el >> > > +++ b/lisp/bookmark.el >> > > @@ -1259,7 +1259,7 @@ it to the name of the bookmark >> currently being set, advancing >> > > "Hook run after `bookmark-jump' jumps to a bookmark. >> > > Useful for example to unhide text in `outline-mode'.") >> > > >> > > -(defun bookmark--jump-via (bookmark-name-or-record >> display-function) >> > > +(cl-defgeneric bookmark--jump-via (bookmark-name-or-record >> display-function) >> > > "Handle BOOKMARK-NAME-OR-RECORD, then call >> DISPLAY-FUNCTION. >> > > DISPLAY-FUNCTION is called with the new buffer as argument. >> > > >> > > @@ -1319,8 +1319,12 @@ DISPLAY-FUNC would be >> `switch-to-buffer-other-window'." >> > > ;; Don't use `switch-to-buffer' because it would let the >> > > ;; window-point override the bookmark's point when >> > > ;; `switch-to-buffer-preserve-window-point' is non-nil. >> > > - (bookmark--jump-via bookmark (or display-func >> 'pop-to-buffer-same-window))) >> > > + (bookmark-jump-1 bookmark display-func)) >> > > >> > > +(defun bookmark-jump-1 (bookmark display-func) >> > > + (let ((dfn (or (bookmark-prop-get bookmark >> 'display-function) >> > > + display-func 'pop-to-buffer-same-window))) >> > > + (bookmark--jump-via bookmark dfn))) >> > > >> > > ;;;###autoload >> > > (defun bookmark-jump-other-window (bookmark) >> > > @@ -2303,7 +2307,7 @@ the related behaviors of >> `bookmark-save' and `bookmark-bmenu-save'." >> > > (pop-up-windows t)) >> > > (delete-other-windows) >> > > (switch-to-buffer (other-buffer) nil t) >> > > - (bookmark--jump-via bmrk 'pop-to-buffer) >> > > + (bookmark-jump-1 bmrk 'pop-to-buffer) >> > > (bury-buffer menu))) >> > > >> > > @@ -2317,7 +2321,7 @@ the related behaviors of >> `bookmark-save' and `bookmark-bmenu-save'." >> > > "Select this line's bookmark in other window, leaving >> bookmark menu visible." >> > > (interactive nil bookmark-bmenu-mode) >> > > (let ((bookmark (bookmark-bmenu-bookmark))) >> > > - (bookmark--jump-via bookmark >> 'switch-to-buffer-other-window))) >> > > + (bookmark-jump-1 bookmark >> 'switch-to-buffer-other-window))) >> > > >> > > (defun bookmark-bmenu-other-frame () >> > > @@ -2333,7 +2337,7 @@ The current window remains selected." >> > > (interactive nil bookmark-bmenu-mode) >> > > (let ((bookmark (bookmark-bmenu-bookmark)) >> > > (fun (lambda (b) (display-buffer b t)))) >> > > - (bookmark--jump-via bookmark fun))) >> > > + (bookmark-jump-1 bookmark fun))) >> > > >> > > (defun bookmark-bmenu-other-window-with-mouse (event) >> > > "Jump to bookmark at mouse EVENT position in other window= . >> > > >> > > Also I guess trying to call bookmark-jump-other-window and >> friends is >> > > failing with your special bookmarks, with this it would run >> just as >> > > bookmark-jump without (possible) errors. >> > > >> > > WDYT? >> > > >> > > Thanks for the continuing discussion. >> > > >> > > The concept will work but it feels a bit over-engineered. >> > >> > It is not, it is quite simple. >> > >> > > The approach of ignoring save-window-excursion and display-func >> via >> > > bookmark-record entries or using properties on the handler seem >> less >> > > intrusive or a mix, if we feel that's appropriate. >> > >> > I proposed this solution to help you cleaning up your code which i= s >> full >> > of workarounds for the current behavior (prior 31). Of course if >> you >> > don't want to make an effort to update your code, what you propose >> is >> > simpler (i.e. you have nothing to change on your side), but >> generally we >> > (external emacs extensions developers) try to adapt ourselves to >> Emacs >> > source and not the contrary. >> > >> > Thanks for the input. >> > >> > The idea that I "don't want to make an effort" is insulting. >> >> Sorry if you take it like this, it was not the intention. >> >> > Perhaps a little less coffee. >> >> I don't drink coffee. >> >> > > Why not just fix the eww bookmark handler to do its own >> > > save-window-excursion, again, rather than make a default bookmar= k >> jump >> > > behavior policy change? >> > >> > Because the problem is not just about eww, but more generally on h= ow >> > bookmark handlers work. >> > >> > Curious to know which other ones are broken? I read eww and w3m. >> >> It is not only about eww AND w3m. The point is not if things are broken >> or not, it is to provide a good API for all bookmarks (and future kind >> of bookmarks). >> >> >> > What do the Emacs maintainers think about this as a matter of taste, >> > easy adoption for other bookmark users, and idiomatic usage? >> >> Now Eli and other maintainers will decide what is the best for emacs. >> > > You may not have seen it but there is already precedent for > bookmark-handler properties in bookmark.el in bookmark-insert for the > 'bookmark-inhibit property on a handler. It could contain a list of > inhibitions. > I'll submit a patch to make that property into a list. It was my code to begin with and used only in shell-bookmark and I should have planned ahead. Even if we don't use it for the above purposes. > > > --000000000000e668590630a1d9d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Mar 18, 2025 at 12:28 Ship Mints <shipmints@gmail.com> wrote:
<= div dir=3D"ltr">

<= div class=3D"gmail_quote">
On Tue, Mar= 18, 2025 at 11:55=E2=80=AFAM Thierry Volpiatto <thievol@posteo.net> wrote:
Ship Mints <shipmints@gmail.com&g= t; writes:

> 1.=C2=A0 ( ) text/plain=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (*) text/htm= l=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>
> On Tue, Mar 18, 2025 at 11:15=E2=80=AFAM Thierry Volpiatto <thievol@posteo.net>= wrote:
>
>=C2=A0 =C2=A0 =C2=A0Ship Mints <shipmints@gmail.com> writes:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0> 1.=C2=A0 ( ) text/plain=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 (*) text/html=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Tue, Mar 18, 2025 at 2:55=E2=80=AFAM Thierr= y Volpiatto <thi= evol@posteo.net> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Sorry for late reply, was b= usy.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Ship Mints <shipmints@gmail.com> wr= ites:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> On Sun, Mar 16, 2025 a= t 5:10=E2=80=AFPM Ship Mints <shipmints@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0On = Sat, Mar 15, 2025 at 10:18=E2=80=AFAM Ship Mints <shipmints@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0On Sat, Mar 15, 2025 at 1:37=E2=80=AFAM Thierry Volpiatto <= thievol@posteo.net<= /a>> wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Ship Mints <shipmints@gmail.com> writes:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> I have workarounds that work only for the m= ost simplistic cases.=C2=A0 Many
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> of our=C2=A0bookmarks themselves contain em= bedded bookmarks and bookmark
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> references (which are individually addressa= ble so can be used
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> separately) with window-states we need to r= estore in tab-bar tabs that
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> they represent.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0I don't really understand what your packages= are doing or are intended
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0doing, but FWICS in bufferlo: You are using in s= ome places
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0(bookmark-jump name #'ignore); why don't= you do all this work (restore
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0window-states in tab) in DISPLAY-FUNCTION instea= d of using `ignore`?
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Your handler would be much simpler by moving the= window-state-put and
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0alike calls in DISPLAY-FUNCTION:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0(bookmark-jump name #'your_function_restorin= g_window_or_frame_state)=C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Using (bookmark-jump name #'ignore) with all= the code that jump to
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0frame/tab etc... in the handler is just a workar= ound to fix the previous
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0buggy behavior of bookmark--jump-via. IMO.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0It would be good to start with a good example or= recipe to see if we can
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0find a good solution.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0We need the bookmarks to work from the bookmark menu where no = display-function overrides are supported.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0I suggest we add bookmark-record keys that indicate to bookmar= k-jump to inhibit/or allow messing with window-configurations.=C2=A0 The bu= fferlo bookmarks (and Adam's if he
>=C2=A0 =C2=A0 =C2=A0wants)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0would
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0contain these hint keys.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0'(bookmark-jump-inhibit-window-actions . t) ; or whatever = we come up with
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0I can contrive an example, if necessary, but I believe y'a= ll get the point.=C2=A0 Nested bookmarks whose handlers expect their window= -configurations not to be messed with up
>=C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0chain,=C2=A0will always be broken without additional controls.=
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0The= attached patch implements such a scheme that works for us, and is transpar= ent to other=C2=A0bookmark=C2=A0uses.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Perhaps we should rest= ore bookmark--jump-via to its previous behavior
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> and better document th= e "rules of the road" for bookmark handlers.=C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> For simple file- and p= oint-based bookmarks, handlers need to ensure
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> that when they return,= the selected window and current buffer are
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> what's intended.= =C2=A0 For bookmark handlers that perform other actions,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> those rules need not a= pply to leverage the bookmark infrastructure.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0What we could do is propose= a more flexible solution so that you could
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0use whatever you want for b= ookmark--jump-via; With what you have proposed so
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0far, you still have the pro= blem of DISPLAY-FUNCTION which will always
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0run (I see there is comment= s about this problem in your mentionned
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0packages), with the patch b= elow you could define a display-function
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0entry in your bookmark-reco= rd e.g. (display-function . ignore) and then
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0add a special method for bo= okmark--jump-via:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0(cl-defmethod bookmark--jum= p-via (bookmark-name-or-record (_ (eql 'ignore)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 (do_watever_you_want= _here)) ; e.g. run only the handler fn.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0NOTE: I used 'ignore as= example but you could use whatever you want.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Here the patch:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0diff --git a/lisp/bookmark.= el b/lisp/bookmark.el
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0index 99bb26e83cc..e594387f= 364 100644
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--- a/lisp/bookmark.el
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+++ b/lisp/bookmark.el
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0@@ -1259,7 +1259,7 @@ it to= the name of the bookmark currently being set, advancing
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0"Hook run= after `bookmark-jump' jumps to a bookmark.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0Useful for example to= unhide text in `outline-mode'.")
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-(defun bookmark--jump-via = (bookmark-name-or-record display-function)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+(cl-defgeneric bookmark--j= ump-via (bookmark-name-or-record display-function)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0"Handle B= OOKMARK-NAME-OR-RECORD, then call DISPLAY-FUNCTION.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0DISPLAY-FUNCTION is c= alled with the new buffer as argument.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0@@ -1319,8 +1319,12 @@ DISP= LAY-FUNC would be `switch-to-buffer-other-window'."
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0;; Don't u= se `switch-to-buffer' because it would let the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0;; window-poin= t override the bookmark's point when
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0;; `switch-to-= buffer-preserve-window-point' is non-nil.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-=C2=A0 (bookmark--jump-via= bookmark (or display-func 'pop-to-buffer-same-window)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 (bookmark-jump-1 bo= okmark display-func))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+(defun bookmark-jump-1 (bo= okmark display-func)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 (let ((dfn (or (boo= kmark-prop-get bookmark 'display-function)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0display-func 'pop-to-buffer-same-= window)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 (bookmark--j= ump-via bookmark dfn)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0;;;###autoload
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0(defun bookmark-jump-= other-window (bookmark)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0@@ -2303,7 +2307,7 @@ the r= elated behaviors of `bookmark-save' and `bookmark-bmenu-save'."= ;
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0(pop-up-windows t))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0(delete= -other-windows)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0(switch= -to-buffer (other-buffer) nil t)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0 (bookmark--j= ump-via bmrk 'pop-to-buffer)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 (bookmark-ju= mp-1 bmrk 'pop-to-buffer)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0(bury-b= uffer menu)))
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0@@ -2317,7 +2321,7 @@ the r= elated behaviors of `bookmark-save' and `bookmark-bmenu-save'."= ;
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0"Select t= his line's bookmark in other window, leaving bookmark menu visible.&quo= t;
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(interactive n= il bookmark-bmenu-mode)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(let ((bookmar= k (bookmark-bmenu-bookmark)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0 (bookmark--j= ump-via bookmark 'switch-to-buffer-other-window)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 (bookmark-ju= mp-1 bookmark 'switch-to-buffer-other-window)))
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0(defun bookmark-bmenu= -other-frame ()
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0@@ -2333,7 +2337,7 @@ The c= urrent window remains selected."
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(interactive n= il bookmark-bmenu-mode)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(let ((bookmar= k (bookmark-bmenu-bookmark))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0= (fun (lambda (b) (display-buffer b t))))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0 (bookmark--j= ump-via bookmark fun)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 (bookmark-ju= mp-1 bookmark fun)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0(defun bookmark-bmenu= -other-window-with-mouse (event)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0"Jump to = bookmark at mouse EVENT position in other window.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Also I guess trying to call= bookmark-jump-other-window and friends is
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0failing with your special b= ookmarks, with this it would run just as
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0bookmark-jump without (poss= ible) errors.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0WDYT?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Thanks for the continuing=C2=A0discussion.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The concept will work but it feels a bit over-= engineered.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0It is not, it is quite simple.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0> The approach of ignoring save-window-excursion= and display-func via
>=C2=A0 =C2=A0 =C2=A0> bookmark-record entries or using properties on= the handler seem less
>=C2=A0 =C2=A0 =C2=A0> intrusive or a mix,=C2=A0if we feel that's= appropriate.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0I proposed this solution to help you cleaning up yo= ur code which is full
>=C2=A0 =C2=A0 =C2=A0of workarounds for the current behavior (prior 31).= =C2=A0 Of course if you
>=C2=A0 =C2=A0 =C2=A0don't want to make an effort to update your cod= e, what you propose is
>=C2=A0 =C2=A0 =C2=A0simpler (i.e. you have nothing to change on your si= de), but generally we
>=C2=A0 =C2=A0 =C2=A0(external emacs extensions developers) try to adapt= ourselves to Emacs
>=C2=A0 =C2=A0 =C2=A0source and not the contrary.
>
> Thanks for the input.
>
> The idea that I "don't want to make an effort" is insult= ing.

Sorry if you take it like this, it was not the intention.

> =C2=A0 Perhaps a little less coffee.

I don't drink coffee.

>=C2=A0 =C2=A0 =C2=A0> Why not just fix the eww bookmark handler to d= o its own
>=C2=A0 =C2=A0 =C2=A0> save-window-excursion, again, rather than make= a default bookmark jump
>=C2=A0 =C2=A0 =C2=A0> behavior policy change?
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0Because the problem is not just about eww, but more= generally on how
>=C2=A0 =C2=A0 =C2=A0bookmark handlers work.
>
> Curious to know which other ones are broken?=C2=A0 I read eww and w3m.=

It is not only about eww AND w3m.=C2=A0 The point is not if things are brok= en
or not, it is to provide a good API for all bookmarks (and future kind
of bookmarks).


> What do the Emacs maintainers think about this as a matter of taste, > easy adoption for other bookmark users, and idiomatic usage?

Now Eli and other maintainers will decide what is the best for emacs.

You may= not have seen it but there is already precedent for bookmark-handler prope= rties in bookmark.el in bookmark-insert for the 'bookmark-inhibit prope= rty on a handler.=C2=A0 It could contain a list of inhibitions.

I'll submit a = patch to make that property into a list.=C2=A0 It was my code to begin with= and used only in shell-bookmark and I should have planned ahead. Even if w= e don't use it for the above purposes.=C2=A0

=
=

--000000000000e668590630a1d9d6-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 24 15:16:52 2025 Received: (at submit) by debbugs.gnu.org; 24 Mar 2025 19:16:52 +0000 Received: from localhost ([127.0.0.1]:58625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1twnI3-0004GS-6B for submit@debbugs.gnu.org; Mon, 24 Mar 2025 15:16:52 -0400 Received: from lists.gnu.org ([2001:470:142::17]:37244) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1twnHz-0004Eo-Ud for submit@debbugs.gnu.org; Mon, 24 Mar 2025 15:16:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1twnHr-00011c-7F for bug-gnu-emacs@gnu.org; Mon, 24 Mar 2025 15:16:40 -0400 Received: from mail-vk1-xa2e.google.com ([2607:f8b0:4864:20::a2e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1twnHm-0003tq-N1; Mon, 24 Mar 2025 15:16:38 -0400 Received: by mail-vk1-xa2e.google.com with SMTP id 71dfb90a1353d-5240a432462so4529956e0c.1; Mon, 24 Mar 2025 12:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742843792; x=1743448592; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qQChXnlqZUJakWeYoF+kF9WALhtNKJ+v4KpM8vo+FA0=; b=NiEw57XjpGlPMFV4P63E8cgv8ho4spB2oGUC1SmhUBVOM4jSfKZ7D2Q+7z1YCv2wRL QpuTBrcMTTUHD4Eex4jHLcrPk3xaR8veIqWy/lOi1wNBhAxfLZYmm1JAXXjFzJeqHi5/ gTKvwQKFwwBDE2kmfTsxCLIC+AOPwAHHIHkFLtHdr6UpBn/4MefNSkjDUzdRsFcHM+rg 1MR1XPdWbAnqNGA0BFjFuNaJH6FGgivYJKJadwS7THBqdmvVm9ErJ5ADIEYFvMVvqbm8 CYLvaJ00dTPp6qR8ulbbKQITDKPcTfq/xMN734k4wOfmV+SLk2R96t3y0XeNqUp82GYV lPOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742843792; x=1743448592; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qQChXnlqZUJakWeYoF+kF9WALhtNKJ+v4KpM8vo+FA0=; b=X10wGFptebg3ZD8wbc2XCoMoS0Gax2A1TQgCvt9lGs5wmWBfXz+jxmDVipHsMH3seA hPcw5Kem4RpYr+o5+8dZe+goi7/lzATVun6jOV9wsCFtd8dekQ1JmsINaylxbq9sn508 ZOrw3XHgxXu3MDArlHsPCjJ1LL6wHVPk9wCKuhdspDMjrO/c1zSyxeHcs+qS744mxogt JUJapsKe7c/lMQZS+R6K3wegOaRzZKgjiuE6sTunEmFUvm4Z1CPgqa3m7sIQU0qDRuKY 2fq5aiI1IhiOh7XJApjPL/eNso/fh2+5QCEiqdRTNs2BVzcGRK90PyOuRQ9jKKnjt3YH oRew== X-Forwarded-Encrypted: i=1; AJvYcCVzVbTejzbK46HW/xThtYPKCEcPUwD2cLLeNgoWZN7w7t7g/+TA330D597PmkMiAoeFe8BqM482UxsRiU/l@gnu.org X-Gm-Message-State: AOJu0YwLUWRvt8rU1YTRJlDdyMjoitvwBHjrpKaQgJQPQbJ9JZ0kzcFT scv0u6XaZEWggM1hvprPc7huXQHn/F+rT7ZcoGh1PRQ7zqPpiVkf6hW8GjbTgNLoVyOFTkx24Ws 6URIY+zSEDrE1SGb9MRsdfS409C5zU7PJ X-Gm-Gg: ASbGncspG2lzJ2qkMq7pB+Kf5R7t1O3YgqsLOwRE2jl9A4jlOhyteR/LfoqOzJ+ahbr CivEA3+bb8i/56dDET9VFSe6qCS2wCO9ldMqD6FZxX1Va5VepzC3GA91gaiamegYntnAzDWKOT2 1NL/Z3Y7KteOTHOs4QdHA7/ISY+A== X-Google-Smtp-Source: AGHT+IGIOCt8C+DfwgPjcbXAcz6xOcPOqOni1d9ElyF+Po8FUgHtU2pwiXejFOU86o6US6MdfrbhHu/tIJK/0egeI7A= X-Received: by 2002:a05:6122:91d:b0:523:e4c6:dddb with SMTP id 71dfb90a1353d-52595bca08fmr15423934e0c.0.1742843791745; Mon, 24 Mar 2025 12:16:31 -0700 (PDT) MIME-Version: 1.0 References: <874izwn306.fsf@posteo.net> <87y0x8kyaq.fsf@posteo.net> <877c4r6cok.fsf@posteo.net> <871puy6e5x.fsf@posteo.net> <87v7s6om6i.fsf@posteo.net> <87ecyul5xg.fsf@posteo.net> <878qp2l41h.fsf@posteo.net> In-Reply-To: From: Ship Mints Date: Mon, 24 Mar 2025 15:16:20 -0400 X-Gm-Features: AQ5f1JpksvzVats45Vt1wJVNnzBLbEOoj4s9mjSMMQiZopK8Uqml-2lvVSpbBxY Message-ID: Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) To: Thierry Volpiatto Content-Type: multipart/mixed; boundary="0000000000001b50e906311b71f9" Received-SPF: pass client-ip=2607:f8b0:4864:20::a2e; envelope-from=shipmints@gmail.com; helo=mail-vk1-xa2e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --0000000000001b50e906311b71f9 Content-Type: multipart/alternative; boundary="0000000000001b50e806311b71f7" --0000000000001b50e806311b71f7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 18, 2025 at 2:12=E2=80=AFPM Ship Mints wr= ote: > On Tue, Mar 18, 2025 at 12:28 Ship Mints wrote: > >> >> On Tue, Mar 18, 2025 at 11:55=E2=80=AFAM Thierry Volpiatto >> wrote: >> >>> Ship Mints writes: >>> >>> > 1. ( ) text/plain (*) text/html >>> > >>> > On Tue, Mar 18, 2025 at 11:15=E2=80=AFAM Thierry Volpiatto >>> wrote: >>> > >>> > Ship Mints writes: >>> > >>> > > 1. ( ) text/plain (*) text/html >>> > > >>> > > On Tue, Mar 18, 2025 at 2:55=E2=80=AFAM Thierry Volpiatto < >>> thievol@posteo.net> wrote: >>> > > >>> > > Sorry for late reply, was busy. >>> > > >>> > > Ship Mints writes: >>> > > >>> > > > On Sun, Mar 16, 2025 at 5:10=E2=80=AFPM Ship Mints < >>> shipmints@gmail.com> wrote: >>> > > > >>> > > > On Sat, Mar 15, 2025 at 10:18=E2=80=AFAM Ship Mints < >>> shipmints@gmail.com> wrote: >>> > > > >>> > > > On Sat, Mar 15, 2025 at 1:37=E2=80=AFAM Thierry V= olpiatto < >>> thievol@posteo.net> wrote: >>> > > > >>> > > > Ship Mints writes: >>> > > > >>> > > > > I have workarounds that work only for the >>> most simplistic cases. Many >>> > > > > of our bookmarks themselves contain embedde= d >>> bookmarks and bookmark >>> > > > > references (which are individually >>> addressable so can be used >>> > > > > separately) with window-states we need to >>> restore in tab-bar tabs that >>> > > > > they represent. >>> > > > >>> > > > I don't really understand what your packages >>> are doing or are intended >>> > > > doing, but FWICS in bufferlo: You are using i= n >>> some places >>> > > > (bookmark-jump name #'ignore); why don't you >>> do all this work (restore >>> > > > window-states in tab) in DISPLAY-FUNCTION >>> instead of using `ignore`? >>> > > > Your handler would be much simpler by moving >>> the window-state-put and >>> > > > alike calls in DISPLAY-FUNCTION: >>> > > > >>> > > > (bookmark-jump name >>> #'your_function_restoring_window_or_frame_state) >>> > > > >>> > > > Using (bookmark-jump name #'ignore) with all >>> the code that jump to >>> > > > frame/tab etc... in the handler is just a >>> workaround to fix the previous >>> > > > buggy behavior of bookmark--jump-via. IMO. >>> > > > >>> > > > It would be good to start with a good example >>> or recipe to see if we can >>> > > > find a good solution. >>> > > > >>> > > > We need the bookmarks to work from the bookmark >>> menu where no display-function overrides are supported. >>> > > > >>> > > > I suggest we add bookmark-record keys that >>> indicate to bookmark-jump to inhibit/or allow messing with >>> window-configurations. The bufferlo bookmarks (and Adam's if he >>> > wants) >>> > > would >>> > > > contain these hint keys. >>> > > > >>> > > > '(bookmark-jump-inhibit-window-actions . t) ; or >>> whatever we come up with >>> > > > >>> > > > I can contrive an example, if necessary, but I >>> believe y'all get the point. Nested bookmarks whose handlers expect th= eir >>> window-configurations not to be messed with up >>> > the >>> > > > chain, will always be broken without additional >>> controls. >>> > > > >>> > > > The attached patch implements such a scheme that work= s >>> for us, and is transparent to other bookmark uses. >>> > > > >>> > > > Perhaps we should restore bookmark--jump-via to its >>> previous behavior >>> > > > and better document the "rules of the road" for bookmark >>> handlers. >>> > > > For simple file- and point-based bookmarks, handlers need >>> to ensure >>> > > > that when they return, the selected window and current >>> buffer are >>> > > > what's intended. For bookmark handlers that perform othe= r >>> actions, >>> > > > those rules need not apply to leverage the bookmark >>> infrastructure. >>> > > >>> > > What we could do is propose a more flexible solution so tha= t >>> you could >>> > > use whatever you want for bookmark--jump-via; With what you >>> have proposed so >>> > > far, you still have the problem of DISPLAY-FUNCTION which >>> will always >>> > > run (I see there is comments about this problem in your >>> mentionned >>> > > packages), with the patch below you could define a >>> display-function >>> > > entry in your bookmark-record e.g. (display-function . >>> ignore) and then >>> > > add a special method for bookmark--jump-via: >>> > > >>> > > (cl-defmethod bookmark--jump-via (bookmark-name-or-record (= _ >>> (eql 'ignore))) >>> > > (do_watever_you_want_here)) ; e.g. run only the handler f= n. >>> > > >>> > > NOTE: I used 'ignore as example but you could use whatever >>> you want. >>> > > >>> > > Here the patch: >>> > > >>> > > diff --git a/lisp/bookmark.el b/lisp/bookmark.el >>> > > index 99bb26e83cc..e594387f364 100644 >>> > > --- a/lisp/bookmark.el >>> > > +++ b/lisp/bookmark.el >>> > > @@ -1259,7 +1259,7 @@ it to the name of the bookmark >>> currently being set, advancing >>> > > "Hook run after `bookmark-jump' jumps to a bookmark. >>> > > Useful for example to unhide text in `outline-mode'.") >>> > > >>> > > -(defun bookmark--jump-via (bookmark-name-or-record >>> display-function) >>> > > +(cl-defgeneric bookmark--jump-via (bookmark-name-or-record >>> display-function) >>> > > "Handle BOOKMARK-NAME-OR-RECORD, then call >>> DISPLAY-FUNCTION. >>> > > DISPLAY-FUNCTION is called with the new buffer as argument= . >>> > > >>> > > @@ -1319,8 +1319,12 @@ DISPLAY-FUNC would be >>> `switch-to-buffer-other-window'." >>> > > ;; Don't use `switch-to-buffer' because it would let the >>> > > ;; window-point override the bookmark's point when >>> > > ;; `switch-to-buffer-preserve-window-point' is non-nil. >>> > > - (bookmark--jump-via bookmark (or display-func >>> 'pop-to-buffer-same-window))) >>> > > + (bookmark-jump-1 bookmark display-func)) >>> > > >>> > > +(defun bookmark-jump-1 (bookmark display-func) >>> > > + (let ((dfn (or (bookmark-prop-get bookmark >>> 'display-function) >>> > > + display-func 'pop-to-buffer-same-window))= ) >>> > > + (bookmark--jump-via bookmark dfn))) >>> > > >>> > > ;;;###autoload >>> > > (defun bookmark-jump-other-window (bookmark) >>> > > @@ -2303,7 +2307,7 @@ the related behaviors of >>> `bookmark-save' and `bookmark-bmenu-save'." >>> > > (pop-up-windows t)) >>> > > (delete-other-windows) >>> > > (switch-to-buffer (other-buffer) nil t) >>> > > - (bookmark--jump-via bmrk 'pop-to-buffer) >>> > > + (bookmark-jump-1 bmrk 'pop-to-buffer) >>> > > (bury-buffer menu))) >>> > > >>> > > @@ -2317,7 +2321,7 @@ the related behaviors of >>> `bookmark-save' and `bookmark-bmenu-save'." >>> > > "Select this line's bookmark in other window, leaving >>> bookmark menu visible." >>> > > (interactive nil bookmark-bmenu-mode) >>> > > (let ((bookmark (bookmark-bmenu-bookmark))) >>> > > - (bookmark--jump-via bookmark >>> 'switch-to-buffer-other-window))) >>> > > + (bookmark-jump-1 bookmark >>> 'switch-to-buffer-other-window))) >>> > > >>> > > (defun bookmark-bmenu-other-frame () >>> > > @@ -2333,7 +2337,7 @@ The current window remains selected." >>> > > (interactive nil bookmark-bmenu-mode) >>> > > (let ((bookmark (bookmark-bmenu-bookmark)) >>> > > (fun (lambda (b) (display-buffer b t)))) >>> > > - (bookmark--jump-via bookmark fun))) >>> > > + (bookmark-jump-1 bookmark fun))) >>> > > >>> > > (defun bookmark-bmenu-other-window-with-mouse (event) >>> > > "Jump to bookmark at mouse EVENT position in other windo= w. >>> > > >>> > > Also I guess trying to call bookmark-jump-other-window and >>> friends is >>> > > failing with your special bookmarks, with this it would run >>> just as >>> > > bookmark-jump without (possible) errors. >>> > > >>> > > WDYT? >>> > > >>> > > Thanks for the continuing discussion. >>> > > >>> > > The concept will work but it feels a bit over-engineered. >>> > >>> > It is not, it is quite simple. >>> > >>> > > The approach of ignoring save-window-excursion and display-func >>> via >>> > > bookmark-record entries or using properties on the handler seem >>> less >>> > > intrusive or a mix, if we feel that's appropriate. >>> > >>> > I proposed this solution to help you cleaning up your code which >>> is full >>> > of workarounds for the current behavior (prior 31). Of course if >>> you >>> > don't want to make an effort to update your code, what you propos= e >>> is >>> > simpler (i.e. you have nothing to change on your side), but >>> generally we >>> > (external emacs extensions developers) try to adapt ourselves to >>> Emacs >>> > source and not the contrary. >>> > >>> > Thanks for the input. >>> > >>> > The idea that I "don't want to make an effort" is insulting. >>> >>> Sorry if you take it like this, it was not the intention. >>> >>> > Perhaps a little less coffee. >>> >>> I don't drink coffee. >>> >>> > > Why not just fix the eww bookmark handler to do its own >>> > > save-window-excursion, again, rather than make a default >>> bookmark jump >>> > > behavior policy change? >>> > >>> > Because the problem is not just about eww, but more generally on >>> how >>> > bookmark handlers work. >>> > >>> > Curious to know which other ones are broken? I read eww and w3m. >>> >>> It is not only about eww AND w3m. The point is not if things are broke= n >>> or not, it is to provide a good API for all bookmarks (and future kind >>> of bookmarks). >>> >>> >>> > What do the Emacs maintainers think about this as a matter of taste, >>> > easy adoption for other bookmark users, and idiomatic usage? >>> >>> Now Eli and other maintainers will decide what is the best for emacs. >>> >> >> You may not have seen it but there is already precedent for >> bookmark-handler properties in bookmark.el in bookmark-insert for the >> 'bookmark-inhibit property on a handler. It could contain a list of >> inhibitions. >> > > I'll submit a patch to make that property into a list. It was my code to > begin with and used only in shell-bookmark and I should have planned ahea= d. > Even if we don't use it for the above purposes. > I've attached a patch to bookmark-jump/bookmark--jump-via that supports inhibiting window actions and display function using the 'bookmark-inhibit handler function property list that Michael Albinus pushed to master last week. Usage for bookmark handler authors is simply: (put #'xxx-bookmark-handler 'bookmark-inhibit '(insert jump-window-actions jump-display-func)) I tested this with a version of bufferlo waiting in the wings and it works nicely. If we want to add generic bookmark handler functions as a separate enhancement, I'm all for that in the future. -Stephane --0000000000001b50e806311b71f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Tue, Mar 18, 2025 at 2:12=E2=80=AFPM Ship Mints <shipmints@gmail.com> wrote:
On Tue, Mar 18, 2025 at 12:28 Ship Mints <shipmints@gmail.com> wrote:

On Tue, Mar 18, 2025 at 11:55=E2=80=AFAM Thierry Volpiatto <thievol@posteo.net> wro= te:
Ship Mints &= lt;shipmints@gmail= .com> writes:

> 1.=C2=A0 ( ) text/plain=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (*) text/htm= l=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>
> On Tue, Mar 18, 2025 at 11:15=E2=80=AFAM Thierry Volpiatto <thievol@posteo.net>= wrote:
>
>=C2=A0 =C2=A0 =C2=A0Ship Mints <shipmints@gmail.com> writes:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0> 1.=C2=A0 ( ) text/plain=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 (*) text/html=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Tue, Mar 18, 2025 at 2:55=E2=80=AFAM Thierr= y Volpiatto <thi= evol@posteo.net> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Sorry for late reply, was b= usy.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Ship Mints <shipmints@gmail.com> wr= ites:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> On Sun, Mar 16, 2025 a= t 5:10=E2=80=AFPM Ship Mints <shipmints@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0On = Sat, Mar 15, 2025 at 10:18=E2=80=AFAM Ship Mints <shipmints@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0On Sat, Mar 15, 2025 at 1:37=E2=80=AFAM Thierry Volpiatto <= thievol@posteo.net<= /a>> wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Ship Mints <shipmints@gmail.com> writes:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> I have workarounds that work only for the m= ost simplistic cases.=C2=A0 Many
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> of our=C2=A0bookmarks themselves contain em= bedded bookmarks and bookmark
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> references (which are individually addressa= ble so can be used
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> separately) with window-states we need to r= estore in tab-bar tabs that
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> they represent.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0I don't really understand what your packages= are doing or are intended
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0doing, but FWICS in bufferlo: You are using in s= ome places
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0(bookmark-jump name #'ignore); why don't= you do all this work (restore
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0window-states in tab) in DISPLAY-FUNCTION instea= d of using `ignore`?
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Your handler would be much simpler by moving the= window-state-put and
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0alike calls in DISPLAY-FUNCTION:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0(bookmark-jump name #'your_function_restorin= g_window_or_frame_state)=C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Using (bookmark-jump name #'ignore) with all= the code that jump to
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0frame/tab etc... in the handler is just a workar= ound to fix the previous
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0buggy behavior of bookmark--jump-via. IMO.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0It would be good to start with a good example or= recipe to see if we can
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0find a good solution.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0We need the bookmarks to work from the bookmark menu where no = display-function overrides are supported.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0I suggest we add bookmark-record keys that indicate to bookmar= k-jump to inhibit/or allow messing with window-configurations.=C2=A0 The bu= fferlo bookmarks (and Adam's if he
>=C2=A0 =C2=A0 =C2=A0wants)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0would
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0contain these hint keys.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0'(bookmark-jump-inhibit-window-actions . t) ; or whatever = we come up with
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0I can contrive an example, if necessary, but I believe y'a= ll get the point.=C2=A0 Nested bookmarks whose handlers expect their window= -configurations not to be messed with up
>=C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0chain,=C2=A0will always be broken without additional controls.=
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0The= attached patch implements such a scheme that works for us, and is transpar= ent to other=C2=A0bookmark=C2=A0uses.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Perhaps we should rest= ore bookmark--jump-via to its previous behavior
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> and better document th= e "rules of the road" for bookmark handlers.=C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> For simple file- and p= oint-based bookmarks, handlers need to ensure
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> that when they return,= the selected window and current buffer are
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> what's intended.= =C2=A0 For bookmark handlers that perform other actions,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> those rules need not a= pply to leverage the bookmark infrastructure.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0What we could do is propose= a more flexible solution so that you could
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0use whatever you want for b= ookmark--jump-via; With what you have proposed so
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0far, you still have the pro= blem of DISPLAY-FUNCTION which will always
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0run (I see there is comment= s about this problem in your mentionned
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0packages), with the patch b= elow you could define a display-function
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0entry in your bookmark-reco= rd e.g. (display-function . ignore) and then
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0add a special method for bo= okmark--jump-via:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0(cl-defmethod bookmark--jum= p-via (bookmark-name-or-record (_ (eql 'ignore)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 (do_watever_you_want= _here)) ; e.g. run only the handler fn.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0NOTE: I used 'ignore as= example but you could use whatever you want.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Here the patch:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0diff --git a/lisp/bookmark.= el b/lisp/bookmark.el
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0index 99bb26e83cc..e594387f= 364 100644
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--- a/lisp/bookmark.el
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+++ b/lisp/bookmark.el
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0@@ -1259,7 +1259,7 @@ it to= the name of the bookmark currently being set, advancing
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0"Hook run= after `bookmark-jump' jumps to a bookmark.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0Useful for example to= unhide text in `outline-mode'.")
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-(defun bookmark--jump-via = (bookmark-name-or-record display-function)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+(cl-defgeneric bookmark--j= ump-via (bookmark-name-or-record display-function)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0"Handle B= OOKMARK-NAME-OR-RECORD, then call DISPLAY-FUNCTION.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0DISPLAY-FUNCTION is c= alled with the new buffer as argument.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0@@ -1319,8 +1319,12 @@ DISP= LAY-FUNC would be `switch-to-buffer-other-window'."
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0;; Don't u= se `switch-to-buffer' because it would let the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0;; window-poin= t override the bookmark's point when
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0;; `switch-to-= buffer-preserve-window-point' is non-nil.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-=C2=A0 (bookmark--jump-via= bookmark (or display-func 'pop-to-buffer-same-window)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 (bookmark-jump-1 bo= okmark display-func))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+(defun bookmark-jump-1 (bo= okmark display-func)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 (let ((dfn (or (boo= kmark-prop-get bookmark 'display-function)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0display-func 'pop-to-buffer-same-= window)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 (bookmark--j= ump-via bookmark dfn)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0;;;###autoload
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0(defun bookmark-jump-= other-window (bookmark)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0@@ -2303,7 +2307,7 @@ the r= elated behaviors of `bookmark-save' and `bookmark-bmenu-save'."= ;
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0(pop-up-windows t))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0(delete= -other-windows)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0(switch= -to-buffer (other-buffer) nil t)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0 (bookmark--j= ump-via bmrk 'pop-to-buffer)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 (bookmark-ju= mp-1 bmrk 'pop-to-buffer)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0(bury-b= uffer menu)))
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0@@ -2317,7 +2321,7 @@ the r= elated behaviors of `bookmark-save' and `bookmark-bmenu-save'."= ;
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0"Select t= his line's bookmark in other window, leaving bookmark menu visible.&quo= t;
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(interactive n= il bookmark-bmenu-mode)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(let ((bookmar= k (bookmark-bmenu-bookmark)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0 (bookmark--j= ump-via bookmark 'switch-to-buffer-other-window)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 (bookmark-ju= mp-1 bookmark 'switch-to-buffer-other-window)))
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0(defun bookmark-bmenu= -other-frame ()
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0@@ -2333,7 +2337,7 @@ The c= urrent window remains selected."
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(interactive n= il bookmark-bmenu-mode)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(let ((bookmar= k (bookmark-bmenu-bookmark))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0= (fun (lambda (b) (display-buffer b t))))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0 (bookmark--j= ump-via bookmark fun)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 (bookmark-ju= mp-1 bookmark fun)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0(defun bookmark-bmenu= -other-window-with-mouse (event)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0"Jump to = bookmark at mouse EVENT position in other window.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Also I guess trying to call= bookmark-jump-other-window and friends is
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0failing with your special b= ookmarks, with this it would run just as
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0bookmark-jump without (poss= ible) errors.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0WDYT?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Thanks for the continuing=C2=A0discussion.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The concept will work but it feels a bit over-= engineered.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0It is not, it is quite simple.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0> The approach of ignoring save-window-excursion= and display-func via
>=C2=A0 =C2=A0 =C2=A0> bookmark-record entries or using properties on= the handler seem less
>=C2=A0 =C2=A0 =C2=A0> intrusive or a mix,=C2=A0if we feel that's= appropriate.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0I proposed this solution to help you cleaning up yo= ur code which is full
>=C2=A0 =C2=A0 =C2=A0of workarounds for the current behavior (prior 31).= =C2=A0 Of course if you
>=C2=A0 =C2=A0 =C2=A0don't want to make an effort to update your cod= e, what you propose is
>=C2=A0 =C2=A0 =C2=A0simpler (i.e. you have nothing to change on your si= de), but generally we
>=C2=A0 =C2=A0 =C2=A0(external emacs extensions developers) try to adapt= ourselves to Emacs
>=C2=A0 =C2=A0 =C2=A0source and not the contrary.
>
> Thanks for the input.
>
> The idea that I "don't want to make an effort" is insult= ing.

Sorry if you take it like this, it was not the intention.

> =C2=A0 Perhaps a little less coffee.

I don't drink coffee.

>=C2=A0 =C2=A0 =C2=A0> Why not just fix the eww bookmark handler to d= o its own
>=C2=A0 =C2=A0 =C2=A0> save-window-excursion, again, rather than make= a default bookmark jump
>=C2=A0 =C2=A0 =C2=A0> behavior policy change?
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0Because the problem is not just about eww, but more= generally on how
>=C2=A0 =C2=A0 =C2=A0bookmark handlers work.
>
> Curious to know which other ones are broken?=C2=A0 I read eww and w3m.=

It is not only about eww AND w3m.=C2=A0 The point is not if things are brok= en
or not, it is to provide a good API for all bookmarks (and future kind
of bookmarks).


> What do the Emacs maintainers think about this as a matter of taste, > easy adoption for other bookmark users, and idiomatic usage?

Now Eli and other maintainers will decide what is the best for emacs.

You may not have seen it but th= ere is already precedent for bookmark-handler properties in bookmark.el in = bookmark-insert for the 'bookmark-inhibit property on a handler.=C2=A0 = It could contain a list of inhibitions.

I'll submit a patch to make that property into a list.=C2=A0 = It was my code to begin with and used only in shell-bookmark and I should h= ave planned ahead. Even if we don't use it for the above purposes.=C2= =A0

I've attached a patch to bookma= rk-jump/bookmark--jump-via that supports inhibiting window actions and disp= lay function using the 'bookmark-inhibit handler function property list= that Michael Albinus pushed to master last week.

Usage for bookmark handler authors is = simply:
<= br>
(put = #'xxx-bookmark-handler 'bookmark-inhibit '(insert
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 jump-window-actions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 jump-display-func))
<= br>
I tes= ted this with a version of bufferlo waiting in the wings and it works nicel= y.

If we want= to add generic bookmark handler functions as a separate enhancement, I'= ;m all for that in the future.

-Stephane
--0000000000001b50e806311b71f7-- --0000000000001b50e906311b71f9 Content-Type: application/octet-stream; name="0001-bookmark-jump-inhibit-window-actions-and-display-fun.patch" Content-Disposition: attachment; filename="0001-bookmark-jump-inhibit-window-actions-and-display-fun.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_m8ng4mt60 RnJvbSAxZjU2NTYzNTU0NTUxZTA0ZWUxYTg4ZjVjNTQwNzE2NTk2MzU4Y2YzIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBzaGlwbWludHMgPHNoaXBtaW50c0BnbWFpbC5jb20+CkRhdGU6 IE1vbiwgMjQgTWFyIDIwMjUgMTU6MDY6MTkgLTA0MDAKU3ViamVjdDogW1BBVENIXSAnYm9va21h cmstanVtcCcgaW5oaWJpdCB3aW5kb3cgYWN0aW9ucyBhbmQgZGlzcGxheSBmdW5jCiAoYnVnIzc1 MzU0KQoKVGhpcyBhbGxvd3MgYm9va21hcmsgaGFuZGxlciBmdW5jdGlvbnMgdG8gcGVyZm9ybSB0 aGVpciBvd24Kd2luZG93IGFjdGlvbnMgYW5kIGRpc3BsYXkgZnVuY3Rpb25zLCB3aXRoIGJhY2t3 YXJkCmNvbXBhdGliaWxpdHkgZm9yIGV4aXN0aW5nIGJvb2ttYXJrIGhhbmRsZXJzLgoKKiBsaXNw L2Jvb2ttYXJrLmVsIChib29rbWFyay0tanVtcC12aWEpOiBTdXBwb3J0IGJvb2ttYXJrCmhhbmRs ZXIgZnVuY3Rpb24gcHJvcGVydHkgJ2Jvb2ttYXJrLWluaGliaXQgc3VwcG9ydCBmb3IKJ2luaGli aXQtd2luZG93LWFjdGlvbnMgYW5kICdpbmhpYml0LWRpc3BsYXktZnVuYy4KKGJvb2ttYXJrLWp1 bXApOiBEb2NzdHJpbmcgbWVudGlvbnMgYm9va21hcmsgaGFuZGxlciBmdW5jdGlvbgpwcm9wZXJ0 eSAnYm9va21hcmstaW5oaWJpdCBzdXBwb3J0IGZvciAnaW5oaWJpdC13aW5kb3ctYWN0aW9ucwph bmQgJ2luaGliaXQtZGlzcGxheS1mdW5jLgotLS0KIGxpc3AvYm9va21hcmsuZWwgfCAzNyArKysr KysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgMjggaW5z ZXJ0aW9ucygrKSwgOSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9saXNwL2Jvb2ttYXJrLmVs IGIvbGlzcC9ib29rbWFyay5lbAppbmRleCAwZGU0MmJjZWE1MS4uZjA0NTE2ODAyYzggMTAwNjQ0 Ci0tLSBhL2xpc3AvYm9va21hcmsuZWwKKysrIGIvbGlzcC9ib29rbWFyay5lbApAQCAtMTI2Niwx NCArMTI2NiwyNSBAQCBib29rbWFyay0tanVtcC12aWEKIEFmdGVyIGNhbGxpbmcgRElTUExBWS1G VU5DVElPTiwgc2V0IHdpbmRvdyBwb2ludCB0byB0aGUgcG9pbnQgc3BlY2lmaWVkCiBieSBCT09L TUFSSy1OQU1FLU9SLVJFQ09SRCwgaWYgbmVjZXNzYXJ5LCBydW4gYGJvb2ttYXJrLWFmdGVyLWp1 bXAtaG9vaycsCiBhbmQgdGhlbiBzaG93IGFueSBhbm5vdGF0aW9ucyBmb3IgdGhpcyBib29rbWFy ay4iCi0gIChsZXQgKGJ1ZiBwb2ludCkKLSAgICAoc2F2ZS13aW5kb3ctZXhjdXJzaW9uCi0gICAg ICAoYm9va21hcmstaGFuZGxlLWJvb2ttYXJrIGJvb2ttYXJrLW5hbWUtb3ItcmVjb3JkKQotICAg ICAgKHNldHEgYnVmIChjdXJyZW50LWJ1ZmZlcikKLSAgICAgICAgICAgIHBvaW50IChwb2ludCkp KQotICAgIChmdW5jYWxsIGRpc3BsYXktZnVuY3Rpb24gYnVmKQotICAgICh3aGVuLWxldCogKCh3 aW4gKGdldC1idWZmZXItd2luZG93IGJ1ZiAwKSkpCi0gICAgICAoc2V0LXdpbmRvdy1wb2ludCB3 aW4gcG9pbnQpKQorICAobGV0KiAoKGluaGliaXQtcHJvcCAoZ2V0IChvciAoYm9va21hcmstZ2V0 LWhhbmRsZXIgYm9va21hcmstbmFtZS1vci1yZWNvcmQpCisgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICMnYm9va21hcmstZGVmYXVsdC1oYW5kbGVyKQorICAgICAgICAgICAgICAgICAg ICAgICAgICAgICdib29rbWFyay1pbmhpYml0KSkKKyAgICAgICAgIChpbmhpYml0LXdpbmRvdy1h Y3Rpb25zIChtZW1xICdqdW1wLXdpbmRvdy1hY3Rpb25zCisgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBpbmhpYml0LXByb3ApKQorICAgICAgICAgKGluaGliaXQtZGlzcGxh eS1mdW5jIChtZW1xICdqdW1wLWRpc3BsYXktZnVuYworICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGluaGliaXQtcHJvcCkpCisgICAgICAgICBidWYgcG9pbnQpCisgICAgKGlm IGluaGliaXQtd2luZG93LWFjdGlvbnMKKyAgICAgICAgKGJvb2ttYXJrLWhhbmRsZS1ib29rbWFy ayBib29rbWFyay1uYW1lLW9yLXJlY29yZCkKKyAgICAgIChzYXZlLXdpbmRvdy1leGN1cnNpb24K KyAgICAgICAgKGJvb2ttYXJrLWhhbmRsZS1ib29rbWFyayBib29rbWFyay1uYW1lLW9yLXJlY29y ZCkKKyAgICAgICAgKHNldHEgYnVmIChjdXJyZW50LWJ1ZmZlcikKKyAgICAgICAgICAgICAgcG9p bnQgKHBvaW50KSkpKQorICAgICh1bmxlc3MgaW5oaWJpdC1kaXNwbGF5LWZ1bmMKKyAgICAgIChm dW5jYWxsIGRpc3BsYXktZnVuY3Rpb24gYnVmKSkKKyAgICAodW5sZXNzIGluaGliaXQtd2luZG93 LWFjdGlvbnMKKyAgICAgICh3aGVuLWxldCogKCh3aW4gKGdldC1idWZmZXItd2luZG93IGJ1ZiAw KSkpCisgICAgICAgIChzZXQtd2luZG93LXBvaW50IHdpbiBwb2ludCkpKQogICAgICh3aGVuIGJv b2ttYXJrLWZyaW5nZS1tYXJrCiAgICAgICAobGV0ICgob3ZlcmxheXMgKG92ZXJsYXlzLWluIChw b3MtYm9sKSAoMSsgKHBvcy1ib2wpKSkpCiAgICAgICAgICAgICB0ZW1wIGZvdW5kKQpAQCAtMTMw OSw3ICsxMzIwLDE1IEBAIGJvb2ttYXJrLWp1bXAKIAogSWYgRElTUExBWS1GVU5DIGlzIG5vbi1u aWwsIGl0IGlzIGEgZnVuY3Rpb24gdG8gaW52b2tlIHRvIGRpc3BsYXkgdGhlCiBib29rbWFyay4g IEl0IGRlZmF1bHRzIHRvIGBwb3AtdG8tYnVmZmVyLXNhbWUtd2luZG93Jy4gIEEgdHlwaWNhbCB2 YWx1ZSBmb3IKLURJU1BMQVktRlVOQyB3b3VsZCBiZSBgc3dpdGNoLXRvLWJ1ZmZlci1vdGhlci13 aW5kb3cnLiIKK0RJU1BMQVktRlVOQyB3b3VsZCBiZSBgc3dpdGNoLXRvLWJ1ZmZlci1vdGhlci13 aW5kb3cnLgorCitJZiB0aGUgYm9va21hcmsgaGFuZGxlciBmdW5jdGlvbiBhc3NvY2lhdGVkIHdp dGggQk9PS01BUkstTkFNRS1PUi1SRUNPUkQKK2hhcyBhIG5vbi1uaWwgXFw9J2Jvb2ttYXJrLWlu aGliaXQgcHJvcGVydHksIHdoaWNoIGlzIGEgbGlzdCwgYW5kIGl0Citjb250YWluczoKKyAgXFw9 J2p1bXAtd2luZG93LWFjdGlvbnMsIHRoZW4gd2luZG93IG9yIGZyYW1lIGFjdGlvbnMgc2hvdWxk IGJlIGhhbmRsZWQKK2J5IHRoZSBib29rbWFyaydzIGhhbmRsZXIKKyAgXFw9J2p1bXAtZGlzcGxh eS1mdW5jLCB0aGVuIGRpc3BsYXkgYWN0aW9ucyBzaG91bGQgYmUgaGFuZGxlZCBieSB0aGUKK2Jv b2ttYXJrJ3MgaGFuZGxlci4iCiAgIChpbnRlcmFjdGl2ZQogICAgKGxpc3QgKGJvb2ttYXJrLWNv bXBsZXRpbmctcmVhZCAiSnVtcCB0byBib29rbWFyayIKIAkJCQkgICBib29rbWFyay1jdXJyZW50 LWJvb2ttYXJrKSkpCi0tIAoyLjQ3LjEKCg== --0000000000001b50e906311b71f9-- From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 27 08:12:13 2025 Received: (at submit) by debbugs.gnu.org; 27 Mar 2025 12:12:13 +0000 Received: from localhost ([127.0.0.1]:47948 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1txm5g-0008J4-HQ for submit@debbugs.gnu.org; Thu, 27 Mar 2025 08:12:13 -0400 Received: from lists.gnu.org ([2001:470:142::17]:43216) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1txm5Y-0008GX-G2 for submit@debbugs.gnu.org; Thu, 27 Mar 2025 08:12:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1txm5S-0001Ck-SR for bug-gnu-emacs@gnu.org; Thu, 27 Mar 2025 08:11:54 -0400 Received: from mail-ua1-x92f.google.com ([2607:f8b0:4864:20::92f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1txm5P-0004UN-PN; Thu, 27 Mar 2025 08:11:54 -0400 Received: by mail-ua1-x92f.google.com with SMTP id a1e0cc1a2514c-86feb84877aso382244241.3; Thu, 27 Mar 2025 05:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743077510; x=1743682310; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=35k+nZTi+I5Cc4p6S8huHwUud4OZ3vffmbDv6qAIZJI=; b=RgxxasJ2mJ8CAe3U5Efpg/tH+clsA4tay2r17lTpE6el8dDfHiZnKUD53dR67FuoI5 NebBM0XgnFrCVukX7ShOEObmI0sAAQWDtQoTquHuDnQ84Hs8SSZtyspb6f9uRABLaLUF qHgM2rmKz8241XuO/ZokV6gGtU3ca/N2hPfDdnXPoOyrQpCr8ZS+hlu9ob6fxzY1hema lqcq9E683seK3P9Fg5o7H9gBTha44GTWbaVb2+Iv5wTzwQRDhjlkxl6DZtoCRMhh++Ck 7aSvLvW/i9hrQcUElMXLQa9/ClmA7nunGAG/9yR4xyn2l1JcZEF0il4R5CAW/SbiDc+X M8QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743077510; x=1743682310; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=35k+nZTi+I5Cc4p6S8huHwUud4OZ3vffmbDv6qAIZJI=; b=r5tKlp5u2U7m3evtvcSdEUK64ZOv2UjdyJUkSf8quje4Zeum2te/Fee0bHNcesHdYR TtDU9Z8N8jNUC0RYq6IuTgeHgNyDrDZrXq5q2pmyjycMOT/pun93hVETmRLMPyPHcPbI VT4IsoUJ6E9uUmJFCfwDPGyNRYlJj2cnKtbfm6KSg28do9Z+aE2icNs+NZcTsk7T5DgE BXQI8dpexvnvbUz2dkWKUJTWUu5gyuvVQ0pFAmk5t3izSiWIa+rt6UZBmO8J0OAdsYEe kOirR6PAI0rrziY2BJoRtVekYtpBrdK7RkSsUBsFU06Sb/eo0N5zMfgIfUn3Uk6GnEPX e3jA== X-Forwarded-Encrypted: i=1; AJvYcCViCx4iVjM28nN/VX73I4O+Fegq8nrKCRB/jXP4Kt9M1s0ANqosA1PM3gU+7JA6WStMCC54MNdRogHk8HCm@gnu.org X-Gm-Message-State: AOJu0YzSnqWLBy0KJeA8nulN95Zxs/XSPc0pJvW1ICyFmym28ZUsNYIk k56FvoK7uxf0OuHxZa9bp6OE5Vtq2U0hMlMopNBubCntimmYf3koQFQbWzjkeRGaREpYj8RmUzj RQWQR+JrigL1BnCtH+26ibw9dUQSTUuXu X-Gm-Gg: ASbGnctRbps0Jsbql5K2JDy2RADTsRsHt9pqqe0qorLo4QdBzNUgLR4rMgkC9c+Z7UF CSVUon3pgQnsfNTf6GfS/huK6CRQjADhacDA2uWwV25kJgZsOLvTFxKRb+6sWK00mKtzC9nyO5O iqldYMFB/jlrs531QgtCjsPnKxWw== X-Google-Smtp-Source: AGHT+IGxlZ4tVEyFcYMmNx3Q+lp42Fm7gfcXuW6KPK8ruIR5S1b5lB0ZskWUe/mwMfkcpQtVy2UNmeybNzkScBs2YXI= X-Received: by 2002:a05:6102:4b8c:b0:4c4:dead:59a3 with SMTP id ada2fe7eead31-4c586f11e9cmr3378031137.2.1743077510244; Thu, 27 Mar 2025 05:11:50 -0700 (PDT) MIME-Version: 1.0 References: <874izwn306.fsf@posteo.net> <87y0x8kyaq.fsf@posteo.net> <877c4r6cok.fsf@posteo.net> <871puy6e5x.fsf@posteo.net> <87v7s6om6i.fsf@posteo.net> <87ecyul5xg.fsf@posteo.net> <878qp2l41h.fsf@posteo.net> In-Reply-To: From: Ship Mints Date: Thu, 27 Mar 2025 08:11:39 -0400 X-Gm-Features: AQ5f1JphS5zoQYCx2irmpr6d_f70U475ukT8g5QQsxPlz4KKH36CT0f8NpwHpaU Message-ID: Subject: Re: bug#75354: (29.4; eww buffer is not displayed correctly when used from bookmark-jump ) To: Thierry Volpiatto Content-Type: multipart/alternative; boundary="000000000000d070b6063151db3d" Received-SPF: pass client-ip=2607:f8b0:4864:20::92f; envelope-from=shipmints@gmail.com; helo=mail-ua1-x92f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Eli Zaretskii , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --000000000000d070b6063151db3d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 24, 2025 at 3:16=E2=80=AFPM Ship Mints wr= ote: > On Tue, Mar 18, 2025 at 2:12=E2=80=AFPM Ship Mints = wrote: > >> On Tue, Mar 18, 2025 at 12:28 Ship Mints wrote: >> >>> >>> On Tue, Mar 18, 2025 at 11:55=E2=80=AFAM Thierry Volpiatto >>> wrote: >>> >>>> Ship Mints writes: >>>> >>>> > 1. ( ) text/plain (*) text/html >>>> > >>>> > On Tue, Mar 18, 2025 at 11:15=E2=80=AFAM Thierry Volpiatto < >>>> thievol@posteo.net> wrote: >>>> > >>>> > Ship Mints writes: >>>> > >>>> > > 1. ( ) text/plain (*) text/html >>>> > > >>>> > > On Tue, Mar 18, 2025 at 2:55=E2=80=AFAM Thierry Volpiatto < >>>> thievol@posteo.net> wrote: >>>> > > >>>> > > Sorry for late reply, was busy. >>>> > > >>>> > > Ship Mints writes: >>>> > > >>>> > > > On Sun, Mar 16, 2025 at 5:10=E2=80=AFPM Ship Mints < >>>> shipmints@gmail.com> wrote: >>>> > > > >>>> > > > On Sat, Mar 15, 2025 at 10:18=E2=80=AFAM Ship Mints = < >>>> shipmints@gmail.com> wrote: >>>> > > > >>>> > > > On Sat, Mar 15, 2025 at 1:37=E2=80=AFAM Thierry = Volpiatto >>>> wrote: >>>> > > > >>>> > > > Ship Mints writes: >>>> > > > >>>> > > > > I have workarounds that work only for the >>>> most simplistic cases. Many >>>> > > > > of our bookmarks themselves contain >>>> embedded bookmarks and bookmark >>>> > > > > references (which are individually >>>> addressable so can be used >>>> > > > > separately) with window-states we need to >>>> restore in tab-bar tabs that >>>> > > > > they represent. >>>> > > > >>>> > > > I don't really understand what your packages >>>> are doing or are intended >>>> > > > doing, but FWICS in bufferlo: You are using >>>> in some places >>>> > > > (bookmark-jump name #'ignore); why don't you >>>> do all this work (restore >>>> > > > window-states in tab) in DISPLAY-FUNCTION >>>> instead of using `ignore`? >>>> > > > Your handler would be much simpler by moving >>>> the window-state-put and >>>> > > > alike calls in DISPLAY-FUNCTION: >>>> > > > >>>> > > > (bookmark-jump name >>>> #'your_function_restoring_window_or_frame_state) >>>> > > > >>>> > > > Using (bookmark-jump name #'ignore) with all >>>> the code that jump to >>>> > > > frame/tab etc... in the handler is just a >>>> workaround to fix the previous >>>> > > > buggy behavior of bookmark--jump-via. IMO. >>>> > > > >>>> > > > It would be good to start with a good exampl= e >>>> or recipe to see if we can >>>> > > > find a good solution. >>>> > > > >>>> > > > We need the bookmarks to work from the bookmark >>>> menu where no display-function overrides are supported. >>>> > > > >>>> > > > I suggest we add bookmark-record keys that >>>> indicate to bookmark-jump to inhibit/or allow messing with >>>> window-configurations. The bufferlo bookmarks (and Adam's if he >>>> > wants) >>>> > > would >>>> > > > contain these hint keys. >>>> > > > >>>> > > > '(bookmark-jump-inhibit-window-actions . t) ; or >>>> whatever we come up with >>>> > > > >>>> > > > I can contrive an example, if necessary, but I >>>> believe y'all get the point. Nested bookmarks whose handlers expect t= heir >>>> window-configurations not to be messed with up >>>> > the >>>> > > > chain, will always be broken without additional >>>> controls. >>>> > > > >>>> > > > The attached patch implements such a scheme that >>>> works for us, and is transparent to other bookmark uses. >>>> > > > >>>> > > > Perhaps we should restore bookmark--jump-via to its >>>> previous behavior >>>> > > > and better document the "rules of the road" for bookmark >>>> handlers. >>>> > > > For simple file- and point-based bookmarks, handlers nee= d >>>> to ensure >>>> > > > that when they return, the selected window and current >>>> buffer are >>>> > > > what's intended. For bookmark handlers that perform >>>> other actions, >>>> > > > those rules need not apply to leverage the bookmark >>>> infrastructure. >>>> > > >>>> > > What we could do is propose a more flexible solution so >>>> that you could >>>> > > use whatever you want for bookmark--jump-via; With what yo= u >>>> have proposed so >>>> > > far, you still have the problem of DISPLAY-FUNCTION which >>>> will always >>>> > > run (I see there is comments about this problem in your >>>> mentionned >>>> > > packages), with the patch below you could define a >>>> display-function >>>> > > entry in your bookmark-record e.g. (display-function . >>>> ignore) and then >>>> > > add a special method for bookmark--jump-via: >>>> > > >>>> > > (cl-defmethod bookmark--jump-via (bookmark-name-or-record >>>> (_ (eql 'ignore))) >>>> > > (do_watever_you_want_here)) ; e.g. run only the handler >>>> fn. >>>> > > >>>> > > NOTE: I used 'ignore as example but you could use whatever >>>> you want. >>>> > > >>>> > > Here the patch: >>>> > > >>>> > > diff --git a/lisp/bookmark.el b/lisp/bookmark.el >>>> > > index 99bb26e83cc..e594387f364 100644 >>>> > > --- a/lisp/bookmark.el >>>> > > +++ b/lisp/bookmark.el >>>> > > @@ -1259,7 +1259,7 @@ it to the name of the bookmark >>>> currently being set, advancing >>>> > > "Hook run after `bookmark-jump' jumps to a bookmark. >>>> > > Useful for example to unhide text in `outline-mode'.") >>>> > > >>>> > > -(defun bookmark--jump-via (bookmark-name-or-record >>>> display-function) >>>> > > +(cl-defgeneric bookmark--jump-via (bookmark-name-or-recor= d >>>> display-function) >>>> > > "Handle BOOKMARK-NAME-OR-RECORD, then call >>>> DISPLAY-FUNCTION. >>>> > > DISPLAY-FUNCTION is called with the new buffer as argumen= t. >>>> > > >>>> > > @@ -1319,8 +1319,12 @@ DISPLAY-FUNC would be >>>> `switch-to-buffer-other-window'." >>>> > > ;; Don't use `switch-to-buffer' because it would let th= e >>>> > > ;; window-point override the bookmark's point when >>>> > > ;; `switch-to-buffer-preserve-window-point' is non-nil. >>>> > > - (bookmark--jump-via bookmark (or display-func >>>> 'pop-to-buffer-same-window))) >>>> > > + (bookmark-jump-1 bookmark display-func)) >>>> > > >>>> > > +(defun bookmark-jump-1 (bookmark display-func) >>>> > > + (let ((dfn (or (bookmark-prop-get bookmark >>>> 'display-function) >>>> > > + display-func 'pop-to-buffer-same-window)= )) >>>> > > + (bookmark--jump-via bookmark dfn))) >>>> > > >>>> > > ;;;###autoload >>>> > > (defun bookmark-jump-other-window (bookmark) >>>> > > @@ -2303,7 +2307,7 @@ the related behaviors of >>>> `bookmark-save' and `bookmark-bmenu-save'." >>>> > > (pop-up-windows t)) >>>> > > (delete-other-windows) >>>> > > (switch-to-buffer (other-buffer) nil t) >>>> > > - (bookmark--jump-via bmrk 'pop-to-buffer) >>>> > > + (bookmark-jump-1 bmrk 'pop-to-buffer) >>>> > > (bury-buffer menu))) >>>> > > >>>> > > @@ -2317,7 +2321,7 @@ the related behaviors of >>>> `bookmark-save' and `bookmark-bmenu-save'." >>>> > > "Select this line's bookmark in other window, leaving >>>> bookmark menu visible." >>>> > > (interactive nil bookmark-bmenu-mode) >>>> > > (let ((bookmark (bookmark-bmenu-bookmark))) >>>> > > - (bookmark--jump-via bookmark >>>> 'switch-to-buffer-other-window))) >>>> > > + (bookmark-jump-1 bookmark >>>> 'switch-to-buffer-other-window))) >>>> > > >>>> > > (defun bookmark-bmenu-other-frame () >>>> > > @@ -2333,7 +2337,7 @@ The current window remains selected.= " >>>> > > (interactive nil bookmark-bmenu-mode) >>>> > > (let ((bookmark (bookmark-bmenu-bookmark)) >>>> > > (fun (lambda (b) (display-buffer b t)))) >>>> > > - (bookmark--jump-via bookmark fun))) >>>> > > + (bookmark-jump-1 bookmark fun))) >>>> > > >>>> > > (defun bookmark-bmenu-other-window-with-mouse (event) >>>> > > "Jump to bookmark at mouse EVENT position in other >>>> window. >>>> > > >>>> > > Also I guess trying to call bookmark-jump-other-window and >>>> friends is >>>> > > failing with your special bookmarks, with this it would ru= n >>>> just as >>>> > > bookmark-jump without (possible) errors. >>>> > > >>>> > > WDYT? >>>> > > >>>> > > Thanks for the continuing discussion. >>>> > > >>>> > > The concept will work but it feels a bit over-engineered. >>>> > >>>> > It is not, it is quite simple. >>>> > >>>> > > The approach of ignoring save-window-excursion and display-fun= c >>>> via >>>> > > bookmark-record entries or using properties on the handler see= m >>>> less >>>> > > intrusive or a mix, if we feel that's appropriate. >>>> > >>>> > I proposed this solution to help you cleaning up your code which >>>> is full >>>> > of workarounds for the current behavior (prior 31). Of course i= f >>>> you >>>> > don't want to make an effort to update your code, what you >>>> propose is >>>> > simpler (i.e. you have nothing to change on your side), but >>>> generally we >>>> > (external emacs extensions developers) try to adapt ourselves to >>>> Emacs >>>> > source and not the contrary. >>>> > >>>> > Thanks for the input. >>>> > >>>> > The idea that I "don't want to make an effort" is insulting. >>>> >>>> Sorry if you take it like this, it was not the intention. >>>> >>>> > Perhaps a little less coffee. >>>> >>>> I don't drink coffee. >>>> >>>> > > Why not just fix the eww bookmark handler to do its own >>>> > > save-window-excursion, again, rather than make a default >>>> bookmark jump >>>> > > behavior policy change? >>>> > >>>> > Because the problem is not just about eww, but more generally on >>>> how >>>> > bookmark handlers work. >>>> > >>>> > Curious to know which other ones are broken? I read eww and w3m. >>>> >>>> It is not only about eww AND w3m. The point is not if things are brok= en >>>> or not, it is to provide a good API for all bookmarks (and future kind >>>> of bookmarks). >>>> >>>> >>>> > What do the Emacs maintainers think about this as a matter of taste, >>>> > easy adoption for other bookmark users, and idiomatic usage? >>>> >>>> Now Eli and other maintainers will decide what is the best for emacs. >>>> >>> >>> You may not have seen it but there is already precedent for >>> bookmark-handler properties in bookmark.el in bookmark-insert for the >>> 'bookmark-inhibit property on a handler. It could contain a list of >>> inhibitions. >>> >> >> I'll submit a patch to make that property into a list. It was my code t= o >> begin with and used only in shell-bookmark and I should have planned ahe= ad. >> Even if we don't use it for the above purposes. >> > > I've attached a patch to bookmark-jump/bookmark--jump-via that supports > inhibiting window actions and display function using the 'bookmark-inhibi= t > handler function property list that Michael Albinus pushed to master last > week. > > Usage for bookmark handler authors is simply: > > (put #'xxx-bookmark-handler 'bookmark-inhibit '(insert > jump-window-actions > jump-display-func)) > > I tested this with a version of bufferlo waiting in the wings and it work= s > nicely. > > If we want to add generic bookmark handler functions as a separate > enhancement, I'm all for that in the future. > I'd like to see the latest approach I proposed installed. We can add fancier method overrides later. We have a major version of bufferlo just about ready for release and I'd like to ensure that it works well in Emacs 31/master. We've already adopted many of the improvements in Emacs 31; including expose-hidden-buffer, tab-bar fixes, window-state-get improvements, define-ibuffer-op improvements. For Emacs < 31, bufferlo advises bookmark--jump-via to avoid display-func when called interactively but it cannot easily avoid save-window-excursion in Emacs 31 without this patch. Many users rely on bookmark-bmenu-list and bookmark-jump commands and we'd love to be able to continue supporting those use cases. Shall we, please? -Stephane --000000000000d070b6063151db3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Mon, Mar 24, 2025 at 3:16=E2=80=AFPM Ship Mints <shipmints@gmail.com> wrote:
On = Tue, Mar 18, 2025 at 2:12=E2=80=AFPM Ship Mints <shipmints@gmail.com> wrote:=
On Tue, Mar 18, 2025 at 12:28 Ship Mints <shipmints@gmail.com> w= rote:

On Tue= , Mar 18, 2025 at 11:55=E2=80=AFAM Thierry Volpiatto <thievol@posteo.net> wrote:
=
Ship Mints <shipmints@gmail.com> writes:

> 1.=C2=A0 ( ) text/plain=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (*) text/htm= l=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>
> On Tue, Mar 18, 2025 at 11:15=E2=80=AFAM Thierry Volpiatto <thievol@posteo.net>= wrote:
>
>=C2=A0 =C2=A0 =C2=A0Ship Mints <shipmints@gmail.com> writes:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0> 1.=C2=A0 ( ) text/plain=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 (*) text/html=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Tue, Mar 18, 2025 at 2:55=E2=80=AFAM Thierr= y Volpiatto <thi= evol@posteo.net> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Sorry for late reply, was b= usy.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Ship Mints <shipmints@gmail.com> wr= ites:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> On Sun, Mar 16, 2025 a= t 5:10=E2=80=AFPM Ship Mints <shipmints@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0On = Sat, Mar 15, 2025 at 10:18=E2=80=AFAM Ship Mints <shipmints@gmail.com> wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0On Sat, Mar 15, 2025 at 1:37=E2=80=AFAM Thierry Volpiatto <= thievol@posteo.net<= /a>> wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Ship Mints <shipmints@gmail.com> writes:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> I have workarounds that work only for the m= ost simplistic cases.=C2=A0 Many
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> of our=C2=A0bookmarks themselves contain em= bedded bookmarks and bookmark
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> references (which are individually addressa= ble so can be used
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> separately) with window-states we need to r= estore in tab-bar tabs that
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0> they represent.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0I don't really understand what your packages= are doing or are intended
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0doing, but FWICS in bufferlo: You are using in s= ome places
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0(bookmark-jump name #'ignore); why don't= you do all this work (restore
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0window-states in tab) in DISPLAY-FUNCTION instea= d of using `ignore`?
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Your handler would be much simpler by moving the= window-state-put and
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0alike calls in DISPLAY-FUNCTION:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0(bookmark-jump name #'your_function_restorin= g_window_or_frame_state)=C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Using (bookmark-jump name #'ignore) with all= the code that jump to
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0frame/tab etc... in the handler is just a workar= ound to fix the previous
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0buggy behavior of bookmark--jump-via. IMO.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0It would be good to start with a good example or= recipe to see if we can
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0find a good solution.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0We need the bookmarks to work from the bookmark menu where no = display-function overrides are supported.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0I suggest we add bookmark-record keys that indicate to bookmar= k-jump to inhibit/or allow messing with window-configurations.=C2=A0 The bu= fferlo bookmarks (and Adam's if he
>=C2=A0 =C2=A0 =C2=A0wants)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0would
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0contain these hint keys.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0'(bookmark-jump-inhibit-window-actions . t) ; or whatever = we come up with
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0I can contrive an example, if necessary, but I believe y'a= ll get the point.=C2=A0 Nested bookmarks whose handlers expect their window= -configurations not to be messed with up
>=C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0chain,=C2=A0will always be broken without additional controls.=
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0The= attached patch implements such a scheme that works for us, and is transpar= ent to other=C2=A0bookmark=C2=A0uses.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Perhaps we should rest= ore bookmark--jump-via to its previous behavior
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> and better document th= e "rules of the road" for bookmark handlers.=C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> For simple file- and p= oint-based bookmarks, handlers need to ensure
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> that when they return,= the selected window and current buffer are
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> what's intended.= =C2=A0 For bookmark handlers that perform other actions,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> those rules need not a= pply to leverage the bookmark infrastructure.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0What we could do is propose= a more flexible solution so that you could
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0use whatever you want for b= ookmark--jump-via; With what you have proposed so
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0far, you still have the pro= blem of DISPLAY-FUNCTION which will always
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0run (I see there is comment= s about this problem in your mentionned
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0packages), with the patch b= elow you could define a display-function
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0entry in your bookmark-reco= rd e.g. (display-function . ignore) and then
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0add a special method for bo= okmark--jump-via:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0(cl-defmethod bookmark--jum= p-via (bookmark-name-or-record (_ (eql 'ignore)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 (do_watever_you_want= _here)) ; e.g. run only the handler fn.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0NOTE: I used 'ignore as= example but you could use whatever you want.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Here the patch:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0diff --git a/lisp/bookmark.= el b/lisp/bookmark.el
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0index 99bb26e83cc..e594387f= 364 100644
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--- a/lisp/bookmark.el
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+++ b/lisp/bookmark.el
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0@@ -1259,7 +1259,7 @@ it to= the name of the bookmark currently being set, advancing
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0"Hook run= after `bookmark-jump' jumps to a bookmark.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0Useful for example to= unhide text in `outline-mode'.")
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-(defun bookmark--jump-via = (bookmark-name-or-record display-function)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+(cl-defgeneric bookmark--j= ump-via (bookmark-name-or-record display-function)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0"Handle B= OOKMARK-NAME-OR-RECORD, then call DISPLAY-FUNCTION.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0DISPLAY-FUNCTION is c= alled with the new buffer as argument.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0@@ -1319,8 +1319,12 @@ DISP= LAY-FUNC would be `switch-to-buffer-other-window'."
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0;; Don't u= se `switch-to-buffer' because it would let the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0;; window-poin= t override the bookmark's point when
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0;; `switch-to-= buffer-preserve-window-point' is non-nil.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-=C2=A0 (bookmark--jump-via= bookmark (or display-func 'pop-to-buffer-same-window)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 (bookmark-jump-1 bo= okmark display-func))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+(defun bookmark-jump-1 (bo= okmark display-func)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 (let ((dfn (or (boo= kmark-prop-get bookmark 'display-function)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0display-func 'pop-to-buffer-same-= window)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 (bookmark--j= ump-via bookmark dfn)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0;;;###autoload
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0(defun bookmark-jump-= other-window (bookmark)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0@@ -2303,7 +2307,7 @@ the r= elated behaviors of `bookmark-save' and `bookmark-bmenu-save'."= ;
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0(pop-up-windows t))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0(delete= -other-windows)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0(switch= -to-buffer (other-buffer) nil t)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0 (bookmark--j= ump-via bmrk 'pop-to-buffer)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 (bookmark-ju= mp-1 bmrk 'pop-to-buffer)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0(bury-b= uffer menu)))
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0@@ -2317,7 +2321,7 @@ the r= elated behaviors of `bookmark-save' and `bookmark-bmenu-save'."= ;
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0"Select t= his line's bookmark in other window, leaving bookmark menu visible.&quo= t;
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(interactive n= il bookmark-bmenu-mode)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(let ((bookmar= k (bookmark-bmenu-bookmark)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0 (bookmark--j= ump-via bookmark 'switch-to-buffer-other-window)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 (bookmark-ju= mp-1 bookmark 'switch-to-buffer-other-window)))
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0(defun bookmark-bmenu= -other-frame ()
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0@@ -2333,7 +2337,7 @@ The c= urrent window remains selected."
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(interactive n= il bookmark-bmenu-mode)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0(let ((bookmar= k (bookmark-bmenu-bookmark))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0= (fun (lambda (b) (display-buffer b t))))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0 (bookmark--j= ump-via bookmark fun)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0+=C2=A0 =C2=A0 (bookmark-ju= mp-1 bookmark fun)))
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0(defun bookmark-bmenu= -other-window-with-mouse (event)
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0"Jump to = bookmark at mouse EVENT position in other window.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Also I guess trying to call= bookmark-jump-other-window and friends is
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0failing with your special b= ookmarks, with this it would run just as
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0bookmark-jump without (poss= ible) errors.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0WDYT?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Thanks for the continuing=C2=A0discussion.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The concept will work but it feels a bit over-= engineered.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0It is not, it is quite simple.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0> The approach of ignoring save-window-excursion= and display-func via
>=C2=A0 =C2=A0 =C2=A0> bookmark-record entries or using properties on= the handler seem less
>=C2=A0 =C2=A0 =C2=A0> intrusive or a mix,=C2=A0if we feel that's= appropriate.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0I proposed this solution to help you cleaning up yo= ur code which is full
>=C2=A0 =C2=A0 =C2=A0of workarounds for the current behavior (prior 31).= =C2=A0 Of course if you
>=C2=A0 =C2=A0 =C2=A0don't want to make an effort to update your cod= e, what you propose is
>=C2=A0 =C2=A0 =C2=A0simpler (i.e. you have nothing to change on your si= de), but generally we
>=C2=A0 =C2=A0 =C2=A0(external emacs extensions developers) try to adapt= ourselves to Emacs
>=C2=A0 =C2=A0 =C2=A0source and not the contrary.
>
> Thanks for the input.
>
> The idea that I "don't want to make an effort" is insult= ing.

Sorry if you take it like this, it was not the intention.

> =C2=A0 Perhaps a little less coffee.

I don't drink coffee.

>=C2=A0 =C2=A0 =C2=A0> Why not just fix the eww bookmark handler to d= o its own
>=C2=A0 =C2=A0 =C2=A0> save-window-excursion, again, rather than make= a default bookmark jump
>=C2=A0 =C2=A0 =C2=A0> behavior policy change?
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0Because the problem is not just about eww, but more= generally on how
>=C2=A0 =C2=A0 =C2=A0bookmark handlers work.
>
> Curious to know which other ones are broken?=C2=A0 I read eww and w3m.=

It is not only about eww AND w3m.=C2=A0 The point is not if things are brok= en
or not, it is to provide a good API for all bookmarks (and future kind
of bookmarks).


> What do the Emacs maintainers think about this as a matter of taste, > easy adoption for other bookmark users, and idiomatic usage?

Now Eli and other maintainers will decide what is the best for emacs.

You may not have seen it but th= ere is already precedent for bookmark-handler properties in bookmark.el in = bookmark-insert for the 'bookmark-inhibit property on a handler.=C2=A0 = It could contain a list of inhibitions.

I'll submit a patch to make that property into a list.=C2=A0 = It was my code to begin with and used only in shell-bookmark and I should h= ave planned ahead. Even if we don't use it for the above purposes.=C2= =A0

I've attached a patch to bookmark-jump/bookmark--jump-v= ia that supports inhibiting window actions and display function using the &= #39;bookmark-inhibit handler function property list that Michael Albinus pu= shed to master last week.

Usage for bookmark handler authors = is simply:

(put #'xxx-bookmark-handler 'bookmark-in= hibit '(insert
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 jump-window-actions
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 jump-display-func))

I tested this with a= version of bufferlo waiting in the wings and it works nicely.

If we want to add generic bookmark handler functions as a separate enhanc= ement, I'm all for that in the future.

I'd like to see the latest approach I proposed installed.=C2=A0 We c= an add fancier method overrides later.

We have a major version of bufferlo just about r= eady for release and I'd like to ensure that it works well in Emacs 31/= master.
<= br>
We= 9;ve already adopted many of the improvements in Emacs 31; including expose= -hidden-buffer, tab-bar fixes, window-state-get improvements, define-ibuffe= r-op improvements.=C2=A0 For Emacs < 31, bufferlo advises bookmark--jump= -via to avoid display-func when called interactively but it cannot easily a= void save-window-excursion in Emacs 31 without this patch.=C2=A0 Many users= rely on bookmark-bmenu-list and bookmark-jump commands and we'd love t= o be able to continue supporting those use cases.

Shall we, please?

-Stephane
--000000000000d070b6063151db3d-- From unknown Sat Jun 21 05:14:57 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 25 Apr 2025 11:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator