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

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Kaushal Modi
Hello,

In the past month or two, I have noticed that left edge of the fringe gets cut by a pixel if that fringe is on the the left-most window (i.e. not in a window that shares the left edge of the frame too).

While this might seem nitpicky, that is very evident when using a package that diff-hl that shows the uncommited changed lines in the fringe.

Step 0: Please eval the below macro.. it's just a helper to install the needed package.

(defmacro emacs-pkg-debug-setup (pkg-alist &rest body)
  "Install packages in PKG-ALIST and evaluate BODY.
Each element of PKG-ALIST has the form (((ID . LOCATION) . (PKG1 PKG2 ..)) ..).
The ID and LOCATION are the same as the ones in `package-archives'.
PKG1, PKG2, .. are package names from the ID archive.

Example usage:

1. Launch 'emacs -Q'.
2. Copy this macro definition to its scratch buffer and evaluate it.
3. Evaluate a minimum working example using this macro as below:
     (emacs-pkg-debug-setup '(;; Install hydra from GNU Elpa
                              (nil . (hydra))
                              ;; Install org from Org Elpa
                              ((\"org\" . \"<a href="http://orgmode.org/elpa/\">http://orgmode.org/elpa/\") . (org)))
       ;; Then evaluate the below forms
       (org-mode)) "
  (declare (indent 1) (debug t))
  `(progn
     (require 'package)
     (setq user-emacs-directory (concat temporary-file-directory
                                        (getenv "USER") "/" ".emacs.d-debug/"))
     (setq package-user-dir (format "%selpa_%s/"
                                    user-emacs-directory emacs-major-version))
     (let (archive pkgs)
       (dolist (archive-alist ,pkg-alist)
(setq archive (car archive-alist))
(when archive
           (add-to-list 'package-archives archive :append))
         (setq pkgs (append pkgs (cdr archive-alist))))
       (package-initialize)
       (package-refresh-contents)

       (dolist (pkg pkgs)
         (when (and pkg (not (package-installed-p pkg)))
           (package-install pkg))
         (require pkg))

       ,@body)))

;; Step 1: Eval above macro and then the below form
(emacs-pkg-debug-setup '((nil . (diff-hl)))
  (scroll-bar-mode -1)
  (message "Done!"))

(PS: You may skip Steps 0 and 1 and do these instead manually, and then proceed to Step 2.)
i. Install diff-hl in emacs -Q
ii. (scroll-bar-mode -1)
 
Step 2: Open a git controlled file, make some changes and save it
Step 3: Eval: (diff-hl-mode)
Step 4: Split the window: C-x 3

image.png

Notice how the green bracket in the fringe covering the changed line looks on the left window (sharing the left edge with frame), and how the window divider overlaps the vertical line of the green bracket in the fringe in the right-hand-side window.

This did not happen in emacs 25.x or until "recently" (about a month or two back).

I am copying Dmitry (author of diff-hl package) as he also has seen this issue happen: https://github.com/dgutov/diff-hl/issues/94#issuecomment-317815076

Also copying Martin as my gut feeling says that he would know exactly what's going on here as it has to do with windows and frames :) My apologies if I shouldn't have copied you.

Thanks.

In GNU Emacs 26.0.50 (build 17, x86_64-pc-linux-gnu, GTK+ Version 2.24.23)
 of 2017-07-25
Repository revision: 6dc5d45c542a6f9cfbcf3e37d597c9e0efb3070d
Windowing system distributor 'The X.Org Foundation', version 11.0.60900000
System Description: Red Hat Enterprise Linux Workstation release 6.6 (Santiago)

Recent messages:
nil
next-line: End of buffer
C-x 3 runs the command split-window-right
C-x 2 runs the command split-window-below
C-x 3 runs the command split-window-right
Mark set [2 times]
Saved text until "mode)
;; Step 4: Split the window: C-x 3"
Mark set
Making completion list...

Configured using:
 'configure --with-modules
 --prefix=/home/kmodi/usr_local/apps/6/emacs/master
 '--program-transform-name=s/^ctags$/ctags_emacs/'
 'CPPFLAGS=-I/home/kmodi/usr_local/6/include -I/usr/include/freetype2
 -I/usr/include' 'CFLAGS=-ggdb3 -O0' 'CXXFLAGS=-ggdb3 -O0'
 'LDFLAGS=-L/home/kmodi/usr_local/6/lib -L/home/kmodi/usr_local/6/lib64
 -ggdb3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK2 X11 MODULES

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  override-global-mode: t
  diff-auto-refine-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug sendmail help-fns two-column iso-transl
help-mode cl-print debug use-package pcase warnings diminish bind-key cl
diff-hl-dired diff advice diff-hl edmacro kmacro face-remap vc-hg vc-git
vc-dir ewoc vc vc-dispatcher diff-mode compile comint ansi-color ring
easy-mmode autoload radix-tree lisp-mnt tar-mode cus-edit cus-start
cus-load wid-edit mm-archive message dired dired-loaddefs format-spec
rfc822 mml mml-sec epa derived gnus-util rmail rmail-loaddefs mailabbrev
gmm-utils mailheader mm-decode mm-bodies mm-encode mail-utils
network-stream starttls url-http tls gnutls mail-parse rfc2231 rfc2047
rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm subr-x puny url-cache
url-auth url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util mailcap epg finder-inf package easymenu
epg-config url-handlers url-parse auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib time-date mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote dbusbind inotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 233359 43074)
 (symbols 48 30364 1)
 (miscs 40 83 524)
 (strings 32 69880 4520)
 (string-bytes 1 1857461)
 (vectors 16 32959)
 (vector-slots 8 1451073 140058)
 (floats 8 72 562)
 (intervals 56 1170 64)
 (buffers 992 18)
 (heap 1024 47444 8353))

--

Kaushal Modi

Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
 > In the past month or two, I have noticed that left edge of the fringe gets
 > cut by a pixel if that fringe is on the the left-most window (i.e. not in a
 > window that shares the left edge of the frame too).

...

 > Notice how the green bracket in the fringe covering the changed line looks
 > on the left window (sharing the left edge with frame), and how the window
 > divider overlaps the vertical line of the green bracket in the fringe in
 > the right-hand-side window.
 >
 > This did not happen in emacs 25.x or until "recently" (about a month or two
 > back).

 From the attached image it's easy to see that both fringes of the window
on the right miss one pixel.  Please try:

- C-x 3 with emacs -Q

- C-x 3 with emacs -Q and scrollbars disabled

and look at the right edge of any truncation glyphs in the window on the
right.  I suppose that the diff-hl fringe customizations are needed to
reproduce the problem but who knows.

Next, on the frame shown in your image do another C-x 3 so we can tell
whether only the rightmost window is affected.  Also, please
double-check whether disabling the scroll bars is needed to show the
effect.

Finally, on the frame shown in your image, do

M-: (window--dump-frame)

This should get you a buffer *window-frame-dump*.  Please post its
contents here.

Thanks, martin



Reply | Threaded
Open this post in threaded view
|

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

Kaushal Modi
Hi Martin,

Thank you for the great reply on the "next steps" for me to execute. I apologize for the late reply.

On Wed, Jul 26, 2017 at 3:53 AM martin rudalics <[hidden email]> wrote:
 
 From the attached image it's easy to see that both fringes of the window
on the right miss one pixel. 

I fail to see that without the diff-hl-mode example.
 
Please try:

- C-x 3 with emacs -Q

- C-x 3 with emacs -Q and scrollbars disabled

I tried that, but nothing stood out.
 
and look at the right edge of any truncation glyphs in the window on the
right.  I suppose that the diff-hl fringe customizations are needed to
reproduce the problem but who knows.

Next, on the frame shown in your image do another C-x 3 so we can tell
whether only the rightmost window is affected. 

Below images and animation are after following the emacs -Q recipe I posted earlier - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27830#5


image.png

As seen above (figure attached), any window not sharing the edge the with frame sees that ~1 pixel truncation.
 
Also, please double-check whether disabling the scroll bars is needed to show the
effect.

Yes!

With scroll bars enabled, the diff-hl-mode glyphs show up fine without truncation (see attached):
image.png

Finally, here's also a GIF (different from the one in the other bug report https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28605#38 )


Finally, on the frame shown in your image, do

M-: (window--dump-frame)

This should get you a buffer *window-frame-dump*.  Please post its
contents here.

Here is the frame dump with scroll bars disabled:

frame pixel: 656 x 540   cols/lines: 82 x 36   units: 8 x 15
frame text pixel: 640 x 540   cols/lines: 80 x 36
tool: 0  scroll: 0/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 5>   parent: nil
pixel left: 0   top: 0   size: 656 x 525   new: 656
char left: 0   top: 0   size: 82 x 35   new: 82
normal: 1.0 x 1.0   new: nil

#<window 3 on init.el>   parent: #<window 5>
pixel left: 0   top: 0   size: 328 x 525   new: 328
char left: 0   top: 0   size: 41 x 35   new: 41
normal: 0.5 x 1.0   new: nil
body pixel: 312 x 510   char: 39 x 34
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 15  divider: 0

#<window 6 on init.el>   parent: #<window 5>
pixel left: 328   top: 0   size: 168 x 525   new: 168
char left: 41   top: 0   size: 21 x 35   new: 21
normal: 0.25 x 1.0   new: 0.25
body pixel: 152 x 510   char: 19 x 34
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 15  divider: 0

#<window 7 on init.el>   parent: #<window 5>
pixel left: 496   top: 0   size: 160 x 525   new: 160
char left: 62   top: 0   size: 20 x 35   new: 20
normal: 0.25 x 1.0   new: 0.25
body pixel: 144 x 510   char: 18 x 34
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 15  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 525   size: 656 x 15   new: 0
char left: 0   top: 35   size: 82 x 1   new: 82
normal: 1.0 x 1.0   new: 0
body pixel: 640 x 15   char: 80 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 0  divider: 0



Here's the same after *enabling* scroll bars:

frame pixel: 672 x 540   cols/lines: 84 x 36   units: 8 x 15
frame text pixel: 640 x 540   cols/lines: 80 x 36
tool: 0  scroll: 16/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 8>   parent: nil
pixel left: 0   top: 0   size: 672 x 525   new: 672
char left: 0   top: 0   size: 84 x 35   new: 84
normal: 1.0 x 1.0   new: nil

#<window 3 on init.el>   parent: #<window 8>
pixel left: 0   top: 0   size: 168 x 525   new: 168
char left: 0   top: 0   size: 21 x 35   new: 21
normal: 0.25 x 1.0   new: nil
body pixel: 136 x 510   char: 17 x 34
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 16  divider: 0
height header-line: 0  mode-line: 15  divider: 0

#<window 10 on init.el>   parent: #<window 8>
pixel left: 168   top: 0   size: 168 x 525   new: 168
char left: 21   top: 0   size: 21 x 35   new: 21
normal: 0.25 x 1.0   new: nil
body pixel: 136 x 510   char: 17 x 34
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 16  divider: 0
height header-line: 0  mode-line: 15  divider: 0

#<window 9 on init.el>   parent: #<window 8>
pixel left: 336   top: 0   size: 336 x 525   new: 336
char left: 42   top: 0   size: 42 x 35   new: 42
normal: 0.5 x 1.0   new: nil
body pixel: 304 x 510   char: 38 x 34
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 16  divider: 0
height header-line: 0  mode-line: 15  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 525   size: 672 x 15   new: 0
char left: 0   top: 35   size: 84 x 1   new: 82
normal: 1.0 x 1.0   new: 0
body pixel: 640 x 15   char: 80 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 16  divider: 0
height header-line: 0  mode-line: 0  divider: 0

 
--

Kaushal Modi

Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
 >>   From the attached image it's easy to see that both fringes of the window
 >> on the right miss one pixel.
 >
 >
 > I fail to see that without the diff-hl-mode example.

I see that the continuation arrows in the rightmost fringe have their
tips truncated.  Do you really need diff-hl-mode enabled to see that?

 >> Please try:
 >>
 >> - C-x 3 with emacs -Q
 >>
 >> - C-x 3 with emacs -Q and scrollbars disabled
 >>
 >
 > I tried that, but nothing stood out.

Can you try again with a buffer with wide enough lines to see the
continuation arrows in the window on the right?  This is important
because it would constitute another, probably different bug.

 > Below images and animation are after following the emacs -Q recipe I posted
 > earlier - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27830#5
 >
 >
 > [image: image.png]
 >
 > As seen above (figure attached), any window not sharing the edge the with
 > frame sees that ~1 pixel truncation.

I see: The first pixel of each fringe in a window that has another one
on the left gets overwritten by the "vertical window border".  With
window dividers or scroll bars on, that border is not drawn.  I think we
should remove that border completely and draw a one pixel wide window
divider instead when scroll bars are disabled in a window and dividers
are off.  Tricky because scroll bars can be turned off individually for
windows and dividers are frame wide.  Strictly for Emacs 27.

As a workaround for things to come I suggest using a one pixel wide
right only window divider with scroll bars off.

 > Here is the frame dump with scroll bars disabled:
 >
 > frame pixel: 656 x 540   cols/lines: 82 x 36   units: 8 x 15
[...]
 > height header-line: 0  mode-line: 0  divider: 0
[...]
 > Here's the same after *enabling* scroll bars:
 >
 > frame pixel: 672 x 540   cols/lines: 84 x 36   units: 8 x 15
[...]
 > height header-line: 0  mode-line: 0  divider: 0

Both dumps are completely normal.

Thanks, martin



Reply | Threaded
Open this post in threaded view
|

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

Kaushal Modi
On Wed, Oct 4, 2017 at 5:04 AM martin rudalics <[hidden email]> wrote:

I see that the continuation arrows in the rightmost fringe have their
tips truncated.  Do you really need diff-hl-mode enabled to see that?

Can you try again with a buffer with wide enough lines to see the
continuation arrows in the window on the right?  This is important
because it would constitute another, probably different bug.

Hi Martin, 

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.png
 
 I see: The first pixel of each fringe in a window that has another one
on the left gets overwritten by the "vertical window border".  With
window dividers or scroll bars on, that border is not drawn.  I think we
should remove that border completely and draw a one pixel wide window
divider instead when scroll bars are disabled in a window and dividers
are off.  Tricky because scroll bars can be turned off individually for
windows and dividers are frame wide.  Strictly for Emacs 27.

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?

As a workaround for things to come I suggest using a one pixel wide
right only window divider with scroll bars off.

The workaround doesn't behave the same because now the windows have a white line show up for the window dividers:

image.png

The "vertical window border" looks very much elegant IMO (with the window dividers disabled, but that then truncates the fringe):

image.png

It this workaround is needed, then:
1) Would it be possible to customize the divider color?
2) It should also go in NEWS and /etc/PROBLEMS

The best case of course is if this can be fixed before 26.1 release.
 
Both dumps are completely normal.

Should the dumps be updated with more info to help catch this?

Thanks!
--

Kaushal Modi

Reply | Threaded
Open this post in threaded view
|

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

Kaushal Modi
On Wed, Oct 4, 2017 at 9:47 AM Kaushal Modi <[hidden email]> wrote:
It this workaround is needed, then:
1) Would it be possible to customize the divider color?

Apologies! I was too quick to send that email.. learned about the window-divider face from Elisp manual!

Looks awesome now!

image.png
 
2) It should also go in NEWS and /etc/PROBLEMS

This still applies. WDYT?
 
The best case of course is if this can be fixed before 26.1 release.

This applies too :) 
--

Kaushal Modi

Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
In reply to this post by Kaushal Modi
 > 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.

 > 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.

 > Should the dumps be updated with more info to help catch this?

No, thanks.

martin



Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
In reply to this post by Kaushal Modi
 > Apologies! I was too quick to send that email.. learned about the
 > window-divider face from Elisp manual!

Good.  Maybe it would also work to enlarge the size of your fringes.

 >> 2) It should also go in NEWS and /etc/PROBLEMS
 >>
 >
 > This still applies. WDYT?

There's nothing "new" about this.  I'll leave it to Eli to decide
whether this should be mentioned in PROBLEMS.

 >> The best case of course is if this can be fixed before 26.1 release.
 >>
 >
 > This applies too :)

I'm afraid that it will not happen, though.

martin



Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
In reply to this post by martin rudalics
 >  > [image: image.png]
 >
 > Unfortunately, I don't see any image here.

Apologies, I see them now.  But that's not what I meant.  I need a
screenshot showing the truncation glyphs in the _window on the right_.
Your image shows them in the window on the left only.  And better make
it a frame with three side by side windows all showing truncation
glyphs.

Thanks, martin



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by martin rudalics
> Date: Thu, 05 Oct 2017 10:11:12 +0200
> From: martin rudalics <[hidden email]>
> CC: Dmitry Gutov <[hidden email]>, Eli Zaretskii <[hidden email]>
>
>  >> 2) It should also go in NEWS and /etc/PROBLEMS
>  >>
>  >
>  > This still applies. WDYT?
>
> There's nothing "new" about this.  I'll leave it to Eli to decide
> whether this should be mentioned in PROBLEMS.

It's definitely not for NEWS.  As for PROBLEMS, can one of you suggest
the wording we'd like to put there?  It's hard for me to make a
decision with no description of the workaround in sight.

Thanks.



Reply | Threaded
Open this post in threaded view
|

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

Kaushal Modi
In reply to this post by martin rudalics
On Thu, Oct 5, 2017 at 4:11 AM martin rudalics <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Kaushal Modi
In reply to this post by martin rudalics
On Thu, Oct 5, 2017 at 4:29 AM martin rudalics <[hidden email]> wrote:
 >  > [image: image.png]
 >
 > Unfortunately, I don't see any image here.

Apologies, I see them now.  But that's not what I meant.  I need a
screenshot showing the truncation glyphs in the _window on the right_.
Your image shows them in the window on the left only.  And better make
it a frame with three side by side windows all showing truncation
glyphs.

I have already sent those images.. the way debbugs is presenting them is messing us up (You will find the images I attached then when to scroll to the bottom of this message: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27830#17 )

(1) Image of frame with 3 windows, scroll-bars OFF, truncation glyphs in all windows: https://debbugs.gnu.org/cgi/bugreport.cgi?att=2;msg=11;bug=27830;filename=image.png

(2) Image of frame with 3 windows, scroll-bars ON, truncation glyphs in all windows: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27830;filename=image.png;att=3;msg=11

The glyphs in the right-most window in both cases look the same/fine to me.
--

Kaushal Modi

Reply | Threaded
Open this post in threaded view
|

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

Kaushal Modi
In reply to this post by Eli Zaretskii
On Thu, Oct 5, 2017 at 4:47 AM Eli Zaretskii <[hidden email]> wrote:
It's definitely not for NEWS.

I agree, as I later realize that this was in 25.1 too, just that it wasn't noticeable with nlinum enabled.
 
  As for PROBLEMS, can one of you suggest
the wording we'd like to put there?  It's hard for me to make a
decision with no description of the workaround in sight.

I would suggest this:

For a window sharing its left edge with another window, the left side of the fringe in that edge gets truncated if scroll-bars are disabled. A workaround is to enable the right-side window-dividers by doing (window-divider-mode 1), and customizing the divider width (window-divider-default-right-width) and face (window-divider) as needed.

This image[1] summarizes the problem.

Here is my workaround[2] for reference.



--

Kaushal Modi

Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
In reply to this post by Eli Zaretskii
 > It's definitely not for NEWS.  As for PROBLEMS, can one of you suggest
 > the wording we'd like to put there?  It's hard for me to make a
 > decision with no description of the workaround in sight.

When vertical scroll bars are disabled on GUI frames, Emacs draws a
one-pixel wide border between side-by-side windows.  This border
occupies the first pixel column of the window on the right and may thus
overwrite the leftmost pixels of any glyph displayed there.  If these
pixels convey important information, you can make them visible by
enabling window dividers (from the Options/Show/Hide menu).  Width and
faces of these dividers can be customized appropriately.  Note, however,
that window dividers are also displayed when scroll bars are enabled.

martin



Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
In reply to this post by Kaushal Modi
 > (1) Image of frame with 3 windows, scroll-bars OFF, truncation glyphs in
 > all windows:
 > https://debbugs.gnu.org/cgi/bugreport.cgi?att=2;msg=11;bug=27830;filename=image.png
 >
 > (2) Image of frame with 3 windows, scroll-bars ON, truncation glyphs in all
 > windows:
 > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27830;filename=image.png;att=3;msg=11
 >
 > The glyphs in the right-most window in both cases look the same/fine to me.

I now looked at all these images and it indeed seems that all truncation
glyphs show up correctly.  So this was a false alarm.

Thanks, martin



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by martin rudalics
> Date: Fri, 06 Oct 2017 10:17:35 +0200
> From: martin rudalics <[hidden email]>
> CC: [hidden email], [hidden email], [hidden email]
>
>  > It's definitely not for NEWS.  As for PROBLEMS, can one of you suggest
>  > the wording we'd like to put there?  It's hard for me to make a
>  > decision with no description of the workaround in sight.
>
> When vertical scroll bars are disabled on GUI frames, Emacs draws a
> one-pixel wide border between side-by-side windows.  This border
> occupies the first pixel column of the window on the right and may thus
> overwrite the leftmost pixels of any glyph displayed there.  If these
> pixels convey important information, you can make them visible by
> enabling window dividers (from the Options/Show/Hide menu).  Width and
> faces of these dividers can be customized appropriately.  Note, however,
> that window dividers are also displayed when scroll bars are enabled.

This is OK for PROBLEMS, but maybe it should be in the user manual
instead?

Thanks.



Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
 > This is OK for PROBLEMS, but maybe it should be in the user manual
 > instead?

It's probably too internal in order to be mentioned in PROBLEMS.  But is
the user manual really a suitable place for this?  I understand your
concerns but, for example, the last paragraph of section "14.14 Window
Fringes" appears to me merely distracting for people who want to learn
basic things about fringes.  Maybe that part should better go to section
"39.3 Truncation" of the Elisp manual.

As for the vertical borders I don't know.  We would need to describe
them somewhere in a context of "resizing side-by-side windows with the
mouse" but we curently do that rather cryptically in section 21.5 of the
Emacs manual as

      Furthermore, by clicking and dragging `mouse-1' on the divider
   between two side-by-side mode lines, you can move the vertical boundary
   to the left or right.

Nothing special about windows without vertical scroll bars.

martin



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> Date: Sat, 07 Oct 2017 10:08:26 +0200
> From: martin rudalics <[hidden email]>
> CC: [hidden email], [hidden email], [hidden email]
>
>  > This is OK for PROBLEMS, but maybe it should be in the user manual
>  > instead?
>
> It's probably too internal in order to be mentioned in PROBLEMS.  But is
> the user manual really a suitable place for this?  I understand your
> concerns but, for example, the last paragraph of section "14.14 Window
> Fringes" appears to me merely distracting for people who want to learn
> basic things about fringes.  Maybe that part should better go to section
> "39.3 Truncation" of the Elisp manual.

This text was added in response to explicit requests of users who
AFAIR had nothing to do with Lisp programming, so I think the place is
right, and its being at the end should minimize the distraction.

> As for the vertical borders I don't know.  We would need to describe
> them somewhere in a context of "resizing side-by-side windows with the
> mouse" but we curently do that rather cryptically in section 21.5 of the
> Emacs manual as
>
>       Furthermore, by clicking and dragging `mouse-1' on the divider
>    between two side-by-side mode lines, you can move the vertical boundary
>    to the left or right.
>
> Nothing special about windows without vertical scroll bars.

I see two potential homes for this: 21.12 "Scroll Bars" and 21.13
"Window Dividers".  We can mention it in both, one a full description,
the other just a short comment and a cross-reference.  WDYT?



Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
 > I see two potential homes for this: 21.12 "Scroll Bars" and 21.13
 > "Window Dividers".  We can mention it in both, one a full description,
 > the other just a short comment and a cross-reference.  WDYT?

See the attached patch.

martin

frames.texi.diff (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> Date: Sat, 07 Oct 2017 11:44:40 +0200
> From: martin rudalics <[hidden email]>
> CC: [hidden email], [hidden email], [hidden email]
>
> See the attached patch.

Thanks, this is fine.  Just one minor comment:

> +@cindex vertical border
> +  On graphical frames, vertical scroll bars implicitly serve to visually
> +separate side-by-side windows.  When vertical scroll bars and window
> +dividers (@pxref{Window Dividers}) are both disabled, Emacs separates
> +such windows with the help of a one-pixel wide @dfn{vertical border}.
> +That border occupies the first pixel column of the window on the right
> +and may thus overdraw the leftmost pixels of any glyph displayed there.
> +If these pixels convey important information, you can make them visible
> +by enabling window dividers with appropriate customizations.
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^
Can we be more specific about the "appropriate customizations", e.g.,
name the variables to customize or have a cross-reference to where
they are described?



12