From: Eli Zaretskii <eliz@gnu.org>
To: Gregory Heytings <gregory@heytings.org>
Cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
Subject: bug#59347: 29.0.50; `:family` face setting ignored
Date: Mon, 12 Dec 2022 17:07:07 +0200 [thread overview]
Message-ID: <831qp4slt0.fsf@gnu.org> (raw)
In-Reply-To: <ec23ed3e95fa8ff23d0e@heytings.org> (message from Gregory Heytings on Mon, 12 Dec 2022 00:57:49 +0000)
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, Po Lu <luangruo@yahoo.com>,
> 59347@debbugs.gnu.org
>
>
> Amazing. I thought this exhausting discussion was over, but no, Po Lu
> came and "improved" the code that was agreed upon only a couple of hours
> after it was pushed, disregarding this entire discussion, the docstring of
> the variable that the commit introduced, the commit message, and without
> asking any questions. How can that be right, how can that be acceptable?
This discussion went overboard, IMO. I indeed think that Po Lu should
have discussed his changes before doing them, but your reaction, in
particular the revert, is also overreaction.
> The name of the variable was changed, and the docstring was "improved",
> and became completely wrong. It is simply untrue that this is a list of
> attributes that Emacs will "ignore when realizing a face", or in fact that
> this changes anything fundamental in the way Emacs realizes faces.
If this is the doc string you saw, you were not looking at an
up-to-date tree. I renamed the variable and rewrote the doc string
soon after Po Lu made his changes; the word "ignore" (which I agree is
inaccurate) is no longer there. If you still have comments on the
current doc string, please speak up.
> Here is again, in every possible detail, but this time in a single post,
> the analysis of this subtle bug, and the rationale of the patch that was
> agreed upon. I explain this bug with an concrete example, with the
> 'variable-pitch' face and a font with a 'medium' weight. That example is
> only meant to illustrate the bug: the same reasoning applies for other
> faces and other font attributes (slant or width).
Thanks. This is a good description, and it is good to have it in the
bug discussion, for posterity.
> From: Po Lu <luangruo@yahoo.com>
> Cc: Gregory Heytings <gregory@heytings.org>
>
> - unsetting the "extra" attribute is not safe on the Haiku port.
If this is so, why not disable that only for Haiku?
> - the bitmask variable is a real nusiance for anyone trying to
> debug Emacs or change the layout of the font attribute index
> enumerator.
"Nuisance" is an exaggeration. But I agree that using more
descriptive values is more convenient, if and when someone needs to
change the default value. And I have a proposal for how to do this
without sacrificing performance; read on.
> Just because a bug has been closed does NOT mean the change in it is no
> longer subject to scrutiny.
But, after such a long and painful discussion, it would have been
prudent to talk first and cut the metal later. And, btw, your change
had two copy/paste typos, which would have probably be avoided if you
posted the patch first.
> all that code takes somewhere between 2 to 4 microseconds to complete
> for me, in a build with optimizations enabled. I don't know how many
People are reportedly running Emacs sessions with several thousands of
faces, in which case 2 to 4 usec per face could add up to a
significant number. So it cannot do any harm to try to make the
"usual" case faster.
> From: Gregory Heytings <gregory@heytings.org>
> To: Po Lu <luangruo@yahoo.com>
> cc: emacs-devel@gnu.org
>
> >> Of course I did. That you did not read it is another thing.
> >
> > You did not. The only real technical argument you put forth was some
> > nonsense about FOR_EACH_TAIL being slow.
> >
>
> "Nonsense", again? Thank you!
Yes, let's please avoid nasty unfriendly language.
> From: Po Lu <luangruo@yahoo.com>
> To: Gregory Heytings <gregory@heytings.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca,
> 59347@debbugs.gnu.org
>
> The fundamental problem I have with the doc string is
> that it did not say what it does, or what it is supposed to debug, in a
> manner users can understand.
Does the current doc string have any such problems you can spot?
Anyway, here's my proposal:
. we change the default value of the variable to be t, and document
that this stands for (:weight :width :slant)
. we change the code to reset only those 3 attributes when the
value is t, and to reset nothing when the value is nil
. the (slower) code which loops over the list will only run if the
value of the variable is neither nil nor t
. we avoid resetting the :extra attribute on Haiku
Is this okay with you both? I volunteer to make these changes if you
agree.
Thanks.
next prev parent reply other threads:[~2022-12-12 15:07 UTC|newest]
Thread overview: 123+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-18 4:57 bug#59347: 29.0.50; `:family` face setting ignored Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-18 12:37 ` Eli Zaretskii
2022-11-18 14:59 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-18 15:13 ` Eli Zaretskii
2022-11-18 15:25 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-18 16:54 ` Eli Zaretskii
2022-11-18 17:21 ` Eli Zaretskii
2022-11-18 20:00 ` Yuan Fu
2022-11-18 20:12 ` Yuan Fu
2022-11-18 21:09 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-19 7:21 ` Eli Zaretskii
2022-11-18 19:46 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-18 19:58 ` Eli Zaretskii
2022-11-18 20:55 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-19 7:15 ` Eli Zaretskii
2022-11-19 14:55 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-19 15:31 ` Eli Zaretskii
2022-11-19 16:01 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-19 16:16 ` Eli Zaretskii
2022-11-20 13:57 ` Gregory Heytings
2022-11-20 14:59 ` Eli Zaretskii
2022-11-20 15:35 ` Gregory Heytings
2022-11-20 15:54 ` Eli Zaretskii
2022-11-20 16:59 ` Gregory Heytings
2022-11-20 17:29 ` Eli Zaretskii
2022-11-20 17:43 ` Gregory Heytings
2022-11-20 17:58 ` Eli Zaretskii
2022-11-20 18:11 ` Gregory Heytings
2022-11-20 18:19 ` Eli Zaretskii
2022-11-20 19:45 ` Gregory Heytings
2022-11-20 20:01 ` Eli Zaretskii
2022-11-20 20:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-20 20:45 ` Gregory Heytings
2022-11-21 12:27 ` Eli Zaretskii
2022-11-20 18:30 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-20 18:53 ` Eli Zaretskii
2022-11-20 18:31 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-20 18:54 ` Eli Zaretskii
2022-11-20 21:49 ` Gregory Heytings
2022-11-21 12:51 ` Eli Zaretskii
2022-11-21 14:48 ` Gregory Heytings
2022-11-21 15:08 ` Eli Zaretskii
2022-11-21 23:34 ` Gregory Heytings
2022-11-22 0:34 ` Gregory Heytings
2022-11-22 3:05 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-22 7:59 ` Gregory Heytings
2022-11-22 13:38 ` Eli Zaretskii
2022-11-22 13:46 ` Gregory Heytings
2022-11-22 13:16 ` Eli Zaretskii
2022-11-22 13:38 ` Gregory Heytings
2022-11-22 14:38 ` Eli Zaretskii
2022-11-22 14:45 ` Gregory Heytings
2022-11-22 14:53 ` Eli Zaretskii
2022-11-22 15:41 ` Gregory Heytings
2022-11-22 17:44 ` Eli Zaretskii
2022-11-22 20:52 ` Gregory Heytings
2022-11-22 20:47 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-23 8:13 ` Gregory Heytings
2022-11-30 10:03 ` Gregory Heytings
2022-11-30 14:00 ` Eli Zaretskii
2022-11-30 15:38 ` Gregory Heytings
2022-12-04 14:21 ` Eli Zaretskii
2022-12-05 23:30 ` Gregory Heytings
2022-12-06 14:22 ` Eli Zaretskii
2022-12-07 11:00 ` Gregory Heytings
[not found] ` <d99c6016-3b32-1116-9ef1-43fe40a71a4@heytings.org>
2022-12-07 11:02 ` Gregory Heytings
2022-12-07 23:19 ` Gregory Heytings
2022-12-08 0:27 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-08 1:07 ` Gregory Heytings
2022-12-08 8:16 ` Eli Zaretskii
2022-12-08 14:59 ` Gregory Heytings
2022-12-08 15:13 ` Eli Zaretskii
[not found] ` <e1b79bb2-a3c5-2677-57d8-fb6db43dfd9@heytings.org>
2022-12-08 16:27 ` Gregory Heytings
2022-12-08 14:12 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-08 15:33 ` Gregory Heytings
2022-12-08 17:29 ` Drew Adams
2022-12-08 17:44 ` Eli Zaretskii
2022-12-08 5:32 ` Yuan Fu
2022-12-08 8:09 ` Eli Zaretskii
2022-12-08 14:17 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-08 14:49 ` Eli Zaretskii
2022-12-08 15:24 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-08 15:45 ` Eli Zaretskii
2022-12-08 8:03 ` Eli Zaretskii
2022-12-08 12:53 ` Gregory Heytings
2022-12-08 14:16 ` Eli Zaretskii
2022-12-08 15:17 ` Gregory Heytings
2022-12-08 15:42 ` Eli Zaretskii
2022-12-10 22:51 ` Gregory Heytings
2022-12-12 0:57 ` Gregory Heytings
2022-12-12 1:49 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-12 8:54 ` Gregory Heytings
2022-12-12 10:33 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-12 10:51 ` Gregory Heytings
2022-12-12 11:18 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-12 11:38 ` Gregory Heytings
2022-12-12 12:47 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-12 15:30 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-12 15:45 ` Eli Zaretskii
2022-12-12 15:07 ` Eli Zaretskii [this message]
2022-12-12 16:12 ` Gregory Heytings
2022-12-12 17:10 ` Eli Zaretskii
2022-12-12 21:28 ` Gregory Heytings
2022-12-13 11:58 ` Eli Zaretskii
2022-12-13 1:16 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-13 15:40 ` Eli Zaretskii
2022-12-04 14:23 ` Eli Zaretskii
2022-11-22 6:42 ` Gregory Heytings
2022-11-22 8:01 ` Gregory Heytings
2022-11-22 13:27 ` Eli Zaretskii
2022-11-22 12:38 ` Eli Zaretskii
2022-11-22 12:43 ` Gregory Heytings
2022-11-22 14:29 ` Eli Zaretskii
2022-11-22 14:39 ` Gregory Heytings
2022-11-22 14:52 ` Eli Zaretskii
2022-11-22 15:17 ` Gregory Heytings
2022-11-20 18:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-20 19:46 ` Gregory Heytings
2022-11-19 0:20 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-19 0:28 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-19 4:37 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-19 6:01 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-19 14:17 ` Stefan Monnier 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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=831qp4slt0.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=59347@debbugs.gnu.org \
--cc=gregory@heytings.org \
--cc=luangruo@yahoo.com \
--cc=monnier@iro.umontreal.ca \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).