From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.devel Subject: Re: face vs. mouse-face text property Date: Sun, 22 Jan 2012 23:21:05 +0100 Message-ID: <87bopv8jla.fsf@web.de> References: <87pqegeluf.fsf@web.de> <87y5t2f7q0.fsf@web.de> <83vco52wph.fsf@gnu.org> Reply-To: michael_heerdegen@web.de, emacs-devel@gnu.org NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1327270815 6298 80.91.229.12 (22 Jan 2012 22:20:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 22 Jan 2012 22:20:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 22 23:20:11 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Rp5li-0005DR-9y for ged-emacs-devel@m.gmane.org; Sun, 22 Jan 2012 23:20:10 +0100 Original-Received: from localhost ([::1]:57041 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rp5lX-0000qN-AI for ged-emacs-devel@m.gmane.org; Sun, 22 Jan 2012 17:19:59 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:38956) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rp5lU-0000qI-Aa for emacs-devel@gnu.org; Sun, 22 Jan 2012 17:19:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rp5lP-0002i6-IL for emacs-devel@gnu.org; Sun, 22 Jan 2012 17:19:56 -0500 Original-Received: from fmmailgate03.web.de ([217.72.192.234]:51341) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rp5lN-0002hi-6x; Sun, 22 Jan 2012 17:19:49 -0500 Original-Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate03.web.de (Postfix) with ESMTP id 3F9191B05D211; Sun, 22 Jan 2012 23:19:44 +0100 (CET) Original-Received: from snow ([217.185.137.245]) by smtp.web.de (mrweb002) with ESMTPA (Nemesis) id 0LfRiT-1SQfYN0ZD7-00pVuW; Sun, 22 Jan 2012 23:19:44 +0100 In-Reply-To: <83vco52wph.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 21 Jan 2012 12:09:46 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-Provags-ID: V02:K0:gJ0a70txdR1I/4aYZ6wVGmvxZwVBS5DlUJT8Yv0CN3W jIWcn3mrWkrNm5nEv49oashEjC1xzS6itPEsfdPo2xJv6Sq6S4 UeN7lEURQ7bJMjK4v0xL+WHdhmvfGfteboC014T5vh9ThgH5mg V5r891BPZ1y991oBbyshCYAxuYNs5steDza0e17PzgYaaxvkY2 PJBLjzdVIqlDnBeTituHwVZjO1Rc6XFBev8/+TnJ9M= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-Received-From: 217.72.192.234 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:147840 Archived-At: Eli Zaretskii writes: > But let's take this particular example: How would you like the newline > to be displayed for the user to understand there's a selectable > newline there? If we replace the "\n" with a "_", the *Completions* > display is like this: > > Possible completions are: > _ aaaa > bbbb cccc > > What would you say the display should look like with \n instead of _, > and which part(s) of the corresponding screen line would need to be > highlighted when the mouse hovers over the newline? Most importantly, > given the display you want to see, how would the user understand she > is suggested a selectable newline? If _ is replaced by a newline character, your example would look like that, I guess: Possible completions are: aaaa bbbb cccc since AFAIK the newline character breaks the visual line. So, the whole first line should be highlighted. The 'mouse-face property should appear exactly on the same space where a 'highlight property would be shown. Actually, this is already the case, but: the highlighting gets only "activated" when the mouse pointer is over a printable character. With other words: there is a discrepancy between what gets highlighted, and where the mouse pointer must be to get the highlighting shown. Currently, if there is a newline character, the highlighting is shown until the end of the line. But if I move the mouse pointer there, the highlighting disappears, although I never left the area of the highlighting. Besides, in the `completing-read' example, you can also _select_ the newline candidate when you click near the end of the line. So, currently, the space where the highlighting is "activated" also doesn't correspond to the space where the candidate can be selected. > Well, I asked for those _situations_ leading to these lists of > candidates to be described. TIA. - All commands that prompt for a piece of text to insert may show candidates including newlines, even empty lines. For example a command that prompts for an entry of the kill ring to insert, showing the available pieces of text as completion candidates (or clickable text). Many people use something like that. - dired. Some people like filenames including newlines. I don't, but I want that dired works for files with any name. filenames appear in *Completions* if you do C or R or something like that in dired. - In Icicles, there are many situations where candidates including newlines can appear, be it showing history items for `repeat-complex-command', or `icicle-search'. > Also, are completion candidates the only situations where these > problems arise? The original issue you raised was much more general, > AFAIU. It's not forbidden to mouse-face arbitrary multi-line text. E.g. in *ielm* or *shell*, if you move the mouse over a previous input, it is mouse-faced. There, input is allowed to be multiline. > Btw, in Emacs 23, you couldn't even select such a newline, neither > with a mouse click nor with a RET: you'd get "\naaaa" instead of a > lone "\n". In Emacs 24, at least you can select the newline alone. Good, that's an improvement. Thanks, Michael.