unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: Kenichi Handa <handa@m17n.org>
Cc: Yoshiaki Kasahara <kasahara@nc.kyushu-u.ac.jp>, emacs-devel@gnu.org
Subject: Re: X fonts selection weirdness
Date: Wed, 25 Jun 2008 10:15:25 +0200	[thread overview]
Message-ID: <85ej6mnd5u.fsf@lola.goethe.zz> (raw)
In-Reply-To: <E1KBPis-0003BB-BA@etlken.m17n.org> (Kenichi Handa's message of "Wed, 25 Jun 2008 16:47:22 +0900")

Kenichi Handa <handa@m17n.org> writes:

> I installed a fix.  Please try again.

[...]

> The above should work, but I'm now thinking about
> introducing non-default-font-script-list:

[...]

I can't help feeling that we are currently stumbling without much
orientation through a maze of ad-hoc local patches and fixes.

This does not feel like it should be the intended mode of operation:
other applications have to use fontsets, too.  So I have the suspicion
that at least for some platforms, we are approaching the problem from an
angle that has not been intended by the creators of the rendering
infrastructures we are using.

It may be that the current Emacs APIs don't allow us to match our font
stuff to what is Xft's intended operation.  In that case, it might be
better to interface at a different level.  If that means that the
behavior and customization of Xft- and non-Xft rendering will differ
more than it does currently, that would appear a reasonable price to pay
in my opinion.

In any way: our current rate of creating yet another ad-hoc variable
intended to patch around the font system in a manner that no other
application does is not useful for platform integration.  And it does
not help people understand what happens.

I have no expertise at all in that area.  I just recognize a pattern
here that feels like a bad idea.  It is a pattern occuring when
something needs to get shipped, and sound judgment is suspended while
"just make it work, we won't touch this again" is the only left
priority.  But "we won't touch this again" is not what we are aiming for
here.

If doing this right needs more time and plan and thought, then we should
invest that.  Or it is going to bite us later.

Again: I lack the technical skills to judge the subsystems here.  I
might be all wrong about this.  But it feels increasingly that we are
getting complexity that will be beyond all users, even if perhaps not
all developers.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




  parent reply	other threads:[~2008-06-25  8:15 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-24  3:42 X fonts selection weirdness Yoshiaki Kasahara
2008-06-24  4:21 ` Miles Bader
2008-06-24  6:20   ` Yoshiaki Kasahara
2008-06-24  4:53 ` Kenichi Handa
2008-06-24  5:57   ` Yoshiaki Kasahara
2008-06-24  7:02     ` Kenichi Handa
2008-06-24  9:08       ` Yoshiaki Kasahara
2008-06-25  7:47         ` Kenichi Handa
2008-06-25  7:55           ` Miles Bader
2008-06-25  8:05             ` Jason Rumney
2008-06-25 11:31             ` Kenichi Handa
2008-06-25 13:45               ` Miles Bader
2008-06-25 14:04                 ` Miles Bader
2008-06-26 11:40                 ` Kenichi Handa
2008-06-26 21:20               ` Richard M Stallman
2008-06-27  0:32                 ` Kenichi Handa
2008-06-27 15:38                   ` Richard M Stallman
2008-06-25  8:15           ` David Kastrup [this message]
2008-07-09  1:42             ` Kenichi Handa
2008-07-15  3:34               ` Yoshiaki Kasahara
2008-06-26  7:39           ` Yoshiaki Kasahara
2008-06-24 12:42       ` Stefan Monnier
2008-06-24 15:10         ` Kenichi Handa
2008-06-24 18:46           ` Stefan Monnier
2008-06-25  0:36             ` Kenichi Handa

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=85ej6mnd5u.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=handa@m17n.org \
    --cc=kasahara@nc.kyushu-u.ac.jp \
    /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).