Re: [PATCH] empty charset registry?
18 years, 1 month
Aidan Kehoe
Ar an naoiú lá de mí na Samhain, scríobh stephen(a)xemacs.org:
> Aidan Kehoe writes:
>
> > The first X11 release with the current server-side font
> > architecture, X11R5, shipped with a long list of ISO-8859-1
> > fonts. So, I am inclined to add the following. Any comments?
>
> If you can't find any font with "*", why would you expect a match with
> "*-iso8859-1"? This is quite unintuitive.
Not "*", rather "*really broken-registry and charset", after someone had
done:
(set-charset-registries 'ascii ["really broken-registry and charset"])
> After integrating your patches, I get a crash in temacs in a tree
> almost identical to CVS HEAD, in an Xft build on Mac OS X with the
> X.org server and libraries, in face initialization. Have you done an
> Xft build with this stuff yet?
Yes. Please post a bug report; I can’t reproduce--currently on Cygwin,
previously on NetBSD.
> I dunno, Aidan. It's not your fault that X goes belly-up whenever you
> hand it something it doesn't expect, but it is a fact that it does. I
> don't really see any good reason to suppose that there aren't several
> more crashes lurking, because you've completely changed the model. Up
> to now, we assumed that we could choose from the whole list of fonts.
That wasn’t always the case; cf. the comment on x-init-device-faces in
x-faces.el.
> Now we have to get the query right. But querying X servers has always
> been less than reliable.
Would you prefer a fallback to fixed for ASCII instead? XFree86 servers at
least give this error if it’s not available:
Fatal server error:
could not open default font ’fixed’
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: empty charset registry?
18 years, 1 month
Aidan Kehoe
Ar an t-ochtú lá de mí na Samhain, scríobh stephen(a)xemacs.org:
> [...]
Related to this, I find that
(set-charset-registries 'ascii ["*-*"])
crashes XEmacs with my change.
To solve the first problem, I’m inclined to apply this:
Index: mule-charset.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/mule-charset.c,v
retrieving revision 1.50
diff -u -r1.50 mule-charset.c
--- mule-charset.c 2006/11/07 14:04:56 1.50
+++ mule-charset.c 2006/11/08 10:08:53
＠＠ -913,6 +913,15 ＠＠
invalid_argument("Not an X11 REGISTRY-ENCODING combination",
XVECTOR_DATA(registries)[i]);
}
+
+ if (qxestrchr(XSTRING_DATA(XVECTOR_DATA(registries)[i]), '*') ||
+ qxestrchr(XSTRING_DATA(XVECTOR_DATA(registries)[i]), '?'))
+ {
+ invalid_argument
+ ("XLFD wildcards not allowed in charset-registries",
+ XVECTOR_DATA(registries)[i]);
+
+ }
}
XCHARSET_REGISTRIES (charset) = registries;
Alternatively, I could add XLFD wildcard handling to
x_font_spec_matches_charset. But it seems to me that the only use for this
is evil hacks like Ilya’s, so it’s more complicated and less maintainable
code for little gain.
The equivalent code on 21.4.19,
(set-charset-registry 'ascii "a very long pattern that won't match at all")
doesn’t crash. That’s because of a special-case for ASCII, and the fact that
the XLFD is not edited to include the charset registry. I would like to
special-case ASCII too; is it reasonable to require that every X11 server we
run on have one font with its XLFD ending in iso8859-1 ?
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: font for jit chars?
18 years, 1 month
Aidan Kehoe
Ar an t-ochtú lá de mí na Samhain, scríobh Ilya N. Golubev:
> So, now `specifier-matching-instance' MATCHSPEC `car' must be
> `(get-charset 'jit-ucs-charset-0)', and this does make difference with
> just `'jit-ucs-charset-0'?
No.
> 1If so, please document. If all of it should not make difference, then my
> tools, `xfontsel', `xfd', show wrong things, or at least fail to
> reproduce how xemacs uses this font.
Does specifier-matching-instance give a different result for the font
compared to this:
(face-font-instance 'default nil 'jit-ucs-charset-0)
? This assumes it is the default face you are investigating.
> And should normally use them to select the font. So in this case will
> need at least an item in `PROBLEMS' describing how to figure that X tools
> are broken this way, and what to use instead.
>
> Is `encode-as-utf-8' in font specifier TAG-SET essential? If so,
> please document.
It’s essential if you want the font specification to apply to the JIT UCS
character sets. See define-specifier-tag for documentation of the new
specifier tag charset predicates; encode-as-utf-8 is a predefined specifier
tag with the semantics of the following:
(define-specifier-tag 'encode-as-utf-8 nil
(lambda (charset)
(charset-property charset 'encode-as-utf-8)))
To apply it to jit-ucs-charset-0 specifically, you could write:
(define-specifier-tag 'jit-ucs-charset-0 nil
(lambda (charset)
(eq charset (find-charset 'jit-ucs-charset-0))))
(set-face-font 'default "your desired font xlfd" nil
'(x jit-ucs-charset-0))
Again, this assumes the default face.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: font for jit chars?
18 years, 1 month
Aidan Kehoe
Ar an t-ochtú lá de mí na Samhain, scríobh Ilya N. Golubev:
> `specifier-matching-instance', even if not signals error, no longer
> returns font actually used for displaying emchars in
> `jit-ucs-charset-0'. One it returns (as part of font instance) just
> does not have the code points that are still displayed. How do we
> figure the font used for these emchars?
(specifier-matching-instance (face-font 'default)
(cons (get-charset 'jit-ucs-charset-0)
'initial))
Or,
(face-font-instance 'default nil 'jit-ucs-charset-0)
> How do we customize it?
(set-face-font 'default "your desired font pattern here"
nil '(x encode-as-utf-8) 'remove-tag-set-prepend)
> Please document.
Will do. Thank you for the bug report.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: decoders writing control-1 chars?
18 years, 1 month
Stephen J. Turnbull
Ilya N. Golubev writes:
> Only perhaps in 21.5. (Never tried to add new ucs <-> emchar mappings
> in it. May still need mule-ucs to do that.)
Of course you don't. 21.5 can read Unicode Consortium-style mapping
files and create a chartable from that.
Regarding bugs in CCL, what it comes down to is that there is
currently *one* person asking for improvements in it and *no*
volunteers. (Maybe Aidan will do it; he has different tastes about
CCL from me---but he hasn't said he will yet, and there are other
things I hope he'll do first.)
If necessary the change the Aidan introduced to 21.4 can be reverted.
Would that fix your immediate problem?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
core dump after 2006-11-06
18 years, 1 month
Stephen J. Turnbull
Ilya N. Golubev writes:
> That is, unconverted utf-8 representation remains in internal buffer
> of coding lstream. When gc occurs, it tries to finalize that lstream,
> that tries to complete conversion, that signals the same error.
> Signalling error while gc is considered assertion failure.
This seems to me to be a bug in the lstream code, not in the coding
code.
We *should* work around it as you describe, but that just means the
lstream bug will be waiting for us in some future time.
> Still having core file. Will send additional details on request.
Please always attach at least Installation. In this case I'm curious
what GC configuration you're using.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: empty charset registry?
18 years, 1 month
Aidan Kehoe
Ar an seachtú lá de mí na Samhain, scríobh Ilya N. Golubev:
> Your 2006-11-05 change of how font is searched for given mule charset
> when instancing font specifiers is clearly user visible. Still there
> is no documentation changes reflecting that, let alone addition to
> `NEWS'. One of incompatibilities is that currently the call:
>
> (set-charset-registry 'ascii "")
>
> signals error:
>
> (invalid-argument "Not an X11 REGISTRY-ENCODING combination" "")
>
>
> Before the change doing this particular elisp call had an obvious and
> a very useful effect. That is, user could easily view raw text
> without explicit mule decoding.
¿Cómo?
Of course there is Mule decoding, otherwise the characters would be
displayed as numbers.
> This is extremely valueable when viewing data items consisting of
> snippets of text in different 8-bit encodings. Those easily result from
> erroneous process output, or simply are some legacy text files. This was
> possible because could obviously specify xemacs to display raw text
> charsets in the very first font retrieved from font specifier for
> particular locale, like this.
>
> (let ((l '(ascii latin-iso8859-1)))
> (while l
> (set-charset-registry (car l) "")
> (setq l (cdr l))))
>
> Then would just set font specifications in default (or even perhaps
> other) face font specifiers for frame (or window), and could rely
> xemacs to display raw text in exactly the font as specified.
That’s a horrible, evil hack.
> Another incompatibility is that `control-1' characters are always
> displayed as `\OCTAL', not as code points of some 8-bit font. The
> latter may be disired for the same reasons.
>
> How do we view raw text in user specified font after the change?
(set-charset-registry 'ascii "charset-registry-of-desired-font")
(set-charset-registry 'latin-iso8859-1 "charset-registry-of-desired-font")
(set-face-font 'default "full-xlfd-of-desired-font")
That is to say, work out which font you want, and choose it.
> How do we check whether `set-charset-registry' in given version and build
> implements old or new data format? Please document.
You shouldn’t need to, if you use the above two lines.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
[COMMIT] Re-introduce ccl-encode-to-ucs-2
18 years, 1 month
Aidan Kehoe
Ar an seachtú lá de mí na Samhain, scríobh Ilya N. Golubev:
> Please fix.
Fixed. Thank you for the bug report.
APPROVE COMMIT
NOTE: This patch has been committed.
lisp/ChangeLog addition:
2006-11-07 Aidan Kehoe <kehoea(a)parhasard.net>
* unicode.el:
Re-introduce ccl-encode-to-ucs-2; it's still being used by the
JIT-UCS charsets, despite what I thought. Thank you Ilya.
XEmacs Trunk source patch:
Diff command: cvs -q diff -Nu
Files affected: lisp/unicode.el
===================================================================
RCS
Index: lisp/unicode.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/lisp/unicode.el,v
retrieving revision 1.17
diff -u -u -r1.17 unicode.el
--- lisp/unicode.el 2006/11/07 15:58:21 1.17
+++ lisp/unicode.el 2006/11/07 18:49:23
＠＠ -283,6 +283,32 ＠＠
"Sorry, encode-char doesn't yet support anything but the UCS. ")
(char-to-unicode char))
+(when (featurep 'mule)
+ ;; This CCL program is used for displaying the fallback UCS character set,
+ ;; and can be repurposed to lao and the IPA, all going well.
+ ;;
+ ;; define-ccl-program is available after mule-ccl is loaded, much later
+ ;; than this file in the build process. The below is the result of
+ ;;
+ ;; (macroexpand
+ ;; '(define-ccl-program ccl-encode-to-ucs-2
+ ;; `(1
+ ;; ((r1 = (r1 << 8))
+ ;; (r1 = (r1 | r2))
+ ;; (mule-to-unicode r0 r1)
+ ;; (r1 = (r0 >> 8))
+ ;; (r2 = (r0 & 255))))
+ ;; "CCL program to transform Mule characters to UCS-2."))
+ ;;
+ ;; and it should occasionally be confirmed that the correspondence still
+ ;; holds.
+
+ (let ((prog [1 10 131127 8 98872 65823 147513 8 82009 255 22]))
+ (defconst ccl-encode-to-ucs-2 prog
+ "CCL program to transform Mule characters to UCS-2.")
+ (put (quote ccl-encode-to-ucs-2) (quote ccl-program-idx)
+ (register-ccl-program (quote ccl-encode-to-ucs-2) prog)) nil))
+
;; #### UTF-7 is not yet implemented, and it's tricky to do. There's
;; an implementation in appendix A.1 of the Unicode Standard, Version
;; 2.0, but I don't know its licensing characteristics.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
[COMMIT] Take the declaration of Qfinal out of mule-charset.c
18 years, 1 month
Aidan Kehoe
Ar an séiú lá de mí na Samhain, scríobh Vin Shelton:
> After updating to the latest CVS, I'm now getting a link error:
>
> link.exe ＠c:\DOCUME~1\vshelton\LOCALS~1\Temp\nmb02264.
> general.obj : error LNK2005: _Qfinal already defined in mule-charset.obj
> e:\cygwin\usr\local\src\xemacs-21.5-2006-11-06\src\temacs.exe : fatal
> error LNK1169: one or more multiply defined symbols found
> NMAKE : fatal error U1077: 'link.exe' : return code '0x491'
> Stop.
After the below commit, with Visual C++ 2005 Express Edition, make-docfile
segfaults. I touch lib-src/DOC to have the compile continue, and then I get
this:
[...]
Dumping under the name xemacs
NMAKE: fatal error U1077: '"D:\Cygwin\home\Aidan\xemacs-21.5\lib-src\i"'
: return code '0x80000003'
Stop.
D:\Cygwin\home\Aidan\xemacs-21.5\nt>
This seems to be something specific to my install; if you’ve seen it before
I’d love a pointer to how to avoid it.
APPROVE COMMIT
NOTE: This patch has been committed.
src/ChangeLog addition:
2006-11-07 Aidan Kehoe <kehoea(a)parhasard.net>
* mule-charset.c:
Take the Qfinal declaration out of mule-charset.c; fixes the MSVC
build. Sorry Vin!
XEmacs Trunk source patch:
Diff command: cvs -q diff -u
Files affected: src/mule-charset.c
===================================================================
RCS
Index: src/mule-charset.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/mule-charset.c,v
retrieving revision 1.49
diff -u -r1.49 mule-charset.c
--- src/mule-charset.c 2006/11/06 19:35:45 1.49
+++ src/mule-charset.c 2006/11/07 14:02:46
＠＠ -79,8 +79,8 ＠＠
Lisp_Object Qcharsetp;
-/* Qdoc_string, Qdimension, Qchars defined in general.c */
-Lisp_Object Qregistries, Qfinal, Qgraphic, Qregistry;
+/* Qdoc_string, Qdimension, Qchars, Qfinal defined in general.c */
+Lisp_Object Qregistries, Qgraphic, Qregistry;
Lisp_Object Qdirection;
Lisp_Object Qreverse_direction_charset;
Lisp_Object Qshort_name, Qlong_name;
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: Windows native build failure
18 years, 1 month
Aidan Kehoe
Ar an séiú lá de mí na Samhain, scríobh Vin Shelton:
> [...] Aidan, next time please be a little more careful and don't rush to
> check things in. It's better to avoid these gotchas in the first place.
I wrote the patch over a period of months; I assure you I wasn’t rushing
it. This is the normal consequence of developing on a platform that you
don’t build on, or on which you only build when you’ve free time in a
full-time job. Just like, for example, the issue that provoked the recent
mail on building on AIX giving an empty file.
I know Windows is an important platform, and I’ve been planning on and off
to get myself a machine or a VMWare image or a partition to test Windows
builds on. But, this laptop regularly overheats building XEmacs as it
is--it’s likely to behave even worse under VMWare. I haven’t the stomach for
the weekend necessary to get NetBSD and XP to play nice on my hard disk,
especially since these builds are the only reason I need to or want to use
XP. Current plans are to get a Mac Mini and install Bootcamp--I anticipate
getting to doing that in early January. Until then, I will pay more
attention to the Windows stuff, but I can’t guarantee that I won’t repeat
this sort of mistake. I thank you in advance for your forbearance.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta