From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: More enhancements to fringe bitmaps. Date: 11 Feb 2004 12:17:24 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1076494871 17790 80.91.224.253 (11 Feb 2004 10:21:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 11 Feb 2004 10:21:11 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Feb 11 11:21:04 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AqrUO-0002kk-00 for ; Wed, 11 Feb 2004 11:21:04 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AqrUN-0005UI-00 for ; Wed, 11 Feb 2004 11:21:04 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AqrRy-0003i8-O6 for emacs-devel@quimby.gnus.org; Wed, 11 Feb 2004 05:18:34 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AqrRc-0003hO-I9 for emacs-devel@gnu.org; Wed, 11 Feb 2004 05:18:12 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AqrR3-0003ax-MF for emacs-devel@gnu.org; Wed, 11 Feb 2004 05:18:08 -0500 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.24) id 1AqrR3-0003aa-2f for emacs-devel@gnu.org; Wed, 11 Feb 2004 05:17:37 -0500 Original-Received: (qmail 9374 invoked from network); 11 Feb 2004 10:17:34 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 11 Feb 2004 10:17:34 -0000 Original-To: YAMAMOTO Mitsuharu In-Reply-To: Original-Lines: 77 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:19860 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19860 YAMAMOTO Mitsuharu writes: > >>>>> On 09 Feb 2004 15:54:27 +0100, storm@cua.dk (Kim F. Storm) said: > > >> Sometimes a box cursor appears as a hollow cursor in the fringe > >> area, but I think this is not related to the above change. > > > Hm, that should only happen if you have > > cursor-in-non-selected-windows set to t. Can you find any pattern? > > Yes. (1) Launch the Carbon Emacs, (2) M-<, C-e, and hit the space bar > four times to move the cursor to the right fringe area of the first > line. (3) C-x 2 to split the window. > > Just after 2), I see a hollow box cursor (should be a filled one), and > 3) makes all cursors disappear. I couldn't reproduce these phenomena > on the X11 version. Which probably makes it hard for me to reproduce -- but I'll look into it. Is TARGET_API_MAC_CARBON defined in the setup that fails? If not, then x_flush is a dummy, and the display may not be updated correctly -- just guessing... > > By the way, bit-swapping in fringe.c is not needed for the mac port. > As a matter of fact, Carbon Emacs in CVS (without the image support > patches) has been displaying right arrows on the right fringe as left > arrows :-) So the following #ifdef (in fringe.c) shouldn't mention MAC_OS then? void init_fringe_bitmap (which, fb, once_p) enum fringe_bitmap_type which; struct fringe_bitmap *fb; int once_p; { if (once_p || fb->dynamic) { #if defined (HAVE_X_WINDOWS) || defined (MAC_OS) unsigned char *bits = fb->bits; int j; for (j = 0; j < fb->height; j++) { > > Additionally, if the start address of the bitmap data for each row > were word-aligned (by occupying 2 bytes for each row) for the mac > port, we would not need to create intermediate data for displaying > fringe bitmaps. I do see an explicit 8->16 bit conversion for W32, but not on the mac port. Do you mean this call? mac_create_bitmap_from_bitmap_data (&bitmap, bits, p->wd, p->h); Supposing that fb->bits was word aligned and 16 bits per row, what would the code for drawing the bitmap look like then? > It would be worth considering if similar things also > happen in the w32 port. I have been thinking about this and there's no fundamental reason why fringe bitmaps must be 8 bits wide (except that we always guarantee that the fringes are at least 8 bits wide if no explicit width has been set). The windows port uses 16 bits per row too, so it would probably be more generic to use that on X as well; I'll think about it. -- Kim F. Storm http://www.cua.dk