all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Pip Cet <pipcet@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 40897@debbugs.gnu.org
Subject: bug#40897: Negation of pixel-width :width expressions does not work
Date: Fri, 1 May 2020 09:41:51 +0000	[thread overview]
Message-ID: <CAOqdjBe_QdVg0UCSc6SnWMzrbKVcZnB7_X96Y5tBU_TnrsTOMA@mail.gmail.com> (raw)
In-Reply-To: <83y2qh3spm.fsf@gnu.org>

On Mon, Apr 27, 2020 at 2:32 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Mon, 27 Apr 2020 08:47:50 +0000
> You say (3) is difficult to fix, but the patch below does succeed in
> preventing the stack overflow, so I don't think I understand why you
> thought this to be difficult.  What am I missing?

Circular lists can have a cycle of length greater than one. However, a
simple limitation of how deeply we recurse into the display spec would
work, and potentially be more robust. Would you agree with that?

Thank you for your other explanations. I've taken the opportunity to
have a look at the redisplay code. I'll confess it's a bit
overwhelming in its complexity, and my understanding so far is
tentative, but it seems to me like it "essentially" goes from buffer
text to the glyph matrix in one shot: there's no intermediate state
that represents what CSS would call the "resolved style" of the
document.

Trying to write this email, I'm realizing I need to think about this
more: I still think the current state of things, where we call Lisp as
part of redisplay but usually don't rely on it, is much better than to
exclude Lisp from the process entirely.





  reply	other threads:[~2020-05-01  9:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-27  8:47 bug#40897: Negation of pixel-width :width expressions does not work Pip Cet
2020-04-27 12:18 ` Pip Cet
2020-04-27 14:52   ` Eli Zaretskii
2020-04-27 14:32 ` Eli Zaretskii
2020-05-01  9:41   ` Pip Cet [this message]
2020-05-01 10:05     ` Eli Zaretskii

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=CAOqdjBe_QdVg0UCSc6SnWMzrbKVcZnB7_X96Y5tBU_TnrsTOMA@mail.gmail.com \
    --to=pipcet@gmail.com \
    --cc=40897@debbugs.gnu.org \
    --cc=eliz@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.