emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#16856: closed (24.3.50; Cursor leaves garbage in f


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#16856: closed (24.3.50; Cursor leaves garbage in fringe (and a request: width of fringes + scroll bar should be full characters))
Date: Sat, 21 May 2016 19:08:02 +0000

Your message dated Sat, 21 May 2016 21:07:53 +0200
with message-id <address@hidden>
and subject line Re: [PATCH] Prevent cursor from over-drawing the fringe
has caused the debbugs.gnu.org bug report #16856,
regarding 24.3.50; Cursor leaves garbage in fringe (and a request: width of 
fringes + scroll bar should be full characters)
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
16856: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16856
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 24.3.50; Cursor leaves garbage in fringe (and a request: width of fringes + scroll bar should be full characters) Date: Sun, 23 Feb 2014 22:39:55 +0100
Hi!

The cursor leaves garbage in the fringe column.

Steps to repeat:

    Emacs -Q
    (setq truncate-partial-width-windows nil) C-j
    C-x 3
    C-x 3
    C-x o
    C-u 15 x
    C-p

Here, the cursor have left a one-pixel bar in the fringe area.

In other scenarios I have seen the cursor leave two or three pixels wide garbage. (I use six columns and a 6x8 font.)

I use OS X 10.9.

I have noticed that when splitting two windows horizontally, the width of the fringes + scroll bar between the two windows don't add up to full characters. Instead, they are five characters and one pixel. My theory is that this extra pixel pushes the cursor into the fringe to the right.

If possible, I would like to see the pixel width of fringes + scroll bar to be a multiple of the width of the font used in the frame, since it is much more convenient for elisp packages that make layout decisions. (As I mentioned above, now they are 5 characters and one pixel. In 24.3 they were exactly six characters wide.)

Sincerely,
    Anders Lindgren

In GNU Emacs 24.3.50.2 (x86_64-apple-darwin13.0.0, NS apple-appkit-1265.00)
 of 2014-02-16 on macpro.lan
Repository revision: 116451 address@hidden
Windowing system distributor `Apple', version 10.3.1265
Configured using:
 `configure --with-ns'

Important settings:
  value of $LC_CTYPE: UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-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

Recent input:
C-y C-j C-x 3 C-x 3 C-x o C-u 1 5 x C-p <up> <down> 
C-g C-x 1 <escape> x r e p o r t <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set
Quit

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils time-date tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel ns-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer 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 make-network-process
cocoa ns multi-tty emacs)


--- End Message ---
--- Begin Message --- Subject: Re: [PATCH] Prevent cursor from over-drawing the fringe Date: Sat, 21 May 2016 21:07:53 +0200
Closed.

Fixed by Alan Third, see the following for details:

http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e5015c5d9632a0bf685c093249ae4a7d3e825b13

    -- Anders

On Sat, May 21, 2016 at 9:35 AM, Alan Third <address@hidden> wrote:
On Fri, May 20, 2016 at 09:33:52PM +0200, Anders Lindgren wrote:
> Hi!
>
> I gave this patch a try.
>
> It works well, the ns port now behaves like the win32 and gtk+ parts of
> Emacs.
>
> Do you want me to push it to master?

If you could, thanks.

> Ps. When the text area doesn't partially overlap a column, the cursor can
> be drawn in the fringe. It's a bit unfortunate that when it do overlap,
> only the part of the cursor in the text area is drawn. A worst case
> scenario is that only a single pixel of the cursor is visible. An ideal
> solution would be to draw the cursor partially in the text area and
> partially in the fringe, but without leaving garbage behind when moved.
> However, this is nothing that we can solve here and now as it would require
> change to all emacs ports and possibly the core system.

Yeah, I was thinking about this but couldn't really see much of a way
around it. I checked the gtk+ and windows ports operated this way just
to be sure I wasn't introducing another bug as it does seem wrong. :)
--
Alan Third


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]