bug#21403: 25.0.50; invisible y-or-n-p prompt

bug#21403: 25.0.50; invisible y-or-n-p prompt

[Mark Oteiza]

Hi,

Somewhere between g5c0fb39 and gfa5a9c7, evaluating the following
results in an empty prompt:

  (y-or-n-p "foo? ")

I'm guessing g5dc644a, as it touches the minibuffer

bug#21403: 25.0.50; invisible y-or-n-p prompt

[Stefan Monnier]

> Somewhere between g5c0fb39 and gfa5a9c7, evaluating the following
> results in an empty prompt:

>   (y-or-n-p "foo? ")

> I'm guessing g5dc644a, as it touches the minibuffer

I think it's fixed now,


        Stefan

bug#21396: 25.0.50; read-key's prompt is not visible

[Tassilo Horn]

I just updated my emacs copy to commit
30866274e21c5f0a1c5f60cfe290743e7d482349.  When I do:

  1. emacs -Q
  2. eval (read-key "Gimme Key: ") in *scratch*

the key will be read but the prompt is not shown in the minibuffer
(though it will be there in the *Messages* buffer after reading the
key).  This is very confusing since I set `yes-or-no-p' to `y-or-n-p',
and now I can't see when something waits for my confirmation.

`read-string' still works as intended; its prompt is shown.

Git bisect says the commit introducing this problem is Stefan whom I
added to the Cc.

--8<---------------cut here---------------start------------->8---
commit 5dc644a6b01e2cf950ff617ab15be4bf1917c38c
Author: Stefan Monnier <monnier@iro.umontreal.ca>
Date:   Tue Sep 1 21:14:18 2015 -0400

    Generalize the prefix-command machinery of C-u
--8<---------------cut here---------------end--------------->8---




In GNU Emacs 25.0.50.8 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6)
 of 2015-09-02
Repository revision: 30866274e21c5f0a1c5f60cfe290743e7d482349
Windowing system distributor 'The X.Org Foundation', version 11.0.11702000
System Description:	Arch Linux

Configured using:
 'configure 'CFLAGS=-g -ggdb3 -O1''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LC_MONETARY: de_DE.utf8
  value of $LC_NUMERIC: de_DE.utf8
  value of $LC_TIME: de_DE.utf8
  value of $LANG: en_US.utf8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  TeX-PDF-mode: t
  TeX-source-correlate-mode: t
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  diff-auto-refine-mode: t
  global-company-mode: t
  company-mode: t
  shell-dirtrack-mode: t
  paredit-mode: t
  global-aggressive-indent-mode: t
  aggressive-indent-mode: t
  highlight-symbol-mode: t
  outline-minor-mode: t
  pdf-occur-global-minor-mode: t
  recentf-mode: t
  highlight-parentheses-mode: t
  global-subword-mode: t
  subword-mode: t
  save-place-mode: t
  savehist-mode: t
  show-paren-mode: t
  ivy-mode: t
  minibuffer-depth-indicate-mode: t
  electric-pair-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Result: nil

Result: nil

Result: nil
Continue...
Test: (y or n) n
nil
y-or-n-p
105 (#o151, #x69, ?i)

Load-path shadows:
~/Repos/el/auctex/lpath hides ~/Repos/el/gnus/lisp/lpath
~/Repos/el/highlight-symbol.el/highlight-symbol hides /home/horn/.emacs.d/elpa/highlight-symbol-20150816.628/highlight-symbol
~/Repos/el/gnus/lisp/md4 hides /home/horn/Repos/el/emacs/lisp/md4
~/Repos/el/gnus/lisp/color hides /home/horn/Repos/el/emacs/lisp/color
~/Repos/el/gnus/lisp/format-spec hides /home/horn/Repos/el/emacs/lisp/format-spec
~/Repos/el/gnus/lisp/password-cache hides /home/horn/Repos/el/emacs/lisp/password-cache
~/Repos/el/gnus/lisp/hex-util hides /home/horn/Repos/el/emacs/lisp/hex-util
~/Repos/el/gnus/lisp/dns-mode hides /home/horn/Repos/el/emacs/lisp/textmodes/dns-mode
~/Repos/el/gnus/lisp/dig hides /home/horn/Repos/el/emacs/lisp/net/dig
~/Repos/el/gnus/lisp/hmac-md5 hides /home/horn/Repos/el/emacs/lisp/net/hmac-md5
~/Repos/el/gnus/lisp/ntlm hides /home/horn/Repos/el/emacs/lisp/net/ntlm
~/Repos/el/gnus/lisp/hmac-def hides /home/horn/Repos/el/emacs/lisp/net/hmac-def
~/Repos/el/gnus/lisp/rfc2104 hides /home/horn/Repos/el/emacs/lisp/net/rfc2104
~/Repos/el/gnus/lisp/sasl-ntlm hides /home/horn/Repos/el/emacs/lisp/net/sasl-ntlm
~/Repos/el/gnus/lisp/sasl-cram hides /home/horn/Repos/el/emacs/lisp/net/sasl-cram
~/Repos/el/gnus/lisp/dns hides /home/horn/Repos/el/emacs/lisp/net/dns
~/Repos/el/gnus/lisp/sasl hides /home/horn/Repos/el/emacs/lisp/net/sasl
~/Repos/el/gnus/lisp/tls hides /home/horn/Repos/el/emacs/lisp/net/tls
~/Repos/el/gnus/lisp/sasl-scram-rfc hides /home/horn/Repos/el/emacs/lisp/net/sasl-scram-rfc
~/Repos/el/gnus/lisp/netrc hides /home/horn/Repos/el/emacs/lisp/net/netrc
~/Repos/el/gnus/lisp/sasl-digest hides /home/horn/Repos/el/emacs/lisp/net/sasl-digest
~/Repos/el/gnus/lisp/uudecode hides /home/horn/Repos/el/emacs/lisp/mail/uudecode
~/Repos/el/gnus/lisp/binhex hides /home/horn/Repos/el/emacs/lisp/mail/binhex
~/Repos/el/gnus/lisp/hashcash hides /home/horn/Repos/el/emacs/lisp/mail/hashcash
~/Repos/el/gnus/lisp/canlock hides /home/horn/Repos/el/emacs/lisp/gnus/canlock
~/Repos/el/gnus/lisp/nneething hides /home/horn/Repos/el/emacs/lisp/gnus/nneething
~/Repos/el/gnus/lisp/mm-encode hides /home/horn/Repos/el/emacs/lisp/gnus/mm-encode
~/Repos/el/gnus/lisp/mm-util hides /home/horn/Repos/el/emacs/lisp/gnus/mm-util
~/Repos/el/gnus/lisp/rfc2047 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2047
~/Repos/el/gnus/lisp/nnml hides /home/horn/Repos/el/emacs/lisp/gnus/nnml
~/Repos/el/gnus/lisp/gnus-cus hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cus
~/Repos/el/gnus/lisp/gnus-range hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-range
~/Repos/el/gnus/lisp/gnus-int hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-int
~/Repos/el/gnus/lisp/gnus-cloud hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cloud
~/Repos/el/gnus/lisp/spam-stat hides /home/horn/Repos/el/emacs/lisp/gnus/spam-stat
~/Repos/el/gnus/lisp/nnmh hides /home/horn/Repos/el/emacs/lisp/gnus/nnmh
~/Repos/el/gnus/lisp/gnus-mlspl hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-mlspl
~/Repos/el/gnus/lisp/deuglify hides /home/horn/Repos/el/emacs/lisp/gnus/deuglify
~/Repos/el/gnus/lisp/gnus-gravatar hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-gravatar
~/Repos/el/gnus/lisp/nngateway hides /home/horn/Repos/el/emacs/lisp/gnus/nngateway
~/Repos/el/gnus/lisp/ietf-drums hides /home/horn/Repos/el/emacs/lisp/gnus/ietf-drums
~/Repos/el/gnus/lisp/mail-parse hides /home/horn/Repos/el/emacs/lisp/gnus/mail-parse
~/Repos/el/gnus/lisp/gnus-salt hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-salt
~/Repos/el/gnus/lisp/nnimap hides /home/horn/Repos/el/emacs/lisp/gnus/nnimap
~/Repos/el/gnus/lisp/gnus-draft hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-draft
~/Repos/el/gnus/lisp/mail-source hides /home/horn/Repos/el/emacs/lisp/gnus/mail-source
~/Repos/el/gnus/lisp/messcompat hides /home/horn/Repos/el/emacs/lisp/gnus/messcompat
~/Repos/el/gnus/lisp/pop3 hides /home/horn/Repos/el/emacs/lisp/gnus/pop3
~/Repos/el/gnus/lisp/nnmaildir hides /home/horn/Repos/el/emacs/lisp/gnus/nnmaildir
~/Repos/el/gnus/lisp/nnheader hides /home/horn/Repos/el/emacs/lisp/gnus/nnheader
~/Repos/el/gnus/lisp/gnus-cite hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cite
~/Repos/el/gnus/lisp/nndiary hides /home/horn/Repos/el/emacs/lisp/gnus/nndiary
~/Repos/el/gnus/lisp/gnus-diary hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-diary
~/Repos/el/gnus/lisp/nnfolder hides /home/horn/Repos/el/emacs/lisp/gnus/nnfolder
~/Repos/el/gnus/lisp/gnus-art hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-art
~/Repos/el/gnus/lisp/gnus-demon hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-demon
~/Repos/el/gnus/lisp/mml-sec hides /home/horn/Repos/el/emacs/lisp/gnus/mml-sec
~/Repos/el/gnus/lisp/nnir hides /home/horn/Repos/el/emacs/lisp/gnus/nnir
~/Repos/el/gnus/lisp/mm-partial hides /home/horn/Repos/el/emacs/lisp/gnus/mm-partial
~/Repos/el/gnus/lisp/gnus-registry hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-registry
~/Repos/el/gnus/lisp/gnus-icalendar hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-icalendar
~/Repos/el/gnus/lisp/compface hides /home/horn/Repos/el/emacs/lisp/gnus/compface
~/Repos/el/gnus/lisp/gnus-fun hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-fun
~/Repos/el/gnus/lisp/gnus-start hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-start
~/Repos/el/gnus/lisp/smiley hides /home/horn/Repos/el/emacs/lisp/gnus/smiley
~/Repos/el/gnus/lisp/gnus-picon hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-picon
~/Repos/el/gnus/lisp/spam-report hides /home/horn/Repos/el/emacs/lisp/gnus/spam-report
~/Repos/el/gnus/lisp/nntp hides /home/horn/Repos/el/emacs/lisp/gnus/nntp
~/Repos/el/gnus/lisp/nnnil hides /home/horn/Repos/el/emacs/lisp/gnus/nnnil
~/Repos/el/gnus/lisp/nndir hides /home/horn/Repos/el/emacs/lisp/gnus/nndir
~/Repos/el/gnus/lisp/gnus-srvr hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-srvr
~/Repos/el/gnus/lisp/smime hides /home/horn/Repos/el/emacs/lisp/gnus/smime
~/Repos/el/gnus/lisp/nnvirtual hides /home/horn/Repos/el/emacs/lisp/gnus/nnvirtual
~/Repos/el/gnus/lisp/gnus-notifications hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-notifications
~/Repos/el/gnus/lisp/nnspool hides /home/horn/Repos/el/emacs/lisp/gnus/nnspool
~/Repos/el/gnus/lisp/gnus-group hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-group
~/Repos/el/gnus/lisp/gnus-bcklg hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-bcklg
~/Repos/el/gnus/lisp/gnus-util hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-util
~/Repos/el/gnus/lisp/gnus-sieve hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sieve
~/Repos/el/gnus/lisp/nndraft hides /home/horn/Repos/el/emacs/lisp/gnus/nndraft
~/Repos/el/gnus/lisp/nnagent hides /home/horn/Repos/el/emacs/lisp/gnus/nnagent
~/Repos/el/gnus/lisp/gnus-spec hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-spec
~/Repos/el/gnus/lisp/gnus-bookmark hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-bookmark
~/Repos/el/gnus/lisp/mml1991 hides /home/horn/Repos/el/emacs/lisp/gnus/mml1991
~/Repos/el/gnus/lisp/rfc2231 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2231
~/Repos/el/gnus/lisp/yenc hides /home/horn/Repos/el/emacs/lisp/gnus/yenc
~/Repos/el/gnus/lisp/gnus-undo hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-undo
~/Repos/el/gnus/lisp/ecomplete hides /home/horn/Repos/el/emacs/lisp/gnus/ecomplete
~/Repos/el/gnus/lisp/legacy-gnus-agent hides /home/horn/Repos/el/emacs/lisp/gnus/legacy-gnus-agent
~/Repos/el/gnus/lisp/utf7 hides /home/horn/Repos/el/emacs/lisp/gnus/utf7
~/Repos/el/gnus/lisp/rtree hides /home/horn/Repos/el/emacs/lisp/gnus/rtree
~/Repos/el/gnus/lisp/gnus-uu hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-uu
~/Repos/el/gnus/lisp/gnus-ml hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-ml
~/Repos/el/gnus/lisp/sieve hides /home/horn/Repos/el/emacs/lisp/gnus/sieve
~/Repos/el/gnus/lisp/gnus hides /home/horn/Repos/el/emacs/lisp/gnus/gnus
~/Repos/el/gnus/lisp/mml hides /home/horn/Repos/el/emacs/lisp/gnus/mml
~/Repos/el/gnus/lisp/message hides /home/horn/Repos/el/emacs/lisp/gnus/message
~/Repos/el/gnus/lisp/mml-smime hides /home/horn/Repos/el/emacs/lisp/gnus/mml-smime
~/Repos/el/gnus/lisp/gnus-eform hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-eform
~/Repos/el/gnus/lisp/gnus-agent hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-agent
~/Repos/el/gnus/lisp/gnus-logic hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-logic
~/Repos/el/gnus/lisp/mm-extern hides /home/horn/Repos/el/emacs/lisp/gnus/mm-extern
~/Repos/el/gnus/lisp/nndoc hides /home/horn/Repos/el/emacs/lisp/gnus/nndoc
~/Repos/el/gnus/lisp/sieve-manage hides /home/horn/Repos/el/emacs/lisp/gnus/sieve-manage
~/Repos/el/gnus/lisp/mm-decode hides /home/horn/Repos/el/emacs/lisp/gnus/mm-decode
~/Repos/el/gnus/lisp/starttls hides /home/horn/Repos/el/emacs/lisp/gnus/starttls
~/Repos/el/gnus/lisp/gnus-dired hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-dired
~/Repos/el/gnus/lisp/nnbabyl hides /home/horn/Repos/el/emacs/lisp/gnus/nnbabyl
~/Repos/el/gnus/lisp/nnmbox hides /home/horn/Repos/el/emacs/lisp/gnus/nnmbox
~/Repos/el/gnus/lisp/gnus-win hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-win
~/Repos/el/gnus/lisp/gnus-async hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-async
~/Repos/el/gnus/lisp/mm-url hides /home/horn/Repos/el/emacs/lisp/gnus/mm-url
~/Repos/el/gnus/lisp/gnus-html hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-html
~/Repos/el/gnus/lisp/gssapi hides /home/horn/Repos/el/emacs/lisp/gnus/gssapi
~/Repos/el/gnus/lisp/mml2015 hides /home/horn/Repos/el/emacs/lisp/gnus/mml2015
~/Repos/el/gnus/lisp/nnrss hides /home/horn/Repos/el/emacs/lisp/gnus/nnrss
~/Repos/el/gnus/lisp/gnus-mh hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-mh
~/Repos/el/gnus/lisp/gnus-sum hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sum
~/Repos/el/gnus/lisp/nnweb hides /home/horn/Repos/el/emacs/lisp/gnus/nnweb
~/Repos/el/gnus/lisp/mail-prsvr hides /home/horn/Repos/el/emacs/lisp/gnus/mail-prsvr
~/Repos/el/gnus/lisp/nnmairix hides /home/horn/Repos/el/emacs/lisp/gnus/nnmairix
~/Repos/el/gnus/lisp/plstore hides /home/horn/Repos/el/emacs/lisp/gnus/plstore
~/Repos/el/gnus/lisp/rfc2045 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2045
~/Repos/el/gnus/lisp/gnus-msg hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-msg
~/Repos/el/gnus/lisp/spam-wash hides /home/horn/Repos/el/emacs/lisp/gnus/spam-wash
~/Repos/el/gnus/lisp/gnus-score hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-score
~/Repos/el/gnus/lisp/mm-uu hides /home/horn/Repos/el/emacs/lisp/gnus/mm-uu
~/Repos/el/gnus/lisp/spam hides /home/horn/Repos/el/emacs/lisp/gnus/spam
~/Repos/el/gnus/lisp/mm-view hides /home/horn/Repos/el/emacs/lisp/gnus/mm-view
~/Repos/el/gnus/lisp/sieve-mode hides /home/horn/Repos/el/emacs/lisp/gnus/sieve-mode
~/Repos/el/gnus/lisp/html2text hides /home/horn/Repos/el/emacs/lisp/gnus/html2text
~/Repos/el/gnus/lisp/gnus-ems hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-ems
~/Repos/el/gnus/lisp/registry hides /home/horn/Repos/el/emacs/lisp/gnus/registry
~/Repos/el/gnus/lisp/auth-source hides /home/horn/Repos/el/emacs/lisp/gnus/auth-source
~/Repos/el/gnus/lisp/gravatar hides /home/horn/Repos/el/emacs/lisp/gnus/gravatar
~/Repos/el/gnus/lisp/flow-fill hides /home/horn/Repos/el/emacs/lisp/gnus/flow-fill
~/Repos/el/gnus/lisp/gmm-utils hides /home/horn/Repos/el/emacs/lisp/gnus/gmm-utils
~/Repos/el/gnus/lisp/mailcap hides /home/horn/Repos/el/emacs/lisp/gnus/mailcap
~/Repos/el/gnus/lisp/gnus-delay hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-delay
~/Repos/el/gnus/lisp/mm-bodies hides /home/horn/Repos/el/emacs/lisp/gnus/mm-bodies
~/Repos/el/gnus/lisp/mm-archive hides /home/horn/Repos/el/emacs/lisp/gnus/mm-archive
~/Repos/el/gnus/lisp/rfc1843 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc1843
~/Repos/el/gnus/lisp/gnus-kill hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-kill
~/Repos/el/gnus/lisp/qp hides /home/horn/Repos/el/emacs/lisp/gnus/qp
~/Repos/el/gnus/lisp/score-mode hides /home/horn/Repos/el/emacs/lisp/gnus/score-mode
~/Repos/el/gnus/lisp/gnus-topic hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-topic
~/Repos/el/gnus/lisp/gnus-cache hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cache
~/Repos/el/gnus/lisp/nnmail hides /home/horn/Repos/el/emacs/lisp/gnus/nnmail
~/Repos/el/gnus/lisp/gnus-vm hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-vm
~/Repos/el/gnus/lisp/gnus-sync hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sync
~/Repos/el/gnus/lisp/nnoo hides /home/horn/Repos/el/emacs/lisp/gnus/nnoo
~/Repos/el/gnus/lisp/nnregistry hides /home/horn/Repos/el/emacs/lisp/gnus/nnregistry
~/Repos/el/gnus/lisp/gnus-dup hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-dup
~/Repos/el/gnus/lisp/parse-time hides /home/horn/Repos/el/emacs/lisp/calendar/parse-time
~/Repos/el/gnus/lisp/time-date hides /home/horn/Repos/el/emacs/lisp/calendar/time-date

Features:
(shadow emacsbug sendmail edebug shr-color shr dom browse-url mm-archive
canlock texmathp preview prv-emacs auto-dictionary flyspell ispell
tex-buf reftex-dcr reftex-auc reftex reftex-vars font-latex latex
tex-style tex dbus tex-mode latexenc hippie-exp url-http url-gw url-auth
sort smiley gnus-cite gnus-async gnus-bcklg qp gnus-ml hl-line nndraft
nnmh rot13 utf-7 gnutls network-stream nsm starttls nnml nnnil
gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-cache
gnus-demon nntp spam spam-stat gnus-uu yenc gnus-msg gnus-gravatar
mail-extr gravatar gnus-topic nnir gnus-registry registry eieio-compat
eieio-base th-private magit-filenotify filenotify linum magit-blame
magit-stash magit-bisect magit-remote magit-commit magit-sequence magit
magit-apply magit-wip magit-log magit-diff smerge-mode magit-core
magit-process magit-popup magit-mode magit-git crm magit-section
magit-utils git-commit log-edit pcvs-util add-log with-editor
async-bytecomp async smex ido seq eieio-opt speedbar sb-image ezimage
dframe vc vc-dispatcher vc-git diff-mode colir color company-files
company-oddmuse company-keywords company-etags company-gtags
company-dabbrev-code company-dabbrev company-capf company-cmake
company-xcode company-clang company-semantic company-eclim
company-template company-css company-nxml company-bbdb company
stratego-mode greql-mode tg-mode generic preview-latex tex-site
auto-loads cider tramp-sh cider-debug cider-browse-ns cider-inspector
cider-mode cider-repl cider-eldoc cider-interaction spinner arc-mode
archive-mode cider-overlays cider-doc org-table org org-macro
org-footnote org-pcomplete org-list org-faces org-entities org-version
ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys
ob-comint ob-core ob-eval org-compat org-macs org-loaddefs cal-menu
calendar cal-loaddefs cider-test cider-stacktrace cider-client
nrepl-client tramp tramp-compat tramp-loaddefs trampver shell pcomplete
queue cider-util ewoc etags xref project dash clojure-mode paredit
aggressive-indent epa-file epa epg rdictcc google-contacts-message
google-contacts xml url-cache google-oauth google-contacts-gnus gnus-art
mm-uu mml2015 mm-view mml-smime smime dig gnus-sum gnus-group gnus-undo
gnus-start gnus-cloud nnimap nnmail mail-source tls utf7 netrc nnoo
parse-time gnus-spec gnus-int gnus-range gnus-win gnus gnus-ems
gnus-compat url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util url-parse auth-source password-cache
url-vars mailcap nnheader gnus-util dired-x em-term term ehelp esh-opt
esh-ext esh-util highlight-symbol thingatpt boxquote rect ecomplete
message rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr
mailabbrev mail-utils gmm-utils mailheader server yasnippet disp-table
noutline outline pdf-occur ibuf-ext ibuffer tablist tablist-filter
semantic/wisent/comp semantic/wisent semantic/wisent/wisent
semantic/util-modes semantic/util semantic semantic/tag semantic/lex
semantic/fw eieio byte-opt bytecomp byte-compile cconv eieio-core
mode-local find-func cedet dired pdf-isearch let-alist pdf-misc imenu
pdf-tools compile comint ansi-color cus-edit cus-start cus-load pdf-view
bookmark pp jka-compr pdf-cache pdf-info tq pdf-util format-spec
image-mode browse-kill-ring derived recentf tree-widget wid-edit
highlight-parentheses cl iedit iedit-lib cl-extra help-mode hydra lv
counsel swiper cap-words superword subword saveplace savehist paren ivy
delsel icomplete mb-depth ace-window easy-mmode cl-macs gv avy ring
smart-mode-line-respectful-theme smart-mode-line-light-theme cl-seq
smart-mode-line rich-minority rx bs elec-pair edmacro kmacro cl-loaddefs
cl-lib gnus-load subr-x pcase tsdh-light-theme finder-inf
memory-usage-autoloads advice info package easymenu epg-config time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core 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 charscript case-table epa-hook
jka-cmpr-hook help simple abbrev 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 1170270 111632)
 (symbols 48 61455 1)
 (miscs 40 14870 20407)
 (strings 32 194271 40957)
 (string-bytes 1 6508128)
 (vectors 16 64888)
 (vector-slots 8 2064099 69203)
 (floats 8 1035 761)
 (intervals 56 47099 6809)
 (buffers 976 41)
 (heap 1024 110440 13253))

bug#21396: 25.0.50; read-key's prompt is not visible

[Stefan Monnier]

>   1. emacs -Q
>   2. eval (read-key "Gimme Key: ") in *scratch*
> the key will be read but the prompt is not shown in the minibuffer
[...]
> commit 5dc644a6b01e2cf950ff617ab15be4bf1917c38c
> Author: Stefan Monnier <monnier@iro.umontreal.ca>
> Date:   Tue Sep 1 21:14:18 2015 -0400
>     Generalize the prefix-command machinery of C-u

Hmm... I'll look into it.

> Git bisect says the commit introducing this problem is Stefan whom I
> added to the Cc.

Thanks for bisecting.  Putting me in the Cc was more trouble than
anything else: it means I get *your* message instead of the one from
Debbugs, so I don't get to know the bug-number and a naive reply would
end up creating a new bug-nb!
[ Tho, IIRC Glenn(?) added some Message-ID matching to Debbugs to try
  and catch those cases.  So maybe it's not that bad.  ]

Better either not put the person in the Cc (in case you expect/know the
person subscribes to bug-gnu-emacs), or else use "X-Debbugs-Cc:" which
instructs Debbugs to add the person to the Cc of the messages it sends out.

Yes, it's an annoying subtlety,


        Stefan

bug#21396: 25.0.50; read-key's prompt is not visible

[Tassilo Horn]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>   1. emacs -Q
>>   2. eval (read-key "Gimme Key: ") in *scratch*
>> the key will be read but the prompt is not shown in the minibuffer
> [...]
>> commit 5dc644a6b01e2cf950ff617ab15be4bf1917c38c
>> Author: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date:   Tue Sep 1 21:14:18 2015 -0400
>>     Generalize the prefix-command machinery of C-u
>
> Hmm... I'll look into it.

Great, thanks.  Meanwhile others have seen that issue, too.  See the
thread on emacs-devel.

>> Git bisect says the commit introducing this problem is Stefan whom I
>> added to the Cc.
>
> Thanks for bisecting.  Putting me in the Cc was more trouble than
> anything else: it means I get *your* message instead of the one from
> Debbugs, so I don't get to know the bug-number and a naive reply would
> end up creating a new bug-nb!
> [ Tho, IIRC Glenn(?) added some Message-ID matching to Debbugs to try
>   and catch those cases.  So maybe it's not that bad.  ]
>
> Better either not put the person in the Cc (in case you expect/know the
> person subscribes to bug-gnu-emacs), or else use "X-Debbugs-Cc:" which
> instructs Debbugs to add the person to the Cc of the messages it sends out.

Oh, thanks for the pointer.  Do you think it would be a good idea to
remap `message-goto-cc' to a similar function which goes to (and thereby
creates) the X-Debbugs-Cc header?  I think it's generally a good idea to
notify the person who introduced some problem, and Cc-ing seems to be
the obvious way to do that.

Bye,
Tassilo

bug#21396: 25.0.50; read-key's prompt is not visible

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Thu, 03 Sep 2015 19:50:23 +0200
> Cc: 21396@debbugs.gnu.org
> 
> > Putting me in the Cc was more trouble than
> > anything else: it means I get *your* message instead of the one from
> > Debbugs, so I don't get to know the bug-number and a naive reply would
> > end up creating a new bug-nb!
> > [ Tho, IIRC Glenn(?) added some Message-ID matching to Debbugs to try
> >   and catch those cases.  So maybe it's not that bad.  ]
> >
> > Better either not put the person in the Cc (in case you expect/know the
> > person subscribes to bug-gnu-emacs), or else use "X-Debbugs-Cc:" which
> > instructs Debbugs to add the person to the Cc of the messages it sends out.
> 
> Oh, thanks for the pointer.  Do you think it would be a good idea to
> remap `message-goto-cc' to a similar function which goes to (and thereby
> creates) the X-Debbugs-Cc header?  I think it's generally a good idea to
> notify the person who introduced some problem, and Cc-ing seems to be
> the obvious way to do that.

Please don't bother about this.  The problem Stefan was worried about
doesn't exist, AFAIK.

bug#21396: 25.0.50; read-key's prompt is not visible

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Putting me in the Cc was more trouble than
>> > anything else: it means I get *your* message instead of the one from
>> > Debbugs, so I don't get to know the bug-number and a naive reply would
>> > end up creating a new bug-nb!
>> > [ Tho, IIRC Glenn(?) added some Message-ID matching to Debbugs to try
>> >   and catch those cases.  So maybe it's not that bad.  ]
>> >
>> > Better either not put the person in the Cc (in case you expect/know the
>> > person subscribes to bug-gnu-emacs), or else use "X-Debbugs-Cc:" which
>> > instructs Debbugs to add the person to the Cc of the messages it sends out.
>> 
>> Oh, thanks for the pointer.  Do you think it would be a good idea to
>> remap `message-goto-cc' to a similar function which goes to (and thereby
>> creates) the X-Debbugs-Cc header?  I think it's generally a good idea to
>> notify the person who introduced some problem, and Cc-ing seems to be
>> the obvious way to do that.
>
> Please don't bother about this.  The problem Stefan was worried about
> doesn't exist, AFAIK.

Maybe the double-bug issue doesn't exist but it's a fact that the
Cc-receiver doesn't get to know the bug number automatically, and that's
really annoying.  The X-Debbugs-Cc would solve that, and the following
patch is easy enough, no?

--8<---------------cut here---------------start------------->8---
diff --git a/lisp/mail/emacsbug.el b/lisp/mail/emacsbug.el
index f54893f..82d8e74 100644
--- a/lisp/mail/emacsbug.el
+++ b/lisp/mail/emacsbug.el
@@ -143,6 +143,12 @@ This requires either the OS X \"open\" command, or the freedesktop
 (defvar message-send-mail-function)
 (defvar message-sendmail-envelope-from)
 
+(defun report-emacs-bug-message-goto-x-debbugs-cc ()
+  "Move point to the X-Debbugs-Cc header."
+  (interactive)
+  (push-mark)
+  (message-position-on-field "X-Debbugs-Cc" "To"))
+
 ;;;###autoload
 (defun report-emacs-bug (topic &optional unused)
   "Report a bug in GNU Emacs.
@@ -319,6 +325,8 @@ usually do not have translators for other languages.\n\n")))
     ;; This is so the user has to type something in order to send easily.
     (use-local-map (nconc (make-sparse-keymap) (current-local-map)))
     (define-key (current-local-map) "\C-c\C-i" 'info-emacs-bug)
+    (define-key (current-local-map) [remap message-goto-cc]
+      #'report-emacs-bug-message-goto-x-debbugs-cc)
     (if can-insert-mail
 	(define-key (current-local-map) "\C-c\M-i"
 	  'report-emacs-bug-insert-to-mailer))
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo

bug#21396: 25.0.50; read-key's prompt is not visible

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Thu, 03 Sep 2015 19:50:23 +0200
> Cc: 21396@debbugs.gnu.org
> 
> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> 
> >>   1. emacs -Q
> >>   2. eval (read-key "Gimme Key: ") in *scratch*
> >> the key will be read but the prompt is not shown in the minibuffer
> > [...]
> >> commit 5dc644a6b01e2cf950ff617ab15be4bf1917c38c
> >> Author: Stefan Monnier <monnier@iro.umontreal.ca>
> >> Date:   Tue Sep 1 21:14:18 2015 -0400
> >>     Generalize the prefix-command machinery of C-u
> >
> > Hmm... I'll look into it.
> 
> Great, thanks.  Meanwhile others have seen that issue, too.  See the
> thread on emacs-devel.

I really hope Stefan will NOT fix this.  It's IMO the wrong way of
dealing with such issues.

If typing yes<RET> is too much in some situations, and just y is
enough, we should not call yes-or-no-p in those situations.  AFAIU,
the only reason to call the latter is when the question is about
some serious matter, so we want to avoid the possibility of mistakenly
pressing just one (wrong) key.  So if some of these situations aren't
so grave, let's call y-or-n-p instead.

And if there are people who still want to press y or n, even when they
might err and pay dearly for their mistakes, then we could have an
option to have yes-or-no-p call y-or-n-p instead.

But using a defalias here is a kludge; asking Emacs maintenance to
support such kludges means extra overhead and tricky code for no good
reason.  I think we should simply say no to such requests.  We have
more than enough work on our hands already, no need for gratuitous
additions, thank you.

bug#21396: 25.0.50; read-key's prompt is not visible

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> >>   1. emacs -Q
>> >>   2. eval (read-key "Gimme Key: ") in *scratch*
>> >> the key will be read but the prompt is not shown in the minibuffer
>> > [...]
>> >> commit 5dc644a6b01e2cf950ff617ab15be4bf1917c38c
>> >> Author: Stefan Monnier <monnier@iro.umontreal.ca>
>> >> Date:   Tue Sep 1 21:14:18 2015 -0400
>> >>     Generalize the prefix-command machinery of C-u
>> >
>> > Hmm... I'll look into it.
>> 
>> Great, thanks.  Meanwhile others have seen that issue, too.  See the
>> thread on emacs-devel.
>
> I really hope Stefan will NOT fix this.  It's IMO the wrong way of
> dealing with such issues.
>
> If typing yes<RET> is too much in some situations, and just y is
> enough, we should not call yes-or-no-p in those situations.  AFAIU,
> the only reason to call the latter is when the question is about
> some serious matter, so we want to avoid the possibility of mistakenly
> pressing just one (wrong) key.  So if some of these situations aren't
> so grave, let's call y-or-n-p instead.
>
> And if there are people who still want to press y or n, even when they
> might err and pay dearly for their mistakes, then we could have an
> option to have yes-or-no-p call y-or-n-p instead.
>
> But using a defalias here is a kludge; asking Emacs maintenance to
> support such kludges means extra overhead and tricky code for no good
> reason.  I think we should simply say no to such requests.  We have
> more than enough work on our hands already, no need for gratuitous
> additions, thank you.

I'm guilty of having (fset 'yes-or-no-p 'y-or-n-p) in my ~/.emacs, too,
but what does this have to do with this issue?  The problem is that no
prompt of any `read-key' is visible, `y-or-n-p' is just the most
prominent place where this pops up.

Bye,
Tassilo

bug#21396: 25.0.50; read-key's prompt is not visible

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: monnier@IRO.UMontreal.CA,  21396@debbugs.gnu.org
> Date: Thu, 03 Sep 2015 20:42:05 +0200
> 
> I'm guilty of having (fset 'yes-or-no-p 'y-or-n-p) in my ~/.emacs, too,
> but what does this have to do with this issue?

If you don't expect that fset to continue working, nothing.

bug#21396: 25.0.50; read-key's prompt is not visible

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> I'm guilty of having (fset 'yes-or-no-p 'y-or-n-p) in my ~/.emacs,
>> too, but what does this have to do with this issue?
>
> If you don't expect that fset to continue working, nothing.

I expect that I can alias/fset, add-function :override, or redefine any
emacs function with a semantically equivalent function.  Redefining
functions is the worst of all customization possibilities, of course,
but what is the reason that the above cannot be expected to continue
working?

Bye,
Tassilo

bug#21396: 25.0.50; read-key's prompt is not visible

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: monnier@IRO.UMontreal.CA,  21396@debbugs.gnu.org
> Date: Fri, 04 Sep 2015 10:04:07 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I'm guilty of having (fset 'yes-or-no-p 'y-or-n-p) in my ~/.emacs,
> >> too, but what does this have to do with this issue?
> >
> > If you don't expect that fset to continue working, nothing.
> 
> I expect that I can alias/fset, add-function :override, or redefine any
> emacs function with a semantically equivalent function.

That's not the expectation I was arguing against.

> Redefining functions is the worst of all customization
> possibilities, of course, but what is the reason that the above
> cannot be expected to continue working?

Supporting this is maintenance burden that we shouldn't be expected to
sustain.  When I'm working on extending a function, how am I supposed
to know that it's defaliased by someone?  If I need to extend the
function to make it incompatible with these tricks, it's a legitimate
development that shouldn't be avoided for fear of breaking someone's
fset.

If people keep using such "customizations", it's a clear sign that
some defcustom or another similar facility is missing, or that the
original code needs improvement.  So when such situations happen,
let's report them to the bug tracker, and let's handle them as we
usually do.

bug#21396: 25.0.50; read-key's prompt is not visible

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> Redefining functions is the worst of all customization possibilities,
>> of course, but what is the reason that the above cannot be expected
>> to continue working?
>
> Supporting this is maintenance burden that we shouldn't be expected to
> sustain.  When I'm working on extending a function, how am I supposed
> to know that it's defaliased by someone?  If I need to extend the
> function to make it incompatible with these tricks, it's a legitimate
> development that shouldn't be avoided for fear of breaking someone's
> fset.

You cannot and should not!  I am fully aware that I won't benefit from
your extensions to `yes-or-no-p' when I do the above fset.  But for a
function with no side-effects and such a sharp contract as "ask the user
for confirmation and return non-nil if she's fine", I don't see a
practical problem anyway.

Again, the current issue was that `read-key' (and therefore `y-or-n-p')
didn't show its prompt anymore.  That was a real regression, not a
change which had the side-effect of breaking the fset "trick."  Stefan
fixed it not in order to restore compatibility with tricks but because
`read-key' didn't satisfy the contract of its docstring anymore.

> If people keep using such "customizations", it's a clear sign that
> some defcustom or another similar facility is missing, or that the
> original code needs improvement.  So when such situations happen,
> let's report them to the bug tracker, and let's handle them as we
> usually do.

I'm all in favour of having a `user-confirmation-function', and/or a
more sensible use of `yes-or-no-p'/`y-or-n-p' inside emacs (use the
former only when the consequences of a wrong answer are really severe),
or something else.  The problem is that it'll take long until all emacs
packages follow suit, and frequently having to type 2 or 3 chars + RET
instead of just one is something which is cumbersome enough to me and
many others as it seems.

Bye,
Tassilo

bug#21396: 25.0.50; read-key's prompt is not visible

[Stefan Monnier]

> I really hope Stefan will NOT fix this.  It's IMO the wrong way of
> dealing with such issues.

I'm not sure what "this" was, but FWIW the recently introduced problem
affected read-key-sequence in general, so it had to be fixed.


        Stefan

bug#21396: 25.0.50; read-key's prompt is not visible

[Dmitry Gutov]

On 09/03/2015 11:10 PM, Stefan Monnier wrote:

> I'm not sure what "this" was, but FWIW the recently introduced problem
> affected read-key-sequence in general, so it had to be fixed.

Thanks, Stefan.

bug#21396: 25.0.50; read-key's prompt is not visible

[Drew Adams]

> If typing yes<RET> is too much in some situations, and just y is
> enough, we should not call yes-or-no-p in those situations. AFAIU,
> the only reason to call the latter is when the question is about
> some serious matter, so we want to avoid the possibility of mistakenly
> pressing just one (wrong) key.  So if some of these situations aren't
> so grave, let's call y-or-n-p instead.

Agreed.  But that's a decision for Emacs, and it is a judgment
call to try to fit what is generally appropriate in that context.

That's different from what a given user might want.

So yes, Emacs should pick the right function to use.
And yes, users should be able to choose something else,
if they really want to.  (Personally, I stick with what
Emacs decides, here.)

> And if there are people who still want to press y or n, even when they
> might err and pay dearly for their mistakes, then we could have an
> option to have yes-or-no-p call y-or-n-p instead.

Yes.

> But using a defalias here is a kludge; asking Emacs maintenance to
> support such kludges means extra overhead and tricky code for no good
> reason.  I think we should simply say no to such requests.  We have
> more than enough work on our hands already, no need for gratuitous
> additions, thank you.

I agree that a user option is more appropriate than defaliasing.

bug#21396: closed (Re: bug#21403: 25.0.50; invisible y-or-n-p prompt)

[Tassilo Horn]

Yes, works!

bug#21403: 25.0.50; invisible y-or-n-p prompt

[Mark Oteiza]

On 03/09/15 at 04:03pm, Stefan Monnier wrote:
> > Somewhere between g5c0fb39 and gfa5a9c7, evaluating the following
> > results in an empty prompt:
> 
> >   (y-or-n-p "foo? ")
> 
> > I'm guessing g5dc644a, as it touches the minibuffer
> 
> I think it's fixed now

Not quite:

  (setq echo-keystrokes 0.1)
  (y-or-n-p "foo? ")

In the minibuffer all I see is my echoed keystrokes (in this case `C-x
C-e-` from evalling the form in *scratch*). This happens erratically.
Seems to happen more consistently the smaller `echo-keystrokes` is.

bug#21403: 25.0.50; invisible y-or-n-p prompt

[Stefan Monnier]

>   (setq echo-keystrokes 0.1)
>   (y-or-n-p "foo? ")

> In the minibuffer all I see is my echoed keystrokes (in this case `C-x
> C-e-` from evalling the form in *scratch*). This happens erratically.
> Seems to happen more consistently the smaller `echo-keystrokes` is.

Hmm... this is a different problem.  I'll take a look at it,


        Stefan

bug#21403: 25.0.50; invisible y-or-n-p prompt

[Stefan Monnier]

>   (setq echo-keystrokes 0.1)
>   (y-or-n-p "foo? ")

Should be fixed now,


        Stefan

bug#21403: 25.0.50; invisible y-or-n-p prompt

[Chris Feng]

I can produce what is reported in Message #27 predictably with the
default `echo-keystrokes' value (1). 944d77f0 also results in other
problems which seem to be closely related to this one.