unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
@ 2017-01-24 21:05 Alex 'QWxleA' Poslavsky
  2017-01-24 23:35 ` npostavs
  2017-01-25  3:31 ` Eli Zaretskii
  0 siblings, 2 replies; 30+ messages in thread
From: Alex 'QWxleA' Poslavsky @ 2017-01-24 21:05 UTC (permalink / raw)
  To: 25521


The following, used as ~/.emacs.d/init.el:

(require 'org)

(defun qw ()
  (interactive)
  "Create a new capture frame helper-function" 
  (make-frame '((name . "foo")
                (width . 120)
                (height . 25)))
  (select-frame-by-name "foo") 
  (org-agenda))

works on emacs24, but not on a current git, build 24 Jan 2017. The
error-message is: select-frame-by-name: There is no frame named ‘foo’

I left everything else, but it doesn't look helpful.

Thanks!

Alex


In GNU Emacs 26.0.50.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.30)
 of 2017-01-24 built on plovs-ThinkPad-X220
Repository revision: 52a87c894d1e2351baecaff9ff061e3b83827220
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description:	Ubuntu 16.10

Recent messages:
Wrote /home/plovs/.profile
Wrote /home/plovs/.Xresources
Wrote /home/plovs/.config/fontconfig/conf.d/10-sourcecodepro.conf
Wrote /home/plovs/.ssh/config
Wrote /home/plovs/.mplayer/config
Wrote /home/plovs/.gitconfig [3 times]
Wrote /home/plovs/.bashrc [7 times]
Wrote /home/plovs/.zsh_custom/qwxlea.zsh-theme
Wrote /home/plovs/.zshrc [5 times]
Tangled 34 code blocks from dotfiles.org

Configured using:
 'configure --prefix=/home/plovs/Applications/emacs-dev'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GSETTINGS NOTIFY GNUTLS LIBXML2
FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK2 X11

Important settings:
  value of $LC_MONETARY: en_IE.UTF-8
  value of $LC_NUMERIC: en_IE.UTF-8
  value of $LC_TIME: en_IE.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Org

Minor modes in effect:
  org-indent-mode: t
  magit-auto-revert-mode: t
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  google-this-mode: t
  shell-dirtrack-mode: t
  display-time-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  which-key-mode: t
  global-diff-hl-mode: t
  diff-hl-mode: t
  diff-auto-refine-mode: t
  global-aggressive-indent-mode: t
  super-save-mode: t
  recentf-mode: t
  savehist-mode: t
  save-place-mode: t
  global-flycheck-mode: t
  flycheck-mode: t
  flyspell-mode: t
  ido-everywhere: t
  global-company-mode: t
  company-mode: t
  show-paren-mode: t
  golden-ratio-mode: t
  global-hl-line-mode: t
  global-auto-revert-mode: t
  delete-selection-mode: t
  override-global-mode: t
  tooltip-mode: t
  global-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
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  visual-line-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
~/src/org-mode/contrib/lisp/htmlize hides /home/plovs/.emacs.d/elpa/htmlize-20161211.1019/htmlize
~/Projects/perry.el/perry-mode hides /home/plovs/.emacs.d/lib/perry-mode
~/src/org-mode/lisp/org-crypt hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-crypt
~/src/org-mode/lisp/ob-lob hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-lob
~/src/org-mode/lisp/org-irc hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-irc
~/src/org-mode/lisp/org-archive hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-archive
~/src/org-mode/lisp/ob-octave hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-octave
~/src/org-mode/lisp/org-mobile hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-mobile
~/src/org-mode/lisp/org-capture hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-capture
~/src/org-mode/lisp/ox-html hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ox-html
~/src/org-mode/lisp/org-footnote hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-footnote
~/src/org-mode/lisp/ob-mscgen hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-mscgen
~/src/org-mode/lisp/org-macro hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-macro
~/src/org-mode/lisp/ob-perl hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-perl
~/src/org-mode/lisp/org-info hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-info
~/src/org-mode/lisp/org-docview hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-docview
~/src/org-mode/lisp/org-habit hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-habit
~/src/org-mode/lisp/ox-beamer hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ox-beamer
~/src/org-mode/lisp/ob-picolisp hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-picolisp
~/src/org-mode/lisp/org-element hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-element
~/src/org-mode/lisp/org-faces hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-faces
~/src/org-mode/lisp/ob-emacs-lisp hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-emacs-lisp
~/src/org-mode/lisp/ob-eval hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-eval
~/src/org-mode/lisp/ox hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ox
~/src/org-mode/lisp/org-datetree hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-datetree
~/src/org-mode/lisp/org-list hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-list
~/src/org-mode/lisp/ob-awk hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-awk
~/src/org-mode/lisp/ob-C hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-C
~/src/org-mode/lisp/org-protocol hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-protocol
~/src/org-mode/lisp/ob-ditaa hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-ditaa
~/src/org-mode/lisp/org-entities hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-entities
~/src/org-mode/lisp/ob-lilypond hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-lilypond
~/src/org-mode/lisp/org-feed hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-feed
~/src/org-mode/lisp/ob-java hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-java
~/src/org-mode/lisp/org-bibtex hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-bibtex
~/src/org-mode/lisp/ob-R hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-R
~/src/org-mode/lisp/org-pcomplete hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-pcomplete
~/src/org-mode/lisp/org-mouse hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-mouse
~/src/org-mode/lisp/ox-publish hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ox-publish
~/src/org-mode/lisp/ox-texinfo hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ox-texinfo
~/src/org-mode/lisp/org-ctags hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-ctags
~/src/org-mode/lisp/ob-scala hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-scala
~/src/org-mode/lisp/ob-haskell hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-haskell
~/src/org-mode/lisp/org-rmail hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-rmail
~/src/org-mode/lisp/ob-ref hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-ref
~/src/org-mode/lisp/ob-maxima hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-maxima
~/src/org-mode/lisp/org-id hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-id
~/src/org-mode/lisp/ob-python hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-python
~/src/org-mode/lisp/ob-comint hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-comint
~/src/org-mode/lisp/ox-odt hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ox-odt
~/src/org-mode/lisp/ob-makefile hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-makefile
~/src/org-mode/lisp/ox-latex hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ox-latex
~/src/org-mode/lisp/org-w3m hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-w3m
~/src/org-mode/lisp/ob-ocaml hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-ocaml
~/src/org-mode/lisp/org-mhe hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-mhe
~/src/org-mode/lisp/org-timer hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-timer
~/src/org-mode/lisp/ox-org hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ox-org
~/src/org-mode/lisp/ob-asymptote hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-asymptote
~/src/org-mode/lisp/org-indent hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-indent
~/src/org-mode/lisp/ob-sass hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-sass
~/src/org-mode/lisp/ob-screen hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-screen
~/src/org-mode/lisp/ox-icalendar hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ox-icalendar
~/src/org-mode/lisp/ob-io hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-io
~/src/org-mode/lisp/ob-tangle hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-tangle
~/src/org-mode/lisp/org-gnus hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-gnus
~/src/org-mode/lisp/ob-latex hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-latex
~/src/org-mode/lisp/ob-keys hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-keys
~/src/org-mode/lisp/org-loaddefs hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-loaddefs
~/src/org-mode/lisp/org hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org
~/src/org-mode/lisp/ob-ruby hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-ruby
~/src/org-mode/lisp/org-agenda hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-agenda
~/src/org-mode/lisp/ob-plantuml hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-plantuml
~/src/org-mode/lisp/org-plot hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-plot
~/src/org-mode/lisp/ob-sqlite hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-sqlite
~/src/org-mode/lisp/ob-exp hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-exp
~/src/org-mode/lisp/org-compat hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-compat
~/src/org-mode/lisp/org-macs hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-macs
~/src/org-mode/lisp/org-colview hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-colview
~/src/org-mode/lisp/ob hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob
~/src/org-mode/lisp/ob-js hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-js
~/src/org-mode/lisp/ob-scheme hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-scheme
~/src/org-mode/lisp/org-attach hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-attach
~/src/org-mode/lisp/org-eshell hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-eshell
~/src/org-mode/lisp/org-table hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-table
~/src/org-mode/lisp/ob-css hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-css
~/src/org-mode/lisp/org-bbdb hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-bbdb
~/src/org-mode/lisp/ob-table hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-table
~/src/org-mode/lisp/org-src hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-src
~/src/org-mode/lisp/ob-shen hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-shen
~/src/org-mode/lisp/ox-ascii hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ox-ascii
~/src/org-mode/lisp/ob-sql hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-sql
~/src/org-mode/lisp/ob-calc hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-calc
~/src/org-mode/lisp/ob-gnuplot hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-gnuplot
~/src/org-mode/lisp/org-clock hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-clock
~/src/org-mode/lisp/ox-man hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ox-man
~/src/org-mode/lisp/org-install hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-install
~/src/org-mode/lisp/ob-matlab hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-matlab
~/src/org-mode/lisp/ob-org hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-org
~/src/org-mode/lisp/org-inlinetask hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-inlinetask
~/src/org-mode/lisp/ob-lisp hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-lisp
~/src/org-mode/lisp/ob-core hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-core
~/src/org-mode/lisp/ob-clojure hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-clojure
~/src/org-mode/lisp/ob-ledger hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-ledger
~/src/org-mode/lisp/ox-md hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ox-md
~/src/org-mode/lisp/ob-dot hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-dot
~/src/org-mode/lisp/ob-fortran hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/ob-fortran
~/src/org-mode/lisp/org-version hides /home/plovs/Applications/emacs-dev/share/emacs/26.0.50/lisp/org/org-version

Features:
(shadow mail-extr emacsbug sendmail conf-mode ffap crux timezone
two-column iso-transl sh-script executable org-indent image-file
disp-table org-protocol org-info org-bbdb magit-filenotify
magit-obsolete magit-blame magit-stash magit-bisect magit-remote
magit-commit magit-sequence magit-notes magit-worktree magit-branch
magit-files magit-refs magit-status magit magit-repos magit-apply
magit-wip magit-log magit-diff smerge-mode magit-core magit-autorevert
magit-process magit-margin magit-mode magit-git crm magit-section
magit-popup git-commit magit-utils log-edit pcvs-util add-log
with-editor async-bytecomp async tramp-sh ido-completing-read+ smex
rainbow-delimiters init emms-info-libtag emms-librefm-stream
emms-librefm-scrobbler emms-playlist-limit emms-volume
emms-volume-amixer emms-i18n emms-history emms-score emms-stream-info
emms-metaplaylist-mode emms-bookmarks emms-cue emms-mode-line-icon
emms-player-xine emms-player-mpd tq emms-playing-time emms-lyrics
emms-url emms-streams emms-show-all emms-tag-editor emms-mark
emms-mode-line emms-info-ogginfo emms-info-mp3info emms-player-vlc
emms-setup emms-browser sort emms-playlist-sort emms-playlist-mode
emms-last-played emms-cache emms-info later-do emms-player-mplayer
emms-source-playlist emms-source-file locate emms-player-simple emms
emms-compat qw-elfeed elfeed-csv elfeed-show message puny rfc822 mml
mml-sec epa epg gnus-util rmail rmail-loaddefs mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr mailabbrev mail-utils gmm-utils mailheader shr svg dom
elfeed-db elfeed-search elfeed elfeed-curl elfeed-lib elfeed-log
url-queue browse-url xml-query xml google-this url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf mailcap
ob-shell ob-ditaa ob-plantuml password-generator org-password-manager
perry perry-utils perry-export mustache perry-mode simple-httpd url-util
htmlize cl noflet cl-indent ox-md ox-odt rng-loc rng-uri rng-parse
rng-match rng-dt rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok
nxml-util ox-latex ox-icalendar ox-html table ox-ascii ox-publish ox
org-clock org-element avl-tree org org-macro org-footnote org-pcomplete
org-list org-faces org-entities org-version ob-emacs-lisp ob ob-tangle
org-src ob-ref ob-lob ob-table ob-keys ob-exp ob-comint tramp
tramp-compat tramp-loaddefs trampver shell pcomplete parse-time ob-core
ob-eval org-compat org-macs org-loaddefs format-spec cal-menu calendar
cal-loaddefs elisp-slime-nav ielm mustache-mode inf-ruby ruby-mode smie
lorem-ipsum yaml-mode markdown-mode noutline outline time bookmark+
bookmark+-key derived bookmark+-1 bookmark+-bmu bookmark+-lit bookmark
pp undo-tree diff which-key diff-hl face-remap vc-hg vc-git vc-dir ewoc
vc vc-dispatcher diff-mode aggressive-indent lisp-mnt super-save
dired-aux dired-x recentf tree-widget wid-edit savehist saveplace
easy-kill thingatpt ag vc-svn compile comint ansi-color find-dired dired
dired-loaddefs windmove flycheck find-func flyspell ispell ido
company-oddmuse company-keywords company-etags etags xref project
company-gtags company-dabbrev-code company-dabbrev company-files
company-capf company-cmake company-xcode company-clang company-semantic
company-eclim company-template company-css company-nxml company-bbdb
company paren paredit golden-ratio darktooth-theme autothemer edmacro
kmacro server hl-line autorevert filenotify delsel paradox paradox-menu
paradox-commit-list hydra ring lv paradox-execute paradox-github
paradox-core spinner subr-x use-package diminish bind-key easy-mmode
gh-common gh-profile rx s ucs-normalize marshal eieio-compat ht json map
dash advice finder-inf info package epg-config url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache url-vars seq byte-opt gv bytecomp byte-compile cl-extra
help-mode easymenu cconv cl-loaddefs pcase cl-lib time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
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 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 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 dbusbind inotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 750198 370486)
 (symbols 48 49741 4)
 (miscs 40 1408 1870)
 (strings 32 199544 263193)
 (string-bytes 1 6329177)
 (vectors 16 96623)
 (vector-slots 8 2118756 224060)
 (floats 8 5135 1508)
 (intervals 56 23623 7076)
 (buffers 976 24))





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-01-24 21:05 bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame Alex 'QWxleA' Poslavsky
@ 2017-01-24 23:35 ` npostavs
  2017-01-25  3:37   ` Eli Zaretskii
  2017-01-25  3:31 ` Eli Zaretskii
  1 sibling, 1 reply; 30+ messages in thread
From: npostavs @ 2017-01-24 23:35 UTC (permalink / raw)
  To: Alex 'QWxleA' Poslavsky; +Cc: 25521

Alex 'QWxleA' Poslavsky <qwxlea@gmail.com> writes:

> The following, used as ~/.emacs.d/init.el:
>
> (require 'org)
>
> (defun qw ()
>   (interactive)
>   "Create a new capture frame helper-function" 
>   (make-frame '((name . "foo")
>                 (width . 120)
>                 (height . 25)))
>   (select-frame-by-name "foo") 
>   (org-agenda))
>
> works on emacs24, but not on a current git, build 24 Jan 2017. The
> error-message is: select-frame-by-name: There is no frame named ‘foo’
>
> I left everything else, but it doesn't look helpful.

I guess this is more fallout from my recent fix for #24091 [1: 6a788d2].
The following simplification of your `qw' function works for me:

(defun qw ()
  (interactive)
  "Create a new capture frame helper-function" 
  (select-frame (make-frame '((width . 120)
                              (height . 25))))
  (org-agenda))


1: 2017-01-20 23:36:26 -0500 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7
  Don't wait for frame to become visible





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-01-24 21:05 bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame Alex 'QWxleA' Poslavsky
  2017-01-24 23:35 ` npostavs
@ 2017-01-25  3:31 ` Eli Zaretskii
  2017-01-25  6:47   ` Alex (QWxleA)
  1 sibling, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2017-01-25  3:31 UTC (permalink / raw)
  To: Alex 'QWxleA' Poslavsky; +Cc: 25521

> From: Alex 'QWxleA' Poslavsky <qwxlea@gmail.com>
> Date: Tue, 24 Jan 2017 23:05:34 +0200
> 
> 
> The following, used as ~/.emacs.d/init.el:
> 
> (require 'org)
> 
> (defun qw ()
>   (interactive)
>   "Create a new capture frame helper-function" 
>   (make-frame '((name . "foo")
>                 (width . 120)
>                 (height . 25)))
>   (select-frame-by-name "foo") 
>   (org-agenda))
> 
> works on emacs24, but not on a current git, build 24 Jan 2017. The
> error-message is: select-frame-by-name: There is no frame named ‘foo’

Does it help to insert a short wait before the select-frame-by-name
call?





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-01-24 23:35 ` npostavs
@ 2017-01-25  3:37   ` Eli Zaretskii
  0 siblings, 0 replies; 30+ messages in thread
From: Eli Zaretskii @ 2017-01-25  3:37 UTC (permalink / raw)
  To: npostavs; +Cc: 25521, qwxlea

> From: npostavs@users.sourceforge.net
> Date: Tue, 24 Jan 2017 18:35:25 -0500
> Cc: 25521@debbugs.gnu.org
> 
> > (require 'org)
> >
> > (defun qw ()
> >   (interactive)
> >   "Create a new capture frame helper-function" 
> >   (make-frame '((name . "foo")
> >                 (width . 120)
> >                 (height . 25)))
> >   (select-frame-by-name "foo") 
> >   (org-agenda))
> >
> > works on emacs24, but not on a current git, build 24 Jan 2017. The
> > error-message is: select-frame-by-name: There is no frame named ‘foo’
> >
> > I left everything else, but it doesn't look helpful.
> 
> I guess this is more fallout from my recent fix for #24091 [1: 6a788d2].

I wonder whether we should reinstate a wait there, but make it limited
so that it never infloops.  Otherwise, these issues will continue to
haunt us and the users.





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-01-25  3:31 ` Eli Zaretskii
@ 2017-01-25  6:47   ` Alex (QWxleA)
  2017-01-25 23:43     ` npostavs
  0 siblings, 1 reply; 30+ messages in thread
From: Alex (QWxleA) @ 2017-01-25  6:47 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 25521


Eli Zaretskii writes:

>> From: Alex 'QWxleA' Poslavsky <qwxlea@gmail.com>
>> Date: Tue, 24 Jan 2017 23:05:34 +0200
>> 
>> 
>> The following, used as ~/.emacs.d/init.el:
>> 
>> (require 'org)
>> 
>> (defun qw ()
>>   (interactive)
>>   "Create a new capture frame helper-function" 
>>   (make-frame '((name . "foo")
>>                 (width . 120)
>>                 (height . 25)))
>>   (select-frame-by-name "foo") 
>>   (org-agenda))
>> 
>> works on emacs24, but not on a current git, build 24 Jan 2017. The
>> error-message is: select-frame-by-name: There is no frame named ‘foo’
>
> Does it help to insert a short wait before the select-frame-by-name
> call?

Yes, the following works:

(require 'org)

(defun qw ()
  (interactive)
  "Create a new capture frame helper-function" 
  (make-frame '((name . "foo")
                (width . 120)
                (height . 25)))
  (sleep-for 0.00134)
  (select-frame-by-name "foo") 
  (org-agenda))

If sleep gets any shorter it no longer works. The wait is short enough
not to be noticed. Good enough for me, thanks for the suggestion.





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-01-25  6:47   ` Alex (QWxleA)
@ 2017-01-25 23:43     ` npostavs
  2017-01-26 11:40       ` Alex (QWxleA)
  0 siblings, 1 reply; 30+ messages in thread
From: npostavs @ 2017-01-25 23:43 UTC (permalink / raw)
  To: Alex (QWxleA); +Cc: 25521

"Alex (QWxleA)" <qwxlea@gmail.com> writes:
>
> Yes, the following works:
>
> (require 'org)
>
> (defun qw ()
>   (interactive)
>   "Create a new capture frame helper-function" 
>   (make-frame '((name . "foo")
>                 (width . 120)
>                 (height . 25)))
>   (sleep-for 0.00134)
>   (select-frame-by-name "foo") 
>   (org-agenda))
>
> If sleep gets any shorter it no longer works. The wait is short enough
> not to be noticed. Good enough for me, thanks for the suggestion.

Can you clarify if the waitless version I suggested in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25521#8 also works?





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-01-25 23:43     ` npostavs
@ 2017-01-26 11:40       ` Alex (QWxleA)
  2017-01-26 14:37         ` npostavs
  0 siblings, 1 reply; 30+ messages in thread
From: Alex (QWxleA) @ 2017-01-26 11:40 UTC (permalink / raw)
  To: npostavs; +Cc: 25521

npostavs@users.sourceforge.net writes:

> "Alex (QWxleA)" <qwxlea@gmail.com> writes:
>>
>> Yes, the following works:
>>
>> (require 'org)
>>
>> (defun qw ()
>>   (interactive)
>>   "Create a new capture frame helper-function" 
>>   (make-frame '((name . "foo")
>>                 (width . 120)
>>                 (height . 25)))
>>   (sleep-for 0.00134)
>>   (select-frame-by-name "foo") 
>>   (org-agenda))
>>
>> If sleep gets any shorter it no longer works. The wait is short enough
>> not to be noticed. Good enough for me, thanks for the suggestion.
>
> Can you clarify if the waitless version I suggested in
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25521#8 also works?

No, the wrong frame is targeted without (select-frame-by-name "foo").
Without it, the parent-frame will run (org-agenda).

Select-frame-by-name does not work without (sleep-for 0.00134).

thanks,

Alex





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-01-26 11:40       ` Alex (QWxleA)
@ 2017-01-26 14:37         ` npostavs
  2017-01-26 15:48           ` Alex (QWxleA)
  0 siblings, 1 reply; 30+ messages in thread
From: npostavs @ 2017-01-26 14:37 UTC (permalink / raw)
  To: Alex (QWxleA); +Cc: 25521

"Alex (QWxleA)" <qwxlea@gmail.com> writes:

>>
>> Can you clarify if the waitless version I suggested in
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25521#8 also works?
>
> No, the wrong frame is targeted without (select-frame-by-name "foo").
> Without it, the parent-frame will run (org-agenda).
>
> Select-frame-by-name does not work without (sleep-for 0.00134).

It sounds like you didn't try my suggestion to use

    (select-frame (make-frame '((width . 120)
                                (height . 25))))

instead of select-frame-by-name.  Could you please try that?  (or is
there some other reason it doesn't apply in your situation?)





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-01-26 14:37         ` npostavs
@ 2017-01-26 15:48           ` Alex (QWxleA)
  2017-01-27  2:02             ` npostavs
  0 siblings, 1 reply; 30+ messages in thread
From: Alex (QWxleA) @ 2017-01-26 15:48 UTC (permalink / raw)
  To: npostavs; +Cc: 25521


npostavs@users.sourceforge.net writes:

> "Alex (QWxleA)" <qwxlea@gmail.com> writes:
>
>>>
>>> Can you clarify if the waitless version I suggested in
>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25521#8 also works?
>>
>> No, the wrong frame is targeted without (select-frame-by-name "foo").
>> Without it, the parent-frame will run (org-agenda).
>>
>> Select-frame-by-name does not work without (sleep-for 0.00134).
>
> It sounds like you didn't try my suggestion to use
>
>     (select-frame (make-frame '((width . 120)
>                                 (height . 25))))
>
> instead of select-frame-by-name.  Could you please try that?  (or is
> there some other reason it doesn't apply in your situation?)

Ah, sorry, did not try that. Your above mentioned suggestion works. As I
needed the name to be set for my window-manager, I ended up with the following (but it
also works without (name . "foo")):

(defun qw ()
  (interactive) 
  (select-frame (make-frame '((name . "foo") 
                              (width . 120)
                              (height . 25))))
  (org-agenda))

This is perfect, it does the same thing as:

(defun qw ()
  (interactive)
  (make-frame '( (name . "foo")
                (width . 120)
                (height . 25)))
  (sleep-for 0.00134)
  (select-frame-by-name "foo") 
  (org-agenda))

But without the time-delay, so for my use it works, and is shorter to
boot, excellent!

Select-frame-by-name is a bit slow, when called right after make-frame, which might be
a bug or not.

Thanks for all the replies,

Alex





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-01-26 15:48           ` Alex (QWxleA)
@ 2017-01-27  2:02             ` npostavs
  2017-01-27  7:56               ` Eli Zaretskii
  0 siblings, 1 reply; 30+ messages in thread
From: npostavs @ 2017-01-27  2:02 UTC (permalink / raw)
  To: Alex (QWxleA); +Cc: 25521

"Alex (QWxleA)" <qwxlea@gmail.com> writes:
>
> Ah, sorry, did not try that. Your above mentioned suggestion works. As I
> needed the name to be set for my window-manager, I ended up with the following (but it
> also works without (name . "foo")):
>
> (defun qw ()
>   (interactive) 
>   (select-frame (make-frame '((name . "foo") 
>                               (width . 120)
>                               (height . 25))))
>   (org-agenda))
>
> This is perfect, it does the same thing as:
>
> (defun qw ()
>   (interactive)
>   (make-frame '( (name . "foo")
>                 (width . 120)
>                 (height . 25)))
>   (sleep-for 0.00134)
>   (select-frame-by-name "foo") 
>   (org-agenda))
>
> But without the time-delay, so for my use it works, and is shorter to
> boot, excellent!

Thanks for confirming.

> Select-frame-by-name is a bit slow, when called right after make-frame, which might be
> a bug or not.

select-frame-by-name only selects frames that are on the current
display, so it doesn't work for frames that haven't been selected yet.
Until recently, Emacs would busy wait until the frame becomes visible,
now that it doesn't, you need to add the wait in lisp code.

Eli Zaretskii <eliz@gnu.org> writes:
>
> I wonder whether we should reinstate a wait there, but make it limited
> so that it never infloops.  Otherwise, these issues will continue to
> haunt us and the users.

This case can be solved in a simpler way, and in the other case
(Bug#25511), I believe Martin was saying something similar, so I think
it would be a bit premature to add the busy wait again.

For select-frame-by-name specifically, we could make it check
non-visible frames as well, though I'm inclined to just mark this as
notabug/wontfix.





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-01-27  2:02             ` npostavs
@ 2017-01-27  7:56               ` Eli Zaretskii
  2017-06-30  3:08                 ` npostavs
  0 siblings, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2017-01-27  7:56 UTC (permalink / raw)
  To: npostavs; +Cc: 25521, qwxlea

> From: npostavs@users.sourceforge.net
> Cc: 25521@debbugs.gnu.org,  Eli Zaretskii <eliz@gnu.org>
> Date: Thu, 26 Jan 2017 21:02:41 -0500
> 
> > I wonder whether we should reinstate a wait there, but make it limited
> > so that it never infloops.  Otherwise, these issues will continue to
> > haunt us and the users.
> 
> This case can be solved in a simpler way, and in the other case
> (Bug#25511), I believe Martin was saying something similar, so I think
> it would be a bit premature to add the busy wait again.

Issues with rare use cases usually take many moons to emerge, but in
this case the complaints started right away.  So it seems like the
elimination of the loop interferes with non-rare use cases, which
means we will probably be seeing much more of similar complaints in
the future, including for stuff people do in their init files without
too detailed understanding of the underlying machinery.  I'd expect at
least some of these case not easily solved, and in any case it's a
nuisance to users and Lisp package developers.

What's more, a similar loop still exists on w32, so we will have
subtly different behavior on different platforms.

Reinstating the loop, but without the danger of inflooping, could have
taken care of these issues in advance.  Thus my proposal.





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-01-27  7:56               ` Eli Zaretskii
@ 2017-06-30  3:08                 ` npostavs
  2017-06-30  6:09                   ` Eli Zaretskii
  2017-06-30  6:52                   ` martin rudalics
  0 siblings, 2 replies; 30+ messages in thread
From: npostavs @ 2017-06-30  3:08 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 25521, qwxlea

Eli Zaretskii <eliz@gnu.org> writes:

> Issues with rare use cases usually take many moons to emerge, but in
> this case the complaints started right away.  So it seems like the
> elimination of the loop interferes with non-rare use cases, which
> means we will probably be seeing much more of similar complaints in
> the future, including for stuff people do in their init files without
> too detailed understanding of the underlying machinery.

On the other hand, I haven't seen any additional cases since the first
two...

> I'd expect at least some of these case not easily solved, and in any
> case it's a nuisance to users and Lisp package developers.
>
> What's more, a similar loop still exists on w32, so we will have
> subtly different behavior on different platforms.
>
> Reinstating the loop, but without the danger of inflooping, could have
> taken care of these issues in advance.  Thus my proposal.

How about removing the delay from w32 as well, and implementing it in
lisp, then it will be easier to play with (by the way,
x_make_frame_visible in nsterm.m does not have any delay so we already
had different behaviour on different platforms).

--- c/lisp/frame.el
+++ i/lisp/frame.el
@@ -610,6 +610,15 @@ (defvar after-make-frame-functions nil
   "Functions to run after a frame is created.
 The functions are run with one arg, the newly created frame.")
 
+(defun wait-until-frame-is-visible (frame)
+  "Busy wait until FRAME is visible."
+  (let ((start-time (current-time)))
+    (while (and (not (frame-visible-p frame))
+                (< (float-time (subtract-time (current-time) start-time)) 1.0))
+      (sit-for 0.05))))
+
+(add-hook 'after-make-frame-functions #'wait-until-frame-is-visible)
+
 (defvar after-setting-font-hook nil
   "Functions to run after a frame's font has been changed.")
 







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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-06-30  3:08                 ` npostavs
@ 2017-06-30  6:09                   ` Eli Zaretskii
  2017-06-30  6:52                   ` martin rudalics
  1 sibling, 0 replies; 30+ messages in thread
From: Eli Zaretskii @ 2017-06-30  6:09 UTC (permalink / raw)
  To: npostavs; +Cc: 25521, qwxlea

> From: npostavs@users.sourceforge.net
> Cc: 25521@debbugs.gnu.org,  qwxlea@gmail.com
> Date: Thu, 29 Jun 2017 23:08:46 -0400
> 
> How about removing the delay from w32 as well, and implementing it in
> lisp, then it will be easier to play with

If it works, why not?  Just make sure this is well tested in the many
use cases where new frames pop up, including the initial frame, the
additional frames created by "C-x 5" and 'make-frame', the
minibufferless and minbuffer-only frames, the non-nil pop-up-frames
case, the tooltip frames, ...

> (by the way,
> x_make_frame_visible in nsterm.m does not have any delay so we already
> had different behaviour on different platforms).

To tell the truth, the NS port was never well in our sights.

Thanks.





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-06-30  3:08                 ` npostavs
  2017-06-30  6:09                   ` Eli Zaretskii
@ 2017-06-30  6:52                   ` martin rudalics
  2017-09-01  3:13                     ` npostavs
  1 sibling, 1 reply; 30+ messages in thread
From: martin rudalics @ 2017-06-30  6:52 UTC (permalink / raw)
  To: npostavs, Eli Zaretskii; +Cc: 25521, qwxlea

 > How about removing the delay from w32 as well, and implementing it in
...
 > +(add-hook 'after-make-frame-functions #'wait-until-frame-is-visible)

Note that currently the w32 port waits only for frames that are meant to
become visible and also waits every time a frame becomes visible and not
only after it was created.

martin





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-06-30  6:52                   ` martin rudalics
@ 2017-09-01  3:13                     ` npostavs
  2017-09-01  6:56                       ` Eli Zaretskii
  2017-09-01 13:02                       ` martin rudalics
  0 siblings, 2 replies; 30+ messages in thread
From: npostavs @ 2017-09-01  3:13 UTC (permalink / raw)
  To: martin rudalics; +Cc: 25521, qwxlea

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

tags 25521 + patch
quit

martin rudalics <rudalics@gmx.at> writes:

>> How about removing the delay from w32 as well, and implementing it in
> ...
>> +(add-hook 'after-make-frame-functions #'wait-until-frame-is-visible)
>
> Note that currently the w32 port waits only for frames that are meant to
> become visible and also waits every time a frame becomes visible and not
> only after it was created.

Hmm, I thought I could get away with using an existing hook.  But
looking at all the places where x_make_frame_visible is called, I'm
feeling reluctant to introduce lisp evaluation into them.  I think we
should go with Eli's idea, bring back the busy wait but add a timeout.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 6389 bytes --]

From 3b8e60de58ae2b2f9fafd806e9f888e716a0f22b Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Wed, 30 Aug 2017 23:12:22 -0400
Subject: [PATCH v1] Bring back the busy wait after x_make_frame_visible
 (Bug#25521)

But limit the wait to a configurable timeout.  This mostly reverts
"Don't wait for frame to become visible".
* src/xterm.c (syms_of_xterm) [x-visible-frame-timeout]: New variable.
* src/xterm.c (x_make_frame_visible):
* src/w32term.c (x_make_frame_visible): Wait for frame to become
visible according to its value.
---
 src/w32term.c | 13 ++++++++----
 src/xterm.c   | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 74 insertions(+), 6 deletions(-)

diff --git a/src/w32term.c b/src/w32term.c
index 2785ae2b52..8b129ae029 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -6609,7 +6609,8 @@ w32_frame_raise_lower (struct frame *f, bool raise_flag)
 \f
 /* Change of visibility.  */
 
-/* This tries to wait until the frame is really visible.
+/* This tries to wait until the frame is really visible, depending on
+   the value of Vx_visible_frame_timeout.
    However, if the window manager asks the user where to position
    the frame, this will return before the user finishes doing that.
    The frame will not actually be visible at that time,
@@ -6668,12 +6669,16 @@ x_make_frame_visible (struct frame *f)
 		      : SW_SHOWNORMAL);
     }
 
+  if (!FLOATP (Vx_visible_frame_timeout))
+      return;
+
   /* Synchronize to ensure Emacs knows the frame is visible
      before we do anything else.  We do this loop with input not blocked
      so that incoming events are handled.  */
   {
     Lisp_Object frame;
-    int count;
+    double timeout = XFLOAT_DATA (Vx_visible_frame_timeout);
+    double start_time = XFLOAT_DATA (Ffloat_time (Qnil));
 
     /* This must come after we set COUNT.  */
     unblock_input ();
@@ -6683,8 +6688,8 @@ x_make_frame_visible (struct frame *f)
     /* Wait until the frame is visible.  Process X events until a
        MapNotify event has been seen, or until we think we won't get a
        MapNotify at all..  */
-    for (count = input_signal_count + 10;
-	 input_signal_count < count && !FRAME_VISIBLE_P (f);)
+    while (timeout > (XFLOAT_DATA (Ffloat_time (Qnil)) - start_time) &&
+           !FRAME_VISIBLE_P (f))
       {
 	/* Force processing of queued events.  */
         /* TODO: x_sync equivalent?  */
diff --git a/src/xterm.c b/src/xterm.c
index a7a52064a1..3ade688f1b 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -11373,8 +11373,13 @@ xembed_send_message (struct frame *f, Time t, enum xembed_message msg,
 \f
 /* Change of visibility.  */
 
-/* This function sends the request to make the frame visible, but may
-   return before it the frame's visibility is changed.  */
+/* This tries to wait until the frame is really visible, depending on
+   the value of Vx_visible_frame_timeout.
+   However, if the window manager asks the user where to position
+   the frame, this will return before the user finishes doing that.
+   The frame will not actually be visible at that time,
+   but it will become visible later when the window manager
+   finishes with it.  */
 
 void
 x_make_frame_visible (struct frame *f)
@@ -11445,11 +11450,14 @@ x_make_frame_visible (struct frame *f)
      before we do anything else.  We do this loop with input not blocked
      so that incoming events are handled.  */
   {
+    Lisp_Object frame;
     /* This must be before UNBLOCK_INPUT
        since events that arrive in response to the actions above
        will set it when they are handled.  */
     bool previously_visible = f->output_data.x->has_been_visible;
 
+    XSETFRAME (frame, f);
+
     int original_left = f->left_pos;
     int original_top = f->top_pos;
 
@@ -11496,6 +11504,48 @@ x_make_frame_visible (struct frame *f)
 
 	unblock_input ();
       }
+
+
+    if (!FLOATP (Vx_visible_frame_timeout))
+      return;
+
+    double timeout = XFLOAT_DATA (Vx_visible_frame_timeout);
+    double start_time = XFLOAT_DATA (Ffloat_time (Qnil));
+
+    /* Process X events until a MapNotify event has been seen.  */
+    while (timeout > (XFLOAT_DATA (Ffloat_time (Qnil)) - start_time) &&
+           !FRAME_VISIBLE_P (f))
+      {
+	/* Force processing of queued events.  */
+	x_sync (f);
+
+       /* This hack is still in use at least for Cygwin.  See
+	   http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00351.html.
+
+	   Machines that do polling rather than SIGIO have been
+	   observed to go into a busy-wait here.  So we'll fake an
+	   alarm signal to let the handler know that there's something
+	   to be read.  We used to raise a real alarm, but it seems
+	   that the handler isn't always enabled here.  This is
+	   probably a bug.  */
+	if (input_polling_used ())
+	  {
+	    /* It could be confusing if a real alarm arrives while
+	       processing the fake one.  Turn it off and let the
+	       handler reset it.  */
+	    int old_poll_suppress_count = poll_suppress_count;
+	    poll_suppress_count = 1;
+	    poll_for_input_1 ();
+	    poll_suppress_count = old_poll_suppress_count;
+	  }
+
+	if (XPending (FRAME_X_DISPLAY (f)))
+	  {
+	    XEvent xev;
+	    XNextEvent (FRAME_X_DISPLAY (f), &xev);
+	    x_dispatch_event (&xev, FRAME_X_DISPLAY (f));
+	  }
+      }
   }
 }
 
@@ -13291,6 +13341,19 @@ syms_of_xterm (void)
 keysyms.  The default is nil, which is the same as `super'.  */);
   Vx_super_keysym = Qnil;
 
+  DEFVAR_LISP ("x-visible-frame-timeout", Vx_visible_frame_timeout,
+    doc: /* How long to wait for a frame to become visible.
+Emacs will wait up to this many seconds after `make-frame-visible' is
+called until receiving notification from the windowing system that the
+frame has become visible.  Under some window managers this can take an
+indefinite amount of time, so it is important to limit the wait.
+
+If set to a non-float value, there will be no wait at all.  This
+should be fine unless your config contains some code that assumes
+frames will become visible immediately (e.g., calling
+`select-frame-by-name' directly after creating a named frame). */);
+  Vx_visible_frame_timeout = make_float (0.5);
+
   DEFVAR_LISP ("x-keysym-table", Vx_keysym_table,
     doc: /* Hash table of character codes indexed by X keysym codes.  */);
   Vx_keysym_table = make_hash_table (hashtest_eql, 900,
-- 
2.14.1


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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-09-01  3:13                     ` npostavs
@ 2017-09-01  6:56                       ` Eli Zaretskii
  2017-09-01 13:02                       ` martin rudalics
  1 sibling, 0 replies; 30+ messages in thread
From: Eli Zaretskii @ 2017-09-01  6:56 UTC (permalink / raw)
  To: npostavs; +Cc: 25521, qwxlea

> From: npostavs@users.sourceforge.net
> Cc: Eli Zaretskii <eliz@gnu.org>,  25521@debbugs.gnu.org,  qwxlea@gmail.com
> Date: Thu, 31 Aug 2017 23:13:50 -0400
> 
> Hmm, I thought I could get away with using an existing hook.  But
> looking at all the places where x_make_frame_visible is called, I'm
> feeling reluctant to introduce lisp evaluation into them.  I think we
> should go with Eli's idea, bring back the busy wait but add a timeout.

This needs a NEWS entry about the new variable, I think.

Please push in a few days if no one objects, and thanks.





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-09-01  3:13                     ` npostavs
  2017-09-01  6:56                       ` Eli Zaretskii
@ 2017-09-01 13:02                       ` martin rudalics
  2017-09-01 13:41                         ` npostavs
  1 sibling, 1 reply; 30+ messages in thread
From: martin rudalics @ 2017-09-01 13:02 UTC (permalink / raw)
  To: npostavs; +Cc: 25521, qwxlea

 > Hmm, I thought I could get away with using an existing hook.  But
 > looking at all the places where x_make_frame_visible is called, I'm
 > feeling reluctant to introduce lisp evaluation into them.  I think we
 > should go with Eli's idea, bring back the busy wait but add a timeout.

I'm not very convinced.  First, the present bug should not motivate this
change.  ‘select-frame-by-name’ is a pretty obscure function.  It fails
in the OP's case because the display info for the new frame has not been
yet set up.  In the interactive call, suggesting a default frame on the
current terminal makes sense; so consulting that info is useful.  But
the info is useless in a non-interactive call: Nothing should prevent
that function from selecting a frame with a given name on any display.

Second, we'll then have a third way how to wait on X for something to
happen: We already have x_wait_for_event with a fixed 0.1 second timeout
for frame resizing.  And we have x_sync_with_move which counts till 50,
may return early when the frame is within some fuzzy distance from the
expected position and waits another 0.5 seconds if the frame hasn't made
it there till then.

martin






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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-09-01 13:02                       ` martin rudalics
@ 2017-09-01 13:41                         ` npostavs
  2017-09-01 15:45                           ` martin rudalics
  0 siblings, 1 reply; 30+ messages in thread
From: npostavs @ 2017-09-01 13:41 UTC (permalink / raw)
  To: martin rudalics; +Cc: 25521, qwxlea

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

martin rudalics <rudalics@gmx.at> writes:

> I'm not very convinced.  First, the present bug should not motivate this
> change.  ‘select-frame-by-name’ is a pretty obscure function.  It fails
> in the OP's case because the display info for the new frame has not been
> yet set up.  In the interactive call, suggesting a default frame on the
> current terminal makes sense; so consulting that info is useful.  But
> the info is useless in a non-interactive call: Nothing should prevent
> that function from selecting a frame with a given name on any display.

Ah, so we could just do something like this? (untested)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 1157 bytes --]

From c31a39c300e32af1f9b810e92065208eb1b5c2f3 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Fri, 1 Sep 2017 09:38:55 -0400
Subject: [PATCH v2] Let select-frame-by-name choose any frame when called from
 lisp (Bug#25521)

* lisp/frame.el (select-frame-by-name): Choose from the whole list of
frames in the non-interactive part.
---
 lisp/frame.el | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/lisp/frame.el b/lisp/frame.el
index 2a14302e9f..e8b7c82cbb 100644
--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -905,11 +905,12 @@ select-frame-by-name
      (if (= (length input) 0)
 	 (list default)
        (list input))))
-  (let* ((frame-names-alist (make-frame-names-alist))
-	 (frame (cdr (assoc name frame-names-alist))))
-    (if frame
-	(select-frame-set-input-focus frame)
-      (error "There is no frame named `%s'" name))))
+  (catch 'done
+    (dolist (frame (frame-list))
+      (when (equal (frame-parameter frame 'name) name)
+        (select-frame-set-input-focus frame)
+        (throw 'done t)))
+    (error "There is no frame named `%s'" name)))
 
 \f
 ;;;; Background mode.
-- 
2.14.1


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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-09-01 13:41                         ` npostavs
@ 2017-09-01 15:45                           ` martin rudalics
  2017-09-26  2:54                             ` Noam Postavsky
  0 siblings, 1 reply; 30+ messages in thread
From: martin rudalics @ 2017-09-01 15:45 UTC (permalink / raw)
  To: npostavs; +Cc: 25521, qwxlea

 > Ah, so we could just do something like this? (untested)

With a slightly amended doc-string, yes.  If someone insists on having
two frames with the same name on different displays and relying on the
old behavior to choose the one on the same display, we could add such a
check to give preference to a frame with the given name on the same
display.  I doubt that someone relies on this function to throw an error
when a frame with the given name exists only on another display.

Note that I'm not opposed to a timeout solution.  As far as w32term.c is
concerned, I think your solution is superior to the present one.  But
IMHO we should try to orchestrate all these efforts using a timer to
synchronize Emacs with the window manager or window system in a uniform
way so that the user knows where and how her time is spent.

For example, if we decided that x_wait_for_event is a good idea, then we
should implement it on Windows too and use it uniformly when waiting for
a move frame event or the visibility confirmation.

martin





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-09-01 15:45                           ` martin rudalics
@ 2017-09-26  2:54                             ` Noam Postavsky
  2017-09-27  8:11                               ` martin rudalics
  0 siblings, 1 reply; 30+ messages in thread
From: Noam Postavsky @ 2017-09-26  2:54 UTC (permalink / raw)
  To: martin rudalics; +Cc: 25521, qwxlea

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

martin rudalics <rudalics@gmx.at> writes:

>> Ah, so we could just do something like this? (untested)
>
> With a slightly amended doc-string, yes.  If someone insists on having
> two frames with the same name on different displays and relying on the
> old behavior to choose the one on the same display, we could add such a
> check to give preference to a frame with the given name on the same
> display.  I doubt that someone relies on this function to throw an error
> when a frame with the given name exists only on another display.

Right, here's an update:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 1737 bytes --]

From 846c5603a02544ef9b25f395c253b3621aea4984 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Fri, 1 Sep 2017 09:38:55 -0400
Subject: [PATCH 1/3] Let select-frame-by-name choose any frame when called
 from lisp (Bug#25521)

* lisp/frame.el (select-frame-by-name): Choose from the whole list of
frames in the non-interactive part, if not found on the current
display.
---
 lisp/frame.el | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/lisp/frame.el b/lisp/frame.el
index 76c1842455..a710360cdb 100644
--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -892,7 +892,8 @@ make-frame-names-alist
 
 (defvar frame-name-history nil)
 (defun select-frame-by-name (name)
-  "Select the frame on the current terminal whose name is NAME and raise it.
+  "Select the frame whose name is NAME and raise it.
+Frames on the current terminal are checked first.
 If there is no frame by that name, signal an error."
   (interactive
    (let* ((frame-names-alist (make-frame-names-alist))
@@ -903,11 +904,14 @@ select-frame-by-name
      (if (= (length input) 0)
 	 (list default)
        (list input))))
-  (let* ((frame-names-alist (make-frame-names-alist))
-	 (frame (cdr (assoc name frame-names-alist))))
-    (if frame
-	(select-frame-set-input-focus frame)
-      (error "There is no frame named `%s'" name))))
+  (select-frame-set-input-focus
+   ;; Prefer frames on the current display.
+   (or (cdr (assoc name (make-frame-names-alist)))
+       (catch 'done
+         (dolist (frame (frame-list))
+           (when (equal (frame-parameter frame 'name) name)
+             (throw 'done frame))))
+       (error "There is no frame named `%s'" name))))
 
 \f
 ;;;; Background mode.
-- 
2.11.0


[-- Attachment #3: Type: text/plain, Size: 721 bytes --]


> Note that I'm not opposed to a timeout solution.  As far as w32term.c is
> concerned, I think your solution is superior to the present one.  But
> IMHO we should try to orchestrate all these efforts using a timer to
> synchronize Emacs with the window manager or window system in a uniform
> way so that the user knows where and how her time is spent.
>
> For example, if we decided that x_wait_for_event is a good idea, then we
> should implement it on Windows too and use it uniformly when waiting for
> a move frame event or the visibility confirmation.

Huh.  I was not aware of those other functions.  Here's a patch which
makes the timeout in x_wait_for_event configurable, and uses it in
x_make_frame_visible.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: patch --]
[-- Type: text/x-diff, Size: 4551 bytes --]

From 9c6730723507505f2c9f46148addd56901cd0bcc Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Wed, 30 Aug 2017 23:12:22 -0400
Subject: [PATCH 2/3] Bring back the busy wait after x_make_frame_visible
 (Bug#25521)

But wait specfically for a MapNotify event, and only for a
configurable amount of time.
* src/xterm.c (syms_of_xterm) [x-wait-for-event-timeout]: New
variable.
(x_wait_for_event): Use it instead of hardcoding the wait to 0.1s.
(x_make_frame_visible): Call x_wait_for_event at the end.
* etc/NEWS: Announce x_wait_for_event.
---
 etc/NEWS    |  5 +++++
 src/xterm.c | 37 +++++++++++++++++++++++++++++++------
 2 files changed, 36 insertions(+), 6 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index 1b5ae658f6..adcc879cb2 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -600,6 +600,11 @@ The two new variables, 'bidi-paragraph-start-re' and
 'bidi-paragraph-separate-re', allow customization of what exactly are
 paragraphs, for the purposes of bidirectional display.
 
+---
+** New variable 'x-wait-for-event-timeout'.
+This controls how long Emacs will wait for updates to the graphical
+state to take effect (making a frame visible, for example).
+
 \f
 * Changes in Specialized Modes and Packages in Emacs 26.1
 
diff --git a/src/xterm.c b/src/xterm.c
index 0b321909c8..50d023f4d9 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -11029,17 +11029,19 @@ x_sync_with_move (struct frame *f, int left, int top, bool fuzzy)
 void
 x_wait_for_event (struct frame *f, int eventtype)
 {
-  int level = interrupt_input_blocked;
+  if (!FLOATP (Vx_wait_for_event_timeout))
+    return;
 
+  int level = interrupt_input_blocked;
   fd_set fds;
   struct timespec tmo, tmo_at, time_now;
   int fd = ConnectionNumber (FRAME_X_DISPLAY (f));
 
   f->wait_event_type = eventtype;
 
-  /* Set timeout to 0.1 second.  Hopefully not noticeable.
-     Maybe it should be configurable.  */
-  tmo = make_timespec (0, 100 * 1000 * 1000);
+  /* Default timeout is 0.1 second.  Hopefully not noticeable.  */
+  double timeout = XFLOAT_DATA (Vx_wait_for_event_timeout);
+  tmo = make_timespec (0, (long int) (timeout * 1000 * 1000 * 1000));
   tmo_at = timespec_add (current_timespec (), tmo);
 
   while (f->wait_event_type)
@@ -11365,8 +11367,13 @@ xembed_send_message (struct frame *f, Time t, enum xembed_message msg,
 \f
 /* Change of visibility.  */
 
-/* This function sends the request to make the frame visible, but may
-   return before it the frame's visibility is changed.  */
+/* This tries to wait until the frame is really visible, depending on
+   the value of Vx_visible_frame_timeout.
+   However, if the window manager asks the user where to position
+   the frame, this will return before the user finishes doing that.
+   The frame will not actually be visible at that time,
+   but it will become visible later when the window manager
+   finishes with it.  */
 
 void
 x_make_frame_visible (struct frame *f)
@@ -11437,11 +11444,14 @@ x_make_frame_visible (struct frame *f)
      before we do anything else.  We do this loop with input not blocked
      so that incoming events are handled.  */
   {
+    Lisp_Object frame;
     /* This must be before UNBLOCK_INPUT
        since events that arrive in response to the actions above
        will set it when they are handled.  */
     bool previously_visible = f->output_data.x->has_been_visible;
 
+    XSETFRAME (frame, f);
+
     int original_left = f->left_pos;
     int original_top = f->top_pos;
 
@@ -11488,6 +11498,10 @@ x_make_frame_visible (struct frame *f)
 
 	unblock_input ();
       }
+
+    /* Try to wait for a MapNotify event (that is what tells us when a
+       frame becomes visible).  */
+    x_wait_for_event (f, MapNotify);
   }
 }
 
@@ -13283,6 +13297,17 @@ syms_of_xterm (void)
 keysyms.  The default is nil, which is the same as `super'.  */);
   Vx_super_keysym = Qnil;
 
+  DEFVAR_LISP ("x-wait-for-event-timeout", Vx_wait_for_event_timeout,
+    doc: /* How long to wait for X events.
+
+Emacs will wait up to this many seconds to receive X events after
+making changes which affect the state of the graphical interface.
+Under some window managers this can take an indefinite amount of time,
+so it is important to limit the wait.
+
+If set to a non-float value, there will be no wait at all.  */);
+  Vx_wait_for_event_timeout = make_float (0.1);
+
   DEFVAR_LISP ("x-keysym-table", Vx_keysym_table,
     doc: /* Hash table of character codes indexed by X keysym codes.  */);
   Vx_keysym_table = make_hash_table (hashtest_eql, 900,
-- 
2.11.0


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


However, based on this comment in w32_read_socket, I think we can't use
the x_wait_for_event approach for w32.

  /* Check which frames are still visible, if we have enqueued any user
     events or been notified of events that may affect visibility.  We
     do this here because there doesn't seem to be any direct
     notification from Windows that the visibility of a window has
     changed (at least, not in all cases).  */

The final patch uses the same timeout variable, not sure if that's much
of an improvement.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #6: patch --]
[-- Type: text/x-diff, Size: 3630 bytes --]

From e0f8d29834afe72b64a3b6f87490cd4e0e571490 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Mon, 25 Sep 2017 21:58:55 -0400
Subject: [PATCH 3/3] Wait for frame visibility with timeout in w32term too

* src/w32term.c (syms_of_w32term) [x-wait-for-event-timeout]: New
variable.
(x_make_frame_visible): Wait for frame to become visible according to
its value.
(input_signal_count): Remove.
---
 src/w32term.c | 31 ++++++++++++++++++++-----------
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/src/w32term.c b/src/w32term.c
index a7a510b9ec..59d1b950ae 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -163,10 +163,6 @@ BOOL (WINAPI *pfnSetLayeredWindowAttributes) (HWND, COLORREF, BYTE, DWORD);
 /* Keyboard code page - may be changed by language-change events.  */
 int w32_keyboard_codepage;
 
-/* Incremented by w32_read_socket whenever it really tries to read
-   events.  */
-static int volatile input_signal_count;
-
 #ifdef CYGWIN
 int w32_message_fd = -1;
 #endif /* CYGWIN */
@@ -4658,9 +4654,6 @@ w32_read_socket (struct terminal *terminal,
 
   block_input ();
 
-  /* So people can tell when we have read the available input.  */
-  input_signal_count++;
-
   /* Process any incoming thread messages.  */
   drain_message_queue ();
 
@@ -6612,7 +6605,8 @@ w32_frame_raise_lower (struct frame *f, bool raise_flag)
 \f
 /* Change of visibility.  */
 
-/* This tries to wait until the frame is really visible.
+/* This tries to wait until the frame is really visible, depending on
+   the value of Vx_visible_frame_timeout.
    However, if the window manager asks the user where to position
    the frame, this will return before the user finishes doing that.
    The frame will not actually be visible at that time,
@@ -6671,12 +6665,16 @@ x_make_frame_visible (struct frame *f)
 		      : SW_SHOWNORMAL);
     }
 
+  if (!FLOATP (Vx_wait_for_event_timeout))
+      return;
+
   /* Synchronize to ensure Emacs knows the frame is visible
      before we do anything else.  We do this loop with input not blocked
      so that incoming events are handled.  */
   {
     Lisp_Object frame;
-    int count;
+    double timeout = XFLOAT_DATA (Vx_wait_for_event_timeout);
+    double start_time = XFLOAT_DATA (Ffloat_time (Qnil));
 
     /* This must come after we set COUNT.  */
     unblock_input ();
@@ -6686,8 +6684,8 @@ x_make_frame_visible (struct frame *f)
     /* Wait until the frame is visible.  Process X events until a
        MapNotify event has been seen, or until we think we won't get a
        MapNotify at all..  */
-    for (count = input_signal_count + 10;
-	 input_signal_count < count && !FRAME_VISIBLE_P (f);)
+    while (timeout > (XFLOAT_DATA (Ffloat_time (Qnil)) - start_time) &&
+           !FRAME_VISIBLE_P (f))
       {
 	/* Force processing of queued events.  */
         /* TODO: x_sync equivalent?  */
@@ -7319,6 +7317,17 @@ syms_of_w32term (void)
   DEFSYM (Qrenamed_from, "renamed-from");
   DEFSYM (Qrenamed_to, "renamed-to");
 
+  DEFVAR_LISP ("x-wait-for-event-timeout", Vx_wait_for_event_timeout,
+    doc: /* How long to wait for X events.
+
+Emacs will wait up to this many seconds to receive X events after
+making changes which affect the state of the graphical interface.
+Under some window managers this can take an indefinite amount of time,
+so it is important to limit the wait.
+
+If set to a non-float value, there will be no wait at all.  */);
+  Vx_wait_for_event_timeout = make_float (0.1);
+
   DEFVAR_INT ("w32-num-mouse-buttons",
 	      w32_num_mouse_buttons,
 	      doc: /* Number of physical mouse buttons.  */);
-- 
2.11.0


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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-09-26  2:54                             ` Noam Postavsky
@ 2017-09-27  8:11                               ` martin rudalics
  2017-09-27 12:13                                 ` Noam Postavsky
                                                   ` (2 more replies)
  0 siblings, 3 replies; 30+ messages in thread
From: martin rudalics @ 2017-09-27  8:11 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: 25521, qwxlea

 > Right, here's an update:

I would add to NEWS something like "'select-frame-by-name' now may
return a frame on another display if it does not find a suitable one on
the current display".

 > Huh.  I was not aware of those other functions.  Here's a patch which
 > makes the timeout in x_wait_for_event configurable, and uses it in
 > x_make_frame_visible.

Is there anything I could tweak here to observe a visible impact?  If I
set ‘x-wait-for-event-timeout’ to some large value nothing becomes
noticeable here, apparently because the frame is created fast enough.

Anyway, I'd proceed as follows:

(1) Install the xterm.c and w32term.c patches on the release branch.

(2) Ask Alex to play around with the settings.  If Alex can use the
     variable to change the behavior from bad to good and back and there
     are no problems with other users, let's consider this part as done
     and the bug closed.

(3) Install the ‘select-frame-by-name’ patch on the release branch.

The reason why I think that (3) is good to have despite of (1) is that
functions would behave reasonably well on systems where the user sets
the timeout to zero.  Thus people who, for some reason, cannot or do not
want a larger timeout have a fallback.  Differently put: A timeout of
zero should work well as default too.

But let's wait for Eli to make a decision.

Thanks, martin






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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-09-27  8:11                               ` martin rudalics
@ 2017-09-27 12:13                                 ` Noam Postavsky
  2017-09-29  8:33                                   ` martin rudalics
  2017-09-29 13:39                                 ` Eli Zaretskii
  2017-10-14  2:14                                 ` Noam Postavsky
  2 siblings, 1 reply; 30+ messages in thread
From: Noam Postavsky @ 2017-09-27 12:13 UTC (permalink / raw)
  To: martin rudalics; +Cc: 25521, qwxlea

martin rudalics <rudalics@gmx.at> writes:

> I would add to NEWS something like "'select-frame-by-name' now may
> return a frame on another display if it does not find a suitable one on
> the current display".

Sure.

> Is there anything I could tweak here to observe a visible impact?  If I
> set ‘x-wait-for-event-timeout’ to some large value nothing becomes
> noticeable here, apparently because the frame is created fast enough.

I think you might have to change window managers.  For instance, when
using i3, adding 'assign [class="Emacs"] 9' to ~/.i3/config will make
Emacs frames show up in workspace 9.  When calling make-frame-command
from a different workspace, Emacs will not get the message about frame
visibility until you switch to workspace 9.

    (let ((x-wait-for-event-timeout nil))
      (benchmark 1 '(make-frame-command)))"Elapsed time: 0.083540s"
    (let ((x-wait-for-event-timeout 0.1)) ; default
      (benchmark 1 '(make-frame-command)))"Elapsed time: 0.169369s"
    (let ((x-wait-for-event-timeout 100.0))
      (benchmark 1 '(make-frame-command)))"Elapsed time: 1.338770s (0.052083s in 1 GCs)"

Hmm, that is actually less effect than I expected.  I recall now that
some non-relevant MapNotify events get sent in this case [1].  These
make x_wait_for_event (f, MapNotify) return earlier than the previous
busy wait.

Should we wrap a timeout loop around the x_wait_for_event call?  Or make
the wait more selective (e.g., check that the given frame matches)?
Seems a bit like overkill considering that a timeout of longer than 1
second is unlikely to be wanted, on the other hand, we're not really
waiting for the right thing...

[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24091#57


> (3) Install the ‘select-frame-by-name’ patch on the release branch.
>
> The reason why I think that (3) is good to have despite of (1) is that
> functions would behave reasonably well on systems where the user sets
> the timeout to zero.  Thus people who, for some reason, cannot or do not
> want a larger timeout have a fallback.  Differently put: A timeout of
> zero should work well as default too.

Yes, I agree with this.





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-09-27 12:13                                 ` Noam Postavsky
@ 2017-09-29  8:33                                   ` martin rudalics
  2017-09-29 12:48                                     ` Noam Postavsky
  0 siblings, 1 reply; 30+ messages in thread
From: martin rudalics @ 2017-09-29  8:33 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: 25521, qwxlea

 > I think you might have to change window managers.

Then I'll probably prefer to rather not play around with this.

 > Hmm, that is actually less effect than I expected.  I recall now that
 > some non-relevant MapNotify events get sent in this case [1].  These
 > make x_wait_for_event (f, MapNotify) return earlier than the previous
 > busy wait.
 >
 > Should we wrap a timeout loop around the x_wait_for_event call?  Or make
 > the wait more selective (e.g., check that the given frame matches)?
 > Seems a bit like overkill considering that a timeout of longer than 1
 > second is unlikely to be wanted, on the other hand, we're not really
 > waiting for the right thing...
 >
 > [1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24091#57

Shouldn't it work to wait only for VisibilityNotify events for the given
frame?

martin





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-09-29  8:33                                   ` martin rudalics
@ 2017-09-29 12:48                                     ` Noam Postavsky
  2017-09-29 18:19                                       ` martin rudalics
  0 siblings, 1 reply; 30+ messages in thread
From: Noam Postavsky @ 2017-09-29 12:48 UTC (permalink / raw)
  To: martin rudalics; +Cc: 25521, qwxlea

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

>> Hmm, that is actually less effect than I expected.  I recall now that
>> some non-relevant MapNotify events get sent in this case [1].  These
>> make x_wait_for_event (f, MapNotify) return earlier than the previous
>> busy wait.

I should check my assumptions more carefully, the problem was actually
that I didn't set the timeout correctly; the whole seconds part was
being dropped.  Fixed with the following (full patches are attached as
well).

-  tmo = make_timespec (0, (long int) (timeout * 1000 * 1000 * 1000));
+  time_t timeout_seconds = (time_t) timeout;
+  tmo = make_timespec
+    (timeout_seconds, (long int) ((timeout - timeout_seconds)
+                                  * 1000 * 1000 * 1000));

And here are the resulting timings (the last is less than 100 because I
got bored of waiting).

    (let ((x-wait-for-event-timeout nil))
      (benchmark 1 '(make-frame-command)))"Elapsed time: 0.117144s (0.042904s in 1 GCs)"
    (let ((x-wait-for-event-timeout 0.1)) ; default
      (benchmark 1 '(make-frame-command)))"Elapsed time: 0.210824s (0.043483s in 1 GCs)"
    (let ((x-wait-for-event-timeout 100.0))
      (benchmark 1 '(make-frame-command)))"Elapsed time: 38.288529s (0.043459s in 1 GCs)"

martin rudalics <rudalics@gmx.at> writes:

> Shouldn't it work to wait only for VisibilityNotify events for the given
> frame?

Thanks for the nudge.  Waiting for VisibilityNotify works too (after
fixing the timeout bug), by the way, but it's MapNotify which has the
Lisp visibile effect.


[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 2256 bytes --]

From a700d113e4f4b63c677bbc9ea26eaefa3dd38c08 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Fri, 1 Sep 2017 09:38:55 -0400
Subject: [PATCH v4 1/3] Let select-frame-by-name choose any frame when called
 from lisp (Bug#25521)

* lisp/frame.el (select-frame-by-name): Choose from the whole list of
frames in the non-interactive part, if not found on the current
display.
---
 etc/NEWS      |  4 ++++
 lisp/frame.el | 16 ++++++++++------
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index 1b5ae658f6..4bf6701e20 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1822,6 +1822,10 @@ For details see the section "Mouse Window Auto-selection" in the Elisp
 manual.
 
 ---
+*** 'select-frame-by-name' now may return a frame on another display
+if it does not find a suitable one on the current display.
+
+---
 ** 'tcl-auto-fill-mode' is now declared obsolete.  Its functionality
 can be replicated simply by setting 'comment-auto-fill-only-comments'.
 
diff --git a/lisp/frame.el b/lisp/frame.el
index 76c1842455..a710360cdb 100644
--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -892,7 +892,8 @@ make-frame-names-alist
 
 (defvar frame-name-history nil)
 (defun select-frame-by-name (name)
-  "Select the frame on the current terminal whose name is NAME and raise it.
+  "Select the frame whose name is NAME and raise it.
+Frames on the current terminal are checked first.
 If there is no frame by that name, signal an error."
   (interactive
    (let* ((frame-names-alist (make-frame-names-alist))
@@ -903,11 +904,14 @@ select-frame-by-name
      (if (= (length input) 0)
 	 (list default)
        (list input))))
-  (let* ((frame-names-alist (make-frame-names-alist))
-	 (frame (cdr (assoc name frame-names-alist))))
-    (if frame
-	(select-frame-set-input-focus frame)
-      (error "There is no frame named `%s'" name))))
+  (select-frame-set-input-focus
+   ;; Prefer frames on the current display.
+   (or (cdr (assoc name (make-frame-names-alist)))
+       (catch 'done
+         (dolist (frame (frame-list))
+           (when (equal (frame-parameter frame 'name) name)
+             (throw 'done frame))))
+       (error "There is no frame named `%s'" name))))
 
 \f
 ;;;; Background mode.
-- 
2.11.0


[-- Attachment #3: patch --]
[-- Type: text/plain, Size: 4678 bytes --]

From 89503e0ca9eb7587c54ad5a1beca9da66447c3e4 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Wed, 30 Aug 2017 23:12:22 -0400
Subject: [PATCH v4 2/3] Bring back the busy wait after x_make_frame_visible
 (Bug#25521)

But wait specfically for a MapNotify event, and only for a
configurable amount of time.
* src/xterm.c (syms_of_xterm) [x-wait-for-event-timeout]: New
variable.
(x_wait_for_event): Use it instead of hardcoding the wait to 0.1s.
(x_make_frame_visible): Call x_wait_for_event at the end.
* etc/NEWS: Announce x_wait_for_event.
---
 etc/NEWS    |  5 +++++
 src/xterm.c | 40 ++++++++++++++++++++++++++++++++++------
 2 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index 4bf6701e20..50daa62448 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -600,6 +600,11 @@ The two new variables, 'bidi-paragraph-start-re' and
 'bidi-paragraph-separate-re', allow customization of what exactly are
 paragraphs, for the purposes of bidirectional display.
 
+---
+** New variable 'x-wait-for-event-timeout'.
+This controls how long Emacs will wait for updates to the graphical
+state to take effect (making a frame visible, for example).
+
 \f
 * Changes in Specialized Modes and Packages in Emacs 26.1
 
diff --git a/src/xterm.c b/src/xterm.c
index 0b321909c8..90275763cb 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -11029,17 +11029,22 @@ x_sync_with_move (struct frame *f, int left, int top, bool fuzzy)
 void
 x_wait_for_event (struct frame *f, int eventtype)
 {
-  int level = interrupt_input_blocked;
+  if (!FLOATP (Vx_wait_for_event_timeout))
+    return;
 
+  int level = interrupt_input_blocked;
   fd_set fds;
   struct timespec tmo, tmo_at, time_now;
   int fd = ConnectionNumber (FRAME_X_DISPLAY (f));
 
   f->wait_event_type = eventtype;
 
-  /* Set timeout to 0.1 second.  Hopefully not noticeable.
-     Maybe it should be configurable.  */
-  tmo = make_timespec (0, 100 * 1000 * 1000);
+  /* Default timeout is 0.1 second.  Hopefully not noticeable.  */
+  double timeout = XFLOAT_DATA (Vx_wait_for_event_timeout);
+  time_t timeout_seconds = (time_t) timeout;
+  tmo = make_timespec
+    (timeout_seconds, (long int) ((timeout - timeout_seconds)
+                                  * 1000 * 1000 * 1000));
   tmo_at = timespec_add (current_timespec (), tmo);
 
   while (f->wait_event_type)
@@ -11365,8 +11370,13 @@ xembed_send_message (struct frame *f, Time t, enum xembed_message msg,
 \f
 /* Change of visibility.  */
 
-/* This function sends the request to make the frame visible, but may
-   return before it the frame's visibility is changed.  */
+/* This tries to wait until the frame is really visible, depending on
+   the value of Vx_wait_for_event_timeout.
+   However, if the window manager asks the user where to position
+   the frame, this will return before the user finishes doing that.
+   The frame will not actually be visible at that time,
+   but it will become visible later when the window manager
+   finishes with it.  */
 
 void
 x_make_frame_visible (struct frame *f)
@@ -11437,11 +11447,14 @@ x_make_frame_visible (struct frame *f)
      before we do anything else.  We do this loop with input not blocked
      so that incoming events are handled.  */
   {
+    Lisp_Object frame;
     /* This must be before UNBLOCK_INPUT
        since events that arrive in response to the actions above
        will set it when they are handled.  */
     bool previously_visible = f->output_data.x->has_been_visible;
 
+    XSETFRAME (frame, f);
+
     int original_left = f->left_pos;
     int original_top = f->top_pos;
 
@@ -11488,6 +11501,10 @@ x_make_frame_visible (struct frame *f)
 
 	unblock_input ();
       }
+
+    /* Try to wait for a MapNotify event (that is what tells us when a
+       frame becomes visible).  */
+    x_wait_for_event (f, MapNotify);
   }
 }
 
@@ -13283,6 +13300,17 @@ syms_of_xterm (void)
 keysyms.  The default is nil, which is the same as `super'.  */);
   Vx_super_keysym = Qnil;
 
+  DEFVAR_LISP ("x-wait-for-event-timeout", Vx_wait_for_event_timeout,
+    doc: /* How long to wait for X events.
+
+Emacs will wait up to this many seconds to receive X events after
+making changes which affect the state of the graphical interface.
+Under some window managers this can take an indefinite amount of time,
+so it is important to limit the wait.
+
+If set to a non-float value, there will be no wait at all.  */);
+  Vx_wait_for_event_timeout = make_float (0.1);
+
   DEFVAR_LISP ("x-keysym-table", Vx_keysym_table,
     doc: /* Hash table of character codes indexed by X keysym codes.  */);
   Vx_keysym_table = make_hash_table (hashtest_eql, 900,
-- 
2.11.0


[-- Attachment #4: patch --]
[-- Type: text/plain, Size: 3633 bytes --]

From 474925d51bbb0ce1ace5e1062cd0bbe4e9f3cfc2 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Mon, 25 Sep 2017 21:58:55 -0400
Subject: [PATCH v4 3/3] Wait for frame visibility with timeout in w32term too

* src/w32term.c (syms_of_w32term) [x-wait-for-event-timeout]: New
variable.
(x_make_frame_visible): Wait for frame to become visible according to
its value.
(input_signal_count): Remove.
---
 src/w32term.c | 31 ++++++++++++++++++++-----------
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/src/w32term.c b/src/w32term.c
index d7ec40118f..0a44a8fb22 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -163,10 +163,6 @@ BOOL (WINAPI *pfnSetLayeredWindowAttributes) (HWND, COLORREF, BYTE, DWORD);
 /* Keyboard code page - may be changed by language-change events.  */
 int w32_keyboard_codepage;
 
-/* Incremented by w32_read_socket whenever it really tries to read
-   events.  */
-static int volatile input_signal_count;
-
 #ifdef CYGWIN
 int w32_message_fd = -1;
 #endif /* CYGWIN */
@@ -4658,9 +4654,6 @@ w32_read_socket (struct terminal *terminal,
 
   block_input ();
 
-  /* So people can tell when we have read the available input.  */
-  input_signal_count++;
-
   /* Process any incoming thread messages.  */
   drain_message_queue ();
 
@@ -6614,7 +6607,8 @@ w32_frame_raise_lower (struct frame *f, bool raise_flag)
 \f
 /* Change of visibility.  */
 
-/* This tries to wait until the frame is really visible.
+/* This tries to wait until the frame is really visible, depending on
+   the value of Vx_visible_frame_timeout.
    However, if the window manager asks the user where to position
    the frame, this will return before the user finishes doing that.
    The frame will not actually be visible at that time,
@@ -6673,12 +6667,16 @@ x_make_frame_visible (struct frame *f)
 		      : SW_SHOWNORMAL);
     }
 
+  if (!FLOATP (Vx_wait_for_event_timeout))
+      return;
+
   /* Synchronize to ensure Emacs knows the frame is visible
      before we do anything else.  We do this loop with input not blocked
      so that incoming events are handled.  */
   {
     Lisp_Object frame;
-    int count;
+    double timeout = XFLOAT_DATA (Vx_wait_for_event_timeout);
+    double start_time = XFLOAT_DATA (Ffloat_time (Qnil));
 
     /* This must come after we set COUNT.  */
     unblock_input ();
@@ -6688,8 +6686,8 @@ x_make_frame_visible (struct frame *f)
     /* Wait until the frame is visible.  Process X events until a
        MapNotify event has been seen, or until we think we won't get a
        MapNotify at all..  */
-    for (count = input_signal_count + 10;
-	 input_signal_count < count && !FRAME_VISIBLE_P (f);)
+    while (timeout > (XFLOAT_DATA (Ffloat_time (Qnil)) - start_time) &&
+           !FRAME_VISIBLE_P (f))
       {
 	/* Force processing of queued events.  */
         /* TODO: x_sync equivalent?  */
@@ -7321,6 +7319,17 @@ syms_of_w32term (void)
   DEFSYM (Qrenamed_from, "renamed-from");
   DEFSYM (Qrenamed_to, "renamed-to");
 
+  DEFVAR_LISP ("x-wait-for-event-timeout", Vx_wait_for_event_timeout,
+    doc: /* How long to wait for X events.
+
+Emacs will wait up to this many seconds to receive X events after
+making changes which affect the state of the graphical interface.
+Under some window managers this can take an indefinite amount of time,
+so it is important to limit the wait.
+
+If set to a non-float value, there will be no wait at all.  */);
+  Vx_wait_for_event_timeout = make_float (0.1);
+
   DEFVAR_INT ("w32-num-mouse-buttons",
 	      w32_num_mouse_buttons,
 	      doc: /* Number of physical mouse buttons.  */);
-- 
2.11.0


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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-09-27  8:11                               ` martin rudalics
  2017-09-27 12:13                                 ` Noam Postavsky
@ 2017-09-29 13:39                                 ` Eli Zaretskii
  2017-10-14  2:14                                 ` Noam Postavsky
  2 siblings, 0 replies; 30+ messages in thread
From: Eli Zaretskii @ 2017-09-29 13:39 UTC (permalink / raw)
  To: martin rudalics; +Cc: 25521, qwxlea, npostavs

> Date: Wed, 27 Sep 2017 10:11:04 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, 25521@debbugs.gnu.org, 
>  qwxlea@gmail.com
> 
> Anyway, I'd proceed as follows:
> 
> (1) Install the xterm.c and w32term.c patches on the release branch.
> 
> (2) Ask Alex to play around with the settings.  If Alex can use the
>      variable to change the behavior from bad to good and back and there
>      are no problems with other users, let's consider this part as done
>      and the bug closed.
> 
> (3) Install the ‘select-frame-by-name’ patch on the release branch.
> 
> The reason why I think that (3) is good to have despite of (1) is that
> functions would behave reasonably well on systems where the user sets
> the timeout to zero.  Thus people who, for some reason, cannot or do not
> want a larger timeout have a fallback.  Differently put: A timeout of
> zero should work well as default too.
> 
> But let's wait for Eli to make a decision.

Maybe I'm missing some downsides of these suggestions, but they sound
fine to me.  Please go ahead, and thanks.





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-09-29 12:48                                     ` Noam Postavsky
@ 2017-09-29 18:19                                       ` martin rudalics
  2017-09-29 22:47                                         ` Noam Postavsky
  0 siblings, 1 reply; 30+ messages in thread
From: martin rudalics @ 2017-09-29 18:19 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: 25521, qwxlea

 > I should check my assumptions more carefully, the problem was actually
 > that I didn't set the timeout correctly; the whole seconds part was
 > being dropped.  Fixed with the following (full patches are attached as
 > well).

Alex can you test them?  Otherwise, install on the release branch.

Many thanks, martin





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-09-29 18:19                                       ` martin rudalics
@ 2017-09-29 22:47                                         ` Noam Postavsky
  0 siblings, 0 replies; 30+ messages in thread
From: Noam Postavsky @ 2017-09-29 22:47 UTC (permalink / raw)
  To: martin rudalics; +Cc: 25521, qwxlea


martin rudalics <rudalics@gmx.at> writes:

>> I should check my assumptions more carefully, the problem was actually
>> that I didn't set the timeout correctly; the whole seconds part was
>> being dropped.  Fixed with the following (full patches are attached as
>> well).
>
> Alex can you test them?  Otherwise, install on the release branch.
>
> Many thanks, martin

I pushed the xterm.c [1: e1f6e3127a] and w32term [2: 695cf5300b] patches
to emacs-26.

[1: e1f6e3127a]: 2017-09-29 18:40:06 -0400
  Bring back the busy wait after x_make_frame_visible (Bug#25521)
  http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e1f6e3127a292e6ba66d27c49ddda4fe949569f5

[2: 695cf5300b]: 2017-09-29 18:40:06 -0400
  Wait for frame visibility with timeout in w32term too
  http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=695cf5300b4f5b0a8f3bd615b3259a99c5532b5e





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-09-27  8:11                               ` martin rudalics
  2017-09-27 12:13                                 ` Noam Postavsky
  2017-09-29 13:39                                 ` Eli Zaretskii
@ 2017-10-14  2:14                                 ` Noam Postavsky
  2017-10-14  8:36                                   ` martin rudalics
  2 siblings, 1 reply; 30+ messages in thread
From: Noam Postavsky @ 2017-10-14  2:14 UTC (permalink / raw)
  To: martin rudalics; +Cc: 25521, qwxlea

martin rudalics <rudalics@gmx.at> writes:

> (1) Install the xterm.c and w32term.c patches on the release branch.
>
> (2) Ask Alex to play around with the settings.  If Alex can use the
>     variable to change the behavior from bad to good and back and there
>     are no problems with other users, let's consider this part as done
>     and the bug closed.

Ping?  Alex can you try it out?  The patches are in the 26.0.90 pretest.





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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-10-14  2:14                                 ` Noam Postavsky
@ 2017-10-14  8:36                                   ` martin rudalics
  2017-10-15 18:22                                     ` Noam Postavsky
  0 siblings, 1 reply; 30+ messages in thread
From: martin rudalics @ 2017-10-14  8:36 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: 25521, qwxlea

 > Ping?  Alex can you try it out?  The patches are in the 26.0.90 pretest.

I think you can safely apply the ‘select-frame-by-name’ patch now.

martin






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

* bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame
  2017-10-14  8:36                                   ` martin rudalics
@ 2017-10-15 18:22                                     ` Noam Postavsky
  0 siblings, 0 replies; 30+ messages in thread
From: Noam Postavsky @ 2017-10-15 18:22 UTC (permalink / raw)
  To: martin rudalics; +Cc: 25521, qwxlea

tags 25521 fixed
close 25521
tags 25511 fixed
close 25511
quit

martin rudalics <rudalics@gmx.at> writes:

> I think you can safely apply the ‘select-frame-by-name’ patch now.

Pushed.  Closing #25511 as well, since it should have been fixed by
delay-restoring patch too.

[1: 616b4c5956]: 2017-10-15 13:58:45 -0400
  Let select-frame-by-name choose any frame when called from lisp (Bug#25521)
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=616b4c59561c63b986634d666c45a73e95fac392





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

end of thread, other threads:[~2017-10-15 18:22 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-01-24 21:05 bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame Alex 'QWxleA' Poslavsky
2017-01-24 23:35 ` npostavs
2017-01-25  3:37   ` Eli Zaretskii
2017-01-25  3:31 ` Eli Zaretskii
2017-01-25  6:47   ` Alex (QWxleA)
2017-01-25 23:43     ` npostavs
2017-01-26 11:40       ` Alex (QWxleA)
2017-01-26 14:37         ` npostavs
2017-01-26 15:48           ` Alex (QWxleA)
2017-01-27  2:02             ` npostavs
2017-01-27  7:56               ` Eli Zaretskii
2017-06-30  3:08                 ` npostavs
2017-06-30  6:09                   ` Eli Zaretskii
2017-06-30  6:52                   ` martin rudalics
2017-09-01  3:13                     ` npostavs
2017-09-01  6:56                       ` Eli Zaretskii
2017-09-01 13:02                       ` martin rudalics
2017-09-01 13:41                         ` npostavs
2017-09-01 15:45                           ` martin rudalics
2017-09-26  2:54                             ` Noam Postavsky
2017-09-27  8:11                               ` martin rudalics
2017-09-27 12:13                                 ` Noam Postavsky
2017-09-29  8:33                                   ` martin rudalics
2017-09-29 12:48                                     ` Noam Postavsky
2017-09-29 18:19                                       ` martin rudalics
2017-09-29 22:47                                         ` Noam Postavsky
2017-09-29 13:39                                 ` Eli Zaretskii
2017-10-14  2:14                                 ` Noam Postavsky
2017-10-14  8:36                                   ` martin rudalics
2017-10-15 18:22                                     ` Noam Postavsky

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).