f



Can't get Super key to work

Hi;

My super key won't act as a modifier key in my Xemacs 21.4.15

xmodmap pk shows Super_L and Super_R mapped to keycodes 115 and 116
respectively, as does the gnome keyboard layout gui.  When I run an
Xemacs command with "super f6" for example I get no response, unless I
purposefully mis-define (Super, S, or Super_L) global-set-key.  Then it
tells me I have a modifier error. i.e it seems to be recognizing super
as a modifier of some kind.

My init.el contains the following:

(define-key global-map '(super f6) 'insert-date) and/or
(global-set-key '(super f6) 'insert-date)

The 'insert-date function works. I have tested it with other key
combinations using meta.  I have tried every possible combination of
super and f6, f, (),[] -- nothing works.

I have Fedora Core 3 installed and I had no problems with 'super' under
RH9.  Any suggestions would be welcome.

Regards Bill

P.S.  My shift key when used as a modifier key is a little wonky as well

0
Bill
1/9/2005 5:58:30 AM
comp.emacs.xemacs 2750 articles. 0 followers. Post Follow

73 Replies
818 Views

Similar Articles

[PageSpeed] 57

 Ar an t-ochtú lá de mí Eanair, scríobh Bill: 

 > My super key won't act as a modifier key in my Xemacs 21.4.15

Nor will it for me, after trying

"21.1 (patch 13) \"Crater Lake\" XEmacs Lucid"
"21.4 (patch 13) \"Rational FORTRAN\" XEmacs Lucid," 
"21.4 (patch 15) \"Security Through Obscurity\" XEmacs Lucid" 
"21.5 (beta18) \"chestnut\" (+CVS-20041209) XEmacs Lucid"

with an X11 display from XFree86, version 4.4.0, vendor release number
40400000. 

With another X11 display, also from XFree86, version 4.3.99.5, vendor
release number 40399005, 

"21.4 (patch 11) \"Native Windows TTY Support\" XEmacs Lucid"

it works fine. Looks like it’s an XFree86 problem. 

-- 
“Ah come on now Ted, a Volkswagen with a mind of its own, driving all over
the place and going mad, if that’s not scary I don’t know what is.”
0
Aidan
1/9/2005 9:32:10 PM
 Ar an naoiú lá de mí Eanair, scríobh Aidan Kehoe: 

 >  Ar an t-ochtú lá de mí Eanair, scríobh Bill: 
 > 
 >  > My super key won't act as a modifier key in my Xemacs 21.4.15
 > 
 > Nor will it for me, after trying [...] with an X11 display from XFree86,
 > version 4.4.0, vendor release number 40400000.
 > 
 > With another X11 display, also from XFree86, version 4.3.99.5, vendor
 > release number 40399005, [...] it works fine. Looks like it’s an XFree86
 > problem.

If you’re considering following up on this with the XFree86 people, here’s
some sample xev(1) output, from pressing Super_L and F6 at once. 

The first is from the working server, vendor release 40399005:

KeyPress event, serial 24, synthetic NO, window 0x1000001
    root 0x40, subw 0x0, time 1509293866, (91,91), root:(702,536)
    state 0x0, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes: ""

KeyPress event, serial 24, synthetic NO, window 0x1000001
    root 0x40, subw 0x0, time 1509294004, (91,91), root:(702,536)
    state 0x40, keycode 72 (keysym 0xffc3, F6), same_screen YES,
    XLookupString gives 0 bytes: ""

KeyRelease event, serial 24, synthetic NO, window 0x1000001
    root 0x40, subw 0x0, time 1509294112, (91,91), root:(702,536)
    state 0x40, keycode 72 (keysym 0xffc3, F6), same_screen YES,
    XLookupString gives 0 bytes: ""

KeyRelease event, serial 24, synthetic NO, window 0x1000001
    root 0x40, subw 0x0, time 1509294168, (91,91), root:(702,536)
    state 0x40, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes: ""

The second is from the failing server, vendor release 40400000:

KeyPress event, serial 27, synthetic NO, window 0x400001,
    root 0x3b, subw 0x0, time 93164255, (128,78), root:(133,120),
    state 0x0, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 27, synthetic NO, window 0x400001,
    root 0x3b, subw 0x0, time 93164395, (128,78), root:(133,120),
    state 0x40, keycode 72 (keysym 0xffc3, F6), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 27, synthetic NO, window 0x400001,
    root 0x3b, subw 0x0, time 93164480, (128,78), root:(133,120),
    state 0x40, keycode 72 (keysym 0xffc3, F6), same_screen YES,
    XLookupString gives 0 bytes: 

KeyRelease event, serial 27, synthetic NO, window 0x400001,
    root 0x3b, subw 0x0, time 93164535, (128,78), root:(133,120),
    state 0x40, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes: 

There doesn’t appear to be much of a difference there, but I’m not expert
enough to judge. 

Bye, 

        - Aidan
-- 
“Ah come on now Ted, a Volkswagen with a mind of its own, driving all over
the place and going mad, if that’s not scary I don’t know what is.”
0
Aidan
1/10/2005 12:33:00 AM
Thanks Aidan;

On Mon, 10 Jan 2005 00:33:00 +0000, Aidan Kehoe wrote:

> 
>  Ar an naoiú lá de mí Eanair, scríobh Aidan Kehoe: 
> 
>  >  Ar an t-ochtú lá de mí Eanair, scríobh Bill: 
>  > 
>  >  > My super key won't act as a modifier key in my Xemacs 21.4.15
>  > 
>  > Nor will it for me, after trying [...] with an X11 display from XFree86,
>  > version 4.4.0, vendor release number 40400000.
>  > 
>  > With another X11 display, also from XFree86, version 4.3.99.5, vendor
>  > release number 40399005, [...] it works fine. Looks like it’s an XFree86
>  > problem.
> 
> If you’re considering following up on this with the XFree86 people, here’s
> some sample xev(1) output, from pressing Super_L and F6 at once. 
>
[snip]
I am going to follow up, if get no useful response from the Fedora mailing
list or from here -- its only polite to wait. And, I will use your info.

I have X Window System version 6.8.1.1 which XFree86.org claims is fully
patched.

My Xev looks very much like yours.  My XFree86.0.log and xorg.conf don't
seem to show any problems either -- but then, I don't know much about the
X Windows system yet.

Regards Bill

0
Bill
1/10/2005 4:31:16 PM
>>>>> "Aidan" == Aidan Kehoe <kehoea@parhasard.net> writes:

    Aidan> If you$B!G(Bre considering following up on this with the
    Aidan> XFree86 people, here$B!G(Bs some sample xev(1) output, from
    Aidan> pressing Super_L and F6 at once.

Things are working OK at that level according to your xev traces.
I'll see if I can take a look at this, but given my current queue
it'll be a while.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.
0
Stephen
1/12/2005 7:37:10 AM
Stephen J. Turnbull <stephen@xemacs.org> wrote on Wed, 12 Jan 2005
16:37:10 +0900:
>>>>>> "Aidan" == Aidan Kehoe <kehoea@parhasard.net> writes:

>     Aidan> If you$B!G(Bre considering following up on this with the
>     Aidan> XFree86 people, here$B!G(Bs some sample xev(1) output, from
>     Aidan> pressing Super_L and F6 at once.

Hey, come on you guys - "^[$B!G^[(B" is surely not, in truth, a good
way to write an apostrophe.

-- 
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").

0
Alan
1/15/2005 9:05:19 AM
 Ar an cúigiú lá déag de mí Eanair, scríobh Alan Mackenzie: 

 > Hey, come on you guys - "^[$B!G^[(B" is surely not, in truth, a good
 > way to write an apostrophe.

Doch. http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html

(No, I’m not saying that Markus suggests using it for Usenet, just that it’s
a better way to write an apostrophe. Using it for Usenet seems to be my
particular perversion. But, it’s 2005, your client should be able to handle
it, if it doesn’t, fix it.)

-- 
“Ah come on now Ted, a Volkswagen with a mind of its own, driving all over
the place and going mad, if that’s not scary I don’t know what is.”
0
Aidan
1/15/2005 1:37:14 PM
Aidan Kehoe <kehoea@parhasard.net> writes:

>  Ar an c=C3=BAigi=C3=BA l=C3=A1 d=C3=A9ag de m=C3=AD Eanair, scr=C3=ADobh Alan Mackenzie:=20
>
>  > Hey, come on you guys - "^[$B!G^[(B" is surely not, in truth, a good
>  > way to write an apostrophe.
>
> Doch. http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
>
> (No, I=E2=80=99m not saying that Markus suggests using it for Usenet, just that it=E2=80=99s
> a better way to write an apostrophe. Using it for Usenet seems to be my
> particular perversion. But, it=E2=80=99s 2005, your client should be able to handle
> it, if it doesn=E2=80=99t, fix it.)

Actually, from your last post, it looks like "fixing it"
would break it.

No way I'm slowing down xemacs anymore than I have to.
0
Dan
1/15/2005 2:47:12 PM
 Ar an cúigiú lá déag de mí Eanair, scríobh Dan Espen: 

 > Actually, from your last post, it looks like "fixing it"
 > would break it.

I’m not sure what I can say to that--I imagine you don’t mean that my
suggestion to Renu Bostwick that passing .doc files to Netscape is worth
trying, either breaks XEmacs or has anything to do with MIME charsets. :-)

 > No way I'm slowing down xemacs anymore than I have to.

That’s your call, that’s why we have ./configure. And you’re using google
groups, you can see my directed quotation marks anyway. :-) .  

-- 
“Ah come on now Ted, a Volkswagen with a mind of its own, driving all over
the place and going mad, if that’s not scary I don’t know what is.”
0
Aidan
1/15/2005 4:05:58 PM
Aidan Kehoe <kehoea@parhasard.net> wrote on Sat, 15 Jan 2005 13:37:14 +0000:

>  Ar an cúigiú lá déag de mí Eanair, scríobh Alan Mackenzie: 

>  > Hey, come on you guys - "^[$B!G^[(B" is surely not, in truth, a good
>  > way to write an apostrophe.

> Doch. http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html

An interesting article.  It's just that, IMAO, an apostrophe looks best
if it is displayed on the screen in a single glyph.  I think there are
quite a lot of people around who find that it's easier to read "it's"
than "it^[$B!G^[(Bs".  The latter might also cause articles to exceed the
preferred 80-n maximum width.

To be able to display things like "^[$B!G^[(B" on my ISO-8859-1 screen,
I've first got to feed them through some sort of filter program to
restore them to what they are.  On Usenet, is it really such a grave or
acute matter, whether one's apostrophes appear upright and honest, or
bend over backwards?

> (No, I’m not saying that Markus suggests using it for Usenet, just
> that it’s a better way to write an apostrophe. Using it for Usenet
> seems to be my particular perversion. But, it’s 2005, your client
> should be able to handle it, if it doesn’t, fix it.)

<sigh ;->  Almost anything in English can be written in ASCII.  Anything
in any language I can understand can be written in ISO-8859-1.  That
standard was designed for writing W.European languages, and it works
well.  Now there's this upstart thing utf-8.  Ah well, that's the great
thing about standards - there's always so many to choose from.

-- 
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").

0
Alan
1/15/2005 4:55:04 PM
Aidan Kehoe <kehoea@parhasard.net> writes:

>  Ar an c=C3=BAigi=C3=BA l=C3=A1 d=C3=A9ag de m=C3=AD Eanair, scr=C3=ADobh Dan Espen:=20
>
>  > Actually, from your last post, it looks like "fixing it"
>  > would break it.
>
> I=E2=80=99m not sure what I can say to that--I imagine you don=E2=80=99t mean that my
> suggestion to Renu Bostwick that passing .doc files to Netscape is worth
> trying, either breaks XEmacs or has anything to do with MIME charsets. :-)

No, I think you recommended using a Mule enabled XEmacs.

I just don't have the cycles to burn to read the extra characters,
most of which I find unnecessary.  (Except for your posts.)

>  > No way I'm slowing down xemacs anymore than I have to.
>
> That=E2=80=99s your  call, that=E2=80=99s why  we have ./configure. And you=E2=80=99re
> using   google  groups, you  can  see  my  directed quotation  marks
> anyway. :-) .

If I'm using Google Groups.  But I'm using GNUS.

Don't get me wrong, post the way you like.
If I get tired of it I have a score file,
its my problem.
0
Dan
1/15/2005 5:32:56 PM
>>>>> "Dan" == Dan Espen <daneNO@SPAM.mk.telcordia.com> writes:

    Dan> No, I think you recommended using a Mule enabled XEmacs.

    Dan> I just don't have the cycles to burn to read the extra
    Dan> characters, most of which I find unnecessary.  (Except for
    Dan> your posts.)

Can you be more specific about the contexts in which you find Mule to
be slow?  In particular, the current variable-width format should
_not_ be slower at all for ASCII, and shouldn't be much slower for
Latin charsets unless your application requires random access.  But
there might be a teensy weensy bug here or there....  We'd like to fix
those.

Longer range, can you afford somewhat more memory for UTF-16, ie, a
true array for all current Mule character sets?  If the answer is
"yes", you'd make Aidan very happy ("UTF Inside" is his pet project,
and he'll take all the excuses he can get to put it in :).

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.
0
Stephen
1/15/2005 7:23:16 PM
"Stephen J. Turnbull" <stephen@xemacs.org> writes:

>>>>>> "Dan" == Dan Espen <daneNO@SPAM.mk.telcordia.com> writes:
>
>     Dan> No, I think you recommended using a Mule enabled XEmacs.
>
>     Dan> I just don't have the cycles to burn to read the extra
>     Dan> characters, most of which I find unnecessary.  (Except for
>     Dan> your posts.)
>
> Can you be more specific about the contexts in which you find Mule to
> be slow?  In particular, the current variable-width format should
> _not_ be slower at all for ASCII, and shouldn't be much slower for
> Latin charsets unless your application requires random access.  But
> there might be a teensy weensy bug here or there....  We'd like to fix
> those.
>
> Longer range, can you afford somewhat more memory for UTF-16, ie, a
> true array for all current Mule character sets?  If the answer is
> "yes", you'd make Aidan very happy ("UTF Inside" is his pet project,
> and he'll take all the excuses he can get to put it in :).

Sorry if I implied I had experience with Mule.

I've only read here that it uses more memory and is slower.
That may have been some time ago.

It does take more memory and slow down everything doesn't it?
0
Dan
1/15/2005 10:03:21 PM
Stephen J. Turnbull wrote:
> 
> Longer range, can you afford somewhat more memory for UTF-16, ie, a
> true array for all current Mule character sets?  If the answer is
> "yes", you'd make Aidan very happy ("UTF Inside" is his pet project,
> and he'll take all the excuses he can get to put it in :).

For the record: If that means that the Unicode-support gets better than in 
21.4.15 -- yes! yes! yes! Until Aidan is finished with his work and 21.5 gets 
promoted to stable, we can all afford it, due to falling memory prices... :-)

	Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod				Email: jschrod@acm.org
Roedermark, Germany
0
Joachim
1/16/2005 4:02:27 PM
>>>>> "Dan" == Dan Espen <daneNO@SPAM.mk.telcordia.com> writes:

    Dan> [Mule] does take more memory and slow down everything doesn't it?

About an extra .5 MB of code (including preloaded Lisp), and extra
buffer/string space from 0%--99% of no-Mule XEmacs (0% if you never
use anything but ASCII, 99% if you use a one-byte charset like
Cyrillic, and everything but the newlines are pure Cyrillic.  For a
typical Western European language, maybe an additional 5-10% of
overhead in plain text, much less in C code, Lisp, or a TeX document.
I would guess typical people would see 1-2 MB of RAM inflation, as
most large buffers (ie, things that you'd measure in MB) tend to be
log files which are often pure ASCII.  The main exception would be
folder-is-file MUAs like VM, RMail, and Gnus nnfolder.

Slowing down depends on usage and bugs.  But even at its slowest Mule
is much faster than a human being for ordinary editing.
Theoretically, it should only be noticable if you are doing random
access in a large buffer.  However, people have complained about the
speed, so I suspect that in practice there are bugs.  :-(  I would
like to know more about them so they can be diagnosed.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.
0
Stephen
1/17/2005 5:36:24 AM
"Stephen J. Turnbull" <stephen@xemacs.org> writes:

>>>>>> "Dan" == Dan Espen <daneNO@SPAM.mk.telcordia.com> writes:
>
>     Dan> [Mule] does take more memory and slow down everything doesn't it?
>
> About an extra .5 MB of code (including preloaded Lisp), and extra
> buffer/string space from 0%--99% of no-Mule XEmacs (0% if you never
> use anything but ASCII, 99% if you use a one-byte charset like
> Cyrillic, and everything but the newlines are pure Cyrillic.  For a
> typical Western European language, maybe an additional 5-10% of
> overhead in plain text, much less in C code, Lisp, or a TeX document.

That's odd, you mean I'd see a 5-10% slowdown in fundamental mode
but nothing in the other modes?

> I would guess typical people would see 1-2 MB of RAM inflation, as
> most large buffers (ie, things that you'd measure in MB) tend to be
> log files which are often pure ASCII.  The main exception would be
> folder-is-file MUAs like VM, RMail, and Gnus nnfolder.
>
> Slowing down depends on usage and bugs.  But even at its slowest Mule
> is much faster than a human being for ordinary editing.

That has to depend on the machine being used.  If you're already
near that magic point where typing turns from instantaneous to
lagging, that 5-10% could matter.

> Theoretically, it should only be noticable if you are doing random
> access in a large buffer.  However, people have complained about the
> speed, so I suspect that in practice there are bugs.  :-(  I would
> like to know more about them so they can be diagnosed.

On occasion I have to deal with large buffers.

I don't think I'm convinced.

I can't see how any of these multibyte schemes will ever match
the speed of ascii.
0
Dan
1/17/2005 12:35:08 PM
 Ar an seachtú lá déag de mí Eanair, scríobh Dan Espen: 

 > > About an extra .5 MB of code (including preloaded Lisp), and extra
 > > buffer/string space from 0%--99% of no-Mule XEmacs (0% if you never
 > > use anything but ASCII, 99% if you use a one-byte charset like
 > > Cyrillic, and everything but the newlines are pure Cyrillic.  For a
 > > typical Western European language, maybe an additional 5-10% of
 > > overhead in plain text, much less in C code, Lisp, or a TeX document.
 > 
 > That's odd, you mean I'd see a 5-10% slowdown in fundamental mode
 > but nothing in the other modes?

It's not a function of the mode, it's a function of the buffer contents.
Under Mule, non-ASCII characters take up more memory than do ASCII
characters; just one byte more per character for alphabetic scripts,
normally two more for Han characters.

So on Mule, the string "résumé" uses ten octets, including those necessarily
for the quotation marks. Each "é" uses two octets, all the other characters
use once octet each. Among Roman-alphabet languages, accented (-> non-ASCII)
characters don't normally make up the bulk of the text, so they need 5-10%
extra space; among Cyrillic-alphabet languages, Cyrillic (-> non-ASCII)
characters tend to make up the bulk of the text, and as such, text in those
languages uses much more extra space than does text in, say, Swahili, or
some other language that's happy to fit in ASCII.

And Stephen’s paragraph above is purely about space, not speed.

 > > I would guess typical people would see 1-2 MB of RAM inflation, as
 > > most large buffers (ie, things that you'd measure in MB) tend to be
 > > log files which are often pure ASCII.  The main exception would be
 > > folder-is-file MUAs like VM, RMail, and Gnus nnfolder.
 > >
 > > Slowing down depends on usage and bugs.  But even at its slowest Mule
 > > is much faster than a human being for ordinary editing.
 > 
 > That has to depend on the machine being used.  If you're already near
 > that magic point where typing turns from instantaneous to lagging, that
 > 5-10% could matter.

Could you give us some details of that environment? 

I have lag on a remote 21.5 with Mule on a TTY and a terminal-coding-system
of UTF-8; I don't notice any typing lag locally with the same version, nor
do I _ever_ notice typing lag with 21.4, even on a Pentium II we have in the
office as a local file server, or any of the old hardware I’ve used in the
last three years.

 > > Theoretically, it should only be noticable if you are doing random
 > > access in a large buffer.  However, people have complained about the
 > > speed, so I suspect that in practice there are bugs.  :-(  I would
 > > like to know more about them so they can be diagnosed.
 > 
 > On occasion I have to deal with large buffers.

How many of them are non-ASCII?

 > I don't think I'm convinced.
 > 
 > I can't see how any of these multibyte schemes will ever match the speed
 > of ascii.

As you say yourself, that judgement is based on minimal exposure to
Mule. Mule is fast enough. 

And shipping a non-Mule XEmacs has meant that people developed code to get
redisplay running with Xft, made it Working For Them, and then we had to
wait a couple of years for someone else's workload to ease off enough to get
the Mule support necessary for it to make it into the trunk. 

-- 
"Ah come on now Ted, a Volkswagen with a mind of its own, driving all over
the place and going mad, if that’s not scary I don’t know what is."
0
Aidan
1/17/2005 2:54:02 PM
Aidan Kehoe <kehoea@parhasard.net> writes:

>  Ar an seacht=C3=BA l=C3=A1 d=C3=A9ag de m=C3=AD Eanair, scr=C3=ADobh Dan Espen:=20
>
>  > > About an extra .5 MB of code (including preloaded Lisp), and extra
>  > > buffer/string space from 0%--99% of no-Mule XEmacs (0% if you never
>  > > use anything but ASCII, 99% if you use a one-byte charset like
>  > > Cyrillic, and everything but the newlines are pure Cyrillic.  For a
>  > > typical Western European language, maybe an additional 5-10% of
>  > > overhead in plain text, much less in C code, Lisp, or a TeX document.
>  >=20
>  > That's odd, you mean I'd see a 5-10% slowdown in fundamental mode
>  > but nothing in the other modes?
>
> It's not a function of the mode, it's a function of the buffer contents.
> Under Mule, non-ASCII characters take up more memory than do ASCII
> characters; just one byte more per character for alphabetic scripts,
> normally two more for Han characters.
>
> So on Mule, the string "r=C3=A9sum=C3=A9" uses ten octets, including those necessarily
> for the quotation marks. Each "=C3=A9" uses two octets, all the other characters
> use once octet each. Among Roman-alphabet languages, accented (-> non-ASCII)
> characters don't normally make up the bulk of the text, so they need 5-10%
> extra space; among Cyrillic-alphabet languages, Cyrillic (-> non-ASCII)
> characters tend to make up the bulk of the text, and as such, text in those
> languages uses much more extra space than does text in, say, Swahili, or
> some other language that's happy to fit in ASCII.
>
> And Stephen=E2=80=99s paragraph above is purely about space, not speed.

Yes, re-reading what he said, I guess he was talking about space.
So, I'm still uncertain, I guess you guys are saying that without actually
using multi-byte characters, there is zero cpu overhead?

>  > > I would guess typical people would see 1-2 MB of RAM inflation, as
>  > > most large buffers (ie, things that you'd measure in MB) tend to be
>  > > log files which are often pure ASCII.  The main exception would be
>  > > folder-is-file MUAs like VM, RMail, and Gnus nnfolder.
>  > >
>  > > Slowing down depends on usage and bugs.  But even at its slowest Mule
>  > > is much faster than a human being for ordinary editing.
>  >=20
>  > That has to depend on the machine being used.  If you're already near
>  > that magic point where typing turns from instantaneous to lagging, that
>  > 5-10% could matter.
>
> Could you give us some details of that environment?=20

My home machine is a Pentium 400 w. 256Meg.
XEmacs only slows down when I've got
a lot of other things going on.  I believe the slowdowns I see are
memory related.  Usually restarting Mozilla helps.

At work I've got XEmacs installed for a bunch of 270MHz Ultra 5s.
XEmacs is right on the borderline of usable on those machines.
A fast typist can definitely outpace XEmacs.

> I have lag on a remote 21.5 with Mule on a TTY and a terminal-coding-system
> of UTF-8; I don't notice any typing lag locally with the same version, nor
> do I _ever_ notice typing lag with 21.4, even on a Pentium II we have in the
> office as a local file server, or any of the old hardware I=E2=80=99ve used in the
> last three years.
>
>  > > Theoretically, it should only be noticable if you are doing random
>  > > access in a large buffer.  However, people have complained about the
>  > > speed, so I suspect that in practice there are bugs.  :-(  I would
>  > > like to know more about them so they can be diagnosed.
>  >=20
>  > On occasion I have to deal with large buffers.
>
> How many of them are non-ASCII?

None, except the occasional binary file.

>  > I don't think I'm convinced.
>  >=20
>  > I can't see how any of these multibyte schemes will ever match the speed
>  > of ascii.
>
> As you say yourself, that judgement is based on minimal exposure to
> Mule. Mule is fast enough.=20
>
> And shipping a non-Mule XEmacs has meant that people developed code to get
> redisplay running with Xft, made it Working For Them, and then we had to
> wait a couple of years for someone else's workload to ease off enough to get
> the Mule support necessary for it to make it into the trunk.=20

It's been a while since I've updated XEmacs.
Back later.
0
Dan
1/17/2005 3:40:40 PM
 Ar an seachtú lá déag de mí Eanair, scríobh Dan Espen: 

 > Yes, re-reading what he said, I guess he was talking about space.
 > So, I'm still uncertain, I guess you guys are saying that without actually
 > using multi-byte characters, there is zero cpu overhead?

Exactly, though zero is an absolute figure, and there is a tiny amount of
overhead on saving files and reading them in, but that’ll be dwarfed by any
lisp hooks on those functions, for example. 

 > > Could you give us some details of that environment? 
 > 
 > My home machine is a Pentium 400 w. 256Meg.  XEmacs only slows down when
 > I've got a lot of other things going on.  I believe the slowdowns I see
 > are memory related.  Usually restarting Mozilla helps.

I would be surprised if that configuration had a noticeable hit for ASCII
buffers under Mule. 

 > At work I've got XEmacs installed for a bunch of 270MHz Ultra 5s.  XEmacs
 > is right on the borderline of usable on those machines.  A fast typist
 > can definitely outpace XEmacs.

I seem to remember using 300 MHz Sparcs with 21.4/Mule and not noticing any
speed issues; but it’s a while since I’ve had access to those machines. 

 > > How many of them are non-ASCII?
 > 
 > None, except the occasional binary file.

Then you shouldn’t have a problem. 

-- 
“Ah come on now Ted, a Volkswagen with a mind of its own, driving all over
the place and going mad, if that’s not scary I don’t know what is.”
0
Aidan
1/17/2005 4:17:52 PM
Aidan Kehoe <kehoea@parhasard.net> writes:

>  Ar an seachtú lá déag de mí Eanair, scríobh Dan Espen: 
>
>  > Yes, re-reading what he said, I guess he was talking about space.
>  > So, I'm still uncertain, I guess you guys are saying that without actually
>  > using multi-byte characters, there is zero cpu overhead?
>
> Exactly, though zero is an absolute figure, and there is a tiny amount of
> overhead on saving files and reading them in, but that’ll be dwarfed by any
> lisp hooks on those functions, for example. 

Ok, back using 2.4.16 with the sumo-mule package.
How come I still see unreadable quotes?

I do see the word ISO8 on the mode-bar.

And when I try to post, it wants to remove unreadable text.
0
Dan
1/17/2005 4:33:01 PM
 Ar an seachtú lá déag de mí Eanair, scríobh Dan Espen: 

 > Ok, back using 2.4.16 with the sumo-mule package.
 >
 > How come I still see unreadable quotes?

You’ll need to load the Mule-UCS package. Put 

(require 'un-define)

in your ~/.xemacs/init.el, or evaluate to make the functionality available
in this session. 

-- 
“Ah come on now Ted, a Volkswagen with a mind of its own, driving all over
the place and going mad, if that’s not scary I don’t know what is.”
0
Aidan
1/17/2005 4:53:52 PM
>>>>> "Dan" == Dan Espen <daneNO@SPAM.mk.telcordia.com> writes:

    Dan> I can't see how any of these multibyte schemes will ever
    Dan> match the speed of ascii.

Simple.  In Mule and UTF-8, if it only uses ASCII characters, it is
exactly ASCII in the buffer.  Special-case ASCII-only buffers, and
you're there.

Overhead due to the special-casing is non-zero, but you'll never
notice it in an interpreted language like Emacs Lisp, even in a
"decrepit" machine running at "only" 270 MHz.

We can't achieve that for buffers that aren't 100% ASCII, but for most
human-directed editing purposes buffer motion overhead is swamped by
keeping track of locale-specific behavior.  And Mule performance does
degrade rather gracefully for other usages.  YMMV of course.  That's
why we're aiming at widechar support, for people who can afford to
accept more space if they get more speed.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.
0
Stephen
1/17/2005 5:45:08 PM
Dan Espen <daneNO@SPAM.mk.telcordia.com> writes:

> Aidan Kehoe <kehoea@parhasard.net> writes:
>
>>  Ar an seachtú lá déag de mí Eanair, scríobh Dan Espen: 
>>
>>  > Yes, re-reading what he said, I guess he was talking about space.
>>  > So, I'm still uncertain, I guess you guys are saying that without actually
>>  > using multi-byte characters, there is zero cpu overhead?
>>
>> Exactly, though zero is an absolute figure, and there is a tiny amount of
>> overhead on saving files and reading them in, but that’ll be dwarfed by any
>> lisp hooks on those functions, for example. 
>
> Ok, back using 2.4.16 with the sumo-mule package.
> How come I still see unreadable quotes?
>
> I do see the word ISO8 on the mode-bar.
>
> And when I try to post, it wants to remove unreadable text.

Ok, I added:

(require 'un-define)

Still no good.

Then I checked the info for Mule, it said to do this:

(set-coding-priority-list '(utf-8))
(set-coding-category-system 'utf-8 utf-8)

the second statement says the variable utf-8 is void,
so I changed it to:

(set-coding-category-system 'utf-8 'utf-8)

But the quotes still display as junk.
Do I have to do something to the fonts I use?
0
Dan
1/17/2005 6:22:27 PM
> For the record: If that means that the Unicode-support gets better than in
> 21.4.15 -- yes! yes! yes!

There are many ways to make it better.  Depending on which ones you care
about, using a UTF-16 internal representation won't make any
difference whatsoever.

In 99% of the cases, the internal representation is just that: internal.
It only minimal impact on the functionality and the impact on resource usage
is generally dwarfed by the rest of Emacs.


        Stefan
0
Stefan
1/17/2005 8:29:24 PM
> <sigh ;->  Almost anything in English can be written in ASCII.  Anything
> in any language I can understand can be written in ISO-8859-1.  That
> standard was designed for writing W.European languages, and it works
> well.  Now there's this upstart thing utf-8.  Ah well, that's the great
> thing about standards - there's always so many to choose from.

All my language skills are covered by latin-1 as well, but I still find it
constraining when I want to write things like:

                  Γ,x:τ₁ ⊢ e : τ₂
            —————————————————————————
             Γ ⊢ λx:τ₁.e : τ₁ → τ₂

;-)

-– Stefan
0
Stefan
1/17/2005 8:34:53 PM
 Ar an seachtú lá déag de mí Eanair, scríobh Stefan Monnier: 

 > > For the record: If that means that the Unicode-support gets better than
 > > in 21.4.15 -- yes! yes! yes!
 > 
 > There are many ways to make it better.  Depending on which ones you care
 > about, using a UTF-16 internal representation won't make any
 > difference whatsoever.

Not for XEmacs. We trash data if we don’t have a map to an internal
character set for a given Unicode code point, and that code point is
represented in some file we encounter and treat as Unicode. GNU Emacs does
this too, but has some crazy hackery such that UTF-8 sequences are at least
preserved.  UTF-anything-else still trashes data for them.

(I’m of the school of thought that says trashing data is bad, and important,
by the way. Just so we’re clear on that.)

 > In 99% of the cases, the internal representation is just that: internal.
 > It only minimal impact on the functionality and the impact on resource
 > usage is generally dwarfed by the rest of Emacs.

Well, having a good internal representation is a big part of the way to
having a good API, which is one more thing to sell to new developers, which
may lead to a better XEmacs. 

-- 
“Ah come on now Ted, a Volkswagen with a mind of its own, driving all over
the place and going mad, if that’s not scary I don’t know what is.”
0
Aidan
1/17/2005 11:43:12 PM
 Ar an seachtú lá déag de mí Eanair, scríobh Stefan Monnier: 

 > All my language skills are covered by latin-1 as well

Ah, voilà quelqu’un qui ne doit pas avoir un cœur très sensible quant à la
typographie ;-)

Of course, if caring about typography were ever a priority in these things,
ASCII would have both directed quotation marks and a c-cedilla with which
one could write façade and not worry about your recipients’ language
support. Ah well. :-)

-- 
“Ah come on now Ted, a Volkswagen with a mind of its own, driving all over
the place and going mad, if that’s not scary I don’t know what is.”
0
Aidan
1/17/2005 11:54:36 PM
>> > For the record: If that means that the Unicode-support gets better than
>> > in 21.4.15 -- yes! yes! yes!
>> 
>> There are many ways to make it better.  Depending on which ones you care
>> about, using a UTF-16 internal representation won't make any
>> difference whatsoever.

> Not for XEmacs. We trash data if we don’t have a map to an internal
> character set for a given Unicode code point, and that code point is
> represented in some file we encounter and treat as Unicode.  GNU Emacs
> does this too, but has some crazy hackery such that UTF-8 sequences are at
> least preserved.  UTF-anything-else still trashes data for them.

In what way does an internal UTF-16 representation make it easier to
properly decode+reencode bad utf-8 (i.e. to preserve the binary
representation of the bad parts)?
How does it make it easier to properly decode+reencode text in some
mixed japanese+chinese using some iso-2022 variant?

It doesn't.  At best it moves the tradeoffs around, such that the hard
problems appear at places about which users care less.

> (I’m of the school of thought that says trashing data is bad, and important,
> by the way. Just so we’re clear on that).

Aren't we all?

>> In 99% of the cases, the internal representation is just that: internal.
>> It only minimal impact on the functionality and the impact on resource
>> usage is generally dwarfed by the rest of Emacs.

> Well, having a good internal representation is a big part of the way to
> having a good API,

I thought a good API is one that doesn't assume too much about the
internal representation.

I have nothing about an internal representation based on Unicode, but don't
expect it to solve all the problems of Mule.


        Stefan
0
Stefan
1/18/2005 12:19:15 AM
 Ar an t-ochtú lá déag de mí Eanair, scríobh Stefan Monnier: 

 > In what way does an internal UTF-16 representation make it easier to
 > properly decode+reencode bad utf-8 (i.e. to preserve the binary
 > representation of the bad parts)?

If you know that your UTF-8 is bad, you should either load it in hex-edit
form or in a no-conversion coding system, and fix it from there. (Note that
this includes the case where you load a file, see the corrupt UTF-8, and
immediately kill the buffer, not preserving any changes.) If you don’t know
that your UTF-8 is bad, you’ve already lost your data--and more data to
come, from whatever trashed the UTF-8--and XEmacs can’t help you. It should
warn you when it reads bad UTF-8, though, and writing a lisp library that
reads in a file with no conversion, decodes as much UTF-8 as valid, and
highlights the rest, to offer as a suggestion with this warning, wouldn’t be
that complex. 

The right thing to do here is well known, just not so much in
Massachusetts. East Asia has been living with variable length encodings for
years, without much magic support for corruptions of EUC-JP or EUC-TW.

 > How does it make it easier to properly decode+reencode text in some
 > mixed japanese+chinese using some iso-2022 variant?

Separate question. We’re planning on passing up language information tags
from the coding systems, either using the Unicode Plane 14 code points or
XEmacs extents. The ISO 2022 coding systems should examine these tags, and
choose which character set to use for decoding and encoding based on them,
and redisplay should examine them and choose the best font for the language
of that region of text.

 > It doesn't.  At best it moves the tradeoffs around, such that the hard
 > problems appear at places about which users care less.

Oh, yeah, of course. And good software has the tradeoffs made in such a way
that the problems appear at places about which the users care least. But
that’s a generalisation :-) . 

 > > (I’m of the school of thought that says trashing data is bad, and
 > > important, by the way. Just so we’re clear on that).
 > 
 > Aren't we all?

Some less than others, judging by the extant UTF-8 support in XEmacs :-( . 

 > I thought a good API is one that doesn't assume too much about the
 > internal representation.

I respectfully disagree, but I have no intention of arguing the philosophy
of APIs with you :-) . 

-- 
“Ah come on now Ted, a Volkswagen with a mind of its own, driving all over
the place and going mad, if that’s not scary I don’t know what is.”
0
Aidan
1/18/2005 12:41:24 AM
 Ar an seachtú lá déag de mí Eanair, scríobh Dan Espen: 

 > (require 'un-define)

What does 

  (coding-system-p (find-coding-system 'utf-8))

give you? And 

  (mm-charset-to-coding-system "utf-8")

?

 > [...] Do I have to do something to the fonts I use?

You may need to have a Japanese font available, because that’s the Mule
character set that Mule-UCS remaps the UCS directed quotation marks to,
under X11. But if you’re using a moderately standard OS install, these
should be available anyhow. 

-- 
“Ah come on now Ted, a Volkswagen with a mind of its own, driving all over
the place and going mad, if that’s not scary I don’t know what is.”
0
Aidan
1/18/2005 2:39:45 AM
>>>>> "Aidan" == Aidan Kehoe <kehoea@parhasard.net> writes:

    >>> (I�m of the school of thought that says trashing data is bad,
    >>> and important, by the way. Just so we�re clear on that).

    >> Aren't we all?

    Aidan> Some less than others, judging by the extant UTF-8 support
    Aidan> in XEmacs :-( .

Trashing data is a historical property of Mule.  I would imagine that
Richard and a couple other hackers insisted on dramatic improvements
for integration into Emacs; Sun was more interested in supporting
Japanese (and the basic Mule APIs and the Unicode implementation in
21.4 were all written by Japanese).

    >> I thought a good API is one that doesn't assume too much about
    >> the internal representation.

    Aidan> I respectfully disagree, but I have no intention of arguing
    Aidan> the philosophy of APIs with you :-) .

Not after the arguments you got from me and Ben, I would hope not.  ;-)

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.
0
Stephen
1/18/2005 2:45:12 AM
Aidan Kehoe <kehoea@parhasard.net> writes:

>  Ar an seacht.ANz lNa dNiag de mNm Eanair, scrNmobh Dan Espen: 
>
>  > (require 'un-define)
>
> What does 
>
>   (coding-system-p (find-coding-system 'utf-8))

t

> give you? And 
>
>   (mm-charset-to-coding-system "utf-8")

utf8

> ?
>
>  > [...] Do I have to do something to the fonts I use?
>
> You may need to have a Japanese font available, because that.FN"s the Mule
> character set that Mule-UCS remaps the UCS directed quotation marks to,
> under X11. But if you.FN"re using a moderately standard OS install, these
> should be available anyhow. 

Ok, looked in the Warning buffer and found these:

(1) (font/warning) Unable to instantiate font for face default,
     charset chinese-cns11643-1

(2) (font/warning) Unable to instantiate font for face default,
     charset ipa


I don't know what to check for.  I recently installed
the latest Xorg release from source.
0
Dan
1/18/2005 4:22:48 AM
In article <16876.30449.813853.55808@parhasard.net>,
Aidan Kehoe  <kehoea@parhasard.net> wrote:
>You may need to have a Japanese font available, because that’s the Mule
>character set that Mule-UCS remaps the UCS directed quotation marks to,
>under X11. But if you’re using a moderately standard OS install, these
>should be available anyhow. 

RANT ON!
What insanity! So because you like to use directed quotes in what
should be a plain text medium, adequately usable in ASCII (until
Markus Kuhn single-handedly sabotaged all the free X platforms), we're
all supposed to install Japanese fonts?
Font specification in XEmacs is one of the worst nightmares I ever
have to deal with...and you want me to find Japanese fonts matching
all my preferred Latin-1 fonts, just so you can pretend that a text
window is medium fit for typographic pedantry?
RANT OFF

But seriously, this is absurd.
0
jcb
1/18/2005 10:29:46 AM
 Ar an t-ochtú lá déag de mí Eanair, scríobh Julian Bradfield: 

 > But seriously, this is absurd.

Noted. I disagree. :-) . 

-- 
“Ah come on now Ted, a Volkswagen with a mind of its own, driving all over
the place and going mad, if that’s not scary I don’t know what is.”
0
Aidan
1/18/2005 2:31:29 PM
jcb@inf.ed.ac.uk (Julian Bradfield) writes:

> In article <16876.30449.813853.55808@parhasard.net>,
> Aidan Kehoe  <kehoea@parhasard.net> wrote:
>>You may need to have a Japanese font available, because that’s the Mule
>>character set that Mule-UCS remaps the UCS directed quotation marks to,
>>under X11. But if you’re using a moderately standard OS install, these
>>should be available anyhow. 
>
> RANT ON!
> What insanity! So because you like to use directed quotes in what
> should be a plain text medium, adequately usable in ASCII (until
> Markus Kuhn single-handedly sabotaged all the free X platforms), we're
> all supposed to install Japanese fonts?
> Font specification in XEmacs is one of the worst nightmares I ever
> have to deal with...and you want me to find Japanese fonts matching
> all my preferred Latin-1 fonts, just so you can pretend that a text
> window is medium fit for typographic pedantry?
> RANT OFF
>
> But seriously, this is absurd.

I don't think it's productive to start an argument over the
merits of this.  I'm getting mail from Windows users I work
with full of this stuff.  I have little choice other than adapting
to it.

If it was up to me, computers would only use uppercase only
mono spaced fonts.  Some people think that's ridiculous.
To me, it just seems like the most effective way to use computer
cycles.  Why do we need those tiny little lowercase characters
anyway?

0
Dan
1/18/2005 3:51:39 PM
Aidan Kehoe <kehoea@parhasard.net> wrote on Mon, 17 Jan 2005 23:54:36 +0000:

>  Ar an seachtú lá déag de mí Eanair, scríobh Stefan Monnier: 

>  > All my language skills are covered by latin-1 as well

> Ah, voilà quelqu’un qui ne doit pas avoir un cœur très sensible quant à la
> typographie ;-)

Right - That's 87 columns wide.  Good job my screen goes to 134
characters wide.  Usenet standards (well, ettiquette at least) mandates a
normal maximim width of less than 80.  I can make out most of your
sentence.  But the bit at the end, "<A twiddle><non-break
space><space>la" defeats me.  But why should I have to jump through these
hoops?

> Of course, if caring about typography were ever a priority in these things,
> ASCII would have both directed quotation marks and a c-cedilla with which
> one could write façade and not worry about your recipients’ language
> support. Ah well. :-)

On Usenet, typography is NOT a priority.  Standardisation is.  Surely
"fa?ade" is going to be marginally easier than "fa??ade" to read on a
terminal which is lacking the language support of the writer?  (And if
not, what's wrong with "Fassade"? ;-)

Why must you use utf-8 here?  It's less readable, on average[*], than
8859-x or ASCII.  Your post is in an English language newsgroup.  Why
must you depart from successful standards and ettiquette, recognised for
decades?

You seem to be saying "if you can't read my utf-8 posts, fix your
system!".

There was an irritating fashion several years ago, due largely to
Microsoft's Outlook Express, for posting in HTML on newsgroups.  The
attitude of those posters was something like "for goodness sake, stop
moaning; this is 1999/2000/<whenever>; upgrade your stone-age system to
something modern, and you'll find my posts much nicer looking than most." 

There would seem to be no essential difference between the utf-8 poster's
attitude and the HTML poster's.

[*] this average being taken over computer systems used for reading
Usenet.

-- 
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").

0
Alan
1/19/2005 8:42:18 PM
"Stephen J. Turnbull" <stephen@xemacs.org> writes:

>>>>>> "Dan" == Dan Espen <daneNO@SPAM.mk.telcordia.com> writes:
>
>     Dan> [Mule] does take more memory and slow down everything doesn't it?
>
> [...] Slowing down depends on usage and bugs.  But even at its
> slowest Mule is much faster than a human being for ordinary editing.
> Theoretically, it should only be noticable if you are doing random
> access in a large buffer.

  e.g., using VM to read a large INBOX, it was so much noticeable that
  i quit using a Mulified XEmacs...  but that was november!

  i'm now using again XEmacs+Mule, and the orrrrible slowdown i
  experienced with VM is a thing of the past

 (thank you, you all)

-- 
TORPEDOED BY SPACE-TIME VORTEX. TORPEDOS. SINKING. U-715.
0
giacomo
1/20/2005 8:30:34 AM
 Ar an naoú lá déag de mí Eanair, scríobh Alan Mackenzie: 

 > There was an irritating fashion several years ago, due largely to
 > Microsoft's Outlook Express, for posting in HTML on newsgroups.  The
 > attitude of those posters was something like "for goodness sake, stop
 > moaning; this is 1999/2000/<whenever>; upgrade your stone-age system to
 > something modern, and you'll find my posts much nicer looking than most." 

I’m tempted to say “Welcome to comp.emacs.xemacs. If your newsreader isn’t
at least as capable as Gnus, please upgrade to Gnus.”

I’m not arguing the theory of the thing--if you want to upgrade to a UTF-8
capable newsreader, I’ll do all I can to help you. If you don’t, well, I
look forward to your killfile. 

-- 
“Ah come on now Ted, a Volkswagen with a mind of its own, driving all over
the place and going mad, if that’s not scary I don’t know what is.”
0
Aidan
1/20/2005 2:30:01 PM
Aidan Kehoe <kehoea@parhasard.net> writes:

>  Ar an nao.ANz lNa dNiag de mNm Eanair, scrNmobh Alan Mackenzie: 
>
>  > There was an irritating fashion several years ago, due largely to
>  > Microsoft's Outlook Express, for posting in HTML on newsgroups.  The
>  > attitude of those posters was something like "for goodness sake, stop
>  > moaning; this is 1999/2000/<whenever>; upgrade your stone-age system to
>  > something modern, and you'll find my posts much nicer looking than most." 
>
> I.FN"m tempted to say $B!H(BWelcome to comp.emacs.xemacs. If your newsreader isnN"t
> at least as capable as Gnus, please upgrade to Gnus.$B!I(B

Son of a gun, I don't know when this started working, but I can now
see the funny quotation marks!

Despite my worries, so far Mule doesn't seem to be slowing down
XEmacs.  Maybe because I moved from 21.1.14 to 21.4.16, it
seems a bit faster.

Now all I have to do is figure out what language you are using.
I tried all the likely candidates at Babelfish and still came
up empty with "Ar an nao.ANz lNa dNiag de mNm Eanair, scrNmobh Alan Mackenzie".

The "scr.ANmobh" is probably related to the English word "scribe", which
has a latin origin but French, Spanish, and Portuguese don't seem to work.

Hmm, it works and it doesn't work.  I could see the characters in
GNUS up til the time I hit C-c C-c, then it asked me if the lines
longer than 80 characters were OK, and it stopped displaying
the quotes and instead displayed the junk.
Now it seems to be stuck that way.
(I suppose for this message only.)
0
Dan
1/20/2005 3:44:47 PM
 Ar an fichiú lá de mí Eanair, scríobh Dan Espen: 

 > Hmm, it works and it doesn't work.  I could see the characters in
 > GNUS up til the time I hit C-c C-c, then it asked me if the lines
 > longer than 80 characters were OK, and it stopped displaying
 > the quotes and instead displayed the junk.
 > Now it seems to be stuck that way.

No, that’s fine--it’s doing MIME encoding to a no-conversion (“binary”)
coding system, which in XEmacs’ case happens to be Latin 1. This is a normal
part of sending a non-ASCII message. 

Cf. the output of 

  (encode-coding-string "é" 'utf-8)

--> you get "é", which is the Latin-1 values for the two octets that would
be written to disk if that character was in a file encoded using UTF-8.

-- 
“Ah come on now Ted, a Volkswagen with a mind of its own, driving all over
the place and going mad, if that’s not scary I don’t know what is.”
0
Aidan
1/20/2005 3:53:28 PM
Aidan Kehoe <kehoea@parhasard.net> writes:

>  Ar an fichi.ANz lNa de mNm Eanair, scrNmobh Dan Espen: 
>
>  > Hmm, it works and it doesn't work.  I could see the characters in
>  > GNUS up til the time I hit C-c C-c, then it asked me if the lines
>  > longer than 80 characters were OK, and it stopped displaying
>  > the quotes and instead displayed the junk.
>  > Now it seems to be stuck that way.
>
> No, that.FN"s fine--itN"s doing MIME encoding to a no-conversion ($B!H(Bbinary$B!I(B)
> coding system, which in XEmacs.FN" case happens to be Latin 1. This is a normal
> part of sending a non-ASCII message. 
>
> Cf. the output of 
>
>   (encode-coding-string ".ANi" 'utf-8)
>
> --> you get ".ANCN)", which is the Latin-1 values for the two octets that would
> be written to disk if that character was in a file encoded using UTF-8.

It first asks me:

You have lines longer than 79 characters.  Really post? (y or n) C-g

Then it asks me:

Illegible text found. Continue posting?  (drie?): 

Are you sure that's normal and fine?
0
Dan
1/20/2005 4:46:58 PM
 Ar an fichiú lá de mí Eanair, scríobh Dan Espen: 

 > It first asks me:
 > 
 > You have lines longer than 79 characters.  Really post? (y or n) C-g
 > 
 > Then it asks me:
 > 
 > Illegible text found. Continue posting?  (drie?): 
 > 
 > Are you sure that's normal and fine?

No, that last bit isn’t. I’m not sure what Gnus’ algorithm for detecting
legibility is, but it’s broken there. Hmm. 

Do you get the same thing after having evaluated the following?

(setq mm-coding-system-priorities '(iso-8859-1 utf-8))

-- 
“Ah come on now Ted, a Volkswagen with a mind of its own, driving all over
the place and going mad, if that’s not scary I don’t know what is.”
0
Aidan
1/20/2005 4:55:42 PM
>>>>> "Alan" == Alan Mackenzie <acm@muc.de> writes:

    Alan> On Usenet, typography is NOT a priority.  Standardisation is.

aargh.  Will you please stop feeding my troll?  I had him on coffee
beans and granola tea, and he was well on his way to producing some
nice patches.  But after a week of red meat in c.e.x, he's polluting
his clean changesets with unfinished hacks and making arithmetic
mistakes like 65 = 0x51.

;-)


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.
0
Stephen
1/20/2005 7:14:34 PM
Aidan Kehoe <kehoea@parhasard.net> writes:

>  Ar an fichi.ANz lNa de mNm Eanair, scrNmobh Dan Espen: 
>
>  > It first asks me:
>  > 
>  > You have lines longer than 79 characters.  Really post? (y or n) C-g
>  > 
>  > Then it asks me:
>  > 
>  > Illegible text found. Continue posting?  (drie?): 
>  > 
>  > Are you sure that's normal and fine?
>
> No, that last bit isn.FN"t. IN"m not sure what GnusN" algorithm for detecting
> legibility is, but it.FN"s broken there. Hmm. 
>
> Do you get the same thing after having evaluated the following?

No, I don't.

> (setq mm-coding-system-priorities '(iso-8859-1 utf-8))

Right now I have:

(require 'un-define)
(set-coding-priority-list '(utf-8))
(set-coding-category-system 'utf-8 'utf-8)
(setq mm-coding-system-priorities '(iso-8859-1 utf-8))

I still don't like the long lines warning,
the lines aren't long.

The last setting you gave me is unique to mail,
shouldn't it inherit its setting from the
set-coding-priority-list?

Do I have to make a bug report for the documentation
issue with the 3rd line to get it fixed?  Ie. the
documentation is missing a quote.

0
Dan
1/20/2005 7:56:31 PM
Aidan Kehoe <kehoea@parhasard.net> wrote on Thu, 20 Jan 2005 14:30:01 +0000:

>  Ar an naoA~� lA~� dA~�ag de mA~� Eanair, scrA~�obh Alan Mackenzie: 

>  > There was an irritating fashion several years ago, due largely to
>  > Microsoft's Outlook Express, for posting in HTML on newsgroups.  The
>  > attitude of those posters was something like "for goodness sake,
>  > stop moaning; this is 1999/2000/<whenever>; upgrade your stone-age
>  > system to something modern, and you'll find my posts much nicer
>  > looking than most." 

> I�~@~Ym tempted to say �~@~\Welcome to comp.emacs.xemacs. If your
> newsreader isn�~@~Yt at least as capable as Gnus, please upgrade to
> Gnus.�~@~]

My newsreader, tin, has qualities that Gnus lacks:  Principally, speed
(compiled C is faster than interpreted Emacs Lisp) and simplicity (the
keybindings are fewer, shorter and more intuitive).  I value these
features.

> I�~@~Ym not arguing the theory of the thing--if you want to upgrade to
> a UTF-8 capable newsreader, I�~@~Yll do all I can to help you.

Thanks.  I run my newsreading software on a 166 MHz Linux Machine set up
for ISO-8859-1.  I'm not prepared to compromise the quality of my Usenet
setup or degrade the performance of my machine by using X-Windows.  I
suspect there are many Usenetters in the over-exploited parts of the
world using machines as powerful as mine, who also don't want the
degradation that GUIs impose.  Relevant help files were noticeably absent
from Markus Kuhn's home page, the one you directed me to a few days ago.

Suggestions on how best to field utf-8 encoded postings in west European
languages would be welcome.

> If you don’t, well, I look forward to your killfile. 

No, dammit��!�  I�~@~\m interested in your your posts���for goodness
sake��!� and _want_ to read them.  Why do you have to make it so ���\�ing
difficult����\�  

-- 
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").

0
Alan
1/20/2005 9:19:38 PM
>>>>> "Alan" == Alan Mackenzie <acm@muc.de> writes:

    Alan> My newsreader, tin, has qualities that Gnus lacks:
    Alan> Principally, speed (compiled C is faster than interpreted
    Alan> Emacs Lisp) and simplicity (the keybindings are fewer,
    Alan> shorter and more intuitive).  I value these features.

All valid, except please don't blame Emacs Lisp for Gnus's
misfeatures.  Emacs Lisp is plenty fast to support a newsreader on
your hardware, it's just that Gnus is 90% Lisp torture test and 10%
newsreader; it's a tour-de-force, not a production application.<0.5 wink>

    Alan> Thanks.  I run my newsreading software on a 166 MHz Linux
    Alan> Machine set up for ISO-8859-1.  I'm not prepared to
    Alan> compromise the quality of my Usenet setup or degrade the
    Alan> performance of my machine by using X-Windows.

XEmacs 21.1 + XFree86 3.3 gave quite satisfactory performance on a
125MHz Pentium with 80MB of RAM.  You are undoubtably correct to look
to non-X11 alternatives first, but don't reject X11 solutions out of
hand.  I suspect that even recent versions of X can give satisfactory
performance on your machine.

Please remember that, Aidan's typopedantic trolling notwithstanding,
the real point is that Unicode is THE standard for plain text.  OK, it
shows all the signs of design-by-committee including barnacles like
the PC and DEC line-drawing characters (2-d, and therefore in
principle not allowed in Unicode) and fungal growths like Asian
"full-width" versions of ASCII and Cyrillic.  Not to mention ticks and
termites like those dumbquotes Aidan is so enamored of.  Ignore all
that; it doesn't change the fact that for the first time there is
agreement on a reasonable way to express all (to a reasonable
approximation) of the world's languages in text/plain.

    Alan> Suggestions on how best to field utf-8 encoded postings in
    Alan> west European languages would be welcome.

Any reasonable *nix-oriented MUA will support MIME properly.  It's
been maybe ten years since I used tin, but I'm sure it does, too.
Note that MIME is not really a single standard, it's an extension
framework.  So "proper support" means providing hooks that can be
triggered by MIME headers, and what you need to do is hang a charset
converter on the Content-Type header.  Since you're running Linux, you
have access to Franc,ois Pinard's wonderful recode program.

Recode will strip Aidan's conceits, or replace them with a character
(I believe of your choice) or change them into readable multicharacter
approximations (cf Francois's name, above) where possible---I suspect
it may even be smart enough to turn dumbquotes into realquotes.
Recent versions may even know enough about MIME to handle one of
those Gnus-produced 146-part multicharset messages.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.
0
Stephen
1/21/2005 8:10:14 AM
On Thu, Jan 20 2005, Aidan Kehoe wrote:

> I’m tempted to say “Welcome to comp.emacs.xemacs. If your newsreader isn’t
> at least as capable as Gnus, please upgrade to Gnus.”

If you look at the User-Agent lines, you'll see that mostly people
running Gnus in *XEmacs* have problems with your postings.  XEmacs
users on Windows don't have the possibility to use XEmacs with MULE,
IIRC [1].  But even with MULE and Mule-UCS enabled, XEmacs/Gnus lead
to funny conversion of your quotation marks to Japanese chars [2].

So please don't tell people that using XEmacs+Gnus would solve their
Unicode problems.

Maybe the situation will improve with your recent patches for Gnus
(but Gnus 5.10.7 isn't released yet).

Bye, Reiner.

[1] See my answer to one of your postings in gnu.emacs.gnus:
    <news:v9sm56lklv.fsf@marauder.physik.uni-ulm.de>

[2]
,----
| From: Dan Espen <daneNO@SPAM.mk.telcordia.com>
| Content-Type: text/plain; charset=ISO-2022-JP-2
| Date: Thu, 20 Jan 2005 10:44:47 -0500
| Message-ID: <ic651snlzk.fsf@home-1.localdomain>
| User-Agent: Gnus/5.090015 (Oort Gnus v0.15) XEmacs/21.4 (Corporate Culture,
|  i686-pc-linux)
`----
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/
0
Reiner
1/21/2005 10:16:05 AM
On Fri, Jan 21 2005, Stephen J. Turnbull wrote:

> Recent versions may even know enough about MIME to handle one of
> those Gnus-produced 146-part multicharset messages.

Starting from Gnus 5.9 or 5.10, "146-part multicharset messages" are
an XEmacs-only feature.  Not reproducible with Emacs 21.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/
0
Reiner
1/21/2005 10:19:45 AM
>>>>> "Reiner" == Reiner Steib <reinersteib+from-uce@imap.cc> writes:

> On Thu, Jan 20 2005, Aidan Kehoe wrote:

> So please don't tell people that using XEmacs+Gnus would solve their
> Unicode problems.

It sure does for me. Maybe those people's problems are that they're
running Windows?
-- 
		     Calle Dybedahl <calle@cyberpomo.com>
		 http://www.livejournal.com/users/cdybedahl/
      "It's not much of a silver lining, but I'll take what I can get."
			  -- yasminm, on LiveJournal
0
Calle
1/21/2005 11:21:03 AM
On Fri, Jan 21 2005, Calle Dybedahl wrote:

>>>>>> "Reiner" == Reiner Steib <reinersteib+from-uce@imap.cc> writes:
>> So please don't tell people that using XEmacs+Gnus would solve their
>> Unicode problems.
>
> It sure does for me. Maybe those people's problems are that they're
> running Windows?

Well, you may formulate it in that way, but it is more accurate to say
that their problem is that you cannot built XEmacs 21.4 with MULE on
Windows (see my previous message).  Windows itself (to my knowledge)
has quite good Unicode support.  I even know people switching from
XEmacs+Gnus to M$ Outlook Express if they want to answer to Unicode
postings.

BTW, I learned from Stephen J. Turnbull that “XEmacs 21.5 is the first
XEmacs which promises to support Unicode.”[1]

Bye, Reiner.

[1] See <news:87k6vjngnm.fsf@tleepslib.sk.tsukuba.ac.jp> or
    http://thread.gmane.org/87k6vjngnm.fsf@tleepslib.sk.tsukuba.ac.jp
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/
0
Reiner
1/21/2005 1:07:16 PM
Calle Dybedahl <posted@cyberpomo.com> writes:

>>>>>> "Reiner" == Reiner Steib <reinersteib+from-uce@imap.cc> writes:
>
>> On Thu, Jan 20 2005, Aidan Kehoe wrote:
>
>> So please don't tell people that using XEmacs+Gnus would solve their
>> Unicode problems.
>
> It sure does for me. Maybe those people's problems are that they're
> running Windows?

Well, I had problems, most of them now solved.

If I was running Windows, I would have even more problems,
but I'm not.
0
Dan
1/21/2005 1:50:31 PM
>>>>> "Reiner" == Reiner Steib <reinersteib+from-uce@imap.cc> writes:

    Reiner> it is more accurate to say that their problem is that you
    Reiner> cannot built XEmacs 21.4 with MULE on Windows (see my
    Reiner> previous message).

It's most accurate to say that no XEmacs with MULE is provided in
binary form for Windows, and that the Unicode support on Windows in
21.5 is so superior that it's not worth bothering to try to build 21.4
with MULE for Windows anymore.

Unfortunately, neither the XEmacs developer who has been providing
binaries nor the Cygwin XEmacs maintainer seem much interested in
building 21.5 for Windows.  I believe there's an InstallShield binary
distribution out there somewhere, but more volunteers would be very
welcome, targeting either the netinstaller or InstallShield/MSI.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.
0
Stephen
1/21/2005 6:38:59 PM
>>>>> "Reiner" == Reiner Steib <reinersteib+from-uce@imap.cc> writes:

    Reiner> Starting from Gnus 5.9 or 5.10, "146-part multicharset
    Reiner> messages" are an XEmacs-only feature.  Not reproducible
    Reiner> with Emacs 21.

No, it's a Gnus feature.  There never was a need for such messages;
single (MIME) charset messages have been quite feasible as long as the
MIME charset parameter to Content-Type has been available, because RFC
1462 predates it.  Since MULE is based on ISO 2022, there really never
was any excuse for that breakage---a universal coding system has
always been available.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.
0
Stephen
1/21/2005 6:52:34 PM
"Stephen J. Turnbull" <stephen@xemacs.org> writes:

>>>>>> "Reiner" == Reiner Steib <reinersteib+from-uce@imap.cc> writes:
>
>     Reiner> it is more accurate to say that their problem is that you
>     Reiner> cannot built XEmacs 21.4 with MULE on Windows (see my
>     Reiner> previous message).
>
> It's most accurate to say that no XEmacs with MULE is provided in
> binary form for Windows, and that the Unicode support on Windows in
> 21.5 is so superior that it's not worth bothering to try to build 21.4
> with MULE for Windows anymore.
>
> Unfortunately, neither the XEmacs developer who has been providing
> binaries nor the Cygwin XEmacs maintainer seem much interested in
> building 21.5 for Windows.  I believe there's an InstallShield binary
> distribution out there somewhere, but more volunteers would be very

Go no further than to the obvious place to find up-to-date
information:

http://www.xemacs.org/Download/win32/index.html

http://ftp.xemacs.org/pub/xemacs/binaries/win32/installshield/
and mirrors have the latest available build (xemacs-21.5.17.exe)

See
http://ftp.xemacs.org/pub/xemacs/binaries/win32/installshield/README

> welcome, targeting either the netinstaller or InstallShield/MSI.

-- 
Adrian Aichner
 mailto:adrian@xemacs.org
 http://www.xemacs.org/
0
Adrian
1/21/2005 7:38:38 PM
Stephen J. Turnbull <stephen@xemacs.org> wrote on Fri, 21 Jan 2005
17:10:14 +0900:
>>>>>> "Alan" == Alan Mackenzie <acm@muc.de> writes:

>     Alan> My newsreader, tin, has qualities that Gnus lacks:
>     Alan> Principally, speed (compiled C is faster than interpreted
>     Alan> Emacs Lisp) and simplicity (the keybindings are fewer,
>     Alan> shorter and more intuitive).  I value these features.

> All valid, except please don't blame Emacs Lisp for Gnus's
> misfeatures.

Who said anything about Misfeatures?  Not me!  I'm merely saying why I
prefer a different program.

> Emacs Lisp is plenty fast to support a newsreader on your hardware,
> it's just that Gnus is 90% Lisp torture test and 10% newsreader; it's a
> tour-de-force, not a production application.<0.5 wink>

Maybe, maybe not.  But I have groups with several tens of thousands of
articles in a leafnode spool.  Optimised C seems a better bet for these.

>     Alan> Thanks.  I run my newsreading software on a 166 MHz Linux
>     Alan> Machine set up for ISO-8859-1.  I'm not prepared to
>     Alan> compromise the quality of my Usenet setup or degrade the
>     Alan> performance of my machine by using X-Windows.

> XEmacs 21.1 + XFree86 3.3 gave quite satisfactory performance on a
> 125MHz Pentium with 80MB of RAM.  You are undoubtably correct to look
> to non-X11 alternatives first, but don't reject X11 solutions out of
> hand.  I suspect that even recent versions of X can give satisfactory
> performance on your machine.

Maybe they can, maybe they can't.  The video quality is better from
hardware generated characters than bitmapped displays, and vertical
scrolling is instantaneous.  I've got a mere 64Mb of RAM on my PC.  Why
sacrifice a significant portion of that to a window manager, even one
like Ratpoison, when I want to avoid having to manage windows?

> Please remember that, Aidan's typopedantic trolling notwithstanding,
> the real point is that Unicode is THE standard for plain text.  OK, it
> shows all the signs of design-by-committee including barnacles like
> the PC and DEC line-drawing characters (2-d, and therefore in
> principle not allowed in Unicode) and fungal growths like Asian
> "full-width" versions of ASCII and Cyrillic.  Not to mention ticks and
> termites like those dumbquotes Aidan is so enamored of.  Ignore all
> that; it doesn't change the fact that for the first time there is
> agreement on a reasonable way to express all (to a reasonable
> approximation) of the world's languages in text/plain.

<rant-mode> Yeah, fine.  It's a massive multi-purpose kludge, trying to
encompass all languages.  It's like one of these universal mains adapters
you get sold at airports, which wiggles alarmingly no matter what shape
of socket it's pushed into.  It's a kind of Huffmann encoding which
swells rather than compresses.  It's heavily biassed towards the Latin
alphabets, but does a poor job of encoding even them.  Text processing
code which would be simple and clear for ASCII or an ISO-8859 variant now
has to distinguish between bytes and characters, and to keep asking
itself "is this a European character at all?  Hey, it's a Chinese
thingamy-gram, can I print it?  Whoops, I'd better interrogate the
termcap entry first - �sugar!, this seems to be a proprietary OS, wonder
what it has instead of termcap,......", and on and on and on and on.

And please don't tell me everything is all nicely encapsulated in
specially modified libc functions which will do everything transparently
and painlessly.  Decades of suffering induced merely by multibyte line
terminators should disabuse anybody of that fantasy notion.  And it's
going to hit users far harder than programmers.  How many sleepless
nights, how many abused spouses, how many extra cases of alcoholism and
other drug addictions are going to be caused by ordinary computer users
driven to distraction by seeing "���" (or whatever) where their
reasonable expectations demand an apostrophe?

utf-8 is inferior to a character set designed specifically for a single
language, or a small set of languages.  It's inferior to ASCII or
ISO-8995-1 for English or German.  I'd wager it's way inferior to
ISO-8995-2 for writing in Polish.  Maybe utf-8 is a good way of writing
Japanese - I don't know.  You're fluent in Japanese, Stephan - how does
utf-8 stack up against purpose-built character sets for Japanese?

I'm sure utf-8 is great for texts containing wierd language combinations.
Perhaps it's appropriate on groups like sci.lang.translation.  But for
English or German or French or Spanish, which have well established
standards (and only a few of them ;-) it's one big pee in the aye. 

>     Alan> Suggestions on how best to field utf-8 encoded postings in
>     Alan> west European languages would be welcome.

> Any reasonable *nix-oriented MUA will support MIME properly.  It's been
> maybe ten years since I used tin, but I'm sure it does, too.  Note that
> MIME is not really a single standard, it's an extension framework.  So
> "proper support" means providing hooks that can be triggered by MIME
> headers, and what you need to do is hang a charset converter on the
> Content-Type header.  Since you're running Linux, you have access to
> Franc,ois Pinard's wonderful recode program.

Or even Fran�ois Pinard's recode program.  ;-)

> Recode will strip Aidan's conceits, or replace them with a character
> (I believe of your choice) or change them into readable multicharacter
> approximations (cf Francois's name, above) where possible---I suspect
> it may even be smart enough to turn dumbquotes into realquotes.
> Recent versions may even know enough about MIME to handle one of
> those Gnus-produced 146-part multicharset messages.

I'll need to get that program.

Plus all the time and settings to ensure I'm not vulgar enough to dump
anything like HTML, utf-8 or Microsoft Word format on anybody else on
Usenet.

<\rant-mode>

Have a great weekend, Stephen!

-- 
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").

0
Alan
1/21/2005 8:53:52 PM
>>>>> "Alan" == Alan Mackenzie <acm@muc.de> writes:

    Alan> Stephen J. Turnbull <stephen@xemacs.org> wrote on Fri, 21
    Alan> Jan 2005 17:10:14 +0900:

    >> All valid, except please don't blame Emacs Lisp for Gnus's
    >> misfeatures.

    Alan> Who said anything about Misfeatures?  Not me!

*I* did.

    >> Emacs Lisp is plenty fast to support a newsreader on your
    >> hardware,

    Alan> Maybe, maybe not.  But I have groups with several tens of
    Alan> thousands of articles in a leafnode spool.  Optimised C
    Alan> seems a better bet for these.

That's a myth.  The reason tin runs faster than Gnus on those spools
is mostly that it uses better algorithms, and probably hasn't changed
much since I used it ten years ago, so it is surely well-optimized.

I will grant you that there is no efficient newsreader written in Emacs
Lisp, any more than there is an efficient web browser.  But both could
be done, and should be preferred to writing new C programs.  (Or write
it in Python or Ruby, I don't care.  Just don't write it in a language
where every I/O operation is a buffer overrun waiting to rootkit you.)

    >> Please remember that, Aidan's typopedantic trolling
    >> notwithstanding, the real point is that Unicode is THE standard
    >> for plain text.

    Alan> Text processing code which would be simple and clear for
    Alan> ASCII or an ISO-8859 variant now has to distinguish between
    Alan> bytes and characters,

No, it doesn't.  The I/O code does that in a few dozen lines of C,
including bullet-proof error handling.  The rest of the text processing
code can be the same as ever (unless you wish to serve the 5.5 billion
people whose native languages don't fit into the ISO 8859 form
factor).

    Alan> utf-8 is inferior to a character set designed specifically
    Alan> for a single language.

Not if that language is American English (except for the temptation to
include non-ASCII characters).  And Unicode as such is not inferior to
ISO 8859/1 for Western European languages, for precisely the same
reason (there's nothing that says you can't subset Unicode to fit in 1
byte by the obvious cast, which gives ISO 8859/1).  Granted, that
won't work for ISO 8859/15, but ISO 8859/15 caused its own problems.

    Alan> I'm sure utf-8 is great for texts containing wierd language
    Alan> combinations.  Perhaps it's appropriate on groups like
    Alan> sci.lang.translation.  But for English or German or French
    Alan> or Spanish, which have well established standards (and only
    Alan> a few of them ;-) it's one big pee in the aye.

Nonsense.  Your problem is with Aidan the Troll, not UTF-8, which
could be identical to ASCII for the _content_ portions of his posts if
he wanted it to be.  As for German, French, and Spanish, it's a nearly
trivial input filter.  If you want more generality, librecode is
freely available, and not that hard to configure for simple use.

    Alan> , or a small set of languages.  It's inferior to ASCII or
    Alan> ISO-8995-1 for English or German.  I'd wager it's way
    Alan> inferior to ISO-8995-2 for writing in Polish. 

Not if you're a Gastarbeiter in Germany, and you use the same program
to write love letters to your s.o. back home and memos to your boss.

The fact is that (partly for spite) the non-ISO 8859/1-compatible
portion of the world is rapidly converting to Unicode and laughing at
us, now that the shoe is on the other foot.  In fact, so is the
commercial part of the free software world (except in Japan).  Both
SuSE and Red Hat now run in UTF-8 locales by default.

The only reason we all haven't been forced to laugh at ourselves yet
is the sheer dominance of the US + Euro economy in the market for
software.  That is not going to last much longer.

    Alan> Maybe utf-8 is a good way of writing Japanese - I don't
    Alan> know.  You're fluent in Japanese, Stephan - how does utf-8
    Alan> stack up against purpose-built character sets for Japanese?

Against any one of them, it's a tossup.  Against the fact that there
are no less than three common _types_ of idiosyncratic encodings of
Japanese, each of which has several (which can mean "dozens") of
programmatically indistinguishable variants?  I bet you can guess!

    >> Since you're running Linux, you have access to Franc,ois
    >> Pinard's wonderful recode program.

    Alan> Or even Fran�ois Pinard's recode program.  ;-)

That's not how he spells his name in the Info file.<wink back>



-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.
0
Stephen
1/22/2005 7:11:32 AM
>> I�~@~Ym not arguing the theory of the thing--if you want to upgrade to
>> a UTF-8 capable newsreader, I�~@~Yll do all I can to help you.

> Thanks.  I run my newsreading software on a 166 MHz Linux Machine set up
> for ISO-8859-1.  I'm not prepared to compromise the quality of my Usenet
> setup or degrade the performance of my machine by using X-Windows.  I

You don't need X11 to display non-iso-8859-1 text.
You can probably get the Linux console in utf-8, and even if you stick to
iso-8859-1, programs like Emacs and Lynx have ways to display approximations
for the Unicode chars you're missing (try to put (latin1-display) in your
..emacs).


        Stefan
0
Stefan
1/24/2005 1:24:14 PM
 Ar an fichiú lá de mí Eanair, scríobh Dan Espen: 

 > The last setting you gave me is unique to mail, shouldn't it inherit its
 > setting from the set-coding-priority-list?

Yes.

Of course, it’s not a given that the character encoding priority you want to
use for locally saved files is identical to that you want to use for Usenet
and email messages. But an explicit initialisation of
mm-coding-system-priorities is a decent price to pay for differentiating the
two.

(If you get to choose the priority for local files yourself, it’s a good
idea to set it to something identical to that used for email and Usenet, so
when you exchange a local document with someone else there’s one fewer thing
to go wrong.)

Do you want to report the bug, or will I?

 > Do I have to make a bug report for the documentation issue with the 3rd
 > line to get it fixed?  Ie. the documentation is missing a quote.

I don’t honestly know what you mean by “3rd line” there; but, in general,
make a bug report if you’d like something fixed.

-- 
“Ah come on now Ted, a Volkswagen with a mind of its own, driving all over
the place and going mad, if that’s not scary I don’t know what is.”
0
Aidan
1/24/2005 4:21:10 PM
On Fri, Jan 21 2005, Stephen J. Turnbull wrote:

>>>>>> "Reiner" == Reiner Steib <reinersteib+from-uce@imap.cc> writes:
>
>     Reiner> it is more accurate to say that their problem is that you
>     Reiner> cannot built XEmacs 21.4 with MULE on Windows (see my
>     Reiner> previous message).
>
> It's most accurate to say that no XEmacs with MULE is provided in
> binary form for Windows,

Well, we both know that the proportion of Windows users building
programs from source can safely be neglected.  ;-)  Are you saying
that it is possible to build XEmacs 21.4 with MULE for Windows?
(If so, only with cygwin or native?)

> and that the Unicode support on Windows in 21.5 is so superior that
> it's not worth bothering to try to build 21.4 with MULE for Windows
> anymore.

Would you recommend Windows users to use the beta version of XEmacs?

BTW, has the Email truncation issue been fixed?
<URL:http://thread.gmane.org/psekn2jvcg.fsf@diannao.ittc.ku.edu>.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/
0
Reiner
1/24/2005 4:44:09 PM
On Fri, Jan 21 2005, Stephen J. Turnbull wrote:

>>>>>> "Reiner" == Reiner Steib <reinersteib+from-uce@imap.cc> writes:
>
>     Reiner> Starting from Gnus 5.9 or 5.10, "146-part multicharset
>     Reiner> messages" are an XEmacs-only feature.  Not reproducible
>     Reiner> with Emacs 21.
>
> No, it's a Gnus feature.  There never was a need for such messages;
> single (MIME) charset messages have been quite feasible as long as the
> MIME charset parameter to Content-Type has been available, because RFC
> 1462 predates it.  

I don't know the history of Gnus' behavior.  If the solution is such
simple, I wonder why no one ever tried to modify the XEmacs specific
parts of gnus/mm-util.el accordingly.

> Since MULE is based on ISO 2022, there really never was any excuse
> for that breakage---a universal coding system has always been
> available.

Are you suggesting that Gnus should send messages with
charset=ISO-2022-JP-2 (like it happened several times in this thread)
instead?  The multipart/mixed messages are not nice.  But when using
ISO-2022, many recipients won't be able to read the message at all
(missing fonts, client[1] doesn't support ISO-2022, ...).

Bye, Reiner.

[1] E.g. in Mozilla Thunderbird, the non-ascii part of the
    ISO-2022-JP-2 messages are not displayed correctly.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/
0
Reiner
1/24/2005 4:44:12 PM
 Ar an fichiú lá de mí Eanair, scríobh Alan Mackenzie: 

 > > Iâ~@~Ym not arguing the theory of the thing--if you want to upgrade to
 > > a UTF-8 capable newsreader, Iâ~@~Yll do all I can to help you.
 > 
 > Thanks.  I run my newsreading software on a 166 MHz Linux Machine set up
 > for ISO-8859-1.  I'm not prepared to compromise the quality of my Usenet
 > setup or degrade the performance of my machine by using X-Windows.  I
 > suspect there are many Usenetters in the over-exploited parts of the
 > world using machines as powerful as mine, who also don't want the
 > degradation that GUIs impose.  Relevant help files were noticeably absent
 > from Markus Kuhn's home page, the one you directed me to a few days ago.
 > 
 > Suggestions on how best to field utf-8 encoded postings in west European
 > languages would be welcome.

Excuse me not getting to that earlier; I managed, accidentally, to have Gnus
ignore comp.emacs.xemacs for half a week :-( .

Gnus people, when you’ve subscribed to a group, and have read all the
messages in that group, and the line for that group has disappeared from the
*Groups* buffer, what’s the sanctioned way to go back and reread those
messages?  I type “U” in the “*Group*” buffer, subscribe to
comp.emacs.xemacs, read 50 messages, and then I seem to be unsubscribed from
it, which is exactly what I don’t want.

Anyway, Alan, tell us if recode with trn works for you. A few minutes’
googling doesn’t give me anything better as a suggestion, besides using the
UTF-8 branch of Mutt together with a news-mail gateway. 

-- 
“Ah come on now Ted, a Volkswagen with a mind of its own, driving all over
the place and going mad, if that’s not scary I don’t know what is.”
0
Aidan
1/24/2005 4:44:18 PM
 Ar an dara lá is fiche de mí Eanair, scríobh Stephen J. Turnbull: 

 > It's most accurate to say that no XEmacs with MULE is provided in
 > binary form for Windows, and that the Unicode support on Windows in
 > 21.5 is so superior that it's not worth bothering to try to build 21.4
 > with MULE for Windows anymore.

Cygwin have a binary with Mule available; but perhaps you were excluding
Cygwin from your “for Windows” definition there.

http://www.cygwin.com/packages/xemacs/ .

-- 
“Ah come on now Ted, a Volkswagen with a mind of its own, driving all over
the place and going mad, if that’s not scary I don’t know what is.”
0
Aidan
1/24/2005 5:09:46 PM
On Mon, Jan 24 2005, Aidan Kehoe wrote:

> Excuse me not getting to that earlier; I managed, accidentally, to have Gnus
> ignore comp.emacs.xemacs for half a week :-( .
>
> Gnus people, when you’ve subscribed to a group, and have read all the
> messages in that group, and the line for that group has disappeared from the
> *Groups* buffer, what’s the sanctioned way to go back and reread those
> messages?  

Use `j' or `L'...

,----[ (info "(gnus)Group Maneuvering") ]
| `j'
|      Jump to a group (and make it visible if it isn't already)
|      (`gnus-group-jump-to-group').  Killed groups can be jumped to, just
|      like living groups.
`----

,----[ (info "(gnus)Listing Groups") ]
| `L'
| `A u'
|      List all groups, whether they have unread articles or not
|      (`gnus-group-list-all-groups').  If the numeric prefix is used,
|      this command will list only groups of level ARG and lower.  By
|      default, it lists groups of level seven or lower (i.e., just
|      subscribed and unsubscribed groups).
`----

Bye, Reiner.
Followup-To: gnu.emacs.gnus
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/
0
Reiner
1/24/2005 5:52:56 PM
Aidan Kehoe <kehoea@parhasard.net> writes:

>  Ar an fichi.ANz lNa de mNm Eanair, scrNmobh Dan Espen: 
>
>  > The last setting you gave me is unique to mail, shouldn't it inherit its
>  > setting from the set-coding-priority-list?
>
> Yes.
>
> Of course, it.FN"s not a given that the character encoding priority you want to
> use for locally saved files is identical to that you want to use for Usenet
> and email messages. But an explicit initialisation of
> mm-coding-system-priorities is a decent price to pay for differentiating the
> two.
>
> (If you get to choose the priority for local files yourself, it.FN"s a good
> idea to set it to something identical to that used for email and Usenet, so
> when you exchange a local document with someone else there.FN"s one fewer thing
> to go wrong.)
>
> Do you want to report the bug, or will I?

If you are offering, it's yours.

>  > Do I have to make a bug report for the documentation issue with the 3rd
>  > line to get it fixed?  Ie. the documentation is missing a quote.
>
> I don.FN"t honestly know what you mean by $B!H(B3rd line$B!I(B there; but, in general,
> make a bug report if you.FN"d like something fixed.

Well, you cut the line from this mail. :)

I found this line in the MULE documentation under instructions
for enabling mule:

(set-coding-category-system 'utf-8 utf-8)

it should be:

(set-coding-category-system 'utf-8 'utf-8)
                                   ^

(I think.)

The first one won't eval, the second one does.
0
Dan
1/24/2005 11:00:59 PM
>>>>> "Aidan" == Aidan Kehoe <kehoea@parhasard.net> writes:

    Aidan> Cygwin have a binary with Mule available; but perhaps you

Will wonders never cease!  Thank you for the correction.

    Aidan> were excluding Cygwin from your ��for Windows�� definition
    Aidan> there.

No, I just wasn't aware of it, and at one point Volker said he wasn't
interested in building one.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.
0
Stephen
1/25/2005 2:11:14 AM
>>>>> "Reiner" == Reiner Steib <reinersteib+from-uce@imap.cc> writes:

    Reiner> Well, we both know that the proportion of Windows users
    Reiner> building programs from source can safely be neglected.

You're the one who brought it up.

    Reiner> ;-) Are you saying that it is possible to build XEmacs
    Reiner> 21.4 with MULE for Windows?  (If so, only with cygwin or
    Reiner> native?)

Yes, both, and once again, don't bother.

    >> and that the Unicode support on Windows in 21.5 is so superior
    >> that it's not worth bothering to try to build 21.4 with MULE
    >> for Windows anymore.

    Reiner> Would you recommend Windows users to use the beta version
    Reiner> of XEmacs?

Yes, if they need Mule.  With the caveat that they should find out
what the recommended version by asking on xemacs-beta is rather than
simply checking out HEAD.

    Reiner> BTW, has the Email truncation issue been fixed?
    Reiner> <URL:http://thread.gmane.org/psekn2jvcg.fsf@diannao.ittc.ku.edu>.

No.  We think we know what's happening, but so far the patches we've
tried are worse than the bug.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.
0
Stephen
1/25/2005 2:16:05 AM
>>>>> "Reiner" == Reiner Steib <reinersteib+from-uce@imap.cc> writes:

    >> No, it's a Gnus feature.  There never was a need for such
    >> messages; single (MIME) charset messages have been quite
    >> feasible as long as the MIME charset parameter to Content-Type
    >> has been available, because RFC 1462 predates it.

    Reiner> I don't know the history of Gnus' behavior.  If the
    Reiner> solution is such simple, I wonder why no one ever tried to
    Reiner> modify the XEmacs specific parts of gnus/mm-util.el
    Reiner> accordingly.

It is NOT an XEmacs-specific issue.  That's the point; the solution
was available on ALL Mule-enabled emacsen.

    >> Since MULE is based on ISO 2022, there really never was any
    >> excuse for that breakage---a universal coding system has always
    >> been available.

    Reiner> Are you suggesting that Gnus should send messages with
    Reiner> charset=ISO-2022-JP-2 (like it happened several times in
    Reiner> this thread) instead?  The multipart/mixed messages are
    Reiner> not nice.  But when using ISO-2022, many recipients won't
    Reiner> be able to read the message at all (missing fonts,
    Reiner> client[1] doesn't support ISO-2022, ...).

Yes, all that is true, and it is relevant to deciding what to do
TODAY; now that everybody more or less supports UTF-8 it's preferable
to use that.  But when Gnus INTRODUCED the MIME-part-per-character
"feature", what should have been done was to ask the user whether to
use UTF-8, ISO-2022, or multiple MIME parts, rather than "do something
guaranteed to display wrong on many conforming clients or die".

    Reiner> [1] E.g. in Mozilla Thunderbird, the non-ascii part of the
    Reiner> ISO-2022-JP-2 messages are not displayed correctly.

This doesn't surprise me.  http://www.jwz.org/doc/cadt.html strikes
again.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.
0
Stephen
1/25/2005 2:24:03 AM
Aidan Kehoe <kehoea@parhasard.net> writes:

> Gnus people, when you’ve subscribed to a group, and have read all the
> messages in that group, and the line for that group has disappeared from the
> *Groups* buffer, what’s the sanctioned way to go back and reread those
> messages?

FWIW, (as a Gnus non-expert) I have:

(setq gnus-permanently-visible-groups "^.*")

in my init file because I have repeatedly been bitten in the bum by
groups disappearing when all their messages are read.
0
John
1/25/2005 7:17:00 PM
Dan Espen <daneNO@SPAM.mk.telcordia.com> writes:

<32 lines deleted by Adrian Aichner>
> I found this line in the MULE documentation under instructions
> for enabling mule:
>
> (set-coding-category-system 'utf-8 utf-8)

Dan, I had to search all .texi files in the XEmacs source tree to find
what you could be referring to.

I found no match for the incorrect example above.

>
> it should be:
>
> (set-coding-category-system 'utf-8 'utf-8)
>                                    ^

This correction has been in place for a long time in the trunk and 21.4
branches of 
man/xemacs-faq.texi

>
> (I think.)
>
> The first one won't eval, the second one does.

-- 
Adrian Aichner
 mailto:adrian@xemacs.org
 http://www.xemacs.org/
0
Adrian
1/30/2005 10:40:47 AM
>>>>> "APA" == Adrian Aichner <adrian@xemacs.org> writes:

    >> (set-coding-category-system 'utf-8 utf-8)

    APA> Dan, I had to search all .texi files in the XEmacs source
    APA> tree to find what you could be referring to.

    APA> I found no match for the incorrect example above.

It's an ancient typo in the mule-ucs documentation which found its way
into the FAQs, I believe, and AFAIK was corrected long ago.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.
0
Stephen
1/30/2005 2:14:21 PM
Adrian Aichner <adrian@xemacs.org> writes:

> Dan Espen <daneNO@SPAM.mk.telcordia.com> writes:
>
> <32 lines deleted by Adrian Aichner>
>> I found this line in the MULE documentation under instructions
>> for enabling mule:
>>
>> (set-coding-category-system 'utf-8 utf-8)
>
> Dan, I had to search all .texi files in the XEmacs source tree to find
> what you could be referring to.
>
> I found no match for the incorrect example above.
>
>>
>> it should be:
>>
>> (set-coding-category-system 'utf-8 'utf-8)
>>                                    ^
>
> This correction has been in place for a long time in the trunk and 21.4
> branches of 
> man/xemacs-faq.texi

You're right.

Plus the copy I have has the quote too.

BUT, when I look at it in info, there's no quote.

I took the pathname from the info buffer, deleted the info
buffer and looked again using find-file, and the quote
is there.

Are there some quoting rules for texinfo files that are being
violated, or is my info broken?
0
Dan
1/30/2005 4:37:19 PM
Dan Espen <daneNO@SPAM.mk.telcordia.com> writes:

> Adrian Aichner <adrian@xemacs.org> writes:
>
>> Dan Espen <daneNO@SPAM.mk.telcordia.com> writes:
>>
>> <32 lines deleted by Adrian Aichner>
>>> I found this line in the MULE documentation under instructions
>>> for enabling mule:
>>>
>>> (set-coding-category-system 'utf-8 utf-8)
>>
>> Dan, I had to search all .texi files in the XEmacs source tree to find
>> what you could be referring to.
>>
>> I found no match for the incorrect example above.
>>
>>>
>>> it should be:
>>>
>>> (set-coding-category-system 'utf-8 'utf-8)
>>>                                    ^
>>
>> This correction has been in place for a long time in the trunk and 21.4
>> branches of 
>> man/xemacs-faq.texi
>
> You're right.
>
> Plus the copy I have has the quote too.
>
> BUT, when I look at it in info, there's no quote.
>
> I took the pathname from the info buffer, deleted the info
> buffer and looked again using find-file, and the quote
> is there.
>
> Are there some quoting rules for texinfo files that are being
> violated, or is my info broken?

Nope, that's not it.
Those lines occur twice in the info file.
The first set are OK, the second aren't.

This is at the front of the file I have:

   This is version $Revision: 1.4 $ of the Mule-UCS manual, last
updated on 25 January 2002.  It documents the XEmacs package
distribution of Mule-UCS.  It should be applicable to other versions of
0
Dan
1/30/2005 5:28:32 PM
Dan Espen <daneNO@SPAM.mk.telcordia.com> writes:

> Dan Espen <daneNO@SPAM.mk.telcordia.com> writes:
>
>> Adrian Aichner <adrian@xemacs.org> writes:
>>
>>> Dan Espen <daneNO@SPAM.mk.telcordia.com> writes:
>>>
>>> <32 lines deleted by Adrian Aichner>
>>>> I found this line in the MULE documentation under instructions
>>>> for enabling mule:
>>>>
>>>> (set-coding-category-system 'utf-8 utf-8)
>>>
>>> Dan, I had to search all .texi files in the XEmacs source tree to find
>>> what you could be referring to.
>>>
>>> I found no match for the incorrect example above.
>>>
>>>>
>>>> it should be:
>>>>
>>>> (set-coding-category-system 'utf-8 'utf-8)
>>>>                                    ^
>>>
>>> This correction has been in place for a long time in the trunk and 21.4
>>> branches of 
>>> man/xemacs-faq.texi
>>
>> You're right.
>>
>> Plus the copy I have has the quote too.
>>
>> BUT, when I look at it in info, there's no quote.
>>
>> I took the pathname from the info buffer, deleted the info
>> buffer and looked again using find-file, and the quote
>> is there.
>>
>> Are there some quoting rules for texinfo files that are being
>> violated, or is my info broken?
>
> Nope, that's not it.
> Those lines occur twice in the info file.
> The first set are OK, the second aren't.

Right, I hadn't run igrep-find on the package sources first.

There was a leftover typo still.

I just commited the typo fix to the repository.

The fix should appear in the next mule-ucs pre-release package soon.

Best regards,

Adrian

cd c:\Hacking\cvs.xemacs.org\XEmacs\packages\
c:\cygwin\bin\find . -type d ( -name RCS -o -name CVS -o -name .svn -o -name SCCS ) -prune -o -type f ! -name "*~" ! -name "*,v" ! -name "s.*" ! -name ".#*" -name "*.texi" -print0 | xargs -0 -e grep -n -Pi -e "set-coding-category-system.*utf-8"  NUL:
Compilation started at Sun Jan 30 15:32:12 2005 +0100 (W. Europe Standard Time)
../mule-packages/mule-ucs/doc/mule-ucs.texi:200:(set-coding-category-system 'utf-8 'utf-8)
../mule-packages/mule-ucs/doc/mule-ucs.texi:351:(set-coding-category-system 'utf-8 utf-8)

igrep finished at Sun Jan 30 15:33:21

>
> This is at the front of the file I have:
>
>    This is version $Revision: 1.4 $ of the Mule-UCS manual, last
> updated on 25 January 2002.  It documents the XEmacs package
> distribution of Mule-UCS.  It should be applicable to other versions of

-- 
Adrian Aichner
 mailto:adrian@xemacs.org
 http://www.xemacs.org/
0
Adrian
1/30/2005 6:47:45 PM
On 2005-01-19 21:42:18 +0100, Alan Mackenzie <acm@muc.de> said:
> 
> On Usenet, typography is NOT a priority.  Standardisation is.  Surely
> "fa?ade" is going to be marginally easier than "fa??ade" to read on a
> terminal which is lacking the language support of the writer?  (And if
> not, what's wrong with "Fassade"? ;-)

Well I think that the french academy won't like "fassade" ;) But as the 
word "facade" does not exist in french then it is the most human 
readable way to write it in ASCII 127 and fa�ade is the only good 
syntax for this word

> Why must you use utf-8 here?  It's less readable, on average[*], than
> 8859-x or ASCII.  Your post is in an English language newsgroup.  Why
> must you depart from successful standards and ettiquette, recognised for
> decades?

I am agree with you there's an etiquette for newsgroups and we have to 
respect it. And even in french ng the usage of UTF-8 is not recommended 
and we prefer latin-1. Then if we take care about ng users we have to 
use ASCII and not UTF
[...]
> 
> There was an irritating fashion several years ago, due largely to
> Microsoft's Outlook Express, for posting in HTML on newsgroups.  The
> attitude of those posters was something like "for goodness sake, stop
> moaning; this is 1999/2000/<whenever>; upgrade your stone-age system to
> something modern, and you'll find my posts much nicer looking than most."
> There would seem to be no essential difference between the utf-8 poster's
> attitude and the HTML poster's.
> 
> [*] this average being taken over computer systems used for reading
> Usenet.


-- 
	Fred

0
Frederic
2/4/2005 2:57:00 PM
Reply:

Similar Artilces:

Re: Can't get Super key to work
Aidan; Got some answers back from the Fedora mailing list that may help. "Subject: Re: My super key won't act as a modifier key in my Xemacs 21.4.15 To: For users of Fedora Core releases <fedora-list@redhat.com> Message-ID: <41E47543.9030000@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed I think this is probably the same issue as: http://freedesktop.org/bugzilla/show_bug.cgi?id=1625 There are bugs open in our bugzilla against emacs and xemacs already. Jens" And "To: For users of Fedora Core releases <f...

Can't get sqlite3.Row working: keyword lookup doesn't work
Hello, using Python 2.7.6 I try to access a sqlite database using keyword lookup instead of position (much more easy to maintain code), but it always fail, with the error: Index must be int or string I have created the database, populated it, and here is the code that tries to retrieve the information: with sqlite3.connect(mydbPath) as db: # open the database db.row_factory = sqlite3.Row cursor = db.cursor() cursor.execute("SELECT * FROM files") for row in cursor.fetchall(): print(row.keys()) print(row["filename&qu...

Can't get 'require' to work
I just started tinkering with Ruby. From "The Poignant Ruby Programmer" or whatever it's called (you know what I mean) I tried running the small example but get an error. This is the first file called m2.rb: require '/usr/home/me.rb' # Get evil idea and swap in code words print "Enter your new idea: " idea = gets code_words.each do |real, code| idea.gsub!( real, code ) end # Save the jibberish to a new file print "File encoded. Please enter a name for this idea: " idea_name = gets.strip File::open( "idea-" + idea_name + "...

Mechanize: Can't get it to work. Can I help make it work next week?
This may be just one more play where my lack of experience with Ruby is biting me, but I have had no luck making mechanize go. I'm using version 0.2.3, and it claims to gem install successfully, but when I try to do a simple script that just goes: require 'rubygems' require 'mechanize' agent = WWW::Mechanize.new (and several versions of thingsafterthis, including blank, don't seem to make any difference) and I run that alone and get a LoadError pointing to something called custom_require.rb, lines 18 and 24, and mechanize line 14. I'd like to make...

I can see keys I can't fetch, and now I'm getting DB_RUNRECOVERY.
G'day, everyone. I'm one of the developers of iPodder, and we're using Python 2.3's inclusion of Berkely DB to implement our state database. C:\dev\db-4.2.52.NC>python >>> import bsddb >>> bsddb.__version__ '4.2.0.2' We've taken great pains to avoid having iPodder run twice, so the database shouldn't be open to more than one process at a time, but we *do* run a lot of threads all of which pound the database at once. That might not have been such a good idea, as we're spotting a few of weird things. Perhaps amusingly, it&...

Can't get sound working (don't worry, full of details)
Hi, I'm new to OpenBSD but I'd like to use it as my desktop. One of the two problems which don't let me do that is that I can't get any sound, :P. Well, I read the FAQs and here is the deal: My motherboard is this: SY-P4VGM http://www.soyousa.com/products/proddesc.php?id=273 My chip is supported (VT8233): http://www.openbsd.org/i386.html dmesg output related to my chip: auvia0 at pci0 dev 17 function 5 "VIA VT8233 AC97" rev 0x50: irq 12 ac97: codec id 0x56494161 (VIA Technologies VT1612A) ac97: codec features headphone, 18 bit DAC, 18 bi...

Can't even get 'Hello World' to work in Oracle!
Maybe I'm a moron. I don't know, but I can't even get Hello World to work in Oracle. I have the following SQL file: BEGIN DBMS_OUTPUT.put_line ('Hello World'); END; I am using SQL developer and connecting to an Oracle Server instance (not sure what version). I run the above file and it just says anonymous block completed in the script output window. In the DBMS output window, it says nothing. In the OWA Output window, it says nothing. What are all of those windows anyway? Thanks in advance for your help. Kramer314 <johnlkramer@gmail.com> wrote in ne...

Can't get '--coverage-html' switch to work in PHPUnit2
hi, how do I use code coverage and test skeleton generators to work in PHPUnit2. I used following commands 1) phpunit --coverage-html SomeTest 2) phpunit --skeleton SomeClass as described at http://www.phpunit.de/en/phpunit2_codecoverage.php and http://www.phpunit.de/en/phpunit2_skeleton.php, but it is not working. Please Help. Thanks ...

pgnuplot 4.0 can't get 'with labels' feature to work
Hi, I can plot the curve just fine unless I try to add labels to the data points. I have seen this labels technique working on several gnuplot tutorials. I cannot find a reason why mine doesn't work. Thanks in advance, Ed WinXP SP2 pgnuplot 4.0 (works) plot '3509120199_APV_dataPointsPruned.csv'using 2:3 with linespoints (doesn't work) plot '3509120199_APV_dataPointsPruned.csv'using 2:3 with linespoints,'' using 2:3:2 with labels ^ expecting 'lines', 'points', 'linespoints',...

Can't use my //e because I can't get any software for it
Here's my problem. I have an Apple //e, but I have absolutely no software for it. I have an older Mac. All of the images I have found are 5.25" and I can't write those back to the floppy using the Mac (or a PC for that matter). I don't have a null modem, but that doesn't matter because I don't have any comm software. Basically I have no way to get anything onto a bootable floppy. Now, if I could find a bootable image of a 3.5" disk I would be in business, but everything is in 5.25" format. Would an emaulator be able to create a bootable 3.5" di...

[Q] Can't get shifted arrow keys to work in xterm. Help pls.
Running VIM 6.1.320 under RedHat 9 in KDE konsole. Arrow keys work fine. Would like to get shifted arrow keys to do selection, but when I press them, nothing happens. $ echo $TERM xterm $ cat .xmodmap ! ! This is an `xmodmap' input file for ! PC 104 key, wide Delete, short Enter (XFree86; US) keyboards. ! Automatically generated on Fri Feb 7 22:43:37 2003 by gary with ! XKeyCaps 2.45; Copyright (c) 1999 Jamie Zawinski <jwz@jwz.org>. ! http://www.jwz.org/xkeycaps/ ! keycode 0x4F = Home keycode 0x50 = Up F13 keycode 0x51 = Prior keycode 0x53 = Left F18 k...

Perl/Tk: can't get -command=> \&function to work 'on-the-fly'!!
Please Help! I am trying to define buttons 'on-the-fly' mostly because their number is determined in a config file - I don't know how many I will need. It's ROYALLY NOT WORKING. I think Tk.pm is having issues. And it's all driving me very... verrrryyy... batty. *** I WANT THIS TO WORK *** (pseudo-code) for i=1;i<100,i++ { $handle[i] = menubar->command(-label => "test_i", %somecolors, -command => Move2Folder(i)); *** IS THIS TOO MUCH TO ASK??? *** 1) If I 'unroll it' (see end of this message) AND wrap the Move2Folder function...

Can't start xemacs
Hi - Running Slackware 10.1 and just installed xemacs. Won't start can't find lib libaudio.so.2. Any ideas? Googled and couldn't find anything relevent. Thanks John John <segmentdump@chello.se> writes: > > Running Slackware 10.1 and just installed xemacs. Won't start can't > find lib libaudio.so.2. Any ideas? It sounds like perhaps you installed a binary that was compiled against NAS. If you want XEmacs to have sound, I think you'll have to install that too http://radscan.com/nas.html If you don't care about sound in XEmacs, the...

I don't work for IBM and I don't make promises I can't deliver on
I wish I could afford an advertising campaign to compete with what they have on the Internet now. I promise to go totally ballistic at the next LLLNL contract. Robert. On 8/12/2011 11:24 PM, Robert Myers wrote: > I wish I could afford an advertising campaign to compete with what they > have on the Internet now. > > I promise to go totally ballistic at the next LLLNL contract. > > Robert. I don't work for IBM (anymore) either. If you are talking about the death of Blue Waters, I don't believe they said they couldn't deliver. They said they chose not to beca...

Web resources about - Can't get Super key to work - comp.emacs.xemacs

Resources last updated: 2/1/2016 2:56:54 AM