Re: Mule-UCS 0.84 (KOUGETSUDAI) release.

Re: Mule-UCS 0.84 (KOUGETSUDAI) release.

[Werner LEMBERG]

Compiling mule-ucs-0.84 (available from m17n.org) with this patch

  http://tats.iris.ne.jp/mule-ucs/mule-ucs-0.84+tats20021129.diff.gz

using Emacs CVS 2002-11-20 fails.  I get the following suspicious error
message:

  In toplevel form:
  un-define.el:859:30:Warning: reference to free variable progn
  [...]

  In toplevel form:
  un-supple.el:29:1:Error: Symbol's value as variable is void: progn

Using Emacs 20.7.1 the compilation is successful, so I suspect a bug
in the byte compiler.  Any solution?


    Werner

Re: Mule-UCS 0.84 (KOUGETSUDAI) release.

[Richard Stallman]

Could you send me the actual code that I should try to compile?

Re: Mule-UCS 0.84 (KOUGETSUDAI) release.

[Werner LEMBERG]

> Could you send me the actual code that I should try to compile?

Sorry, I can't due to the big size of the archive, but I've just
checked that it is not necessary to apply the patch to trigger the
bug.

Thus a simpliflied procedure is as follows:

  . Download

      ftp://ftp.m17n.org/pub/MULE/Mule-UCS-0.84.tar.gz

    and extract the archive.

  . Enter the archive and execute

      emacs -q --no-site-file -batch -l mucs-comp.el

I can't size this down to a small example -- mule-ucs is one of the
most complicated pieces of Lisp I've ever seen.


     Werner

Re: Mule-UCS 0.84 (KOUGETSUDAI) release.

[Kenichi Handa]

In article <20021202.175121.98551706.wl@gnu.org>, Werner LEMBERG <wl@gnu.org> writes:

> Compiling mule-ucs-0.84 (available from m17n.org) with this patch

>   http://tats.iris.ne.jp/mule-ucs/mule-ucs-0.84+tats20021129.diff.gz

> using Emacs CVS 2002-11-20 fails.  I get the following suspicious error
> message:

>   In toplevel form:
>   un-define.el:859:30:Warning: reference to free variable progn
>   [...]

>   In toplevel form:
>   un-supple.el:29:1:Error: Symbol's value as variable is void: progn

By inspecting several results of macroexpand, I found
mucs-embed-program-with-hooks results in a form:
	(progn progn ...)
So, please try the attached patch?

> Using Emacs 20.7.1 the compilation is successful, so I suspect a bug
> in the byte compiler.  Any solution?

?!?!?  I have no idea why Mule-UCS can be compiled by 20.7
and 21.2 without error.

Himi-san, could you please investigate it?

---
Ken'ichi HANDA
handa@m17n.org


*** mucs.el	2002/12/05 07:53:41	1.1
--- mucs.el	2002/12/05 07:55:59
***************
*** 196,203 ****
  		    (funcall (car hookval))
  		    result)
  	    hookval (cdr hookval)))
!     (cons 'progn
! 	  result)))
  
  (defmacro mucs-define-package (package &rest form)
    "Enclose a unit of package with this.
--- 196,202 ----
  		    (funcall (car hookval))
  		    result)
  	    hookval (cdr hookval)))
!     result))
  
  (defmacro mucs-define-package (package &rest form)
    "Enclose a unit of package with this.

Re: Mule-UCS 0.84 (KOUGETSUDAI) release.

[Andreas Schwab]

Kenichi Handa <handa@m17n.org> writes:

|> *** mucs.el	2002/12/05 07:53:41	1.1
|> --- mucs.el	2002/12/05 07:55:59
|> ***************
|> *** 196,203 ****
|>   		    (funcall (car hookval))
|>   		    result)
|>   	    hookval (cdr hookval)))
|> !     (cons 'progn
|> ! 	  result)))
|>   
|>   (defmacro mucs-define-package (package &rest form)
|>     "Enclose a unit of package with this.
|> --- 196,202 ----
|>   		    (funcall (car hookval))
|>   		    result)
|>   	    hookval (cdr hookval)))
|> !     result))
|>   
|>   (defmacro mucs-define-package (package &rest form)
|>     "Enclose a unit of package with this.

IMHO this patch is better:

--- mucs.el	2002/12/05 10:43:28	1.1
+++ mucs.el	2002/12/05 10:46:26
@@ -196,7 +196,7 @@ In order to embed data or lisp code, use
 		    (funcall (car hookval))
 		    result)
 	    hookval (cdr hookval)))
-    (cons 'progn
+    (list 'progn
 	  result)))
 
 (defmacro mucs-define-package (package &rest form)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Mule-UCS 0.84 (KOUGETSUDAI) release.

[Kenichi Handa]

In article <je7keo7ned.fsf@sykes.suse.de>, Andreas Schwab <schwab@suse.de> writes:
> IMHO this patch is better:

> --- mucs.el	2002/12/05 10:43:28	1.1
> +++ mucs.el	2002/12/05 10:46:26
> @@ -196,7 +196,7 @@ In order to embed data or lisp code, use
>  		    (funcall (car hookval))
>  		    result)
>  	    hookval (cdr hookval)))
> -    (cons 'progn
> +    (list 'progn
>  	  result)))
 
>  (defmacro mucs-define-package (package &rest form)

Could you explain why?

---
Ken'ichi HANDA
handa@m17n.org

Re: Mule-UCS 0.84 (KOUGETSUDAI) release.

[Andreas Schwab]

Kenichi Handa <handa@m17n.org> writes:

|> In article <je7keo7ned.fsf@sykes.suse.de>, Andreas Schwab <schwab@suse.de> writes:
|> > IMHO this patch is better:
|> 
|> > --- mucs.el	2002/12/05 10:43:28	1.1
|> > +++ mucs.el	2002/12/05 10:46:26
|> > @@ -196,7 +196,7 @@ In order to embed data or lisp code, use
|> >  		    (funcall (car hookval))
|> >  		    result)
|> >  	    hookval (cdr hookval)))
|> > -    (cons 'progn
|> > +    (list 'progn
|> >  	  result)))
|>  
|> >  (defmacro mucs-define-package (package &rest form)
|> 
|> Could you explain why?

Actually this is also wrong.  The right fix is to collect the function
results with cons instead of append.  Each hook function is returning a
form to be evaluated, and the final form returned by the macro is
supposed to be one that evaluates each form in sequence.

--- mucs.el	2002/12/05 10:43:28	1.1
+++ mucs.el	2002/12/05 12:15:29
@@ -192,7 +192,7 @@ In order to embed data or lisp code, use
       (if (not (listp hookval))
 	  (error "Invalid hook:%S" hooksym)))
     (while hookval
-      (setq result (append
+      (setq result (cons
 		    (funcall (car hookval))
 		    result)
 	    hookval (cdr hookval)))

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Mule-UCS 0.84 (KOUGETSUDAI) release.

[Stefan Monnier]

>      (while hookval
> -      (setq result (append
> +      (setq result (cons
>  		    (funcall (car hookval))
>  		    result)
>  	    hookval (cdr hookval)))

AKA

    (dolist (f hookval)
      (push (funcall f) result))


-- Stefan

Re: Mule-UCS 0.84 (KOUGETSUDAI) release.

[MIYASHITA Hisashi]

At Thu, 5 Dec 2002 17:15:27 +0900 (JST),
Kenichi Handa wrote:

> ?!?!?  I have no idea why Mule-UCS can be compiled by 20.7
> and 21.2 without error.
> 
> Himi-san, could you please investigate it?

Ummmm...  It must be a dark side of Mule-UCS;-).  As you know, mucs.el
embeds lisp programs generated by TAE and MUCS-CCL, which maybe
varies with the compilation environment...

Anyway, it is a bug of Mule-UCS.  However, it is not a bug
of mucs-embed-program-with-hooks, because all hooks called by this
function(mucs-embed-program-with-hooks) MUST return a list of
S-expression(s), MUST NOT return a bare S-expression.  This rule is
important, because lots of parts of Mule-UCS generates Lisp
programs.  This rule simplifies the interface a little bit.

The patch attached to this mail maybe fixes the problem.  Could you
please test the following patch on Emacs 21.3?

BTW, right now I am too busy to fix the bug,  bu I would like to
check it strictly after my current work is over.

  With regards,

from himi

Index: mucs-ccl.el
===================================================================
RCS file: /cvsroot/mule-ucs/lisp/mucs-ccl.el,v
retrieving revision 1.25
diff -u -r1.25 mucs-ccl.el
--- mucs-ccl.el	3 Oct 2000 14:50:16 -0000	1.25
+++ mucs-ccl.el	5 Dec 2002 16:21:08 -0000
@@ -639,10 +639,9 @@
       (mucs-notify-embedment 'mucs-ccl-required name)
       (setq ccl-pgm-list (cdr ccl-pgm-list)))
 ;   (message "MCCLREGFIN:%S" result)
-    `(progn
-       (setq mucs-ccl-facility-alist
-	     (quote ,mucs-ccl-facility-alist))
-       ,@result)))
+    `((setq mucs-ccl-facility-alist
+	    (quote ,mucs-ccl-facility-alist))
+      ,@result)))
 
 ;;; Add hook for embedding translation informations to a package.
 (add-hook 'mucs-package-definition-end-hook

Re: Mule-UCS 0.84 (KOUGETSUDAI) release.

[Dan Discipulo]

How do I get off this mailing list?

Kenichi Handa wrote:

> In article <je7keo7ned.fsf@sykes.suse.de>, Andreas Schwab <schwab@suse.de> writes:
> > IMHO this patch is better:
>
> > --- mucs.el   2002/12/05 10:43:28     1.1
> > +++ mucs.el   2002/12/05 10:46:26
> > @@ -196,7 +196,7 @@ In order to embed data or lisp code, use
> >                   (funcall (car hookval))
> >                   result)
> >           hookval (cdr hookval)))
> > -    (cons 'progn
> > +    (list 'progn
> >         result)))
>
> >  (defmacro mucs-define-package (package &rest form)
>
> Could you explain why?
>
> ---
> Ken'ichi HANDA
> handa@m17n.org

Re: Mule-UCS 0.84 (KOUGETSUDAI) release.

[Kenichi Handa]

In article <u8yz4ph3p.wl@kiri.meadowy.org.meadow.scphys.kyoto-u.ac.jp>, MIYASHITA Hisashi (宮下 尚:HIMI) <himi@meadowy.org> writes:

> Ummmm...  It must be a dark side of Mule-UCS;-).  As you know, mucs.el
> embeds lisp programs generated by TAE and MUCS-CCL, which maybe
> varies with the compilation environment...

> Anyway, it is a bug of Mule-UCS.  However, it is not a bug
> of mucs-embed-program-with-hooks, because all hooks called by this
> function(mucs-embed-program-with-hooks) MUST return a list of
> S-expression(s), MUST NOT return a bare S-expression.  This rule is
> important, because lots of parts of Mule-UCS generates Lisp
> programs.  This rule simplifies the interface a little bit.

> The patch attached to this mail maybe fixes the problem.  Could you
> please test the following patch on Emacs 21.3?

I confirmed that your change also fixes the problem.  Thank you.

---
Ken'ichi HANDA
handa@m17n.org

Re: Mule-UCS 0.84 (KOUGETSUDAI) release.

[Richard Stallman]

    Sorry, I can't due to the big size of the archive, but I've just
    checked that it is not necessary to apply the patch to trigger the
    bug.

    Thus a simpliflied procedure is as follows:

      . Download

	  ftp://ftp.m17n.org/pub/MULE/Mule-UCS-0.84.tar.gz

That would not be easy for me to do; I will not get involved in this
bug for now.  If someone reduces it to a test case he can mail to me,
then I will take it from there.

It doesn't have to be a small test case, it just has to be something
you can email to me.

Re: Mule-UCS 0.84 (KOUGETSUDAI) release.

[Dave Love]

Werner LEMBERG <wl@gnu.org> writes:

> I can't size this down to a small example -- mule-ucs is one of the
> most complicated pieces of Lisp I've ever seen.

Indeed, and as far as I know, only himi understands it.  The
equivalent functionality in the Emacs development source is quite
simple because CCL can now do lookup in hash tables.  It is currently
_too_ simple, but it should allow you to edit CJK text decoded from
utf-8 in basically the same way as Mule-UCS.

It would be good if people who need that facility and use the Emacs
development version would try it and help make improvements.  I can
sketch ideas for improvement and I have generated some useful tables
which aren't currently installed.  I've also recently corrected an
oversight in CVS -- the mule-utf-8 safe-chars property wasn't updated
to take account of the encodable CJK characters.

I'm not saying that problems with Mule-UCS shouldn't be fixed, of
course.

Re: Mule-UCS 0.84 (KOUGETSUDAI) release.

[Dan Discipulo]

Can you help me get off this mailling list.?

Kenichi Handa wrote:

> In article <u8yz4ph3p.wl@kiri.meadowy.org.meadow.scphys.kyoto-u.ac.jp>, MIYASHITA Hisashi (^[$B5\2<^[(B ^[$B>0^[(B:HIMI) <himi@meadowy.org> writes:
>
> > Ummmm...  It must be a dark side of Mule-UCS;-).  As you know, mucs.el
> > embeds lisp programs generated by TAE and MUCS-CCL, which maybe
> > varies with the compilation environment...
>
> > Anyway, it is a bug of Mule-UCS.  However, it is not a bug
> > of mucs-embed-program-with-hooks, because all hooks called by this
> > function(mucs-embed-program-with-hooks) MUST return a list of
> > S-expression(s), MUST NOT return a bare S-expression.  This rule is
> > important, because lots of parts of Mule-UCS generates Lisp
> > programs.  This rule simplifies the interface a little bit.
>
> > The patch attached to this mail maybe fixes the problem.  Could you
> > please test the following patch on Emacs 21.3?
>
> I confirmed that your change also fixes the problem.  Thank you.
>
> ---
> Ken'ichi HANDA
> handa@m17n.org

Re: You dan@wilshire.com are not member (mule ML)

[Dan Discipulo]

Can somebody help get me off this mailing list.
This doen't help. I don't know what this means.

mule-admin@m17n.org wrote:

> You are not a member of this mailing list <mule@m17n.org>.
>
> If you know the general guide of this list, please send mail with
> the mail body
>
>         guide
>
> to the address
>
>         mule-ctl@m17n.org
>
> where guide is equal to GUIDE for case insensitive.

Re: Mule-UCS 0.84 (KOUGETSUDAI) release.

[Dave Love]

Werner LEMBERG <wl@gnu.org> writes:

> I'm not sure whether Emacs without Mule-UCS can satisfy my needs yet:
> I want to map UTF8 input to the many ETL fonts (which are in various
> encodings) for displaying.

I assumed this was about CJK, but perhaps not.  Anyhow, you can
certainly display the mule-unicode charsets with any fonts you can map
onto them with CCL.  (See `utf-translate-cjk' if the issue really is
CJK in utf-8/16.)

> According to the documentation of unify-8859-on-decoding-mode, it does
> exactly the opposite.

That's really unrelated to display (there was an obsolete comment in
there).  See `utf-fragment-on-decoding' actually to decode into
different charsets (which would need an updated table), or you should
be able to do like ccl-encode-unicode-font in fontset.el but with the
reverse mapping.

> The real problem with Mule-UCS for me is that the configuration of
> this mapping has never worked (besides the fact that it has never been
> documented);

I've certainly configured Mule-UCS (at build time) to change the
precedence of the charsets into which it decodes.  I thought I'd also
changed the font mapping orthogonally, but I don't remember clearly.

> I don't have enough time currently to test Emacs-Unicode which will
> eventually support what I want AFAIK.

I'm not sure quite what you want, or why the internal representation
is relevant.  The fontset mechanism has been changed, but I haven't
finished a user interface for it and I think you don't want to use
that code for real work.