unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#19474: 24.4; icomplete fails to insert character with C-x 8
@ 2014-12-30 18:54 Eric Hanchrow
  2016-01-13  4:33 ` Alexis
  0 siblings, 1 reply; 6+ messages in thread
From: Eric Hanchrow @ 2014-12-30 18:54 UTC (permalink / raw)
  To: 19474

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

* I started emacs with emacs -Q -nw
* I turned on icomplete by typing ESC x i c o m p l e t e RET
* I attempted to insert my favorite character, "PILE OF POO", by typing C-x
8 RET p i l e RET
* I saw an error in the echo area: read-char-by-name: Invalid character
* I did not see my beloved character in the current buffer



In GNU Emacs 24.4.1 (i686-pc-linux-gnu)
 of 2014-10-22 on ip-10-172-239-100
Repository revision: rgm@gnu.org-20141020192115-57qyk6ygie4c15vx
System Description: Ubuntu 14.04.1 LTS

Configured using:
 `configure --without-x'

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  icomplete-mode: t
  tooltip-mode: t
  electric-indent-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
  transient-mark-mode: t

Recent input:
ESC [ > 8 3 ; 4 0 1 0 0 ; 0 c ESC x i c o m p l e t
e RET C-x 8 RET p i l e RET C-h l ESC x r e p o r t
- e m a c s - RET

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Source file `/mnt/emacs/lisp/cus-start.el' newer than byte-compiled file
read-char-by-name: Invalid character
Type C-x 1 to delete the help window.
Source file `/mnt/emacs/lisp/mail/emacsbug.el' newer than byte-compiled file

Load-path shadows:
/mnt/emacs/lisp/emulation/vip hides /mnt/emacs/lisp/obsolete/vip
/mnt/emacs/lisp/emulation/tpu-edt hides /mnt/emacs/lisp/obsolete/tpu-edt
/mnt/emacs/lisp/emulation/ws-mode hides /mnt/emacs/lisp/obsolete/ws-mode
/mnt/emacs/lisp/emulation/tpu-mapper hides
/mnt/emacs/lisp/obsolete/tpu-mapper
/mnt/emacs/lisp/emulation/crisp hides /mnt/emacs/lisp/obsolete/crisp
/mnt/emacs/lisp/progmodes/cc-compat hides /mnt/emacs/lisp/obsolete/cc-compat
/mnt/emacs/lisp/emulation/vi hides /mnt/emacs/lisp/obsolete/vi
/mnt/emacs/lisp/emulation/tpu-extras hides
/mnt/emacs/lisp/obsolete/tpu-extras

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils help-mode easymenu mule-util
iso-transl cus-start cus-load icomplete xterm time-date tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
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
minibuffer 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 make-network-process
dbusbind gfilenotify multi-tty emacs)

Memory information:
((conses 8 179617 4242)
 (symbols 24 36393 0)
 (miscs 20 37 136)
 (strings 16 77064 5781)
 (string-bytes 1 1408331)
 (vectors 8 8547)
 (vector-slots 4 409862 15748)
 (floats 8 60 609)
 (intervals 28 165 25)
 (buffers 512 12)
 (heap 1024 14171 1298))

[-- Attachment #2: Type: text/html, Size: 4360 bytes --]

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

* bug#19474: 24.4; icomplete fails to insert character with C-x 8
  2014-12-30 18:54 bug#19474: 24.4; icomplete fails to insert character with C-x 8 Eric Hanchrow
@ 2016-01-13  4:33 ` Alexis
  2016-01-13  5:39   ` Drew Adams
  0 siblings, 1 reply; 6+ messages in thread
From: Alexis @ 2016-01-13  4:33 UTC (permalink / raw)
  To: Eric Hanchrow; +Cc: 19474

Eric Hanchrow <eric.hanchrow@gmail.com> writes: 
 
> * I started emacs with emacs -Q -nw * I turned on icomplete by 
> typing ESC x i c o m p l e t e RET * I attempted to insert my 
> favorite character, "PILE OF POO", by typing C-x 8 RET p i l e 
> RET  * I saw an error in the echo area: read-char-by-name: 
> Invalid character * I did not see my beloved character in the 
> current buffer 

It seems to me that the issue here is that icomplete expects one 
to accept completions via C-j 
(`minibuffer-force-complete-and-exit`) rather than RET (which is 
bound to `minibuffer-exit`). i myself find this behaviour 
counterintuitive, and would prefer that RET also be bound to 
`minibuffer-force-complete-and-exit`, since i would still be able 
to exit the minibuffer via C-g. i wonder if there are people 
relying on RET being bound to `minibuffer-exit`?





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

* bug#19474: 24.4; icomplete fails to insert character with C-x 8
  2016-01-13  4:33 ` Alexis
@ 2016-01-13  5:39   ` Drew Adams
  2016-01-13  7:19     ` Alexis
  0 siblings, 1 reply; 6+ messages in thread
From: Drew Adams @ 2016-01-13  5:39 UTC (permalink / raw)
  To: Alexis, Eric Hanchrow; +Cc: 19474

> It seems to me that the issue here is that icomplete expects one
> to accept completions via C-j (`minibuffer-force-complete-and-exit`)
> rather than RET (which is bound to `minibuffer-exit`).

Yes, exactly.

> i myself find this behaviour
> counterintuitive, and would prefer that RET also be bound to
> `minibuffer-force-complete-and-exit`, since i would still be able
> to exit the minibuffer via C-g. i wonder if there are people
> relying on RET being bound to `minibuffer-exit`?

Yes, there are.  Icomplete's C-j does not have the same
behavior as RET.  If Icomplete treated RET the way it
treats C-j then that would mean that you could never input
anything that matched a completion candidate, without
choosing that match.

IOW, it would remove the possibility of lax completion.

You could not, for example, use `C-x b' to create a new
buffer `foo' if there were already a buffer `foobar' -
typing `foo RET' would just choose `foobar'.

IOW, even in Icomplete mode, RET is used normally in the
minibuffer: it accepts the text typed so far or, if a
match is required in order to exit and there is only one
possible match, it accepts that match.

C-j for Icomplete mode is used not to input what you have
typed so far but to input the first of the available matches.
IOW, it completes and then exits (similar to what
`minibuffer-complete-and-exit' does).

Completion for `C-x 8 RET' is lax - a match is not required.

This is because you can enter something other than a match
of one of the char names - you can enter a code point.
E.g., you can type `1F4A9 RET' to get your pile of poo.

The code point here is not a _match_ for the char name
(and only char names are completion candidates - there is
no _completion_ against code points).  The code point is
simply another acceptable input, and it has the same effect
(inserts the same char).

---

FWIW, if you were to do this in Icicles, with the default
settings, you _could_ use RET, for this reason:

With the default settings your input for `C-x 8 RET' can
match any combination of parts of a 3-part multi-completion:
char name, code point, and the char itself.  (You can
complete the name or the code point, or both.  And you can
alternatively type the code point or the char to see what
the name is.)

And with the default settings, if your input matches only
a char name or a code point, and if there is only one match,
then that char is inserted.  (Again, you can complete
against the name, the code point, or the char itself, or
any combination of these parts.)

(If option `icicle-read-char-by-name-multi-completion-flag'
is nil, which is not the default value, then the behavior
is similar to vanilla Emacs,except that you get Icicles
matching against the char name.)





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

* bug#19474: 24.4; icomplete fails to insert character with C-x 8
  2016-01-13  5:39   ` Drew Adams
@ 2016-01-13  7:19     ` Alexis
  2016-01-13 15:17       ` Drew Adams
  0 siblings, 1 reply; 6+ messages in thread
From: Alexis @ 2016-01-13  7:19 UTC (permalink / raw)
  To: Drew Adams; +Cc: 19474, Eric Hanchrow


Drew Adams <drew.adams@oracle.com> writes:

> Yes, there are.  Icomplete's C-j does not have the same behavior 
> as RET.  If Icomplete treated RET the way it treats C-j then 
> that would mean that you could never input anything that matched 
> a completion candidate, without choosing that match.
>
> IOW, it would remove the possibility of lax completion.

Okay, so then this bug report should be closed, since things are 
"working as designed". Does anyone have any objections to closing?





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

* bug#19474: 24.4; icomplete fails to insert character with C-x 8
  2016-01-13  7:19     ` Alexis
@ 2016-01-13 15:17       ` Drew Adams
  2016-01-22  7:12         ` Alexis
  0 siblings, 1 reply; 6+ messages in thread
From: Drew Adams @ 2016-01-13 15:17 UTC (permalink / raw)
  To: Alexis; +Cc: 19474, Eric Hanchrow

> > Yes, there are.  Icomplete's C-j does not have the same behavior
> > as RET.  If Icomplete treated RET the way it treats C-j then
> > that would mean that you could never input anything that matched
> > a completion candidate, without choosing that match.
> >
> > IOW, it would remove the possibility of lax completion.
> 
> Okay, so then this bug report should be closed, since things are
> "working as designed". Does anyone have any objections to closing?

Yes, IMO it should be closed.  But I don't decide these things.





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

* bug#19474: 24.4; icomplete fails to insert character with C-x 8
  2016-01-13 15:17       ` Drew Adams
@ 2016-01-22  7:12         ` Alexis
  0 siblings, 0 replies; 6+ messages in thread
From: Alexis @ 2016-01-22  7:12 UTC (permalink / raw)
  To: Drew Adams; +Cc: 19474-done, Eric Hanchrow


Drew Adams <drew.adams@oracle.com> writes:

>> > Yes, there are.  Icomplete's C-j does not have the same 
>> > behavior as RET.  If Icomplete treated RET the way it treats 
>> > C-j then that would mean that you could never input anything 
>> > that matched a completion candidate, without choosing that 
>> > match.
>> >
>> > IOW, it would remove the possibility of lax completion.
>> 
>> Okay, so then this bug report should be closed, since things 
>> are "working as designed". Does anyone have any objections to 
>> closing?
>
> Yes, IMO it should be closed.  But I don't decide these things.

A week has passed and there's been no objection, so i'm tagging 
this as 'notabug' and closing.


Alexis.





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

end of thread, other threads:[~2016-01-22  7:12 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-30 18:54 bug#19474: 24.4; icomplete fails to insert character with C-x 8 Eric Hanchrow
2016-01-13  4:33 ` Alexis
2016-01-13  5:39   ` Drew Adams
2016-01-13  7:19     ` Alexis
2016-01-13 15:17       ` Drew Adams
2016-01-22  7:12         ` Alexis

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).