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: [PATCH] Console based mouse face highlighting. Date: Wed, 16 May 2007 00:15:12 +0300 Message-ID: References: <17989.37070.393150.565546@kahikatea.snap.net.nz> <17990.21422.577087.305723@kahikatea.snap.net.nz> <17990.37305.657724.344516@kahikatea.snap.net.nz> <17992.53379.953892.751275@kahikatea.snap.net.nz> <17993.11948.400368.430713@kahikatea.snap.net.nz> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: sea.gmane.org 1179263730 7345 80.91.229.12 (15 May 2007 21:15:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 15 May 2007 21:15:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Nick Roberts Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 15 23:15:27 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Ho4Mg-0003Lv-OA for ged-emacs-devel@m.gmane.org; Tue, 15 May 2007 23:15:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ho4Ua-00030U-Q4 for ged-emacs-devel@m.gmane.org; Tue, 15 May 2007 17:23:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ho4UX-0002za-6t for emacs-devel@gnu.org; Tue, 15 May 2007 17:23:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ho4UU-0002zI-Ml for emacs-devel@gnu.org; Tue, 15 May 2007 17:23:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ho4UU-0002z7-Dp for emacs-devel@gnu.org; Tue, 15 May 2007 17:23:30 -0400 Original-Received: from heller.inter.net.il ([213.8.233.23]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ho4MZ-0005iX-93 for emacs-devel@gnu.org; Tue, 15 May 2007 17:15:19 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-84-229-239-87.inter.net.il [84.229.239.87]) by heller.inter.net.il (MOS 3.7.3a-GA) with ESMTP id CPC26361 (AUTH halo1); Wed, 16 May 2007 00:15:08 +0300 (IDT) In-reply-to: <17993.11948.400368.430713@kahikatea.snap.net.nz> (message from Nick Roberts on Tue, 15 May 2007 15:53:16 +1200) X-detected-kernel: FreeBSD 4.7-5.2 (or MacOS X 10.2-10.4) (2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:71123 Archived-At: > From: Nick Roberts > 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.