empty charset registry?

[Ilya N. Golubev]

The main issue is as follows.  Some text processing features of quite
general purpose, including the ability to

> view raw text in user specified font

were available in any build configuration, with use of clearly
documented xemacs core features.  Now they are restricted to only some
build configurations or only working on some sorts of X servers as
described below.  Is such a regression absolutely necessary?

The restrictions are as follows.

> In the unlikely event that the font
> you want to use doesn?t have a full XLFD available, please create one using
> a directory and fonts.alias,

Already wrote why it may be impossible, and even proper to remain so:
<multiuser X [Re: empty charset registry?]> of Mon, 13 Nov 2006
20:30:07 +0300 (<214pt345ls.fsf_-_ at mo.msk.ru>).  For the same reason the
question:

> When you do 
> can you then select the font with xfd in full dashed form? 

is irrelevant.  What I can <do> with that particular X server in that
particular installation of that system does not have to be possible
even in different installation of the same system, let alone of one
which X server package is slightly different, with more access control
features.

> or use the non-Mule version of XEmacs

This is direct discouragement to use Mule.

Even personally would avoid building xemacs 21.{1,2} with mule for
quite a long time exactly for the fear that some non- mule features
would be unavailable in it.  Eventually figured how not to depend on
non- mule configuration in all uses.  Now such fears receive
justification.  Is it necessary?

That many users are unable to (re-) build xemacs and thus confined to
some single binary package of single configuration is an additional
issue.  I personally did not belong to that category for many years,
but may easily get back there, at least temporarily on some systems.
Sometimes these systems are (yet) poorly equipped with development
tools.  Sometimes even xemacs packager for that system may have (most
likely by unintentional omission) violated GPL in failing to
distribute patches he applied to have xemacs build on that system, and
/ or is simply unaccessible for any communication.


> Running XEmacs on X11 is not useful after a successful call to
>
> (set-face-font 'default "cursor") 

This example is setting (the default face) font specification for
*default* locale.  Indeed never did it that way.  Instead, would put
quite weird fonts (including even this one!) in font specification for
*frame* / window, as wrote in the initial message on the topic,
<96wt67fa3f.fsf at mo.msk.ru>.  If you like, call it a poor man's `xfd' /
`xfontsel' (OTOH, very flexible and convenient, again due to ability
to see several frames / windows at the same time).  And it certainly
makes sense.

To remove the loophole for misunderstanding, normally do that setting
face font specification for frame is my environment by adding (to
stick with font name from your example):

XEmacs*cu.default.attributeFont:  cursor

to xemacs X resource file (`~/Emacs' for 21.4, `~/XEmacs' for 21.5)
before xemacs startup, as described in <(xemacs) Face Resources>.  To
write it in elisp as you do, it is

(set-face-font
 'default "cursor" (selected-frame) 'x
 'append)

(Or choose your favorite form from backtrace like this.)

  add-spec-list-to-specifier(SPECIFIER ((FRAME (... . "cursor"))) append)
  # bind (is-valid nval how-to-add tag-set locale value specifier)
  set-specifier(SPECIFIER "cursor" FRAME x append)
  # bind (how-to-add tag-set locale value property face)
  set-face-property(default font "cursor" FRAME x append)
  # bind (how-to-add tag-set locale font face)
  set-face-font(default "cursor" FRAME x append)
  # bind (rp bp dp hp stp ulp bgp bg fg fn name face-sym device-class tty-tag-set x-tag-set tag-set append set-anyway locale face)
  x-init-face-from-resources(default FRAME)
  # bind (devtype locale face)
  init-face-from-resources(default FRAME)
  # bind (face G65294 frame)
  init-frame-faces(FRAME)
  # (unwind-protect ...)
  # bind (frame-being-created)
  make-frame((name "cu"))


> If I?m implementing something, it is relevant to me what real-world
> situations are affected by it.

Not necessarily.  When the issue is mere consistency of behavior, or
conforming to documentation, or language standard conformance of code,
most of user system specifics are irrelevant.  And users may have many
reasons not to reveal such a specifics.  Not depending on them is
certainly more reliable.

A related issue is it is certainly not relevant how many users have
exactly the sort of system in question.  In any system complex enough,
which xemacs certainly is, just about any feature is used only by a
minority.  And just any user may be marked a minority this way.


Will be unable to check mail until Dec 12.