From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: Potential problem of minibuffer-message Date: Fri, 11 Apr 2003 11:22:01 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200304110222.LAA18413@etlken.m17n.org> References: <200304100144.KAA16944@etlken.m17n.org> <200304101344.h3ADiMe3003713@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1050027806 28592 80.91.224.249 (11 Apr 2003 02:23:26 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 11 Apr 2003 02:23:26 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Apr 11 04:23:24 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 193oC0-0007Pi-00 for ; Fri, 11 Apr 2003 04:23:04 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 193oHF-0006wq-00 for ; Fri, 11 Apr 2003 04:28:29 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 193oBV-00076q-01 for emacs-devel@quimby.gnus.org; Thu, 10 Apr 2003 22:22:33 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 193oB7-0006vy-00 for emacs-devel@gnu.org; Thu, 10 Apr 2003 22:22:09 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 193oB5-0006rZ-00 for emacs-devel@gnu.org; Thu, 10 Apr 2003 22:22:08 -0400 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 193oB5-0006mr-00 for emacs-devel@gnu.org; Thu, 10 Apr 2003 22:22:07 -0400 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2])h3B2M1o20656; Fri, 11 Apr 2003 11:22:01 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) h3B2M1A11266; Fri, 11 Apr 2003 11:22:01 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id LAA18413; Fri, 11 Apr 2003 11:22:01 +0900 (JST) Original-To: monnier+gnu/emacs@rum.cs.yale.edu In-reply-to: <200304101344.h3ADiMe3003713@rum.cs.yale.edu> (monnier+gnu/emacs@rum.cs.yale.edu) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.2.92 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:13133 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13133 In article <200304101344.h3ADiMe3003713@rum.cs.yale.edu>, "Stefan Monnier" writes: > As part of my still-in-progress rewrite of completion in elisp, > I use the following (partly taken from complete.el where it is > called PC-temp-minibuffer-message or somesuch). Ah! Your version is surely superior. But... > Note how it already works in both case: from the minibuffer or > from some other buffer. This facility is surplus in my case (i.e. in quail) because quail should show different guidance messages in a normal case and in a minibuffer case anyway. Richard Stallman writes: > These changes seem good to me. I've just installed this bug fix only. 2003-04-11 Kenichi Handa * lisp.h (temp_echo_area_glyphs): Adjust prototype. * minibuf.c (temp_echo_area_glyphs): Change the arg to Lisp string. Caller changed. I'll leave it Stefan and Richard as to these matters. o Should minibuffer-message has the same argument as message? o Should it pay attention to the case of being called from non-minibuffer? Should it automatically re-format the message to " [...]"? o Should it use minibuffer-message-timeout as timeout? For the moment, for quail, I'll use my own version quail-minibuffer-message which is the simplified version of Stefan's one. By the way, I'd like to raise these points too. o Isn't it better to take care of modified and read-only flags of the minibuffer? o If a rear-advancing overlay is in the minibufer and it has face (or any hooks) property, simply inserting a message yields an unpleasant result. It seems that we should have a new function insert-after-markers (analogous to insert-before-markers). --- Ken'ichi HANDA handa@m17n.org