* bug#37495: 27.0.50; lwindow doesn't pass to system @ 2019-09-24 1:22 Albert 2019-09-24 4:41 ` Juanma Barranquero 2019-09-24 23:53 ` Juanma Barranquero 0 siblings, 2 replies; 40+ messages in thread From: Albert @ 2019-09-24 1:22 UTC (permalink / raw) To: 37495 [-- Attachment #1: Type: text/plain, Size: 6023 bytes --] Subject: 27.0.50; lwindow doesn't pass to system --text follows this line-- lwindow doesn't pass to system with default settings. Win+D and Win+R don't pass to system, these keys are ignored by emacs. In GNU Emacs 27.0.50 (build 1, x86_64-w64-mingw32) of 2019-09-19 built on CIRROCUMULUS Repository revision: 61c2183a440c94ab797696d0f0c76a7dc4007eeb Repository branch: master Windowing system distributor 'Microsoft Corp.', version 10.0.18362 System Description: Microsoft Windows 10 Home China (v10.0.1903.18362.356) Recent messages: Configuring package winum...done Loading package winum...done Configuring package undo-tree...done Loading e:/home/albert/.emacs.d/Albert.el (source)...done Loaded e:/home/albert/.emacs.d/Albert.el Configuring package doom-modeline...done For information about GNU Emacs and the GNU system, type C-h C-a. Emacs loaded 81 packages in 4.587s evil-signal-at-eob: End of buffer [4 times] Configuring package helm...done (0.327s) Configured using: 'configure --without-dbus --host=x86_64-w64-mingw32 --without-compress-install -C 'CFLAGS=-O2 -static -g3'' Configured features: XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2 HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS THREADS PDUMPER LCMS2 GMP Important settings: value of $LANG: zh_CN locale-coding-system: cp936 Major mode: Lisp Interaction Minor modes in effect: helm-mode: t display-line-numbers-mode: t doom-modeline-mode: t winum-mode: t display-time-mode: t global-paren-face-mode: t paren-face-mode: t highlight-parentheses-mode: t global-highlight-parentheses-mode: t global-undo-tree-mode: t undo-tree-mode: t shell-dirtrack-mode: t evil-mode: t evil-local-mode: t save-place-mode: t show-paren-mode: t auto-compile-on-load-mode: t override-global-mode: t cl-old-struct-compat-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t auto-save-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail rmail-loaddefs text-property-search mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils winner helm-command helm-elisp helm-eval edebug backtrace helm-info helm-mode helm-files helm-buffers helm-occur helm-tags helm-locate helm-grep helm-regexp helm-utils helm-help helm-types helm helm-source eieio-compat helm-multi-match helm-lib async display-line-numbers doom-modeline doom-modeline-segments doom-modeline-env doom-modeline-core shrink-path rx f s all-the-icons all-the-icons-faces data-material data-weathericons data-octicons data-fileicons data-faicons data-alltheicons memoize org-crypt ob-plantuml ob-dot org-clock winum dash pcase diminish time doom-themes-ext-org doom-themes-ext-treemacs doom-themes-ext-visual-bell face-remap doom-deeper-blue-theme doom-themes doom-themes-base avoid paren-face highlight-parentheses ido evil evil-keybindings evil-integration undo-tree diff evil-maps evil-commands reveal flyspell ispell evil-jumps evil-command-window evil-types evil-search evil-ex shell evil-macros evil-repeat evil-states evil-core evil-common windmove thingatpt rect evil-digraphs evil-vars edmacro kmacro saveplace paren auto-compile packed cl-extra help-mode use-package use-package-ensure use-package-delight use-package-diminish use-package-bind-key bind-key use-package-core org-element avl-tree generator org org-macro org-footnote org-pcomplete pcomplete org-list org-faces org-entities time-date noutline outline easy-mmode org-version ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob ob-table ob-keys ob-exp ob-comint comint ansi-color ring ob-core ob-eval org-compat org-macs org-loaddefs format-spec find-func cal-menu calendar cal-loaddefs benchmark-init advice benchmark-init-modes finder-inf org2blog-autoloads info package easymenu browse-url url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib china-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type 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 elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame 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 charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty make-network-process emacs) Memory information: ((conses 16 279852 219671) (symbols 48 24099 1) (strings 32 81731 25777) (string-bytes 1 2745266) (vectors 16 36873) (vector-slots 8 478717 141520) (floats 8 804 1291) (intervals 56 352 383) (buffers 992 13)) [-- Attachment #2: Type: text/html, Size: 6301 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-24 1:22 bug#37495: 27.0.50; lwindow doesn't pass to system Albert @ 2019-09-24 4:41 ` Juanma Barranquero 2019-09-24 13:05 ` bug#37495: �ظ��� " Albert 2019-09-24 23:53 ` Juanma Barranquero 1 sibling, 1 reply; 40+ messages in thread From: Juanma Barranquero @ 2019-09-24 4:41 UTC (permalink / raw) To: Albert; +Cc: 37495 [-- Attachment #1: Type: text/plain, Size: 6226 bytes --] Did you try setting them like: (setq w32-lwindow-modifier 'super) (w32-register-hot-key [s-]) ;; this needs to be *after* the setq above (define-key global-map [?\s-r] 'my-s-r-command) (define-key global-map [?\s-d 'my-s-d-command) ? On Tue, Sep 24, 2019 at 3:50 AM Albert <georgealbert@qq.com> wrote: > Subject: 27.0.50; lwindow doesn't pass to system > --text follows this line-- > > lwindow doesn't pass to system with default settings. Win+D and Win+R > don't pass to system, these keys are ignored by emacs. > > > In GNU Emacs 27.0.50 (build 1, x86_64-w64-mingw32) > of 2019-09-19 built on CIRROCUMULUS > Repository revision: 61c2183a440c94ab797696d0f0c76a7dc4007eeb > Repository branch: master > Windowing system distributor 'Microsoft Corp.', version 10.0.18362 > System Description: Microsoft Windows 10 Home China (v10.0.1903.18362.356) > > Recent messages: > Configuring package winum...done > Loading package winum...done > Configuring package undo-tree...done > Loading e:/home/albert/.emacs.d/Albert.el (source)...done > Loaded e:/home/albert/.emacs.d/Albert.el > Configuring package doom-modeline...done > For information about GNU Emacs and the GNU system, type C-h C-a. > Emacs loaded 81 packages in 4.587s > evil-signal-at-eob: End of buffer [4 times] > Configuring package helm...done (0.327s) > > Configured using: > 'configure --without-dbus --host=x86_64-w64-mingw32 > --without-compress-install -C 'CFLAGS=-O2 -static -g3'' > > Configured features: > XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2 > HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS THREADS PDUMPER LCMS2 GMP > > Important settings: > value of $LANG: zh_CN > locale-coding-system: cp936 > > Major mode: Lisp Interaction > > Minor modes in effect: > helm-mode: t > display-line-numbers-mode: t > doom-modeline-mode: t > winum-mode: t > display-time-mode: t > global-paren-face-mode: t > paren-face-mode: t > highlight-parentheses-mode: t > global-highlight-parentheses-mode: t > global-undo-tree-mode: t > undo-tree-mode: t > shell-dirtrack-mode: t > evil-mode: t > evil-local-mode: t > save-place-mode: t > show-paren-mode: t > auto-compile-on-load-mode: t > override-global-mode: t > cl-old-struct-compat-mode: t > tooltip-mode: t > global-eldoc-mode: t > eldoc-mode: t > electric-indent-mode: t > mouse-wheel-mode: t > file-name-shadow-mode: t > global-font-lock-mode: t > font-lock-mode: t > blink-cursor-mode: t > auto-composition-mode: t > auto-encryption-mode: t > auto-compression-mode: t > column-number-mode: t > line-number-mode: t > transient-mark-mode: t > auto-save-mode: t > > Load-path shadows: > None found. > > Features: > (shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs > rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail > rmail-loaddefs text-property-search mm-decode mm-bodies mm-encode > mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 > rfc2045 ietf-drums mm-util mail-prsvr mail-utils winner helm-command > helm-elisp helm-eval edebug backtrace helm-info helm-mode helm-files > helm-buffers helm-occur helm-tags helm-locate helm-grep helm-regexp > helm-utils helm-help helm-types helm helm-source eieio-compat > helm-multi-match helm-lib async display-line-numbers doom-modeline > doom-modeline-segments doom-modeline-env doom-modeline-core shrink-path > rx f s all-the-icons all-the-icons-faces data-material data-weathericons > data-octicons data-fileicons data-faicons data-alltheicons memoize > org-crypt ob-plantuml ob-dot org-clock winum dash pcase diminish time > doom-themes-ext-org doom-themes-ext-treemacs doom-themes-ext-visual-bell > face-remap doom-deeper-blue-theme doom-themes doom-themes-base avoid > paren-face highlight-parentheses ido evil evil-keybindings > evil-integration undo-tree diff evil-maps evil-commands reveal flyspell > ispell evil-jumps evil-command-window evil-types evil-search evil-ex > shell evil-macros evil-repeat evil-states evil-core evil-common windmove > thingatpt rect evil-digraphs evil-vars edmacro kmacro saveplace paren > auto-compile packed cl-extra help-mode use-package use-package-ensure > use-package-delight use-package-diminish use-package-bind-key bind-key > use-package-core org-element avl-tree generator org org-macro > org-footnote org-pcomplete pcomplete org-list org-faces org-entities > time-date noutline outline easy-mmode org-version ob-emacs-lisp ob > ob-tangle org-src ob-ref ob-lob ob-table ob-keys ob-exp ob-comint comint > ansi-color ring ob-core ob-eval org-compat org-macs org-loaddefs > format-spec find-func cal-menu calendar cal-loaddefs benchmark-init > advice benchmark-init-modes finder-inf org2blog-autoloads info package > easymenu browse-url url-handlers url-parse auth-source cl-seq eieio > eieio-core cl-macs eieio-loaddefs password-cache json subr-x map > url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib > china-util tooltip eldoc electric uniquify ediff-hook vc-hooks > lisp-float-type 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 elisp-mode lisp-mode > prog-mode register page menu-bar rfn-eshadow isearch timer select > scroll-bar mouse jit-lock font-lock syntax facemenu font-core > term/tty-colors frame 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 charscript charprop case-table epa-hook jka-cmpr-hook > help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs > button faces cus-face macroexp files text-properties overlay sha1 md5 > base64 format env code-pages mule custom widget hashtable-print-readable > backquote threads w32notify w32 lcms2 multi-tty make-network-process > emacs) > > Memory information: > ((conses 16 279852 219671) > (symbols 48 24099 1) > (strings 32 81731 25777) > (string-bytes 1 2745266) > (vectors 16 36873) > (vector-slots 8 478717 141520) > (floats 8 804 1291) > (intervals 56 352 383) > (buffers 992 13)) > [-- Attachment #2: Type: text/html, Size: 6906 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: �ظ��� bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-24 4:41 ` Juanma Barranquero @ 2019-09-24 13:05 ` Albert 2019-09-24 13:50 ` Juanma Barranquero 0 siblings, 1 reply; 40+ messages in thread From: Albert @ 2019-09-24 13:05 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 37495 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1.1: Type: text/plain; charset="gb18030", Size: 6762 bytes --] Thanks for reply. I tried the setting. ------------------ ÔʼÓʼþ ------------------ ·¢¼þÈË: "Juanma Barranquero"<lekktu@gmail.com>; ·¢ËÍʱ¼ä: 2019Äê9ÔÂ24ÈÕ(ÐÇÆÚ¶þ) ÖÐÎç12:41 ÊÕ¼þÈË: "Albert"<georgealbert@qq.com>; ³ËÍ: "37495"<37495@debbugs.gnu.org>; Ö÷Ìâ: Re: bug#37495: 27.0.50; lwindow doesn't pass to system Did you try setting them like: (setq w32-lwindow-modifier 'super) (w32-register-hot-key [s-]) ;; this needs to be *after* the setq above (define-key global-map [?\s-r] 'my-s-r-command) (define-key global-map [?\s-d 'my-s-d-command) ? On Tue, Sep 24, 2019 at 3:50 AM Albert <georgealbert@qq.com> wrote: Subject: 27.0.50; lwindow doesn't pass to system --text follows this line-- lwindow doesn't pass to system with default settings. Win+D and Win+R don't pass to system, these keys are ignored by emacs. In GNU Emacs 27.0.50 (build 1, x86_64-w64-mingw32) of 2019-09-19 built on CIRROCUMULUS Repository revision: 61c2183a440c94ab797696d0f0c76a7dc4007eeb Repository branch: master Windowing system distributor 'Microsoft Corp.', version 10.0.18362 System Description: Microsoft Windows 10 Home China (v10.0.1903.18362.356) Recent messages: Configuring package winum...done Loading package winum...done Configuring package undo-tree...done Loading e:/home/albert/.emacs.d/Albert.el (source)...done Loaded e:/home/albert/.emacs.d/Albert.el Configuring package doom-modeline...done For information about GNU Emacs and the GNU system, type C-h C-a. Emacs loaded 81 packages in 4.587s evil-signal-at-eob: End of buffer [4 times] Configuring package helm...done (0.327s) Configured using: 'configure --without-dbus --host=x86_64-w64-mingw32 --without-compress-install -C 'CFLAGS=-O2 -static -g3'' Configured features: XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2 HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS THREADS PDUMPER LCMS2 GMP Important settings: value of $LANG: zh_CN locale-coding-system: cp936 Major mode: Lisp Interaction Minor modes in effect: helm-mode: t display-line-numbers-mode: t doom-modeline-mode: t winum-mode: t display-time-mode: t global-paren-face-mode: t paren-face-mode: t highlight-parentheses-mode: t global-highlight-parentheses-mode: t global-undo-tree-mode: t undo-tree-mode: t shell-dirtrack-mode: t evil-mode: t evil-local-mode: t save-place-mode: t show-paren-mode: t auto-compile-on-load-mode: t override-global-mode: t cl-old-struct-compat-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t auto-save-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail rmail-loaddefs text-property-search mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils winner helm-command helm-elisp helm-eval edebug backtrace helm-info helm-mode helm-files helm-buffers helm-occur helm-tags helm-locate helm-grep helm-regexp helm-utils helm-help helm-types helm helm-source eieio-compat helm-multi-match helm-lib async display-line-numbers doom-modeline doom-modeline-segments doom-modeline-env doom-modeline-core shrink-path rx f s all-the-icons all-the-icons-faces data-material data-weathericons data-octicons data-fileicons data-faicons data-alltheicons memoize org-crypt ob-plantuml ob-dot org-clock winum dash pcase diminish time doom-themes-ext-org doom-themes-ext-treemacs doom-themes-ext-visual-bell face-remap doom-deeper-blue-theme doom-themes doom-themes-base avoid paren-face highlight-parentheses ido evil evil-keybindings evil-integration undo-tree diff evil-maps evil-commands reveal flyspell ispell evil-jumps evil-command-window evil-types evil-search evil-ex shell evil-macros evil-repeat evil-states evil-core evil-common windmove thingatpt rect evil-digraphs evil-vars edmacro kmacro saveplace paren auto-compile packed cl-extra help-mode use-package use-package-ensure use-package-delight use-package-diminish use-package-bind-key bind-key use-package-core org-element avl-tree generator org org-macro org-footnote org-pcomplete pcomplete org-list org-faces org-entities time-date noutline outline easy-mmode org-version ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob ob-table ob-keys ob-exp ob-comint comint ansi-color ring ob-core ob-eval org-compat org-macs org-loaddefs format-spec find-func cal-menu calendar cal-loaddefs benchmark-init advice benchmark-init-modes finder-inf org2blog-autoloads info package easymenu browse-url url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib china-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type 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 elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame 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 charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty make-network-process emacs) Memory information: ((conses 16 279852 219671) (symbols 48 24099 1) (strings 32 81731 25777) (string-bytes 1 2745266) (vectors 16 36873) (vector-slots 8 478717 141520) (floats 8 804 1291) (intervals 56 352 383) (buffers 992 13)) [-- Attachment #1.2: Type: text/html, Size: 7958 bytes --] [-- Attachment #2: 2A05D014@5964794E.7E148A5D.jpg --] [-- Type: image/jpeg, Size: 70368 bytes --] [-- Attachment #3: 2703CD18@B03B2226.7E148A5D.jpg --] [-- Type: image/jpeg, Size: 70368 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-24 13:05 ` bug#37495: �ظ��� " Albert @ 2019-09-24 13:50 ` Juanma Barranquero 2019-09-24 16:39 ` Eli Zaretskii 0 siblings, 1 reply; 40+ messages in thread From: Juanma Barranquero @ 2019-09-24 13:50 UTC (permalink / raw) To: Albert; +Cc: 37495 [-- Attachment #1.1: Type: text/plain, Size: 639 bytes --] I see two problems in your image, but none of them are related to being unable to redefine lwindow. The first one is that I omitted a closing ] in the second define-key command. Sorry. But it seems you corrected it, The second one is about my-s-d-command, which obviously won't work because it does not exist. It was just an example command for you to substitute. So, in other words, if you do (setq w32-lwindow-modifier 'super) (w32-register-hot-key [s-]) (define-key global-map [?\s-r] 'list-buffers) (define-key global-map [?\s-d] 'make-frame-command) does lwindow+r run list-buffers? And does lwindow+d make a new frame? [-- Attachment #1.2: Type: text/html, Size: 846 bytes --] [-- Attachment #2: 2A05D014@5964794E.7E148A5D.jpg --] [-- Type: image/jpeg, Size: 70368 bytes --] [-- Attachment #3: 2703CD18@B03B2226.7E148A5D.jpg --] [-- Type: image/jpeg, Size: 70368 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-24 13:50 ` Juanma Barranquero @ 2019-09-24 16:39 ` Eli Zaretskii 2019-09-24 16:43 ` bug#37495: �ظ��� " Albert 2019-09-24 16:55 ` Juanma Barranquero 0 siblings, 2 replies; 40+ messages in thread From: Eli Zaretskii @ 2019-09-24 16:39 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 37495, georgealbert > From: Juanma Barranquero <lekktu@gmail.com> > Date: Tue, 24 Sep 2019 15:50:35 +0200 > Cc: 37495 <37495@debbugs.gnu.org> > > I see two problems in your image, but none of them are related to being unable to redefine lwindow. I thought the OP said that lwindow doesn't work for him _without_ redefining it. IOW, the default action of the key is somehow intercepted by Emacs when it shouldn't be. Am I confused? ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: �ظ��� bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-24 16:39 ` Eli Zaretskii @ 2019-09-24 16:43 ` Albert 2019-09-24 16:55 ` Juanma Barranquero 1 sibling, 0 replies; 40+ messages in thread From: Albert @ 2019-09-24 16:43 UTC (permalink / raw) To: Eli Zaretskii, Juanma Barranquero; +Cc: 37495 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="gb18030", Size: 927 bytes --] yes, Iwindow key with the default setting(nil) doesn't work as expected, it should be passed to windows. ------------------ ÔʼÓʼþ ------------------ ·¢¼þÈË: "Eli Zaretskii"<eliz@gnu.org>; ·¢ËÍʱ¼ä: 2019Äê9ÔÂ25ÈÕ(ÐÇÆÚÈý) Á賿0:39 ÊÕ¼þÈË: "Juanma Barranquero"<lekktu@gmail.com>; ³ËÍ: "Albert"<georgealbert@qq.com>;"37495"<37495@debbugs.gnu.org>; Ö÷Ìâ: Re: bug#37495: 27.0.50; lwindow doesn't pass to system > From: Juanma Barranquero <lekktu@gmail.com> > Date: Tue, 24 Sep 2019 15:50:35 +0200 > Cc: 37495 <37495@debbugs.gnu.org> > > I see two problems in your image, but none of them are related to being unable to redefine lwindow. I thought the OP said that lwindow doesn't work for him _without_ redefining it. IOW, the default action of the key is somehow intercepted by Emacs when it shouldn't be. Am I confused? [-- Attachment #2: Type: text/html, Size: 1250 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-24 16:39 ` Eli Zaretskii 2019-09-24 16:43 ` bug#37495: �ظ��� " Albert @ 2019-09-24 16:55 ` Juanma Barranquero 2019-09-24 16:59 ` bug#37495: �ظ��� " Albert 2019-09-24 17:17 ` Eli Zaretskii 1 sibling, 2 replies; 40+ messages in thread From: Juanma Barranquero @ 2019-09-24 16:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 37495, georgealbert [-- Attachment #1: Type: text/plain, Size: 478 bytes --] On Tue, Sep 24, 2019 at 6:39 PM Eli Zaretskii <eliz@gnu.org> wrote: > I thought the OP said that lwindow doesn't work for him _without_ > redefining it. IOW, the default action of the key is somehow > intercepted by Emacs when it shouldn't be. > > Am I confused? No, you're right and I was. I misunderstood. But then, he says "Iwindow key with the default setting(nil)". But w32-pass-lwindow-to-system's default value is t, both in 26.2 and 27.0.50. So I'm still confused. [-- Attachment #2: Type: text/html, Size: 718 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: �ظ��� bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-24 16:55 ` Juanma Barranquero @ 2019-09-24 16:59 ` Albert 2019-09-24 17:17 ` Juanma Barranquero 2019-09-24 17:17 ` Eli Zaretskii 1 sibling, 1 reply; 40+ messages in thread From: Albert @ 2019-09-24 16:59 UTC (permalink / raw) To: Juanma Barranquero, Eli Zaretskii; +Cc: 37495 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="gb18030", Size: 1014 bytes --] I'm sorry, the default value of w32-pass-lwindow-to-system is t. I dont' change w32-pass-lwindow-to-system in init file. ------------------ ÔʼÓʼþ ------------------ ·¢¼þÈË: "Juanma Barranquero"<lekktu@gmail.com>; ·¢ËÍʱ¼ä: 2019Äê9ÔÂ25ÈÕ(ÐÇÆÚÈý) Á賿0:55 ÊÕ¼þÈË: "Eli Zaretskii"<eliz@gnu.org>; ³ËÍ: "Albert"<georgealbert@qq.com>;"37495"<37495@debbugs.gnu.org>; Ö÷Ìâ: Re: bug#37495: 27.0.50; lwindow doesn't pass to system On Tue, Sep 24, 2019 at 6:39 PM Eli Zaretskii <eliz@gnu.org> wrote: > I thought the OP said that lwindow doesn't work for him _without_ > redefining it. IOW, the default action of the key is somehow > intercepted by Emacs when it shouldn't be. > > Am I confused? No, you're right and I was. I misunderstood. But then, he says "Iwindow key with the default setting(nil)". But w32-pass-lwindow-to-system's default value is t, both in 26.2 and 27.0.50. So I'm still confused. [-- Attachment #2: Type: text/html, Size: 1473 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-24 16:59 ` bug#37495: �ظ��� " Albert @ 2019-09-24 17:17 ` Juanma Barranquero 2019-09-24 19:29 ` bug#37495: �ظ��� " Albert 0 siblings, 1 reply; 40+ messages in thread From: Juanma Barranquero @ 2019-09-24 17:17 UTC (permalink / raw) To: Albert; +Cc: 37495 [-- Attachment #1: Type: text/plain, Size: 790 bytes --] On Tue, Sep 24, 2019 at 6:59 PM Albert <georgealbert@qq.com> wrote: > I'm sorry, the default value of w32-pass-lwindow-to-system is t. I dont' change w32-pass-lwindow-to-system in init file. So, let's recapitulate. - You start Emacs 27.0.50 - In your init file(s), you do not change the default value of w32-pass-lwindow-to-system - While Emacs has the focus, if you press an lwindow combination, Emacs catches it and it is not passed back to Windows. - So, from inside 27.0.50, you cannot do LWin+R o LWin+D, etc. - But this didn't happen with Emacs 26.2. Am I right now? If so, when you're inside Emacs 27.0.50, what does it say when you examine the value of w32-pass-lwindow-to-system? For example, with describe-variable. Does still happen if you start Emacs with emacs -Q ? [-- Attachment #2: Type: text/html, Size: 1123 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: �ظ��� bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-24 17:17 ` Juanma Barranquero @ 2019-09-24 19:29 ` Albert 2019-09-24 23:09 ` Juanma Barranquero 0 siblings, 1 reply; 40+ messages in thread From: Albert @ 2019-09-24 19:29 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 37495 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1.1: Type: text/plain; charset="gb18030", Size: 1965 bytes --] So, let's recapitulate. - You start Emacs 27.0.50 - In your init file(s), you do not change the default value of w32-pass-lwindow-to-system - While Emacs has the focus, if you press an lwindow combination, Emacs catches it and it is not passed back to Windows. - So, from inside 27.0.50, you cannot do LWin+R o LWin+D, etc. - But this didn't happen with Emacs 26.2. > Am I right now? Yes, you are right. If so, when you're inside Emacs 27.0.50, what does it say when you examine the value of w32-pass-lwindow-to-system? For example, with describe-variable. Does still happen if you start Emacs with emacs -Q C:\emacs-27.0.50-snapshot-2019-09-18-x86_64\bin>emacs -Q ------------------ ÔʼÓʼþ ------------------ ·¢¼þÈË: "Juanma Barranquero"<lekktu@gmail.com>; ·¢ËÍʱ¼ä: 2019Äê9ÔÂ25ÈÕ(ÐÇÆÚÈý) Á賿1:17 ÊÕ¼þÈË: "Albert"<georgealbert@qq.com>; ³ËÍ: "Eli Zaretskii"<eliz@gnu.org>;"37495"<37495@debbugs.gnu.org>; Ö÷Ìâ: Re: bug#37495: 27.0.50; lwindow doesn't pass to system On Tue, Sep 24, 2019 at 6:59 PM Albert <georgealbert@qq.com> wrote: > I'm sorry, the default value of w32-pass-lwindow-to-system is t. I dont' change w32-pass-lwindow-to-system in init file. So, let's recapitulate. - You start Emacs 27.0.50 - In your init file(s), you do not change the default value of w32-pass-lwindow-to-system - While Emacs has the focus, if you press an lwindow combination, Emacs catches it and it is not passed back to Windows. - So, from inside 27.0.50, you cannot do LWin+R o LWin+D, etc. - But this didn't happen with Emacs 26.2. Am I right now? If so, when you're inside Emacs 27.0.50, what does it say when you examine the value of w32-pass-lwindow-to-system? For example, with describe-variable. Does still happen if you start Emacs with emacs -Q ? [-- Attachment #1.2: Type: text/html, Size: 2832 bytes --] [-- Attachment #2: 2D01D01B@E6FD2546.896E8A5D.jpg --] [-- Type: image/jpeg, Size: 50491 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-24 19:29 ` bug#37495: �ظ��� " Albert @ 2019-09-24 23:09 ` Juanma Barranquero 0 siblings, 0 replies; 40+ messages in thread From: Juanma Barranquero @ 2019-09-24 23:09 UTC (permalink / raw) To: Albert; +Cc: 37495 [-- Attachment #1: Type: text/plain, Size: 413 bytes --] Well, that's weird, because there's nothing that should be setting w32-pass-lwindow-to-system to nil. But, at least, if the behavior you see is caused by that variable being set to nil, it sort of makes more sense (the problem is that something sets the variable, and not that it is not being obeyed). If you do emacs -Q --eval "(setq w32-pass-lwindow-to-system t)" does Emacs stop intercepting the LWin key? [-- Attachment #2: Type: text/html, Size: 564 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-24 16:55 ` Juanma Barranquero 2019-09-24 16:59 ` bug#37495: �ظ��� " Albert @ 2019-09-24 17:17 ` Eli Zaretskii 2019-09-24 17:22 ` bug#37495: �ظ��� " Albert 1 sibling, 1 reply; 40+ messages in thread From: Eli Zaretskii @ 2019-09-24 17:17 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 37495, georgealbert > From: Juanma Barranquero <lekktu@gmail.com> > Date: Tue, 24 Sep 2019 18:55:00 +0200 > Cc: georgealbert@qq.com, 37495@debbugs.gnu.org > > But then, he says "Iwindow key with the default setting(nil)". But w32-pass-lwindow-to-system's default value > is t, both in 26.2 and 27.0.50. I didn't see the "nil" part in the original report, just the "with the default setting" part. ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: �ظ��� bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-24 17:17 ` Eli Zaretskii @ 2019-09-24 17:22 ` Albert 0 siblings, 0 replies; 40+ messages in thread From: Albert @ 2019-09-24 17:22 UTC (permalink / raw) To: Eli Zaretskii, Juanma Barranquero; +Cc: 37495 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1.1: Type: text/plain; charset="gb18030", Size: 866 bytes --] I run the command eval-print-last-sexp with C-j, it prints "t", the default value. ------------------ ÔʼÓʼþ ------------------ ·¢¼þÈË: "Eli Zaretskii"<eliz@gnu.org>; ·¢ËÍʱ¼ä: 2019Äê9ÔÂ25ÈÕ(ÐÇÆÚÈý) Á賿1:17 ÊÕ¼þÈË: "Juanma Barranquero"<lekktu@gmail.com>; ³ËÍ: "Albert"<georgealbert@qq.com>;"37495"<37495@debbugs.gnu.org>; Ö÷Ìâ: Re: bug#37495: 27.0.50; lwindow doesn't pass to system > From: Juanma Barranquero <lekktu@gmail.com> > Date: Tue, 24 Sep 2019 18:55:00 +0200 > Cc: georgealbert@qq.com, 37495@debbugs.gnu.org > > But then, he says "Iwindow key with the default setting(nil)". But w32-pass-lwindow-to-system's default value > is t, both in 26.2 and 27.0.50. I didn't see the "nil" part in the original report, just the "with the default setting" part. [-- Attachment #1.2: Type: text/html, Size: 1401 bytes --] [-- Attachment #2: 2E01D219@3C7FC76C.C5508A5D.jpg --] [-- Type: image/jpeg, Size: 12023 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-24 1:22 bug#37495: 27.0.50; lwindow doesn't pass to system Albert 2019-09-24 4:41 ` Juanma Barranquero @ 2019-09-24 23:53 ` Juanma Barranquero 2019-09-25 5:27 ` bug#37495: �ظ��� " Albert 2019-09-25 6:12 ` Eli Zaretskii 1 sibling, 2 replies; 40+ messages in thread From: Juanma Barranquero @ 2019-09-24 23:53 UTC (permalink / raw) To: Albert; +Cc: 37495 [-- Attachment #1: Type: text/plain, Size: 807 bytes --] On Tue, Sep 24, 2019 at 3:50 AM Albert <georgealbert@qq.com> wrote: > In GNU Emacs 27.0.50 (build 1, x86_64-w64-mingw32) > of 2019-09-19 built on CIRROCUMULUS > Repository revision: 61c2183a440c94ab797696d0f0c76a7dc4007eeb That revision is more than three months old: commit 61c2183a440c94ab797696d0f0c76a7dc4007eeb Author: Phillip Lord <phillip.lord@russet.org.uk> Date: 2019-06-04 15:02:33 +0100 Could you please try with a recent snapshot from master? Also surprising: > Configured using: > 'configure --without-dbus --host=x86_64-w64-mingw32 > --without-compress-install -C 'CFLAGS=-O2 -static -g3'' I thought Emacs could not be cross-built. Are you crossbuilding from Windows to Windows (assuming that's even possible)? Why? Do you happen to have a non-standard lisp/loadup.el perhaps? [-- Attachment #2: Type: text/html, Size: 1226 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: �ظ��� bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-24 23:53 ` Juanma Barranquero @ 2019-09-25 5:27 ` Albert 2019-09-25 6:24 ` Eli Zaretskii 2019-09-25 6:12 ` Eli Zaretskii 1 sibling, 1 reply; 40+ messages in thread From: Albert @ 2019-09-25 5:27 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 37495 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1.1: Type: text/plain; charset="gb18030", Size: 1542 bytes --] C:\emacs-27.0.50-snapshot-2019-09-18-x86_64\bin>emacs -Q --eval "(setq w32-pass-lwindow-to-system t)" Emacs which I uses is downloaded from http://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-27/emacs-27.0.50-snapshot-2019-09-18-x86_64.zip. I don't know how to compile emacs on windows. ------------------ ÔʼÓʼþ ------------------ ·¢¼þÈË: "Juanma Barranquero"<lekktu@gmail.com>; ·¢ËÍʱ¼ä: 2019Äê9ÔÂ25ÈÕ(ÐÇÆÚÈý) ÉÏÎç7:53 ÊÕ¼þÈË: "Albert"<georgealbert@qq.com>; ³ËÍ: "37495"<37495@debbugs.gnu.org>; Ö÷Ìâ: Re: bug#37495: 27.0.50; lwindow doesn't pass to system On Tue, Sep 24, 2019 at 3:50 AM Albert <georgealbert@qq.com> wrote: > In GNU Emacs 27.0.50 (build 1, x86_64-w64-mingw32) > of 2019-09-19 built on CIRROCUMULUS > Repository revision: 61c2183a440c94ab797696d0f0c76a7dc4007eeb That revision is more than three months old: commit 61c2183a440c94ab797696d0f0c76a7dc4007eeb Author: Phillip Lord <phillip.lord@russet.org.uk> Date: 2019-06-04 15:02:33 +0100 Could you please try with a recent snapshot from master? Also surprising: > Configured using: > 'configure --without-dbus --host=x86_64-w64-mingw32 > --without-compress-install -C 'CFLAGS=-O2 -static -g3'' I thought Emacs could not be cross-built. Are you crossbuilding from Windows to Windows (assuming that's even possible)? Why? Do you happen to have a non-standard lisp/loadup.el perhaps? [-- Attachment #1.2: Type: text/html, Size: 2324 bytes --] [-- Attachment #2: 320ED317@07CB7060.ADFA8A5D.jpg --] [-- Type: image/jpeg, Size: 72213 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-25 5:27 ` bug#37495: �ظ��� " Albert @ 2019-09-25 6:24 ` Eli Zaretskii 2019-09-25 6:26 ` bug#37495: �ظ��� " Albert 0 siblings, 1 reply; 40+ messages in thread From: Eli Zaretskii @ 2019-09-25 6:24 UTC (permalink / raw) To: Albert; +Cc: lekktu, 37495 > From: "Albert" <georgealbert@qq.com> > Date: Wed, 25 Sep 2019 13:27:09 +0800 > Cc: 37495 <37495@debbugs.gnu.org> > > C:\emacs-27.0.50-snapshot-2019-09-18-x86_64\bin>emacs -Q --eval "(setq w32-pass-lwindow-to-system t)" Does lwindow work when you invoke Emacs that way? ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: �ظ��� bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-25 6:24 ` Eli Zaretskii @ 2019-09-25 6:26 ` Albert 2019-09-25 12:44 ` Juanma Barranquero 0 siblings, 1 reply; 40+ messages in thread From: Albert @ 2019-09-25 6:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Juanma Barranquero, 37495 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="gb18030", Size: 714 bytes --] No, it doesn't work. lwindow is swallowed by emacs. ------------------ ÔʼÓʼþ ------------------ ·¢¼þÈË: "Eli Zaretskii"<eliz@gnu.org>; ·¢ËÍʱ¼ä: 2019Äê9ÔÂ25ÈÕ(ÐÇÆÚÈý) ÏÂÎç2:24 ÊÕ¼þÈË: "Albert"<georgealbert@qq.com>; ³ËÍ: "lekktu"<lekktu@gmail.com>;"37495"<37495@debbugs.gnu.org>; Ö÷Ìâ: Re: bug#37495: 27.0.50; lwindow doesn't pass to system > From: "Albert" <georgealbert@qq.com> > Date: Wed, 25 Sep 2019 13:27:09 +0800 > Cc: 37495 <37495@debbugs.gnu.org> > > C:\emacs-27.0.50-snapshot-2019-09-18-x86_64\bin>emacs -Q --eval "(setq w32-pass-lwindow-to-system t)" Does lwindow work when you invoke Emacs that way? [-- Attachment #2: Type: text/html, Size: 1050 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-25 6:26 ` bug#37495: �ظ��� " Albert @ 2019-09-25 12:44 ` Juanma Barranquero 2019-09-25 12:49 ` bug#37495: �ظ��� " Albert 0 siblings, 1 reply; 40+ messages in thread From: Juanma Barranquero @ 2019-09-25 12:44 UTC (permalink / raw) To: Albert; +Cc: 37495 [-- Attachment #1: Type: text/plain, Size: 437 bytes --] In my system, using that very same snapshot, w32-pass-lwindow-to-system is t and it doesn't swallow any LWin command. So it seems something specific to your setup. What does emacs -Q --batch --eval "(princ w32-pass-lwindow-to-system)" return? Does it change if you do create an empty directory, let's call it C:\EMPTY, and you set HOME to it? set HOME=C:\EMPTY emacs -Q --batch --eval "(princ w32-pass-lwindow-to-system)" [-- Attachment #2: Type: text/html, Size: 679 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: �ظ��� bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-25 12:44 ` Juanma Barranquero @ 2019-09-25 12:49 ` Albert 2019-09-25 13:12 ` Juanma Barranquero 0 siblings, 1 reply; 40+ messages in thread From: Albert @ 2019-09-25 12:49 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 37495 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1.1: Type: text/plain; charset="gb18030", Size: 1009 bytes --] Hi, Here is the output of emacs 27.0.50: <lwindow> is passed to windows system in emacs 26.2 with the same init file and packages. ------------------ ÔʼÓʼþ ------------------ ·¢¼þÈË: "Juanma Barranquero"<lekktu@gmail.com>; ·¢ËÍʱ¼ä: 2019Äê9ÔÂ25ÈÕ(ÐÇÆÚÈý) ÍíÉÏ8:44 ÊÕ¼þÈË: "Albert"<georgealbert@qq.com>; ³ËÍ: "Eli Zaretskii"<eliz@gnu.org>;"37495"<37495@debbugs.gnu.org>; Ö÷Ìâ: Re: bug#37495: 27.0.50; lwindow doesn't pass to system In my system, using that very same snapshot, w32-pass-lwindow-to-system is t and it doesn't swallow any LWin command. So it seems something specific to your setup. What does emacs -Q --batch --eval "(princ w32-pass-lwindow-to-system)" return? Does it change if you do create an empty directory, let's call it C:\EMPTY, and you set HOME to it? set HOME=C:\EMPTY emacs -Q --batch --eval "(princ w32-pass-lwindow-to-system)" [-- Attachment #1.2: Type: text/html, Size: 1649 bytes --] [-- Attachment #2: 2D07D01B@15ACAA7C.5F628B5D.jpg --] [-- Type: image/jpeg, Size: 21075 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-25 12:49 ` bug#37495: �ظ��� " Albert @ 2019-09-25 13:12 ` Juanma Barranquero 2019-09-25 13:16 ` bug#37495: �ظ��� " Albert 0 siblings, 1 reply; 40+ messages in thread From: Juanma Barranquero @ 2019-09-25 13:12 UTC (permalink / raw) To: Albert; +Cc: 37495 [-- Attachment #1: Type: text/plain, Size: 282 bytes --] It's a bit hard to see in the picture, but I think the answer is t in both cases. So, running Emacs from the command line says that w32-pass-lwindow-to-system is t. But you said that if you do: emacs -Q and then check the value of the variable on Emacs, it is nil. Is it so? [-- Attachment #2: Type: text/html, Size: 444 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: �ظ��� bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-25 13:12 ` Juanma Barranquero @ 2019-09-25 13:16 ` Albert 2019-09-25 13:41 ` Juanma Barranquero 0 siblings, 1 reply; 40+ messages in thread From: Albert @ 2019-09-25 13:16 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 37495 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="gb18030", Size: 790 bytes --] No, w32-pass-lwindow-to-system that running emacs from the command line and in emacs with "emacs -Q", both are t. ------------------ ÔʼÓʼþ ------------------ ·¢¼þÈË: "Juanma Barranquero"<lekktu@gmail.com>; ·¢ËÍʱ¼ä: 2019Äê9ÔÂ25ÈÕ(ÐÇÆÚÈý) ÍíÉÏ9:12 ÊÕ¼þÈË: "Albert"<georgealbert@qq.com>; ³ËÍ: "Eli Zaretskii"<eliz@gnu.org>;"37495"<37495@debbugs.gnu.org>; Ö÷Ìâ: Re: bug#37495: 27.0.50; lwindow doesn't pass to system It's a bit hard to see in the picture, but I think the answer is t in both cases. So, running Emacs from the command line says that w32-pass-lwindow-to-system is t. But you said that if you do: emacs -Q and then check the value of the variable on Emacs, it is nil. Is it so? [-- Attachment #2: Type: text/html, Size: 1243 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-25 13:16 ` bug#37495: �ظ��� " Albert @ 2019-09-25 13:41 ` Juanma Barranquero 2019-09-25 13:49 ` bug#37495: �ظ��� " Albert 2019-09-25 15:11 ` Eli Zaretskii 0 siblings, 2 replies; 40+ messages in thread From: Juanma Barranquero @ 2019-09-25 13:41 UTC (permalink / raw) To: Albert; +Cc: 37495 [-- Attachment #1: Type: text/plain, Size: 635 bytes --] > No, w32-pass-lwindow-to-system that running emacs from the command line and in emacs with "emacs -Q", both are t. Ok. You're sending low-res images, which are hard to see (at least to my old eyes), and in one of a few hours ago I thought you were showing w32-pass-lwindow-to-system, while in fact it was w32-lwindow-modifier. I got sidetracked by that mistake. So, to summarize (again), if you run emacs -Q from that 2019-09-18 snapshot, then in that running instance, - w32-pass-lwindow-to-system is t - w32-lwindow-modifier is nil, - and lwindow+r does not invoke Windows' Run command. while it does in my setup. Weird. [-- Attachment #2: Type: text/html, Size: 874 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: �ظ��� bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-25 13:41 ` Juanma Barranquero @ 2019-09-25 13:49 ` Albert 2019-09-25 14:12 ` Juanma Barranquero 2019-09-25 15:11 ` Eli Zaretskii 1 sibling, 1 reply; 40+ messages in thread From: Albert @ 2019-09-25 13:49 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 37495 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1.1: Type: text/plain; charset="gb18030", Size: 1325 bytes --] Sorry for the low res pictures. What about this picture? emacs 27.0.50 2019-09-19 snapshot, emacs -Q w32-pass-lwindow-to-system is t w32-lwindow-modifier is nil, lwindow+r does not invoke Windows' Run command. ------------------ ÔʼÓʼþ ------------------ ·¢¼þÈË: "Juanma Barranquero"<lekktu@gmail.com>; ·¢ËÍʱ¼ä: 2019Äê9ÔÂ25ÈÕ(ÐÇÆÚÈý) ÍíÉÏ9:41 ÊÕ¼þÈË: "Albert"<georgealbert@qq.com>; ³ËÍ: "Eli Zaretskii"<eliz@gnu.org>;"37495"<37495@debbugs.gnu.org>; Ö÷Ìâ: Re: bug#37495: 27.0.50; lwindow doesn't pass to system > No, w32-pass-lwindow-to-system that running emacs from the command line and in emacs with "emacs -Q", both are t. Ok. You're sending low-res images, which are hard to see (at least to my old eyes), and in one of a few hours ago I thought you were showing w32-pass-lwindow-to-system, while in fact it was w32-lwindow-modifier. I got sidetracked by that mistake. So, to summarize (again), if you run emacs -Q from that 2019-09-18 snapshot, then in that running instance, - w32-pass-lwindow-to-system is t - w32-lwindow-modifier is nil, - and lwindow+r does not invoke Windows' Run command. while it does in my setup. Weird. [-- Attachment #1.2: Type: text/html, Size: 1938 bytes --] [-- Attachment #2: 2E03D21D@C6AAAC13.71708B5D.jpg --] [-- Type: image/jpeg, Size: 40085 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-25 13:49 ` bug#37495: �ظ��� " Albert @ 2019-09-25 14:12 ` Juanma Barranquero 2019-09-25 14:16 ` bug#37495: �ظ��� " Albert 2019-09-25 15:14 ` Eli Zaretskii 0 siblings, 2 replies; 40+ messages in thread From: Juanma Barranquero @ 2019-09-25 14:12 UTC (permalink / raw) To: Albert; +Cc: 37495 [-- Attachment #1.1: Type: text/plain, Size: 218 bytes --] On Wed, Sep 25, 2019 at 3:54 PM Albert <georgealbert@qq.com> wrote: > > Sorry for the low res pictures. What about this picture? :-) So, if you do C-h k and then lwindow r Emacs says this [image: image.png] [-- Attachment #1.2: Type: text/html, Size: 593 bytes --] [-- Attachment #2: image.png --] [-- Type: image/png, Size: 18388 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: �ظ��� bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-25 14:12 ` Juanma Barranquero @ 2019-09-25 14:16 ` Albert 2019-09-25 15:14 ` Eli Zaretskii 1 sibling, 0 replies; 40+ messages in thread From: Albert @ 2019-09-25 14:16 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 37495 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1.1: Type: text/plain; charset="gb18030", Size: 710 bytes --] C-h k then press lwindow + r, emacs 27.0.50 displays nothing. It seems lwindow is ignored. ------------------ ÔʼÓʼþ ------------------ ·¢¼þÈË: "Juanma Barranquero"<lekktu@gmail.com>; ·¢ËÍʱ¼ä: 2019Äê9ÔÂ25ÈÕ(ÐÇÆÚÈý) ÍíÉÏ10:12 ÊÕ¼þÈË: "Albert"<georgealbert@qq.com>; ³ËÍ: "Eli Zaretskii"<eliz@gnu.org>;"37495"<37495@debbugs.gnu.org>; Ö÷Ìâ: Re: bug#37495: 27.0.50; lwindow doesn't pass to system On Wed, Sep 25, 2019 at 3:54 PM Albert <georgealbert@qq.com> wrote: > > Sorry for the low res pictures. What about this picture? :-) So, if you do C-h k and then lwindow r Emacs says this [-- Attachment #1.2: Type: text/html, Size: 1354 bytes --] [-- Attachment #2: 965AB6E7@2150CE72.AD768B5D.jpg --] [-- Type: image/jpeg, Size: 18388 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-25 14:12 ` Juanma Barranquero 2019-09-25 14:16 ` bug#37495: �ظ��� " Albert @ 2019-09-25 15:14 ` Eli Zaretskii 2019-09-25 15:22 ` Juanma Barranquero 1 sibling, 1 reply; 40+ messages in thread From: Eli Zaretskii @ 2019-09-25 15:14 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 37495, georgealbert > From: Juanma Barranquero <lekktu@gmail.com> > Date: Wed, 25 Sep 2019 16:12:38 +0200 > Cc: Eli Zaretskii <eliz@gnu.org>, 37495 <37495@debbugs.gnu.org> > > So, if you do > > C-h k > > and then > > lwindow r > > Emacs says this > > image.png I see the same, FWIW, and the *Help* window pops up before I hit 'r', just after I hit lwindow. I think this is normal. ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-25 15:14 ` Eli Zaretskii @ 2019-09-25 15:22 ` Juanma Barranquero 2019-09-25 15:30 ` bug#37495: �ظ��� " Albert 0 siblings, 1 reply; 40+ messages in thread From: Juanma Barranquero @ 2019-09-25 15:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 37495, georgealbert [-- Attachment #1: Type: text/plain, Size: 422 bytes --] On Wed, Sep 25, 2019 at 5:14 PM Eli Zaretskii <eliz@gnu.org> wrote: > I see the same, FWIW, and the *Help* window pops up before I hit 'r', > just after I hit lwindow. > > I think this is normal. Yes, it is normal. But it's not what happens to Albert. So I think you're right, something in his system's set up is messing with keyboard handling, and it's not an Emacs thing. But somehow it didn't affect 26.2... Weird. [-- Attachment #2: Type: text/html, Size: 609 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: �ظ��� bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-25 15:22 ` Juanma Barranquero @ 2019-09-25 15:30 ` Albert 2019-09-26 5:38 ` bug#37495: 回复: " Albert 0 siblings, 1 reply; 40+ messages in thread From: Albert @ 2019-09-25 15:30 UTC (permalink / raw) To: Juanma Barranquero, Eli Zaretskii; +Cc: 37495 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1.1: Type: text/plain; charset="gb18030", Size: 1116 bytes --] Picture above is emacs 26.2, it is ok. I can't figure out why emacs 26.3 and 27.0.50 are not ok with the same config of emacs 26.2. Maybe I should trye to compile emacs from source. I use emacs on linux by compiling from trunk. But I don't set up develop environment on windows. ------------------ ÔʼÓʼþ ------------------ ·¢¼þÈË: "Juanma Barranquero"<lekktu@gmail.com>; ·¢ËÍʱ¼ä: 2019Äê9ÔÂ25ÈÕ(ÐÇÆÚÈý) ÍíÉÏ11:22 ÊÕ¼þÈË: "Eli Zaretskii"<eliz@gnu.org>; ³ËÍ: "Albert"<georgealbert@qq.com>;"37495"<37495@debbugs.gnu.org>; Ö÷Ìâ: Re: bug#37495: 27.0.50; lwindow doesn't pass to system On Wed, Sep 25, 2019 at 5:14 PM Eli Zaretskii <eliz@gnu.org> wrote: > I see the same, FWIW, and the *Help* window pops up before I hit 'r', > just after I hit lwindow. > > I think this is normal. Yes, it is normal. But it's not what happens to Albert. So I think you're right, something in his system's set up is messing with keyboard handling, and it's not an Emacs thing. But somehow it didn't affect 26.2... Weird. [-- Attachment #1.2: Type: text/html, Size: 1604 bytes --] [-- Attachment #2: 2D00D515@1902123F.0D888B5D.jpg --] [-- Type: image/jpeg, Size: 55856 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 回复: bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-25 15:30 ` bug#37495: �ظ��� " Albert @ 2019-09-26 5:38 ` Albert 2019-09-26 11:45 ` Juanma Barranquero 0 siblings, 1 reply; 40+ messages in thread From: Albert @ 2019-09-26 5:38 UTC (permalink / raw) To: Juanma Barranquero, Eli Zaretskii; +Cc: 37495 [-- Attachment #1.1: Type: text/plain, Size: 1892 bytes --] I compiled emacs from the latest code. But lwindow is still not passed to windows. Albert@Albert MSYS /e/workspace/emacs_src/emacs $ git log commit 07367e5b95fe31f3d4e994b42b081075501b9b60 (grafted, HEAD -> master, origin/master, origin/HEAD) Author: Mattias Engdegård <mattiase@acm.org> Date: Wed Sep 25 14:29:50 2019 -0700 ------------------ 原始邮件 ------------------ 发件人: "Albert"<georgealbert@qq.com>; 发送时间: 2019年9月25日(星期三) 晚上11:30 收件人: "Juanma Barranquero"<lekktu@gmail.com>;"Eli Zaretskii"<eliz@gnu.org>; 抄送: "37495"<37495@debbugs.gnu.org>; 主题: 回复: bug#37495: 27.0.50; lwindow doesn't pass to system Picture above is emacs 26.2, it is ok. I can't figure out why emacs 26.3 and 27.0.50 are not ok with the same config of emacs 26.2. Maybe I should trye to compile emacs from source. I use emacs on linux by compiling from trunk. But I don't set up develop environment on windows. ------------------ 原始邮件 ------------------ 发件人: "Juanma Barranquero"<lekktu@gmail.com>; 发送时间: 2019年9月25日(星期三) 晚上11:22 收件人: "Eli Zaretskii"<eliz@gnu.org>; 抄送: "Albert"<georgealbert@qq.com>;"37495"<37495@debbugs.gnu.org>; 主题: Re: bug#37495: 27.0.50; lwindow doesn't pass to system On Wed, Sep 25, 2019 at 5:14 PM Eli Zaretskii <eliz@gnu.org> wrote: > I see the same, FWIW, and the *Help* window pops up before I hit 'r', > just after I hit lwindow. > > I think this is normal. Yes, it is normal. But it's not what happens to Albert. So I think you're right, something in his system's set up is messing with keyboard handling, and it's not an Emacs thing. But somehow it didn't affect 26.2... Weird. [-- Attachment #1.2: Type: text/html, Size: 2698 bytes --] [-- Attachment #2: F2C2AF47@A1867239.BA4E8C5D.jpg --] [-- Type: image/jpeg, Size: 55856 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 回复: bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-26 5:38 ` bug#37495: 回复: " Albert @ 2019-09-26 11:45 ` Juanma Barranquero 2019-09-26 12:17 ` Eli Zaretskii 0 siblings, 1 reply; 40+ messages in thread From: Juanma Barranquero @ 2019-09-26 11:45 UTC (permalink / raw) To: Albert; +Cc: 37495 [-- Attachment #1.1: Type: text/plain, Size: 380 bytes --] On Thu, Sep 26, 2019 at 7:39 AM Albert <georgealbert@qq.com> wrote: > > I compiled emacs from the latest code. But lwindow is still not passed to windows. What your screenshot shows is the normal behavior when Emacs is passing the key to Windows. So at this point I think Eli's right, and it is something in your system's setup. Why it didn't happen with 26.2, I have no idea. [-- Attachment #1.2: Type: text/html, Size: 541 bytes --] [-- Attachment #2: F2C2AF47@A1867239.BA4E8C5D.jpg --] [-- Type: image/jpeg, Size: 55856 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 回复: bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-26 11:45 ` Juanma Barranquero @ 2019-09-26 12:17 ` Eli Zaretskii 2019-09-26 13:40 ` bug#37495: �ظ��� bug#37495: �ظ��� " Albert 0 siblings, 1 reply; 40+ messages in thread From: Eli Zaretskii @ 2019-09-26 12:17 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 37495, georgealbert > From: Juanma Barranquero <lekktu@gmail.com> > Date: Thu, 26 Sep 2019 13:45:03 +0200 > Cc: Eli Zaretskii <eliz@gnu.org>, 37495 <37495@debbugs.gnu.org> > > Why it didn't happen with 26.2, I have no idea. Maybe Emacs 26.2 was downloaded from a different site, or it was a different build? ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: �ظ��� bug#37495: �ظ��� bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-26 12:17 ` Eli Zaretskii @ 2019-09-26 13:40 ` Albert 2019-09-29 3:29 ` Albert 0 siblings, 1 reply; 40+ messages in thread From: Albert @ 2019-09-26 13:40 UTC (permalink / raw) To: Eli Zaretskii, Juanma Barranquero; +Cc: 37495 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="gb18030", Size: 973 bytes --] Emacs 26.2/26.3/27.0.50 are downloaded from gnu website(http://ftp.gnu.org/gnu/emacs/windows/emacs-26/ and http://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-27/). I tried to comment code in w32fns.c to bypass lwindow to system, but failed without luck. ------------------ ÔʼÓʼþ ------------------ ·¢¼þÈË: "Eli Zaretskii"<eliz@gnu.org>; ·¢ËÍʱ¼ä: 2019Äê9ÔÂ26ÈÕ(ÐÇÆÚËÄ) ÍíÉÏ8:17 ÊÕ¼þÈË: "Juanma Barranquero"<lekktu@gmail.com>; ³ËÍ: "Albert"<georgealbert@qq.com>;"37495"<37495@debbugs.gnu.org>; Ö÷Ìâ: Re: bug#37495: »Ø¸´£º bug#37495: 27.0.50; lwindow doesn't pass to system > From: Juanma Barranquero <lekktu@gmail.com> > Date: Thu, 26 Sep 2019 13:45:03 +0200 > Cc: Eli Zaretskii <eliz@gnu.org>, 37495 <37495@debbugs.gnu.org> > > Why it didn't happen with 26.2, I have no idea. Maybe Emacs 26.2 was downloaded from a different site, or it was a different build? [-- Attachment #2: Type: text/html, Size: 1322 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: �ظ��� bug#37495: �ظ��� bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-26 13:40 ` bug#37495: �ظ��� bug#37495: �ظ��� " Albert @ 2019-09-29 3:29 ` Albert 2019-09-29 3:44 ` bug#37495: 回复: " Juanma Barranquero 0 siblings, 1 reply; 40+ messages in thread From: Albert @ 2019-09-29 3:29 UTC (permalink / raw) To: Eli Zaretskii, Juanma Barranquero; +Cc: 37495 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="gb18030", Size: 1559 bytes --] I finally found the problem. My anti-virus software(360°²È«ÎÀÊ¿) blocks emacs to emulate lwindow key. When emacs is trusted by anti-virus software, the problem is solved. Thank you for all your help. ------------------ ÔʼÓʼþ ------------------ ·¢¼þÈË: "Albert"<georgealbert@qq.com>; ·¢ËÍʱ¼ä: 2019Äê9ÔÂ26ÈÕ(ÐÇÆÚËÄ) ÍíÉÏ9:40 ÊÕ¼þÈË: "Eli Zaretskii"<eliz@gnu.org>;"Juanma Barranquero"<lekktu@gmail.com>; ³ËÍ: "37495"<37495@debbugs.gnu.org>; Ö÷Ìâ: »Ø¸´£º bug#37495: »Ø¸´£º bug#37495: 27.0.50; lwindow doesn't pass to system Emacs 26.2/26.3/27.0.50 are downloaded from gnu website(http://ftp.gnu.org/gnu/emacs/windows/emacs-26/ and http://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-27/). I tried to comment code in w32fns.c to bypass lwindow to system, but failed without luck. ------------------ ÔʼÓʼþ ------------------ ·¢¼þÈË: "Eli Zaretskii"<eliz@gnu.org>; ·¢ËÍʱ¼ä: 2019Äê9ÔÂ26ÈÕ(ÐÇÆÚËÄ) ÍíÉÏ8:17 ÊÕ¼þÈË: "Juanma Barranquero"<lekktu@gmail.com>; ³ËÍ: "Albert"<georgealbert@qq.com>;"37495"<37495@debbugs.gnu.org>; Ö÷Ìâ: Re: bug#37495: »Ø¸´£º bug#37495: 27.0.50; lwindow doesn't pass to system > From: Juanma Barranquero <lekktu@gmail.com> > Date: Thu, 26 Sep 2019 13:45:03 +0200 > Cc: Eli Zaretskii <eliz@gnu.org>, 37495 <37495@debbugs.gnu.org> > > Why it didn't happen with 26.2, I have no idea. Maybe Emacs 26.2 was downloaded from a different site, or it was a different build? [-- Attachment #2: Type: text/html, Size: 2219 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 回复: bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-29 3:29 ` Albert @ 2019-09-29 3:44 ` Juanma Barranquero 0 siblings, 0 replies; 40+ messages in thread From: Juanma Barranquero @ 2019-09-29 3:44 UTC (permalink / raw) To: Albert; +Cc: 37495-done [-- Attachment #1: Type: text/plain, Size: 220 bytes --] On Sun, Sep 29, 2019 at 5:29 AM Albert <georgealbert@qq.com> wrote: > > I finally found the problem. My anti-virus software(360安全卫士) blocks emacs to emulate lwindow key. Great, thanks for letting us know. [-- Attachment #2: Type: text/html, Size: 334 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-25 13:41 ` Juanma Barranquero 2019-09-25 13:49 ` bug#37495: �ظ��� " Albert @ 2019-09-25 15:11 ` Eli Zaretskii 1 sibling, 0 replies; 40+ messages in thread From: Eli Zaretskii @ 2019-09-25 15:11 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 37495, georgealbert > From: Juanma Barranquero <lekktu@gmail.com> > Date: Wed, 25 Sep 2019 15:41:35 +0200 > Cc: Eli Zaretskii <eliz@gnu.org>, 37495 <37495@debbugs.gnu.org> > > So, to summarize (again), if you run > > emacs -Q > > from that 2019-09-18 snapshot, then in that running instance, > > - w32-pass-lwindow-to-system is t > - w32-lwindow-modifier is nil, > - and lwindow+r does not invoke Windows' Run command. > > while it does in my setup. Weird. Which probably means the OP has some local non-default system-wide setup regarding keyboard handling. ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-24 23:53 ` Juanma Barranquero 2019-09-25 5:27 ` bug#37495: �ظ��� " Albert @ 2019-09-25 6:12 ` Eli Zaretskii 2019-09-25 7:52 ` Andreas Schwab 2019-09-25 12:36 ` Juanma Barranquero 1 sibling, 2 replies; 40+ messages in thread From: Eli Zaretskii @ 2019-09-25 6:12 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 37495, georgealbert > From: Juanma Barranquero <lekktu@gmail.com> > Date: Wed, 25 Sep 2019 01:53:41 +0200 > Cc: 37495@debbugs.gnu.org > > Also surprising: > > > Configured using: > > 'configure --without-dbus --host=x86_64-w64-mingw32 > > --without-compress-install -C 'CFLAGS=-O2 -static -g3'' > > I thought Emacs could not be cross-built. Are you crossbuilding from Windows to Windows (assuming that's > even possible)? Why? I think you should disregard that, it's just an artifact of how the configure command was run by the person who built Emacs. I have no idea why they used --host=, it isn't required. ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-25 6:12 ` Eli Zaretskii @ 2019-09-25 7:52 ` Andreas Schwab 2019-09-25 8:53 ` Eli Zaretskii 2019-09-25 12:36 ` Juanma Barranquero 1 sibling, 1 reply; 40+ messages in thread From: Andreas Schwab @ 2019-09-25 7:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Juanma Barranquero, 37495, georgealbert On Sep 25 2019, Eli Zaretskii <eliz@gnu.org> wrote: > I think you should disregard that, it's just an artifact of how the > configure command was run by the person who built Emacs. I have no > idea why they used --host=, it isn't required. There's nothing wrong with using --host when it matches what config.guess would give. It can be useful to force a specific spelling for host_alias. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-25 7:52 ` Andreas Schwab @ 2019-09-25 8:53 ` Eli Zaretskii 0 siblings, 0 replies; 40+ messages in thread From: Eli Zaretskii @ 2019-09-25 8:53 UTC (permalink / raw) To: Andreas Schwab; +Cc: lekktu, 37495, georgealbert > From: Andreas Schwab <schwab@suse.de> > Cc: Juanma Barranquero <lekktu@gmail.com>, 37495@debbugs.gnu.org, georgealbert@qq.com > Date: Wed, 25 Sep 2019 09:52:21 +0200 > > On Sep 25 2019, Eli Zaretskii <eliz@gnu.org> wrote: > > > I think you should disregard that, it's just an artifact of how the > > configure command was run by the person who built Emacs. I have no > > idea why they used --host=, it isn't required. > > There's nothing wrong with using --host when it matches what > config.guess would give. Indeed, nothing wrong. It's just redundant in this case. ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-25 6:12 ` Eli Zaretskii 2019-09-25 7:52 ` Andreas Schwab @ 2019-09-25 12:36 ` Juanma Barranquero 2019-09-25 12:45 ` Juanma Barranquero 1 sibling, 1 reply; 40+ messages in thread From: Juanma Barranquero @ 2019-09-25 12:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 37495, georgealbert [-- Attachment #1: Type: text/plain, Size: 503 bytes --] > I think you should disregard that, it's just an artifact of how the > configure command was run by the person who built Emacs. I have no > idea why they used --host=, it isn't required. Yes, of course. It's just that I thought that Albert was building its own Emacs, so I wanted to know if he were doing something different. But it's an "official" snapshot. And a recent one, in fact. The commit is dated 2019-06-04, but that's because of some merge. The previous commit is indeed from 2019-09-18. [-- Attachment #2: Type: text/html, Size: 619 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* bug#37495: 27.0.50; lwindow doesn't pass to system 2019-09-25 12:36 ` Juanma Barranquero @ 2019-09-25 12:45 ` Juanma Barranquero 0 siblings, 0 replies; 40+ messages in thread From: Juanma Barranquero @ 2019-09-25 12:45 UTC (permalink / raw) To: georgealbert; +Cc: 37495 [-- Attachment #1: Type: text/plain, Size: 198 bytes --] On Wed, Sep 25, 2019 at 2:36 PM Juanma Barranquero <lekktu@gmail.com> wrote: > Yes, of course. It's just that I thought that Albert was building its own > Emacs > *His* own Emacs. Sorry. Sleepy. [-- Attachment #2: Type: text/html, Size: 719 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2019-09-29 3:44 UTC | newest] Thread overview: 40+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-09-24 1:22 bug#37495: 27.0.50; lwindow doesn't pass to system Albert 2019-09-24 4:41 ` Juanma Barranquero 2019-09-24 13:05 ` bug#37495: �ظ��� " Albert 2019-09-24 13:50 ` Juanma Barranquero 2019-09-24 16:39 ` Eli Zaretskii 2019-09-24 16:43 ` bug#37495: �ظ��� " Albert 2019-09-24 16:55 ` Juanma Barranquero 2019-09-24 16:59 ` bug#37495: �ظ��� " Albert 2019-09-24 17:17 ` Juanma Barranquero 2019-09-24 19:29 ` bug#37495: �ظ��� " Albert 2019-09-24 23:09 ` Juanma Barranquero 2019-09-24 17:17 ` Eli Zaretskii 2019-09-24 17:22 ` bug#37495: �ظ��� " Albert 2019-09-24 23:53 ` Juanma Barranquero 2019-09-25 5:27 ` bug#37495: �ظ��� " Albert 2019-09-25 6:24 ` Eli Zaretskii 2019-09-25 6:26 ` bug#37495: �ظ��� " Albert 2019-09-25 12:44 ` Juanma Barranquero 2019-09-25 12:49 ` bug#37495: �ظ��� " Albert 2019-09-25 13:12 ` Juanma Barranquero 2019-09-25 13:16 ` bug#37495: �ظ��� " Albert 2019-09-25 13:41 ` Juanma Barranquero 2019-09-25 13:49 ` bug#37495: �ظ��� " Albert 2019-09-25 14:12 ` Juanma Barranquero 2019-09-25 14:16 ` bug#37495: �ظ��� " Albert 2019-09-25 15:14 ` Eli Zaretskii 2019-09-25 15:22 ` Juanma Barranquero 2019-09-25 15:30 ` bug#37495: �ظ��� " Albert 2019-09-26 5:38 ` bug#37495: 回复: " Albert 2019-09-26 11:45 ` Juanma Barranquero 2019-09-26 12:17 ` Eli Zaretskii 2019-09-26 13:40 ` bug#37495: �ظ��� bug#37495: �ظ��� " Albert 2019-09-29 3:29 ` Albert 2019-09-29 3:44 ` bug#37495: 回复: " Juanma Barranquero 2019-09-25 15:11 ` Eli Zaretskii 2019-09-25 6:12 ` Eli Zaretskii 2019-09-25 7:52 ` Andreas Schwab 2019-09-25 8:53 ` Eli Zaretskii 2019-09-25 12:36 ` Juanma Barranquero 2019-09-25 12:45 ` Juanma Barranquero
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).