Re: completing-read case problem

Re: completing-read case problem

[Richard Stallman]

    > It is unreasonable to use a case-sensitive predicate with
    > completion-ignore-case non-nil.

    But it can be inconvenient if one has to avoid using a case-sensitive
    predicate.

Not very much.  You just have to downcase the string first.

It would be inconvenient to change Emacs to remove this requirement,
and I don't have time to even think about it.

    You get a buffer "*Customize Group: Mouse*" showing no members of the
    (non-empty) group 'mouse -- which is not what is intended.  This
    problem appears because of completing-read with non-nil
    completion-ignore-case in customize-group.  completing-read returns
    "Mouse", which is not the symbol-name of group 'mouse.

There are two ways to fix this:

1. Decide that case is significant in custom group names,
and read them case-sensitively.

2. Decide that case is not significant in custom group names,
and that they should all be lower case.

Either one seems ok to me.
What do others think?

Re: completing-read case problem

[Lennart Borgman]

Case insensitive please! (I am using ms windows so I am biased by my habits
in this case, but I would believe that a lot of users like case insensitive
handling. Compare with mail-addresses for example, they are since long not
case sensitive.)

- Lennart


----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>
To: "Markus Rost" <rost@ias.edu>
Cc: <emacs-devel@gnu.org>
Sent: Monday, November 15, 2004 3:00 PM
Subject: Re: completing-read case problem


>     > It is unreasonable to use a case-sensitive predicate with
>     > completion-ignore-case non-nil.
>
>     But it can be inconvenient if one has to avoid using a case-sensitive
>     predicate.
>
> Not very much.  You just have to downcase the string first.
>
> It would be inconvenient to change Emacs to remove this requirement,
> and I don't have time to even think about it.
>
>     You get a buffer "*Customize Group: Mouse*" showing no members of the
>     (non-empty) group 'mouse -- which is not what is intended.  This
>     problem appears because of completing-read with non-nil
>     completion-ignore-case in customize-group.  completing-read returns
>     "Mouse", which is not the symbol-name of group 'mouse.
>
> There are two ways to fix this:
>
> 1. Decide that case is significant in custom group names,
> and read them case-sensitively.
>
> 2. Decide that case is not significant in custom group names,
> and that they should all be lower case.
>
> Either one seems ok to me.
> What do others think?
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>

Re: completing-read case problem

[Kevin Rodgers]

[Please don't top-post.]

Lennart Borgman wrote:
 > Case insensitive please! (I am using ms windows so I am biased by my
 > habits in this case, but I would believe that a lot of users like case
 > insensitive handling. Compare with mail-addresses for example, they
 > are since long not case sensitive.)

Internet mail addresses are defined by IETC RFCs, and have always been
case insensitive.  They have as much to do with the matter at hand as
whether or not file names in different file systems are case sensitive:
nothing.

Customization group names are Emacs Lisp symbols, which are by
definition case sensitive.

-- 
Kevin Rodgers

Re: completing-read case problem

[Markus Rost]

[I suggest to keep this thread on emacs-devel.]

> > (let ((completion-ignore-case t))
> >   (completing-read "Give me ABC: "
> > 		   (list "abc")
> > 		   (lambda (string)
> > 		     (string= string "abc"))
> > 		   t
> > 		   ))
> 
> > With input "ABC" it returns "ABC", which I think is incorrect -- at
> > least it may lead to surprises in programs which assume that the
> > output of completing-read is always an exact member of TABLE,
> > restricted by PREDICATE.
> 
> Yes, we pretty much agreed to that in an earlier discussion this year.
> Nobody has stepped forward with a patch for it, tho.
> 

I guess you mean the discussion started with
<URL:http://lists.gnu.org/archive/html/emacs-devel/2003-12/msg00459.html>.

I think it would be definitely better to fix completing-read than to
make changes elsewhere in code using completing-read, but I can't do
that (I am not a C programmer).

The mentioned problem with "M-x customize-group Mouse" is rather
minor, and one could just leave it as it is.

One possibility for a change would be the patch below, but I don't
like it, and it would have to be applied also to
customize-group-other-window and perhaps also at other places in
cus-edit.el.

===Buffer *vc-diff*=========================================
*** cus-edit.el	02 Nov 2004 09:17:44 -0500	1.196
--- cus-edit.el	15 Nov 2004 14:32:55 -0500	
***************
*** 866,871 ****
--- 866,875 ----
  					  (or (get symbol 'custom-loads)
  					      (get symbol 'custom-group)))
  					t))))
+   ;; If we got the wrong case, give it another try.
+   (unless (or (get (intern group) 'custom-loads)
+ 	      (get (intern group) 'custom-group))
+     (setq group (downcase group)))
    (when (stringp group)
      (if (string-equal "" group)
  	(setq group 'emacs)
============================================================

Re: completing-read case problem

[Simon Josefsson]

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> Lennart Borgman wrote:
>> Case insensitive please! (I am using ms windows so I am biased by my
>> habits in this case, but I would believe that a lot of users like case
>> insensitive handling. Compare with mail-addresses for example, they
>> are since long not case sensitive.)
>
> Internet mail addresses are defined by IETC RFCs, and have always been
> case insensitive.  They have as much to do with the matter at hand as
> whether or not file names in different file systems are case sensitive:
> nothing.

If I recall the RFCs correctly, the right hand side of e-mail
addresses are indeed case insensitive, but whether the left hand side
of e-mail addresses are case sensitive or not, is up to each domain.
For example, foo@bar.com does not necessarily equal FOO@bar.com.  This
means that, in general, case must be preserved.

What is relevant to this discussion is, I guess, that deciding between
case sensitive and case insensitive is a trade-off, and there is no
clear answer.

Re: completing-read case problem

[Stefan Monnier]

How 'bout the patch below, which is a free adaptation from my elisp code

  ...
  (cond
   ((or (= (field-beginning) (field-end))
	(test-completion (field-string)
			 minibuffer-completion-table
			 minibuffer-completion-predicate))
    (when completion-ignore-case
      ;; Fixup case of the field, if necessary.
      (let* ((string (field-string))
	     (compl (try-completion string
				    minibuffer-completion-table
				    minibuffer-completion-predicate)))
	(if (and (stringp string)
		 ;; If it weren't for this piece of paranoia, I'd replace
		 ;; the whole thing with a call to complete-do-completion.
		 (= (length string) (length compl)))
	    (let ((beg (field-beginning))
		  (end (field-end)))
	      (goto-char end)
	      (insert compl)
	      (delete-region beg end)))))
    (exit-minibuffer))
   ...


        Stefan


--- minibuf.c	15 nov 2004 10:41:18 -0500	1.273
+++ minibuf.c	15 nov 2004 16:57:59 -0500	
@@ -2076,10 +2076,27 @@
   if (XINT (Fminibuffer_prompt_end ()) == ZV)
     goto exit;
 
-  if (!NILP (Ftest_completion (Fminibuffer_contents (),
+  if (!NILP (Ftest_completion (val = Fminibuffer_contents (),
 			       Vminibuffer_completion_table,
 			       Vminibuffer_completion_predicate)))
+    {
+      if (completion_ignore_case)
+	{ /* Fixup case of the field, if necessary. */
+	  Lisp_Object compl
+	    = Ftry_completion (val,
+			       Vminibuffer_completion_table,
+			       Vminibuffer_completion_predicate);
+	  if (STRINGP (compl)
+	      /* If it weren't for this piece of paranoia, I'd replace
+		 the whole thing with a call to do_completion. */
+	      && EQ (Flength (val), Flength (compl)))
+	    {
+	      del_range (XINT (Fminibuffer_prompt_end ()), ZV);
+	      Finsert (1, &compl);
+	    }
+	}
     goto exit;
+    }
 
   /* Call do_completion, but ignore errors.  */
   SET_PT (ZV);

Re: completing-read case problem

[Luc Teirlinck]

Markus Rost wrote (in response to Stefan Monnier):

   > > With input "ABC" it returns "ABC", which I think is incorrect -- at
   > > least it may lead to surprises in programs which assume that the
   > > output of completing-read is always an exact member of TABLE,
   > > restricted by PREDICATE.
   > 
   > Yes, we pretty much agreed to that in an earlier discussion this year.
   > Nobody has stepped forward with a patch for it, tho.
   > 

   I guess you mean the discussion started with
   <URL:http://lists.gnu.org/archive/html/emacs-devel/2003-12/msg00459.html>.

I do not know whether that was what Stefan was referring to, but if I
remember correctly, that thread was concerned with certain bugs
concerning case that occurred for hash tables and obarrays, but not
for lists.

The bug there was that completion-ignore-case was ignored for hash
tables and obarrays.  It concerned finding a match when there was
none and not finding one when there was one.  I did install a fix for
that problem.

I did not follow this thread in detail, but I believe that what you
are complaining about is the _case of the returned result_ if there is
a match and the search is case insensitive.  I do not believe that
there still are problems with finding out correctly whether or not
there is a match.  (Unless I misunderstood.)

Sincerely,

Luc.

Re: completing-read case problem

[Markus Rost]

> I did not follow this thread in detail, but I believe that what you
> are complaining about is the _case of the returned result_ if there is
> a match and the search is case insensitive.

Well, yes, I was complaining that sometimes the result is not a member
of TABLE or does not satisfy PREDICATE.  For instance if PREDICATE is

   (lambda (s) (eq s 'Hello))

then any result ought to be EXACTLY 'Hello and neither 'hello nor
'HELLO are allowed, even in a caSe-inSenSitive search.  Anything else
would be confusing for a programmer, I think.

>  I do not believe that
> there still are problems with finding out correctly whether or not
> there is a match. 

I did not see any problem of this kind.

Re: completing-read case problem

[Markus Rost]

> How 'bout the patch below,

> ...

> --- minibuf.c   15 nov 2004 10:41:18 -0500      1.273
> +++ minibuf.c   15 nov 2004 16:57:59 -0500      

This patch works fine for me.  All problems I mentioned disappear.
Thanks.

Re: completing-read case problem

[Richard Stallman]

I installed the patch that Stefan sent, since the report
is that it worked well.

Re: completing-read case problem

[Markus Rost]

> I installed the patch that Stefan sent, since the report
> is that it worked well.
> 

The installed patch doesn't work well for me.

I think that one additional bogus line "goto exit;" slipped into it,
see the following patch.  This patch looks rather obvious to me, but
since I am not a C programmer, I didn't install it myself.

The second patch is Stefan's, which worked fine for me.


===Buffer *vc-diff*=========================================
*** minibuf.c.~1.275.~	Sat Nov 20 23:37:08 2004
--- minibuf.c	Sat Nov 20 23:55:30 2004
***************
*** 2105,2112 ****
        goto exit;
      }
  
-     goto exit;
- 
    /* Call do_completion, but ignore errors.  */
    SET_PT (ZV);
    val = internal_condition_case (complete_and_exit_1, Qerror,
--- 2105,2110 ----
============================================================



===Buffer minibuf.diff======================================
*** minibuf.c.~1.273.~	Sun Nov 14 00:59:52 2004
--- minibuf.c	Mon Nov 15 22:29:45 2004
***************
*** 2076,2085 ****
    if (XINT (Fminibuffer_prompt_end ()) == ZV)
      goto exit;
  
!   if (!NILP (Ftest_completion (Fminibuffer_contents (),
  			       Vminibuffer_completion_table,
  			       Vminibuffer_completion_predicate)))
!     goto exit;
  
    /* Call do_completion, but ignore errors.  */
    SET_PT (ZV);
--- 2076,2102 ----
    if (XINT (Fminibuffer_prompt_end ()) == ZV)
      goto exit;
  
!   if (!NILP (Ftest_completion (val = Fminibuffer_contents (),
  			       Vminibuffer_completion_table,
  			       Vminibuffer_completion_predicate)))
!     {
!       if (completion_ignore_case)
! 	{ /* Fixup case of the field, if necessary. */
! 	  Lisp_Object compl
! 	    = Ftry_completion (val,
! 			       Vminibuffer_completion_table,
! 			       Vminibuffer_completion_predicate);
! 	  if (STRINGP (compl)
! 	      /* If it weren't for this piece of paranoia, I'd replace
! 		 the whole thing with a call to do_completion. */
! 	      && EQ (Flength (val), Flength (compl)))
! 	    {
! 	      del_range (XINT (Fminibuffer_prompt_end ()), ZV);
! 	      Finsert (1, &compl);
! 	    }
! 	}
!       goto exit;
!     }
  
    /* Call do_completion, but ignore errors.  */
    SET_PT (ZV);
============================================================

Re: completing-read case problem

[Luc Teirlinck]

Markus Rost wrote:

   > I installed the patch that Stefan sent, since the report
   > is that it worked well.
   > 

   The installed patch doesn't work well for me.

   I think that one additional bogus line "goto exit;" slipped into it,
   see the following patch.  This patch looks rather obvious to me, but
   since I am not a C programmer, I didn't install it myself.

   The second patch is Stefan's, which worked fine for me.


   ===Buffer *vc-diff*=========================================
   *** minibuf.c.~1.275.~	Sat Nov 20 23:37:08 2004
   --- minibuf.c	Sat Nov 20 23:55:30 2004
   ***************
   *** 2105,2112 ****
	   goto exit;
	 }

   -     goto exit;
   - 
       /* Call do_completion, but ignore errors.  */
       SET_PT (ZV);
       val = internal_condition_case (complete_and_exit_1, Qerror,
   --- 2105,2110 ----
   ============================================================

That patch _does_ look obvious and it fixes minibuffer completion
problems reported by several people.  That is, it makes `M-x she RET'
work again.

Sincerely,

Luc.

Re: completing-read case problem

[Richard Stallman]

Thanks.