From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ben Key Newsgroups: gmane.emacs.devel Subject: Re: Bar Cursor Still To Narrow on Mac OS X Date: Sat, 5 Mar 2011 20:45:15 -0600 Message-ID: References: <87pqq5f7ga.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=000325557406a110c6049dc75fe6 X-Trace: dough.gmane.org 1299379566 17210 80.91.229.12 (6 Mar 2011 02:46:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 6 Mar 2011 02:46:06 +0000 (UTC) To: Chong Yidong , Emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 06 03:46:02 2011 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.69) (envelope-from ) id 1Pw3yd-0002Zv-Ot for ged-emacs-devel@m.gmane.org; Sun, 06 Mar 2011 03:45:59 +0100 Original-Received: from localhost ([127.0.0.1]:33397 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pw3yX-0005sB-Is for ged-emacs-devel@m.gmane.org; Sat, 05 Mar 2011 21:45:41 -0500 Original-Received: from [140.186.70.92] (port=58437 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pw3yT-0005s6-Lf for Emacs-devel@gnu.org; Sat, 05 Mar 2011 21:45:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pw3yS-0002Wu-HB for Emacs-devel@gnu.org; Sat, 05 Mar 2011 21:45:37 -0500 Original-Received: from mail-bw0-f41.google.com ([209.85.214.41]:40116) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pw3yS-0002Wo-Bp for Emacs-devel@gnu.org; Sat, 05 Mar 2011 21:45:36 -0500 Original-Received: by bwz17 with SMTP id 17so3488593bwz.0 for ; Sat, 05 Mar 2011 18:45:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=f1BoIbPOu/GwqGzIKJRTeWyugMBPQF0ysh3RiSgmjlU=; b=htjeD0rWGZc6E8RQvso9KjaBhXO+iA8Ma4tkSEFumddDKql4L1eSK3Vpic8XAAWwm/ evvUku+BkexCC5D6ZmeWXfVLD2zDIfKuDeuQpleTP40VvU45vVzuLYz0Vz8xOkz7ldPH kDsAKsb5Wk9fXR/WzzJGxqRn3XDz6Vgos0ri0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=jIgoPpEn1uNsx2V3yihAWG1PRPoJzvl5Yylkct6rVEJxpcP+WVNK+x3pxNCU7Wb25A bOUwxW3M+BoL0GC5bXlF1Y9/2P3YMl9ospvgnlTTD+h8yxKBO/AGsUnieB+5tBOpoXxN 2KqMu87X4NXVbI+/1ZAMyw3GIV0jARuMABNh0= Original-Received: by 10.204.19.10 with SMTP id y10mr2017365bka.190.1299379535286; Sat, 05 Mar 2011 18:45:35 -0800 (PST) Original-Received: by 10.204.14.212 with HTTP; Sat, 5 Mar 2011 18:45:15 -0800 (PST) In-Reply-To: <87pqq5f7ga.fsf@stupidchicken.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.214.41 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:136803 Archived-At: --000325557406a110c6049dc75fe6 Content-Type: text/plain; charset=ISO-8859-1 Thanks. I tested the latest change with cursor-type set to (bar . 4) and everything works as expected. I can now actually see the bar cursor without straining. Note that with the most recent changes, the cursor is not drawn correctly when the user sets the cursor-type variable to (hbar . HEIGHT). According to the documentation for the cursor-type variable, when this form is used, the number after the . is supposed to specify the "height" of the cursor, not the "width." The function get_specified_cursor_type processes this form by setting the width output parameter to the user specified width. The value assigned to the width output parameter in get_specified_cursor_type is eventually used to set the value of the cursor_width parameter when ns_draw_window_cursor is called. The expectation is that a horizontal bar cursor will be used whose height is set to the user specified height and width is set to be equal to the width of the current glyph at point. This is what happens in Emacs 23. The problem with the latest code in ns_draw_window_cursor is that the user specified value for the cursor "height" is currently also being used for the cursor "width." As a result, when cursor-type is set to (hbar . 4) the result is a 4 pixel by 4 pixel block, not a block that is 4 pixels tall and as wide as the current glyph at point. I am working on a patch that fixes this problem. --000325557406a110c6049dc75fe6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks.

I tested the latest change with cursor-type= set to (bar . 4) and everything works as expected.=A0 I can now actually s= ee the bar cursor without straining.

Note that with the most recent = changes, the cursor is not drawn correctly when the user sets the cursor-ty= pe variable to (hbar . HEIGHT).=A0 According to the documentation for the <= /font>cursor-type variable, when this form is used, the nu= mber after the . is supposed to specify the "height" of the curso= r, not the "width."

The function get_specified_cursor_type processes this form by setting t= he width output parameter to the user specified width.=A0 The value assigne= d to the width output parameter in get_specified_cu= rsor_type is eventually used to set the value of the cursor_width parameter= when ns_draw_window_cursor is called.

The expectation is that a horizontal bar cursor will b= e used whose height is set to the user specified height and width is set to= be equal to the width of the current glyph at point.=A0 This is what happe= ns in Emacs 23.

The problem with the latest code in ns_draw_window_cursor is that the u= ser specified value for the cursor "height" is currently also bei= ng used for the cursor "width."=A0 As a result, when cursor-type is set to (hbar . 4) the result is a 4 pixel by 4 p= ixel block, not a block that is 4 pixels tall and as wide as the current gl= yph at point.

I am working on a patch that fixes this problem= .

 --000325557406a110c6049dc75fe6--