emacs 22 release

emacs 22 release

[Olive]

Hello,

Does anyone know if there are a date planned for the Emacs 22 release. I 
have been told that emacs 22 is already stable (in particular the auctex 
manuel recommend it). I consider to switch to it already, but I am 
usually very relunctant to use unreleased version of softwares because I 
usually think that if a software has not been released, then the 
developpers should have a good reason for that.

Olive

Re: emacs 22 release

[Nurullah Akkaya]

i have been using 22 for a while it is stable never crashed and it  
usually stays open for days.
os is mac os x

On Sep 28, 2005, at 8:04 AM, Olive wrote:

> Hello,
>
> Does anyone know if there are a date planned for the Emacs 22  
> release. I have been told that emacs 22 is already stable (in  
> particular the auctex manuel recommend it). I consider to switch to  
> it already, but I am usually very relunctant to use unreleased  
> version of softwares because I usually think that if a software has  
> not been released, then the developpers should have a good reason  
> for that.
>
> Olive
>
>
>
> _______________________________________________
> Help-gnu-emacs mailing list
> Help-gnu-emacs@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
>

Re: emacs 22 release

[Peter Dyballa]

Am 28.09.2005 um 15:04 schrieb Olive:

> Does anyone know if there are a date planned for the Emacs 22 release.

I don't see so many changes from stable GNU Emacs 21.4 to GNU Emacs 22 
from CVS. The latter still can't handle completely the case of dealing 
with more than one ISO or Unicode encoding. And printing is still bad 
too! This message comes from trying to print a buffer in ISO 
8859-15/ISO Latin-9:

	These characters in the buffer can't be printed:
	 €,  , ¡, ¢, £, €, ¥, Š, §, š, ©, ª, «, ¬, ­, and more...
	Click them to jump to the buffer position,
	or C-u C-x = will give information about them.

And it's not even true, since I can see ¡, ¢, £, §, ©, ª, «, ¬, ­ ...

Is it really that complicated to determine the system's TrueType fonts 
and use the Unicode encoded ones to print in whatever ISO, Greek, or 
Cyrillic encoding? Or in Arabic or Hebrew?

I'd look forward to Unicode Emacs 23.

--
Greetings

   Pete

When in doubt, use brute force.
                 -- Ken Thompson

Re: emacs 22 release

[Kevin Rodgers]

Peter Dyballa wrote:
 > I don't see so many changes from stable GNU Emacs 21.4 to GNU Emacs 22
 > from CVS. The latter still can't handle completely the case of dealing
 > with more than one ISO or Unicode encoding.

Did you happen to turn off unify-8859-on-encoding-mode?  (It's enabled
in Emacs 22 by default.)  Did you try turning on
unify-8859-on-decoding-mode?

 > And printing is still bad
 > too! This message comes from trying to print a buffer in ISO 8859-15/ISO
 > Latin-9:
 >
 >     These characters in the buffer can't be printed:
 > 	 €,  , ¡, ¢, £, €, ¥, Š, §, š, ©, ª, «, ¬, ­, and more...
 >     Click them to jump to the buffer position,
 >     or C-u C-x = will give information about them.
 >
 > And it's not even true, since I can see ¡, ¢, £, §, ©, ª, «, ¬, ­ ...

Have you submitted a bug report?  Looking at the source code, it might
be useful to `M-x debug-on-entry RET ps-mule-show-warning RET' and
report what `e unprintable-charsets RET' shows when invoked in the
*Backtrace* buffer.

Also, that error message includes 4 characters that are outside ISO
8859-x: 0x80 (twice), 0x8A, and 0x9A.  Your message was sent as:

	Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
	Content-Transfer-Encoding: quoted-printable

 > Is it really that complicated to determine the system's TrueType fonts
 > and use the Unicode encoded ones to print in whatever ISO, Greek, or
 > Cyrillic encoding? Or in Arabic or Hebrew?

I don't know, but I suspect it is hard to do for all the platforms that
Emacs supports.

 > I'd look forward to Unicode Emacs 23.

You'd be looking very far forward.

-- 
Kevin Rodgers

Re: emacs 22 release

[Peter Dyballa]

Am 28.09.2005 um 22:35 schrieb Kevin Rodgers:

> Peter Dyballa wrote:
> > I don't see so many changes from stable GNU Emacs 21.4 to GNU Emacs 
> 22
> > from CVS. The latter still can't handle completely the case of 
> dealing
> > with more than one ISO or Unicode encoding.
>
> Did you happen to turn off unify-8859-on-encoding-mode?  (It's enabled
> in Emacs 22 by default.)  Did you try turning on
> unify-8859-on-decoding-mode?

In my 'standard' edition of GNU Emacs 22 I have not changed the default 
values. Adding

	(setq unify-8859-on-encoding-mode nil)
	(setq unify-8859-on-decoding-mode t)

makes no change in that field which I address in my writing: I can't 
i-search again for the same 8bit character when I change from buffer a 
in encoding a to buffer b in encoding b.

>
> > And printing is still bad
> > too! This message comes from trying to print a buffer in ISO 
> 8859-15/ISO
> > Latin-9:
> >
> >     These characters in the buffer can't be printed:
> > 	 €,  , ¡, ¢, £, €, ¥, Š, §, š, ©, ª, «, ¬, ­, and more...
> >     Click them to jump to the buffer position,
> >     or C-u C-x = will give information about them.
> >
> > And it's not even true, since I can see ¡, ¢, £, §, ©, ª, «, ¬, ­ ...
>
> Have you submitted a bug report?

Not yet, but you motivate me to do so! (Again. I think I reported 
something similiar earlier this year and Kenichi Handa then made some 
changes that the message about unprintable characters became more 
realistic, being based on the actual glyphs of the encoding used. He 
promised that in Unicode Emacs 23 the problem will be solved. Could be 
some backlash happened in the meantime that the reports are not true 
again ... as in real life and its politics. Or politicians?)

>
> Also, that error message includes 4 characters that are outside ISO
> 8859-x: 0x80 (twice), 0x8A, and 0x9A.  Your message was sent as:
>
> 	Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
> 	Content-Transfer-Encoding: quoted-printable

I work on Mac OS X and use Apple's Mail. I think it's so clever to use 
the encoding of the incoming message for the response's encoding. 
Looking at what Mail tells me about this eMail's encoding I see 
'US-Standard' checked! Whatever this means ... I mean, outside the U.S. 
of A! The characters from outside any ISO 8859 encoding you mention can 
come from copying them in GNU Emacs, transferring them to the Mac OS X 
clipboard and then pasting them into Mail. At least *I* can see in your 
citation the same shapes that I saw in Emacs and in my message!

>
> > Is it really that complicated to determine the system's TrueType 
> fonts
> > and use the Unicode encoded ones to print in whatever ISO, Greek, or
> > Cyrillic encoding? Or in Arabic or Hebrew?
>
> I don't know, but I suspect it is hard to do for all the platforms that
> Emacs supports.

It can't be that problematic. There is just a handful of Unicode 
encoded fonts which are regular parts of a Linux or BSD distribution. 
Kind of a standard base edition. And there is too customisation. So a 
'rich' user can make use of her or his set of fonts.

But the problem actually is inside the Elisp code for ps-print: it does 
a censorship on those glyphs it supposes they can't be printed. Here is 
an excerpt from an ISO 8859-15 encoded buffer:

	  = 240 = 160 = A0 = U+00A0 =    C2 A0 : NO-BREAK SPACE
	¡ = 241 = 161 = A1 = U+00A1 =    C2 A1 : INVERTED EXCLAMATION MARK
	¢ = 242 = 162 = A2 = U+00A2 =    C2 A2 : CENT SIGN
	£ = 243 = 163 = A3 = U+00A3 =    C2 A3 : POUND SIGN
	€ = 244 = 164 = A4 = U+20AC = E2 82 AC : EURO SIGN
	¥ = 245 = 165 = A5 = U+00A5 =    C2 A5 : YEN SIGN

and here is that same region as censored by ps-print:

	LHL
	/f0 F
	(\240) S
	/f0 F
	( = 240 = 160 = A0 = U+00A0 =    C2 A0 : NO-BREAK SPACE) S
	LHL
	/f0 F
	(\241) S
	/f0 F
	( = 241 = 161 = A1 = U+00A1 =    C2 A1 : INVERTED EXCLAMATION MARK) S
	LHL
	/f0 F
	(\242) S
	/f0 F
	( = 242 = 162 = A2 = U+00A2 =    C2 A2 : CENT SIGN) S
	LHL
	/f0 F
	(\243) S
	/f0 F
	( = 243 = 163 = A3 = U+00A3 =    C2 A3 : POUND SIGN) S
	LHL
	1 1 SB
	/f0 F
	( = 244 = 164 = A4 = U+20AC = E2 82 AC : EURO SIGN) S
	LHL
	/f0 F
	(\245) S
	/f0 F
	( = 245 = 165 = A5 = U+00A5 =    C2 A5 : YEN SIGN) S

[LHL does a 'hard' linefeed, F selects an encoded font /f0, S does 
complicated things with the string in (), SB paints an empty box]

The Euro sign is taken away, although since five years or even longer 
no PostScript printer entered the market without being able to print a 
€. And you too see that ps-print leaves ¡, ¢, £ in the PS output -- 
although claiming the contrary!

 From these bugs I'd like to estimate that Unicode Emacs 23 will be 
released before GNU Emacs 22. It's worth to go directly to Unicode, 
without wasting the valuable resources of the developers.

>
> > I'd look forward to Unicode Emacs 23.
>
> You'd be looking very far forward.

The elder you become, the easier it gets to look very far away! (I am 
writing from own experience.)

--
Greetings

   Pete                           <]
              o        __o         |__    o       HPV, the real
     ___o    /I       -\<,         |o \  -\),-%     high speed!
___/\ /\___./ \___...O/ O____.....`-O-'-()--o_________________

Re: emacs 22 release

[Jason Rumney]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> In my 'standard' edition of GNU Emacs 22 I have not changed the
> default values. Adding
>
> 	(setq unify-8859-on-encoding-mode nil)
> 	(setq unify-8859-on-decoding-mode t)
>
> makes no change in that field which I address in my writing

As per the documentation for those variables, you can't just set them
like that. Also, I think you want them both set to t, otherwise you
will have problems writing files in various encodings, due to the
buffer representation being a different encoding than what you are
trying to save as. You probably need to kill existing buffers and
reread the files after changing unify-8859-on-decoding-mode, since it
only has any effect when reading files/process output etc. 

>> >     These characters in the buffer can't be printed:
>> > 	 €,  , ¡, ¢, £, €, ¥, Š, §, š, ©, ª, «, ¬, ­, and more...
>> >
>> > And it's not even true, since I can see ¡, ¢, £, §, ©, ª, «, ¬, ­ ...

This is probably because those characters pass through
unify-8859-on-encoding-mode to convert them to Latin-1 after the
message has already been displayed. Out of the box, ps-print only
handles Latin-1, but there are variables to control this.

> Not yet, but you motivate me to do so! (Again. I think I reported
> something similiar earlier this year and Kenichi Handa then made some
> changes that the message about unprintable characters became more
> realistic, being based on the actual glyphs of the encoding used. He
> promised that in Unicode Emacs 23 the problem will be solved. Could be
> some backlash happened in the meantime that the reports are not true
> again ... as in real life and its politics. Or politicians?)

I think the change you are talking about was when saving a file. The
code for printing is different, so a separate fix will be required
there.

>  From these bugs I'd like to estimate that Unicode Emacs 23 will be
>  released before GNU Emacs 22. It's worth to go directly to Unicode,
>  without wasting the valuable resources of the developers.

Using Unicode in Emacs will not magically fix postscript. There is
more work involved in getting all the peripheral code like ps-print to
take advantage of the Unicode support in the core of Emacs 23 than
there is in fixing a few minor bugs in Emacs 22.

Re: emacs 22 release

[Jason Rumney]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> from CVS. The latter still can't handle completely the case of dealing
> with more than one ISO or Unicode encoding.

What do you mean by that?

Re: emacs 22 release

[Peter Dyballa]

Am 29.09.2005 um 09:12 schrieb Jason Rumney:

> What do you mean by that?
>

*Not* having set unify-8859-on-encoding-mode to nil and 
unify-8859-on-decoding-mode to t, I can i-search in an ISO 8859-1 
buffer for ä. When I then change to an ISO 8859-15 encoded buffer and I 
type C-s C-s (repeating previous i-search) ä can't be found (I can see 
it *is* there). There seem to be ten different ä's! And similarly the 
other 8bit characters.

Setting

	(setq unify-8859-on-encoding-mode nil)
	(setq unify-8859-on-decoding-mode t)

for GNU Emacs 22 makes no change.


I reported this earlier this year. Stefan Monnier and Kenichi Handa 
tried to help me with some code to patch xterm.c. It worked fine -- as 
long as I did not update again ...

--
Greetings

   Pete

There's something the technicians need to learn from the artists.
If it isn't aesthetically pleasing, it's probably wrong.

Re: emacs 22 release

[Johan Bockgård]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Setting
>
> 	(setq unify-8859-on-encoding-mode nil)
> 	(setq unify-8859-on-decoding-mode t)
>
> for GNU Emacs 22 makes no change.

    "Setting this variable directly does not take effect; use either
     M-x customize or the function `unify-8859-on-decoding-mode'."

-- 
Johan Bockgård

Re: emacs 22 release

[Peter Dyballa]

Am 29.09.2005 um 16:21 schrieb Johan Bockgård:

>> Setting
>>
>> 	(setq unify-8859-on-encoding-mode nil)
>> 	(setq unify-8859-on-decoding-mode t)
>>
>> for GNU Emacs 22 makes no change.
>
>     "Setting this variable directly does not take effect; use either
>      M-x customize or the function `unify-8859-on-decoding-mode'."
>

(unify-8859-on-decoding-mode) makes it! I can reuse i-search's 8bit 
arguments!

--
Greetings

   Pete     === -Q
              ==<__/% >>
_____________(_)____@_____________________________

Re: emacs 22 release

[Stefan Monnier]

> I reported this earlier this year.  Stefan Monnier and Kenichi Handa tried
> to help me with some code to patch xterm.c. It worked fine -- as long as
> I did not update again ...

Please try to resurrect the thread by re-reporting the bug.
You can include my suggested patch in it.


        Stefan


--- orig/src/keyboard.c
+++ mod/src/keyboard.c
@@ -3185,6 +3185,11 @@
     }
 
  exit:
+  if (NATNUMP (c) && !EQ (prev_event, Qt)
+      && CHAR_VALID_P (XFASTINT (c), Qnil))
+    XSETINT (c, translate_char (Vtranslation_table_for_input,
+                               XFASTINT (c), 0, 0, 0));
+
   RESUME_POLLING;
   RETURN_UNGCPRO (c);
 }

Re: emacs 22 release

[Sébastien Kirche]

At 17:09 on Sep 28 2005, Peter Dyballa said :

> And printing is still bad 
> too! This message comes from trying to print a buffer in ISO 
> 8859-15/ISO Latin-9:
> 
> 	These characters in the buffer can't be printed:
> 	 €,  , ¡, ¢, £, €, ¥, Š, §, š, ©, ª, «, ¬, ­, and more...
> 	Click them to jump to the buffer position,
> 	or C-u C-x = will give information about them.
> 
> And it's not even true, since I can see ¡, ¢, £, §, ©, ª, «, ¬, ­ ...

For that  problem of using latin-9  chars when printing, i  have found a
setting that helped much :

(setq ps-mule-font-info-database-default 
      '((latin-iso8859-15 (normal nil nil iso-latin-9)) 
	    (latin-iso8859-1 (normal nil nil iso-latin-1))))

I am  by default in  latin-9 (although I  am currently with OSX)  and at
least  the  €  is  printed  correctly.  Printer  is  PS  compatible  too
(HP LaserJet).

-- 
Sébastien Kirche

Re: emacs 22 release

[Peter Dyballa]

Am 29.09.2005 um 10:09 schrieb Sébastien Kirche:

> (setq ps-mule-font-info-database-default
>       '((latin-iso8859-15 (normal nil nil iso-latin-9))
> 	    (latin-iso8859-1 (normal nil nil iso-latin-1))))
>

This statement makes GNU Emacs report the truth:

	These characters in the buffer can't be printed:
	 €, €, Š, š, Ž, ž, Œ, œ, Ÿ

Then I patched both /sw/share/ghostscript/fonts/Fontmap.GS having the 
PostScript font names point to corresponding Unicode encoded TrueType 
files and the PS spool file to now have an ISOLatin9Encoding -- and 
voilà: the PDF output from ps2pdf14 was correct! (I only had to use 
TeXShop or Preview, gv did not want to show € -- I don't want to waste 
paper, toner, and energy, it's all part of the German disease)

This systems works for some more encodings too. It would be very useful 
if ps-print would print less boxes to substitute with the proper glyph!

--
Greetings

   Pete

Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush

Re: emacs 22 release

[Peter Dyballa]

Am 29.09.2005 um 10:09 schrieb Sébastien Kirche:

> For that  problem of using latin-9  chars when printing, i  have found 
> a
> setting that helped much :
>
> (setq ps-mule-font-info-database-default
>       '((latin-iso8859-15 (normal nil nil iso-latin-9))
> 	    (latin-iso8859-1 (normal nil nil iso-latin-1))))
>

Sébastien,

to me this setting makes no difference! I can start GNU Emacs 22 
without this setting active, open my iso-latin-9 encoded file and print 
it with ps-spool-buffer-with faces. When I save the *PostScript* buffer 
under a different name, eval your code and 'print' again, the new 
*PostScript* buffer is only different in the printing date ...

--
Greetings

   Pete

The day Microsoft makes something that doesn't suck is the day they 
start selling vacuum cleaners.

Re: emacs 22 release

[Sébastien Kirche]

At 00:10 on oct 1 2005, Peter Dyballa said :

> Am 29.09.2005 um 10:09 schrieb Sébastien Kirche:
> 
> > For that  problem of using latin-9  chars when printing, i  have
> > found a
> > setting that helped much :
> > 
> > (setq ps-mule-font-info-database-default
> > '((latin-iso8859-15 (normal nil nil iso-latin-9))
> > 	    (latin-iso8859-1 (normal nil nil iso-latin-1))))
> > 
> 
> Sébastien,
> 
> to  me this  setting makes  no difference!  I can  start GNU  Emacs 22
> without  this setting  active, open  my iso-latin-9  encoded  file and
> print it with ps-spool-buffer-with faces. When I save the *PostScript*
> buffer under a  different name, eval your code  and 'print' again, the
> new *PostScript* buffer is only different in the printing date ...

Sorry to see that it does not fix anything for you.

The key is maybe that I use those settings not to process the postscript
data  e.g. with  ghostscript but  to send  it directly  to  a postscript
printer.

Maybe it is what makes the difference ?

-- 
Sébastien Kirche

Re: emacs 22 release

[Peter Dyballa]

Am 01.10.2005 um 14:13 schrieb Sébastien Kirche:

> The key is maybe that I use those settings not to process the 
> postscript
> data  e.g. with  ghostscript but  to send  it directly  to  a 
> postscript
> printer.
>
> Maybe it is what makes the difference ?
>

How? Is there any reason why GNU Emacs should send different PS code to 
the *PostScript* buffer then to the printer queue?

I wouldn't buy a printer without PostScript, so I do not have any need 
to use gs between GNU Emacs or another application and the printer. And 
it's modern enough to be able to print € or ISO 8859-16 glyphs. It's 
CUPS that finally takes care for a good printout, being able to convert 
text to PS too?

There is just one need for gs: to view GNU Emacs' output or to convert 
this output reliably to PDF. Apple's own pstopdf in Mac OS X fails as 
does any other application when made to display this: they all first 
need to convert PS to PDF to make it display (as "Display PDF") in 
Quartz.

--
Greetings

   Pete

"Eternity is a terrible thought. I mean, where's it going to end?"
                                                    - Tom Stoppard

Re: emacs 22 release

[Sébastien Kirche]

At 16:10 on Oct 1 2005, Peter Dyballa said :

> How? Is there any reason  why GNU Emacs  should send different PS code
> to the *PostScript* buffer then to the printer queue?

Actually, i don't know, but IIRC I was not able to printthe euro sign to
the network printer HP LaserJet here until I found that setting
somewhere in the web.

> I wouldn't buy a printer without PostScript, so I do not have any need
> to use gs  between GNU Emacs or another  application  and the printer. 
> And it's modern  enough to be able  to print € or  ISO 8859-16 glyphs. 
> It's CUPS that finally takes  care for a good  printout, being able to
> convert text to PS too?

I dunno.

> There is just one need for gs: to view GNU Emacs' output or to convert
> this output reliably to PDF. Apple's own pstopdf in  Mac OS X fails as
> does any  other application when made  to display this: they all first
> need  to convert PS to  PDF to make it   display (as "Display PDF") in
> Quartz.

Yes. I never understood why can't one see a ps-printed emacs page
correctly on OSX  without processing it first.
-- 
Sébastien Kirche

Re: emacs 22 release

[Stefan Monnier]

> I'd look forward to Unicode Emacs 23.

Have you actually tried that branch and found it to be working
more smoothly?  Or are you just assuming that because it says "Unicode" it
will necessarily have all problems fixed without even having to do anything
about them?


        Stefan

Re: emacs 22 release

[Peter Dyballa]

Am 04.10.2005 um 05:57 schrieb Stefan Monnier:

> Have you actually tried that branch and found it to be working
> more smoothly?

Yes. From the start Unicode Emacs 23 handled the switching between 
buffers with different ISO 8859 encodings better. C-h H made an 
improved impression. File names in UTF-8 (as in Mac OS X) appear to be 
file names, they don't look like a cloud of 8 bit control characters. 
And the dates of the files can be from the month of "Mär". UTF-8 output 
from programmes in *Shell* looks right. Printing looks to be even worse 
than in GNU Emacs 22. And Carbon Emacs 23 lacks more than GNU Emacs 22, 
particularly font handling.

> Or are you just assuming that because it says "Unicode" it will 
> necessarily have all problems fixed without even having to do anything 
> about them?
>

Reading this word made me believe to assume some progress in handling a 
non-7 bit world, being more based on a recent reality. This seems to be 
true, this too still needs many improvements (for example using the 
pre-composed glyphs instead of trying to compose the names from the 
de-composed contents of directory entries). Unicode Emacs 23 is not 
completely finished yet.

--
Greetings

   Pete

Think of XML as Lisp for COBOL programmers.

	-- Tony-A (some guy on /.)

Re: emacs 22 release

[Harald Hanche-Olsen]

+ Peter Dyballa <Peter_Dyballa@Web.DE>:

| Am 04.10.2005 um 05:57 schrieb Stefan Monnier:
| 
| > Have you actually tried that branch and found it to be working
| > more smoothly?
| 
| Yes. From the start Unicode Emacs 23

I'd like to try it too, just to see for myself where it stands.
Is emacs-unicode-2 the appropriate cvs tag to check out?

- Harald

Re: emacs 22 release

[Peter Dyballa]

Am 04.10.2005 um 22:43 schrieb Harald Hanche-Olsen:

> Is emacs-unicode-2 the appropriate cvs tag to check out?
>

Yes!

cvs -z3 -d:ext:anoncvs@savannah.gnu.org:/cvsroot/emacs co -d 
emacs-unicode -r emacs-unicode-2 -P emacs

To update:

cd emacs-unicode ; cvs -z3 
-d:ext:anoncvs@savannah.gnu.org:/cvsroot/emacs update


--
Greetings

   Pete

"engineer: a mechanism for converting caffeine into designs"

Re: emacs 22 release

[Ralf Resack]

Hello,

Olive writes:

> Does anyone know if there are a date planned for the Emacs 22
> release. 

This question came up in the mailing list "emacs-devel"
recently. You'll find Richard M. Stallman's answer in this thread:

<http://lists.gnu.org/archive/html/emacs-devel/2005-09/threads.html#00313>,
<http://lists.gnu.org/archive/html/emacs-devel/2005-09/msg00353.html>.

Ralf