Out-of-date completions for `read-buffer'

Out-of-date completions for `read-buffer'

[Stuart D. Herring]

Fread_buffer directly uses Vbuffer_alist in its call to Fcompleting_read. 
This breaks if, while the minibuffer is active, the user switches buffers
around.  The cons which was the head of the list when Fread_buffer was
called will in general no longer be at the head, and so part of the list
will vanish for completion purposes.  (Of course, it's slightly worse when
REQUIRE-MATCH is set.)  Similar problems result from creating or killing
buffers during the call.  I also have a vague suspicion that this
procedure exposes the alist to modification by user code, but I can't
think of how at the moment.

Copying the alist for the call to Fcompleting_read (which is trivial to
implement) would solve the reordering problems but not the ones involving
creation/destruction; the real solution is to write a `complete-buffer'
completion function that would re-consult the buffer list each time
completion was needed.

WDOT?  Is this worth fixing, and if so in which way?

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Out-of-date completions for `read-buffer'

[Richard Stallman]

    Copying the alist for the call to Fcompleting_read (which is trivial to
    implement) would solve the reordering problems but not the ones involving
    creation/destruction; the real solution is to write a `complete-buffer'
    completion function that would re-consult the buffer list each time
    completion was needed.

    WDOT?  Is this worth fixing, and if so in which way?

I think it is worth fixing.  Copying the alist pairs as well as the
alist itself would be simple and avoid any danger of crashing.  It
would still "complete wrong" in the case of creating or killing
buffers, but that seems like a minor issue.  So I think that solution
would be fine.  However, the `complete-buffer' solution you proposed
would be fine too.

Would you like to fix it one way or the other?

Re: Out-of-date completions for `read-buffer'

[Stuart D. Herring]

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

> I think it is worth fixing.  Copying the alist pairs as well as the
> alist itself would be simple and avoid any danger of crashing.  It
> would still "complete wrong" in the case of creating or killing
> buffers, but that seems like a minor issue.  So I think that solution
> would be fine.  However, the `complete-buffer' solution you proposed
> would be fine too.
>
> Would you like to fix it one way or the other?

It turned out that the `complete-buffer' method was easy, since
Vbuffer_alist is of course still around: see the attached (hopefully
trivial) patch.  The name of the new function and its doc string might
both need improvement.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

[-- Attachment #2: read-buffer.patch --]
[-- Type: application/octet-stream, Size: 1637 bytes --]

*** minibuf.c.~1.307.~	2006-07-17 11:45:27.000000000 -0600
--- minibuf.c	2006-08-17 13:41:47.000000000 -0600
***************
*** 1149,1154 ****
--- 1149,1168 ----
    return Fintern (name, Qnil);
  }
  
+ DEFUN ("complete-buffer", Fcomplete_buffer, Scomplete_buffer, 3, 3, 0,
+        doc: /* Perform completion on buffer names.
+ See `try-completion', `all-completions', and `test-completion'.  */)
+      (string, predicate, flag)
+      Lisp_Object string, predicate, flag;
+ {
+   if (NILP (flag))
+     return Ftry_completion (string, Vbuffer_alist, predicate);
+   else if (EQ (flag, Qt))
+     return Fall_completions (string, Vbuffer_alist, predicate, Qt);
+   else				/* assume `lambda' */
+     return Ftest_completion (string, Vbuffer_alist, predicate);
+ }
+ 
  DEFUN ("read-buffer", Fread_buffer, Sread_buffer, 1, 3, 0,
         doc: /* Read the name of a buffer and return as a string.
  Prompt with PROMPT.
***************
*** 1195,1201 ****
  	  prompt = Fformat (3, args);
  	}
  
!       return Fcompleting_read (prompt, Vbuffer_alist, Qnil,
  			       require_match, Qnil, Qbuffer_name_history,
  			       def, Qnil);
      }
--- 1209,1215 ----
  	  prompt = Fformat (3, args);
  	}
  
!       return Fcompleting_read (prompt, Scomplete_buffer, Qnil,
  			       require_match, Qnil, Qbuffer_name_history,
  			       def, Qnil);
      }
***************
*** 2915,2920 ****
--- 2929,2935 ----
    defsubr (&Sread_string);
    defsubr (&Sread_command);
    defsubr (&Sread_variable);
+   defsubr (&Scomplete_buffer);
    defsubr (&Sread_buffer);
    defsubr (&Sread_no_blanks_input);
    defsubr (&Sminibuffer_depth);

[-- 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: Out-of-date completions for `read-buffer'

[Richard Stallman]

Your patch is clean, but we should call the new function
internal-complete-buffer so that people won't complain that it isn't
documented it in the Lisp Manual.

Would someone (Eli?) please install the patch, with that change?

Re: Out-of-date completions for `read-buffer'

[Stuart D. Herring]

> Your patch is clean, but we should call the new function
> internal-complete-buffer so that people won't complain that it isn't
> documented it in the Lisp Manual.
>
> Would someone (Eli?) please install the patch, with that change?

Not to harass, but this hasn't happened in ten days, so I thought I'd
re-raise it.  The patch's message is at
http://lists.gnu.org/archive/html/emacs-devel/2006-08/msg00574.html.

Thanks,
Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Out-of-date completions for `read-buffer'

[Eli Zaretskii]

> Date: Mon, 28 Aug 2006 13:25:47 -0700 (PDT)
> From: "Stuart D. Herring" <herring@lanl.gov>
> 
> > Your patch is clean, but we should call the new function
> > internal-complete-buffer so that people won't complain that it isn't
> > documented it in the Lisp Manual.
> >
> > Would someone (Eli?) please install the patch, with that change?
> 
> Not to harass, but this hasn't happened in ten days

I was travelling when Richard asked me to do it.  Please be more
patient.

Re: Out-of-date completions for `read-buffer'

[Stuart D. Herring]

>> Not to harass, but this hasn't happened in ten days
>
> I was travelling when Richard asked me to do it.  Please be more
> patient.

No impatience, I promise.  I merely wish it not to be forgotten, and can't
tell from here whether it has been.  I'll be content if I'm assured its
installation in two years, and quite happy if it makes it for 22.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Out-of-date completions for `read-buffer'

[Eli Zaretskii]

> Date: Wed, 30 Aug 2006 08:43:53 -0700 (PDT)
> From: "Stuart D. Herring" <herring@lanl.gov>
> Cc: emacs-devel@gnu.org
> 
> No impatience, I promise.  I merely wish it not to be forgotten, and can't
> tell from here whether it has been.

It will never be forgotten.  Richard has a machinery in place that
reminds after 2 weeks if his request was not replied to by whoever he
asked to do it (in this case, me).

Re: Out-of-date completions for `read-buffer'

[Stuart D. Herring]

> It will never be forgotten.  Richard has a machinery in place that
> reminds after 2 weeks if his request was not replied to by whoever he
> asked to do it (in this case, me).

Oh.  I thought the interval was one week, and so thought the lack of
reminder after 10 days was significant with regards to that.  Apologies.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Out-of-date completions for `read-buffer'

[Eli Zaretskii]

> Date: Mon, 28 Aug 2006 13:25:47 -0700 (PDT)
> From: "Stuart D. Herring" <herring@lanl.gov>
> 
> > Your patch is clean, but we should call the new function
> > internal-complete-buffer so that people won't complain that it isn't
> > documented it in the Lisp Manual.
> >
> > Would someone (Eli?) please install the patch, with that change?
> 
> Not to harass, but this hasn't happened in ten days, so I thought I'd
> re-raise it.  The patch's message is at
> http://lists.gnu.org/archive/html/emacs-devel/2006-08/msg00574.html.

Installed.

Your original patch didn't compile:

  minibuf.c: In function `Fread_buffer':
  minibuf.c:1218: error: incompatible type for argument 2 of `Fcompleting_read'
  make[1]: *** [minibuf.o] Error 1

I fixed that by using `intern ("internal-complete-buffer")' instead of
`Sinternal_complete_buffer'.  I also expanded the doc string to
explain the arguments.

Thanks.