Emacs.app (Cocoa/GNUstep port) release and feature list

Emacs.app (Cocoa/GNUstep port) release and feature list

[Adrian Robert]

Hi,

Release 9.0-rc3 for the GNUstep and OS X / Cocoa port of the GNU Emacs
unicode-2 is available at http://emacs-app/sf.net

This release brings with it the multi-TTY merge (mixed GUI/TTY
sessions not yet supported though), and a number of bug fixes and
minor enhancements.  GNUstep support is untested for this release;
please contact me off-list if you have a GNUstep installation and are
willing to try it out.

In view of the prospects for upcoming merge into CVS, it was suggested
that a list of user-visible differences in this port from other
platforms be posted.  See below.  A couple of general points should be
noted:

- The general aim is to take advantage of platform-specific features
without compromising or altering anything in standard emacs
functionality.  It should support all non-platform-specific emacs lisp
packages -- if not it's a bug.

- Most of the features below are now supported as well by the Carbon
port, modulo differences in what is enabled or set by default.

- "Patch" files available on sourceforge allow easy inspection of just
the code that this port adds.


- Text rendering: Font anti-aliasing.

  This is standard on the OS X and GNUstep platforms.  Can be turned
off if desired.


- Text rendering: adjustable line height.

  Allows vertical compression or expansion of the display.  By default
it is inactive.


- Display: alpha and background image support.

  Frame backgrounds can be set to transparent colors and/or images.
Inactive by default.


- Keyboard handling: Support platform "Command" key as "Super".

  The Command key is an extra key on this platform relative to typical
X hardware.  Mapping it to Super and setting up appropriate
keybindings allows Emacs to support full CUA keybindings on these
systems without interfering with standard emacs Control and Meta
bindings.


- Keyboard handling: Support platform input methods and keyboard mappings.

  Equivalent to XIM support on X systems.


- Fontsets: Capability to autogenerate fontsets for a given base font.

  This takes advantage of platform-provided facilities.  It does not
have to be used; standard manually-defined fontsets are fully
supported, albeit via an X11-specific syntax.


- Menus: Prefer Super bindings in display of shortcuts.

  This causes display of CUA bindings, similar to other platform apps.


- Menus: Add "Emacs" and "Windows" menus.

  These are standard menus for all platform applications.  A couple of
entries on these are moved from other menus.


- Navigation: ns-mark-nav package for navigating the mark rings.

  User can move backwards or forwards through buffer or global mark
history with meta-p / meta-n.


- Customization: Use of 'defaults' persistent user preferences database.

  Takes the place of X resources on NS systems, called through the
same pathways (x_get_string_resource(), etc.), and used for similar
settings (mostly GUI-related).  As with X resources, these may be
overridden by .emacs and other lisp-based methods.


- Customization: Font panel for default font and size selection.

  This feature allows user to select font via a system-provided
chooser.  It exists also in the Carbon and W32 ports, and maybe (?)
the GTK/Xft port.  Does not interfere with ordinary face-customization
setting of fonts, just provides an alternate route.


- Customization: Color panel for face color customization.

  This feature has no equivalent on other systems, but need not be
used and does not interfere with standard means of color
customization.  User may drag from a color-selection panel to
characters in an emacs frame to change color of face at that point.


- Customization: Preferences panel for major GUI settings.

  This feature has no equivalent on other systems, but need not be
used and does not interfere with standard means of customization.
Backed by lisp-accessible variables and persisted via the X resources
equivalent.


- Integration: Services integration.

  "Services" on NS platforms provide for inter-application
communication.  The Emacs.app implementation currently exposes
services from other apps to Emacs, via both menus and lisp functions.


- Integration: Respond to Workspace requests.

  Files can be associated to Emacs.app and opened within it by
double-clicking (new instance started only if one not running),
similar to emacsclient but tied to the OS file browser.  Note this
does not replace emacsclient, which remains bundled with Emacs.app and
functions correctly on these systems.


- Integration: drag/drop of files and text.

  Text or file dragged to an emacs window is inserted; file dragged to
application icon opened in new buffer.


- Integration: ns-grab-env function and macFixEnv binary tool.

  These deal with a platform-specific issue in which the PATH value
given to the application started from the Workspace (rather than
command line) may not be what is expected.


- File system: Open and Save file GUI panels are available.

  These are bound to menu operations and 'super' keybindings.  They do
not take the place of standard minibuffer- and dired-based Emacs
file-finding mechanisms, and no existing keybindings are overridden.



cheers,
Adrian

Re: Emacs.app (Cocoa/GNUstep port) release and feature list

[David Reitter]

Adrian,

thanks for working on the port - one can tell that there has been a  
lot of progress.

A couple of comments.

In general: do you support the established Mac specific customization  
variables? In particular:

> - Keyboard handling: Support platform "Command" key as "Super".

Is this a default, and can it be changed using `mac-command-modifier'?
While your default is good (similar to what we have in Aquamacs, after  
all), I know that a lot of users like to configure Command to be Meta,  
especially when using keyboard layouts that require the use of the  
Option key to type things like curly brackets, the backlash or @ sign.

> - Customization: Preferences panel for major GUI settings.
>
>  This feature has no equivalent on other systems, but need not be
> used and does not interfere with standard means of customization.
> Backed by lisp-accessible variables and persisted via the X resources
> equivalent.

There is no way to customize these dialogs via Lisp, i.e. add new  
options?
While I find the UI approach very good, I think that a lack of  
interaction with the Lisp side of things would be rather un-Emacs-like.

Secondly, why introduce yet another system to store (rather than just  
load) Emacs-specific configuration variables?
There  is `custom-file', and users can edit their .emacs.

What do you do when settings conflict?

A couple of other questions w.r.t. known problems with the Carbon port:

- does your port run from anywhere in the system like any good  
application? The current Carbon port (including 22.1) crashes when  
started from directories with non-7-bit ASCII path names, such as / 
Applications/Développement/

- does your port play nice with multi-screen setups, especially when  
screens are of different size? The Carbon port doesn't.

- does your port take care to not open frames underneath the Dock (or  
otherwise) or enlarge them too much when changing font sizes?  
(Aquamacs / Carbon has trouble with this at the moment)

Best
- David

PS.: I can't run rc3 on my 10.5.1. machine. It quits immediately. If  
you need more info, let me know.

Re: Emacs.app (Cocoa/GNUstep port) release and feature list

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 23 Nov 2007 14:56:32 +0000, David Reitter <david.reitter@gmail.com> said:

> A couple of other questions w.r.t. known problems with the Carbon
> port:

> - does your port run from anywhere in the system like any good
> application? The current Carbon port (including 22.1) crashes when
> started from directories with non-7-bit ASCII path names, such as /
> Applications/Développement/

> - does your port play nice with multi-screen setups, especially when
> screens are of different size? The Carbon port doesn't.

As I said before, they are platform-independent problems.  I don't
think it's a good idea to work around them in a platform-specific way.

> - does your port take care to not open frames underneath the Dock
> (or otherwise) or enlarge them too much when changing font sizes?
> (Aquamacs / Carbon has trouble with this at the moment)

Cocoa seems to handle such situations automatically by default.
Actually, the Carbon+AppKit port handles them.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Emacs.app (Cocoa/GNUstep port) release and feature list

[Stefan Monnier]

Thanks Adrian.  It all sounds pretty good.  Except:

> - Keyboard handling: Support platform "Command" key as "Super".

>   The Command key is an extra key on this platform relative to typical
> X hardware.  Mapping it to Super and setting up appropriate
> keybindings allows Emacs to support full CUA keybindings on these
> systems without interfering with standard emacs Control and Meta
> bindings.

I hope that this is customizable for people such as myself who are more
familiar with Emacs than CUA and who find Apple's command and alt keys
a bit too small and tend to have trouble hitting one of them rather than
other and prefer to map them both to `meta'.

> - Menus: Prefer Super bindings in display of shortcuts.
>   This causes display of CUA bindings, similar to other platform apps.

And of course, if the command->Super mapping is not used, these Super
bindings should not appear in the menus (tho it wouldn't matter much
for me).

I looked at the sourceforge page and I couldn't find the sources in
the CVS.  Are you using a revision control system?  If not, why not, and
especially why not just put it all in Emacs's CVS repository?  If yes,
where is it?


        Stefan

Re: Emacs.app (Cocoa/GNUstep port) release and feature list

[Adrian Robert]

> In general: do you support the established Mac specific customization
> variables? In particular:
>
> > - Keyboard handling: Support platform "Command" key as "Super".
>
> Is this a default, and can it be changed using `mac-command-modifier'?

The Cocoa port has "ns-command-modifier", the difference relating to
Mac-and-GNUstep vs. Mac-only -- but there's no reason the Cocoa port
can't add aliases that are more intuitive or follow conventions on the
Mac.



> > - Customization: Preferences panel for major GUI settings.
>
> There is no way to customize these dialogs via Lisp, i.e. add new
> options?
> While I find the UI approach very good, I think that a lack of
> interaction with the Lisp side of things would be rather un-Emacs-like.

They are completely optional.  .emacs settings take precedence in conflicts.



> Secondly, why introduce yet another system to store (rather than just
> load) Emacs-specific configuration variables?
> There  is `custom-file', and users can edit their .emacs.

It's just easier/quicker to use (in some people's opinion).
Personally I use customize and direct .emacs editing a lot, but for
quick UI customization still prefer the prefs dialog, font panel,
etc..



> - does your port run from anywhere in the system like any good
> application? The current Carbon port (including 22.1) crashes when
> started from directories with non-7-bit ASCII path names, such as /
> Applications/Développement/

A quick check here revealed no problems, maybe it's a difference from
the unicode branch..



> - does your port play nice with multi-screen setups, especially when
> screens are of different size? The Carbon port doesn't.

There were a couple of bugs with new frame creation and popup menus
but these have been fixed.  Could be other problems, I haven't really
tried w/diff sizes.



> - does your port take care to not open frames underneath the Dock (or
> otherwise) or enlarge them too much when changing font sizes?
> (Aquamacs / Carbon has trouble with this at the moment)

This was improved with the rc3 release.  The questionable cases that
remain are those where it's hard to choose one behavior over another.



> PS.: I can't run rc3 on my 10.5.1. machine. It quits immediately. If
> you need more info, let me know.

It would be great if you could send whatever info you can here (crash
log, gdb backtrace).  I don't have access to any Leopard machines,
probably won't for a while, but if it's something obvious from the
logs I can fix it.

Re: Emacs.app (Cocoa/GNUstep port) release and feature list

[Adrian Robert]

> > - Keyboard handling: Support platform "Command" key as "Super".

> I hope that this is customizable for people such as myself who are more
> familiar with Emacs than CUA and who find Apple's command and alt keys
> a bit too small and tend to have trouble hitting one of them rather than
> other and prefer to map them both to `meta'.

This is supported.


> > - Menus: Prefer Super bindings in display of shortcuts.
> >   This causes display of CUA bindings, similar to other platform apps.
>
> And of course, if the command->Super mapping is not used, these Super
> bindings should not appear in the menus (tho it wouldn't matter much
> for me).

This seems reasonable from a user perspective, and I was thinking of
making this a customizable setting.  Autodetermining based on modifier
setting is another possibility.  Neither is straightforward owing to
the fact the displayed menu key shortcuts are precomputed.


> I looked at the sourceforge page and I couldn't find the sources in
> the CVS.  Are you using a revision control system?  If not, why not, and
> especially why not just put it all in Emacs's CVS repository?  If yes,
> where is it?

This port maintained its own CVS for a while, but that was messing up
existing tags in emacs files and also making syncing with emacs CVS
difficult.  I know there are git and arch alternatives here, but
Richard has said he is OK with bringing this into the trunk after the
unicode merge and that seems like the best route for maintenance.  (A
branch is another possibility but that still leaves an ongoing merge
burden.)

Re: Emacs.app (Cocoa/GNUstep port) release and feature list

[Stefan Monnier]

> This port maintained its own CVS for a while, but that was messing up
> existing tags in emacs files and also making syncing with emacs CVS
> difficult.  I know there are git and arch alternatives here, but
> Richard has said he is OK with bringing this into the trunk after the
> unicode merge and that seems like the best route for maintenance.  (A
> branch is another possibility but that still leaves an ongoing merge
> burden.)

I think it would be good to add it as a branch in the CVS.  It won't add
any "merge burden" that isn't already present.  And it will make it easier
to keep them synchronized, to compare them, etc...


        Stefan

Re: Emacs.app (Cocoa/GNUstep port) release and feature list

[CHENG Gao]

*On Fri, 23 Nov 2007 11:24:51 -0500
* Also sprach Stefan Monnier <monnier@iro.umontreal.ca>:

> I think it would be good to add it as a branch in the CVS.  It won't add
> any "merge burden" that isn't already present.  And it will make it easier
> to keep them synchronized, to compare them, etc...

If I understand not wrongly, this new release contains patchs to
emacs-unicode-2 branch source, and its platform-specific files reside
all in nextstep/ dir. Since I trust the patchs are for building on
MacOSX/Nextstep and wont hurt building of any other platforms, maybe a
new branch is not needed - patches can be committed directly to
emacs-unicode-2 branch and nextstep/ dir be added directly.

And thank you Adrian for your efforts. I wish this port can be merged
the soonest thus it can be tested the earliest by the greatest part of
MacOSX (& NextStep users). 

 
-- 
Vivere est cogitare

Re: Emacs.app (Cocoa/GNUstep port) release and feature list

[Dan Nicolaescu]

"Adrian Robert" <adrian.b.robert@gmail.com> writes:

  > Hi,
  > 
  > Release 9.0-rc3 for the GNUstep and OS X / Cocoa port of the GNU Emacs
  > unicode-2 is available at http://emacs-app/sf.net
  > 
  > This release brings with it the multi-TTY merge (mixed GUI/TTY
  > sessions not yet supported though), and a number of bug fixes and
  > minor enhancements.  GNUstep support is untested for this release;
  > please contact me off-list if you have a GNUstep installation and are
  > willing to try it out.
  > 
  > In view of the prospects for upcoming merge into CVS, it was suggested
  > that a list of user-visible differences in this port from other
  > platforms be posted.  See below.  A couple of general points should be
  > noted:

Thanks for doing this!

Here are a few observations from quickly scanning the code: 

In loadup.el:

(if (featurep 'ns-windowing)
              ^^^^^^^
              Some better name here? There's no identifier in emacs that
              contains "windowing"

    (progn
      (load "emacs-lisp/easymenu")
      (load "emacs-lisp/easy-mmode")
      (load "view")
      (load "help-mode")
      (load "help-fns")
      (load "emacs-lisp/advice")
      (load "ns-mark-nav")
      (load "paren")

Are these acceptable to be preloaded in platform specific code? IMHO no.

These files: 

 lisp/erc/erc-nicklist.el           |only
 lisp/net/tramp-util.el             |only
 lisp/net/tramp-vc.el               |only
 lisp/tumme.el                      |only
 src/s/umips.h                      |only

have been deleted from Emacs CVS

 lisp/mic-paren.el                  |only

This is unrelated to the port, either submit separately or drop it.

 lisp/ns-grabenv.el                 |only

Doesn't the Carbon port have the same problem that this file tries to
solve? Does GNUstep have this problem? Is the ns-* name appropriate
then?

 lisp/ns-mark-nav.el                |only

This does not seem to be specific to the port, why not submit is separately?

 lisp/term/ns-win.el

   The functions/variables in here should either be called ns-* or x-*
   
   (setq transient-mark-mode t
   This needs to be a function call, not setq
   
         highlight-nonselected-windows nil
   Already the default
         delete-selection-mode t
   As above
   
         search-highlight t
         query-replace-highlight t
         split-window-keep-point t
   All are already the default
         mouse-copy-selection nil
   Non-existent variable
         frame-title-format t
         icon-title-format t)
   These might be incorrect
   
   (mouse-wheel-mode 1)
   Already done by default.
   
   Are the deffaces really needed in this file?
   

I think you posted the changes to lisp/progmodes/cc-*.el to this
list. What keeps them from being checked in CVS? They are not related to
this port, just unnecessary overhead for you...
   

The comments in the ns*.m files use both // and /**/. Why not
standardize on /**/? That would make the sources consistent with the
rest of emacs, and it would be easier to move code from .m files to .c
files (if it's ever needed). 

The new #defines: HAVE_NS GNUSTEP COCOA COCOA_EXPERIMENTAL_CTRL_G

Why not HAVE_GNUSTEP and HAVE_COCOA too? 

Also it seems that !GNUSTEP is the same as COCOA. Why not just use one
of them?

Don't do any #ifdef MULTI_KBOARD, just assume it is always defined.

Can the icons be shared with the Carbon port?

Is the nextstep/compile script really needed? Wouldn't 
./configure && make 
work on this platform?

You probably know RMS won't allow this code to be checked in without
proper ChangeLogs...


I hope this helps.

            --dan

Re: Emacs.app (Cocoa/GNUstep port) release and feature list

[Adrian Robert]

On 11/24/07, Dan Nicolaescu <dann@ics.uci.edu> wrote:

>     (progn
>       (load "emacs-lisp/easymenu")
>       (load "emacs-lisp/easy-mmode")
>       (load "view")
>       (load "help-mode")
>       (load "help-fns")
>       (load "emacs-lisp/advice")
>       (load "ns-mark-nav")
>       (load "paren")
>
> Are these acceptable to be preloaded in platform specific code? IMHO no.

Could you elaborate on this?  These are loaded because setup in ns-win
needs them.    Is there some detrimental effect in loading them now
that ns-win must be loaded pre-dump?



>  lisp/mic-paren.el                  |only
>
> This is unrelated to the port, either submit separately or drop it.

Will do so.



>  lisp/ns-grabenv.el                 |only
>
> Doesn't the Carbon port have the same problem that this file tries to
> solve? Does GNUstep have this problem? Is the ns-* name appropriate
> then?

You are right this solves a problem mainly encountered on the Mac
platform for the Cocoa port.  However it currently names all its
functions with the "ns-" prefix, so it seemed inappropriate to use
"mac-".  It could also have some use on GNUstep or other platforms if
the user edits his/her .cshrc after starting emacs.  So theoretically
it could be added to emacs core lisp functionality, but I would
recommend to extend it to work on Windows as well first.



>  lisp/ns-mark-nav.el                |only
>
> This does not seem to be specific to the port, why not submit is separately?

It is generic functionality, it could be submitted separately if it is
of interest.



>  lisp/term/ns-win.el
>
>    The functions/variables in here should either be called ns-* or x-*

OK.




>    Are the deffaces really needed in this file?

ns-working-text-face is needed.  paren-face-match-light will be
removed along with mic-paren when/if a merge becomes imminent.



> I think you posted the changes to lisp/progmodes/cc-*.el to this
> list. What keeps them from being checked in CVS? They are not related to
> this port, just unnecessary overhead for you...

They are still not accepted by the maintainer yet.  If they get
accepted I can take them out.  Otherwise I feel they should at least
be bundled as part of the port, because Objective-C is the primary
development language for both Mac and GNUstep.



> The new #defines: HAVE_NS GNUSTEP COCOA COCOA_EXPERIMENTAL_CTRL_G
>
> Why not HAVE_GNUSTEP and HAVE_COCOA too?

HAVE_XX seems to be standard for the overall windowing system / port
being used: HAVE_XWINDOWS, HAVE_NTGUI.  GNUSTEP and COCOA are platform
indicators, like DARWIN, MAC_OS8, GNU_LINUX, or VMS.  I would use
"MAC_OSX" instead of COCOA, but that is already used by the Carbon
port to mean essentially HAVE_CARBONGUI.



> Also it seems that !GNUSTEP is the same as COCOA. Why not just use one
> of them?

I'm fine to make this change if people think it's easier to read.



> Don't do any #ifdef MULTI_KBOARD, just assume it is always defined.

I don't understand this.  There is lots of #ifdef MULTI_KEYBOARD in
the emacs code.



> Can the icons be shared with the Carbon port?

Emacs.app does not include any icons.  Unless you're talking about the
main app icon.  For now I think it's best to use a different one, so
users know which version they are running.



> Is the nextstep/compile script really needed? Wouldn't
> ./configure && make
> work on this platform?

With a little work it would not be needed.  It is there to pick up
environment variable settings (GNUstep) and to complete packaging
operations into the .app (both platforms).  it also makes building
easier for end users, because this port is distributed directly right
now to the user community.



> You probably know RMS won't allow this code to be checked in without
> proper ChangeLogs...

There is nextstep/ChangeLog reflecting everything during my
maintainership period.  I don't think anything from the years previous
to that will be available.


> I hope this helps.

Thanks much for this feedback.


Adrian

Re: Emacs.app (Cocoa/GNUstep port) release and feature list

[William Xu]

"Adrian Robert" <adrian.b.robert@gmail.com> writes:

> - Integration: drag/drop of files and text.
>
>   Text or file dragged to an emacs window is inserted; file dragged to
> application icon opened in new buffer.

It seems to me there's no need to distinguish them, as inserting is far
less common. At least carbon emacs doesn't. Any other emacs version that
distinguishes them?

-- 
William

http://williamxu.net9.org

Re: Emacs.app (Cocoa/GNUstep port) release and feature list

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 24 Nov 2007 20:37:07 +0900, William Xu <william.xwl@gmail.com> said:

> "Adrian Robert" <adrian.b.robert@gmail.com> writes:
>> - Integration: drag/drop of files and text.
>> 
>> Text or file dragged to an emacs window is inserted; file dragged
>> to application icon opened in new buffer.

> It seems to me there's no need to distinguish them, as inserting is
> far less common. At least carbon emacs doesn't. Any other emacs
> version that distinguishes them?

The Carbon(+AppKit) port does distinguish them, but the default
behaviors just look the same.  Files dropped into the application icon
are always opened by `dnd-open-local-file'.  Files dropped into an
Emacs frame are passed to `dnd-handle-one-url' like other platforms so
users/major modes can customize the drag-and-drop behavior in a
platform-independent way.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Emacs.app (Cocoa/GNUstep port) release and feature list

[Dan Nicolaescu]

"Adrian Robert" <adrian.b.robert@gmail.com> writes:

  > On 11/24/07, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > >     (progn
  > >       (load "emacs-lisp/easymenu")
  > >       (load "emacs-lisp/easy-mmode")
  > >       (load "view")
  > >       (load "help-mode")
  > >       (load "help-fns")
  > >       (load "emacs-lisp/advice")
  > >       (load "ns-mark-nav")
  > >       (load "paren")
  > >
  > > Are these acceptable to be preloaded in platform specific code? IMHO no.
  > 
  > Could you elaborate on this?  These are loaded because setup in ns-win
  > needs them.    Is there some detrimental effect in loading them now
  > that ns-win must be loaded pre-dump?

We are trying to minimize the number of files preloaded, if you look in
loadup.el no other platform loads these files, you'd need to justify the
need to load them.

emacs-lisp/advice will 100% be rejected, if you need different
functionality, just change the function, not advice it.

  > >  lisp/ns-grabenv.el                 |only
  > >
  > > Doesn't the Carbon port have the same problem that this file tries to
  > > solve? Does GNUstep have this problem? Is the ns-* name appropriate
  > > then?
  > 
  > You are right this solves a problem mainly encountered on the Mac
  > platform for the Cocoa port.  

Are you saying that the Carbon port does not have to deal with this issue.

  > However it currently names all its functions with the "ns-" prefix,
  > so it seemed inappropriate to use "mac-".  It could also have some
  > use on GNUstep or other platforms if the user edits his/her .cshrc
  > after starting emacs.  

That is a generic problem then, just post it here separately and see if
it will get included.

  > >  lisp/ns-mark-nav.el                |only
  > >
  > > This does not seem to be specific to the port, why not submit is separately?
  > 
  > It is generic functionality, it could be submitted separately if it is
  > of interest.

Please do that then.

  > >  lisp/term/ns-win.el
  > 
  > >    Are the deffaces really needed in this file?
  > 
  > ns-working-text-face is needed.  paren-face-match-light will be
  > removed along with mic-paren when/if a merge becomes imminent.

That's not very productive for the people reviewing this code: if
something won't be included, then drop it and keep it as local
customization, it won't force unnecessary extra work on people trying to
help with the merge.

BTW, I just noticed this: 
(makunbound 'yank-menu-length)
(defcustom yank-menu-length 40

Use customize-set-variable instead. But even that would need
justification for changing a default in a platform specific file.


  > > I think you posted the changes to lisp/progmodes/cc-*.el to this
  > > list. What keeps them from being checked in CVS? They are not related to
  > > this port, just unnecessary overhead for you...
  > 
  > They are still not accepted by the maintainer yet.  If they get
  > accepted I can take them out.  Otherwise I feel they should at least
  > be bundled as part of the port, because Objective-C is the primary
  > development language for both Mac and GNUstep.

Were the changes not reviewed or not accepted at all? If the former, I'd
advice you repost them here, CCing RMS. In general he keeps track of
submitted patches.

  > > The new #defines: HAVE_NS GNUSTEP COCOA COCOA_EXPERIMENTAL_CTRL_G
  > >
  > > Why not HAVE_GNUSTEP and HAVE_COCOA too?
  > 
  > HAVE_XX seems to be standard for the overall windowing system / port
  > being used: HAVE_XWINDOWS, HAVE_NTGUI.  GNUSTEP and COCOA are platform
  > indicators, like DARWIN, MAC_OS8, GNU_LINUX, or VMS.  

IMHO it is much cleaner to use the HAVE_ prefix for new code. Besides
COCOA is not such a widely known term for the people that work on
emacs...

  > I would use "MAC_OSX" instead of COCOA, but that is already used by
  > the Carbon port to mean essentially HAVE_CARBONGUI.

That sounds very confusing!

  > > Also it seems that !GNUSTEP is the same as COCOA. Why not just use one
  > > of them?
  > 
  > I'm fine to make this change if people think it's easier to read.

Yeah, the least amount of identifiers that one has to learn the meaning
for, the better.

  > > Don't do any #ifdef MULTI_KBOARD, just assume it is always defined.
  > 
  > I don't understand this.  There is lots of #ifdef MULTI_KEYBOARD in
  > the emacs code.

For historic reasons, and it is only needed in multi-platform code. Only
the DOS port still needs !MULTI_KBOARD.

The Cocoa port defines MULTI_KBOARD unconditionally, so there's no need
to deal with it in platform specific code, it's just noise.

  > > Can the icons be shared with the Carbon port?
  > 
  > Emacs.app does not include any icons.  Unless you're talking about the
  > main app icon.  For now I think it's best to use a different one, so
  > users know which version they are running.

On X11, we don't have different icons for running with different
toolkits...

  > > Is the nextstep/compile script really needed? Wouldn't
  > > ./configure && make
  > > work on this platform?
  > 
  > With a little work it would not be needed.  

It would be great to not have to have different build instructions for
different platforms. But that might be done after the merge too. You
might want to consult RMS on this.

  > > You probably know RMS won't allow this code to be checked in without
  > > proper ChangeLogs...
  > 
  > There is nextstep/ChangeLog reflecting everything during my
  > maintainership period.  I don't think anything from the years
  > previous to that will be available.

Please follow the example in other branches: place the ChangeLog files
in the appropriate directories and call them ChangeLog.cocoa. 

For new files you just need a single entry: New file. Every single
change to generic emacs code needs to have a ChangeLog entry describing
it, even if it was done before you maintained the code.  If you'd look
on the mailing list for the experience with merging other code, you'd
see that RMS won't allow merges to proceed until the ChangeLogs are
acceptable.


        --dan

Re: Emacs.app (Cocoa/GNUstep port) release and feature list

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 24 Nov 2007 13:39:26 +0300, "Adrian Robert" <adrian.b.robert@gmail.com> said:

> GNUSTEP and COCOA are platform indicators, like DARWIN, MAC_OS8,
> GNU_LINUX, or VMS.

What would happen if one tries to make the GNUstep build on Mac OS X?

> I would use "MAC_OSX" instead of COCOA, but that is already used by
> the Carbon port to mean essentially HAVE_CARBONGUI.

No, MAC_OSX does not necessarily mean HAVE_CARBON.  Actually, MAC_OSX
is defined also on the X11 build for Mac OS X.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Emacs.app (Cocoa/GNUstep port) release and feature list

[Adrian Robert]

On 11/23/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > This port maintained its own CVS for a while, but that was messing up
> > existing tags in emacs files and also making syncing with emacs CVS
> > difficult.  I know there are git and arch alternatives here, but
> > Richard has said he is OK with bringing this into the trunk after the
> > unicode merge and that seems like the best route for maintenance.  (A
> > branch is another possibility but that still leaves an ongoing merge
> > burden.)
>
> I think it would be good to add it as a branch in the CVS.  It won't add
> any "merge burden" that isn't already present.  And it will make it easier
> to keep them synchronized, to compare them, etc...

If this is the preferred route I'll consider it, but on the whole I'd
rather just wait and merge to trunk, unless that is far off or might
not happen.  I've been posting diffs on sourceforge for comparison
purposes.  What was the merge process for the Carbon port?

Re: Emacs.app (Cocoa/GNUstep port) release and feature list

[Adrian Robert]

On 11/24/07, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> We are trying to minimize the number of files preloaded, if you look in
> loadup.el no other platform loads these files, you'd need to justify the
> need to load them.
>
> emacs-lisp/advice will 100% be rejected, if you need different
> functionality, just change the function, not advice it.

OK, I've dropped advice and its prereqs, dropped paren (because drop
mic-paren), and ns-mark-nav will be submitted separately.  All that is
left are easymenu and easy-mmode.  These are needed to ease the pain
in making the minor menu changes needed for platform convention in
ns-win.  Are they a problem?



>  > >  lisp/ns-grabenv.el                 |only
>  > >
>  > > Doesn't the Carbon port have the same problem that this file tries to
>  > > solve? Does GNUstep have this problem? Is the ns-* name appropriate
>  > > then?
>  >
>  > You are right this solves a problem mainly encountered on the Mac
>  > platform for the Cocoa port.
>
> Are you saying that the Carbon port does not have to deal with this issue.

There are multiple ways for users to tackle it.  Emacs.app includes
two (ns-grabenv.el and mac-fix-env binary), and some Carbon users take
these out of the Emacs.app dist and use them.  Many Carbon users use
Aquamacs, a distribution that includes its own approach to the problem
(basically auto-invoke something like ns-grabenv on startup).  Power
OS X users can and do work around the issue without any of these
tools.



>  > >  lisp/term/ns-win.el
>  >
>  > >    Are the deffaces really needed in this file?
>  >
>  > ns-working-text-face is needed.  paren-face-match-light will be
>  > removed along with mic-paren when/if a merge becomes imminent.
>
> That's not very productive for the people reviewing this code: if
> something won't be included, then drop it and keep it as local
> customization, it won't force unnecessary extra work on people trying to
> help with the merge.

OK , removed, will be reflected in next release.



> BTW, I just noticed this:
> (makunbound 'yank-menu-length)
> (defcustom yank-menu-length 40
>
> Use customize-set-variable instead. But even that would need
> justification for changing a default in a platform specific file.

Dropped (though IMHO the default of 20 is unnecessarily small).



>  > > I think you posted the changes to lisp/progmodes/cc-*.el to this
>  > > list. What keeps them from being checked in CVS? They are not related to
>  > > this port, just unnecessary overhead for you...
>  >
>  > They are still not accepted by the maintainer yet.  If they get
>  > accepted I can take them out.  Otherwise I feel they should at least
>  > be bundled as part of the port, because Objective-C is the primary
>  > development language for both Mac and GNUstep.
>
> Were the changes not reviewed or not accepted at all? If the former, I'd
> advice you repost them here, CCing RMS. In general he keeps track of
> submitted patches.

RMS and Alan Mackenzie seemed OK with acceptance, but I think Alan has
not had time to look at it since.  I'm not sure if maybe some
objection will be found.  See thread associated with:

http://lists.gnu.org/archive/html/emacs-devel/2007-10/msg01428.html



>  > > Also it seems that !GNUSTEP is the same as COCOA. Why not just use one of them?
>  >
>  > I'm fine to make this change if people think it's easier to read.
>
> Yeah, the least amount of identifiers that one has to learn the meaning
> for, the better.

I'll drop COCOA and look into dropping GNUSTEP in favor of !MAC_OSX.
Although, to answer Yamamoto-san's question, building GNUSTEP under OS
X should be left possible, since people do install GNUstep on Macs.



>  > > Don't do any #ifdef MULTI_KBOARD, just assume it is always defined.

Done.



>  > Emacs.app does not include any icons.  Unless you're talking about the
>  > main app icon.  For now I think it's best to use a different one, so
>  > users know which version they are running.
>
> On X11, we don't have different icons for running with different
> toolkits...

For merging I will switch to the standard (notebook) icons used for
Carbon.  If I continue an enhanced binary distribution I'll use the
current Emacs.app icon.



> Please follow the example in other branches: place the ChangeLog files
> in the appropriate directories and call them ChangeLog.cocoa.
>
> For new files you just need a single entry: New file. Every single
> change to generic emacs code needs to have a ChangeLog entry describing
> it, even if it was done before you maintained the code.

OK, this will be done.


Adrian

Re: Emacs.app (Cocoa/GNUstep port) release and feature list

[Dan Nicolaescu]

"Adrian Robert" <adrian.b.robert@gmail.com> writes:

  > On 11/24/07, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > > We are trying to minimize the number of files preloaded, if you look in
  > > loadup.el no other platform loads these files, you'd need to justify the
  > > need to load them.
  > >
  > > emacs-lisp/advice will 100% be rejected, if you need different
  > > functionality, just change the function, not advice it.
  > 
  > OK, I've dropped advice and its prereqs, dropped paren (because drop
  > mic-paren), and ns-mark-nav will be submitted separately.  All that is
  > left are easymenu and easy-mmode.  These are needed to ease the pain
  > in making the minor menu changes needed for platform convention in
  > ns-win.  Are they a problem?

IMHO they probably are. One possible solution: change the code in
menu-bar.el to create menus the way you want them for this platform
instead of tweaking the menus in ns-win.el.

Re: Emacs.app (Cocoa/GNUstep port) release and feature list

[Adrian Robert]

> > The new #defines: HAVE_NS GNUSTEP COCOA COCOA_EXPERIMENTAL_CTRL_G
> >
> > Why not HAVE_GNUSTEP and HAVE_COCOA too?
>
> HAVE_XX seems to be standard for the overall windowing system / port
> being used: HAVE_XWINDOWS, HAVE_NTGUI.  GNUSTEP and COCOA are platform
> indicators, like DARWIN, MAC_OS8, GNU_LINUX, or VMS.  I would use
> "MAC_OSX" instead of COCOA, but that is already used by the Carbon
> port to mean essentially HAVE_CARBONGUI.
>
>
>
> > Also it seems that !GNUSTEP is the same as COCOA. Why not just use one
> > of them?
>
> I'm fine to make this change if people think it's easier to read.

I tried this, but on second thought there are two problems.  First,
GNUSTEP and COCOA are both implementations of the NeXTstep API.  There
are others out there, and if Emacs.app one day supports them then it
will need more than GNUSTEP and !GNUSTEP.  Also, it is not sufficient
to assume if MAC_OSX then COCOA, because GNUstep (and possibly other
implementations) can and are installed and used under OS X.

Second, it seems less readable to use "#ifndef XXX" for blocks of code
that are enabled on platform YYY. " #if YYY" (without the negative) is
clearer, even at the cost of additional identifiers.

I could rename them to something like NS_IMPL_GNUSTEP, NS_IMPL_COCOA
(or NS_VENDOR_GNU, NS_VENDOR_APPLE) to make their meaning clearer.

Re: Emacs.app (Cocoa/GNUstep port) release and feature list

[Stefan Monnier]

> I tried this, but on second thought there are two problems.  First,
> GNUSTEP and COCOA are both implementations of the NeXTstep API.  There
> are others out there, and if Emacs.app one day supports them then it
> will need more than GNUSTEP and !GNUSTEP.  Also, it is not sufficient
> to assume if MAC_OSX then COCOA, because GNUstep (and possibly other
> implementations) can and are installed and used under OS X.

> Second, it seems less readable to use "#ifndef XXX" for blocks of code
> that are enabled on platform YYY. " #if YYY" (without the negative) is
> clearer, even at the cost of additional identifiers.

> I could rename them to something like NS_IMPL_GNUSTEP, NS_IMPL_COCOA
> (or NS_VENDOR_GNU, NS_VENDOR_APPLE) to make their meaning clearer.

On a related note: do we have somewhere a list of such CPP defines with
their intended meanings?  If so, where?  If not, then let's make one.


        Stefan

MAC_OS_X cpp macro?

[Stefan Monnier]

> On a related note: do we have somewhere a list of such CPP defines with
> their intended meanings?  If so, where?  If not, then let's make one.

While taking a look at this idea, I bumped into the following in mac.c:

   [...]
   #ifndef MAC_OS_X
   [...]

AFAICT it's the only occurrence of MAC_OS_X in an ifdef/ifndef, whereas
there are many occurrences of MAC_OSX.  Is that a typo?


        Stefan

admin/CPP-DEFINES

[Stefan Monnier]

I've just added an embryo file admin/CPP-DEFINES to list the macros that
we use together with their intended meaning.  Please help me fill it,
correct misconceptions, and remove the question marks.


        Stefan

Re: MAC_OS_X cpp macro?

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 10 Dec 2007 11:47:56 -0500, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> On a related note: do we have somewhere a list of such CPP defines
>> with their intended meanings?  If so, where?  If not, then let's
>> make one.

> While taking a look at this idea, I bumped into the following in
> mac.c:

>    [...]  #ifndef MAC_OS_X [...]

> AFAICT it's the only occurrence of MAC_OS_X in an ifdef/ifndef,
> whereas there are many occurrences of MAC_OSX.  Is that a typo?

Yes, it is a typo and does not do harm at this particular place.  I
was planning to fix it when merging the Mac-related changes as of the
before-merge-multi-tty-to-trunk tag to EMACS_22_BASE after the Emacs
22.2 release.

And some comments about some Mac-related defines in admin/CPP-DEFINES:

> MAC_OS		Compiling for some version of Mac OS?

In short, it corresponds to (eq window-system 'mac), or is equivalent
to `MAC_OS8 || (MAC_OSX && HAVE_CARBON)'.  Currently it can be said as
"Compile support for the Mac native GUI", but this will no longer be
true if the Cocoa port is merged.

> MAC_OS8		Compiling for Mac OS version 8.  Requires MAC_OS?

Compiling for Mac OS Classic (8 or 9).

> MAC_OSX		Compiling for Mac OS X?  Is that also valid for Darwin?

Compiling for Mac OS X.  Not valid for bare Darwin.
Also, DARWIN should not be defined for Mac OS X because it is used for
distinguishing them in CoreFoundation.h.

> HAVE_CARBON	Compile support for the Carbon GUI.  Requires MAC_OS?

Yes.  For MAC_OS8, either of HAVE_CARBON and !HAVE_CARBON is possible
and the native GUI is used anyway.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: MAC_OS_X cpp macro?

[Stefan Monnier]

>> MAC_OS		Compiling for some version of Mac OS?

> In short, it corresponds to (eq window-system 'mac), or is equivalent
> to `MAC_OS8 || (MAC_OSX && HAVE_CARBON)'.  Currently it can be said as
> "Compile support for the Mac native GUI", but this will no longer be
> true if the Cocoa port is merged.

Hmm... see below.

>> MAC_OSX		Compiling for Mac OS X?  Is that also valid for Darwin?
> Compiling for Mac OS X.  Not valid for bare Darwin.
> Also, DARWIN should not be defined for Mac OS X because it is used for
> distinguishing them in CoreFoundation.h.

OK.

>> HAVE_CARBON	Compile support for the Carbon GUI.  Requires MAC_OS?

> Yes.  For MAC_OS8, either of HAVE_CARBON and !HAVE_CARBON is possible
> and the native GUI is used anyway.

What's the difference between MAC_OS8 with HAVE_CARBON and MAC_OS8
without HAVE_CARBON?

If there is none, then HAVE_CARBON and MAC_OS seem to be equivalent.


        Stefan

Re: MAC_OS_X cpp macro?

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 11 Dec 2007 13:57:48 -0500, Stefan Monnier <monnier@iro.umontreal.ca> said:

>>> HAVE_CARBON Compile support for the Carbon GUI.  Requires MAC_OS?

>> Yes.  For MAC_OS8, either of HAVE_CARBON and !HAVE_CARBON is
>> possible and the native GUI is used anyway.

> What's the difference between MAC_OS8 with HAVE_CARBON and MAC_OS8
> without HAVE_CARBON?

The former uses the Carbon APIs, and the latter uses the earlier APIs.

http://developer.apple.com/documentation/Carbon/Conceptual/carbon_porting_guide/cpg_intro_struct/chapter_1_section_1.html

So MAC_OS does not necessarily mean HAVE_CARBON.

In Emacs 23, removal of the whole Mac OS Classic (8 or 9) support is
much more likely to happen than that of the Carbon support.  Then this
distinction will become meaningless in that version.  Of course, the
documentation for cpp defines is still useful to read the Emacs 22
code.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: admin/CPP-DEFINES

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 10 Dec 2007 12:04:34 -0500
> 
> I've just added an embryo file admin/CPP-DEFINES to list the macros that
> we use together with their intended meaning.  Please help me fill it,
> correct misconceptions, and remove the question marks.

I added some more symbols and fixed a few ``misconceptions''.