* bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering @ 2022-05-01 16:03 Eli Zaretskii 2022-05-02 1:10 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2022-05-01 16:03 UTC (permalink / raw) To: 55208 The double-buffering feature on MS-Windows has one unpleasant side-effect: when the user opens any GUI selection dialog that is provided by the MS-Windows "toolkit", dragging that dialog leaves its "ghost" shown in the Emacs frame. To reproduce: emacs -Q Click File->Open File Drag the file selection dialog with the mouse Observe that the dialog is indeed dragged, as expected, but it leaves its "ghost" at the original position I think this is related to the fact that, as long as the selection dialog is open, we don't update the Emacs display. With double-buffering disabled, the area across which the dialog is dragged is cleared (the text is not "erased", and only the background remains). Which is also not very nice, but it's much more subtle, so much so that I don't recall any bug reports about this. Showing the "ghost" of the menu there is much more prominent, so I hope we could at least go back to what we have without double-buffering. Bonus points for redrawing the text while the dialog is being dragged. In GNU Emacs 29.0.50 (build 968, i686-pc-mingw32) of 2022-05-01 built on HOME-C4E4A596F7 Repository revision: 9370a4763aacbb9278b5be9c92a2484e3652bc29 Repository branch: master Windowing system distributor 'Microsoft Corp.', version 5.1.2600 System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600) Configured using: 'configure -C --prefix=/d/usr --with-wide-int --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3'' Configured features: ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP XPM ZLIB Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message mailcap yank-media rmc puny rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date seq gv subr-x byte-opt bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils dired dired-loaddefs face-remap iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win 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 simple cl-generic 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 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 w32notify w32 lcms2 multi-tty make-network-process emacs) Memory information: ((conses 16 49989 12437) (symbols 48 6902 1) (strings 16 19268 3097) (string-bytes 1 540461) (vectors 16 11301) (vector-slots 8 161753 13124) (floats 8 25 198) (intervals 40 340 71) (buffers 888 10)) ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering 2022-05-01 16:03 bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering Eli Zaretskii @ 2022-05-02 1:10 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-05-02 2:29 ` Eli Zaretskii 2022-05-07 7:40 ` Eli Zaretskii 0 siblings, 2 replies; 13+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-05-02 1:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 55208 Eli Zaretskii <eliz@gnu.org> writes: > The double-buffering feature on MS-Windows has one unpleasant > side-effect: when the user opens any GUI selection dialog that is > provided by the MS-Windows "toolkit", dragging that dialog leaves its > "ghost" shown in the Emacs frame. > > To reproduce: > > emacs -Q > Click File->Open File > Drag the file selection dialog with the mouse > Observe that the dialog is indeed dragged, as expected, but it leaves > its "ghost" at the original position > > I think this is related to the fact that, as long as the selection > dialog is open, we don't update the Emacs display. With > double-buffering disabled, the area across which the dialog is dragged > is cleared (the text is not "erased", and only the background > remains). Which is also not very nice, but it's much more subtle, so > much so that I don't recall any bug reports about this. Showing the > "ghost" of the menu there is much more prominent, so I hope we could > at least go back to what we have without double-buffering. Bonus > points for redrawing the text while the dialog is being dragged. I think the version of MS Windows I used to test the double-buffering feature doesn't overwrite the contents of windows underneath the topmost window, which is why I don't see that bug. But try adding some code along the following lines under `WM_PAINT' in `w32_msg_pump': if (popup is active) { enter_crit (); if (FRAME_OUTPUT_DATA (f)->paint_dc) { BeginPaint (hwnd, &paintStruct); BitBlt (FRAME_OUTPUT_DATA (f)->paint_buffer_handle, 0, 0, FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f), FRAME_OUTPUT_DATA (f)->paint_dc, 0, 0, SRCCOPY); EndPaint (hwnd, &paintStruct); } leave_crit (); return 0; } (I don't know how to implement the "popup is active" part, unfortunately.) Thanks. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering 2022-05-02 1:10 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-05-02 2:29 ` Eli Zaretskii 2022-05-02 2:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-05-07 7:40 ` Eli Zaretskii 1 sibling, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2022-05-02 2:29 UTC (permalink / raw) To: Po Lu; +Cc: 55208 > From: Po Lu <luangruo@yahoo.com> > Cc: 55208@debbugs.gnu.org > Date: Mon, 02 May 2022 09:10:53 +0800 > > I think the version of MS Windows I used to test the double-buffering > feature doesn't overwrite the contents of windows underneath the topmost > window, which is why I don't see that bug. What _do_ you see when you drag the selection dialog box with the mouse? ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering 2022-05-02 2:29 ` Eli Zaretskii @ 2022-05-02 2:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 0 replies; 13+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-05-02 2:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 55208 Eli Zaretskii <eliz@gnu.org> writes: > What _do_ you see when you drag the selection dialog box with the > mouse? Nothing out of the ordinary: the contents in the frame underneath the selection dialog box are preserved. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering 2022-05-02 1:10 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-05-02 2:29 ` Eli Zaretskii @ 2022-05-07 7:40 ` Eli Zaretskii 2022-05-07 8:26 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 1 sibling, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2022-05-07 7:40 UTC (permalink / raw) To: Po Lu; +Cc: 55208 > From: Po Lu <luangruo@yahoo.com> > Cc: 55208@debbugs.gnu.org > Date: Mon, 02 May 2022 09:10:53 +0800 > > But try adding some code along the following lines under `WM_PAINT' in > `w32_msg_pump': w32_msg_pump doesn't handle WM_PAINT, so I'm not sure what you mean here. Also, AFAIK w32_msg_pump runs in a separate thread, so is it safe to call BitBlt from that thread? > if (popup is active) > { > enter_crit (); > if (FRAME_OUTPUT_DATA (f)->paint_dc) > { > BeginPaint (hwnd, &paintStruct); > > BitBlt (FRAME_OUTPUT_DATA (f)->paint_buffer_handle, > 0, 0, FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f), > FRAME_OUTPUT_DATA (f)->paint_dc, 0, 0, SRCCOPY); > > EndPaint (hwnd, &paintStruct); > } > leave_crit (); > > return 0; > } > > (I don't know how to implement the "popup is active" part, > unfortunately.) I do know, but the above issues bother me more, so I didn't yet try this. Thanks. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering 2022-05-07 7:40 ` Eli Zaretskii @ 2022-05-07 8:26 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-05-07 9:02 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-05-07 8:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 55208 Eli Zaretskii <eliz@gnu.org> writes: > w32_msg_pump doesn't handle WM_PAINT, so I'm not sure what you mean > here. Also, AFAIK w32_msg_pump runs in a separate thread, so is it > safe to call BitBlt from that thread? Sorry, I meant `w32_msg_pump'. But it should be safe as long as the painting is done inside the critical section, which protects all modifications to the paint buffer (and its handle.) > I do know, but the above issues bother me more, so I didn't yet try > this. I tried to explain above, thanks. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering 2022-05-07 8:26 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-05-07 9:02 ` Eli Zaretskii 2022-05-07 9:19 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2022-05-07 9:02 UTC (permalink / raw) To: Po Lu; +Cc: 55208 > From: Po Lu <luangruo@yahoo.com> > Cc: 55208@debbugs.gnu.org > Date: Sat, 07 May 2022 16:26:39 +0800 > > Eli Zaretskii <eliz@gnu.org> writes: > > > w32_msg_pump doesn't handle WM_PAINT, so I'm not sure what you mean > > here. Also, AFAIK w32_msg_pump runs in a separate thread, so is it > > safe to call BitBlt from that thread? > > Sorry, I meant `w32_msg_pump'. That's what I said: w32_msg_pump doesn't currently handle WM_PAINT, it only handles WM_EMACS_* messages we send to it. Did you mean w32_wnd_proc instead? Or what am I missing? ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering 2022-05-07 9:02 ` Eli Zaretskii @ 2022-05-07 9:19 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-05-07 10:06 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-05-07 9:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 55208 Eli Zaretskii <eliz@gnu.org> writes: > That's what I said: w32_msg_pump doesn't currently handle WM_PAINT, it > only handles WM_EMACS_* messages we send to it. Did you mean > w32_wnd_proc instead? Or what am I missing? Silly me! I did indeed mean `w32_wnd_proc'. Thanks. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering 2022-05-07 9:19 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-05-07 10:06 ` Eli Zaretskii 2022-05-07 10:23 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2022-05-07 10:06 UTC (permalink / raw) To: Po Lu; +Cc: 55208 > From: Po Lu <luangruo@yahoo.com> > Cc: 55208@debbugs.gnu.org > Date: Sat, 07 May 2022 17:19:18 +0800 > > Eli Zaretskii <eliz@gnu.org> writes: > > > That's what I said: w32_msg_pump doesn't currently handle WM_PAINT, it > > only handles WM_EMACS_* messages we send to it. Did you mean > > w32_wnd_proc instead? Or what am I missing? > > Silly me! I did indeed mean `w32_wnd_proc'. Thanks, the below seems to fix the problem here on XP. Does the patch look reasonable, and if so, could you perhaps test it on some newer version of Windows, to see that it doesn't cause any regressions there? diff --git a/src/w32fns.c b/src/w32fns.c index 0f25c1a..d2da943 100644 --- a/src/w32fns.c +++ b/src/w32fns.c @@ -247,6 +247,8 @@ #define MENU_FREE_DELAY 1000 static int w32_unicode_gui; +static struct frame *w32_selection_dialog_open_frame = NULL; + /* From w32menu.c */ int menubar_in_use = 0; @@ -4184,6 +4186,16 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) update_rect.left, update_rect.top, update_rect.right, update_rect.bottom)); #endif + /* Under double-buffering, update the frame from the back + buffer, to prevent a "ghost" of the selection dialog to + be left on display while the user selects in the dialog. */ + if (w32_selection_dialog_open_frame == f + && !w32_disable_double_buffering + && FRAME_OUTPUT_DATA (f)->paint_dc) + BitBlt (FRAME_OUTPUT_DATA (f)->paint_buffer_handle, + 0, 0, FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f), + FRAME_OUTPUT_DATA (f)->paint_dc, 0, 0, SRCCOPY); + EndPaint (hwnd, &paintStruct); leave_crit (); @@ -7754,6 +7766,16 @@ file_dialog_callback (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) w32_dialog_in_progress (Lisp_Object in_progress) { Lisp_Object frames, frame; + struct frame *f = SELECTED_FRAME (); + + /* If the current frame has double-buffering enabled, indicate to + w32_wnd_proc that the selection dialog is about to be open. */ + if (FRAME_OUTPUT_DATA (f)->want_paint_buffer) + { + enter_crit (); + w32_selection_dialog_open_frame = NILP (in_progress) ? NULL : f; + leave_crit (); + } /* Don't let frames in `above' z-group obscure dialog windows. */ FOR_EACH_FRAME (frames, frame) ^ permalink raw reply related [flat|nested] 13+ messages in thread
* bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering 2022-05-07 10:06 ` Eli Zaretskii @ 2022-05-07 10:23 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-05-07 10:41 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-05-07 10:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 55208 Eli Zaretskii <eliz@gnu.org> writes: > Thanks, the below seems to fix the problem here on XP. Does the patch > look reasonable, and if so, could you perhaps test it on some newer > version of Windows, to see that it doesn't cause any regressions > there? I don't have access to the Windows machine(s) at this time of day. The patch looks good to me (though I wonder what happens if a WM_PAINT message is received for a frame other than `w32_selection_dialog_open_frame'), and I will test it ASAP. Thanks. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering 2022-05-07 10:23 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-05-07 10:41 ` Eli Zaretskii 2022-05-08 5:33 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2022-05-07 10:41 UTC (permalink / raw) To: Po Lu; +Cc: 55208 > From: Po Lu <luangruo@yahoo.com> > Cc: 55208@debbugs.gnu.org > Date: Sat, 07 May 2022 18:23:10 +0800 > > Eli Zaretskii <eliz@gnu.org> writes: > > > Thanks, the below seems to fix the problem here on XP. Does the patch > > look reasonable, and if so, could you perhaps test it on some newer > > version of Windows, to see that it doesn't cause any regressions > > there? > > I don't have access to the Windows machine(s) at this time of day. The > patch looks good to me (though I wonder what happens if a WM_PAINT > message is received for a frame other than > `w32_selection_dialog_open_frame') Hmm... you are right. An updated patch below. > and I will test it ASAP. Thanks. diff --git a/src/w32fns.c b/src/w32fns.c index 0f25c1a..e5becb5 100644 --- a/src/w32fns.c +++ b/src/w32fns.c @@ -247,6 +247,8 @@ #define MENU_FREE_DELAY 1000 static int w32_unicode_gui; +static bool w32_selection_dialog_open; + /* From w32menu.c */ int menubar_in_use = 0; @@ -4184,6 +4186,16 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) update_rect.left, update_rect.top, update_rect.right, update_rect.bottom)); #endif + /* Under double-buffering, update the frame from the back + buffer, to prevent a "ghost" of the selection dialog to + be left on display while the user selects in the dialog. */ + if (w32_selection_dialog_open + && !w32_disable_double_buffering + && FRAME_OUTPUT_DATA (f)->paint_dc) + BitBlt (FRAME_OUTPUT_DATA (f)->paint_buffer_handle, + 0, 0, FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f), + FRAME_OUTPUT_DATA (f)->paint_dc, 0, 0, SRCCOPY); + EndPaint (hwnd, &paintStruct); leave_crit (); @@ -7755,6 +7767,15 @@ w32_dialog_in_progress (Lisp_Object in_progress) { Lisp_Object frames, frame; + /* Indicate to w32_wnd_proc that the selection dialog is about to be + open (or was closed, if IN_PROGRESS is nil). */ + if (!w32_disable_double_buffering) + { + enter_crit (); + w32_selection_dialog_open = !NILP (in_progress); + leave_crit (); + } + /* Don't let frames in `above' z-group obscure dialog windows. */ FOR_EACH_FRAME (frames, frame) { ^ permalink raw reply related [flat|nested] 13+ messages in thread
* bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering 2022-05-07 10:41 ` Eli Zaretskii @ 2022-05-08 5:33 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-05-08 6:26 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-05-08 5:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 55208 Eli Zaretskii <eliz@gnu.org> writes: > diff --git a/src/w32fns.c b/src/w32fns.c > index 0f25c1a..e5becb5 100644 > --- a/src/w32fns.c > +++ b/src/w32fns.c > @@ -247,6 +247,8 @@ #define MENU_FREE_DELAY 1000 > > static int w32_unicode_gui; > > +static bool w32_selection_dialog_open; > + > /* From w32menu.c */ > int menubar_in_use = 0; > > @@ -4184,6 +4186,16 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) > update_rect.left, update_rect.top, > update_rect.right, update_rect.bottom)); > #endif > + /* Under double-buffering, update the frame from the back > + buffer, to prevent a "ghost" of the selection dialog to > + be left on display while the user selects in the dialog. */ > + if (w32_selection_dialog_open > + && !w32_disable_double_buffering > + && FRAME_OUTPUT_DATA (f)->paint_dc) > + BitBlt (FRAME_OUTPUT_DATA (f)->paint_buffer_handle, > + 0, 0, FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f), > + FRAME_OUTPUT_DATA (f)->paint_dc, 0, 0, SRCCOPY); > + > EndPaint (hwnd, &paintStruct); > leave_crit (); > > @@ -7755,6 +7767,15 @@ w32_dialog_in_progress (Lisp_Object in_progress) > { > Lisp_Object frames, frame; > > + /* Indicate to w32_wnd_proc that the selection dialog is about to be > + open (or was closed, if IN_PROGRESS is nil). */ > + if (!w32_disable_double_buffering) > + { > + enter_crit (); > + w32_selection_dialog_open = !NILP (in_progress); > + leave_crit (); > + } > + > /* Don't let frames in `above' z-group obscure dialog windows. */ > FOR_EACH_FRAME (frames, frame) > { This seems to work fine, please go ahead and install it. Thanks. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering 2022-05-08 5:33 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-05-08 6:26 ` Eli Zaretskii 0 siblings, 0 replies; 13+ messages in thread From: Eli Zaretskii @ 2022-05-08 6:26 UTC (permalink / raw) To: Po Lu; +Cc: 55208-done > From: Po Lu <luangruo@yahoo.com> > Cc: 55208@debbugs.gnu.org > Date: Sun, 08 May 2022 13:33:40 +0800 > > This seems to work fine, please go ahead and install it. Thanks. Thanks. Installed and closing the bug. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-05-08 6:26 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-05-01 16:03 bug#55208: 29.0.50; MS-Windows GUI selection dialogs and double-buffering Eli Zaretskii 2022-05-02 1:10 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-05-02 2:29 ` Eli Zaretskii 2022-05-02 2:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-05-07 7:40 ` Eli Zaretskii 2022-05-07 8:26 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-05-07 9:02 ` Eli Zaretskii 2022-05-07 9:19 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-05-07 10:06 ` Eli Zaretskii 2022-05-07 10:23 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-05-07 10:41 ` Eli Zaretskii 2022-05-08 5:33 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-05-08 6:26 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).