Re: filling inside minibuffer behaves poorly

Re: filling inside minibuffer behaves poorly

[Richard Stallman]

    I use a package that does instant messaging inside of emacs. It
    prompts for the message in the minibuffer. In previous versions if
    my message went long I hit M-q (fill-paragraph) to word wrap the
    message before sending it and the message appeared fine.

    In this version it seems to get confused and the first line is
    always short.  It seems it's taking into account the length of the
    prompt as if it were part of the text I'm typing. As a result all
    my messages look odd with a very short first line followed by
    regular length lines afterwards.

That is because the prompt is now text in the minibuffer.

I can see why the result is inconvenient for your application, and I
can see how to make it give results that are good for you.  What I am
not sure is whether we should consider it generally wrong.

Do you like the results that this patch gives?
It changes M-q in all minibuffers.  We might instead want to
change M-q only for particular minibuffer inputs.


*** fill.el	07 Sep 2006 17:19:34 -0400	1.191
--- fill.el	02 Nov 2006 15:07:19 -0500	
***************
*** 741,746 ****
--- 741,751 ----
  	       (looking-at (regexp-quote prefix))))
      (goto-char (match-end 0))))
  
+ (defun fill-minibuffer-function (arg)
+   (save-restriction 
+     (narrow-to-region (minibuffer-prompt-end) (point-max))
+     (fill-paragraph arg)))
+ 
  (defun fill-paragraph (arg)
    "Fill paragraph at or after point.  Prefix ARG means justify as well.
  If `sentence-end-double-space' is non-nil, then period followed by one
***************
*** 755,762 ****
  		 (barf-if-buffer-read-only)
  		 (list (if current-prefix-arg 'full))))
    ;; First try fill-paragraph-function.
!   (or (and fill-paragraph-function
! 	   (let ((function fill-paragraph-function)
  		 ;; If fill-paragraph-function is set, it probably takes care
  		 ;; of comments and stuff.  If not, it will have to set
  		 ;; fill-paragraph-handle-comment back to t explicitly or
--- 760,770 ----
  		 (barf-if-buffer-read-only)
  		 (list (if current-prefix-arg 'full))))
    ;; First try fill-paragraph-function.
!   (or (and (or fill-paragraph-function
! 	       (and (window-minibuffer-p (selected-window))
! 		    (= 1 (point-min))))
! 	   (let ((function (or fill-paragraph-function
! 			       'fill-minibuffer-function))
  		 ;; If fill-paragraph-function is set, it probably takes care
  		 ;; of comments and stuff.  If not, it will have to set
  		 ;; fill-paragraph-handle-comment back to t explicitly or

Re: filling inside minibuffer behaves poorly

[Gregory Stark]

Richard Stallman <rms@gnu.org> writes:

> I can see why the result is inconvenient for your application, and I
> can see how to make it give results that are good for you.  What I am
> not sure is whether we should consider it generally wrong.

I understand your concern and I'm sure I'm in a pretty small minority with
this problem. But the more I think about it I can't think of any situation
where you wouldn't want this behaviour. After all minibuffer prompts are for
inputing text that's going _somewhere_ and the prompt isn't going to be going
with it.

> Do you like the results that this patch gives?
> It changes M-q in all minibuffers.  We might instead want to
> change M-q only for particular minibuffer inputs.

It works perfectly for my use.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

Re: filling inside minibuffer behaves poorly

[Richard Stallman]

    I understand your concern and I'm sure I'm in a pretty small minority with
    this problem. But the more I think about it I can't think of any situation
    where you wouldn't want this behaviour. After all minibuffer prompts are for
    inputing text that's going _somewhere_ and the prompt isn't going to be going
    with it.

That seems like a good argument, except for one thing: in most cases
the text isn't going anywhere that you'd care about filling, so the
main purpose of filling would be to make it look nice in the
minibuffer.  And it looks nicer in the minibuffer the old way.

The appearance of the text in the minibuffer is clearly secondary to
its appearance in real use.  So if both issues arose equally often,
I'd say that the latter wins.  But what if the latter issue only
arises in a few commands, and the former can arise for all commands?
Maybe then the existing code is better.

I am not sure how to judge this, and I wonder what others think.

Re: filling inside minibuffer behaves poorly

[Mathias Dahl]

> The appearance of the text in the minibuffer is clearly secondary to
> its appearance in real use.  So if both issues arose equally often,
> I'd say that the latter wins.  But what if the latter issue only
> arises in a few commands, and the former can arise for all commands?
> Maybe then the existing code is better.
>
> I am not sure how to judge this, and I wonder what others think.

If I wanted to use filling in the minibuffer at all it would be to
have the text look nice where it is finally used/sent, in this case
some chat application. I don't really see a point in having the text
look nice in the minibuffer; after all it is only seen there for a
short while.

However, this is really core business in Emacs and it could also be
fixed in the chat application. It could fill the message before they
are sent. If the chat text ends up in another client this might be a
bad idea though (the client that receives the chat might have its own
filling or wrapping or whatever), so I would leave the filling as an
option.

Re: filling inside minibuffer behaves poorly

[John S. Yates, Jr.]

On Sat, 04 Nov 2006 01:37:01 -0500, you wrote:

>That seems like a good argument, except for one thing: in most cases
>the text isn't going anywhere that you'd care about filling, so the
>main purpose of filling would be to make it look nice in the
>minibuffer.  And it looks nicer in the minibuffer the old way.

How does tab expansion in the first line work?  Does it consider
column 1 the first character of the prompt or the first character
following the prompt?

/john

Re: filling inside minibuffer behaves poorly

[Richard Stallman]

    How does tab expansion in the first line work?  Does it consider
    column 1 the first character of the prompt or the first character
    following the prompt?

Do you mean redisplay?  It makes no distinction between the prompt
and the user input.