all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Re: filling inside minibuffer behaves poorly
       [not found] <87ejsoxlu4.fsf@enterprisedb.com>
@ 2006-11-02 21:47 ` Richard Stallman
  2006-11-03  0:27   ` Gregory Stark
  0 siblings, 1 reply; 6+ messages in thread
From: Richard Stallman @ 2006-11-02 21:47 UTC (permalink / raw)
  Cc: emacs-devel

    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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: filling inside minibuffer behaves poorly
  2006-11-02 21:47 ` filling inside minibuffer behaves poorly Richard Stallman
@ 2006-11-03  0:27   ` Gregory Stark
  2006-11-04  6:37     ` Richard Stallman
  0 siblings, 1 reply; 6+ messages in thread
From: Gregory Stark @ 2006-11-03  0:27 UTC (permalink / raw)
  Cc: gsstark, emacs-devel


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: filling inside minibuffer behaves poorly
  2006-11-03  0:27   ` Gregory Stark
@ 2006-11-04  6:37     ` Richard Stallman
  2006-11-04  7:37       ` Mathias Dahl
  2006-11-04 18:12       ` John S. Yates, Jr.
  0 siblings, 2 replies; 6+ messages in thread
From: Richard Stallman @ 2006-11-04  6:37 UTC (permalink / raw)
  Cc: gsstark, emacs-devel

    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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: filling inside minibuffer behaves poorly
  2006-11-04  6:37     ` Richard Stallman
@ 2006-11-04  7:37       ` Mathias Dahl
  2006-11-04 18:12       ` John S. Yates, Jr.
  1 sibling, 0 replies; 6+ messages in thread
From: Mathias Dahl @ 2006-11-04  7:37 UTC (permalink / raw)
  Cc: Gregory Stark, emacs-devel

> 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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: filling inside minibuffer behaves poorly
  2006-11-04  6:37     ` Richard Stallman
  2006-11-04  7:37       ` Mathias Dahl
@ 2006-11-04 18:12       ` John S. Yates, Jr.
  2006-11-05 19:22         ` Richard Stallman
  1 sibling, 1 reply; 6+ messages in thread
From: John S. Yates, Jr. @ 2006-11-04 18:12 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: filling inside minibuffer behaves poorly
  2006-11-04 18:12       ` John S. Yates, Jr.
@ 2006-11-05 19:22         ` Richard Stallman
  0 siblings, 0 replies; 6+ messages in thread
From: Richard Stallman @ 2006-11-05 19:22 UTC (permalink / raw)
  Cc: emacs-devel

    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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2006-11-05 19:22 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <87ejsoxlu4.fsf@enterprisedb.com>
2006-11-02 21:47 ` filling inside minibuffer behaves poorly Richard Stallman
2006-11-03  0:27   ` Gregory Stark
2006-11-04  6:37     ` Richard Stallman
2006-11-04  7:37       ` Mathias Dahl
2006-11-04 18:12       ` John S. Yates, Jr.
2006-11-05 19:22         ` Richard Stallman

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.