Re: [PATCH] Console based mouse face highlighting.

[Eli Zaretskii <eliz@gnu.org>]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Tue, 15 May 2007 15:53:16 +1200
> Cc: emacs-devel@gnu.org
> 
> Is cursor movement expensive on GNU/Linux?

I don't think so, but in any case, it is IMO wrong to try to optimize
this case before you actually see that it slows down redisplay.  I
suggest to do it right first, and worry about speed afterwards, if
needed.

> msdos.c uses:
> 
> 	  IT_set_face (dpyinfo->mouse_face_face_id);
> 	  _farsetsel (_dos_ds);
> 	  while (nglyphs--)
> 	    {
> 	      _farnspokeb (offset, ScreenAttrib);
> 	      offset += 2;
> 	    }
> 	  if (screen_virtual_segment)
> 	    dosv_refresh_virtual_screen (start_offset, end_hpos - start_hpos);
> 
> 
> Can I write directly to the screen like this in term.c?

Not on a tty in general, no.  I'm not an expert on Linux terminals, so
perhaps you can do that there.  But again, I suggest to do it first
with straight file I/O (fwrite etc.) and only worry about direct I/O
if standard I/O is too slow.  (msdos.c has good reasons for direct
access, since file I/O would have required a switch from protected
mode to real mode and back -- because DOS system calls run DOS code
that cannot run in protected mode -- and these mode switches are
painfully slow.  Also, file I/O does not support color on MSDOS.)

> Or do I have to modify the current glyph matrix somehow?

term.c is a terminal-specific back-end of the display code (like
xterm.c is for X, w32term.c for Windows, etc.).  It is therefore
invoked when the glyph matrices were already modified, and the diffs
between the current and desired matrices were already calculated.  In
particular, mouse highlight appears in the glyph matrices as either a
text property or an overlay, and the display engine notices that and
invokes the terminal code in term.c and its ilk to redraw the affected
portions of text.  This means that when you are in term.c, you are way
past glyph matrices changing time, and should never modify them, or
you will wreak havoc on the display engine operation.

> >From term_show_mouse_face in my term.c:
> 
> 
> 	  if(draw_mouse_face == DRAW_MOUSE_FACE)
> 	    {
> 	      //TODO
> 	    }
> 	  else /* draw_mouse_face == DRAW_NORMAL_TEXT */
> 	    {
> 	      /* write_glyphs writes at cursor position, so we need to
> 		 temporarily move cursor coordinates to the beginning of
> 		 the highlight region.  */
> 
> 	      /* Save current cursor co-ordinates */
> 	      save_x = curX;
> 	      save_y = curY;
> 
> 	      pos_x = row->used[LEFT_MARGIN_AREA] + start_hpos
> 		+ WINDOW_LEFT_EDGE_X (w);
> 	      pos_y = row->y + WINDOW_TOP_EDGE_Y (w);
> 	
> 	      cursor_to (pos_x, pos_y);
> 	      write_glyphs (row->glyphs[TEXT_AREA] + start_hpos, nglyphs);
> 	      cursor_to (save_x, save_y);
> 	    }

This whole code should probably be invoked only if FRAME_TERMCAP_P,
because msdos.c does not need that and will not like being called (via
cursor_to_hook), nor should write_glyphs be called on MSDOS.  In fact,
I think the whole term_show_mouse_face should be called only for
FRAME_TERMCAP_P frames.

Also, perhaps compute `row->glyphs[TEXT_AREA] + start_hpos' only once
and reuse the value in the call to write_glyphs.  But that's
nit-picking.

Other than that, looks about right.