From xemacs-m  Sun Mar 23 17:12:53 1997
Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id RAA09205
	for <xemacs-beta@xemacs.org>; Sun, 23 Mar 1997 17:12:52 -0600 (CST)
Received: from sdnp5.ucsd.edu (sdnp5.ucsd.edu [132.239.79.10]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with SMTP id PAA19537 for <xemacs-beta@xemacs.org>; Sun, 23 Mar 1997 15:12:52 -0800 (PST)
Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4)
	id PAA04857; Sun, 23 Mar 1997 15:14:46 -0800
Sender: dmoore@sdnp5.ucsd.edu
To: xemacs-beta@xemacs.org
Subject: Re: patches to compile.el
References: <199703230329.WAA05074@pochacco.alphatech.com> <m267yimdxs.fsf@altair.xemacs.org>
X-Face: "oX;zS#-JU$-,WKSzG.1gGE]x^cIg!hW.dq>.f6pzS^A+(k!T|M:}5{_%>Io<>L&{hO7W4cicOQ|>/lZ1G(m%7iaCf,6Qgk0%%Bz7b2-W3jd0m_UG\Y;?]}4s0O-U)uox>P3JN)9cm]O\@,vy2e{`3pb!"pqmRy3peB90*2L
Mail-Copies-To: never
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
From: David Moore <dmoore@ucsd.edu>
Date: 23 Mar 1997 15:14:44 -0800
In-Reply-To: Steven L Baur's message of 23 Mar 1997 14:38:39 -0800
Message-ID: <rvohcaxkt7.fsf@sdnp5.ucsd.edu>
Lines: 54
X-Mailer: Gnus v5.4.33/XEmacs 19.15(beta103)

Steven L Baur <steve@miranova.com> writes:

> /* Useless FSFmacs functions */
> /* More than useless.  I've nuked minibuf_prompt_width so they won't
>    function at all in XEmacs at the moment.  They are used to
>    implement some braindamage in FSF which we aren't including. --cet */
> 
> #if 0
> xxDEFUN ("minibuffer-prompt", Fminibuffer_prompt, Sminibuffer_prompt, 0, 0, 0,
>   "Return the prompt string of the currently-active minibuffer.\n"

Well, uncomenting this won't break anything (well once you fix the old
style DEFUN).  The question therefore is what is the motivation for
having it or not.  I can see how minibuf_prompt_width is certainly a
questionable thing to try to provide, but not minibuffer-prompt.

But letting routines know the text of the prompt message seems
reasonable to me.  I could see someone wanting a routine that logged the
prompts they were shown.  Or a generic routine could be hung off the
minibuffer mode map to do certain forms of user specific completion.
This routine might look at the prompt to pick from a collection of user
specified completion methods.

An external function might look at the prompt and decide not to do
something while the user is at a prompt.  For example, gnus might choose
to not run demon processes when the prompt is set.


What is to be gained by leaving it disabled?  I can see how removing the
width is reasonable, since width isn't well defined with proportional
fonts.  Of course, we have functions which tell you a meaningless width
of a face.

It has occured to me that the particular use for rsz-minibuf probably
won't work with a proportional minibuffer font.  But then probably none
of rsz-minibuf will work correctly in that situation.


PS.  Should things really be calling `gettext' repeatedly?  For example
yes-or-no-p calls gettext on the prompt and slaps some more text on it.
It then passes the combined prompt to read-from-minibuffer which calls
gettext on that.  Eventually read-minibuffer-internal gets this again
and calls LISP_GETTEXT on it.  I realize the gettext stuff isn't working
currently, but should it be used like that?  The situation looks like
for yes-or-no-p looks like:

(gettext (gettext (concat (gettext prompt) (gettext "(yes or no ")))))


-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | In a cloud bones of steel.

