From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: face vs. mouse-face text property Date: Mon, 23 Jan 2012 01:48:46 -0500 Message-ID: References: <87pqegeluf.fsf@web.de> <87y5t2f7q0.fsf@web.de> <83vco52wph.fsf@gnu.org> <87bopv8jla.fsf@web.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1327301337 5313 80.91.229.12 (23 Jan 2012 06:48:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 23 Jan 2012 06:48:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: michael_heerdegen@web.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 23 07:48:52 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 1RpDi0-0005Ro-2G for ged-emacs-devel@m.gmane.org; Mon, 23 Jan 2012 07:48:52 +0100 Original-Received: from localhost ([::1]:57654 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpDhz-0004vL-LG for ged-emacs-devel@m.gmane.org; Mon, 23 Jan 2012 01:48:51 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:56898) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpDhw-0004vA-BY for emacs-devel@gnu.org; Mon, 23 Jan 2012 01:48:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpDhu-0000io-Sq for emacs-devel@gnu.org; Mon, 23 Jan 2012 01:48:48 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:41376) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpDhu-0000ik-RN for emacs-devel@gnu.org; Mon, 23 Jan 2012 01:48:46 -0500 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RpDhu-0003VC-FW; Mon, 23 Jan 2012 01:48:46 -0500 In-reply-to: <87bopv8jla.fsf@web.de> (message from Michael Heerdegen on Sun, 22 Jan 2012 23:21:05 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:147842 Archived-At: > From: Michael Heerdegen > Cc: emacs-devel@gnu.org > Date: Sun, 22 Jan 2012 23:21:05 +0100 > > > 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. Isn't that confusing, though? I think many users will not understand what they are being shown. Therefore, I think if we want to be able to display selectable newlines, we need to have a special way to display such newlines, e.g. "" or some such. > 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. These are all side effects of the fact that a newline has no glyph that is displayed on the screen. We are trying to highlight and select an object that doesn't exist on the screen. Again, if we want to handle these cases, we need some way of producing a tangible display of a newline. > - 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'. Candidates that just include newlines are not the problem. Candidates that include _only_ newlines are. Anyway, please feel free to file a wishlist bug report about this. Thanks.