bug#7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to the top left of the frames buffer.

bug#7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to the top left of the frames buffer.

[Arne Babenhauserheide]

If I open a file via emacsclient -c <file> in KDE/KWin it moves my
mousecursor to the top right section of the buffer of the opened frame. 

recipe: 

$ /etc/init.d/emacs.arne start # start emacs daemon
$ emacsclient -c <filename>
⇒ mouse moves.

This happens every time and disturbs my workflow a bit, because it’s
quite unexpected and gives me no advantage (I don’t use focus follows
mouse, so this also doesn’t help by being able to edit at once). 

A peculiar point about my setup is that I use grouped windows in KDE,
so the emacs frame is placed at the same place as the previous emacs
frame. It also happens when there’s no other emacs frame open, though,
so I doubt that this is the reason for moving the mouse. 



In GNU Emacs 24.0.50.1 (x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2010-10-07 on fluss
Windowing system distributor `The X.Org Foundation', version 11.0.10707000
configured using `configure  '--prefix=/usr' '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--libdir=/usr/lib64' '--program-suffix=-emacs-24' '--infodir=/usr/share/info/emacs-24' '--with-crt-dir=/usr/lib64' '--without-compress-info' '--with-sound' '--with-x' '--without-gconf' '--without-xml2' '--with-toolkit-scroll-bars' '--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff' '--with-xpm' '--without-imagemagick' '--with-xft' '--with-libotf' '--with-m17n-flt' '--with-x-toolkit=athena' '--without-hesiod' '--without-kerberos' '--without-kerberos5' '--with-gpm' '--with-dbus' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-march=amdfam10 -O2 -pipe -mtune=amdfam10' 'LDFLAGS=-Wl,-O1 -Wl,--as-needed''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: C
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8
  default enable-multibyte-characters: t

Major mode: Markdown

Minor modes in effect:
  shell-dirtrack-mode: t
  diff-auto-refine-mode: t
  real-global-auto-complete-mode: t
  global-auto-complete-mode: t
  auto-complete-mode: t
  show-paren-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-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
  line-number-mode: t
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Recent input:
u m a c h e n , SPC k a n n SPC v i e l SPC e r r e 
i c h e n <end> <right> C-x C-s C-x C-s C-x v v W e 
c <backspace> l c h e SPC W i r t s c h a f t SPC w 
i l l s t SPC d u ? C-c C-c <help-echo> <help-echo> 
<down-mouse-1> <mouse-1> C-x # C-x k <return> <backspace> 
C-x C-s C-x k C-c C-c C-x # C-x b <return> <backspace> 
C-x C-s <down> C-x r b C-g C-g C-x b C-g C-g C-x C-c 
<help-echo> C-x b C-g C-g C-x r b r e m e m <tab> <return> 
M-< C-s b ö r s e C-s C-s C-s C-g C-g <down> <tab> 
<down> <tab> C-x C-c <help-echo> <down-mouse-2> <mouse-2> 
M-< <return> <return> <up> <up> W e SPC w i n SPC i 
n SPC f r e e SPC s o f t w a r e <C-backspace> <C-backspace> 
<C-backspace> <C-backspace> <C-backspace> F r e e SPC 
s o f t w a r e SPC i s SPC w i n n i n g SPC o n SPC 
t h e SPC d e s k t o p . <backspace> <down-mouse-1> 
<mouse-movement> <mouse-1> C-c C-c <down-mouse-1> <mouse-1> 
M-x b u g <tab> <tab> <tab> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> r e p o <tab> r <tab> <return> 
s t a r t i n g SPC e m a c s c l i e n t SPC - c SPC 
m o v e s SPC t h e SPC m o u s e SPC c u r s o r M-x 
<up> <return>

Recent messages:
Use C-c C-c to remember the data.
Mark set
Saving file /home/arne/Dokumente/eigenes/Notizen/emacs-remember-mode.org...
Wrote /home/arne/Dokumente/eigenes/Notizen/emacs-remember-mode.org
Auto-saving...
When done with a buffer, type C-x #
Making completion list... [2 times]
Back to top level.
Local Ispell dictionary set to english
When done with a buffer, type C-x #

Load-path shadows:
/usr/share/emacs/site-lisp/cedet/common/ezimage hides /usr/share/emacs/24.0.50/lisp/ezimage
/usr/share/emacs/site-lisp/flim/sha1 hides /usr/share/emacs/24.0.50/lisp/sha1
/usr/share/emacs/site-lisp/flim/md4 hides /usr/share/emacs/24.0.50/lisp/md4
/usr/share/emacs/site-lisp/cedet/speedbar/sb-image hides /usr/share/emacs/24.0.50/lisp/sb-image
/usr/share/emacs/site-lisp/cedet/speedbar/dframe hides /usr/share/emacs/24.0.50/lisp/dframe
/usr/share/emacs/site-lisp/flim/hex-util hides /usr/share/emacs/24.0.50/lisp/hex-util
/usr/share/emacs/site-lisp/cedet/speedbar/speedbar hides /usr/share/emacs/24.0.50/lisp/speedbar
/usr/share/emacs/site-lisp/remember/remember hides /usr/share/emacs/24.0.50/lisp/textmodes/remember
/usr/share/emacs/site-lisp/ruby-mode/ruby-mode hides /usr/share/emacs/24.0.50/lisp/progmodes/ruby-mode
/usr/share/emacs/site-lisp/org-mode/ob-octave hides /usr/share/emacs/24.0.50/lisp/org/ob-octave
/usr/share/emacs/site-lisp/org-mode/ob-tangle hides /usr/share/emacs/24.0.50/lisp/org/ob-tangle
/usr/share/emacs/site-lisp/org-mode/org-rmail hides /usr/share/emacs/24.0.50/lisp/org/org-rmail
/usr/share/emacs/site-lisp/org-mode/org-table hides /usr/share/emacs/24.0.50/lisp/org/org-table
/usr/share/emacs/site-lisp/org-mode/org-mhe hides /usr/share/emacs/24.0.50/lisp/org/org-mhe
/usr/share/emacs/site-lisp/org-mode/ob-sass hides /usr/share/emacs/24.0.50/lisp/org/ob-sass
/usr/share/emacs/site-lisp/org-mode/org-mac-message hides /usr/share/emacs/24.0.50/lisp/org/org-mac-message
/usr/share/emacs/site-lisp/org-mode/org-src hides /usr/share/emacs/24.0.50/lisp/org/org-src
/usr/share/emacs/site-lisp/org-mode/ob-perl hides /usr/share/emacs/24.0.50/lisp/org/ob-perl
/usr/share/emacs/site-lisp/org-mode/ob-gnuplot hides /usr/share/emacs/24.0.50/lisp/org/ob-gnuplot
/usr/share/emacs/site-lisp/org-mode/org-footnote hides /usr/share/emacs/24.0.50/lisp/org/org-footnote
/usr/share/emacs/site-lisp/org-mode/org-html hides /usr/share/emacs/24.0.50/lisp/org/org-html
/usr/share/emacs/site-lisp/org-mode/org-install hides /usr/share/emacs/24.0.50/lisp/org/org-install
/usr/share/emacs/site-lisp/org-mode/org-compat hides /usr/share/emacs/24.0.50/lisp/org/org-compat
/usr/share/emacs/site-lisp/org-mode/org-bibtex hides /usr/share/emacs/24.0.50/lisp/org/org-bibtex
/usr/share/emacs/site-lisp/org-mode/org-bbdb hides /usr/share/emacs/24.0.50/lisp/org/org-bbdb
/usr/share/emacs/site-lisp/org-mode/org-w3m hides /usr/share/emacs/24.0.50/lisp/org/org-w3m
/usr/share/emacs/site-lisp/org-mode/ob-screen hides /usr/share/emacs/24.0.50/lisp/org/ob-screen
/usr/share/emacs/site-lisp/org-mode/ob-mscgen hides /usr/share/emacs/24.0.50/lisp/org/ob-mscgen
/usr/share/emacs/site-lisp/org-mode/ob-table hides /usr/share/emacs/24.0.50/lisp/org/ob-table
/usr/share/emacs/site-lisp/org-mode/org-info hides /usr/share/emacs/24.0.50/lisp/org/org-info
/usr/share/emacs/site-lisp/org-mode/org-irc hides /usr/share/emacs/24.0.50/lisp/org/org-irc
/usr/share/emacs/site-lisp/org-mode/org-ctags hides /usr/share/emacs/24.0.50/lisp/org/org-ctags
/usr/share/emacs/site-lisp/org-mode/ob-ruby hides /usr/share/emacs/24.0.50/lisp/org/ob-ruby
/usr/share/emacs/site-lisp/org-mode/org-mks hides /usr/share/emacs/24.0.50/lisp/org/org-mks
/usr/share/emacs/site-lisp/org-mode/ob-sqlite hides /usr/share/emacs/24.0.50/lisp/org/ob-sqlite
/usr/share/emacs/site-lisp/org-mode/ob-ocaml hides /usr/share/emacs/24.0.50/lisp/org/ob-ocaml
/usr/share/emacs/site-lisp/org-mode/org-mew hides /usr/share/emacs/24.0.50/lisp/org/org-mew
/usr/share/emacs/site-lisp/org-mode/org-crypt hides /usr/share/emacs/24.0.50/lisp/org/org-crypt
/usr/share/emacs/site-lisp/org-mode/org-wl hides /usr/share/emacs/24.0.50/lisp/org/org-wl
/usr/share/emacs/site-lisp/org-mode/org-jsinfo hides /usr/share/emacs/24.0.50/lisp/org/org-jsinfo
/usr/share/emacs/site-lisp/org-mode/org-inlinetask hides /usr/share/emacs/24.0.50/lisp/org/org-inlinetask
/usr/share/emacs/site-lisp/org-mode/org-attach hides /usr/share/emacs/24.0.50/lisp/org/org-attach
/usr/share/emacs/site-lisp/org-mode/ob-ditaa hides /usr/share/emacs/24.0.50/lisp/org/ob-ditaa
/usr/share/emacs/site-lisp/org-mode/ob-dot hides /usr/share/emacs/24.0.50/lisp/org/ob-dot
/usr/share/emacs/site-lisp/org-mode/ob-lob hides /usr/share/emacs/24.0.50/lisp/org/ob-lob
/usr/share/emacs/site-lisp/org-mode/ob-comint hides /usr/share/emacs/24.0.50/lisp/org/ob-comint
/usr/share/emacs/site-lisp/org-mode/ob-python hides /usr/share/emacs/24.0.50/lisp/org/ob-python
/usr/share/emacs/site-lisp/org-mode/org-feed hides /usr/share/emacs/24.0.50/lisp/org/org-feed
/usr/share/emacs/site-lisp/org-mode/org hides /usr/share/emacs/24.0.50/lisp/org/org
/usr/share/emacs/site-lisp/org-mode/org-entities hides /usr/share/emacs/24.0.50/lisp/org/org-entities
/usr/share/emacs/site-lisp/org-mode/org-latex hides /usr/share/emacs/24.0.50/lisp/org/org-latex
/usr/share/emacs/site-lisp/org-mode/org-xoxo hides /usr/share/emacs/24.0.50/lisp/org/org-xoxo
/usr/share/emacs/site-lisp/org-mode/ob-C hides /usr/share/emacs/24.0.50/lisp/org/ob-C
/usr/share/emacs/site-lisp/org-mode/org-exp hides /usr/share/emacs/24.0.50/lisp/org/org-exp
/usr/share/emacs/site-lisp/org-mode/ob hides /usr/share/emacs/24.0.50/lisp/org/ob
/usr/share/emacs/site-lisp/org-mode/org-exp-blocks hides /usr/share/emacs/24.0.50/lisp/org/org-exp-blocks
/usr/share/emacs/site-lisp/org-mode/ob-R hides /usr/share/emacs/24.0.50/lisp/org/ob-R
/usr/share/emacs/site-lisp/org-mode/org-gnus hides /usr/share/emacs/24.0.50/lisp/org/org-gnus
/usr/share/emacs/site-lisp/org-mode/ob-asymptote hides /usr/share/emacs/24.0.50/lisp/org/ob-asymptote
/usr/share/emacs/site-lisp/org-mode/org-publish hides /usr/share/emacs/24.0.50/lisp/org/org-publish
/usr/share/emacs/site-lisp/org-mode/ob-haskell hides /usr/share/emacs/24.0.50/lisp/org/ob-haskell
/usr/share/emacs/site-lisp/org-mode/org-vm hides /usr/share/emacs/24.0.50/lisp/org/org-vm
/usr/share/emacs/site-lisp/org-mode/ob-latex hides /usr/share/emacs/24.0.50/lisp/org/ob-latex
/usr/share/emacs/site-lisp/org-mode/org-clock hides /usr/share/emacs/24.0.50/lisp/org/org-clock
/usr/share/emacs/site-lisp/org-mode/ob-exp hides /usr/share/emacs/24.0.50/lisp/org/ob-exp
/usr/share/emacs/site-lisp/org-mode/ob-matlab hides /usr/share/emacs/24.0.50/lisp/org/ob-matlab
/usr/share/emacs/site-lisp/org-mode/org-colview hides /usr/share/emacs/24.0.50/lisp/org/org-colview
/usr/share/emacs/site-lisp/org-mode/ob-css hides /usr/share/emacs/24.0.50/lisp/org/ob-css
/usr/share/emacs/site-lisp/org-mode/org-remember hides /usr/share/emacs/24.0.50/lisp/org/org-remember
/usr/share/emacs/site-lisp/org-mode/org-docbook hides /usr/share/emacs/24.0.50/lisp/org/org-docbook
/usr/share/emacs/site-lisp/org-mode/org-archive hides /usr/share/emacs/24.0.50/lisp/org/org-archive
/usr/share/emacs/site-lisp/org-mode/org-habit hides /usr/share/emacs/24.0.50/lisp/org/org-habit
/usr/share/emacs/site-lisp/org-mode/ob-sh hides /usr/share/emacs/24.0.50/lisp/org/ob-sh
/usr/share/emacs/site-lisp/org-mode/org-plot hides /usr/share/emacs/24.0.50/lisp/org/org-plot
/usr/share/emacs/site-lisp/org-mode/org-icalendar hides /usr/share/emacs/24.0.50/lisp/org/org-icalendar
/usr/share/emacs/site-lisp/org-mode/org-taskjuggler hides /usr/share/emacs/24.0.50/lisp/org/org-taskjuggler
/usr/share/emacs/site-lisp/org-mode/ob-clojure hides /usr/share/emacs/24.0.50/lisp/org/ob-clojure
/usr/share/emacs/site-lisp/org-mode/org-capture hides /usr/share/emacs/24.0.50/lisp/org/org-capture
/usr/share/emacs/site-lisp/org-mode/org-timer hides /usr/share/emacs/24.0.50/lisp/org/org-timer
/usr/share/emacs/site-lisp/org-mode/ob-sql hides /usr/share/emacs/24.0.50/lisp/org/ob-sql
/usr/share/emacs/site-lisp/org-mode/org-protocol hides /usr/share/emacs/24.0.50/lisp/org/org-protocol
/usr/share/emacs/site-lisp/org-mode/org-mobile hides /usr/share/emacs/24.0.50/lisp/org/org-mobile
/usr/share/emacs/site-lisp/org-mode/org-indent hides /usr/share/emacs/24.0.50/lisp/org/org-indent
/usr/share/emacs/site-lisp/org-mode/org-mouse hides /usr/share/emacs/24.0.50/lisp/org/org-mouse
/usr/share/emacs/site-lisp/org-mode/org-datetree hides /usr/share/emacs/24.0.50/lisp/org/org-datetree
/usr/share/emacs/site-lisp/org-mode/ob-eval hides /usr/share/emacs/24.0.50/lisp/org/ob-eval
/usr/share/emacs/site-lisp/org-mode/org-id hides /usr/share/emacs/24.0.50/lisp/org/org-id
/usr/share/emacs/site-lisp/org-mode/ob-keys hides /usr/share/emacs/24.0.50/lisp/org/ob-keys
/usr/share/emacs/site-lisp/org-mode/org-freemind hides /usr/share/emacs/24.0.50/lisp/org/org-freemind
/usr/share/emacs/site-lisp/org-mode/ob-ref hides /usr/share/emacs/24.0.50/lisp/org/ob-ref
/usr/share/emacs/site-lisp/org-mode/org-macs hides /usr/share/emacs/24.0.50/lisp/org/org-macs
/usr/share/emacs/site-lisp/org-mode/org-list hides /usr/share/emacs/24.0.50/lisp/org/org-list
/usr/share/emacs/site-lisp/org-mode/org-faces hides /usr/share/emacs/24.0.50/lisp/org/org-faces
/usr/share/emacs/site-lisp/org-mode/org-docview hides /usr/share/emacs/24.0.50/lisp/org/org-docview
/usr/share/emacs/site-lisp/org-mode/org-agenda hides /usr/share/emacs/24.0.50/lisp/org/org-agenda
/usr/share/emacs/site-lisp/org-mode/ob-emacs-lisp hides /usr/share/emacs/24.0.50/lisp/org/ob-emacs-lisp
/usr/share/emacs/site-lisp/org-mode/org-ascii hides /usr/share/emacs/24.0.50/lisp/org/org-ascii
/usr/share/emacs/site-lisp/org-mode/org-beamer hides /usr/share/emacs/24.0.50/lisp/org/org-beamer
/usr/share/emacs/site-lisp/nxml-mode/rng-valid hides /usr/share/emacs/24.0.50/lisp/nxml/rng-valid
/usr/share/emacs/site-lisp/nxml-mode/rng-xsd hides /usr/share/emacs/24.0.50/lisp/nxml/rng-xsd
/usr/share/emacs/site-lisp/nxml-mode/rng-nxml hides /usr/share/emacs/24.0.50/lisp/nxml/rng-nxml
/usr/share/emacs/site-lisp/nxml-mode/rng-parse hides /usr/share/emacs/24.0.50/lisp/nxml/rng-parse
/usr/share/emacs/site-lisp/nxml-mode/rng-match hides /usr/share/emacs/24.0.50/lisp/nxml/rng-match
/usr/share/emacs/site-lisp/nxml-mode/xsd-regexp hides /usr/share/emacs/24.0.50/lisp/nxml/xsd-regexp
/usr/share/emacs/site-lisp/nxml-mode/rng-cmpct hides /usr/share/emacs/24.0.50/lisp/nxml/rng-cmpct
/usr/share/emacs/site-lisp/nxml-mode/rng-maint hides /usr/share/emacs/24.0.50/lisp/nxml/rng-maint
/usr/share/emacs/site-lisp/nxml-mode/nxml-uchnm hides /usr/share/emacs/24.0.50/lisp/nxml/nxml-uchnm
/usr/share/emacs/site-lisp/nxml-mode/nxml-maint hides /usr/share/emacs/24.0.50/lisp/nxml/nxml-maint
/usr/share/emacs/site-lisp/nxml-mode/nxml-rap hides /usr/share/emacs/24.0.50/lisp/nxml/nxml-rap
/usr/share/emacs/site-lisp/nxml-mode/rng-loc hides /usr/share/emacs/24.0.50/lisp/nxml/rng-loc
/usr/share/emacs/site-lisp/nxml-mode/rng-util hides /usr/share/emacs/24.0.50/lisp/nxml/rng-util
/usr/share/emacs/site-lisp/nxml-mode/nxml-util hides /usr/share/emacs/24.0.50/lisp/nxml/nxml-util
/usr/share/emacs/site-lisp/nxml-mode/nxml-glyph hides /usr/share/emacs/24.0.50/lisp/nxml/nxml-glyph
/usr/share/emacs/site-lisp/nxml-mode/rng-pttrn hides /usr/share/emacs/24.0.50/lisp/nxml/rng-pttrn
/usr/share/emacs/site-lisp/nxml-mode/nxml-enc hides /usr/share/emacs/24.0.50/lisp/nxml/nxml-enc
/usr/share/emacs/site-lisp/nxml-mode/nxml-ns hides /usr/share/emacs/24.0.50/lisp/nxml/nxml-ns
/usr/share/emacs/site-lisp/nxml-mode/nxml-parse hides /usr/share/emacs/24.0.50/lisp/nxml/nxml-parse
/usr/share/emacs/site-lisp/nxml-mode/xmltok hides /usr/share/emacs/24.0.50/lisp/nxml/xmltok
/usr/share/emacs/site-lisp/nxml-mode/rng-dt hides /usr/share/emacs/24.0.50/lisp/nxml/rng-dt
/usr/share/emacs/site-lisp/nxml-mode/nxml-outln hides /usr/share/emacs/24.0.50/lisp/nxml/nxml-outln
/usr/share/emacs/site-lisp/nxml-mode/rng-uri hides /usr/share/emacs/24.0.50/lisp/nxml/rng-uri
/usr/share/emacs/site-lisp/nxml-mode/nxml-mode hides /usr/share/emacs/24.0.50/lisp/nxml/nxml-mode
/usr/share/emacs/site-lisp/flim/hmac-md5 hides /usr/share/emacs/24.0.50/lisp/net/hmac-md5
/usr/share/emacs/site-lisp/flim/ntlm hides /usr/share/emacs/24.0.50/lisp/net/ntlm
/usr/share/emacs/site-lisp/flim/sasl-digest hides /usr/share/emacs/24.0.50/lisp/net/sasl-digest
/usr/share/emacs/site-lisp/flim/sasl-cram hides /usr/share/emacs/24.0.50/lisp/net/sasl-cram
/usr/share/emacs/site-lisp/flim/hmac-def hides /usr/share/emacs/24.0.50/lisp/net/hmac-def
/usr/share/emacs/site-lisp/flim/sasl-ntlm hides /usr/share/emacs/24.0.50/lisp/net/sasl-ntlm
/usr/share/emacs/site-lisp/flim/sasl hides /usr/share/emacs/24.0.50/lisp/net/sasl
~/.emacs.d/private/gnus hides /usr/share/emacs/24.0.50/lisp/gnus/gnus
/usr/share/emacs/site-lisp/cedet/eieio/chart hides /usr/share/emacs/24.0.50/lisp/emacs-lisp/chart
/usr/share/emacs/site-lisp/cedet/eieio/eieio-custom hides /usr/share/emacs/24.0.50/lisp/emacs-lisp/eieio-custom
/usr/share/emacs/site-lisp/cedet/eieio/eieio-speedbar hides /usr/share/emacs/24.0.50/lisp/emacs-lisp/eieio-speedbar
/usr/share/emacs/site-lisp/cedet/eieio/eieio hides /usr/share/emacs/24.0.50/lisp/emacs-lisp/eieio
/usr/share/emacs/site-lisp/cedet/eieio/eieio-base hides /usr/share/emacs/24.0.50/lisp/emacs-lisp/eieio-base
/usr/share/emacs/site-lisp/cedet/eieio/eieio-comp hides /usr/share/emacs/24.0.50/lisp/emacs-lisp/eieio-comp
/usr/share/emacs/site-lisp/cedet/eieio/eieio-datadebug hides /usr/share/emacs/24.0.50/lisp/emacs-lisp/eieio-datadebug
/usr/share/emacs/site-lisp/cedet/eieio/eieio-opt hides /usr/share/emacs/24.0.50/lisp/emacs-lisp/eieio-opt
/usr/share/emacs/site-lisp/cedet/common/cedet-files hides /usr/share/emacs/24.0.50/lisp/cedet/cedet-files
/usr/share/emacs/site-lisp/cedet/common/mode-local hides /usr/share/emacs/24.0.50/lisp/cedet/mode-local
/usr/share/emacs/site-lisp/cedet/ede/ede hides /usr/share/emacs/24.0.50/lisp/cedet/ede
/usr/share/emacs/site-lisp/cedet/semantic/semantic hides /usr/share/emacs/24.0.50/lisp/cedet/semantic
/usr/share/emacs/site-lisp/cedet/srecode/srecode hides /usr/share/emacs/24.0.50/lisp/cedet/srecode
/usr/share/emacs/site-lisp/cedet/common/pulse hides /usr/share/emacs/24.0.50/lisp/cedet/pulse
/usr/share/emacs/site-lisp/cedet/common/cedet hides /usr/share/emacs/24.0.50/lisp/cedet/cedet
/usr/share/emacs/site-lisp/cedet/common/inversion hides /usr/share/emacs/24.0.50/lisp/cedet/inversion
/usr/share/emacs/site-lisp/cedet/common/data-debug hides /usr/share/emacs/24.0.50/lisp/cedet/data-debug
/usr/share/emacs/site-lisp/cedet/common/cedet-idutils hides /usr/share/emacs/24.0.50/lisp/cedet/cedet-idutils
/usr/share/emacs/site-lisp/cedet/common/cedet-cscope hides /usr/share/emacs/24.0.50/lisp/cedet/cedet-cscope
/usr/share/emacs/site-lisp/cedet/common/cedet-global hides /usr/share/emacs/24.0.50/lisp/cedet/cedet-global

Features:
(shadow sort mail-extr message idna rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mailabbrev gmm-utils mailheader emacsbug org-archive
org-wl org-w3m org-vm org-rmail org-mhe org-mew org-irc org-jsinfo
org-infojs org-html org-exp ob-exp org-exp-blocks org-agenda org-info
org-gnus org-docview org-bibtex org-bbdb bookmark pp mail-utils novice
hanoi repeat newcomment skeleton sh-script semantic-html sgml-mode
css-mode tabify rect life tramp tramp-compat password-cache format-spec
tramp-loaddefs vc-git vc-bzr sha1 sha1-el hex-util vc-sccs vc-svn vc-cvs
vc-rcs semantic-imenu semantic-sb pymacs wisent-python wisent-python-wy
semantic-wisent wisent imenu ipython executable shell python-mode
info-look sb-info info ansi-color compile eieio-opt help-mode view
multi-isearch log-edit pcvs-util add-log diff-mode yasnippet
semantic-edit semantic-c semantic-gcc semantic-dep semanticdb-mode
semantic-decorate-include semanticdb-find semanticdb-ref
semantic-decorate-mode semantic-decorate pulse hideif semantic-c-by
semantic-lex-spp tempo xml-parse doxymacs cc-mode cc-fonts cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs thingatpt vc-hg
markdown-mode server semantic-el semantic-bovine bovine-debug
semantic-debug ispell finder-inf package activate-babenv
activate-private-data private-basic activate-identica identica-mode json
url-http tls url-auth mail-parse rfc2231 rfc2047 rfc2045 ietf-drums
url-gw url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-util url-parse auth-source netrc gnus-util url-vars
mm-util mail-prsvr mailcap longlines parse-time xml epa-file epa epg
epg-config activate-german-spelling activate-auto-complete
auto-complete-config auto-complete edmacro kmacro popup
activate-markdown htmlize type-break goto-chg activate-quick-note
remember org-remember org-datetree org ob-emacs-lisp ob-keys ob-comint
comint ring ob-tangle ob-ref ob-lob ob-table ob org-footnote org-src
org-list org-faces org-compat org-entities org-macs time-date noutline
outline easy-mmode cal-menu calendar cal-loaddefs allout ido
activate-base jka-compr saveplace paren cus-start cus-load site-gentoo
planner-autoloads slime-autoloads w3m-load org-install nxml-enc
muse-autoloads mmm-auto mmm-vars mmm-compat gdiff-setup vc vc-dispatcher
circe-auto cedet cedet-contrib-load contrib-loaddefs cogre-load
cogre-loaddefs speedbar-load speedbar-loaddefs ede-load ede-loaddefs
ede-speedbar ede-files ede ede-base ede-auto eieio-speedbar
semantic-ia-sb semantic-analyze semantic-scope semantic-analyze-fcn
semantic-sort semanticdb-el semanticdb semantic-ctxt semantic-format
semantic-util-modes semantic-util semantic semantic-lex semantic-tag
working fame speedbar sb-image ezimage dframe easymenu assoc
eieio-custom wid-edit ede-source eieio-base srecode-load srecode
srecode-loaddefs semantic-load semantic-fw semantic-loaddefs mode-local
find-func derived eieio-load eieio-loaddefs cedet-load cedet-compat
cedet-loaddefs eieio warnings advice help-fns advice-preload byte-opt
bytecomp byte-compile cl inversion bbdb-autoloads bbdb regexp-opt
timezone tex-site auto-loads tooltip ediff-hook vc-hooks lisp-float-type
mwheel x-win x-dnd tool-bar dnd fontset image fringe lisp-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button
minibuffer faces cus-face files text-properties overlay md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind dynamic-setting
font-render-setting x-toolkit x multi-tty emacs)

bug#7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to the top left of the frames buffer.

[Anders Kaseorg]

A workaround is M-x customize-save-variable focus-follows-mouse n.

It’s probably time to flip the default, since even on X these days there 
are only a small minority of focus-follows-mouse users.

Anders

bug#7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to the top left of the frames buffer.

[Stefan Monnier]

> A workaround is M-x customize-save-variable focus-follows-mouse n.
> It’s probably time to flip the default, since even on X these days there 
> are only a small minority of focus-follows-mouse users.

Even tho I love focus follows mouse, I'd tend to agree: not only it
seems we're in the minority, but the nil value is a safer default since
moving the mouse is something that should usually be avoided.


        Stefan

bug#7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to the top left of the frames buffer.

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> A workaround is M-x customize-save-variable focus-follows-mouse n.
>> It’s probably time to flip the default, since even on X these days there 
>> are only a small minority of focus-follows-mouse users.
>
> Even tho I love focus follows mouse, I'd tend to agree: not only it
> seems we're in the minority, but the nil value is a safer default since
> moving the mouse is something that should usually be avoided.

Nowadays focus follows mouse doesn't mean that the focus strictly
follows the mouse position, it can still be set independent of it.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#7269: bug #7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to, the top left of the frames buffer.

[Alain Knaff]

> Nowadays focus follows mouse doesn't mean that the focus strictly
> follows the mouse position, it can still be set independent of it.

Even that (ignoring mouse position, and just grabbing focus) would be a
highly antisocial move. Why can't emacs just leave the mouse and the
focus alone, like most other apps do, and patiently wait until the user
gives it focus? It's not as if emacs is the only app that opens new
windows...

Focus grabbing is dangerous, may cause privacy issues (if emacs happens
to grab focus from another app where user is entering a password), may
cause data loss (if user happens to type in a character sequence in
another app which for emacs means "delete this file"... don't laugh,
I've lost a couple of photos due to such an issue in digikam), and is an
annoyance, in general.

One acceptable behavior would be to pop up the new window _near_ (but
not under!) the mouse pointer, so that the user doesn't have to move the
mouse too much to give it focus. Yes, make the window appear near mouse,
rather than the other way round.

Thanks,

Alain

bug#7269: bug #7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to, the top left of the frames buffer.

[Lennart Borgman]

On Sat, Nov 13, 2010 at 9:13 PM, Alain Knaff <alain@knaff.lu> wrote:
>> Nowadays focus follows mouse doesn't mean that the focus strictly
>> follows the mouse position, it can still be set independent of it.
>
> Even that (ignoring mouse position, and just grabbing focus) would be a
> highly antisocial move. Why can't emacs just leave the mouse and the
> focus alone, like most other apps do, and patiently wait until the user
> gives it focus?

Of course Emacs should grab focus if the user uses emacsclient to open
a file. Why should not Emacs grab the focus then? AFAICS this is what
the user expects.

bug#7269: bug #7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to, the top left of the frames buffer.

[Alain Knaff]

On 11/13/2010 10:11 PM, Lennart Borgman wrote:
> You answered privately, was that your intention?

No, not really, I accidentally did a "reply" instead of a "reply-all".
Thanks for bringing this to my attention, I re-added the bug report in
Cc: now. Hopefully this will work...

> 
> What application do you mean do not grab focus when you ask them to
> open a file? I actually can't remember any. (Except for GIMP which
> seems to have a bug there on w32.)

Why would an application behave differently if I want them to open a
file, than if I just want to create a new document?

Well, in any case, I've never seen any application do this even when
opening a file.

I tried it with openoffice and inkscape right now, and neither of them
did this.

Neither did firefox (when trying to add the URL on the commandline), nor
konqueror.
(thunderbird/firefox steal focus when popping up certain alerts, but not
on open)

Can you name me just one application which steals focus when you launch
it with a file name parameter?

N.B. during my test sometimes the app just happened to pop up its window
under my mouse, so it got focus the "natural" way. However, this choice
of location was by no way deliberate, and didn't happen when retrying it
with a different window disposition.

Alain


> 
> 
> On Sat, Nov 13, 2010 at 10:04 PM, Alain Knaff <alain@knaff.lu> wrote:
>> On 11/13/2010 09:58 PM, Lennart Borgman wrote:
>>> On Sat, Nov 13, 2010 at 9:13 PM, Alain Knaff <alain@knaff.lu> wrote:
>>>>> Nowadays focus follows mouse doesn't mean that the focus strictly
>>>>> follows the mouse position, it can still be set independent of it.
>>>>
>>>> Even that (ignoring mouse position, and just grabbing focus) would be a
>>>> highly antisocial move. Why can't emacs just leave the mouse and the
>>>> focus alone, like most other apps do, and patiently wait until the user
>>>> gives it focus?
>>>
>>> Of course Emacs should grab focus if the user uses emacsclient to open
>>> a file. Why should not Emacs grab the focus then? AFAICS this is what
>>> the user expects.
>>
>> Did you ever wonder why all the other applications (except thunderbird
>> and firefox in some cases) didn't behave in this way?
>>
>> I'll give you the answer: because most users do NOT expect such rude
>> behavior. We do not want application to steal focus from us, we want
>> them to patiently wait for their turn. Almost all the other apps behave,
>> why can't emacs?
>>
>> Alain
>>

bug#7269: bug #7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to, the top left of the frames buffer.

[Lennart Borgman]

On Sat, Nov 13, 2010 at 10:25 PM, Alain Knaff <alain@knaff.lu> wrote:
> On 11/13/2010 10:11 PM, Lennart Borgman wrote:
>> You answered privately, was that your intention?
>
> No, not really, I accidentally did a "reply" instead of a "reply-all".
> Thanks for bringing this to my attention, I re-added the bug report in
> Cc: now. Hopefully this will work...
>
>>
>> What application do you mean do not grab focus when you ask them to
>> open a file? I actually can't remember any. (Except for GIMP which
>> seems to have a bug there on w32.)
>
> Why would an application behave differently if I want them to open a
> file, than if I just want to create a new document?
>
> Well, in any case, I've never seen any application do this even when
> opening a file.
>
> I tried it with openoffice and inkscape right now, and neither of them
> did this.
>
> Neither did firefox (when trying to add the URL on the commandline), nor
> konqueror.
> (thunderbird/firefox steal focus when popping up certain alerts, but not
> on open)
>
> Can you name me just one application which steals focus when you launch
> it with a file name parameter?


As I said I know of no exception on w32. All applications I can think
of right now grabs focus when you call them from the command line (or
from Windows Explorer).

Maybe this is dependent on the window manager used?

What happens if you launch a program from the command line without a
file name argument? Does the application get focus? (On w32 they do
get focus.)

bug#7269: bug #7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to, the top left of the frames buffer.

[Lennart Borgman]

>>> What application do you mean do not grab focus when you ask them to
>>> open a file? I actually can't remember any. (Except for GIMP which
>>> seems to have a bug there on w32.)

Hm, this was a bit interesting regarding GIMP on w32. I have long
wondered why they do not fix the bug that it does not grab focus and
that it is also very hard to give it focus on w32. Apparently there
must be some misunderstanding in the use of the w32 API for focusing.
And it might be the GTK part that has a bug there. Anyone knows where
to file a bug about this?

bug#7269: bug #7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to, the top left of the frames buffer.

[Alain Knaff]

On 11/13/2010 10:31 PM, Lennart Borgman wrote:
[...]
> As I said I know of no exception on w32. All applications I can think
> of right now grabs focus when you call them from the command line (or
> from Windows Explorer).

Ok, but if I really liked this braindead behavior, I'd actually use
Windows, rather than Linux. And I'd probably use Notepad too rather than
Emacs :-)

So why exactly is Emacs trying to force Windows down everybody's throat?
Emacs, of all software! The flagship of the GNU movement! The mind
boggles...

Maybe, in emacs this behavior could be made conditional on running on
Windows?

> 
> Maybe this is dependent on the window manager used?

I use KDE.

I don't believe this is a window manager issue... if that was the case,
wouldn't all applications behave the same way?

> 
> What happens if you launch a program from the command line without a
> file name argument? Does the application get focus?

No, of course not.

Unless it just happens to pop up in front of the mouse.

And this has been the case with other Window managers as well, even
before KDE. Even in mwm, twm, fvwm, applications didn't steal focus
willy-nilly. I don't know for sure about Gnome, I don't use Gnome very
often, but I guess I would have noticed if this was the case...

> (On w32 they do
> get focus.)

... and that's one of the zillion reasons why I don't use w32... :-)

Alain

bug#7269: bug #7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to, the top left of the frames buffer.

[Alain Knaff]

On 11/13/2010 10:39 PM, Lennart Borgman wrote:
>>>> What application do you mean do not grab focus when you ask them to
>>>> open a file? I actually can't remember any. (Except for GIMP which
>>>> seems to have a bug there on w32.)
> 
> Hm, this was a bit interesting regarding GIMP on w32. I have long
> wondered why they do not fix the bug that it does not grab focus and
> that it is also very hard to give it focus on w32. Apparently there
> must be some misunderstanding in the use of the w32 API for focusing.
> And it might be the GTK part that has a bug there. Anyone knows where
> to file a bug about this?

According to http://www.gtk.org/development.html, you can report GTK
bugs at http://bugzilla.gnome.org/

Regards,

Alain

bug#7269: bug #7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to, the top left of the frames buffer.

[Lennart Borgman]

On Sat, Nov 13, 2010 at 10:42 PM, Alain Knaff <alain@knaff.lu> wrote:
> On 11/13/2010 10:39 PM, Lennart Borgman wrote:
>>>>> What application do you mean do not grab focus when you ask them to
>>>>> open a file? I actually can't remember any. (Except for GIMP which
>>>>> seems to have a bug there on w32.)
>>
>> Hm, this was a bit interesting regarding GIMP on w32. I have long
>> wondered why they do not fix the bug that it does not grab focus and
>> that it is also very hard to give it focus on w32. Apparently there
>> must be some misunderstanding in the use of the w32 API for focusing.
>> And it might be the GTK part that has a bug there. Anyone knows where
>> to file a bug about this?
>
> According to http://www.gtk.org/development.html, you can report GTK
> bugs at http://bugzilla.gnome.org/

Thanks. I see they have a lot of bug reports regarding focus on w32 so
I guess there is no use in adding my example too. (Some of them are
very strange, but I think I have seen those with GIMP.)

bug#7269: bug #7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to, the top left of the frames buffer.

[Lennart Borgman]

On Sat, Nov 13, 2010 at 10:40 PM, Alain Knaff <alain@knaff.lu> wrote:
> On 11/13/2010 10:31 PM, Lennart Borgman wrote:
> [...]
>> As I said I know of no exception on w32. All applications I can think
>> of right now grabs focus when you call them from the command line (or
>> from Windows Explorer).
>
> Ok, but if I really liked this braindead behavior, I'd actually use
> Windows, rather than Linux. And I'd probably use Notepad too rather than
> Emacs :-)

Why is it good that the newly started program does not get focus?

> Maybe, in emacs this behavior could be made conditional on running on
> Windows?

Yes. Or the window manager if that is better (and possible).

>> Maybe this is dependent on the window manager used?
>
> I use KDE.
>
> I don't believe this is a window manager issue... if that was the case,
> wouldn't all applications behave the same way?

No. There are some extra difficulties since Emacs uses a server which
emacsclients connects to.

>> What happens if you launch a program from the command line without a
>> file name argument? Does the application get focus?
>
> No, of course not.

Thanks.

> And this has been the case with other Window managers as well, even
> before KDE. Even in mwm, twm, fvwm, applications didn't steal focus
> willy-nilly. I don't know for sure about Gnome, I don't use Gnome very
> often, but I guess I would have noticed if this was the case...

bug#7269: bug #7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to, the top left of the frames buffer.

[Alain Knaff]

On 11/13/2010 10:52 PM, Lennart Borgman wrote:
> On Sat, Nov 13, 2010 at 10:40 PM, Alain Knaff <alain@knaff.lu> wrote:
>> On 11/13/2010 10:31 PM, Lennart Borgman wrote:
>> [...]
>>> As I said I know of no exception on w32. All applications I can think
>>> of right now grabs focus when you call them from the command line (or
>>> from Windows Explorer).
>>
>> Ok, but if I really liked this braindead behavior, I'd actually use
>> Windows, rather than Linux. And I'd probably use Notepad too rather than
>> Emacs :-)
> 
> Why is it good that the newly started program does not get focus?

In order not to disrupt the user's work in some other program.
Multitasking may be a foreign concept on Windows, but on Linux, people
routinely have multiple programs open. They may launch a compilation in
one window, and then, while it runs,  launch a firefox for their online
banking. They would be rather unhappy if suddenly their online banking
password would show up readable for all shoulder surfers in the
emacsclient spawned by cvs commit.

Please don't break multitasking, it is one of the many features that we
love about Linux.

> 
>> Maybe, in emacs this behavior could be made conditional on running on
>> Windows?
> 
> Yes. Or the window manager if that is better (and possible).

Only emacs (and firefox/thunderbird in other scenarios) do this. So I
think, the problem is with them, not the window manager.

However, it could be argued that the window manager should do a better
job at policing applications. I've indeed entered such a bug report on
KDE a while back (for the situation caused by firefox/thunderbird), and
their answer was that some elements may have a legitimate need to grab
focus or switch desktops. These elements would be for example the window
manager's own widgets for switching desktops.

However, KDE does have a way of optionally reigning in some of the
methods of stealing focus, this is called "Focus stealing prevention",
and can be found in
systemSettings->WindowBehavior->WindowRules->New->Workarounds

But apparently, there is more than one method to grab focus, and some
aren't blocked by this (... or are only blocked at a price... such as
new windows popping up behind all others rather than in front)

>>> Maybe this is dependent on the window manager used?
>>
>> I use KDE.
>>
>> I don't believe this is a window manager issue... if that was the case,
>> wouldn't all applications behave the same way?
> 
> No. There are some extra difficulties since Emacs uses a server which
> emacsclients connects to.

I've noticed some weirdness there too. Normally, the idea of emacsclient
should be to display the client on the DISPLAY pointed to by the client,
not by the server. Indeed, if I'm logged in over ssh to a remote server,
and start an emacsclient, I want to see that emacsclient on my display,
and not have it displayed on the server's console in some dusty NOC
where it is of use to no-one. Same thing with virtual desktops: I want
to see the emacsclient on the desktop that I am currently on, and not on
the one where emacs' main window is (or worse, have me forcefully
teleported to that desktop).

This was working fine in the old days (> 3 years ago), but some recent
versions do some really bizarre and illogical stuff here. Is this also a
matter of emulating windows? We Linux and Unix users like network
transparency and multiple desktops, please don't break them for us. And
it was working fine for ages before, so why mess with it now?


>>> What happens if you launch a program from the command line without a
>>> file name argument? Does the application get focus?
>>
>> No, of course not.
> 
> Thanks.
> 
>> And this has been the case with other Window managers as well, even
>> before KDE. Even in mwm, twm, fvwm, applications didn't steal focus
>> willy-nilly. I don't know for sure about Gnome, I don't use Gnome very
>> often, but I guess I would have noticed if this was the case...

Thanks,

Alain

bug#7269: bug #7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to, the top left of the frames buffer.

[Lennart Borgman]

On Sat, Nov 13, 2010 at 11:10 PM, Alain Knaff <alain@knaff.lu> wrote:
>>
>> Why is it good that the newly started program does not get focus?
>
> In order not to disrupt the user's work in some other program.
> Multitasking may be a foreign concept on Windows, but on Linux, people
> routinely have multiple programs open.

Having multiple programs open is the idea of Windows I guess (but it
was not invented by MS, it is older).

> They may launch a compilation in
> one window, and then, while it runs,  launch a firefox for their online
> banking. They would be rather unhappy if suddenly their online banking
> password would show up readable for all shoulder surfers in the
> emacsclient spawned by cvs commit.

I think you refer to another problem: The sync problem of keyboard
input and window focus. When a new program is launched and it is going
to grab focus it is difficult to sync.

However I would say that the compilation program should not get window
and keyboard focus automatically. There should be a way to avoid it.
And isn't there actually that? Can't you start those programs in the
background from most shells?

> Please don't break multitasking, it is one of the many features that we
> love about Linux.

This is not a GNU/Linux thing.

> However, it could be argued that the window manager should do a better
> job at policing applications.

It would seem natural to me that the window manager respected the
users decision to run a program in the background. (But I do not know
if there is enough semantic/syntax for that for the shells. I simply
no very little about the *nix shells. And I even do not know about
this for the w32 shells.)

> But apparently, there is more than one method to grab focus, and some
> aren't blocked by this

Yes. In some situations the users choice must be overriden. But on w32
there has been many changes to avoid that this is used when it should
not be used. (In the case of emacsclient it should be used.)

>>> I don't believe this is a window manager issue... if that was the case,
>>> wouldn't all applications behave the same way?
>>
>> No. There are some extra difficulties since Emacs uses a server which
>> emacsclients connects to.
>
> I've noticed some weirdness there too. Normally, the idea of emacsclient
> should be to display the client on the DISPLAY pointed to by the client,
> not by the server. Indeed, if I'm logged in over ssh to a remote server,
> and start an emacsclient, I want to see that emacsclient on my display,
> and not have it displayed on the server's console in some dusty NOC
> where it is of use to no-one. Same thing with virtual desktops: I want
> to see the emacsclient on the desktop that I am currently on, and not on
> the one where emacs' main window is (or worse, have me forcefully
> teleported to that desktop).
>
> This was working fine in the old days (> 3 years ago), but some recent
> versions do some really bizarre and illogical stuff here. Is this also a
> matter of emulating windows? We Linux and Unix users like network
> transparency and multiple desktops, please don't break them for us. And
> it was working fine for ages before, so why mess with it now?


This is over my head. I know nothing about this. But I hope someone
else will look at it.

bug#7269: bug #7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to, the top left of the frames buffer.

[Alain Knaff]

On 11/13/2010 11:38 PM, Lennart Borgman wrote:
> On Sat, Nov 13, 2010 at 11:10 PM, Alain Knaff <alain@knaff.lu> wrote:
>>>
>>> Why is it good that the newly started program does not get focus?
>>
>> In order not to disrupt the user's work in some other program.
>> Multitasking may be a foreign concept on Windows, but on Linux, people
>> routinely have multiple programs open.
> 
> Having multiple programs open is the idea of Windows I guess (but it
> was not invented by MS, it is older).

Very few things have been invented by MS... :-)

> 
>> They may launch a compilation in
>> one window, and then, while it runs,  launch a firefox for their online
>> banking. They would be rather unhappy if suddenly their online banking
>> password would show up readable for all shoulder surfers in the
>> emacsclient spawned by cvs commit.
> 
> I think you refer to another problem: The sync problem of keyboard
> input and window focus.

I'm concerned about keyboard focus here, i.e. which window gets the
keyboard input events. I vaguely remember having read that there are
other kinds of focus than keyboard focus (window focus?), but I'm unsure
what they do exactly, and am (for this discussion...) not overly
concerned with these.

> When a new program is launched and it is going
> to grab focus it is difficult to sync.

I think this is exactly the reason why focus changes should be initiated
by the user.

Keyboard input is context sensitive. Backspace typed in a shell window
means something else than backspace typed in digikam for example (in one
case, it just erases the last character types, whereas in the other, it
wipes the currently displayed photo...)

Now, if something else than the source of keyboard input changes the
interpretation context (focus), SNAFU results. Hence the rule that all
keyboard focus changes should be initiated (or at least acknowledged) by
the user, who is the source of keyboard input.

However, as acknowledging application-requested keyboard focus is just
as much work as just moving the mouse over to the app to give it
keyboard focus, I think we can do away with that scenario.

So, the app only gets keyboard focus when the user gives it keyboard
focus. Period.

Sometimes an application may want to get the user's attention (to inform
him that they are "done", or that some error condition needs a
decision). The proper way to do this is to flash their border, or their
outline in the desktop pager, but never to forcefully grab keyboard focus.

> 
> However I would say that the compilation program should not get window
> and keyboard focus automatically.

Yes, that's my point. No part of, or program spawned by the compilation
should just grab keyboard focus.

> There should be a way to avoid it.

There is a way to avoid it (keyboard focus stealing prevention), but
wouldn't it be so much better if all programs just behaved nice?

> And isn't there actually that? Can't you start those programs in the
> background from most shells?

I'm not really sure what background has to do with it... Background only
affects which process should get signals if you press Ctrl-C in the
terminal window, it doesn't have anything to do with what other windows
these programs may spawn, and what they do with these...

>> Please don't break multitasking, it is one of the many features that we
>> love about Linux.
> 
> This is not a GNU/Linux thing.
> 
>> However, it could be argued that the window manager should do a better
>> job at policing applications.
> 
> It would seem natural to me that the window manager respected the
> users decision to run a program in the background.

How would the window manager even know which program was in the
background in the general case? Hint: it may not even run on the same
machine. And even in the local case, not all shells may manage
foreground/background in the same way. And in many cases, the
application might not even have been started by an interactive shell in
the first place...

And the compilation from my example would probably been have started in
the foreground in its shell, in order not to mess up its copious output...

And why should it be the window manager's job to police apps? You sound
a little bit like the thief who complains "why aren't there enough
police around to keep me in line". It's your app who plays nasty, please
fix it. And I don't care that in the Middle East (Windows), stealing
might be acceptable behavior, I live in Europe (Linux), and here it this
is definitely  not acceptable :-)

Why can't emacs respect the user's wish to never steal keyboard focus, ever?


> (But I do not know
> if there is enough semantic/syntax for that for the shells. I simply
> no very little about the *nix shells. And I even do not know about
> this for the w32 shells.)

On Linux, the appropriate behavior would be:

1. If the shell's name ends in sh, then do not let the app forcefully
grab keyboard focus
2. And for those rare shells whose name doesn't end in sh, do not let
the app forcefully grab keyboard focus either :-)

> 
>> But apparently, there is more than one method to grab focus, and some
>> aren't blocked by this
> 
> Yes. In some situations the users choice must be overriden.

Which would these be?

> But on w32
> there has been many changes to avoid that this is used when it should
> not be used. (In the case of emacsclient it should be used.)

Maybe all these Windows specific hacks should be bracketed by #ifdef W32
... #endif so that they don't bother users of other platforms?

>>>> I don't believe this is a window manager issue... if that was the case,
>>>> wouldn't all applications behave the same way?
>>>
>>> No. There are some extra difficulties since Emacs uses a server which
>>> emacsclients connects to.
>>
>> I've noticed some weirdness there too. Normally, the idea of emacsclient
>> should be to display the client on the DISPLAY pointed to by the client,
>> not by the server. Indeed, if I'm logged in over ssh to a remote server,
>> and start an emacsclient, I want to see that emacsclient on my display,
>> and not have it displayed on the server's console in some dusty NOC
>> where it is of use to no-one. Same thing with virtual desktops: I want
>> to see the emacsclient on the desktop that I am currently on, and not on
>> the one where emacs' main window is (or worse, have me forcefully
>> teleported to that desktop).
>>
>> This was working fine in the old days (> 3 years ago), but some recent
>> versions do some really bizarre and illogical stuff here. Is this also a
>> matter of emulating windows? We Linux and Unix users like network
>> transparency and multiple desktops, please don't break them for us. And
>> it was working fine for ages before, so why mess with it now?
> 
> 
> This is over my head. I know nothing about this. But I hope someone
> else will look at it.

In simpler words: we chose to use Linux because we prefer the way it
works. Please don't make it behave like Windows :-)

Thanks,

Alain

bug#7269: bug #7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to, the top left of the frames buffer.

[Lennart Borgman]

On Sun, Nov 14, 2010 at 12:20 AM, Alain Knaff <alain@knaff.lu> wrote:

>>
>> I think you refer to another problem: The sync problem of keyboard
>> input and window focus.
>
> I'm concerned about keyboard focus here, i.e. which window gets the
> keyboard input events. I vaguely remember having read that there are
> other kinds of focus than keyboard focus (window focus?), but I'm unsure
> what they do exactly, and am (for this discussion...) not overly
> concerned with these.

I am beeing very imprecise here. What you should distinguish is which
window/application takes the keyboard input and which window is on top
on the screen. (The latter means that it will take mouse input inside
the window.)

>> When a new program is launched and it is going
>> to grab focus it is difficult to sync.
>
> I think this is exactly the reason why focus changes should be initiated
> by the user.
>
> Keyboard input is context sensitive.

All input is.

> .. Hence the rule that all
> keyboard focus changes should be initiated (or at least acknowledged) by
> the user, who is the source of keyboard input.

Yes, but there seem to be different opinions for what this mean. In
many circumstances launching an application means you want to use it
and therefore wants it to have input focus. But not in your use cases
of course.

> So, the app only gets keyboard focus when the user gives it keyboard
> focus. Period.

Unfortunately that is not clear, see above.

> Sometimes an application may want to get the user's attention (to inform
> him that they are "done", or that some error condition needs a
> decision). The proper way to do this is to flash their border, or their
> outline in the desktop pager, but never to forcefully grab keyboard focus.

It depends on the window manager what the proper way is. It is
actually specified for some of them.

>> However I would say that the compilation program should not get window
>> and keyboard focus automatically.
>
> Yes, that's my point. No part of, or program spawned by the compilation
> should just grab keyboard focus.
>
>> There should be a way to avoid it.
..
>> And isn't there actually that? Can't you start those programs in the
>> background from most shells?
>
> I'm not really sure what background has to do with it... Background only
> affects which process should get signals if you press Ctrl-C in the
> terminal window, it doesn't have anything to do with what other windows
> these programs may spawn, and what they do with these...

So this means that this part of the semantic does not apply here. I do
not know if there is anything else that can glue things together.
Maybe the semantic has not been specified clearly.


>> It would seem natural to me that the window manager respected the
>> users decision to run a program in the background.
>
> How would the window manager even know which program was in the
> background in the general case? Hint: it may not even run on the same
> machine. And even in the local case, not all shells may manage
> foreground/background in the same way. And in many cases, the
> application might not even have been started by an interactive shell in
> the first place...

These are good point, but different people and different situations
might require different solutions. However I do not know anything
about what has been done on that level.

> And the compilation from my example would probably been have started in
> the foreground in its shell, in order not to mess up its copious output...
>
> And why should it be the window manager's job to police apps?

I think it is about cooperation and some pieces might be missing, see above.

>> (But I do not know
>> if there is enough semantic/syntax for that for the shells. I simply
>> no very little about the *nix shells. And I even do not know about
>> this for the w32 shells.)
>
> On Linux, the appropriate behavior would be:
>
> 1. If the shell's name ends in sh, then do not let the app forcefully
> grab keyboard focus
> 2. And for those rare shells whose name doesn't end in sh, do not let
> the app forcefully grab keyboard focus either :-)

Simple enough ;-)

But maybe not flexible enough.

>>> But apparently, there is more than one method to grab focus, and some
>>> aren't blocked by this
>>
>> Yes. In some situations the users choice must be overriden.
>
> Which would these be?

Urgent messages.

>> But on w32
>> there has been many changes to avoid that this is used when it should
>> not be used. (In the case of emacsclient it should be used.)
>
> Maybe all these Windows specific hacks should be bracketed by #ifdef W32
> ... #endif so that they don't bother users of other platforms?

I don't think this is a w32 specific problem at all. See above. There
are different solutions and your solution tends to be best for a
programmer, at least it looks so to me. However most users are not
programmers (and maybe that is part of the problem for GNU/Linux that
opinions from programmers does not respect other users needs and
therefore makes the platform unnecessary impopular).

> In simpler words: we chose to use Linux because we prefer the way it
> works. Please don't make it behave like Windows :-)

There are bigger issues than this. The whole platform GNU/Linux exists
because people want a free platform. Whether it should behave like w32
is something that should be evaluated mainly against this.

bug#7269: bug #7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to, the top left of the frames buffer.

[Alain Knaff]

On 11/14/2010 12:50 AM, Lennart Borgman wrote:
> On Sun, Nov 14, 2010 at 12:20 AM, Alain Knaff <alain@knaff.lu> wrote:
> 
>>>
>>> I think you refer to another problem: The sync problem of keyboard
>>> input and window focus.
>>
>> I'm concerned about keyboard focus here, i.e. which window gets the
>> keyboard input events. I vaguely remember having read that there are
>> other kinds of focus than keyboard focus (window focus?), but I'm unsure
>> what they do exactly, and am (for this discussion...) not overly
>> concerned with these.
> 
> I am beeing very imprecise here. What you should distinguish is which
> window/application takes the keyboard input and which window is on top
> on the screen. (The latter means that it will take mouse input inside
> the window.)

ok, I see. Yes, in my case I'm more concerned about keyboard input than
about which window is on top.

>>> When a new program is launched and it is going
>>> to grab focus it is difficult to sync.
>>
>> I think this is exactly the reason why focus changes should be initiated
>> by the user.
>>
>> Keyboard input is context sensitive.
> 
> All input is.

:-)

>> .. Hence the rule that all
>> keyboard focus changes should be initiated (or at least acknowledged) by
>> the user, who is the source of keyboard input.
> 
> Yes, but there seem to be different opinions for what this mean. In
> many circumstances launching an application means you want to use it
> and therefore wants it to have input focus. But not in your use cases
> of course.

Maybe it's dangerous to make too many assumptions, and preferable to
rely on explicit actions rather than second-guessing the user. Maybe the
user was just feeling hot? :-)

>> So, the app only gets keyboard focus when the user gives it keyboard
>> focus. Period.
> 
> Unfortunately that is not clear, see above.

Why does this have to feel like a cheesy rape trial? :-)

>> Sometimes an application may want to get the user's attention (to inform
>> him that they are "done", or that some error condition needs a
>> decision). The proper way to do this is to flash their border, or their
>> outline in the desktop pager, but never to forcefully grab keyboard focus.
> 
> It depends on the window manager what the proper way is. It is
> actually specified for some of them.

Hopefully there is a standardized API for "get user's attention
unintrusively"...

[...]
>> I'm not really sure what background has to do with it... Background only
>> affects which process should get signals if you press Ctrl-C in the
>> terminal window, it doesn't have anything to do with what other windows
>> these programs may spawn, and what they do with these...
> 
> So this means that this part of the semantic does not apply here.

No, not really...

> I do
> not know if there is anything else that can glue things together.
> Maybe the semantic has not been specified clearly.

Why can't the answer to "when is it allowed to grab focus" simply be
"never"?

>>> It would seem natural to me that the window manager respected the
>>> users decision to run a program in the background.
>>
>> How would the window manager even know which program was in the
>> background in the general case? Hint: it may not even run on the same
>> machine. And even in the local case, not all shells may manage
>> foreground/background in the same way. And in many cases, the
>> application might not even have been started by an interactive shell in
>> the first place...
> 
> These are good point, but different people and different situations
> might require different solutions. However I do not know anything
> about what has been done on that level.

Somehow, other apps don't feel the need to mess in a similar way with
keyboard focus.

Now, I understand that it is a windows compatibility thingy. But then,
why is this code activated on non-Windows platforms? Wouldn't it be
possible to make everybody happy by just bracketing it with #idef w32
... #endif, or something similar?

> 
>> And the compilation from my example would probably been have started in
>> the foreground in its shell, in order not to mess up its copious output...
>>
>> And why should it be the window manager's job to police apps?
> 
> I think it is about cooperation and some pieces might be missing, see above.

Yeah, that's the point. Window manager assume well-behaved (cooperative)
apps, but apparently some aren't. Hence the need of "focus stealing
prevention" and similar settings, which unfortunately don't always work
(either they are ineffective, or have undesirable side-effects...)

> 
>>> (But I do not know
>>> if there is enough semantic/syntax for that for the shells. I simply
>>> no very little about the *nix shells. And I even do not know about
>>> this for the w32 shells.)
>>
>> On Linux, the appropriate behavior would be:
>>
>> 1. If the shell's name ends in sh, then do not let the app forcefully
>> grab keyboard focus
>> 2. And for those rare shells whose name doesn't end in sh, do not let
>> the app forcefully grab keyboard focus either :-)
> 
> Simple enough ;-)
> 
> But maybe not flexible enough.

Well, it's simple enough for the 99% of the other Linux applications out
there...

>>>> But apparently, there is more than one method to grab focus, and some
>>>> aren't blocked by this
>>>
>>> Yes. In some situations the users choice must be overriden.
>>
>> Which would these be?
> 
> Urgent messages.

Wouldn't "flashing" the app's outline be more appropriate? Just imagine
emacs wanted to display the urgent message "Disk filling up. Is it ok to
delete file xyz.abc to make space (y/n)", but the user just started to
type "yesterday" into another app?

>>> But on w32
>>> there has been many changes to avoid that this is used when it should
>>> not be used. (In the case of emacsclient it should be used.)
>>
>> Maybe all these Windows specific hacks should be bracketed by #ifdef W32
>> ... #endif so that they don't bother users of other platforms?
> 
> I don't think this is a w32 specific problem at all.

Well, I think it is. According to you, on Windows, most apps grab focus
when launched. From my observation, on Linux almost none do. Shouldn't
that tell you something? Why does emacs want to be the white elephant here?

> See above. There
> are different solutions and your solution tends to be best for a
> programmer, at least it looks so to me. However most users are not
> programmers (and maybe that is part of the problem for GNU/Linux that
> opinions from programmers does not respect other users needs and
> therefore makes the platform unnecessary impopular).

We have a saying here in Luxembourg: "Mir wölle bleiwe wat mir sin" ("We
want to stay what we are"). What good is a popular Linux if it has had
to sell its soul in order to become so? If I want Windows, I can go out
into a shop and buy it right now. I don't need to transform Linux into
Windows.

If popularity means becoming flaky and unreliable, I prefer to live
without it.

... and if you are really concerned about pandering to Windows users
that migrated to Linux, then bracket the offending code with

if(getenv("WINDOWS_COMPATIBILITY")) {
  ...
}

instead. So those users who really want this can set the
WINDOWS_COMPATIBILITY environment variable to 1...

Hey, maybe we can even get a standard rolling to agree on a same
environment variable for all applications that might feel the need to
transform Linux into Windows :-)

> 
>> In simpler words: we chose to use Linux because we prefer the way it
>> works. Please don't make it behave like Windows :-)
> 
> There are bigger issues than this. The whole platform GNU/Linux exists
> because people want a free platform. Whether it should behave like w32
> is something that should be evaluated mainly against this.

IMHO, solidity, usability and reliability played as big a role in the
popularity of Linux (amongst its primary audience) than its freeness (be
it as in beer or as in speech). Why do we have to throw away our
advantages to pander to the masses?

Alain

bug#7269: bug #7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to, the top left of the frames buffer.

[Lennart Borgman]

On Sun, Nov 14, 2010 at 1:20 AM, Alain Knaff <alain@knaff.lu> wrote:
>
> Why does this have to feel like a cheesy rape trial? :-)

Not sure ;-)


> Hopefully there is a standardized API for "get user's attention
> unintrusively"...

There is the "always on top" feature for windows.


>> I do
>> not know if there is anything else that can glue things together.
>> Maybe the semantic has not been specified clearly.
>
> Why can't the answer to "when is it allowed to grab focus" simply be
> "never"?

Because it would be very inconventient.

Take for example the case when a user double-clicks on a file in the
file manager (on w32 it is Windows Explorer). Then the purpose is to
open it in the associated application, for example a word processor.
Is there any reason not to give the word processor the focus in this
case? (Please remember this is a very common use case.)


> Somehow, other apps don't feel the need to mess in a similar way with
> keyboard focus.

Of course Emacs should behave similar to other apps on the platform as
far as possible. At least in my opinion.


> Now, I understand that it is a windows compatibility thingy.

I am not sure that it is w32 only. I would be very surprised if it was.



>> I think it is about cooperation and some pieces might be missing, see above.
>
> Yeah, that's the point. Window manager assume well-behaved (cooperative)
> apps, but apparently some aren't. Hence the need of "focus stealing
> prevention" and similar settings, which unfortunately don't always work
> (either they are ineffective, or have undesirable side-effects...)

I think the apps can not solve this all by themselves. But looking
into the possible semantics of this is far beyond what we actually
talking about now.


>>>>> But apparently, there is more than one method to grab focus, and some
>>>>> aren't blocked by this
>>>>
>>>> Yes. In some situations the users choice must be overriden.
>>>
>>> Which would these be?
>>
>> Urgent messages.
>
> Wouldn't "flashing" the app's outline be more appropriate? Just imagine
> emacs wanted to display the urgent message "Disk filling up. Is it ok to
> delete file xyz.abc to make space (y/n)", but the user just started to
> type "yesterday" into another app?

In some situations it is not enough. (For example if continuing doing
something might crash the computer or destroy data.)


>> I don't think this is a w32 specific problem at all.
>
> Well, I think it is. According to you, on Windows, most apps grab focus
> when launched.

No. The window manager gives them focus.


> From my observation, on Linux almost none do. Shouldn't
> that tell you something? Why does emacs want to be the white elephant here?

I am sure it does not want to be that.

Did you try changing the option `server-raise-frame' in Emacs?


>> There are bigger issues than this. The whole platform GNU/Linux exists
>> because people want a free platform. Whether it should behave like w32
>> is something that should be evaluated mainly against this.
>
> IMHO, solidity, usability and reliability played as big a role in the
> popularity of Linux (amongst its primary audience) than its freeness (be
> it as in beer or as in speech). Why do we have to throw away our
> advantages to pander to the masses?

I doubt that there actually would be any GNU/Linux if it was only for
programmers. It is too expensive for that. A lot of people would not
invest their free time to develop it - and without that the price
would be too high. It is or could be a treasure.

bug#7269: bug #7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to, the top left of the frames buffer.

[Alain Knaff]

On 11/14/2010 01:51 AM, Lennart Borgman wrote:
> On Sun, Nov 14, 2010 at 1:20 AM, Alain Knaff <alain@knaff.lu> wrote:
[...]
>> Hopefully there is a standardized API for "get user's attention
>> unintrusively"...
> 
> There is the "always on top" feature for windows.

Strange name ...

>>> I do
>>> not know if there is anything else that can glue things together.
>>> Maybe the semantic has not been specified clearly.
>>
>> Why can't the answer to "when is it allowed to grab focus" simply be
>> "never"?
> 
> Because it would be very inconventient.
> 
> Take for example the case when a user double-clicks on a file in the
> file manager (on w32 it is Windows Explorer). Then the purpose is to
> open it in the associated application, for example a word processor.
> Is there any reason not to give the word processor the focus in this
> case? (Please remember this is a very common use case.)

Yes, same reasons as discussed earlier still apply:
- not re-interpret user's keyboard input in other context
- not disrupt his work

Why do you think launching a word processor should be somehow special?

Remember, word processors are not among the fastest starting programs,
so there is the real possibility that the user quickly checked his mail
or did something else while waiting for it to open up.

In the old days, when computers were slower, people would have a cup of
coffee while waiting for their stuff to come up. Maybe word processors
back then should have opened the CD tray in order to knock off the
coffee cup from the table, to make sure that the user promptly got back
to them when they were finally ready :-)

Maybe, on w32, it is too cumbersome for the user to give an app the
focus, but this is not the case on Linux, so people are rightfully
appalled when you try to second-guess them here.

>> Somehow, other apps don't feel the need to mess in a similar way with
>> keyboard focus.
> 
> Of course Emacs should behave similar to other apps on the platform as
> far as possible. At least in my opinion.

Exactly. Great to see that we finally agree :-)

>> Now, I understand that it is a windows compatibility thingy.
> 
> I am not sure that it is w32 only. I would be very surprised if it was.

Maybe. Maybe not. But it for sure isn't the case on Linux or other
Unices. So please leave these platforms alone with this second guessing.

>>> I think it is about cooperation and some pieces might be missing, see above.
>>
>> Yeah, that's the point. Window manager assume well-behaved (cooperative)
>> apps, but apparently some aren't. Hence the need of "focus stealing
>> prevention" and similar settings, which unfortunately don't always work
>> (either they are ineffective, or have undesirable side-effects...)
> 
> I think the apps can not solve this all by themselves. But looking
> into the possible semantics of this is far beyond what we actually
> talking about now.

But why are the apps even _trying_ to "solve" anything here? In this
case, it's the apps themselves that are the problem. The solution to the
problem is trivial: don't interfere with the focus _at_all_ on those
platforms where this is frowned upon (Linux, Unix, and possibly others)

Other applications don't try to recreate the "windows experience" on
Linux in such a way either. They just display their window, period.

[...]
>> Wouldn't "flashing" the app's outline be more appropriate? Just imagine
>> emacs wanted to display the urgent message "Disk filling up. Is it ok to
>> delete file xyz.abc to make space (y/n)", but the user just started to
>> type "yesterday" into another app?
> 
> In some situations it is not enough. (For example if continuing doing
> something might crash the computer or destroy data.)

Wouldn't just stopping its own processing, flashing its outline, and
then patiently waiting for its turn be enough?

Could you just give me one concrete situation where forcefully
interrupting the user, and possibly misinterpreting the user's random
chattering as the answer to a life-and-death situation would be
acceptable behavior?

But in any case, we are not even talking about exceptional circumstances
here. If not stopped by the window manager, emacsclient does it
_every_single_time_...

>>> I don't think this is a w32 specific problem at all.
>>
>> Well, I think it is. According to you, on Windows, most apps grab focus
>> when launched.
> 
> No. The window manager gives them focus.

So, apps don't NEED to play games, even on w32, as the window manager
does it for them there?! Well in that case, that bunch of code which
creates the mischief can go:

   On Windows it is not needed, and on Linux it is not wanted.

So why exactly is it there?


>> From my observation, on Linux almost none do. Shouldn't
>> that tell you something? Why does emacs want to be the white elephant here?
> 
> I am sure it does not want to be that.

I am glad we finally agree.

Hopefully, whoever is making decisions on these (mis)features sees this
as well :-)

> Did you try changing the option `server-raise-frame' in Emacs?

Yes, this works, thanks for this valuable information. Hopefully it
doesn't have any nasty side-effects... (the strange name worries me
somewhat...)

No, I didn't know about this option yet. Maybe this should also default
to nil, just like the focus-follows-mouse option should? Or a global
switch to switch off all focus and mouse related "bizarreness" altogether?


>>> There are bigger issues than this. The whole platform GNU/Linux exists
>>> because people want a free platform. Whether it should behave like w32
>>> is something that should be evaluated mainly against this.
>>
>> IMHO, solidity, usability and reliability played as big a role in the
>> popularity of Linux (amongst its primary audience) than its freeness (be
>> it as in beer or as in speech). Why do we have to throw away our
>> advantages to pander to the masses?
> 
> I doubt that there actually would be any GNU/Linux if it was only for
> programmers. It is too expensive for that. A lot of people would not
> invest their free time to develop it - and without that the price
> would be too high. It is or could be a treasure.

If there were no programmers, there wouldn't be any GNU/Linux at all.
Think about it. Why do we programmers have to be so self-deprecatingly
masochistic?

And don't be fooled by my initial example of "lengthy compilation". I
could just as well have said "lengthy account consolidation
calculation", "lengthy movie rendering job", or even "slow starting
office productivity app".

Regards,

Alain

bug#7269: 24.0.50; opening a file via emacsclient -c <file> moves the mouse cursor to the top left of the frames buffer.

[Chong Yidong]

> > A workaround is M-x customize-save-variable focus-follows-mouse n.
> > It’s probably time to flip the default, since even on X these days
> > there are only a small minority of focus-follows-mouse users.

> Even tho I love focus follows mouse, I'd tend to agree: not only it
> seems we're in the minority, but the nil value is a safer default
> since moving the mouse is something that should usually be avoided.

Since no one has spoken up against making focus-follows-mouse nil, I
made it so; committed to trunk.