10:26 p.m.
Salam,
I've fixed `list-coding-systems', both with C-u (it simply works now
;) and without it (it now lists only base coding systems, as per
documentation). It was broken because interface of appropriate
functions changed heavily.
It was necessary to change record separator from colon to semicolon
because some coding systems have colons in their names.
Hope it will go into base XEmacs (notify me in that case, please :)
--- mule-diag.el 2001/05/04 06:46:35 1.1
+++ mule-diag.el 2001/05/06 21:18:05
＠＠ -390,68 +390,69 ＠＠
;; Print detailed information on CODING-SYSTEM.
(defun print-coding-system (coding-system)
- (let ((type (coding-system-type coding-system))
- (eol-type (coding-system-eol-type coding-system))
- (flags (coding-system-flags coding-system))
- (aliases (coding-system-get coding-system 'alias-coding-systems)))
- (if (not (eq (car aliases) coding-system))
- (princ (format "%s (alias of %s)\n" coding-system (car aliases)))
- (princ coding-system)
- (setq aliases (cdr aliases))
- (while aliases
- (princ ",")
- (princ (car aliases))
- (setq aliases (cdr aliases)))
- (princ (format ":%s:%c:%d:"
+ (princ coding-system)
+ (if (coding-system-alias-p coding-system)
+ (princ (format " (alias of %s)\n" (coding-system-aliasee
coding-system)))
+ (let ((type (coding-system-type coding-system))
+ (eol-type (coding-system-eol-type coding-system)))
+ (princ (format ";%s;%s;%s;"
type
(coding-system-mnemonic coding-system)
- (if (integerp eol-type) eol-type 3)))
- (cond ((eq type 2) ; ISO-2022
- (let ((idx 0)
- charset)
- (while (< idx 4)
- (setq charset (aref flags idx))
- (cond ((null charset)
- (princ -1))
- ((eq charset t)
- (princ -2))
- ((charsetp charset)
- (princ charset))
- ((listp charset)
- (princ "(")
- (princ (car charset))
- (setq charset (cdr charset))
- (while charset
- (princ ",")
- (princ (car charset))
- (setq charset (cdr charset)))
- (princ ")")))
- (princ ",")
- (setq idx (1+ idx)))
- (while (< idx 12)
- (princ (if (aref flags idx) 1 0))
- (princ ",")
- (setq idx (1+ idx)))
- (princ (if (aref flags idx) 1 0))))
- ((eq type 4) ; CCL
- (let (i len)
- (if (symbolp (car flags))
- (princ (format " %s" (car flags)))
- (setq i 0 len (length (car flags)))
- (while (< i len)
- (princ (format " %x" (aref (car flags) i)))
- (setq i (1+ i))))
- (princ ",")
- (if (symbolp (cdr flags))
- (princ (format "%s" (cdr flags)))
- (setq i 0 len (length (cdr flags)))
- (while (< i len)
- (princ (format " %x" (aref (cdr flags) i)))
- (setq i (1+ i))))))
- (t (princ 0)))
- (princ ":")
+ (symbol-name eol-type)))
+ (let ((flags '()))
+ (cond ((eq type 'iso2022) ; ISO-2022
+ ;; G0, G1, G2, G3
+ ;; probably this should be implemented with (defmacro)?
+ (mapcar*
+ (lambda (GX charset force-charset)
+ (let ((charset-name (coding-system-get coding-system (intern charset))))
+ (if charset-name
+ (let (flag)
+ (if (coding-system-property coding-system (intern force-charset))
+ (setq flag (concat GX ":[" (symbol-name charset-name)
"]"))
+ (setq flag (concat GX ":" (symbol-name charset-name))))
+ (setq flags (append (list flag) flags))))))
+
+ '("G0" "G1" "G2" "G3")
+ '("charset-g0" "charset-g1" "charset-g2"
"charset-g3")
+ '("force-g0-on-output" "force-g1-on-output"
+ "force-g2-on-output" "force-g3-on-output"))
+
+ ;; various other flags
+ (if (coding-system-get coding-system 'short)
+ (setq flags (append '("SHORT-FORM") flags)))
+
+ (unless (coding-system-get coding-system 'no-ascii-eol)
+ (setq flags (append '("ASCII-EOL") flags)))
+
+ (unless (coding-system-get coding-system 'no-ascii-cntl)
+ (setq flags (append '("ASCII-CNTL") flags)))
+
+ (if (coding-system-get coding-system 'seven)
+ (setq flags (append '("SEVEN") flags)))
+
+ (if (coding-system-get coding-system 'lock-shift)
+ (setq flags (append '("LOCKING-SHIFT") flags)))
+
+ (if (coding-system-get coding-system 'no-iso6429)
+ (setq flags (append '("NO-ISO6429") flags))))
+
+ ((eq type 'ccl) ; CCL
+ (princ (format "%s, %s"
+ (coding-system-get coding-system 'encode)
+ (coding-system-get coding-system 'decode) flags))))
+ (setq flags (reverse flags))
+ (if (car flags)
+ (progn
+ (princ (format "%s" (car flags)))
+ (mapc
+ (lambda (flag)
+ (princ (format ", %s" flag)))
+ (cdr flags))))
+ ))
+ (princ ";")
(princ (coding-system-doc-string coding-system))
- (princ "\n"))))
+ (princ "\n")))
;;;###autoload
(defun list-coding-systems (&optional arg)
＠＠ -480,35 +481,49 ＠＠
## LIST OF CODING SYSTEMS
## Each line corresponds to one coding system
## Format of a line is:
-## NAME[,ALIAS...]:TYPE:MNEMONIC:EOL:FLAGS:POST-READ-CONVERSION
-## :PRE-WRITE-CONVERSION:DOC-STRING,
+## NAME[,ALIAS...];TYPE;MNEMONIC;EOL;FLAGS;POST-READ-CONVERSION
+## ;PRE-WRITE-CONVERSION;DOC-STRING,
## where
## NAME = coding system name
## ALIAS = alias of the coding system
## TYPE = nil (no conversion), t (undecided or automatic detection),
## 0 (EMACS-MULE), 1 (SJIS), 2 (ISO2022), 3 (BIG5), or 4 (CCL)
-## EOL = 0 (LF), 1 (CRLF), 2 (CR), or 3 (Automatic detection)
+## EOL = lf (LF), crlf (CRLF), cr (CR), or nil (Automatic detection)
## FLAGS =
-## if TYPE = 2 then
+## if TYPE = 'ISO2022 then
## comma (`,') separated data of the followings:
## G0, G1, G2, G3, SHORT-FORM, ASCII-EOL, ASCII-CNTL, SEVEN,
-## LOCKING-SHIFT, SINGLE-SHIFT, USE-ROMAN, USE-OLDJIS, NO-ISO6429
-## else if TYPE = 4 then
+## LOCKING-SHIFT, NO-ISO6429
+## else if TYPE = 'CCL then
## comma (`,') separated CCL programs for read and write
## else
## 0
## POST-READ-CONVERSION, PRE-WRITE-CONVERSION = function name to be called
##
"))
- (let ((bases (coding-system-list))
- ;;(coding-system-list 'base-only))
- coding-system)
- (while bases
- (setq coding-system (car bases))
- (if (null arg)
- (print-coding-system-briefly coding-system 'doc-string)
+ (if (null arg)
+ ;; print only base coding systems (w/o "-dos", "-unix",
"-mac")
+ (let ((bases (make-hash-table)))
+ ;; put base coding systems into hash-table
+ (mapc
+ (lambda (coding-system)
+ (let* ((base (coding-system-base coding-system))
+ (base-name (coding-system-name base)))
+
+ (unless (gethash base-name bases)
+ (puthash base-name base bases))))
+ (coding-system-list))
+
+ ;; traverse hash-table and print each coding system
+ (maphash
+ (lambda (key value) (print-coding-system-briefly value 'doc-string))
+ bases))
+
+ ;; print all coding systems in details
+ (mapc
+ '(lambda (coding-system)
(print-coding-system coding-system))
- (setq bases (cdr bases)))))
+ (coding-system-list))))
;;;###autoload
(defun list-coding-categories ()
--alexm
2:26 p.m.
Alexey Mahotkin <alexm(a)hsys.msk.ru> writes:
I've fixed `list-coding-systems', both with C-u (it simply
works now
;) and without it (it now lists only base coding systems, as per
documentation). It was broken because interface of appropriate
functions changed heavily.
It was necessary to change record separator from colon to semicolon
because some coding systems have colons in their names.
Hope it will go into base XEmacs (notify me in that case, please :)
Thanks for the patch. Your patch is good and I'd like to
approve it. But I can't since mule-diag.el is in the
package. XEmacs 21.1 does not have functions like
coding-system-aliasee. I think mule-diag.el should belong
to core so that it can avoid issues like this. But the
status quo is that mule-diag.el belongs to mule-base package
and XEmacs 21.1 must be supported by package. Could you
please fix it to work with XEmacs 21.1? Then that will
definitely go in.
--
Yoshiki Hayashi
4:34 p.m.
>>>> "Yoshiki" == Yoshiki Hayashi
<yoshiki(a)xemacs.org> writes:
Yoshiki> Your patch is good and I'd like to approve it. But I
Yoshiki> can't since mule-diag.el is in the package. XEmacs 21.1
Yoshiki> does not have functions like coding-system-aliasee. I
Yoshiki> think mule-diag.el should belong to core so that it can
Yoshiki> avoid issues like this.
I tend to disagree. The functions in that file are basically
developer's aids; they have little to do with the Mule implementation
per se. An excellent candidate for packagization, IMO.
I don't see why the same argument doesn't apply to all packages that
use APIs that might change. calc comes to mind as an example of a
library that has been "attacked" many times by unexpected API changes,
but surely you wouldn't advocate moving calc to the core.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
8:47 p.m.
>>>> "YH" == Yoshiki Hayashi
<yoshiki(a)xemacs.org> writes:
YH> But I can't since mule-diag.el is in the package. XEmacs
YH> 21.1 does not have functions like coding-system-aliasee.
I've tested this tiny patch to my patch with XEmacs 21.1.10 (those
functions were broken there as horribly too):
--- mule-diag.el 2001/05/06 21:18:52 1.4
+++ mule-diag.el 2001/05/08 19:15:42
＠＠ -391,7 +391,8 ＠＠
;; Print detailed information on CODING-SYSTEM.
(defun print-coding-system (coding-system)
(princ coding-system)
- (if (coding-system-alias-p coding-system)
+ ;; aliases for coding system are not supported in XEmacs 21.1.x
+ (if (and (functionp 'coding-system-alias-p) (coding-system-alias-p coding-system))
(princ (format " (alias of %s)\n" (coding-system-aliasee
coding-system)))
(let ((type (coding-system-type coding-system))
(eol-type (coding-system-eol-type coding-system)))
'encode and 'decode properties in 21.1 are printed out rather
incomprehensibly:
alternativnyj-mac;ccl;Cy.Alt:t;cr;[1 110 14 1051 21 140 -1017 -1268
...skipped... 32 32 32 32 32 32 1648 -66292 22];Coding-system used for
Alternativnyj
This could be somehow "fixed" (at least printing just "there is
'encode/'decode ccl program") simply, as `arrayp' helps to distinguish
between old-style and new-style ccl-programs.
YH> I think mule-diag.el should belong to core so that it can avoid issues
YH> like this. But the status quo is that mule-diag.el belongs to
YH> mule-base package and XEmacs 21.1 must be supported by package.
Hm. Is there anywhere explained which versions of XEmacsen should be
supported by packages?
YH> Could you please fix it to work with XEmacs 21.1? Then that will
YH> definitely go in.
That'd be great even though I understand that no one probably will use
those ;) But it was very important patch for my Lisp education (thanks
again, Hannu) :)
--alexm
10:29 p.m.
Alexey Mahotkin <alexm(a)hsys.msk.ru> writes:
Hm. Is there anywhere explained which versions of XEmacsen should
be supported by packages?
Currently the earliest XEmacs you need to worry about is 21.1. It
goes without saying that releases *later* than that are supported.
When 21.4.x becomes stable and widely used, I expect the 21.1 support
to be relaxed.
5:17 a.m.
>>>> "Alexey" == Alexey Mahotkin
<alexm(a)hsys.msk.ru> writes:
Alexey> 'encode and 'decode properties in 21.1 are printed out
Alexey> rather incomprehensibly:
Alexey> This could be somehow "fixed" (at least printing just
Alexey> "there is 'encode/'decode ccl program") simply, as
Alexey> `arrayp' helps to distinguish between old-style and
Alexey> new-style ccl-programs.
Why "fix" it? The point of these functions is "debug" information
for
developers. They are hardly friendly to ordinary users, so removing
information is a bad idea IMO.
Alexey> Hm. Is there anywhere explained which versions of
Alexey> XEmacsen should be supported by packages?
Packages are supported by XEmacs starting with 20.4. You "should"
support them all. In practice, nobody is likely to object if you
submit a patch as "tested with $STABLE and $BETA", and ignore older
versions. The earliest version tested should be documented in the
file if you have any suspicions. Right now STABLE=21.1, BETA=21.5,
and 21.4 is close enough to 21.5 not to make a difference which you
test. (This will not be true anymore in a few weeks, as Ben Wing is
planning a large merge of Mule code he is currently developing.).
Mule APIs change often enough that you should always be suspicious of
backward incompatibilities in mule libraries. :(
YH> Could you please fix it to work with XEmacs 21.1? Then that
YH> will definitely go in.
Alexey> That'd be great even though I understand that no one
Alexey> probably will use those ;)
If they worked, probably people would use them. I certainly would.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
8:33 a.m.
Alexey Mahotkin <alexm(a)hsys.msk.ru> writes:
>>>>> "YH" == Yoshiki Hayashi
<yoshiki(a)xemacs.org> writes:
YH> But I can't since mule-diag.el is in the package. XEmacs
YH> 21.1 does not have functions like coding-system-aliasee.
I've tested this tiny patch to my patch with XEmacs 21.1.10 (those
functions were broken there as horribly too):
Thanks! I still have a few comments but it is cleary better
than current version in package. Reviewed and approved.
Steve, could you apply these two patches?
<15093.49523.736978.443168(a)gargle.gargle.HOWL>
http://list-archive.xemacs.org/xemacs-patches/200105/msg00029.html
<15096.19782.470107.692088(a)gargle.gargle.HOWL>
http://list-archive.xemacs.org/xemacs-patches/200105/msg00043.html
The patched version does not print coding-system aliases
with M-x list-coding-systems because (coding-system-get
coding-system 'alias-coding-systems) doesn't work on XEmacs.
C-u M-x prints subsidiary coding-systems (-unix, -mac, -dos)
It should only print base coding-systems. However, these
are not big issues since they haven't been working for quite
a while. But you are always welcomed to fix them
yourself. :-)
--
Yoshiki Hayashi
8:44 a.m.
>>>> "YH" == Yoshiki Hayashi
<yoshiki(a)xemacs.org> writes:
YH> C-u M-x prints
YH> subsidiary coding-systems (-unix, -mac, -dos) It should only print
YH> base coding-systems.
I intently did it that way because print-coding-system reports EOL
field. So there is no sense to ignore EOL variations.
Thanks,
--alexm
3:21 a.m.
Alexey Mahotkin <alexm(a)hsys.msk.ru> writes:
>>>>> "YH" == Yoshiki Hayashi
<yoshiki(a)xemacs.org> writes:
YH> C-u M-x prints
YH> subsidiary coding-systems (-unix, -mac, -dos) It should only print
YH> base coding-systems.
I intently did it that way because print-coding-system reports EOL
field. So there is no sense to ignore EOL variations.
Well, that's why listing subsidiary coding-system is
redundant. :-)
If EOL of base coding-system is nil (automatic detection),
then it has all three subsidiary coding-system. If EOL of
base coding-system is non-nil (LF, CRLF, CR), then it has no
subsidiary coding-system.
This is how FSF Emacs's list-coding-systems works and I
prefer their behavior. (I just prefer it, there's nothing
wrong with your version.)
--
Yoshiki Hayashi
10:01 a.m.
Yoshiki Hayashi wrote:
Alexey Mahotkin <alexm(a)hsys.msk.ru> writes:
> I've fixed `list-coding-systems', both with C-u (it simply works now
> ;) and without it (it now lists only base coding systems, as per
> documentation). It was broken because interface of appropriate
> functions changed heavily.
>
> It was necessary to change record separator from colon to semicolon
> because some coding systems have colons in their names.
>
> Hope it will go into base XEmacs (notify me in that case, please :)
Thanks for the patch. Your patch is good and I'd like to
approve it. But I can't since mule-diag.el is in the
package. XEmacs 21.1 does not have functions like
coding-system-aliasee. I think mule-diag.el should belong
to core so that it can avoid issues like this. But the
status quo is that mule-diag.el belongs to mule-base package
and XEmacs 21.1 must be supported by package. Could you
please fix it to work with XEmacs 21.1? Then that will
definitely go in.
speaking of this ... long ago i realized that xemacs-base and mule-base
definitely belong in the core, not as packages.
what do others think of this?
--
Yoshiki Hayashi
--
ben
I'm sometimes slow in getting around to reading my mail, so if you
want to reach me faster, call 520-661-6661.
See http://www.666.com/ben/chronic-pain/ for the hell I've been
through.
12:23 p.m.
>>>> "Ben" == Ben Wing <ben(a)666.com>
writes:
Ben> speaking of this ... long ago i realized that xemacs-base
Ben> and mule-base definitely belong in the core, not as packages.
What's the rationale? Is it just the build and runtime problems due
to missing libraries when bootstrapping, or is it something else?
Ben> what do others think of this?
I'm not sure. Many of those files do not implement "core"
functionality (eg, canna.el and mule-diag.el), and can use standard
APIs as documented in Lispref.
Certainly, it's annoying to have build problems (eg, Norbert Koch's
make check failures) because commonly used libraries are in packages.
But I think it's better to fix that problem by having a subset of
packages distributed with XEmacs sources, and keep the logical
distinction between "core" libraries (which are implemented via
internal APIs we reserve the right to change on a whim) and "package"
libraries, which use only public APIs.
I don't know how to implement this for CVS, though, or if it even
needs to be. I have thought about it for the tarballs. Note that it
is not a problem for the netinstaller.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
2:44 p.m.
"Stephen J. Turnbull" wrote:
>>>>> "Ben" == Ben Wing <ben(a)666.com> writes:
Ben> speaking of this ... long ago i realized that xemacs-base
Ben> and mule-base definitely belong in the core, not as packages.
What's the rationale? Is it just the build and runtime problems due
to missing libraries when bootstrapping, or is it something else?
it has to do with maintainability. much of the stuff in xemacs-base really is
part of the core [e.g. advice.el, comint.el, shell.el, etc.]. much of the core
depends on xemacs-base, and xemacs-base depends on the core, and these two
things are closely tied together. but there's an artificial separation here
that makes it very difficult and cumbersome to make changes in xemacs-base,
since we have to worry about keeping compatibility with old versions of xemacs
and can't use other new core functions in them, etc. the whole purpose of the
package system is to allow independent chunks to be maintained and upgraded
independently, but in this case xemacs-base is *NOT* an independent package
since it's so bound up with the core. any potential gain from being able to
upgrade it independently is far outweighed by the loss caused by the difficulty
in working on its code.
the fact that some files do not seem part of the core is irrelevant. we simply
move those files out -- or perhaps, move everything in xemacs-base that's really
part of the core into the core, and leave the remainder.
Ben> what do others think of this?
I'm not sure. Many of those files do not implement "core"
functionality (eg, canna.el and mule-diag.el), and can use standard
APIs as documented in Lispref.
Certainly, it's annoying to have build problems (eg, Norbert Koch's
make check failures) because commonly used libraries are in packages.
But I think it's better to fix that problem by having a subset of
packages distributed with XEmacs sources, and keep the logical
distinction between "core" libraries (which are implemented via
internal APIs we reserve the right to change on a whim) and "package"
libraries, which use only public APIs.
I don't know how to implement this for CVS, though, or if it even
needs to be. I have thought about it for the tarballs. Note that it
is not a problem for the netinstaller.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
--
ben
I'm sometimes slow in getting around to reading my mail, so if you
want to reach me faster, call 520-661-6661.
See http://www.666.com/ben/chronic-pain/ for the hell I've been
through.
8:20 a.m.
>>>> "Ben" == Ben Wing <ben(a)666.com>
writes:
I completely agree with Ben about the maintainability issues below.
Ben> it has to do with maintainability. much of the stuff in xemacs-base really is
Ben> part of the core [e.g. advice.el, comint.el, shell.el, etc.]. much of the core
Ben> depends on xemacs-base, and xemacs-base depends on the core, and these two
Ben> things are closely tied together. but there's an artificial separation here
Ben> that makes it very difficult and cumbersome to make changes in xemacs-base,
Ben> since we have to worry about keeping compatibility with old versions of xemacs
Ben> and can't use other new core functions in them, etc. the whole purpose of
the
Ben> package system is to allow independent chunks to be maintained and upgraded
Ben> independently, but in this case xemacs-base is *NOT* an independent package
Ben> since it's so bound up with the core. any potential gain from being able to
Ben> upgrade it independently is far outweighed by the loss caused by the difficulty
Ben> in working on its code.
8596
days inactive
8601
days old
12 comments
6 participants
participants (6)
-
Alexey Mahotkin -
Ben Wing -
Hrvoje Niksic -
Martin Buchholz -
Stephen J. Turnbull -
Yoshiki Hayashi