all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Nested display strings
Date: Mon, 25 Apr 2011 11:57:44 -0300	[thread overview]
Message-ID: <jwvei4qz8ls.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83ipu2a284.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 25 Apr 2011 16:29:31 +0300")

>> The main issue is that a single overlays with a `display' property
>> normally means "display that thing *once*".  So while we can argue of
>> the case where the two overlays share the start or end position, in the
>> case where the inner overlays is really "in the middle", there's no
>> clearly correct way to render it.

> I see.  So in this modified use case, where the overlays start at the
> same position:

> (defvar myov1 (make-overlay 16 51))
> (defvar myov2 (make-overlay 16 43))
> (overlay-put myov1 'display "STRING1")
> (overlay-put myov2 'display "STRING2")
> (overlay-put myov1 'priority 1)
> (overlay-put myov2 'priority 2)

> you think it's okay to display

> ;; This buffer STRING2STRING1, and for Lisp evaluation.

> ?

I'm not sure if it's OK, but at least there's an argument that it
doesn't break the "display once per overlay" rule.

> And in the opposite case, where the overlays end at the same position:

> (defvar myov1 (make-overlay 16 51))
> (defvar myov2 (make-overlay 29 51))
> (overlay-put myov1 'display "STRING1")
> (overlay-put myov2 'display "STRING2")
> (overlay-put myov1 'priority 1)
> (overlay-put myov2 'priority 2)

> it is okay to display

> ;; This buffer STRING1, and for Lisp evaluation.

> ?

It seems inconsistent, but I think we should consider both cases
unsupported, so the inconsistency is not too serious.

> If the modified display is deemed okay, I will install that change
> (and probably add something to the docs to mention these caveats).

I think it's OK.

>> So I think the best behavior is to detect the situation and signal
>> some kind of warning/error

> Hmm.. how do you signal an error during redisplay?  I can do something
> like this:

>     add_to_log ("Warning: overlapping `display' strings at pos %d",
>                 make_number (pos));

> Would that be sufficient?

There was recently a discussion of how to signal warnings/errors in
a delayed fashion.  We don't have a good mechanism for it currently, but
it would be good to add one.
In the mean time, the above is better than nothing.


        Stefan



  reply	other threads:[~2011-04-25 14:57 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-23 16:44 Nested display strings Eli Zaretskii
2011-04-23 19:42 ` Andreas Röhler
2011-04-23 20:07   ` Eli Zaretskii
2011-04-23 20:31 ` Drew Adams
2011-04-23 22:16   ` Eli Zaretskii
2011-04-23 23:20     ` Drew Adams
2011-04-24  6:25       ` Eli Zaretskii
2011-04-24  5:01 ` Stefan Monnier
2011-04-24 17:37   ` Eli Zaretskii
2011-04-25 12:47     ` Stefan Monnier
2011-04-25 13:29       ` Eli Zaretskii
2011-04-25 14:57         ` Stefan Monnier [this message]
2011-04-25 19:03           ` Juanma Barranquero
2011-04-25 19:41       ` Chong Yidong
2011-04-25 19:56         ` Eli Zaretskii
2011-04-26 18:04           ` Chong Yidong
2011-04-26 18:28             ` Eli Zaretskii
2011-04-26 12:53         ` Stefan Monnier
2011-04-26 17:51           ` Eli Zaretskii
2011-04-26 18:13             ` Ted Zlatanov
2011-04-26 18:25               ` Eli Zaretskii
2011-04-26 18:35                 ` chad
2011-04-26 18:50                   ` Ted Zlatanov
2011-04-26 19:19                   ` Drew Adams
2011-04-28  0:45             ` Stefan Monnier
2011-04-28 16:48               ` Eli Zaretskii
2011-04-28 18:42                 ` Stefan Monnier
2011-04-26 20:51           ` Chong Yidong
2011-04-27  0:59             ` Stefan Monnier
2011-04-26 14:46       ` Richard Stallman
2011-04-24  5:19 ` Michael Welsh Duggan
2011-04-24  6:17   ` Eli Zaretskii
2011-04-24  6:22     ` Michael Welsh Duggan
2011-04-24  6:31   ` Andreas Röhler

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

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

  git send-email \
    --in-reply-to=jwvei4qz8ls.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.