[alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[Richard Stallman]

Would someone please fix this, then ack?

------- Start of forwarded message -------
From: A Soare <alinsoar@voila.fr>
To: "Emacs   Dev  [emacs-devel]" <emacs-devel@gnu.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Date: Mon,  5 Mar 2007 15:26:35 +0100 (CET)
Subject: EVAL and mouse selection in *Completions*
Reply-To: alinsoar@voila.fr
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
	version=3.0.4

1. M-:
(setq indent- <TAB>

select with the mouse indent-tabs-mode

In the minibuffer appears just indent-tabs-mode.


(setq is lost.






_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
------- End of forwarded message -------

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[Glenn Morris]

Richard Stallman wrote:

> Would someone please fix this, then ack?
>
> From: A Soare <alinsoar@voila.fr>
> Subject: EVAL and mouse selection in *Completions*

This bug was already mentioned by Martin Rudalics in reply to your
mail "[bojohan+mail@bogus.example.com: Partial completion]" of Feb
24th. 

I suggest the following fix, but it seems both this bug and the other
one need input from the OPs (or those who use partial completion), to
test that the suggested fixes do not break anything else.


***************
*** 710,722 ****
  			(and completion-auto-help
  			     (eq last-command this-command))
  			(eq mode 'help))
  		    (with-output-to-temp-buffer "*Completions*"
  		      (display-completion-list (sort helpposs 'string-lessp))
  		      (with-current-buffer standard-output
  			;; Record which part of the buffer we are completing
  			;; so that choosing a completion from the list
  			;; knows how much old text to replace.
! 			(setq completion-base-size dirlength)))
  		  (PC-temp-minibuffer-message " [Next char not unique]"))
  		nil)))))
  
--- 718,734 ----
  			(and completion-auto-help
  			     (eq last-command this-command))
  			(eq mode 'help))
+                     (let ((width (minibuffer-prompt-width)))
                        (with-output-to-temp-buffer "*Completions*"
                          (display-completion-list (sort helpposs 'string-lessp))
                          (with-current-buffer standard-output
                            ;; Record which part of the buffer we are completing
                            ;; so that choosing a completion from the list
                            ;; knows how much old text to replace.
!                           (setq completion-base-size
!                                 (if dirname
!                                     dirlength
!                                   (- beg 1 width))))))
                    (PC-temp-minibuffer-message " [Next char not unique]"))
  		nil)))))

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> Richard Stallman wrote:
>
>> Would someone please fix this, then ack?
>>
>> 1. M-:
>> (setq indent- <TAB>
>>
>> select with the mouse indent-tabs-mode
>>
>> In the minibuffer appears just indent-tabs-mode.
>>
> This bug was already mentioned by Martin Rudalics in reply to your
> mail "[bojohan+mail@bogus.example.com: Partial completion]" of Feb
> 24th. 
>
> I suggest the following fix, but it seems both this bug and the other
> one need input from the OPs (or those who use partial completion), to
> test that the suggested fixes do not break anything else.

This bug does not refer to partial completion: it happens even for the
ordinary completion mechanism.  The basic problem is that
completion-base-size is set to 0 for minibuffer input, whereas we want
it to be nil when completing a symbol.

The following is the minimal fix I've managed to find.  I don't know
if a less invasive change is possible.

*** emacs/lisp/simple.el.~1.847.~	2007-03-05 09:28:25.000000000 -0500
--- emacs/lisp/simple.el	2007-03-05 21:46:47.000000000 -0500
***************
*** 1056,1064 ****
  If `eval-expression-debug-on-error' is non-nil, which is the default,
  this command arranges for all errors to enter the debugger."
    (interactive
!    (list (read-from-minibuffer "Eval: "
  			       nil read-expression-map t
! 			       'read-expression-history)
  	 current-prefix-arg))
  
    (if (null eval-expression-debug-on-error)
--- 1056,1065 ----
  If `eval-expression-debug-on-error' is non-nil, which is the default,
  this command arranges for all errors to enter the debugger."
    (interactive
!    (list (let ((minibuffer-completing-symbol t))
! 	   (read-from-minibuffer "Eval: "
  			       nil read-expression-map t
! 			       'read-expression-history))
  	 current-prefix-arg))
  
    (if (null eval-expression-debug-on-error)
***************
*** 5109,5114 ****
--- 5110,5117 ----
  		(save-excursion
  		  (skip-chars-backward completion-root-regexp)
  		  (- (point) (minibuffer-prompt-end)))))
+ 	     (minibuffer-completing-symbol
+ 	      nil)
  	     ;; Otherwise, in minibuffer, the base size is 0.
  	     ((minibufferp mainbuf) 0)))
        (setq common-string-length
*** emacs/src/minibuf.c.~1.326.~	2007-02-23 11:24:42.000000000 -0500
--- emacs/src/minibuf.c	2007-03-05 21:46:15.000000000 -0500
***************
*** 139,144 ****
--- 139,145 ----
  Lisp_Object Vminibuffer_completion_predicate, Qminibuffer_completion_predicate;
  Lisp_Object Vminibuffer_completion_confirm, Qminibuffer_completion_confirm;
  Lisp_Object Vminibuffer_completing_file_name;
+ Lisp_Object Vminibuffer_completing_symbol;
  
  Lisp_Object Quser_variable_p;
  
***************
*** 2929,2934 ****
--- 2930,2940 ----
  	       doc: /* Non-nil and non-`lambda' means completing file names.  */);
    Vminibuffer_completing_file_name = Qnil;
  
+   DEFVAR_LISP ("minibuffer-completing-symbol",
+ 	       &Vminibuffer_completing_symbol,
+ 	       doc: /* Non-nil means completing a Lisp symbol in the minibuffer.  */);
+   Vminibuffer_completing_symbol = Qnil;
+ 
    DEFVAR_LISP ("minibuffer-help-form", &Vminibuffer_help_form,
  	       doc: /* Value that `help-form' takes on inside the minibuffer.  */);
    Vminibuffer_help_form = Qnil;

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[Nick Roberts]

 > > Would someone please fix this, then ack?
 > >
 > > From: A Soare <alinsoar@voila.fr>
 > > Subject: EVAL and mouse selection in *Completions*
 > 
 > This bug was already mentioned by Martin Rudalics in reply to your
 > mail "[bojohan+mail@bogus.example.com: Partial completion]" of Feb
 > 24th. 
 > 
 > I suggest the following fix, but it seems both this bug and the other
 > one need input from the OPs (or those who use partial completion), to
 > test that the suggested fixes do not break anything else.

The OP _did_ say that Martin's fix worked for him:

http://lists.gnu.org/archive/html/emacs-devel/2007-03/msg00086.html

Of course it's hard to be sure that regressions aren't being introduced with
such fixes, but I hope that whoever takes over Emacs maintenance will introduce
some kind of web based bug tracker/database.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[Glenn Morris]

Nick Roberts wrote:

> http://lists.gnu.org/archive/html/emacs-devel/2007-03/msg00086.html

I seem to be failing basic reading comprehension left, right and
centre today... I was reading the thread on the web archives and the
OP's reply was in a different month.

Is someone going to install it then?

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[Glenn Morris]

Glenn Morris wrote:

> Is someone going to install it then?

(by "it" I meant Martin Rudalics' patch).

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[martin rudalics]

 >>Is someone going to install it then?
 >
 >
 > (by "it" I meant Martin Rudalics' patch).

As far as I can tell we now have

- my patch (where the term `try-completion-old' is conflicting according
   to Richard)

- your patch

- Chong's patch

If Chong's patch resolves the erasure-from-bob problem for _any_
completion mode (apparently people never ever used symbol completion and
the recent attention given to partial completion mode is a plain mystery
to me ;-)) we should probably revise your patch and install it.

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[Stefan Monnier]

>>> Is someone going to install it then?
>> 
>> 
>> (by "it" I meant Martin Rudalics' patch).

> As far as I can tell we now have

> - my patch (where the term `try-completion-old' is conflicting according
>   to Richard)

> - your patch

> - Chong's patch

> If Chong's patch resolves the erasure-from-bob problem for _any_
> completion mode (apparently people never ever used symbol completion and
> the recent attention given to partial completion mode is a plain mystery
> to me ;-)) we should probably revise your patch and install it.

Whichever patch people end up installing, please please pretty please, wrap
it in a thick layer of comment explaing the problem it's trying to fix, as
well as your best understanding of why it should fix it.


        Stefan

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[Glenn Morris]

martin rudalics wrote:

> As far as I can tell we now have
>
> - my patch (where the term `try-completion-old' is conflicting according
>   to Richard)
>
> - your patch
>
> - Chong's patch
>
> If Chong's patch resolves the erasure-from-bob problem for _any_
> completion mode (apparently people never ever used symbol completion and
> the recent attention given to partial completion mode is a plain mystery
> to me ;-)) we should probably revise your patch and install it.

I thought your try-completion-old was a better, more comprehensive
solution than mine. But I agree the name is poor. Why not call it
PC-try-completion? Also, shouldn't it return STRING, rather than "",
for an exact match? I think it must be the right solution for the
'sequencep t' problem, and should be installed.

With regards to the partial completion erasing buffer thing, I don't
know if we need to tweak completion-base-size, apply the complex fix,
or both.

I have little idea how anyone can have used partial completion for
much of anything, given all the problems it seems to have.

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[martin rudalics]

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

 > I thought your try-completion-old was a better, more comprehensive
 > solution than mine. But I agree the name is poor. Why not call it
 > PC-try-completion?

OK

 > Also, shouldn't it return STRING, rather than "",
 > for an exact match?

It should, indeed, thanks.  Please look at the attached patch.  Johan,
please have another look at this too.

 > With regards to the partial completion erasing buffer thing, I don't
 > know if we need to tweak completion-base-size, apply the complex fix,
 > or both.

I removed this part from my patch.  Could people please try whether
Chong's `completion-base-size' fix solves this part of the symbol
completion problem.

[-- Attachment #2: complete.diff --]
[-- Type: text/plain, Size: 3740 bytes --]

*** complete.el	Tue Jan 23 07:40:00 2007
--- complete.el	Wed Mar  7 11:21:16 2007
***************
*** 383,388 ****
--- 383,411 ----
      (let ((completion-ignore-case nil))
        (test-completion str table pred))))

+ ;; The following function is an attempt to work around two problems:
+ 
+ ;; (1) When complete.el was written, (try-completion "" '(("") (""))) used to
+ ;; return the value "".  With a change from 2002-07-07 it returns t which caused
+ ;; `PC-lisp-complete-symbol' to fail with a "Wrong type argument: sequencep, t"
+ ;; error.  `PC-try-completion' returns STRING in this case.
+ 
+ ;; (2) (try-completion "" '((""))) returned t before the above-mentioned change.
+ ;; Since `PC-chop-word' operates on the return value of `try-completion' this
+ ;; case might have provoked a similar error as in (1).  `PC-try-completion'
+ ;; returns "" instead.  I don't know whether this is a real problem though.
+ 
+ ;; Since `PC-try-completion' is not a guaranteed to fix these bugs reliably, you
+ ;; should try to look at the following discussions when you encounter problems:
+ ;; - emacs-pretest-bug ("Partial Completion" starting 2007-02-23),
+ ;; - emacs-devel ("[address-of-OP: Partial completion]" starting 2007-02-24),
+ ;; - emacs-devel ("[address-of-OP: EVAL and mouse selection in *Completions*]"
+ ;;   starting 2007-03-05).
+ (defun PC-try-completion (string alist &optional predicate)
+   "Like `try-completion' but return STRING instead of t."
+   (let ((result (try-completion string alist predicate)))
+     (if (eq result t) string result)))
+ 
  (defun PC-do-completion (&optional mode beg end)
    (or beg (setq beg (minibuffer-prompt-end)))
    (or end (setq end (point-max)))
***************
*** 623,630 ****

  	    ;; Check if next few letters are the same in all cases
  	    (if (and (not (eq mode 'help))
! 		     (setq prefix (try-completion (PC-chunk-after basestr skip)
!                                                   poss)))
  		(let ((first t) i)
  		  ;; Retain capitalization of user input even if
  		  ;; completion-ignore-case is set.
--- 646,653 ----

  	    ;; Check if next few letters are the same in all cases
  	    (if (and (not (eq mode 'help))
! 		     (setq prefix (PC-try-completion
! 				   (PC-chunk-after basestr skip) poss)))
  		(let ((first t) i)
  		  ;; Retain capitalization of user input even if
  		  ;; completion-ignore-case is set.
***************
*** 662,668 ****
  			      (setq skip (concat skip
  						 (regexp-quote prefix)
  						 PC-ndelims-regex)
! 				    prefix (try-completion
  					    (PC-chunk-after
  					     ;; not basestr, because that does
  					     ;; not reflect insertions
--- 685,691 ----
  			      (setq skip (concat skip
  						 (regexp-quote prefix)
  						 PC-ndelims-regex)
! 				    prefix (PC-try-completion
  					    (PC-chunk-after
  					     ;; not basestr, because that does
  					     ;; not reflect insertions
***************
*** 996,1002 ****
                (cond
                 ((not completion-table) nil)
                 ((eq action 'lambda) (test-completion str2 completion-table nil))
!                ((eq action nil) (try-completion str2 completion-table nil))
                 ((eq action t) (all-completions str2 completion-table nil)))))
      ad-do-it))
  \f
--- 1019,1025 ----
                (cond
                 ((not completion-table) nil)
                 ((eq action 'lambda) (test-completion str2 completion-table nil))
!                ((eq action nil) (PC-try-completion str2 completion-table nil))
                 ((eq action t) (all-completions str2 completion-table nil)))))
      ad-do-it))
  \f

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

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[Glenn Morris]

martin rudalics wrote:

> It should, indeed, thanks.  Please look at the attached patch.

Looks good to me. Also fixes the issue "partial-completion-mode and
Info-menu]".

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[Richard Stallman]

    I suggest the following fix, but it seems both this bug and the other
    one need input from the OPs (or those who use partial completion), to
    test that the suggested fixes do not break anything else.

If you think that, you should cc your message to the OP.
How about doing that now?

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[Glenn Morris]

Richard Stallman wrote:

> If you think that, you should cc your message to the OP.

Why do you forward bug reports from emacs-devel to emacs-devel, with
only the little "please DTRT and ACK" addition? It has the effect of
removing the OP from the CC list when people reply to your forward, as
well as creating a separate thread. Presumably someone who posts to
emacs-devel wants to be involved in the discussion. You could reply to
the original message instead of forwarding it.

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[Richard Stallman]

    Why do you forward bug reports from emacs-devel to emacs-devel, with
    only the little "please DTRT and ACK" addition?

Because my experience is that this gets someone to debug and fix it.
If I don't do this, quite often nobody works on the bug.

It also gives me a reminder if nobody works on it.

     It has the effect of
    removing the OP from the CC list when people reply to your forward, as
    well as creating a separate thread.

Perhaps I should reply instead.

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[Stefan Monnier]

>      It has the effect of
>     removing the OP from the CC list when people reply to your forward, as
>     well as creating a separate thread.

> Perhaps I should reply instead.

Yes, please, that would be helpful.

It would have the additional advantage that it makes it easier to recover
the original message, which is important if it used a MIME attachment, since
your mail reader obviously doesn't know how to forward a MIME message.


        Stefan

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[Richard Stallman]

    It would have the additional advantage that it makes it easier to recover
    the original message, which is important if it used a MIME attachment, since
    your mail reader obviously doesn't know how to forward a MIME message.

I forward mail with rmail-forward.  rmail-unforward will extract
the forwarded message as it was.

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[Stefan Monnier]

>     It would have the additional advantage that it makes it easier to
>     recover the original message, which is important if it used a MIME
>     attachment, since your mail reader obviously doesn't know how to
>     forward a MIME message.

> I forward mail with rmail-forward.  rmail-unforward will extract
> the forwarded message as it was.

Last I tried, this didn't work quit right because rmail-forward had stripped
some relevant header.


        Stefan

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[Richard Stallman]

    Last I tried, this didn't work quit right because rmail-forward had stripped
    some relevant header.

I will test it myself now.

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[A Soare]

I found this bug a long time ago, but I reported it just yesterday. Had I had some time, I would have solved it alone and sent just the patch.

It does not refer to PS-complete, but to default completion.


Alin Soare.

[alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[A Soare]

>     Why do you forward bug reports from emacs-devel to emacs-devel, with
>     only the little "please DTRT and ACK" addition?
> 
> Because my experience is that this gets someone to debug and fix it.
> If I don't do this, quite often nobody works on the bug.
> 
> It also gives me a reminder if nobody works on it.

If the OP see in 1-2 months that it is not solved yet, the OP will report it again.

> 
>      It has the effect of
>     removing the OP from the CC list when people reply to your forward, as
>     well as creating a separate thread.
> 
> Perhaps I should reply instead.

Since the OP reported it as a bug, not as a patch, that means that the OP does not necessarily want to work on this bug.
So it is not very important to reply to the OP every time, just in case of misunderstandings...

I spoke just from the viewpoint of my bugs. For the others members that report bugs, maybe the opinions differ.

A Soare

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[Nick Roberts]

 > Since the OP reported it as a bug, not as a patch, that means that the OP
 > does not necessarily want to work on this bug.  So it is not very important
 > to reply to the OP every time, just in case of misunderstandings...

The OP may not want to fix the bug, or know how to, but he often is the best
person to know whether a patch does indeed fix the bug.  If he is not willing,
or in a position, to provide such feedback then that devalues the bug report.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[Richard Stallman]

    If the OP see in 1-2 months that it is not solved yet, the OP will report it again.

You don't know that.  Some will, some won't.  Anyway, when we are hoping
to make a release soon, we don't want to 1 to 2 months!

    Since the OP reported it as a bug, not as a patch, that means that the OP does not necessarily want to work on this bug.

The reason to include the OP, as was usefully pointed out to me by
Glenn, was that we want that person to confirm that the patch fixes
the bug.

Whether the OP wants to work on fixing it is therefore beside the point.

Re: [alinsoar@voila.fr: EVAL and mouse selection in *Completions*]

[A Soare]

>     Why do you forward bug reports from emacs-devel to emacs-devel, with
>     only the little "please DTRT and ACK" addition?
> 
> Because my experience is that this gets someone to debug and fix it.
> If I don't do this, quite often nobody works on the bug.
> 
> It also gives me a reminder if nobody works on it.

If the OP see in 1-2 months that it is not solved yet, the OP will report it again.

> 
>      It has the effect of
>     removing the OP from the CC list when people reply to your forward, as
>     well as creating a separate thread.
> 
> Perhaps I should reply instead.

Since the OP reported it as a bug, not as a patch, that means that the OP does not necessarily want to work on this bug.
So it is not very important to reply to the OP every time, just in case of misunderstandings...

I spoke just from the viewpoint of my bugs. For the others members that report bugs, maybe the opinions differ.