filling in the minibuffer

filling in the minibuffer

[Alex Schroeder]

I sometimes have the need for filling a paragraph in the minibuffer.

(let ((debug-ignored-errors nil)
      (debug-on-error t))
  (read-from-minibuffer "Text: "))

Type a few words, hit M-q.

You get an error:

fill-delete-newlines: Text is read-only

When you type a few words, C-q C-j to insert a newline, and type some
more, and then hit M-q, filling works as expected.

I think we should try to make it work without a newline in the
minibuffer, too.  In fact, I think this used to work in earlier
versions.

Why does it happen?

The prompt ends with a space.  When fill-delete-newlines gets called, 
we have a problem at the very end:

  (if (and nosqueeze (not (eq justify 'full)))
      nil
    (canonically-space-region (or squeeze-after (point)) to)
    ;; Remove trailing whitespace.
    ;; Maybe canonically-space-region should do that.
    (goto-char to) (delete-char (- (skip-chars-backward " \t"))))
  (goto-char from))

That is, this tries to delete the space ending the prompt, which
fails.

What should we do?  Should we just skip over read-only text when
filling?

Maybe that is not the whole story, because why is the code being
called on the prompt only?

Edebugging fill-paragraph I note the following:

	(save-excursion
	  ;; To make sure the return value of forward-paragraph is meaningful,
	  ;; we have to start from the beginning of line, otherwise skipping
	  ;; past the last few chars of a paragraph-separator would count as
	  ;; a paragraph (and not skipping any chars at EOB would not count
	  ;; as a paragraph even if it is).
	  (move-to-left-margin)
	  (if (not (zerop (forward-paragraph)))
	      ;; There's no paragraph at or after point: give up.
	      (setq fill-pfx "")
	    (let ((end (point))
		  (beg (progn (backward-paragraph) (point))))
	      (goto-char before)

The call to move-to-left-margin takes us to the beginning of the
prompt.  The forward-paragraph takes us to end of the prompt (end).
Then the next backward-paragraph takes us to the beginning of the
prompt again (beg).  I think this is the bug.

Maybe move-to-left-margin should stop at field boundaries?  I'm not
sure this is the correct solution...

Alex.
-- 
.O.  http://www.emacswiki.org/alex/
..O  Schroeder's fourth law:
OOO  None of your friends and coworkers share your taste in music.

Re: filling in the minibuffer

[Richard Stallman]

    The prompt ends with a space.  When fill-delete-newlines gets called, 
    we have a problem at the very end:

      (if (and nosqueeze (not (eq justify 'full)))
	  nil
	(canonically-space-region (or squeeze-after (point)) to)
	;; Remove trailing whitespace.
	;; Maybe canonically-space-region should do that.
	(goto-char to) (delete-char (- (skip-chars-backward " \t"))))
      (goto-char from))

    That is, this tries to delete the space ending the prompt, which
    fails.

It seems to me that a special case check here for the minibuffer,
to leave the prompt alone, is an ok solution.

    The call to move-to-left-margin takes us to the beginning of the
    prompt.  The forward-paragraph takes us to end of the prompt (end).
    Then the next backward-paragraph takes us to the beginning of the
    prompt again (beg).  I think this is the bug.

    Maybe move-to-left-margin should stop at field boundaries?  I'm not
    sure this is the correct solution...

It would make sense for move-to-left-margin to special-case
the minibuffer and treat the end of the prompt as the left margin.

Does this patch give good results?

*** indent.el	11 Sep 2003 09:45:48 -0400	1.55
--- indent.el	17 Aug 2004 20:27:18 -0400	
***************
*** 164,177 ****
    (interactive (list (prefix-numeric-value current-prefix-arg) t))
    (beginning-of-line n)
    (skip-chars-forward " \t")
!   (let ((lm (current-left-margin))
! 	(cc (current-column)))
!     (cond ((> cc lm)
! 	   (if (> (move-to-column lm force) lm)
! 	       ;; If lm is in a tab and we are not forcing, move before tab
! 	       (backward-char 1)))
! 	  ((and force (< cc lm))
! 	   (indent-to-left-margin)))))
  
  ;; This used to be the default indent-line-function,
  ;; used in Fundamental Mode, Text Mode, etc.
--- 164,181 ----
    (interactive (list (prefix-numeric-value current-prefix-arg) t))
    (beginning-of-line n)
    (skip-chars-forward " \t")
!   (if (window-minibuffer-p)
!       (if (save-excursion (beginning-of-line) (bobp))
! 	  (goto-char (minibuffer-prompt-end))
! 	(beginning-of-line))
!     (let ((lm (current-left-margin))
! 	  (cc (current-column)))
!       (cond ((> cc lm)
! 	     (if (> (move-to-column lm force) lm)
! 		 ;; If lm is in a tab and we are not forcing, move before tab
! 		 (backward-char 1)))
! 	    ((and force (< cc lm))
! 	     (indent-to-left-margin))))))
  
  ;; This used to be the default indent-line-function,
  ;; used in Fundamental Mode, Text Mode, etc.

Re: filling in the minibuffer

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

>     Maybe move-to-left-margin should stop at field boundaries?  I'm not
>     sure this is the correct solution...
>
> It would make sense for move-to-left-margin to special-case
> the minibuffer and treat the end of the prompt as the left margin.
>
> Does this patch give good results?

It does.  Thanks.

Alex.


> *** indent.el	11 Sep 2003 09:45:48 -0400	1.55
> --- indent.el	17 Aug 2004 20:27:18 -0400	
> ***************
> *** 164,177 ****
>     (interactive (list (prefix-numeric-value current-prefix-arg) t))
>     (beginning-of-line n)
>     (skip-chars-forward " \t")
> !   (let ((lm (current-left-margin))
> ! 	(cc (current-column)))
> !     (cond ((> cc lm)
> ! 	   (if (> (move-to-column lm force) lm)
> ! 	       ;; If lm is in a tab and we are not forcing, move before tab
> ! 	       (backward-char 1)))
> ! 	  ((and force (< cc lm))
> ! 	   (indent-to-left-margin)))))
>   
>   ;; This used to be the default indent-line-function,
>   ;; used in Fundamental Mode, Text Mode, etc.
> --- 164,181 ----
>     (interactive (list (prefix-numeric-value current-prefix-arg) t))
>     (beginning-of-line n)
>     (skip-chars-forward " \t")
> !   (if (window-minibuffer-p)
> !       (if (save-excursion (beginning-of-line) (bobp))
> ! 	  (goto-char (minibuffer-prompt-end))
> ! 	(beginning-of-line))
> !     (let ((lm (current-left-margin))
> ! 	  (cc (current-column)))
> !       (cond ((> cc lm)
> ! 	     (if (> (move-to-column lm force) lm)
> ! 		 ;; If lm is in a tab and we are not forcing, move before tab
> ! 		 (backward-char 1)))
> ! 	    ((and force (< cc lm))
> ! 	     (indent-to-left-margin))))))
>   
>   ;; This used to be the default indent-line-function,
>   ;; used in Fundamental Mode, Text Mode, etc.
>

Re: filling in the minibuffer

[Stefan Monnier]

>> Maybe move-to-left-margin should stop at field boundaries?  I'm not
>> sure this is the correct solution...
>> 
>> It would make sense for move-to-left-margin to special-case
>> the minibuffer and treat the end of the prompt as the left margin.

I disagree.  The same problem can most likely happen in
a (non-mini)buffer.


        Stefan

Re: filling in the minibuffer

[Miles Bader]

On Sat, Aug 21, 2004 at 09:14:07PM -0400, Stefan Monnier wrote:
> >> Maybe move-to-left-margin should stop at field boundaries?  I'm not
> >> sure this is the correct solution...
> >> 
> >> It would make sense for move-to-left-margin to special-case
> >> the minibuffer and treat the end of the prompt as the left margin.
> 
> I disagree.  The same problem can most likely happen in
> a (non-mini)buffer.

I agree -- I think it's almost always the case that a field check is better
than a minibuffer check, because exactly the same situation can occur in
other applications of fields (e.g., comint, custom, etc).

BTW, filling in the minibuffer with fields did use to work correctly (I made
sure it was the case when I originally added the field code).

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff