GNU bug report logs - #11035
24.0.94; icomplete with multiline candidates and standalone minibuffer

Previous Next

Full log

Message #11 received at 11035 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>,
	Chong Yidong <cyd <at> stupidchicken.com>
Cc: 11035 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#11035: 24.0.94;
	icomplete with multiline candidates and standalone minibuffer
Date: Sat, 17 Mar 2012 16:57:31 +0200

> Date: Sat, 17 Mar 2012 14:53:20 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 11035 <at> debbugs.gnu.org
> 
> > In Emacs 22.3, the display appears like this:
> >  
> > This is the prompt: b(bbbb candidate
> > bbbbb second line
> > )  [Matched]
> >  
> > with the cursor on the left paren, after the first `b'.  That is normal
> > (and useful).  The user can see the prompt and the input, in addition to
> > the start of the first candidate (in fact all of the first candidate, in
> > this case).
> 
> icomplete post-23 shows point at the end of the overlay.  This is a
> consequence of using multi-line overlay strings: the cursor always
> skips all but the last line of such a string.
> 
> So we need to decide whether we want to display the cursor on the left
> paren instead, in this case.

If what we want is to display the cursor on the left parenthesis after
"b" in the first line (which is what we already do when the candidates
don't include newlines), then the following patch will achieve that.

As this isn't a regression wrt Emacs 23, Stefan and Chong, please tell
if this should be installed or deferred till after 24.1.

=== modified file 'src/xdisp.c'
--- src/xdisp.c	2012-03-02 15:40:44 +0000
+++ src/xdisp.c	2012-03-17 14:32:13 +0000
@@ -18456,9 +18456,11 @@ cursor_row_p (struct glyph_row *row)
       /* Suppose the row ends on a string.
 	 Unless the row is continued, that means it ends on a newline
 	 in the string.  If it's anything other than a display string
-	 (e.g. a before-string from an overlay), we don't want the
+	 (e.g., a before-string from an overlay), we don't want the
 	 cursor there.  (This heuristic seems to give the optimal
-	 behavior for the various types of multi-line strings.)  */
+	 behavior for the various types of multi-line strings.)
+	 One exception: if the string has `cursor' property on one of
+	 its characters, we _do_ want the cursor there.  */
       if (CHARPOS (row->end.string_pos) >= 0)
 	{
 	  if (row->continued_p)
@@ -18480,6 +18482,25 @@ cursor_row_p (struct glyph_row *row)
 		    result =
 		      (!NILP (prop)
 		       && display_prop_string_p (prop, glyph->object));
+		    /* If there's a `cursor' property on one of the
+		       string's characters, this row is a cursor row,
+		       even though this is not a display string.  */
+		    if (!result)
+		      {
+			Lisp_Object s = glyph->object;
+
+			for ( ; glyph >= beg && EQ (glyph->object, s); --glyph)
+			  {
+			    EMACS_INT gpos = glyph->charpos;
+
+			    if (!NILP (Fget_char_property (make_number (gpos),
+							   Qcursor, s)))
+			      {
+				result = 1;
+				break;
+			      }
+			  }
+		      }
 		    break;
 		  }
 	    }

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.