all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Yuchen Guo <yguo@posteo.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 66416@debbugs.gnu.org
Subject: bug#66416: 29.1; Crashes when visiting HELLO file with pgtk on Wayland
Date: Tue, 10 Oct 2023 12:59:58 +0000	[thread overview]
Message-ID: <875y3ews35.fsf@lan> (raw)
In-Reply-To: <83pm1mvfw4.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 10 Oct 2023 15:08:43 +0300")

Eli Zaretskii <eliz@gnu.org> writes:

> You do have the freedom, and Emacs gives users more freedom in
> customizing fonts than most other GUI apps.

In my experience, Emacs is certainly one of, if not the most effective
at customizing fonts, made even more impressive considering the fact
that everything is controlled by elisp.

Kudos to you for making a truly wonderful GUI possible!

> You just need to know very well what you are doing to exercise that
> freedom, so we are trying hard to make the need for that as small and
> rare as possible.

Yes.  In a previous reply you mentioned that this configuration is
non-trivial, and indeed a perfect out-of-the-box experience is a noble
goal in itself.

Alas, some of us users would still try to customize the fonts with very
little understanding of the intricacies of Emacs internals.

> Thanks.  The question is: how can Emacs distinguish between these
> fonts and decide that one of them is not suitable.

I think this is not possible without the user explicitly specifying
which variant is needed.  In HTML this is done with language tags, such
as lang="zh-Hans", but this strategy only covers a minority of cases,
because

- the author of the HTML document has to specify this language tag
- the browser must understand this tag
- only applies to HTML documents

In most other cases, such as the user interface of an Android phone, the
default variant is chosen during language configuration.  If a non-CJK
language was chosen, such as en-US for American English (I do this), it
will behave in the same manner as Emacs.

> In general, Emacs picks up the first font that matches the fontset's
> spec, so we need to come up with two things: (a) the way for Emacs to
> distinguish between these fonts, and (b) the way to encode the
> requirements for a "good" font in our default fontset.  Then Emacs
> will be able to pick up the correct font automatically.

"Good" is, in this case, defined by user.  One font suitable for
Mainland China users is not suitable for Taiwan, Hong Kong or Japan
users, and vice versa.  In other words, it is impossible for Emacs to
determine what variant does a given user prefer.

But there's good news.  I've rebuilt Emacs from latest commit (9 hours
ago) in the emacs-29 branch, with debug symbols enabled.  Fresh out of
the oven!  This was all made very simple and declarative thanks to the
Nix package manager:

https://codeberg.org/m0p/dotfiles/commit/e1fb4ffc4b4ce3a914adbd4c4a49863b2a48afeb

with the following init.el

https://codeberg.org/m0p/dotfiles/raw/commit/eec25a4ae443de78ea3d8ea3d94541060d7861d7/imports/not-nix-config-files/emacs-init.el

We will see if Emacs crashes again.  So far with (4 hours, 43 minutes, 3
seconds) uptime.





  reply	other threads:[~2023-10-10 12:59 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-08 20:32 bug#66416: 29.1; Crashes when visiting HELLO file with pgtk on Wayland Yuchen Guo
2023-10-09 10:31 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-09 11:19   ` Eli Zaretskii
2023-10-09 11:24 ` Eli Zaretskii
     [not found]   ` <87bkd7k6b8.fsf@lan>
2023-10-09 18:45     ` Eli Zaretskii
2023-10-09 19:07       ` Yuchen Guo
2023-10-10  2:30         ` Eli Zaretskii
2023-10-10  5:26           ` Yuchen Guo
2023-10-10 12:08             ` Eli Zaretskii
2023-10-10 12:59               ` Yuchen Guo [this message]
2023-10-10 13:40                 ` Eli Zaretskii
2023-10-10 16:26                   ` Yuchen Guo
2023-10-11 11:31                     ` Eli Zaretskii
2023-10-11 12:45                       ` Yuchen Guo
2023-10-11 13:12                         ` Eli Zaretskii
2023-10-10  4:39         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-09 18:44 ` bug#66416: Coredump Yuchen Guo
2023-10-12  7:46 ` bug#66416: GDB output from new crash Yuchen Guo
2023-10-12  8:12   ` Yuchen Guo
2023-10-12 10:23     ` Eli Zaretskii
2023-10-12 11:22       ` Yuchen Guo
2023-10-12 12:31         ` Eli Zaretskii
2023-10-12 13:58           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-12 14:28             ` Yuchen Guo
2023-10-12 14:42             ` Yuchen Guo
2023-10-14 11:00               ` Eli Zaretskii
2023-10-14 11:26                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-14 12:38                   ` Eli Zaretskii
2023-10-14 12:40                   ` Yuchen Guo
2023-10-14 12:44                     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-14 14:23                       ` Yuchen Guo
2023-10-14 15:40                         ` Eli Zaretskii
2023-10-15  1:11                         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-15  5:54                           ` Yuchen Guo
2023-10-12 11:43       ` Yuchen Guo
2023-10-14 19:14 ` bug#66416: 29.1; pgtk build crashes due to ftcrfont Yuchen Guo
2024-04-16  0:27   ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]   ` <87mspui23l.fsf@>
2024-04-16 12:16     ` Eli Zaretskii
2024-04-16 13:13       ` Mattias Engdegård
2024-04-16 14:21         ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-16 13:39       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-16 14:19         ` Björn Bidar 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=875y3ews35.fsf@lan \
    --to=yguo@posteo.net \
    --cc=66416@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.