From: Lars Ingebrigtsen <larsi@gnus.org>
To: Pip Cet <pipcet@gmail.com>
Cc: Alan Third <alan@idiocy.org>, 36403@debbugs.gnu.org
Subject: bug#36403: 27.0.50; Trivial image.c bugs
Date: Fri, 21 Aug 2020 13:26:25 +0200 [thread overview]
Message-ID: <877dts8cke.fsf@gnus.org> (raw)
In-Reply-To: <CAOqdjBf3uujzsK-s-H0YHYfazUR=2TnKMkLUxnP=mAKurfzE1Q@mail.gmail.com> (Pip Cet's message of "Fri, 21 Aug 2020 09:26:10 +0000")
Pip Cet <pipcet@gmail.com> writes:
> Paul's suggestion was to use equal () instead of !NILP (Fequal (...)).
> I'm against that, because the F in Fequal kind of hints at the
> difficulties of using equal, of which there are many: in the current
> implementation, it can signal, quit, be asymmetric (signalling for
> (equal a b) whereas (equal b a) works), and is susceptible to equality
> bombs that take forever to compare.
Yeah, your equal_lists is better in all ways, I think. It should be
much faster, too -- Fequal on a list checks whether the string members
are equal, too, which is slow. So I think this will speed things up if
you have a buffer that displays images where the data comes from a
string (which can be huge) instead of a file.
> Replacing !NILP is a better idea, but I'm struggling to come up with a
> good name for that. But even a bad name would be an improvement.
TRUEP is kinda obvious, isn't it? Although I guess some people would
object on the grounds that only t is true, while all other non-nil
values are only trueish.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
next prev parent reply other threads:[~2020-08-21 11:26 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-27 16:28 bug#36403: 27.0.50; Trivial image.c bugs Pip Cet
2019-06-27 17:40 ` Eli Zaretskii
2019-06-28 15:05 ` Pip Cet
2019-06-28 19:52 ` Eli Zaretskii
2019-07-22 2:55 ` Pip Cet
2019-07-26 6:56 ` Eli Zaretskii
2019-07-28 14:50 ` Pip Cet
2019-09-24 16:26 ` Lars Ingebrigtsen
2020-08-03 7:47 ` Lars Ingebrigtsen
2020-08-18 16:28 ` Lars Ingebrigtsen
2020-08-20 23:03 ` Alan Third
2020-08-20 23:13 ` Lars Ingebrigtsen
2020-08-20 23:17 ` Lars Ingebrigtsen
2020-08-20 23:32 ` Lars Ingebrigtsen
2020-08-21 9:26 ` Pip Cet
2020-08-21 11:26 ` Lars Ingebrigtsen [this message]
2022-10-04 13:52 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-04 14:06 ` Lars Ingebrigtsen
2022-10-04 18:05 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-14 22:14 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
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=877dts8cke.fsf@gnus.org \
--to=larsi@gnus.org \
--cc=36403@debbugs.gnu.org \
--cc=alan@idiocy.org \
--cc=pipcet@gmail.com \
/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.