Release timelines and Unicode2 branch

Release timelines and Unicode2 branch

[Adrian Robert]

Hi,

I'm maintaining the Emacs-on-Aqua GNUstep / OS X port, currently  
based on emacs 20.7 (http://emacs-on-aqua.sf.net/).  I want to update  
this to a more recent version but would ideally like to do so against  
a stabilized / released version of GNU emacs -- just so I know that  
bugs are my own fault when doing the port.  On the other hand, I'm  
not sure if the 21.3/21.4 release is best for this since there was a  
lot of change since then.  That brings my first question:

1) When is the best estimate of when 22.1 will come out?

My second question concerns the unicode-2 branch of CVS.  As I  
understand it, this branch contains reworked internal handling of  
character encoding, is receiving updates from CVS Head, and will  
eventually form the basis for a future emacs release.  (23?)  To  
avoid having to rework Emacs-on-Aqua's character handling in the  
future, I was thinking to base my port on this branch rather than  
22.1.  So my questions here:

2) Is 22.1 being released off its own branch (instead of the head),  
and if so are the stabilizations (to be) done there merged into  
unicode-2?

3) How much significant unicode-2-specific work remains before that  
branch becomes eligible for a release of its own?  (I see from the  
list archives there are plans to merge unicode into CVS head, but  
that doesn't necessarily mean there won't be further heavy  
development before 23.1.)  And how stable / bug-free is unicode-2  
right now compared with the will-become-22.1 code?  What I'm getting  
at is, is it reasonable to port Emacs-on-Aqua to this branch now, or  
should I stick with the to-be-22.1 code, or perhaps just wait before  
starting anything?

thanks,
Adrian

Re: Release timelines and Unicode2 branch

[Stefan Monnier]

> 1) When is the best estimate of when 22.1 will come out?

Not before 2006.

> My second question concerns the unicode-2 branch of CVS.  As I  understand

I don't know much about Aqua/Cocoa/Carbon, and more specifically I don't
know how different are Cocoa and Carbon, so I don't know who much of the
Carbon work can be used for the Cocoa work.  From the sound of your message
and a few others I've seen in the past, it seems that the Carbon port is of
no use for the Cocoa port.  Too bad.

But AFAIK the Cocoa API uses utf-8 or Unicode throughout, so I think it
would make a lot of sense to start from the emacs-unicode branch.
That will also help you avoid having to play catch up.

OTOH if the work can be expected to take in the order of a few months only
(i.e. a large part of the work you've done on 20.7 can be reused with little
or no changes), it would also make sense to start from the current HEAD (to
be 22.1).

In any case I think such an effort should aim to be included in the official
Emacs release.


        Stefan

Re: Release timelines and Unicode2 branch

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > 1) When is the best estimate of when 22.1 will come out?
>
> Not before 2006.

I hope it can be done faster than that!

Looking through FOR-RELEASE, the only major bug left to fix is the
compact_small_strings/string_free_list problem -- which may have been
finally pinned down today (see the thread on "potential bug in
display_mode_element").

Assuming that problem is really fixed, there are only five bugs left
in the list, of which three can be resolved quickly:

(1) Update Speedbar.

According to

  http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg00263.html

the paperwork for speedbar is OK, so we just need to copy in
speedbar.el, dframe.el, sb-image.el, and ezimage.el along with some
icons, from

  http://cvs.sourceforge.net/viewcvs.py/cedet/cedet/speedbar/

If its OK, I'll contact Eric Ludlam and go ahead and copy in the
files.

(2) Fix recognition of shell's `dirs' command.

I installed tcsh, turned on command echoing, and was unable to get the
`dirs' command confused.  Let's just close this, unless someone else
is seeing the problem.

(3) Emacs on Windows crashes on JPEG images from files in unusual
    MingW/MSVC configurations

The commentary says that the fix is straightforward but "it is on the
back burner waiting for a legal comment".  Since the legal comment
doesn't seem to be forthcoming, let's just add a note to etc/PROBLEMS
telling users not to mix MSVC builds of Emacs with a MinGW builds of
the jpeg library, and not delay the release for this.

(4) Bug in ebrowse
(5) TCP server processes do not work on Windows.

Can we start the release process once these five bugs are resolved, or
is there any more reason to delay?

Re: Release timelines and Unicode2 branch

[David Kastrup]

"Chong Yidong" <cyd@stupidchicken.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> > 1) When is the best estimate of when 22.1 will come out?
>>
>> Not before 2006.
>
> I hope it can be done faster than that!

[...]

> Can we start the release process once these five bugs are resolved,
> or is there any more reason to delay?

One should give out warnings suitably in advance to all serious
hackers so that they don't suffer a heart attack.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Release timelines and Unicode2 branch

[Kim F. Storm]

"Chong Yidong" <cyd@stupidchicken.com> writes:

> Can we start the release process once these five bugs are resolved, or
> is there any more reason to delay?

Starting the release process means to start the pre-test.

IMO, solving the remaining problems don't need to postpone that,
but Richard has the final word.

If we start the pretest now, maybe we can release 22.1 in 2005.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Release timelines and Unicode2 branch

[Stefan Monnier]

>> > 1) When is the best estimate of when 22.1 will come out?
>> Not before 2006.
> I hope it can be done faster than that!

I hope so as well, but my best estimate is still "not before 2006".


        Stefan

Re: Release timelines and Unicode2 branch

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 12 Sep 2005 17:37:13 -0400
> Cc: emacs-devel@gnu.org
> 
> >> > 1) When is the best estimate of when 22.1 will come out?
> >> Not before 2006.
> > I hope it can be done faster than that!
> 
> I hope so as well, but my best estimate is still "not before 2006".

Mine too.

Re: Release timelines and Unicode2 branch

[Juanma Barranquero]

On 9/12/05, Chong Yidong <cyd@stupidchicken.com> wrote:

> I hope it can be done faster than that!

I'll eat my Emacs reference card if 22.1 is out before *2007*. Yeah,
I've read the rest of the thread. I'll be delighted to be proven
wrong.

> (3) Emacs on Windows crashes on JPEG images from files in unusual
>     MingW/MSVC configurations
> 
> The commentary says that the fix is straightforward but "it is on the
> back burner waiting for a legal comment".  Since the legal comment
> doesn't seem to be forthcoming, let's just add a note to etc/PROBLEMS
> telling users not to mix MSVC builds of Emacs with a MinGW builds of
> the jpeg library, and not delay the release for this.

It could crash with MinGW-only builds, if Emacs and the library were
compiled against different versions of the RTL. It's *not* dependant
on MSVC.

-- 
                    /L/e/k/t/u

Re: Release timelines and Unicode2 branch

[Romain Francoise]

"Chong Yidong" <cyd@stupidchicken.com> writes:

> (2) Fix recognition of shell's `dirs' command.

> I installed tcsh, turned on command echoing, and was unable to get the
> `dirs' command confused.  Let's just close this, unless someone else
> is seeing the problem.

I can reproduce it with bash and 'stty echo', or with zsh.  We installed
a change in 2003 that is supposed to fix the problem but doesn't work in
all cases.  I spent some time a few weeks ago to try to find a fix but
failed; I plan to work on this again in the near future as motivation
allows...

-- 
Romain Francoise <romain@orebokech.com> | The world is a fine place,
it's a miracle -- http://orebokech.com/ | and worth fighting for.
                                        | --Ernest Hemingway

Re: Release timelines and Unicode2 branch

[Emilio Lopes]

Romain Francoise writes:

> "Chong Yidong" <cyd@stupidchicken.com> writes:
>> (2) Fix recognition of shell's `dirs' command.

> I can reproduce it with bash and 'stty echo', or with zsh.  We
> installed a change in 2003 that is supposed to fix the problem but
> doesn't work in all cases.  I spent some time a few weeks ago to try
> to find a fix but failed; I plan to work on this again in the near
> future as motivation allows...

Maybe you could report your experience so far, so that others with the
motivation need not to go all the process for themselves again.

Re: Release timelines and Unicode2 branch

[Romain Francoise]

Emilio Lopes <eclig@gmx.net> writes:

> Maybe you could report your experience so far, so that others with the
> motivation need not to go all the process for themselves again.

Sure.  In a nutshell, the optional part of the regular expression
sometimes doesn't match even when there is an echoed
`shell-dirstack-query' command, so the command is considered to be the
directory list.  (The change we installed back in 2003 was to add this
optional part.)  Depending on the state of your shell buffer (what
previous shell commands returned, etc), things sometimes work as
intended.

I have yet to understand why it doesn't match in some cases.  Beware
that doing things under edebug will change things subtly in a way that
any fix you might find won't work in the normal case (without edebug).
Also, in my case stepping in the function made Emacs hang when reaching
this line:

      (while (not (looking-at
		   (concat "\\(" ; skip literal echo in case of stty echo
			   (regexp-quote shell-dirstack-query)
			   "\n\\)?" ; skip if present
			   "\\(" ".+\n" "\\)")) ) ; what to actually look for
=>	(accept-process-output proc)
	(goto-char pt)))

Reaching `proc' sends Emacs in an infinite loop, C-g C-g escapes it but
also stops the edebug session.

Good luck!

-- 
Romain Francoise <romain@orebokech.com> | All you've been is a piece of
it's a miracle -- http://orebokech.com/ | blood wrapped in skin.

Re: Release timelines and Unicode2 branch

[Emilio Lopes]

Thanks for taking the time to explain the problem.  I can definitely
reproduce this.

Re: Release timelines and Unicode2 branch

[Chong Yidong]

> Sure.  In a nutshell, the optional part of the regular expression
> sometimes doesn't match even when there is an echoed
> `shell-dirstack-query' command, so the command is considered to be the
> directory list.  (The change we installed back in 2003 was to add this
> optional part.)  Depending on the state of your shell buffer (what
> previous shell commands returned, etc), things sometimes work as
> intended.
>
> I have yet to understand why it doesn't match in some cases.

What do you mean by "in some cases"?  Is there a consistent way to
reproduce this, i.e., step by step instructions for getting
shell-resync-dirs confused?

Re: Release timelines and Unicode2 branch

[Romain Francoise]

Chong Yidong <cyd@stupidchicken.com> writes:

> What do you mean by "in some cases"?  Is there a consistent way to
> reproduce this, i.e., step by step instructions for getting
> shell-resync-dirs confused?

1. Start a shell in Emacs: SHELL=bash emacs -Q -f shell
2. Make the shell echo: stty echo RET
3. M-x set-variable comint-process-echoes RET t RET
4. M-x dirs RET

=> "Couldn't cd"

3. is optional as it doesn't actually make a difference.

-- 
Romain Francoise <romain@orebokech.com> | I used to think there is no
it's a miracle -- http://orebokech.com/ | future left at all.

Re: Release timelines and Unicode2 branch

[Richard M. Stallman]

    Assuming that problem is really fixed, there are only five bugs left
    in the list, of which three can be resolved quickly:

We also need people to finish checking the files of the manuals, and
finish updating the copyright years in just a couple of directories.
But overall you're right--progress has speeded up and we are getting
pretty close.

I told the CC mode developers that we would wait a few weeks, if
necessary, so that the new version of CC mode can be installed.

After things are "ready", we should begin formal pretest.
During that time, we just fix bugs that people report.
When the reported bugs are fixed, we make a new pretest.
When a pretest works well enough, we make a release.

Re: Release timelines and Unicode2 branch

[Romain Francoise]

"Chong Yidong" <cyd@stupidchicken.com> writes:

> (2) Fix recognition of shell's `dirs' command.

I've just installed a fix for this problem.

-- 
Romain Francoise <romain@orebokech.com> | I just thought I'd go out
it's a miracle -- http://orebokech.com/ | with a little bit more style.

Re: Release timelines and Unicode2 branch

[Adrian Robert]

On Sep 12, 2005, at 3:35 PM, Stefan Monnier wrote:

> OTOH if the work can be expected to take in the order of a few  
> months only
> (i.e. a large part of the work you've done on 20.7 can be reused  
> with little
> or no changes), it would also make sense to start from the current  
> HEAD (to
> be 22.1).

My best guess from past experience is I'll have an initial version  
out this fall, but to fill in holes and generally get things up to  
production status will take a further year.

Re: Release timelines and Unicode2 branch

[Miles Bader]

2005/9/13, Adrian Robert <arobert@cogsci.ucsd.edu>:
> And how stable / bug-free is unicode-2
> right now compared with the will-become-22.1 code?

I use unicode-2 as my "secondary" emacs, and it seems pretty stable,
more or less identical to the trunk.  The main problems I've had seem
to mostly be related to font selection, e.g., where unicode-2 will
choose a worse X font to display a character than the trunk would
have; however I presume in your case you probably will not use the X
font selection code anyway.

> What I'm getting
> at is, is it reasonable to port Emacs-on-Aqua to this branch now, or
> should I stick with the to-be-22.1 code

If the unicode-2 branch would make your job much easier, I think going
with the branch would be a perfectly reasonable thing to do.

> or perhaps just wait before starting anything?

I see no particular reason to wait; my impression is that
by-and-large, the unicode-2 branch is not going to change
dramatically.  Kenichi can give a more knowledgable answer however.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Release timelines and Unicode2 branch

[Nick Roberts]

Miles Bader writes:
 > I use unicode-2 as my "secondary" emacs, and it seems pretty stable,
 > more or less identical to the trunk.

and

 >                                     my impression is that
 > by-and-large, the unicode-2 branch is not going to change
 > dramatically.

That does beg the question as to why unicode-2 hasn't already been merged into
HEAD given that, using timescales for Emacs 22, Emacs 23 won't be released
until about 2010.

Nick

Re: Release timelines and Unicode2 branch

[Miles Bader]

2005/9/13, Nick Roberts <nickrob@snap.net.nz>:
>  >                                     my impression is that
>  > by-and-large, the unicode-2 branch is not going to change
>  > dramatically.
> 
> That does beg the question as to why unicode-2 hasn't already been merged into
> HEAD given that, using timescales for Emacs 22

Er, well guessing what you meant[*], it seems a reasonable enough
thing to do -- I'm referring to _fundamental_ changes in
representations, etc.  I think _those_ are unlikely to change, but
nevertheless the unicode branch still is different enough from the
trunk that merging it would probably cause a fair number of bugs.

I think that such bugs would be minor enough that using the branch for
development of something like Aqua Emacs is quite reasonable (such
minor bugs probably wouldn't significantly affect the work on the Aqua
backend, and subsequent bug-fixes would likely be straight-forward to
merge), but they would unnecessarily delay a trunk release.

[*] as you seemed to have used the phrase "beg the question"
incorrectly -- it means "makes the question pointless"

-miles
-- 
Do not taunt Happy Fun Ball.

Re: Release timelines and Unicode2 branch

[David Kastrup]

Nick Roberts <nickrob@snap.net.nz> writes:

> Miles Bader writes:
>  > I use unicode-2 as my "secondary" emacs, and it seems pretty stable,
>  > more or less identical to the trunk.
>
> and
>
>  >                                     my impression is that
>  > by-and-large, the unicode-2 branch is not going to change
>  > dramatically.
>
> That does beg the question as to why unicode-2 hasn't already been
> merged into HEAD given that, using timescales for Emacs 22, Emacs 23
> won't be released until about 2010.

So that Emacs 22 will not get released only in 2010.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Release timelines and Unicode2 branch

[Nick Roberts]

 > > That does beg the question as to why unicode-2 hasn't already been
 > > merged into HEAD given that, using timescales for Emacs 22, Emacs 23
 > > won't be released until about 2010.
 > 
 > So that Emacs 22 will not get released only in 2010.

The description Miles gave suggested that unicode-2 was already usable.  The
plan, as I understand it, is to merge unicode-2 to HEAD immediately after
Emacs 22 is released.  It will then presumably sit in CVS for years while a
myriad of other features are added.

Nick

Re: Release timelines and Unicode2 branch

[David Kastrup]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > > That does beg the question as to why unicode-2 hasn't already been
>  > > merged into HEAD given that, using timescales for Emacs 22, Emacs 23
>  > > won't be released until about 2010.
>  > 
>  > So that Emacs 22 will not get released only in 2010.
>
> The description Miles gave suggested that unicode-2 was already
> usable.  The plan, as I understand it, is to merge unicode-2 to HEAD
> immediately after Emacs 22 is released.  It will then presumably sit
> in CVS for years while a myriad of other features are added.

We have been through this already.  The major features are unicode-2
and multi-tty support.  There are some updates from external packages
like tramp that have been held back from the code base, but nothing
really Earth-shattering.

It sounds like a month of merging should get us through the worst, and
then not too much cleaning up should be necessary: the branches we are
talking about are in active use.

That is the exact decision why we have already agreed _not_ to merge
the bidi branch at that time.  Even though it obviously forms a
logical complement to unicode-2, its state of maturity is not
comparable.

Can we just concentrate on Emacs 22 before going bonkers over Emacs 23
_again_?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Release timelines and Unicode2 branch

[Ralf Angeli]

* Nick Roberts (2005-09-13) writes:

>  > > That does beg the question as to why unicode-2 hasn't already been
>  > > merged into HEAD given that, using timescales for Emacs 22, Emacs 23
>  > > won't be released until about 2010.
>  > 
>  > So that Emacs 22 will not get released only in 2010.
>
> The description Miles gave suggested that unicode-2 was already usable.

That depends on your definition of "usable".  Last time I tried the
unicode-2 branch it felt significantly slower than a trunk build,
observable e.g. during line-by-line scrolling.  The slowdown was big
enough for me to stick with a trunk build.

-- 
Ralf

Re: Release timelines and Unicode2 branch

[Adrian Robert]

Thanks all for the info; I'll start examining the unicode-2 code..

-Adrian

Re: Release timelines and Unicode2 branch

[Richard M. Stallman]

    > What I'm getting
    > at is, is it reasonable to port Emacs-on-Aqua to this branch now, or
    > should I stick with the to-be-22.1 code

    If the unicode-2 branch would make your job much easier, I think going
    with the branch would be a perfectly reasonable thing to do.

To release this code in a modified version, which runs only on
a non-free system, would be deleterious to the goals of the GNU Project.
Please don't ever suggest such a thing to anyone.

Re: Release timelines and Unicode2 branch

[Stefan Monnier]

>> What I'm getting
>> at is, is it reasonable to port Emacs-on-Aqua to this branch now, or
>> should I stick with the to-be-22.1 code

>     If the unicode-2 branch would make your job much easier, I think going
>     with the branch would be a perfectly reasonable thing to do.

> To release this code in a modified version, which runs only on
> a non-free system, would be deleterious to the goals of the GNU Project.
> Please don't ever suggest such a thing to anyone.

IIUC Adrian Robert works mainly on the GNUstep version, which is free and
runs on free systems.


        Stefan

Re: Release timelines and Unicode2 branch

[Richard M. Stallman]

    IIUC Adrian Robert works mainly on the GNUstep version, which is free and
    runs on free systems.

He was talking about "Emacs for Aqua".
Isn't Aqua the name of a version of MacOS?

Re: Release timelines and Unicode2 branch

[Adrian Robert]

On Sep 13, 2005, at 12:25 PM, Stefan Monnier wrote:

>>> What I'm getting
>>> at is, is it reasonable to port Emacs-on-Aqua to this branch now, or
>>> should I stick with the to-be-22.1 code
>>>
>
>
>>     If the unicode-2 branch would make your job much easier, I  
>> think going
>>     with the branch would be a perfectly reasonable thing to do.
>>
>
>
>> To release this code in a modified version, which runs only on
>> a non-free system, would be deleterious to the goals of the GNU  
>> Project.
>> Please don't ever suggest such a thing to anyone.
>>
>
> IIUC Adrian Robert works mainly on the GNUstep version, which is  
> free and
> runs on free systems.

That's correct -- or actually the GNUstep "version" and the OS X one  
are the same code, with a few ifdefs here and there.  The APIs  
provided by GNUstep and Cocoa are almost identical (or at least  
largely overlapping; please see http://gnustep.org for more  
explanation)  The new port (emacs-app.sf.net) should always run, like  
Emacs-on-Aqua, on GNUstep _and_ OS X.  (The "-on-Aqua" name is a  
historical artifact that does not reflect the port's actual character.)

To ease development of the upcoming Emacs.app, I do intend to host  
and distribute the code, including both the GNU Emacs core and the  
port code, from SourceForge (emacs-app.sf.net).  However contributors  
will be limited to those willing to (a) preserve GNUstep  
functionality (as opposed to adding code which uses Cocoa-only APIs  
and making it run only on OS X), and (b) assign copyright to the FSF,  
so that an eventual integration can be achieved.  If/when that day  
comes, hosting on SourceForge will cease.

If someone would prefer some alternative (e.g., using 'arch' in some  
funky way), please let me know.  I'm just assuming no one is going to  
want the Cocoa/GNUstep code anywhere near the main Emacs tree itself  
until it's quite stable.

-Adrian

Re: Release timelines and Unicode2 branch

[Stefan Monnier]

> If someone would prefer some alternative (e.g., using 'arch' in some funky
> way), please let me know.  I'm just assuming no one is going to want the
> Cocoa/GNUstep code anywhere near the main Emacs tree itself until it's
> quite stable.

As far as I'm concerned, I wouldn't mind seeing it added to the
emacs-unicode branch before it's "quite stable", as long as it doesn't
impact the rest of the code (i.e. those who use it, do it at their own risk,
while those who don't will not be affected).


        Stefan

Re: Release timelines and Unicode2 branch

[Richard M. Stallman]

    That's correct -- or actually the GNUstep "version" and the OS X one  
    are the same code, with a few ifdefs here and there.  The APIs  
    provided by GNUstep and Cocoa are almost identical (or at least  
    largely overlapping; please see http://gnustep.org for more  
    explanation)  The new port (emacs-app.sf.net) should always run, like  
    Emacs-on-Aqua, on GNUstep _and_ OS X.  (The "-on-Aqua" name is a  
    historical artifact that does not reflect the port's actual character.)

Could we please rename it, then?  Let's call it Emacs for GNUstep.
It is counterproductive to publicize Apple gratuitously.

Re: Release timelines and Unicode2 branch

[Adrian Robert]

On Sep 15, 2005, at 9:00 AM, Richard M. Stallman wrote:

>     That's correct -- or actually the GNUstep "version" and the OS X 
> one
>     are the same code, with a few ifdefs here and there.  The APIs
>     provided by GNUstep and Cocoa are almost identical (or at least
>     largely overlapping; please see http://gnustep.org for more
>     explanation)  The new port (emacs-app.sf.net) should always run, 
> like
>     Emacs-on-Aqua, on GNUstep _and_ OS X.  (The "-on-Aqua" name is a
>     historical artifact that does not reflect the port's actual 
> character.)
>
> Could we please rename it, then?  Let's call it Emacs for GNUstep.
> It is counterproductive to publicize Apple gratuitously.

The new name was going to be simply "Emacs.app", which is OS neutral 
(but OpenStep specific).  I prefer a neutral name to avoid throwing off 
potential Apple users, because I'll need the interest and help of the 
Cocoa / Apple community to make this port work.

The GNUstep community is very small (albeit undeservedly so), but a 
quality Emacs port that makes people want to run GNUstep so they can 
use it could help it grow.  If Apple users testing and helping with 
development can make this happen, I think it would be worth the 
ancillary costs of publicity for and enhancement of the non-free OS X 
platform.

What about a compromise, like "Emacs.app for GNUstep and OS X" (on 
every web page and release announcement), with short name simply 
"Emacs.app"?

Re: Release timelines and Unicode2 branch

[David Kastrup]

Adrian Robert <arobert@cogsci.ucsd.edu> writes:

> On Sep 15, 2005, at 9:00 AM, Richard M. Stallman wrote:
>
>>     That's correct -- or actually the GNUstep "version" and the OS X
>> one
>>     are the same code, with a few ifdefs here and there.  The APIs
>>     provided by GNUstep and Cocoa are almost identical (or at least
>>     largely overlapping; please see http://gnustep.org for more
>>     explanation)  The new port (emacs-app.sf.net) should always run,
>> like
>>     Emacs-on-Aqua, on GNUstep _and_ OS X.  (The "-on-Aqua" name is a
>>     historical artifact that does not reflect the port's actual
>> character.)
>>
>> Could we please rename it, then?  Let's call it Emacs for GNUstep.
>> It is counterproductive to publicize Apple gratuitously.
>
> The new name was going to be simply "Emacs.app", which is OS neutral
> (but OpenStep specific).  I prefer a neutral name to avoid throwing
> off potential Apple users, because I'll need the interest and help of
> the Cocoa / Apple community to make this port work.
>
> The GNUstep community is very small (albeit undeservedly so), but a
> quality Emacs port that makes people want to run GNUstep so they can
> use it could help it grow.  If Apple users testing and helping with
> development can make this happen, I think it would be worth the
> ancillary costs of publicity for and enhancement of the non-free OS X
> platform.
>
> What about a compromise, like "Emacs.app for GNUstep and OS X" (on
> every web page and release announcement), with short name simply
> "Emacs.app"?

I think "Emacs.app" is fine.  Web page and announcement will carry the
information for which operating systems Emacs.app is known to work in
their main text.

There are also things like View.app and similar, and people tend to
know what this implies, more or less.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Release timelines and Unicode2 branch

[Richard M. Stallman]

"Emacs.app" is a good name.  Mac users will recognize its relevance,
but it doesn't publicize Macintosh otherwise.

So let's use that.

Re: Release timelines and Unicode2 branch

[Steven Tamm]

Sorry to jump in late,
Emacs.app is the name of the bundle that contains the app.  On Mac OS  
X Finder and throughout the graphical interface the name appears as  
"Emacs".  Any build of emacs that is meant to be run from the Mac  
graphical interface should be called "Emacs".

Aqua = Name of the look and field of the Mac OS X windowing system.   
It is a description of the Theme of the Mac OS X.
Carbon = Name of the C interface to the Mac OS X windowing system.   
Based on Mac OS 9 APIs.
Cocoa = Name of the ObjC interface to the Mac OS X windowing system.   
Based on Next/OpenStep.  For the most part compatible with GNUStep.   
The incompatibilities are minor and mostly have to do with image  
rendering and font handling.

The name "emacs on aqua" is misleading and bad for technical reasons  
(it's like saying Emacs for Clearlooks).

The default build on mainline for Mac OS X is referred to as "Carbon"  
as distinct from the "X11" build.   But it's still "Emacs", as would  
a build based on GNUStep compiled under Cocoa.

As for the unicode branch, the way that unicode font handling is done  
on the Mac (ATSUI) is different from the old-style (Quickdraw) that  
is used in the Carbon port.    Quickdraw is based on MBTE and  
converting it to unicode is hard.  I've done some work on rewriting  
the text rendering to use ATSUI, but I ran into some performance  
problems due to the way that fonts and styles are handled in ATSUI .   
It would be easier to port a GNUStep based version to use utf8 in an  
efficient manner based on NSLayoutManager: but any GNUStep based  
version of Emacs will suffer from some pretty tricky threading issues  
due to Apple's strange implementation of menu handling.  It took a  
lot of effort to figure it out with Carbon.  Also, maintaining  
backwards compatibility of font spec's is nigh impossible.  But I  
haven't looked at the cocoa port of emacs in forever.

-Steven

On Sep 20, 2005, at 11:43 PM, Richard M. Stallman wrote:

> "Emacs.app" is a good name.  Mac users will recognize its relevance,
> but it doesn't publicize Macintosh otherwise.
>
> So let's use that.
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>

Re: Release timelines and Unicode2 branch

[Adrian Robert]

On Sep 22, 2005, at 2:03 AM, Steven Tamm wrote:

> As for the unicode branch, the way that unicode font handling is done 
> on the Mac (ATSUI) is different from the old-style (Quickdraw) that is 
> used in the Carbon port.    Quickdraw is based on MBTE and converting 
> it to unicode is hard.  I've done some work on rewriting the text 
> rendering to use ATSUI, but I ran into some performance problems due 
> to the way that fonts and styles are handled in ATSUI .  It would be 
> easier to port a GNUStep based version to use utf8 in an efficient 
> manner based on NSLayoutManager: but any GNUStep based version of 
> Emacs will suffer from some pretty tricky threading issues due to 
> Apple's strange implementation of menu handling.  It took a lot of 
> effort to figure it out with Carbon.  Also, maintaining backwards 
> compatibility of font spec's is nigh impossible.  But I haven't looked 
> at the cocoa port of emacs in forever.

Yup, been there and done that in the 20.7-based Emacs on Aqua (yes, bad 
name.. ;).  I used about 4-5 different text rendering methods at 
various times, and 3 or 4 of them are still in the code used in various 
situations.  The one used on OS X 10.3/10.4 uses ATSUI to obtain fonts, 
but little else.  Characters are passed as UTF-8 to a low-level API 
that NSLayoutManager itself uses.  Either Quartz or Quickdraw 
antialiasing can be used when actually rendering.

I also tried using a pure NSLayoutManager solution.  Very easy, and the 
huge win is that backup fonts are chosen automatically 
character-by-character to render glyphs that aren't in the main font.  
The backups are chosen to match the appearance of the main font as 
closely as possible.  In other words, automatic "fontset" handling for 
free.  The penalty is it was slow in the way that Emacs had to use it.  
Ordinarily, one throws the entire text of a buffer into the system, 
then tells it which parts to render.  With emacs, the core sends the 
rendering front end just the on-screen text (as emacs "glyphs"), so you 
keep having to reset the layout system with whatever new text gets 
sent.  Maybe there was a way to work around this, and we can 
investigate it when the time comes.  (An aside, many rendering method 
issues also related to needing to render characters in a grid on 
emacs-20, which of course changes on 21+...)

As for menu handling, the way it's done in Emacs-on-Aqua is not at all 
optimal.  A definite candidate for eventual rewrite, and maybe some of 
the Carbon code will prove useful there (not for the actual API calls, 
but the overall approach).

Re: Release timelines and Unicode2 branch

[Stefan Monnier]

> The default build on mainline for Mac OS X is referred to as "Carbon"  as
> distinct from the "X11" build.   But it's still "Emacs", as would  a build
> based on GNUStep compiled under Cocoa.

Before being integrated in the main code, the w32 code for Emacs was called
NTEmacs, and nowadays it's still common to hear people refer to a w32 of
Emacs as NTEmacs.  Similarly a Carbon build of Emacs is often referred to as
Carbon Emacs.  So it seems quite OK to name the project Emacs.app and this
name will probably stick even after it gets included in the
main distribution.


        Stefan

Re: Release timelines and Unicode2 branch

[Richard M. Stallman]

    Emacs.app is the name of the bundle that contains the app.  On Mac OS  
    X Finder and throughout the graphical interface the name appears as  
    "Emacs".  Any build of emacs that is meant to be run from the Mac  
    graphical interface should be called "Emacs".

That seems right.

We're discussing the name to give the distribution that people would
build to run this program.  "Emacs.app" seems to fit that.

Re: Release timelines and Unicode2 branch

[Richard M. Stallman]

    1) When is the best estimate of when 22.1 will come out?

I would estimate two months.  Of course, it could be longer.

    2) Is 22.1 being released off its own branch (instead of the head),  

No.

    3) How much significant unicode-2-specific work remains before that  
    branch becomes eligible for a release of its own?

Handa is the one who can answer that,