From: Po Lu <luangruo@yahoo.com>
To: Gregory Heytings <gregory@heytings.org>
Cc: emacs-devel@gnu.org
Subject: Re: emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b)
Date: Mon, 12 Dec 2022 19:08:55 +0800 [thread overview]
Message-ID: <878rjcj2uw.fsf@yahoo.com> (raw)
In-Reply-To: <ec23ed3e958ddf1ca9ef@heytings.org> (Gregory Heytings's message of "Mon, 12 Dec 2022 10:42:17 +0000")
Gregory Heytings <gregory@heytings.org> writes:
> It is telling that you "see no purpose" in discussing a change to code
> that was agreed upon after 300 posts in a bug report.
Sorry, but I don't see where in the discussion the use of a bitmask as a
variable was actually discussed. My change does not touch any of the
code which was discussed.
> That variable is of no interest whatsoever to our users. It is there
> only for debugging purposes, and is once again only meant to be used
> by the few users who understand subtle technicalities in the face
> realization code.
Then the best course of action is to just remove the variable.
> Aha. That's your understanding of a "discussion", then: you say
> something, and act immediately, without waiting for a potential
> answer. And then claim that there was a "discussion" because you said
> something. Oh, in fact no, that's not even what happened: you reverted
> before saying anything.
Only because you reverted first.
> You would not ask that question if you had read the explanation in
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59347#331. And the fact
> you ask that question shows that you did not read it.
Anyway, AFAIK :font can be a font-entity and not a font-spec, in which
case it is definitely not okay to touch :extra under the Haiku font
backend: it contains two indices into the system-wide font and family
arrays which should not be changed.
> The relevant parts of that enum have not changed at all since they
> were introduced fifteen years ago.
And will you guarantee that will always be the case?
> Nobody should do that. The docstring clearly said: "There is no
> reason to change that value except for debugging purposes."
Alas, what ``should'' be is very different from reality. Someone will
set the unused bits to random garbage, and someone elses nice plan for
adding extra fields to a font object will be broken by that change.
> Oh yes, I see. FONT_SPEC_MAX is (and has always been) 15, but
> clearly, for a reason that hasn't happened in the past fifteen years,
> "at some point in the future", it will become 30, and that will be
> problematic on 32-bit computers. And you tell me that what I write is
> "nonsense".
It could change, and once it does I can almost guarantee that nobody
will think to update the ``obscure'' bitmask exposed to Lisp that users
``are not supposed'' to set.
> Anyway, I don't want to deal with this anymore. I probably spent
> about 50 hours on that bug, that's more than enough.
Fair enough.
next prev parent reply other threads:[~2022-12-12 11:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <167080778504.14972.16819452979975432761@vcs2.savannah.gnu.org>
[not found] ` <20221212011625.58E8AC004B4@vcs2.savannah.gnu.org>
2022-12-12 2:41 ` emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b) Po Lu
2022-12-12 2:48 ` Po Lu
2022-12-12 9:09 ` Gregory Heytings
2022-12-12 9:37 ` Issue building master Ergus
2022-12-12 13:33 ` Eli Zaretskii
[not found] ` <2127787931.394320.1670853418624@mail.yahoo.com>
2022-12-12 14:12 ` Eli Zaretskii
2022-12-12 15:49 ` Ergus
2022-12-12 16:04 ` Eli Zaretskii
2022-12-12 17:16 ` Ergus
2022-12-12 10:05 ` emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b) Po Lu
2022-12-12 10:42 ` Gregory Heytings
2022-12-12 11:08 ` Po Lu [this message]
2022-12-12 10:18 ` xenodasein--- via Emacs development discussions.
2022-12-12 10:29 ` Cool down, please [was: emacs-29 b8d2ec920f: Revert ...] tomas
2022-12-12 10:36 ` emacs-29 b8d2ec920f: Revert "Improve last change to xfaces.c" (05ece1eb8b) Po Lu
2022-12-12 10:48 ` xenodasein--- via Emacs development discussions.
2022-12-12 13:44 ` Eli Zaretskii
2022-12-12 15:03 ` xenodasein--- via Emacs development discussions.
2022-12-12 15:13 ` tomas
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=878rjcj2uw.fsf@yahoo.com \
--to=luangruo@yahoo.com \
--cc=emacs-devel@gnu.org \
--cc=gregory@heytings.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.