From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.bugs Subject: bug#16856: 24.3.50; Cursor leaves garbage in fringe (and a request: width of fringes + scroll bar should be full characters) Date: Mon, 24 Feb 2014 16:12:38 +0100 Message-ID: References: <530AF78F.9080102@gmx.at> <530B24BD.7030700@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d043c801ef1eed504f3286679 X-Trace: ger.gmane.org 1393254791 16272 80.91.229.3 (24 Feb 2014 15:13:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Feb 2014 15:13:11 +0000 (UTC) Cc: 16856@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 24 16:13:18 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WHxDZ-00042t-Bm for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Feb 2014 16:13:17 +0100 Original-Received: from localhost ([::1]:58191 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHxDY-0007VM-FY for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Feb 2014 10:13:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHxDR-0007SR-1c for bug-gnu-emacs@gnu.org; Mon, 24 Feb 2014 10:13:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WHxDK-0002k6-Fb for bug-gnu-emacs@gnu.org; Mon, 24 Feb 2014 10:13:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36762) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHxDK-0002jn-D1 for bug-gnu-emacs@gnu.org; Mon, 24 Feb 2014 10:13:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WHxDK-00031n-0e for bug-gnu-emacs@gnu.org; Mon, 24 Feb 2014 10:13:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Feb 2014 15:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16856 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16856-submit@debbugs.gnu.org id=B16856.139325477011621 (code B ref 16856); Mon, 24 Feb 2014 15:13:01 +0000 Original-Received: (at 16856) by debbugs.gnu.org; 24 Feb 2014 15:12:50 +0000 Original-Received: from localhost ([127.0.0.1]:37944 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WHxD6-00031M-Gd for submit@debbugs.gnu.org; Mon, 24 Feb 2014 10:12:49 -0500 Original-Received: from mail-wi0-f174.google.com ([209.85.212.174]:38203) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WHxD2-000316-AA for 16856@debbugs.gnu.org; Mon, 24 Feb 2014 10:12:46 -0500 Original-Received: by mail-wi0-f174.google.com with SMTP id f8so3184380wiw.13 for <16856@debbugs.gnu.org>; Mon, 24 Feb 2014 07:12:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KoxgkAa1D32mEVQDyfPNbie8c76hGJVo+2aBlYrYqbM=; b=DO4DFOp1u7adxnhnjFpW3I3XVB55e5LgtTjMR67EBma1RoM2N+47uE1wtnh4eeLM1J J7mKMbeyqKRYGMWZT8JiDlqpY0YeJlLCAXxaiAcbW1tkxtgqDirU79h5xO/FJe/5xxic 5peNLJRceHLoDfxImUnodQYCP8zZ3JGdymL/BW7xUhTV4os5uStiiV7R0lVL/MFnE+ul 0MParpW2QruHaXj0T/D0Htw47Qyk009XHAcfyS4qCq0LUfS4Al7vSld3AwVCpMJQMZdJ 1GV4PRuFTe3uduTP4Noztcv5yFYRPlx4RBptrqTPQuxixrMOJMdRrUGgeZOmTYPThidJ 7qrw== X-Received: by 10.180.77.129 with SMTP id s1mr14762877wiw.56.1393254758213; Mon, 24 Feb 2014 07:12:38 -0800 (PST) Original-Received: by 10.217.110.131 with HTTP; Mon, 24 Feb 2014 07:12:38 -0800 (PST) In-Reply-To: <530B24BD.7030700@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:86128 Archived-At: --f46d043c801ef1eed504f3286679 Content-Type: text/plain; charset=ISO-8859-1 Ok, I think that I understand more of how the new layout works, and that I need to work on the pixel level. Hence, I drop my request to make the width of the fringes + scroll bars a multiple of the frame character width. The problem with the cursor leaving garbage in the right fringe still remains, though. -- Anders On Mon, Feb 24, 2014 at 11:53 AM, martin rudalics wrote: > >> The pixel widths of fringes and scrollbars are customizable on a per > >> frame/window basis so you should be able to set them up on you system > >> as you need. Does that fail? > > > > > > Well, it's much more work to handle things on the pixel level than > working > > with characters as the base unit. > > > > For example, I'm currently writing a package to set up multiple > > side-by-size windows. When figuring out a suitable frame width, I used to > > multiply the number of side-by-side windows with the sum of the column > > width and the width (in characters) of the fringe and scroll bars, to get > > the number of characters to set the width to. Now, I would have to work > on > > the pixel level to do this properly -- this is much more error prone and > I > > can't use the code on old Emacs versions. > > If you do that, you already preclude your code from working correctly on > maximized or fullscreen frames. These might have widths that are not an > integral multiple of your character widths. And toolkit scrollbars may > have a width that is not an integral multiple either - so you would have > to adjust the combined size anyway. > > > > It doesn't help that functions doesn't seem to be designed to work > > together, for example I would expect: > > (set-frame-size (selected-frame) (frame-pixel-width) > > (frame-pixel-height) t)' > > to be a no-op, but instead the frame increases its size both on the width > > and on the height. > > `set-frame-size' expects as argument the new _text_ width of the frame > and adds the width of fringes, a scrollbar and internal borders to that. > > > > Another argument of not having a "odd" width is that when splitting > windows > > side-by-side, you will end up with an unused gap to the right of almost a > > full character. Steps to repeat: > > > > emacs -Q > > (setq truncate-partial-width-windows nil) C-j > > C-x 3 > > > > Here, the right window have an unused space between the rightmost > > character and the fringe, the space is almost a character wide. It's not > > possible to resize the frame manually to correct this, as the frame can > > only be resized full characters (as it should be). (When > > `truncate-partial-width-windows' is t, the gap is used to display a > partial > > character.) > > > > To conclude, I would be much happier if the sum of the fringes and the > > scroll bar would be an even five characters rather than five characters > and > > one pixel, as it is today. > > > > The question is if this is due to some display bug (maybe OS X specific) > or > > if this is the way it is supposed to work now? > > This used to happen with Emacs 24.3 here and should be gone now. But OS > X still has the old extended fringes code in place - maybe that > interferes. Could you try to remove it - I can't compile for OS X so I > won't do that. If you want to know how, have a look at these changes: > > 2013-12-02 YAMAMOTO Mitsuharu > > * xterm.h (struct scroll_bar): Remove member `fringe_extended_p'. > > * xterm.c (x_draw_fringe_bitmap, x_scroll_run): Remove code for > fringe background extension. > (x_scroll_bar_create): Remove variables `sb_left' and `sb_width', > because they are now always the same as `left' and `width', > respectively. Remove code for the case that `width' and > `sb_width' are different. > > 2013-12-21 YAMAMOTO Mitsuharu > > * w32term.h (struct scroll_bar): Remove member `fringe_extended_p'. > > * w32term.c (w32_draw_fringe_bitmap, x_scroll_run): Remove code for > fringe background extension. > (x_scroll_bar_create): Remove variables `sb_left' and `sb_width', > because they are now always the same as `left' and `width', > respectively. Remove code for the case that `width' and > `sb_width' are different. > > martin > --f46d043c801ef1eed504f3286679 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ok, I think that I understand more of how the new layout w= orks, and that I need to work on the pixel level. Hence, I drop my request = to make the width of the fringes + scroll bars a multiple of the frame char= acter width.

The problem with the cursor leaving garbage in the right fri= nge still remains, though.

=A0 =A0 -- Anders
=


On Mon,= Feb 24, 2014 at 11:53 AM, martin rudalics <rudalics@gmx.at> w= rote:
>> The pixel widths of= fringes and scrollbars are customizable on a per
>> frame/window basis so you should be able to set them up on you sys= tem
>> as you need. =A0Does that fail?
>
>
> Well, it's much more work to handle things on the pixel level than= working
> with characters as the base unit.
>
> For example, I'm currently writing a package to set up multiple > side-by-size windows. When figuring out a suitable frame width, I used= to
> multiply the number of side-by-side windows with the sum of the column=
> width and the width (in characters) of the fringe and scroll bars, to = get
> the number of characters to set the width to. Now, I would have to wor= k on
> the pixel level to do this properly -- this is much more error prone a= nd I
> can't use the code on old Emacs versions.

If you do that, you already preclude your code from working correctly on maximized or fullscreen frames. =A0These might have widths that are not an<= br> integral multiple of your character widths. =A0And toolkit scrollbars may have a width that is not an integral multiple either - so you would have to adjust the combined size anyway.


> It doesn't help that functions doesn't seem to be designed to = work
> together, for example I would expect:
> =A0 =A0 (set-frame-size (selected-frame) (frame-pixel-width)
> (frame-pixel-height) t)'
> to be a no-op, but instead the frame increases its size both on the wi= dth
> and on the height.

`set-frame-size' expects as argument the new _text_ width of the frame<= br> and adds the width of fringes, a scrollbar and internal borders to that.

> Another argument of not having a "odd" width is that when sp= litting windows
> side-by-side, you will end up with an unused gap to the right of almos= t a
> full character. Steps to repeat:
>
> =A0 =A0 emacs -Q
> =A0 =A0 (setq truncate-partial-width-windows nil) C-j
> =A0 =A0 C-x 3
>
> =A0 =A0 =A0 =A0 Here, the right window have an unused space between th= e rightmost
> character and the fringe, the space is almost a character wide. It'= ;s not
> possible to resize the frame manually to correct this, as the frame ca= n
> only be resized full characters (as it should be). (When
> `truncate-partial-width-windows' is t, the gap is used to d= isplay a partial
> character.)
>
> To conclude, I would be much happier if the sum of the fringes and the=
> scroll bar would be an even five characters rather than five character= s and
> one pixel, as it is today.
>
> The question is if this is due to some display bug (maybe OS X specifi= c) or
> if this is the way it is supposed to work now?

This used to happen with Emacs 24.3 here and should be gone now. =A0But OS<= br> X still has the old extended fringes code in place - maybe that
interferes. =A0Could you try to remove it - I can't compile for OS X so= I
won't do that. =A0If you want to know how, have a look at these changes= :

2013-12-02 =A0YAMAMOTO Mitsuharu =A0<mituharu@math.s.chiba-u.ac.jp>= ;

=A0 =A0 =A0 =A0 * xterm.h (struct scroll_bar): Remove member `fringe_extend= ed_p'.

=A0 =A0 =A0 =A0 * xterm.c (x_draw_fringe_bitmap, x_scroll_run): Remove code= for
=A0 =A0 =A0 =A0 fringe background extension.
=A0 =A0 =A0 =A0 (x_scroll_bar_create): Remove variables `sb_left' and `= sb_width',
=A0 =A0 =A0 =A0 because they are now always the same as `left' and `wid= th',
=A0 =A0 =A0 =A0 respectively. =A0Remove code for the case that `width' = and
=A0 =A0 =A0 =A0 `sb_width' are different.

2013-12-21 =A0YAMAMOTO Mitsuharu =A0<mituharu@math.s.chiba-u.ac.jp>= ;

=A0 =A0 =A0 =A0 * w32term.h (struct scroll_bar): Remove member `fringe_exte= nded_p'.

=A0 =A0 =A0 =A0 * w32term.c (w32_draw_fringe_bitmap, x_scroll_run): Remove = code for
=A0 =A0 =A0 =A0 fringe background extension.
=A0 =A0 =A0 =A0 (x_scroll_bar_create): Remove variables `sb_left' and `= sb_width',
=A0 =A0 =A0 =A0 because they are now always the same as `left' and `wid= th',
=A0 =A0 =A0 =A0 respectively. =A0Remove code for the case that `width' = and
=A0 =A0 =A0 =A0 `sb_width' are different.

martin

--f46d043c801ef1eed504f3286679--