unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Anders Lindgren <andlind@gmail.com>
To: martin rudalics <rudalics@gmx.at>
Cc: 16856@debbugs.gnu.org
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	[thread overview]
Message-ID: <CABr8ebZk27rspLV8JXExZFU45r1dapPNxUg=1gWT131NAPyARg@mail.gmail.com> (raw)
In-Reply-To: <530B24BD.7030700@gmx.at>

[-- Attachment #1: Type: text/plain, Size: 4363 bytes --]

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 <rudalics@gmx.at> 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  <mituharu@math.s.chiba-u.ac.jp>
>
>         * 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  <mituharu@math.s.chiba-u.ac.jp>
>
>         * 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
>

[-- Attachment #2: Type: text/html, Size: 5475 bytes --]

  reply	other threads:[~2014-02-24 15:12 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-23 21:39 bug#16856: 24.3.50; Cursor leaves garbage in fringe (and a request: width of fringes + scroll bar should be full characters) Anders Lindgren
2014-02-24  3:44 ` Eli Zaretskii
2014-02-24  7:41 ` martin rudalics
2014-02-24 10:12   ` Anders Lindgren
2014-02-24 10:53     ` martin rudalics
2014-02-24 15:12       ` Anders Lindgren [this message]
2014-02-26 10:15         ` martin rudalics
2014-02-26 12:51           ` Anders Lindgren
2016-05-17 18:30       ` Alan Third
2016-05-17 19:06         ` Anders Lindgren
2016-05-17 21:14           ` bug#16856: [PATCH] Prevent cursor from over-drawing the fringe Alan Third
2016-05-20 19:33             ` Anders Lindgren
2016-05-21  7:35               ` Alan Third
2016-05-21 19:07                 ` Anders Lindgren
2016-07-17  6:57 ` bug#16856: 24.3.50; Cursor leaves garbage in fringe David Reitter
2017-11-09 18:50 ` bug#16856: Enable fringe cursor when *almost* exact_window_width_line_p Keith David Bershatsky
2017-11-09 18:58   ` bug#29233: " Keith David Bershatsky
2017-11-09 22:11   ` Alan Third
2017-11-10  7:53     ` bug#16856: " Eli Zaretskii
2017-11-11 16:34       ` Anders Lindgren
2017-11-11 17:25         ` Eli Zaretskii
2017-11-11 17:49           ` Anders Lindgren
2017-11-11 18:46             ` Alan Third
2017-11-11 20:36               ` Anders Lindgren
2017-11-10  0:31   ` bug#29233: " Keith David Bershatsky
2017-11-11 22:33   ` Keith David Bershatsky
2017-11-12  4:10     ` Eli Zaretskii
2017-12-12 23:24       ` Noam Postavsky
2017-11-09 19:00 ` bug#16856: Cursor leaves garbage in fringe Keith David Bershatsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABr8ebZk27rspLV8JXExZFU45r1dapPNxUg=1gWT131NAPyARg@mail.gmail.com' \
    --to=andlind@gmail.com \
    --cc=16856@debbugs.gnu.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).