[PATCH] Console based mouse face highlighting.

[PATCH] Console based mouse face highlighting.

[Nick Roberts]

[-- Attachment #1: message body and .signature --]
[-- Type: text/plain, Size: 1190 bytes --]


Here's a patch that gives Emacs mouse functionality on a console on GNU/Linux
It does single, multiple, modified clicks and drags. Of course, t-mouse does
thisalready but with this patch Emacs uses a Unix socket to talk to Gpm, rather
than faking events using the client program mev.

I think it is worth installing for this alone but the icing on the cake would
be to add mouse highlighting and mouse tracking.  Of course, I can't quite get
that to work, and I've spent far too much time on it now, trying to get my head
around frame based glyph matrices.

If there is a display expert who could give me a few hints, or even finish it,
I'd be eternally grateful (well I'd say thank-you anyway!).  I've been abusing
x_y_to_hpos_vpos from xdisp.c for use on a text terminal, so that would be a
good place to look.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


Notes

1) CVS diff against repository at Sat May 12 21:30 (+12:00)

2) To build you need libgpm and gpm.h.  On Ubuntu these are in
   the packages gpm and gpm-dev respectively.

3) To try mouse highlighting, uncomment the call to term_mouse_highlight
   in term_mouse_movement in term.c.



[-- Attachment #2: term mouse functionality --]
[-- Type: application/octet-stream, Size: 16865 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [PATCH] Console based mouse face highlighting.

[Nick Roberts]

 > Notes
 > 
 > 1) CVS diff against repository at Sat May 12 21:30 (+12:00)

On the trunk.

Also to enable, you need to do:

M-x t-mouse-mode

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [PATCH] Console based mouse face highlighting.

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sat, 12 May 2007 22:02:54 +1200
> 
> I think it is worth installing for this alone but the icing on the cake would
> be to add mouse highlighting and mouse tracking.  Of course, I can't quite get
> that to work, and I've spent far too much time on it now, trying to get my head
> around frame based glyph matrices.
> 
> If there is a display expert who could give me a few hints

Did you look at what msdos.c does to support mouse highlight on an
otherwise text-mode display?  If not, I'd suggest to have a look.

Re: [PATCH] Console based mouse face highlighting.

[Nick Roberts]

 > Did you look at what msdos.c does to support mouse highlight on an
 > otherwise text-mode display?  If not, I'd suggest to have a look.

OK, thanks, that helped.   I've now replaced calls to x_y_to_hpos_vpos with
code in that file.  It looks a bit better now, but the mouse highlighting
is from text adjacent to the pointer, appears in a slightly different location
and only when there is some input e.g a mouse click, and remains until I do
a refresh (^L).  I have a few questions:

1) Does write_glyphs *overwrite* existing glyphs (while insert_glyphs adds
   to them) ?  It would be nice if a comment said what these functions do.

2) After a call to write_glyphs, does the cursor position move?

3) Any hints on frame updating ? (both xterm.c and msdos.c use dpyinfo)

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [PATCH] Console based mouse face highlighting.

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sun, 13 May 2007 11:54:22 +1200
> Cc: emacs-devel@gnu.org
> 
> OK, thanks, that helped.   I've now replaced calls to x_y_to_hpos_vpos with
> code in that file.  It looks a bit better now, but the mouse highlighting
> is from text adjacent to the pointer, appears in a slightly different location
> and only when there is some input e.g a mouse click, and remains until I do
> a refresh (^L).

I'm afraid I don't quite understand what you are saying here.  What do
you mean by ``mouse highlighting is from text adjacent to the
pointer''? can you show an image or describe this with a specific
example?  Also, in what ``slightly different location'' does the
highlight appear?

> 1) Does write_glyphs *overwrite* existing glyphs (while insert_glyphs adds
>    to them) ?

Yes (on both accounts).  More accurately, write_glyphs simply dumps
the glyphs to the screen (with a call to fwrite), which on a tty will
overwrite whatever is displayed in the respective screen locations,
while insert_glyphs first switches the screen to insert mode, and then
calls write_glyphs.

> It would be nice if a comment said what these functions do.

Feel free to add comments.  Personally, I think the code speaks very
well for itself (I didn't write it), but that's me.

> 2) After a call to write_glyphs, does the cursor position move?

I'm not sure.  Why is this important?  Anyway, Emacs always
repositions the cursor at point at redisplay end.

> 3) Any hints on frame updating ? (both xterm.c and msdos.c use dpyinfo)

Sorry, I don't understand the question.  Please elaborate.

Re: [PATCH] Console based mouse face highlighting.

[Nick Roberts]

 > > OK, thanks, that helped.  I've now replaced calls to x_y_to_hpos_vpos with
 > > code in that file.  It looks a bit better now, but the mouse highlighting
 > > is from text adjacent to the pointer, appears in a slightly different
 > > location and only when there is some input e.g a mouse click, and remains
 > > until I do a refresh (^L).
 > 
 > I'm afraid I don't quite understand what you are saying here.  What do
 > you mean by ``mouse highlighting is from text adjacent to the
 > pointer''? can you show an image or describe this with a specific
 > example?  Also, in what ``slightly different location'' does the
 > highlight appear?

I dont know how to make a screenshot on a text terminal but I'll try to
explain more clearly.  In dired with something like

  -rw-r--r--  1 nickrob nickrob    22289 2007-04-23 05:00 abbrev.c
  -rw-r--r--  1 nickrob nickrob   185308 2007-05-09 23:02 abbrev.o
  -rw-r--r--  1 nickrob nickrob     1311 2007-02-11 11:34 acldef.h
  -rw-r--r--  1 nickrob nickrob    14768 2004-01-31 06:10 alloca.c

The filenames have mouse face highlighting.  If I click on acldef.h, then the
text "alloca.c" might appear after abbrev.c, say, with the mouse face overlay
(green background, black foreground).  If I click on other filenames, I get
similar output (sometimes more than one filename).  These all accumulate until
I do ^L, when they disappear.

Perhaps some of my glyph row/column calculations are a bit wrong.

 > > 1) Does write_glyphs *overwrite* existing glyphs (while insert_glyphs adds
 > >    to them) ?
 > 
 > Yes (on both accounts).  More accurately, write_glyphs simply dumps
 > the glyphs to the screen (with a call to fwrite), which on a tty will
 > overwrite whatever is displayed in the respective screen locations,
 > while insert_glyphs first switches the screen to insert mode, and then
 > calls write_glyphs.
 > 
 > > It would be nice if a comment said what these functions do.
 > 
 > Feel free to add comments.  Personally, I think the code speaks very
 > well for itself (I didn't write it), but that's me.

It probably speaks for itself if you are generally familiar with terminal
control.  I'll add comments when I have a better understanding.

 > > 2) After a call to write_glyphs, does the cursor position move?
 > 
 > I'm not sure.  Why is this important?  Anyway, Emacs always
 > repositions the cursor at point at redisplay end.

I've not considered the cursor up till now and it sometimes seems to jump
around (but perhaps I'm confusing the cursor with the pointer, which are the
same shape with Gpm).

 > > 3) Any hints on frame updating ? (both xterm.c and msdos.c use dpyinfo)
 > 
 > Sorry, I don't understand the question.  Please elaborate.

I'll explore further.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [PATCH] Console based mouse face highlighting.

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sun, 13 May 2007 16:19:05 +1200
> Cc: emacs-devel@gnu.org
> 
>   -rw-r--r--  1 nickrob nickrob    22289 2007-04-23 05:00 abbrev.c
>   -rw-r--r--  1 nickrob nickrob   185308 2007-05-09 23:02 abbrev.o
>   -rw-r--r--  1 nickrob nickrob     1311 2007-02-11 11:34 acldef.h
>   -rw-r--r--  1 nickrob nickrob    14768 2004-01-31 06:10 alloca.c
> 
> The filenames have mouse face highlighting.

Does the highlight show when you move the mouse pointer above any of
these names?

> If I click on acldef.h

Why do you need to click?  Mouse highlight is supposed to happen
without any need to click.

> then the text "alloca.c" might appear after abbrev.c, say, with the
> mouse face overlay (green background, black foreground)

When you say ``after abbrev.c'', do you mean immediately to the right
of abbrev.c, or do you mean below abbrev.c, in the line occupied by
abbrev.o above?

> Perhaps some of my glyph row/column calculations are a bit wrong.

It sounds like that.  If you turn on termscript, you will see the
exact commands that are sent to the terminal driver.  You will then be
able to compare the positioning used in the initial display of the
buffer with the positions you use when you generate highlighted
glyphs.

>  > > 2) After a call to write_glyphs, does the cursor position move?
>  > 
>  > I'm not sure.  Why is this important?  Anyway, Emacs always
>  > repositions the cursor at point at redisplay end.
> 
> I've not considered the cursor up till now and it sometimes seems to jump
> around (but perhaps I'm confusing the cursor with the pointer, which are the
> same shape with Gpm).

Again, termscript will show you what cursor-positioning commands are
sent.  Also, I think the text cursor is switched off during the entire
redisplay (and you probably should turn it off when you generate
highlight, if you didn't already).

Re: [PATCH] Console based mouse face highlighting.

[Stefan Monnier]

> 1) Does write_glyphs *overwrite* existing glyphs (while insert_glyphs adds
>    to them) ?  It would be nice if a comment said what these functions do.

Please, as soon as you understand enough about this code, add a comment
explaining what you understood.

> 2) After a call to write_glyphs, does the cursor position move?

Add a note about that as well.


        Stefan "more and more convinced that commenting is the role of the
                person browsing/using/rereading the code"

Re: [PATCH] Console based mouse face highlighting.

[Nick Roberts]

 > >   -rw-r--r--  1 nickrob nickrob    22289 2007-04-23 05:00 abbrev.c
 > >   -rw-r--r--  1 nickrob nickrob   185308 2007-05-09 23:02 abbrev.o
 > >   -rw-r--r--  1 nickrob nickrob     1311 2007-02-11 11:34 acldef.h
 > >   -rw-r--r--  1 nickrob nickrob    14768 2004-01-31 06:10 alloca.c
 > > 
 > > The filenames have mouse face highlighting.
 > 
 > Does the highlight show when you move the mouse pointer above any of
 > these names?
 > 
 > > If I click on acldef.h
 > 
 > Why do you need to click?  Mouse highlight is supposed to happen
 > without any need to click.

I'm getting closer.  The help string appears now appears in the mini-buffer
when the pointer is over highlighting and I don't have to click.  The correct
text is displayed with highlighting, however, it starts where the cursor is.
The file msdos.c says:

	  /* IT_write_glyphs writes at cursor position,...

and I guess the same is true for write_glyphs in term.c.  I don't quite follow
what new_pos_X, new_pos_Y do, and their use appears to use dos calls.  In
term_mouse_show_face, I would like to do something like:

	  /* write_glyphs writes at cursor position, so we need to
	     temporarily move cursor coordinates to the beginning of
	     the highlight region.  */

	  /* Get cursor co-ordinates */
	  GET_CURSOR (pos_x, pos_y);
	  save_x = pos_x;
	  save_y = pos_x;

	  pos_x = start_hpos + WINDOW_LEFT_EDGE_X (w);
	  pos_y = row->y + WINDOW_TOP_EDGE_Y (w);
	
	  cursor_to (pos_x, pos_y);

	  draw_mouse_face = draw == DRAW_MOUSE_FACE;
	  write_glyphs (row->glyphs[TEXT_AREA] + start_hpos, nglyphs);

	  cursor_to (save_x, save_y);

but I can't find a function that does the task of GET_CURSOR and when I do
this without it, for some reason, the highlighting appears in the
minibuffer where the help string is!

Any ideas?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [PATCH] Console based mouse face highlighting.

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Tue, 15 May 2007 09:11:31 +1200
> Cc: emacs-devel@gnu.org
> 
> I'm getting closer.  The help string appears now appears in the mini-buffer
> when the pointer is over highlighting and I don't have to click.  The correct
> text is displayed with highlighting, however, it starts where the cursor is.
> The file msdos.c says:
> 
> 	  /* IT_write_glyphs writes at cursor position,...
> 
> and I guess the same is true for write_glyphs in term.c.

Yes.

> I don't quite follow what new_pos_X, new_pos_Y do, and their use
> appears to use dos calls.

They are part of the scheme that tracks the current and desired
positions of the cursor.  This comment before IT_cmgoto explains that
at some length:

    /* Emacs calls cursor-movement functions a lot when it updates the
       display (probably a legacy of old terminals where you cannot
       update a screen line without first moving the cursor there).
       However, cursor movement is expensive on MSDOS (it calls a slow
       BIOS function and requires 2 mode switches), while actual screen
       updates access the video memory directly and don't depend on
       cursor position.  To avoid slowing down the redisplay, we cheat:
       all functions that move the cursor only set internal variables
       which record the cursor position, whereas the cursor is only
       moved to its final position whenever screen update is complete.

       `IT_cmgoto' is called from the keyboard reading loop and when the
       frame update is complete.  This means that we are ready for user
       input, so we update the cursor position to show where the point is,
       and also make the mouse pointer visible.

       Special treatment is required when the cursor is in the echo area,
       to put the cursor at the end of the text displayed there.  */

You will see in the code the careful dance with current_pos_X/Y and
new_pos_X/Y both of which are used in IT_cmgoto to decide whether it
needs to invoke a system call to actually move the cursor.

> I can't find a function that does the task of GET_CURSOR and when I do
> this without it, for some reason, the highlighting appears in the
> minibuffer where the help string is!

I think curX and curY store the current location of the cursor.  They
are updated in cm.c.

Re: [PATCH] Console based mouse face highlighting.

[Nick Roberts]

 > I think curX and curY store the current location of the cursor.  They
 > are updated in cm.c.

OK, thanks.  Is cursor movement expensive on GNU/Linux?  If not, I would do
something like below in term_show_mouse_face.  That would just leave drawing
the highlighting where I've now put TODO (previously I manipulated write_glyphs
to use mouse_face_face_id but that was probably wrong).  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?  Or do I have to modify
the current glyph matrix somehow? (Which might be what xdisp.c does.)

-- 
Nick                                           http://www.inet.net.nz/~nickrob


>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);
	    }
	}

Re: [PATCH] Console based mouse face highlighting.

[Eli Zaretskii]

> 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.

Re: [PATCH] Console based mouse face highlighting.

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

"Expensive" is probably the wrong question.  With regard to CPU usage,
cursor movement on a tty will be negligible.  However, it may have
visual effects (depending on the terminal in question), and one of the
reasons for using a tty in the first place might be a lack of
bandwidth or high latency.  With regard to latency, one wants to avoid
"roundtrips", but those don't occur usually for text terminal control
sequences.  With regard to bandwidth, one might want to avoid
excessive cursor positioning, and also too many separate write calls.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [PATCH/Now RFA] Console based mouse face highlighting.

[Nick Roberts]

[-- Attachment #1: message body and .signature --]
[-- Type: text/plain, Size: 1267 bytes --]


Thanks, I've got something that seems to work now.  I read your message
afterwards, so I'm afraid I think it does modify the glyph matrix and I've not
used FRAME_TERMCAP_P.  (I'm still not sure how the iterator, glyph matrix and
write_glyphs relate.  I would have thought if I've changed the glyph matrix I
don't need to call write_glyphs but that doesn't seem to be the case.  Also if
I call write_glyphs with different values, these would get overwritten with
those from the glyph matrix when an update is done.)

Anyway I'd like to commit these changes now.  I'm confident that the patch DTRT
generally, although I'm sure there will be a few problems.  It is perhaps
timely with the imminent merge of multi-tty, and should be possible to extend
to xterms by someone who understands the difference between mev and rmev.

So could someone please try it out and say if it works for them?

-- 
Nick                                           http://www.inet.net.nz/~nickrob


1) CVS diff against repository at Wed May 16 10:26am (+12:00) (on the trunk).

2) To build you need libgpm and gpm.h.  On Ubuntu these are in
   the packages gpm and gpm-dev respectively.

3) To enable do M-x t-mouse-mode (make sure that you've byte compiled the new
    t-mouse.el first).



[-- Attachment #2: mouse highligting and help echos on a tty --]
[-- Type: application/octet-stream, Size: 16824 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [PATCH] Console based mouse face highlighting.

[Eli Zaretskii]

> Cc: Nick Roberts <nickrob@snap.net.nz>,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Tue, 15 May 2007 23:33:53 +0200
> 
> >> 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.
> 
> "Expensive" is probably the wrong question.  With regard to CPU usage,
> cursor movement on a tty will be negligible.

This is a display issue, where ``expensive'' generally means ``slow'',
not ``CPU intensive''.

> However, it may have visual effects (depending on the terminal in
> question), and one of the reasons for using a tty in the first place
> might be a lack of bandwidth or high latency.

If the link is very slow, one can always disable this feature.

Re: [PATCH/Now RFA] Console based mouse face highlighting.

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Wed, 16 May 2007 10:39:57 +1200
> Cc: emacs-devel@gnu.org
> 
> Thanks, I've got something that seems to work now.  I read your message
> afterwards, so I'm afraid I think it does modify the glyph matrix and I've not
> used FRAME_TERMCAP_P.

Too bad.

> I'm still not sure how the iterator, glyph matrix and write_glyphs
> relate.

The iterator is used to create the ``desired glyph matrix'', one that
describes what _should_have_been_ on the screen given the current
buffer contents and point position.  Then the desired matrix is diffed
against the current matrix (which describes what _is_ on the screen
now), and finally the diffs are used to update the affected portions
of the screen by calls to write_glyphs.

> I would have thought if I've changed the glyph matrix I don't need
> to call write_glyphs but that doesn't seem to be the case.

Probably because you modify the glyph matrix where Emacs doesn't
expect it to happen.  term.c is supposed to access the glyph matrix in
the read-only mode.

I actually don't understand at all why you need to modify the glyph
matrix.  What are you modifying there, exactly?

> Also if I call write_glyphs with different values, these would get
> overwritten with those from the glyph matrix when an update is
> done.)

Again, because Emacs doesn't expect the glyph matrix to change at this
point.

> Anyway I'd like to commit these changes now.

I'd be happier if you fixed the two aspects we've been talking about
(not change the glyph matrix and avoid calling this code on non-tty
frames.  I think these are really nasty bugs.  And I don't see any
reason for haste here.

Thanks for working on this.

Re: [PATCH/Now RFA] Console based mouse face highlighting.

[Nick Roberts]

 > I actually don't understand at all why you need to modify the glyph
 > matrix.  What are you modifying there, exactly?

Just the face_id.  I'm replacing it with mouse_face_face_id and putting it
back afterwards:

         term_show_mouse_face (draw)
         i loop ...

	  if(draw == DRAW_MOUSE_FACE)
	    {
	      struct glyph* glyph;
	      face_ids[i] = xmalloc (nglyphs * sizeof (int));
	      for (j = 0; j < nglyphs; j = j++)
		{
		  glyph = (row->glyphs[TEXT_AREA] + start_hpos + j);
		  face_ids[i][j] = glyph->face_id;
		  glyph->face_id = mouse_face_face_id;
		}
	    }
	  else /* draw == DRAW_NORMAL_TEXT */
	    {
	      for (j = 0; j< nglyphs; j = j++)
		{
		  (row->glyphs[TEXT_AREA] + start_hpos + j)->face_id
		    = face_ids[i][j];
		}
	      if (face_ids[i])
		{
		  xfree (face_ids[i]);
		  face_ids[i] = NULL;
		}
	    }

	  pos_y = row->y + WINDOW_TOP_EDGE_Y (w);
	  pos_x = row->used[LEFT_MARGIN_AREA] + start_hpos
	    + WINDOW_LEFT_EDGE_X (w);
	  
	  cursor_to (pos_y, pos_x);
	  write_glyphs (row->glyphs[TEXT_AREA] + start_hpos, nglyphs);

 > > Anyway I'd like to commit these changes now.
 > 
 > I'd be happier if you fixed the two aspects we've been talking about
 > (not change the glyph matrix and avoid calling this code on non-tty
 > frames.  I think these are really nasty bugs.  And I don't see any
 > reason for haste here.

Thre's no hurry, but once it's in people can, and will, tell me what's wrong
with it.  I'm not sure these are really nasty bugs: you can only open a
connection with Gpm from a Linux console, e.g., it's a no-op on X, and the
display seems pretty much to DTRT. Currently, the variable row is a row from
the current matrix, but it needn't be.  However I don't think declaring a new
struct glyph_row varable would save much.  I'm not sure what else I could do.

 > Thanks for working on this.

Thanks for the hints.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [RFA] Console based mouse face highlighting.

[Nick Roberts]

 >                                     ...However I don't think declaring a new
 > struct glyph_row varable would save much.  I'm not sure what else I could
 > do.

Actually I can do better than this, as below, which doesn't modify the glyph
matrix and does indeed eliminate some problems.

OK to apply now?

-- 
Nick                                           http://www.inet.net.nz/~nickrob


       term_show_mouse_face (draw)
       loop ...

	  if (draw == DRAW_MOUSE_FACE)
	    {
	      glyph = xmalloc (nglyphs * sizeof (struct glyph));
	      memcpy (glyph, row->glyphs[TEXT_AREA] + start_hpos,
		      nglyphs * sizeof (struct glyph));
	      for (j = 0; j < nglyphs; j = j++)
		  (glyph + j)->face_id = mouse_face_face_id;
	    }
	  else /* draw == DRAW_NORMAL_TEXT */
	      glyph = row->glyphs[TEXT_AREA] + start_hpos;

	  pos_y = row->y + WINDOW_TOP_EDGE_Y (w);
	  pos_x = row->used[LEFT_MARGIN_AREA] + start_hpos
	    + WINDOW_LEFT_EDGE_X (w);
	  
	  cursor_to (pos_y, pos_x);
	  write_glyphs (glyph, nglyphs);
	  if (draw == DRAW_MOUSE_FACE)
	    xfree (glyph);
      cursor_to (save_y, save_x);
    }

Re: [RFA] Console based mouse face highlighting.

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Wed, 16 May 2007 22:00:52 +1200
> 
>        term_show_mouse_face (draw)
>        loop ...
> 
> 	  if (draw == DRAW_MOUSE_FACE)
> 	    {
> 	      glyph = xmalloc (nglyphs * sizeof (struct glyph));
> 	      memcpy (glyph, row->glyphs[TEXT_AREA] + start_hpos,
> 		      nglyphs * sizeof (struct glyph));
> 	      for (j = 0; j < nglyphs; j = j++)
> 		  (glyph + j)->face_id = mouse_face_face_id;
> 	    }
> 	  else /* draw == DRAW_NORMAL_TEXT */
> 	      glyph = row->glyphs[TEXT_AREA] + start_hpos;
> 
> 	  pos_y = row->y + WINDOW_TOP_EDGE_Y (w);
> 	  pos_x = row->used[LEFT_MARGIN_AREA] + start_hpos
> 	    + WINDOW_LEFT_EDGE_X (w);
> 	  
> 	  cursor_to (pos_y, pos_x);
> 	  write_glyphs (glyph, nglyphs);
> 	  if (draw == DRAW_MOUSE_FACE)
> 	    xfree (glyph);
>       cursor_to (save_y, save_x);
>     }

I don't think you need to poke the face of the glyphs in the glyph
matrix to have them in mouse highlight face.  Instead, you need to
turn on the mouse highlight face before the call to fwrite that
actually delivers the glyphs to the screen.  To this end, either
modify write_glyphs to teach it to use mouse_face_face_id when that is
necessary (e.g., add an additional argument to write_glyphs), or write
a new function that is identical to write_glyphs which will use the
mouse face instead of the face encoded in the glyph matrix.

I think this will be a more elegant solution, and it also avoids
malloc'ing memory.

Re: [RFA] Console based mouse face highlighting.

[Nick Roberts]

 > I don't think you need to poke the face of the glyphs in the glyph
 > matrix to have them in mouse highlight face.  Instead, you need to
 > turn on the mouse highlight face before the call to fwrite that
 > actually delivers the glyphs to the screen.  To this end, either
 > modify write_glyphs to teach it to use mouse_face_face_id when that is
 > necessary (e.g., add an additional argument to write_glyphs), or write
 > a new function that is identical to write_glyphs which will use the
 > mouse face instead of the face encoded in the glyph matrix.
 > 
 > I think this will be a more elegant solution, and it also avoids
 > malloc'ing memory.

I can't easily add an extra argument to write_glyphs as it's called in many
places.  However, I can use a (static) global variable and this is what I did
do earlier but it didn't work because had I assumed cursor_to (x, y) when it's
actually cursor_to (y, x) i.e vertical co-ordinate first.

Do you mean something like below?  (I've tested it and it works too.)  It's
certainly more lightweght, but I think global variables tend to spoil the flow.

-- 
Nick                                           http://www.inet.net.nz/~nickrob



In term.c:

static int draw_mouse_face;



In term_show_mouse_face:

        loop ...

	  cursor_to (pos_y, pos_x);

	  if (draw == DRAW_MOUSE_FACE)
	    {
	      draw_mouse_face = 1;
	      write_glyphs (row->glyphs[TEXT_AREA] + start_hpos, nglyphs);
	      draw_mouse_face = 0;
	    }
	  else /* draw == DRAW_NORMAL_TEXT */
	    write_glyphs (row->glyphs[TEXT_AREA] + start_hpos, nglyphs);
	}
      cursor_to (save_y, save_x);



In write_glyphs:

  while (len > 0)
    {
      /* Identify a run of glyphs with the same face.  */
      int face_id = string->face_id;
      int n;

       if (draw_mouse_face)
 	{
 	  face_id = mouse_face_face_id;
 	  n = len;
 	}
       else
      for (n = 1; n < len; ++n)
	if (string[n].face_id != face_id)
	  break;

Re: [RFA] Console based mouse face highlighting.

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Thu, 17 May 2007 09:46:00 +1200
> Cc: emacs-devel@gnu.org
> 
> I can't easily add an extra argument to write_glyphs as it's called in many
> places.

But it sounds like all of them but one should be called with that
argument zero, so it shouldn't be too hard to convert them.  Am I
missing something?

> Do you mean something like below?  (I've tested it and it works too.)  It's
> certainly more lightweght, but I think global variables tend to spoil the flow.

Yes, that's what I had in mind.  But isn't it equivalent to calling
write_glyphs with the additional flag argument non-zero in just this
one place?  That would eliminate the need for a global variable.

Re: [RFA] Console based mouse face highlighting.

[Nick Roberts]

 > > I can't easily add an extra argument to write_glyphs as it's called in many
 > > places.
 > 
 > But it sounds like all of them but one should be called with that
 > argument zero, so it shouldn't be too hard to convert them.  Am I
 > missing something?

Well it means changes to write_glyphs and rif->write_glyphs in a dozen or so
places in dispnew.c, and a change to x_write_glyph in xdisp.c at least (and
perhaps w32con_write_glyphs).  If you're comfortable with those changes and
still think it's the right approach, I'll do that.

 > > Do you mean something like below?  (I've tested it and it works too.)
 > > It's certainly more lightweght, but I think global variables tend to spoil
 > > the flow.
 > 
 > Yes, that's what I had in mind.  But isn't it equivalent to calling
 > write_glyphs with the additional flag argument non-zero in just this
 > one place?  That would eliminate the need for a global variable.

Yes, I think they're equivalent.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [RFA] Console based mouse face highlighting.

[Stefan Monnier]

>> > I can't easily add an extra argument to write_glyphs as it's called in many
>> > places.
>> 
>> But it sounds like all of them but one should be called with that
>> argument zero, so it shouldn't be too hard to convert them.  Am I
>> missing something?

> Well it means changes to write_glyphs and rif->write_glyphs in a dozen or so
> places in dispnew.c, and a change to x_write_glyph in xdisp.c at least (and
> perhaps w32con_write_glyphs).  If you're comfortable with those changes and
> still think it's the right approach, I'll do that.

It doesn't seem like it'd be a big problem as such.  But I do wonder why
this is necessary now, even though it hasn't been necessary until now for
all other places where we support mouse highlighting.  So a bit of
argumentation that explains why this situation is different seems in order.
It might also help understand the code, so I'd recommend to put it
in comments.


        Stefan

Re: [RFA] Console based mouse face highlighting.

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Thu, 17 May 2007 15:54:34 +1200
> Cc: emacs-devel@gnu.org
> 
>  > But it sounds like all of them but one should be called with that
>  > argument zero, so it shouldn't be too hard to convert them.  Am I
>  > missing something?
> 
> Well it means changes to write_glyphs and rif->write_glyphs in a dozen or so
> places in dispnew.c, and a change to x_write_glyph in xdisp.c at least (and
> perhaps w32con_write_glyphs).  If you're comfortable with those changes and
> still think it's the right approach, I'll do that.

I suggested an alternative a few days ago: to add a new function, say,
write_mouse_highlighted_glyphs, which does the same as write_glyphs,
but uses the mouse face.  You could then call this function in the
only place where you now need write_glyphs to use the mouse face.
Would this solve the problem without any unnecessary overhead?

Re: [RFA] Console based mouse face highlighting.

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 17 May 2007 10:59:36 -0400
> 
> > Well it means changes to write_glyphs and rif->write_glyphs in a dozen or so
> > places in dispnew.c, and a change to x_write_glyph in xdisp.c at least (and
> > perhaps w32con_write_glyphs).  If you're comfortable with those changes and
> > still think it's the right approach, I'll do that.
> 
> It doesn't seem like it'd be a big problem as such.  But I do wonder why
> this is necessary now, even though it hasn't been necessary until now for
> all other places where we support mouse highlighting.

Actually, you will see that xdisp.c:draw_glyphs _does_ accept an
argument HL which tells it to use the mouse highlight face when
appropriate.  So at least on X and w32 this was always necessary.

msdos.c doesn't need this because it actually cheats: instead of
redrawing the glyphs with the mouse face, it pokes the video memory
with the attribute byte that changes the text colors, but leaves the
characters themselves intact (to avoid encoding them).  msdos.c can do
that because, unlike on X, it knows that the mouse face can only
change the text _colors_, so the characters themselves don't need to
be redrawn.

Re: [RFA] Console based mouse face highlighting.

[Nick Roberts]

 > > Well it means changes to write_glyphs and rif->write_glyphs in a dozen or
 > > so places in dispnew.c, and a change to x_write_glyph in xdisp.c at least
 > > (and perhaps w32con_write_glyphs).  If you're comfortable with those
 > > changes and still think it's the right approach, I'll do that.
 > 
 > It doesn't seem like it'd be a big problem as such.  

The problem is that it takes me to code that I don't really understand.

 >                                                      But I do wonder why
 > this is necessary now, even though it hasn't been necessary until now for
 > all other places where we support mouse highlighting.  So a bit of
 > argumentation that explains why this situation is different seems in order.
 > It might also help understand the code, so I'd recommend to put it
 > in comments.

As Eli says, xdisp.c uses draw_glyphs which is actually much more complicated.
I only intend to comment the code that I add because that's all I really
understand, i.e., I can't make comments about the difference with draw_glyphs.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [RFA] Console based mouse face highlighting.

[Nick Roberts]

 > > Well it means changes to write_glyphs and rif->write_glyphs in a dozen or
 > > so places in dispnew.c, and a change to x_write_glyph in xdisp.c at least
 > > (and perhaps w32con_write_glyphs).  If you're comfortable with those
 > > changes and still think it's the right approach, I'll do that.
 > 
 > I suggested an alternative a few days ago: to add a new function, say,
 > write_mouse_highlighted_glyphs, which does the same as write_glyphs,
 > but uses the mouse face.  You could then call this function in the
 > only place where you now need write_glyphs to use the mouse face.
 > Would this solve the problem without any unnecessary overhead?

That's another possibility, but it results in duplication of code (write_glyphs
is about 80 lines long) which adds to the burden of maintenance.

I think each approach has pros and cons; it's just a matter of choosing one.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [RFA] Console based mouse face highlighting.

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Fri, 18 May 2007 10:34:41 +1200
> Cc: emacs-devel@gnu.org
> 
>  > I suggested an alternative a few days ago: to add a new function, say,
>  > write_mouse_highlighted_glyphs, which does the same as write_glyphs,
>  > but uses the mouse face.  You could then call this function in the
>  > only place where you now need write_glyphs to use the mouse face.
>  > Would this solve the problem without any unnecessary overhead?
> 
> That's another possibility, but it results in duplication of code (write_glyphs
> is about 80 lines long) which adds to the burden of maintenance.

I don't think the burden is too big: write_glyphs is not a large
function, and insert_glyphs already uses this technique anyway.

> I think each approach has pros and cons; it's just a matter of choosing one.

I prefer the separate function approach.

Re: [RFA] Console based mouse face highlighting.

[Nick Roberts]

 > > I think each approach has pros and cons; it's just a matter of choosing
 > > one.
 > 
 > I prefer the separate function approach.

OK, I'l submit a patch using this one and a ChangeLog if conditions become more
favourable again.  After 22.1 I would prefer to have a team of maintainers with
a more formal approval and release process.  The current arrangement isn't
working for me, and I see no point in contributing any more if it coninues.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [RFA] Console based mouse face highlighting.

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sat, 19 May 2007 09:09:14 +1200
> Cc: emacs-devel@gnu.org
> 
>  > > I think each approach has pros and cons; it's just a matter of choosing
>  > > one.
>  > 
>  > I prefer the separate function approach.
> 
> OK, I'l submit a patch using this one and a ChangeLog if conditions become more
> favourable again.  After 22.1 I would prefer to have a team of maintainers with
> a more formal approval and release process.  The current arrangement isn't
> working for me, and I see no point in contributing any more if it coninues.

Sorry, I don't understand what caused this angry response.  Did I say
something impolite? if so, I apologize.

For the record: I have no formal approval powers; anyone with write
access to CVS can install _anything_ they want without asking me, or
even against my objections.  You asked for my advice, so I gave it to
you, but if you disagree with what I say, _I_ cannot prevent you from
committing your changes anyway.

Re: [RFA] Console based mouse face highlighting.

[Nick Roberts]

 > > OK, I'l submit a patch using this one and a ChangeLog if conditions become
 > > more favourable again.  After 22.1 I would prefer to have a team of
 > > maintainers with a more formal approval and release process.  The current
 > > arrangement isn't working for me, and I see no point in contributing any
 > > more if it coninues.
 > 
 > Sorry, I don't understand what caused this angry response.  Did I say
 > something impolite? if so, I apologize.

Sorry, it's nothing that you've said, and it's not meant to sound angry but
disillusioned.  I think having a single maintainer only works when that person
communicates clearly with his developers.  I've lost interest in trying to
guess what the trunk is for, what the status of the release is, why it hasn't
happened, or if it ever will.

 > For the record: I have no formal approval powers; anyone with write
 > access to CVS can install _anything_ they want without asking me, or
 > even against my objections.  You asked for my advice, so I gave it to
 > you, but if you disagree with what I say, _I_ cannot prevent you from
 > committing your changes anyway.

I appreciate your advice, without it I couldn't have got the patch to work.  As
it touches on core C code that I'm not very familiar with, I don't want to
commit it without some formal approval (or at least consensus) as it might be
disruptive to do so.  Maybe Richard is too busy to comment, buts that's why it
would be a good idea to have a team of global maintainers.  There are many on
this list, yourself included, who, given the opportunity, could clearly do that
job.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [RFA] Console based mouse face highlighting.

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sat, 19 May 2007 20:15:17 +1200
> Cc: emacs-devel@gnu.org
> 
> I appreciate your advice, without it I couldn't have got the patch to work.  As
> it touches on core C code that I'm not very familiar with, I don't want to
> commit it without some formal approval (or at least consensus) as it might be
> disruptive to do so.  Maybe Richard is too busy to comment, buts that's why it
> would be a good idea to have a team of global maintainers.

IMHO, we don't need Richard's approval for this patch on the trunk.
The commit policy in Emacs has always been that there's no need for
anyone's approval, formally; people who have write access to CVS are
expected to use their best judgment to decide if or when a particular
change needs to be discussed or approval for it should be sought.  At
the worst, if one makes a mistake, she might be requested to revert
the change.

So I think it's okay for you to commit these changes.  Especially
since, in this case, the changes were discussed on the list for quite
some time, and if someone, including Richard, had comments about it,
they would undoubtedly voice them by now.

Re: [RFA] Console based mouse face highlighting.

[Richard Stallman]

      I've lost interest in trying to
    guess what the trunk is for, what the status of the release is, why it hasn't
    happened, or if it ever will.

Please stop belly-aching.  If you don't want to contribute, then at
please don't keep injecting bad spirits.

Re: [RFA] Console based mouse face highlighting.

[Nick Roberts]

 > So I think it's okay for you to commit these changes.  Especially
 > since, in this case, the changes were discussed on the list for quite
 > some time, and if someone, including Richard, had comments about it,
 > they would undoubtedly voice them by now.

OK I've committed these changes to the trunk.  To see any difference you need:

1) To be in the console on GNU/Linux
2) To have gpm running
3) To have configured Emacs with both libgpm and gpm.h present and accessible.
   (Contrary to what I said earlier, on Ubuntu these are in the packages
    libgpm1 and libgpm1-dev.)

The when the mouse is over text with the mouse-face property, e.g, a file in
dired, the text should appear with a green background, and the help text
should appear in the minibuffer.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [RFA] Console based mouse face highlighting.

[Johan Bockgård]

Nick Roberts <nickrob@snap.net.nz> writes:

> OK I've committed these changes to the trunk.

I found these problems.


1. When the connection to Gpm is not open, term-close-connection
   causes a crash. (Evaluate `(term-close-connection)' twice.)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47687871279920 (LWP 25171)]
0x0000000000547ffd in delete_gpm_wait_descriptor (desc=-1) at process.c:7032
7032	  FD_CLR (desc, &input_wait_mask);



2. When t-mouse is running, evaluate 

     (track-mouse (read-event))

   Move the mouse.

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
#0  0x0000000000000000 in ?? ()
#1  0x00000000004bb6f2 in read_char (commandflag=0, nmaps=0, maps=0x0, prev_event=10402289, used_mouse_menu=0x0, end_time=0x0)
    at keyboard.c:4268
#2  0x00000000005351ee in read_filtered_event (no_switch_frame=0, ascii_required=0, error_nonascii=0, input_method=0, 
    seconds=<value optimized out>) at lread.c:504
#3  0x000000000051ad37 in Feval (form=<value optimized out>) at eval.c:2334
#4  0x000000000051b0e1 in Fprogn (args=<value optimized out>) at eval.c:447
#5  0x00000000004b9a6a in Ftrack_mouse (args=15790853) at keyboard.c:1436
#6  0x000000000051af28 in Feval (form=<value optimized out>) at eval.c:2275
#7  0x000000000051b84e in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2997
#8  0x00000000005475bb in Fbyte_code (bytestr=<value optimized out>, vector=15077793, maxdepth=141) at bytecode.c:679
#9  0x000000000051b308 in funcall_lambda (fun=9196644, nargs=1, arg_vector=0x7fffd1ad8808) at eval.c:3184
#10 0x000000000051b6e6 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:3054
#11 0x00000000005475bb in Fbyte_code (bytestr=<value optimized out>, vector=15077745, maxdepth=8) at bytecode.c:679
#12 0x000000000051b308 in funcall_lambda (fun=9197612, nargs=1, arg_vector=0x7fffd1ad89e8) at eval.c:3184
#13 0x000000000051b6e6 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:3054
#14 0x00000000005188fd in Fcall_interactively (function=10766193, record_flag=10402193, keys=10473844) at callint.c:860
#15 0x00000000004b2bda in Fcommand_execute (cmd=10766193, record_flag=10402193, keys=10402193, special=<value optimized out>)
    at keyboard.c:10116
#16 0x00000000004c00e0 in command_loop_1 () at keyboard.c:1873
#17 0x000000000051a1a4 in internal_condition_case (bfun=0x4bfd00 <command_loop_1>, handlers=10497953, 
    hfun=0x4b9cd0 <cmd_error>) at eval.c:1481
#18 0x00000000004b907a in command_loop_2 () at keyboard.c:1329
#19 0x000000000051a2a7 in internal_catch (tag=<value optimized out>, func=0x4b9060 <command_loop_2>, arg=10402193)
    at eval.c:1222
#20 0x00000000004b9b08 in command_loop () at keyboard.c:1308
#21 0x00000000004b9efa in recursive_edit_1 () at keyboard.c:1006
#22 0x00000000004b9ff9 in Frecursive_edit () at keyboard.c:1067
#23 0x00000000004ae82b in main (argc=2, argv=0x7fffd1ad94b8) at emacs.c:1762

Lisp Backtrace:
"read-event" (0x9eb991)
"track-mouse" (0xf0f305)
"eval" (0xf0f2e5)
"eval-last-sexp-1" (0x9eb991)
"eval-last-sexp" (0x9eb991)
"call-interactively" (0xa44771)


-- 
Johan Bockgård

Re: [RFA] Console based mouse face highlighting.

[Nick Roberts]

 > I found these problems.
 > 
 > 
 > 1. When the connection to Gpm is not open, term-close-connection
 >    causes a crash. (Evaluate `(term-close-connection)' twice.)
 > 
 > Program received signal SIGSEGV, Segmentation fault.
 > [Switching to Thread 47687871279920 (LWP 25171)]
 > 0x0000000000547ffd in delete_gpm_wait_descriptor (desc=-1) at process.c:7032
 > 7032	  FD_CLR (desc, &input_wait_mask);

I think that I've already fixed this problem.  Could you please update to my
last set of changes and tell me if it goes away.

 > 2. When t-mouse is running, evaluate 
 > 
 >      (track-mouse (read-event))
 > 
 >    Move the mouse.
 > 
 > Program received signal SIGSEGV, Segmentation fault.
 > 0x0000000000000000 in ?? ()

OK.  I couldn't get track-mouse to work but I didn't realised it made things
crash.  I've only seen track-mouse used for GUD tooltips.  Is it's broken state
inconveniencing you or are you just reporting a bug?  I can take those changes
out but I'd prefer to get it working first.

Does it work for you otherwise?

Thanks for the report.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [RFA] Console based mouse face highlighting.

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sun, 20 May 2007 18:00:30 +1200
> Cc: emacs-devel@gnu.org
> 
> OK I've committed these changes to the trunk.

Thanks.

> To see any difference you need:
> 
> 1) To be in the console on GNU/Linux
> 2) To have gpm running
> 3) To have configured Emacs with both libgpm and gpm.h present and accessible.
>    (Contrary to what I said earlier, on Ubuntu these are in the packages
>     libgpm1 and libgpm1-dev.)
> 
> The when the mouse is over text with the mouse-face property, e.g, a file in
> dired, the text should appear with a green background, and the help text
> should appear in the minibuffer.

I think etc/NEWS should reflect this new feature.

Renaming NEWS [was: [RFA] Console based mouse face highlighting.]

[Glenn Morris]

Eli Zaretskii wrote:

> I think etc/NEWS should reflect this new feature.

I think that if new entries are going to be added, the existing NEWS
on the trunk should (as Kim suggested a while ago) be renamed to
NEWS.22, and a new NEWS file created.

I have hesitated to do this because it will complicate Miles' syncing
of the release branch to the trunk. Such incompatibilities are probably
inevitable sooner or later though.

Re: Renaming NEWS [was: [RFA] Console based mouse face highlighting.]

[Nick Roberts]

Glenn Morris writes:
 > Eli Zaretskii wrote:
 > 
 > > I think etc/NEWS should reflect this new feature.
 > 
 > I think that if new entries are going to be added, the existing NEWS
 > on the trunk should (as Kim suggested a while ago) be renamed to
 > NEWS.22, and a new NEWS file created.
 > 
 > I have hesitated to do this because it will complicate Miles' syncing
 > of the release branch to the trunk. Such incompatibilities are probably
 > inevitable sooner or later though.

Thre's presumably no hurry for this.  I'll do it after the release.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Renaming NEWS

[Miles Bader]

Glenn Morris <rgm@gnu.org> writes:
> I think that if new entries are going to be added, the existing NEWS
> on the trunk should (as Kim suggested a while ago) be renamed to
> NEWS.22, and a new NEWS file created.
>
> I have hesitated to do this because it will complicate Miles' syncing
> of the release branch to the trunk. Such incompatibilities are probably
> inevitable sooner or later though.

It won't complicate things if the file is truly renamed, i.e., the
existing arch-targ: in NEWS is kept in NEWS.22 (and omitted from the
_new_ NEWS file).  [BTW, if you create a new file, don't add an empty
arch-tag: line or anything, just leave it out, and one will get added
during syncing.]

-miles
-- 
We have met the enemy, and he is us.  -- Pogo

Re: Renaming NEWS

[Glenn Morris]

Miles Bader wrote:

> It won't complicate things if the file is truly renamed, i.e., the
> existing arch-targ: in NEWS is kept in NEWS.22 (and omitted from the
> _new_ NEWS file).  [BTW, if you create a new file, don't add an empty
> arch-tag: line or anything, just leave it out, and one will get added
> during syncing.]

Nifty.

It also seems time (again, as Kim said earlier) for a fresh
lisp/ChangeLog and a new lisp/ChangeLog.12. The right thing to do here
is create ChangeLog.12 as a new file with no arch tag, and move most
of the current contents of ChangeLog there, right? That way, when you
sync things from lisp/ChangeLog on the release branch, they will go
into lisp/ChangeLog rather than ChangeLog.12.

What do people think the best split date is? The base of the release
branch, or perhaps 2006-12-31, to match ChangeLog.11?

BTW I'm not saying any of this needs to be done in a rush.

Re: Renaming NEWS

[David Kastrup]

Glenn Morris <rgm@gnu.org> writes:

> Miles Bader wrote:
>
>> It won't complicate things if the file is truly renamed, i.e., the
>> existing arch-targ: in NEWS is kept in NEWS.22 (and omitted from the
>> _new_ NEWS file).  [BTW, if you create a new file, don't add an empty
>> arch-tag: line or anything, just leave it out, and one will get added
>> during syncing.]
>
> Nifty.
>
> It also seems time (again, as Kim said earlier) for a fresh
> lisp/ChangeLog and a new lisp/ChangeLog.12. The right thing to do here
> is create ChangeLog.12 as a new file with no arch tag, and move most
> of the current contents of ChangeLog there, right?

Including moving the arch tag, I suppose.

> That way, when you sync things from lisp/ChangeLog on the release
> branch, they will go into lisp/ChangeLog rather than ChangeLog.12.

I don't think we really should sync anything from the release branch
for now.  Fixes should make their way from the trunk to the release
branch, not the other way round.  And they should be few enough that
synching them manually between ChangeLog and ChangeLog should be
workable (arch would presumably want to synch between ChangeLog.12 and
ChangeLog).

> What do people think the best split date is? The base of the release
> branch, or perhaps 2006-12-31, to match ChangeLog.11?

Base of release branch would be my preference.

> BTW I'm not saying any of this needs to be done in a rush.

We should do this before any branch merge, I think.

-- 
David Kastrup

Re: Renaming NEWS [was: [RFA] Console based mouse face highlighting.]

[Richard Stallman]

    I think that if new entries are going to be added, the existing NEWS
    on the trunk should (as Kim suggested a while ago) be renamed to
    NEWS.22, and a new NEWS file created.

Yes, it should be done.  There should not be any more changes
in NEWS for Emacs 22 anyway.

Re: Renaming NEWS

[Glenn Morris]

David Kastrup wrote:

> Glenn Morris <rgm@gnu.org> writes:
>
>> It also seems time (again, as Kim said earlier) for a fresh
>> lisp/ChangeLog and a new lisp/ChangeLog.12. The right thing to do here
>> is create ChangeLog.12 as a new file with no arch tag, and move most
>> of the current contents of ChangeLog there, right?
>
> Including moving the arch tag, I suppose.

No, leaving the arch tag in lisp/ChangeLog would seem to make more
sense to me. Anyone who is using this tag must expect it to refer to
the "current lisp ChangeLog", not some random ChangeLog.NN.
ChangeLog.12, which will almost never be used, should get a new arch
tag.

> I don't think we really should sync anything from the release branch
> for now.  Fixes should make their way from the trunk to the release
> branch, not the other way round. 

It has happened the other way around ever since the branch was
created, and continues to do so.

> And they should be few enough that synching them manually between
> ChangeLog and ChangeLog should be workable

People seem to find Miles' automated merging of changes from release
branch to trunk useful.

> (arch would presumably want to synch between ChangeLog.12 and
> ChangeLog).

Which is why I don't think the arch tag should be moved to ChangeLog.12.

>> What do people think the best split date is? The base of the release
>> branch, or perhaps 2006-12-31, to match ChangeLog.11?
>
> Base of release branch would be my preference.

Mine too, I think.

Re: Renaming NEWS

[Miles Bader]

Glenn Morris <rgm@gnu.org> writes:
> No, leaving the arch tag in lisp/ChangeLog would seem to make more
> sense to me. Anyone who is using this tag must expect it to refer to
> the "current lisp ChangeLog", not some random ChangeLog.NN.
> ChangeLog.12, which will almost never be used, should get a new arch
> tag.

People don't use the tag.  The tag is used by tools to establish file
identity.

In general the tag should move with the file (and will be used by arch
to move the file in a branch when merging into the branch).

If you want "ChangeLog" changes on the branch to continue to go to the
"ChangeLog" on the trunk then indeed, you're right ... but this will
complicate things to some degree with merging to other branches, because
the "contents move" on the trunk will be essentially be a huge delete
from one file (ChangeLog) and a huge add to another file (ChangeLog.12)
-- and large textual changes like that are quite brittle (e.g., the
presence of slight text differences in the ChangeLog of another branch
will cause a merge conflict for the whole huge chunk).

I guess it doesn't matter too much one way or another though; since it's
a rare event and affects few files, it's not really a big deal to fix
things up by hand.

-Miles

-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: Renaming NEWS

[Richard Stallman]

I don't want to split ChangeLog in the coming Emacs 22 release.
It is ok to split it in the trunk.

Re: [RFA] Console based mouse face highlighting.

[Johan Bockgård]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > I found these problems.
>  > 
>  > 
>  > 1. When the connection to Gpm is not open, term-close-connection
>  >    causes a crash. (Evaluate `(term-close-connection)' twice.)
>  > 
>  > Program received signal SIGSEGV, Segmentation fault.
>  > [Switching to Thread 47687871279920 (LWP 25171)]
>  > 0x0000000000547ffd in delete_gpm_wait_descriptor (desc=-1) at process.c:7032
>  > 7032	  FD_CLR (desc, &input_wait_mask);
>
> I think that I've already fixed this problem.  Could you please update to my
> last set of changes and tell me if it goes away.

There have been no changes since I tried it. Can you reproduce it?

>  > 2. When t-mouse is running, evaluate 
>  > 
>  >      (track-mouse (read-event))
>  > 
>  >    Move the mouse.
>  > 
>  > Program received signal SIGSEGV, Segmentation fault.
>  > 0x0000000000000000 in ?? ()
>
> OK. I couldn't get track-mouse to work but I didn't realised it made
> things crash. I've only seen track-mouse used for GUD tooltips. Is
> it's broken state inconveniencing you or are you just reporting a
> bug?

The latter.

> Does it work for you otherwise?

The menu bar can't be activated by clicking; dragging the
mode-line/vertical-border doesn't work.

-- 
Johan Bockgård

Re: Renaming NEWS

[Glenn Morris]

Miles Bader wrote:

> People don't use the tag.  The tag is used by tools to establish file
> identity.
>
> In general the tag should move with the file (and will be used by arch
> to move the file in a branch when merging into the branch).

I have zero experience of arch, so whatever you say. I'm going to
assume that "don't use the tag" + "in general the tag should move with
the file" means to move the existing tag in lisp/ChangeLog into
ChangeLog.12. Unless corrected...

Re: Renaming NEWS

[Glenn Morris]

Richard Stallman wrote:

> I don't want to split ChangeLog in the coming Emacs 22 release.
> It is ok to split it in the trunk.

That's what I meant to suggest.

Re: [RFA] Console based mouse face highlighting.

[Nick Roberts]

 > >  > 1. When the connection to Gpm is not open, term-close-connection
 > >  >    causes a crash. (Evaluate `(term-close-connection)' twice.)
 > >  > 
 > >  > Program received signal SIGSEGV, Segmentation fault.
 > >  > [Switching to Thread 47687871279920 (LWP 25171)]
 > >  > 0x0000000000547ffd in delete_gpm_wait_descriptor (desc=-1) at process.c:7032
 > >  > 7032	  FD_CLR (desc, &input_wait_mask);
 > >
 > > I think that I've already fixed this problem.  Could you please update to
 > > my last set of changes and tell me if it goes away.
 > 
 > There have been no changes since I tried it. Can you reproduce it?

No.  Have you recompiled t-mouse.el?

 >...
 > > Does it work for you otherwise?
 > 
 > The menu bar can't be activated by clicking; dragging the
 > mode-line/vertical-border doesn't work.

OK, I can see these.  I'll put them on my todo list.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [RFA] Console based mouse face highlighting.

[Nick Roberts]

 >  > The menu bar can't be activated by clicking; dragging the
 >  > mode-line/vertical-border doesn't work.
 > 
 > OK, I can see these.  I'll put them on my todo list.

The menu bar isn't currently recognised by Emacs as a special area.  The file
t-mouse.el previously worked by faking the mouse event.  Now it is read from
the command loop, I think Emacs needs to add ON_MENU_BAR to enum window_part
and make coordinates_in_window return it when appropriate.

I've got the function mouse-position to work but trying to drag the
mode-line/vertical-border still doesn't.

Evaluating your expression:    (track-mouse (read-event)) 

after the mouse has been moved onto part of this text gives an erroneous value
for POS-OR-AREA and TEXT-POS.  (It's always at (point-max) i.e the end of the
text.)  This might be the cause of the problem.  I'll elaborate if anyone is
interested in fixing it.


-- 
Nick                                           http://www.inet.net.nz/~nickrobff

Re: [RFA] Console based mouse face highlighting.

[Nick Roberts]

 > > Does it work for you otherwise?
 > 
 > The menu bar can't be activated by clicking; dragging the
 > mode-line/vertical-border doesn't work.

Dragging the mode-line/vertical-border should work now.  Can you please test
it?

The menubar still doesn't work.  I hope that we can get rid of tmm.el in Emacs
23 and make menus work along the lines that David Kastrup and Eli Zaretskii
suggested.  It might be a good idea to do these two things at the same tine

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [RFA] Console based mouse face highlighting.

[Richard Stallman]

    The menubar still doesn't work.  I hope that we can get rid of tmm.el in Emacs
    23 and make menus work along the lines that David Kastrup and Eli Zaretskii
    suggested.

Can you resend me that suggestion?  I don't recall what they proposed.

RE: [RFA] Console based mouse face highlighting.

[Drew Adams]

>     The menubar still doesn't work.  I hope that we can get rid
>     of tmm.el in Emacs 23 and make menus work along the lines
>     that David Kastrup and Eli Zaretskii suggested.
>
> Can you resend me that suggestion?  I don't recall what they proposed.

How about sending it (or a summary or a pointer to it) to all of us?

I too would be interested, at least. I have my own library that is similar
to (but different from ;-)) tmm.el.

Re: [RFA] Console based mouse face highlighting.

[Nick Roberts]

 >     The menubar still doesn't work.  I hope that we can get rid of tmm.el in
 >     Emacs 23 and make menus work along the lines that David Kastrup and Eli
 >     Zaretskii suggested.
 > 
 > Can you resend me that suggestion?  I don't recall what they proposed.

My understanding was that it should work like a DOS application (!), where the
menu appears as in-situ text overlaying existing text.  To see how this works
on GNU/Linux, run midnight commander or aptitude from the console. for example.

ISTR that Eli said it wouldn't be too hard to implement, but if there is no-one
willing to do it, perhaps it could be done as a future Google Summer of Code
project.  It's a somewhat vacuous suggestion as I don't have the knowldege to
mentor it.  More generally, perhaps TODO could be adapted with the Summer of
Code project in mind, where existing contributors could offer to mentor things
that they would like to see implemented.  I have no experience of this project
but I presume it is an annual thing.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [RFA] Console based mouse face highlighting.

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Mon, 4 Jun 2007 11:31:46 +1200
> Cc: emacs-devel@gnu.org, bojohan+news@dd.chalmers.se
> 
>  >     The menubar still doesn't work.  I hope that we can get rid of tmm.el in
>  >     Emacs 23 and make menus work along the lines that David Kastrup and Eli
>  >     Zaretskii suggested.
>  > 
>  > Can you resend me that suggestion?  I don't recall what they proposed.
> 
> My understanding was that it should work like a DOS application (!), where the
> menu appears as in-situ text overlaying existing text.  To see how this works
> on GNU/Linux, run midnight commander or aptitude from the console. for example.

More accurate, my suggestion was to do something similar to the MSDOS
port of Emacs.  Most of the code can be lifted from msdos.c.