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

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

bug#58122: closed (28.2; overlay before/after-string does not render mor


From: GNU bug Tracking System
Subject: bug#58122: closed (28.2; overlay before/after-string does not render more than one fringe display spec)
Date: Thu, 29 Sep 2022 06:14:01 +0000

Your message dated Thu, 29 Sep 2022 09:12:57 +0300
with message-id <83mtaihfo6.fsf@gnu.org>
and subject line Re: bug#58122: 28.2; overlay before/after-string does not 
render more than one fringe display spec
has caused the debbugs.gnu.org bug report #58122,
regarding 28.2; overlay before/after-string does not render more than one 
fringe display spec
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
58122: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58122
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 28.2; overlay before/after-string does not render more than one fringe display spec Date: Tue, 27 Sep 2022 11:05:10 -0700 User-agent: Cyrus-JMAP/3.7.0-alpha0-968-g04df58079d-fm-20220921.001-g04df5807
An overlay `before-string' or `after-string' property with both left and right 
fringe display specs only seems to render the first spec.

*Demonstration*:
- Launch GUI Emacs with the -q flag
- In an Elisp buffer, define these two commands

(defun insert-two-squares ()
  (interactive)
  (insert (propertize " " 'display [(left-fringe hollow-square)
                                    (right-fringe hollow-square)])))

(defun overlay-two-squares (right-first)
  (interactive "P")
  (remove-overlays)
  (let ((ov (make-overlay (point) (point)))
        (specs [(left-fringe hollow-square)
                 (right-fringe hollow-square)]))
    (overlay-put ov 'before-string
                 (propertize " "
                             'display
                             (if right-first
                                 (reverse specs)
                               specs)))))

- Switch to a new test buffer
- Invoke `insert-two-squares'; observe that both left and right fringes display 
a hollow square
- Delete the inserted character (fringe bitmaps disappear)
- Invoke `overlay-two-squares'; observe that only the left fringe displays a 
hollow square
- Invoke `overlay-two-squares' prefixed with `C-u'; observe that only the 
_right_ fringe displays the hollow square

The same behavior is seen if the overlay property is `after-string' rather than 
`before-string'.

*Expectation*:
Based on the display spec documentation I would expect the overlay to render 
fringes the same way as an inserted propertized string.


In GNU Emacs 28.2 (build 1, aarch64-apple-darwin21.1.0, NS appkit-2113.00 
Version 12.0.1 (Build 21A559))
of 2022-09-12 built on armbob.lan
Windowing system distributor 'Apple', version 10.3.2113
System Description:  macOS 12.0.1

Configured using:
'configure --with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp' --with-modules'

Configured features:
ACL GMP GNUTLS JSON LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER THREADS
TOOLKIT_SCROLL_BARS ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-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
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search seq byte-opt
gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date subr-x edmacro kmacro
cl-loaddefs cl-lib iso-transl tooltip eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/ns-win ns-win
ucs-normalize mule-util term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer 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 emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice
button loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads kqueue cocoa ns multi-tty
make-network-process emacs)

Memory information:
((conses 16 52550 8825)
(symbols 48 6664 1)
(strings 32 18735 1663)
(string-bytes 1 623539)
(vectors 16 14125)
(vector-slots 8 194959 12178)
(floats 8 23 44)
(intervals 56 313 0)
(buffers 992 12))



--- End Message ---
--- Begin Message --- Subject: Re: bug#58122: 28.2; overlay before/after-string does not render more than one fringe display spec Date: Thu, 29 Sep 2022 09:12:57 +0300
> Date: Wed, 28 Sep 2022 18:18:57 -0700
> From: Josh <emacs@woolsweater.net>
> Cc: 58122@debbugs.gnu.org
> 
> > This was never supported in Emacs. The reasons are subtle and very
> > technical, and I will not go into them here.  Making this work as
> > expected might be possible, but it would require changes on a very low
> > level in the code that handles nested display properties and overlay
> > strings, which is already extremely complicated.  I find changes of
> > such nature unjustified for such a fringe (pun intended) use case.
> >
> > As an easy work-around, you can have 2 different overlay strings at
> > the same position, like this:
> 
> Got it. I think this workaround should be sufficient. Thank you for the quick 
> response!

Thanks, so I'm closing this bug report.


--- End Message ---

reply via email to

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