GNU bug report logs - #27830
26.0.50; Left fringe gets truncated by a pixel in window not sharing that edge with frame

Previous Next

Full log

Message #35 received at 27830 <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>, 27830 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: 26.0.50; Left fringe gets truncated by a pixel in window not
 sharing that edge with frame
Date: Thu, 05 Oct 2017 11:46:45 +0000

[Message part 1 (text/plain, inline)]

On Thu, Oct 5, 2017 at 4:11 AM martin rudalics <rudalics <at> gmx.at> wrote:

>  > The screenshots attached in my previous email show the truncation arrows
>  > with/without scrollbars.. they look the same in both cases to me (see
>  > below, without scrollbars on left, and with, on right):
>  >
>  > I am using diff-hl-mode because the truncation is very evident as you
> see
>  > in that same image.
>  >
>  > [image: image.png]
>
> Unfortunately, I don't see any image here.
>

I think that's partially responsible for some miscommunication between us.
debbugs doesn't show the images inline in the messages (as I see them in
Google Inbox when I am sending the emails). debbugs instead just creates an
attachment named image.png for each inline image.

In a later email, you mention that you can see the above reference image,
but just for clarity, this is the one:
https://debbugs.gnu.org/cgi/bugreport.cgi?att=2;msg=17;bug=27830;filename=image.png


>  > Oh no, can this be please fixed in emacs 26.1? I am pretty sure that
> people
>  > using emacs without scroll bars and without window dividers are not in
>  > minority. This artifact will be pretty evident to people using fringe
>  > elements like in diff-hl-mode.
>  >
>  > @Eli: Can this be a blocker for 26.1?
>
> This behavior has been with us ever since the vertical border has been
> used for GUI frames so it hardly qualifies as a blocker for the release.
>

I understand. I thought this was a regression in 26, because I started
using the native line number implementation.

Earlier (in emacs 25), when using nlinum, this was the order of window
elements:

    | line num | fringe | window text | ..

In emacs 26, when using native line numbers, this became the order of
window elements:

    | fringe | line num | window text | ..

So the issue was essentially masked earlier if you were using line numbers
using (n)linum.

I confirm that this issue was in emacs 25.1 too. Sorry for the drastic
measure suggestion.
-- 

Kaushal Modi

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.