Carbon: resizing a frame on wrong "space"

Carbon: resizing a frame on wrong "space"

[David Reitter]

When using the new "spaces" feature in Leopard, Emacs shows a bug when  
attempting to resize a frame.

To reproduce:

- configure "spaces" in 10.5 so that there are two vertically placed  
spaces.
- emacs -Q   (Recent Carbon port build from 22 branch CVS)
- move the frame to the other space (e.g. by dragging it to the  
[lower] edge of the screen)
- resize it (with the mouse)

What happens for me is that the frame is moved to the original space  
on which it was created while I'm resizing it. Then, it is moved back  
down.

Re: Carbon: resizing a frame on wrong "space"

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 20 Feb 2008 11:02:43 +0000, David Reitter <david.reitter@gmail.com> said:

> When using the new "spaces" feature in Leopard, Emacs shows a bug when  
> attempting to resize a frame.

> To reproduce:

> - configure "spaces" in 10.5 so that there are two vertically placed  
> spaces.
> - emacs -Q   (Recent Carbon port build from 22 branch CVS)
> - move the frame to the other space (e.g. by dragging it to the  
> [lower] edge of the screen)
> - resize it (with the mouse)

> What happens for me is that the frame is moved to the original space  
> on which it was created while I'm resizing it. Then, it is moved back  
> down.

I couldn't reproduce it with Mac OS X 10.5.2/PPC.  Does anyone else
see this behavior?

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

Re: Carbon: resizing a frame on wrong "space"

[Harald Maier]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>>>>>> On Wed, 20 Feb 2008 11:02:43 +0000, David Reitter <david.reitter@gmail.com> said:
>
>> When using the new "spaces" feature in Leopard, Emacs shows a bug when  
>> attempting to resize a frame.
>
>> To reproduce:
>
>> - configure "spaces" in 10.5 so that there are two vertically placed  
>> spaces.
>> - emacs -Q   (Recent Carbon port build from 22 branch CVS)
>> - move the frame to the other space (e.g. by dragging it to the  
>> [lower] edge of the screen)
>> - resize it (with the mouse)
>
>> What happens for me is that the frame is moved to the original space  
>> on which it was created while I'm resizing it. Then, it is moved back  
>> down.
>
> I couldn't reproduce it with Mac OS X 10.5.2/PPC.  Does anyone else
> see this behavior?

Yes, I see this behavior too. It's really annoying. 

Harald

Re: Carbon: resizing a frame on wrong "space"

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 28 Feb 2008 21:26:12 +0100, Harald Maier <harald@maierh.de> said:

>>> When using the new "spaces" feature in Leopard, Emacs shows a bug when  
>>> attempting to resize a frame.
>> 
>>> To reproduce:
>> 
>>> - configure "spaces" in 10.5 so that there are two vertically placed  
>>> spaces.
>>> - emacs -Q   (Recent Carbon port build from 22 branch CVS)
>>> - move the frame to the other space (e.g. by dragging it to the  
>>> [lower] edge of the screen)
>>> - resize it (with the mouse)
>> 
>>> What happens for me is that the frame is moved to the original space  
>>> on which it was created while I'm resizing it. Then, it is moved back  
>>> down.
>> 
>> I couldn't reproduce it with Mac OS X 10.5.2/PPC.  Does anyone else
>> see this behavior?

> Yes, I see this behavior too. It's really annoying. 

I could also reproduce it but needed an additional step "resize the
frame once before moving the frame to the other Space".

AFAIK, Spaces are not visible from the application side, and there's
no API for them.  I strongly suspect the problem is due to a bug of
Carbon `ResizeWindow' in displaying a "frame" (not in the Emacs
terminology) for resizing.  I'll report it to Apple.

FYI, it does not happen with the Carbon+AppKit port.

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

Re: Carbon: resizing a frame on wrong "space"

[William Xu]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> FYI, it does not happen with the Carbon+AppKit port.

I have seen you mentioned this port several times, but never find it
through google. Seems not in CVS repo either? So where can I get it?

-- 
William

http://williamxu.net9.org

Re: Carbon: resizing a frame on wrong "space"

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 29 Feb 2008 11:40:10 +0900, William Xu <william.xwl@gmail.com> said:

>> FYI, it does not happen with the Carbon+AppKit port.

> I have seen you mentioned this port several times, but never find it
> through google. Seems not in CVS repo either? So where can I get it?

I said in http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg00249.html:

> I'm planning to do before-merge-multi-tty-to-trunk -> EMACS_22_BASE
> merge after the 22.2 release.  And below is the plan after that (for
> Emacs 22):

>   * Reorganize Carbon-specific code by separating its GUI parts into a
>     new file `mactoolbox.c'.
>   * Use Quartz 2D Image I/O API instead of QuickTime C API for reading
>     images on Mac OS X 10.4 and later.
>   * Add some event handlers to support dictionary lookup with
>     DictionaryService (Command-Control-D, 10.4 and later).
>   * Add (mostly GUI) code for the Carbon+AppKit port if it is allowed.

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

Re: Carbon: resizing a frame on wrong "space"

[William Xu]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>>>>>> On Fri, 29 Feb 2008 11:40:10 +0900, William Xu <william.xwl@gmail.com> said:
>
>>> FYI, it does not happen with the Carbon+AppKit port.
>
>> I have seen you mentioned this port several times, but never find it
>> through google. Seems not in CVS repo either? So where can I get it?
>
> I said in http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg00249.html:
>
>> I'm planning to do before-merge-multi-tty-to-trunk -> EMACS_22_BASE
>> merge after the 22.2 release.  And below is the plan after that (for
>> Emacs 22):
>
>>   * Reorganize Carbon-specific code by separating its GUI parts into a
>>     new file `mactoolbox.c'.
>>   * Use Quartz 2D Image I/O API instead of QuickTime C API for reading
>>     images on Mac OS X 10.4 and later.
>>   * Add some event handlers to support dictionary lookup with
>>     DictionaryService (Command-Control-D, 10.4 and later).
>>   * Add (mostly GUI) code for the Carbon+AppKit port if it is allowed.

Does you mean that the Carbon+AppKit port codes is still in your private
repo? Or already in before-merge-multi-tty-to-trunk branch ?

-- 
William

http://williamxu.net9.org

Re: Carbon: resizing a frame on wrong "space"

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 29 Feb 2008 12:10:51 +0900, William Xu <william.xwl@gmail.com> said:

>> I said in http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg00249.html:
>> 
>>> I'm planning to do before-merge-multi-tty-to-trunk -> EMACS_22_BASE
>>> merge after the 22.2 release.  And below is the plan after that (for
>>> Emacs 22):
>> 
>>> * Reorganize Carbon-specific code by separating its GUI parts into a
>>> new file `mactoolbox.c'.
>>> * Use Quartz 2D Image I/O API instead of QuickTime C API for reading
>>> images on Mac OS X 10.4 and later.
>>> * Add some event handlers to support dictionary lookup with
>>> DictionaryService (Command-Control-D, 10.4 and later).
>>> * Add (mostly GUI) code for the Carbon+AppKit port if it is allowed.

> Does you mean that the Carbon+AppKit port codes is still in your private
> repo? Or already in before-merge-multi-tty-to-trunk branch ?

I meant there are several steps needed before installing that port.

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

Re: Carbon: resizing a frame on wrong "space"

[Dan Nicolaescu]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

  > >>>>> On Fri, 29 Feb 2008 11:40:10 +0900, William Xu <william.xwl@gmail.com> said:
  > 
  > >> FYI, it does not happen with the Carbon+AppKit port.
  > 
  > > I have seen you mentioned this port several times, but never find it
  > > through google. Seems not in CVS repo either? So where can I get it?
  > 
  > I said in http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg00249.html:
  > 
  > > I'm planning to do before-merge-multi-tty-to-trunk -> EMACS_22_BASE
  > > merge after the 22.2 release.  And below is the plan after that (for
  > > Emacs 22):
     ^^^^^^^^^^^
Stefan said recently on the list that there might not be and emacs-22.3...
So planning to do significant work on that branch might not be the best
idea.

Re: Carbon: resizing a frame on wrong "space"

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 28 Feb 2008 20:55:21 -0800, Dan Nicolaescu <dann@ics.uci.edu> said:

>> > I'm planning to do before-merge-multi-tty-to-trunk -> EMACS_22_BASE
>> > merge after the 22.2 release.  And below is the plan after that (for
>> > Emacs 22):
>      ^^^^^^^^^^^
> Stefan said recently on the list that there might not be and emacs-22.3...
> So planning to do significant work on that branch might not be the best
> idea.

If you mean
http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02377.html ,
I understand he just said that there's no absolute guarantee to have a
22.3 release.

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

Re: Carbon: resizing a frame on wrong "space"

[Stefan Monnier]

>>> > I'm planning to do before-merge-multi-tty-to-trunk -> EMACS_22_BASE
>>> > merge after the 22.2 release.  And below is the plan after that (for
>>> > Emacs 22):
>> ^^^^^^^^^^^
>> Stefan said recently on the list that there might not be and emacs-22.3...
>> So planning to do significant work on that branch might not be the best
>> idea.

> If you mean
> http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02377.html ,
> I understand he just said that there's no absolute guarantee to have a
> 22.3 release.

You understood right,


        Stefan

Re: Carbon: resizing a frame on wrong "space"

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 29 Feb 2008 11:40:10 +0900, William Xu <william.xwl@gmail.com> said:

> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>> FYI, it does not happen with the Carbon+AppKit port.

> I have seen you mentioned this port several times, but never find it
> through google. Seems not in CVS repo either? So where can I get it?

Now it is publicly available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-22.3-appkit-1.0.tar.gz

Below is the contents its README file:

1. What's this?

This is "Carbon+AppKit port" addition to GNU Emacs 22.3.

The Carbon+AppKit port of GNU Emacs 22.3 is a port of the Carbon port
(aka "Carbon Emacs", don't confuse it with "Carbon Emacs Package")
that is a part of the official GNU Emacs 22 distribution and provides
native GUI support for Mac OS.  The two ports differ in the GUI
implementation basis: the Carbon port uses Carbon HIToolbox, but the
Carbon+AppKit port uses the Cocoa Application Kit framework (AppKit).

The Carbon+AppKit port inherits the code of the non-GUI part of the
Carbon port, such as drawing, font and image handling.  So in this
sense, the Carbon+AppKit port can be regarded as a variant of the
Carbon port.  Obviously, this is not a backport of the Cocoa/GNUstep
port (aka "Emacs.app").

The Carbon+AppKit port shares mostly the same features with the Carbon
port including the following:

  * C-g handling
    You can quit (while t) and (shell-command "sleep 100").

  * Emulation of `select' without periodic polling
    It doesn't use CPU time while the Lisp interpreter is idle and
    waiting for some events to come, even with subprocesses or network
    connections.

  * Graceful termination
    If you try logout/shutdown/reboot while leaving a file-visiting
    buffer modified and unsaved, a popup window appears for
    confirmation.  If you cancel the termination of Emacs, the whole
    logout/shutdown/reboot process is also canceled immediately.

  * Apple Event handling
    One can define Apple Event handlers at the Lisp level.  Actually,
    graceful termination above is an instance of Lisp-level Apple
    Event handling.  Another example is "Get URL" handler that enables
    us to invoke the mailer you customized with `mail-user-agent',
    e.g.,

      $ osascript -e 'tell application "Emacs"
		      to open location "mailto:foo@example.com"'

    If you set Emacs as the default mailer via Mail.app preference,
    the Emacs mailer will set up a draft buffer when you click a
    mailto: link in a Web browser.

  * DictionaryService support (10.4 and later)
    You can look up a word under the mouse pointer in the selected
    window by typing Command-Control-D.

Basically, the Carbon+AppKit port doesn't add new features per se,
except for the following two aspects:

  * Resolution independence (10.4 and later, 10.5 recommended)
    Scaling works in Framework-Scaled Mode as opposed to (blurry)
    Magnified Mode for the Carbon port.  You may want to disable
    QuickDraw Text, which is incompatible with Framework-Scaled Mode,
    by adding "-DUSE_QUICKDRAW=0" to CFLAGS on compilation.

  * 64-bit (10.5, MAY CRASH, see below)
    You can build and run a 64-bit binary with GUI support by
    specifying CC='gcc -m64' on configure.
    !! Caution !! The resulting binary will crash when you try to
    display particular characters such as combining diacritics.  This
    is due to a bug in 64-bit ATSUI.  Apple says it won't be fixed but
    maybe you can vote for the fix of this bug
    (rdar://problem/5578675) at the Apple Bug Reporter.


2. Build instruction

  a. Untar the official GNU Emacs 22.3 distribution tarball.  Let
     EMACS_SOURCE_TOP be the top directory of the source tree.

  b. Apply the patch `patch-carbon+appkit' to the source tree.

  c. Copy `lisp/term/mac-win.elc' to
     `EMACS_SOURCE_TOP/lisp/term/mac-win.elc' by overriding the
     latter.  (Alternatively, you can bytecompile
     `EMACS_SOURCE_TOP/lisp/term/mac-win.el' that was patched in the
     previous step.)

  d. Copy `src/macappkit.h' and `src/macappkit.m' to
     `EMACS_SOURCE_TOP/src'.

  e. Build as usual with adding "--with-appkit" as a configure option.

Enjoy,

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

Re: Carbon: resizing a frame on wrong "space"

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 07 Sep 2008 12:46:02 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>>> FYI, it does not happen with the Carbon+AppKit port.

>> I have seen you mentioned this port several times, but never find
>> it through google. Seems not in CVS repo either? So where can I get
>> it?

> Now it is publicly available from

>   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-22.3-appkit-1.0.tar.gz

The first update of the Carbon+AppKit port is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-22.3-appkit-1.1.tar.gz

Below is the list of changes:

** Fixed bugs

*** 64-bit binary doesn't work with AquaSKK Japanese input method.

*** Tooltip contents are chopped off if the fractional part of the
scaling factor is greater than or equal to 0.5.

*** Crash with tooltip autodisplay that happens when its contents are
not yet ready.

*** (do-applescript "choose file") -> cancel -> hang on 10.5.

*** With asynchronous subprocesses, the "[Complete, but not unique]"
message shown by C-x C-f / TAB TAB will disappear on key release.
(Both Carbon and Carbon+Appkit)

*** Crash with tabbar.el (not specific to the Carbon(+AppKit) port).
http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1337

** Improvements

*** Execution of flyspell-small-region is no longer too slow.

*** The "Visit New File" dialog no longer confirms replacement if an
existing file is specified (only on 10.3 and later).

*** Update display while the resize control (or the slider in the font
panel) is being dragged.

*** Align key bindings shown in a menu.

*** Explicitly link with libncurses.5 if MACOSX_DEPLOYMENT_TARGET <
1040 to avoid runtime link error when running on the versions without
/usr/lib/libncurses.5.4.dylib.

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

Re: Carbon: resizing a frame on wrong "space"

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 27 Nov 2008 20:37:53 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>>> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>>>> FYI, it does not happen with the Carbon+AppKit port.

>>> I have seen you mentioned this port several times, but never find
>>> it through google. Seems not in CVS repo either? So where can I
>>> get it?

>> Now it is publicly available from

>> ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-22.3-appkit-1.0.tar.gz

> The first update of the Carbon+AppKit port is now available from

>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-22.3-appkit-1.1.tar.gz

The second update of the Carbon+AppKit port is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-22.3-appkit-1.2.tar.gz

Below is the list of changes:

** Fixed bugs

*** do-applescript crashes with -nw due to the previous fix for
(do-applescript "choose file") hang.

*** Cursor erasure sometimes fails on Mac OS X 10.5 due to the
previous change for flyspell-small-region slowness.

*** Buffer overrun in creation of Vmac_carbon_version_string.

** Improvements

*** Untag Lisp_Object by subtraction instead of masking.
http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg01876.html

*** `select' emulation waits for user signal delivery as well as
window system events and process outputs via sockets.
http://lists.gnu.org/archive/html/emacs-devel/2008-10/msg00198.html

*** Hourglass display is enabled.

*** Let the framework decide whether wheel events to non-focus frames
are accepted or not.

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

Re: Carbon: resizing a frame on wrong "space"

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 26 Jan 2009 13:48:19 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>>>> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>>>>> FYI, it does not happen with the Carbon+AppKit port.

>>>> I have seen you mentioned this port several times, but never find
>>>> it through google. Seems not in CVS repo either? So where can I
>>>> get it?

>>> Now it is publicly available from

>>> ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-22.3-appkit-1.0.tar.gz

The third update of the Carbon+AppKit port is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-22.3-appkit-1.3.tar.gz

Below is the list of changes:

** Fixed bugs

*** Popup dialog button labels may get corrupted.
http://lists.gnu.org/archive/html/emacs-devel/2009-03/msg00261.html

*** Popup dialog does not select the default item with the return key.

*** Tooltip contents are sometimes not shown on 10.4 due to the
previous change for flyspell-small-region slowness.

** Improvements

*** Hourglass (progress indicator) is shown in the title bar.

*** Add f20 and kp-separator to the keycode-to-xkeysym table.


This time, README is slightly expanded as follows:

1. What's this?

This is "Carbon+AppKit port" addition to GNU Emacs 22.3.

The Carbon+AppKit port of GNU Emacs 22.3 is a port of the Carbon port
(aka "Carbon Emacs", don't confuse it with "Carbon Emacs Package")
that is a part of the official GNU Emacs 22 distribution and provides
native GUI support for Mac OS.  The two ports differ in the GUI
implementation basis: the Carbon port uses Carbon HIToolbox, but the
Carbon+AppKit port uses the Cocoa Application Kit framework (AppKit).

The Carbon+AppKit port inherits the code of the non-GUI part of the
Carbon port, such as drawing, font and image handling.  So in this
sense, the Carbon+AppKit port can be regarded as a variant of the
Carbon port.  Obviously, this is not a backport of the Cocoa/GNUstep
port (aka "Emacs.app").

The Carbon+AppKit port shares mostly the same features with the Carbon
port including the following:

  * C-g handling
    You can quit (while t) and (shell-command "sleep 100").
    No bogus menu bar activation while these evaluations.

  * Emulation of `select' without periodic polling
    It doesn't use CPU time while the Lisp interpreter is idle and
    waiting for some events to come, even with subprocesses or network
    connections.

  * Graceful termination
    If you try logout/shutdown/reboot while leaving a file-visiting
    buffer modified and unsaved, a popup window appears for
    confirmation.  If you cancel the termination of Emacs (including
    C-g or ESC), the whole logout/shutdown/reboot process is also
    canceled immediately (i.e., you will see a "canceled" dialog
    immediately rather than a "timed out" one afterward).  If you
    don't have unsaved buffers, shell buffers, etc., you won't see
    unnecessary confirmation.

  * Apple Event handling
    One can define Apple Event handlers at the Lisp level.  Actually,
    graceful termination above is an instance of Lisp-level Apple
    Event handling.  Another example is "Get URL" handler that enables
    us to invoke the mailer you customized with `mail-user-agent',
    e.g.,

      $ osascript -e 'tell application "Emacs"
		      to open location "mailto:foo@example.com"'

    If you set Emacs as the default mailer via Mail.app preference,
    the Emacs mailer will set up a draft buffer when you click a
    mailto: link in a Web browser.

  * DictionaryService support (10.4 and later)
    You can look up a word under the mouse pointer in the selected
    window by typing Command-Control-D.

Basically, the Carbon+AppKit port doesn't add new features per se,
except for the following two aspects:

  * Resolution independence (10.4 and later, 10.5 recommended)
    Scaling works in Framework-Scaled Mode as opposed to (blurry)
    Magnified Mode for the Carbon port.  You may want to disable
    QuickDraw Text, which is incompatible with Framework-Scaled Mode,
    by adding "-DUSE_QUICKDRAW=0" to CFLAGS on compilation.

  * 64-bit (10.5, MAY CRASH, see below)
    You can build and run a 64-bit binary with GUI support by
    specifying CC='gcc -m64' on configure.
    !! Caution !! The resulting binary will crash when you try to
    display particular characters such as combining diacritics.  This
    is due to a bug in 64-bit ATSUI.  Apple says it won't be fixed but
    maybe you can vote for the fix of this bug
    (rdar://problem/5578675) at the Apple Bug Reporter.

Although they are minor, some visual enhancements can be found in the
Carbon+AppKit port:

  * Aligned key bindings in menus

  * Progress indicator (corresponding to hourglass) in the title bar

  * Unusable items in the font panel are hidden
    Try Options -> Show/Hide -> Font Panel from the menu bar or
    M-x mac-font-panel-mode RET.

  * Update display while the resize control (or the slider in the font
    panel) is being dragged


2. Build instruction

  a. Untar the official GNU Emacs 22.3 distribution tarball.  Let
     EMACS_SOURCE_TOP be the top directory of the source tree.

  b. Apply the patch `patch-carbon+appkit' to the source tree.

  c. Copy `lisp/term/mac-win.elc' to
     `EMACS_SOURCE_TOP/lisp/term/mac-win.elc' by overriding the
     latter.  (Alternatively, you can bytecompile
     `EMACS_SOURCE_TOP/lisp/term/mac-win.el' that was patched in the
     previous step.)

  d. Copy `src/macappkit.h' and `src/macappkit.m' to
     `EMACS_SOURCE_TOP/src'.

  e. Build as usual with adding "--with-appkit" as a configure option.

Enjoy,

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

Re: Carbon: resizing a frame on wrong "space"

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 27 Mar 2009 09:28:32 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> The third update of the Carbon+AppKit port is now available from

>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-22.3-appkit-1.3.tar.gz

> Basically, the Carbon+AppKit port doesn't add new features per se,
> except for the following two aspects:

>   * 64-bit (10.5, MAY CRASH, see below)
>     You can build and run a 64-bit binary with GUI support by
>     specifying CC='gcc -m64' on configure.
>     !! Caution !! The resulting binary will crash when you try to
>     display particular characters such as combining diacritics.  This
>     is due to a bug in 64-bit ATSUI.  Apple says it won't be fixed but
>     maybe you can vote for the fix of this bug
>     (rdar://problem/5578675) at the Apple Bug Reporter.

This crash issue seems to be fixed in Mac OS X 10.5.7.

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

Emacs 22 Carbon+AppKit port (was Re: Carbon: resizing a frame on wrong "space")

[YAMAMOTO Mitsuharu]

The fourth update of the Carbon+AppKit port is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-22.3-appkit-1.4.tar.gz

As I said in
http://lists.gnu.org/archive/html/emacs-devel/2009-05/msg00262.html ,
a 64-bit ATSUI bug was fixed in Mac OS X 10.5.7 update and the 64-bit
executable no longer crashes on displaying combining diacritics.

Below is the list of changes:

** Fixed bugs

*** Fringe bitmap display is incorrect if its width is not 8.

*** Crash when calculating Quickdraw font metrics in an invisible frame.

*** Crash when changing internal-border-width of an invisible frame.

*** Assertion failure in mac_set_font.

*** "Hide" in Login Items does not work. 

*** (mac-pasteboard-string-to-string "\342\204\246" 'mac-roman) gives
GREEK CAPITAL LETTER OMEGA instead of OHM SIGN (likewise for
mac-utxt-to-string).

*** mac-symbol -> emacs-mule mapping is represented wrong for #x30 - #x37.

** Improvements

*** Conversion between CFNumber and Lisp objects now uses Lisp strings
for integers that don't fit in the Lisp float range.

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

Re: Emacs 22 Carbon+AppKit port

[YAMAMOTO Mitsuharu]

The fifth update of the Carbon+AppKit port is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-22.3-appkit-1.5.tar.gz

** Fixed bugs

*** "open -g" (available on Mac OS X 10.5 and later) does not work.

*** Control-Tab is not recognized on Mac OS X 10.4 and earlier.

** Improvements

*** Resizing truncates the window width/height to multiple of the
nominal character size instead of rounding unless the resizing is
triggered by mouse dragging of the resize handle.

*** Warning "CFMessagePort: bootstrap_register(): failed" with
multiple invocations via command-line or "open -n" is suppressed
(except for Mac OS X 10.4).

An experimental/hackers-only version for Emacs 23.1 on Mac OS X 10.2 -
10.5 is also available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1-mac-1.90.tar.gz

I'd call this "Mac port" following the value of `window-system',
because the GUI implementation with Carbon HIToolbox is dropped, and
it's no longer much meaningful to say Carbon or Cocoa (both are used).

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

Re: Emacs 22 Carbon+AppKit port

[CHENG Gao]

I just want to report that I have built this port (Emacs 23.1)
successfully (I am posting this message with this new build).

I see one difference from Cocoa port.

While using Cocoa port (23.1 and 23.1.50), when I enter a group in Gnus,
the first line of *Summary* buffer is half truncated at the top. I need
to turn tool bar off, and then turn on again to make it display
correctly.
(I am not sure if there is something wrong with my setting. Or it's a
bug in Cocoa port.)

I dont see this problem in Carbon+AppKit port.

I am glad to be the first one to report back about this port. And I
wanna say "Thank you".

-- 
The truth which makes men free is for the most part the truth which men prefer not to hear.

Re: Emacs 22 Carbon+AppKit port

[YAMAMOTO Mitsuharu]

The sixth update of the Carbon+AppKit port is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-22.3-appkit-1.6.tar.gz

** Fixed bugs

*** Doesn't build on Mac OS X 10.6.

*** Mach port right leaks due to the previous change for the warning
"CFMessagePort: bootstrap_register(): failed".

** Improvement

*** File dialogs can be closed with C-g on Mac OS X 10.5 and later.


The first update of the Mac port, which is experimental/hackers-only,
is also available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1-mac-1.91.tar.gz

** Fixed bugs

*** Doesn't build on Mac OS X 10.6.

*** Multi-page TIFF images are not supported.
I thought they were, but I actually added the code to another working
tree and forgot to merge it in the previous version.

*** "Visit New File" shows a wrong dialog.
Apply Jason Rumney's fix for Bug#3969.

*** Mach port right leaks due to the previous change for the warning
"CFMessagePort: bootstrap_register(): failed".

** Improvement

*** File and font dialogs can be closed with C-g on Mac OS X 10.5 and later.

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

Re: Emacs 22 Carbon+AppKit port

[Benjamin Riefenstahl]

YAMAMOTO Mitsuharu writes:
> The first update of the Mac port, which is experimental/hackers-only,
> is also available from
>
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1-mac-1.91.tar.gz

Works for me so far.  Thanks for that.

A couple of things that I noticed:

* Iconify confusion.  a) When I minimize the Emacs frame and than click
on the Dock icon, I get a new frame.  I would expect the old frame to be
restored instead.  b) When I close the new frame (without opening the
old frame before), Emacs quits.  It seems that the code that decides
between just closing a frame and quitting Emacs does not consider
iconified frames.  This already happend with the previous version of
Carbon+AppKit.

* multi-tty feature.  "(featurep 'multi-tty)" returns t even though
multi-tty does not work (as you note in README-mac).

I would of course prefer to have this work in the first place.  You say
in the README-mac that you do not know how to disconnect from the Dock,
but I do not think that it is really important to have that particular
feature.  Multi-tty is still usefull, even if the Emacs icon in the Dock
stays activated.

On second thought I am not even sure I want this to change, after all
Emacs /is/ still active even if it doesn't show any UI frames currently.

* Self-contained app.  I can create a self-contained app, not depending
on /usr/local, by redirecting all the stuff that usually gets installed
to /usr/local to mac/Emacs.app/Contents/Resources.  I basically override
all the relevant Makefile variables in the make step.  Can we get this
as a regular configure option?  The GnuStep/Cocoa port does this as did
the old Carbon port and I for one like it.


benny

Re: Emacs 22 Carbon+AppKit port

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 31 Aug 2009 19:38:15 +0200, Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net> said:

> A couple of things that I noticed:

> * Iconify confusion.  a) When I minimize the Emacs frame and than
> click on the Dock icon, I get a new frame.  I would expect the old
> frame to be restored instead.  b) When I close the new frame
> (without opening the old frame before), Emacs quits.  It seems that
> the code that decides between just closing a frame and quitting
> Emacs does not consider iconified frames.  This already happend with
> the previous version of Carbon+AppKit.

Indeed.  This is a bug and inconsistent with the Carbon port behavior.
For an immediate fix, please modify the line

  return [window isVisible];

to 

  return [window isVisible] || [window isMiniaturized];

in the function `mac_is_frame_window_visible' (src/macappkit.m).
Thanks for reporting this.

I also noticed that iconified frames can't be made invisible.  I'll
look into it.

> * multi-tty feature.  "(featurep 'multi-tty)" returns t even though
> multi-tty does not work (as you note in README-mac).

IIRC, the W32 port has the same problem.  Maybe we can adopt some
change once it is fixed on W32 (or is it already fixed?).  BTW,
multi-tty is supposed to work if you don't use GUI (i.e., -nw).

> I would of course prefer to have this work in the first place.  You
> say in the README-mac that you do not know how to disconnect from
> the Dock, but I do not think that it is really important to have
> that particular feature.  Multi-tty is still usefull, even if the
> Emacs icon in the Dock stays activated.

> On second thought I am not even sure I want this to change, after
> all Emacs /is/ still active even if it doesn't show any UI frames
> currently.

I'm not sure if it is feasible without changing the
platform-independent part in an aggressive way.  Let's see how the
official NS port will deal with this.

> * Self-contained app.  I can create a self-contained app, not
> depending on /usr/local, by redirecting all the stuff that usually
> gets installed to /usr/local to mac/Emacs.app/Contents/Resources.  I
> basically override all the relevant Makefile variables in the make
> step.  Can we get this as a regular configure option?  The
> GnuStep/Cocoa port does this as did the old Carbon port and I for
> one like it.

Currently this has low priority.  Maybe you can imitate a part of
`make-package' script in Emacs 22, but things may change in future as
the current version is "experimental/hackers-only".

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

Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The seventh update of the Carbon+AppKit port is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-22.3-appkit-1.7.tar.gz

** Fixed bugs

*** Command-Control-D doesn't pop up dictionary on Mac OS X 10.6.

*** Iconified frames aren't considered visible.
Reported by Benjamin Riefenstahl.

*** Can't make iconified frames invisible.

** Improvement

*** Fall back on mac-system-coding-system if script and language
information is not available in text input events.


The second update of the Mac port, which is experimental/hackers-only,
is also available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1-mac-1.92.tar.gz

In addition to the bug fixes and improvements above, it has the
following experimental feature (only for Mac OS X 10.6 Snow Leopard):

*** New implementation for the `select' emulation using Grand Central
Dispatch instead of CFSocket.  It is enabled by default if built for
Mac OS X 10.6.  If you find it unstable/problematic, then you can turn
it off by compiling with "-DSELECT_USE_GCD=0".

There is a change in how to report bugs.  Please read `README-mac' in
the tarball.

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

Re: Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[CHENG Gao]

YAMAMOTO-san, I found emacs-23.1-mac-1.92.tar.gz file is not there.

Since Snow Leopard is out of cage, I am wondering if YAMAMOTO-san intend
to add mac port into Emacs trunk. I personally hope this can happen.
With mac port added, the greatest befinet is Emacs can work on all
MacOSX versions. And if I understand correctly, it's not possible for
Cocoa port to achieve this easily.

Reasons:
1 Cocoa port uses 10.3 SDK to support MacOSX 10.3-10.5.

2 Snow Leopard supports only 10.4 and up (10.4 support is optional
installation).

3 Without radical changes, Cocoa port can not be built on Snow Leopard.
If Cocoa port is changed to use 10.4 SDK to add support for Snow
Leopard, 10.3 will be left out.


If mac port can be added, the benefits and possible future plan are:

1 Emacs (22, 23 and TRUNK?) works on all MacOSX versions.
User can choose to build mac port or Cocoa port.
Take 23 for example (I dont use 22 so I can not say for it):
User can build mac/Cocoa port on 10.3-10.5
User can build mac port on 10.6

2 Since all version can be covered by two ports combined, for future
development, mac/Cocoa port can be merged to support 10.5 and up (If
agressively enough, 10.6 and up for brand new features).

Re: Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[CHENG Gao]

Minutes later I downloaded emacs/emacs-23.1-mac-1.92.tar.gz and built
successfully.

I am posting from this new build.

Just let everyone knows it works.

Re: Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 05 Sep 2009 15:47:49 +0800, CHENG Gao <chenggao@gmail.com> said:

> YAMAMOTO-san, I found emacs-23.1-mac-1.92.tar.gz file is not there.

Sorry for inconvenience.  I temporarily withdrew the file because I
found a minor mistake before no one had downloaded it.  It is
available now.

> Since Snow Leopard is out of cage, I am wondering if YAMAMOTO-san
> intend to add mac port into Emacs trunk. I personally hope this can
> happen.  With mac port added, the greatest befinet is Emacs can work
> on all MacOSX versions. And if I understand correctly, it's not
> possible for Cocoa port to achieve this easily.

At least, I'd like to make the Mac port separate for now: it's still
at the experimental/hackers-only stage.  I hope I can get rid of that
label shortly after the 23.2 release.

> 1 Emacs (22, 23 and TRUNK?) works on all MacOSX versions.
> User can choose to build mac port or Cocoa port.
> Take 23 for example (I dont use 22 so I can not say for it):
> User can build mac/Cocoa port on 10.3-10.5
> User can build mac port on 10.6

The Mac port can be built on Mac OS X 10.2 - 10.6.  As far as I know,
the NS port can be built on Mac OS X 10.4 - 10.6: there is a problem
with a compilation on 10.3 (*1), and a 32-bit binary can be made on
10.6 (*2) with a small patch (23.1) or as it is (CVS trunk).

*1: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3917
*2: http://lists.gnu.org/archive/html/emacs-devel/2009-08/msg01401.html

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

Re: Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[CHENG Gao]

*On Sat, 05 Sep 2009 17:56:37 +0900
* Also sprach YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>:

>>>>>> On Sat, 05 Sep 2009 15:47:49 +0800, CHENG Gao <chenggao@gmail.com> said:
>
>> YAMAMOTO-san, I found emacs-23.1-mac-1.92.tar.gz file is not there.
>
> Sorry for inconvenience.  I temporarily withdrew the file because I
> found a minor mistake before no one had downloaded it.  It is
> available now.

Yes I got it later. Thanks!

>> Since Snow Leopard is out of cage, I am wondering if YAMAMOTO-san
>> intend to add mac port into Emacs trunk. I personally hope this can
>> happen.  With mac port added, the greatest befinet is Emacs can work
>> on all MacOSX versions. And if I understand correctly, it's not
>> possible for Cocoa port to achieve this easily.
>
> At least, I'd like to make the Mac port separate for now: it's still
> at the experimental/hackers-only stage.  I hope I can get rid of that
> label shortly after the 23.2 release.

>> 1 Emacs (22, 23 and TRUNK?) works on all MacOSX versions.
>> User can choose to build mac port or Cocoa port.
>> Take 23 for example (I dont use 22 so I can not say for it):
>> User can build mac/Cocoa port on 10.3-10.5
>> User can build mac port on 10.6
>
> The Mac port can be built on Mac OS X 10.2 - 10.6.  As far as I know,
> the NS port can be built on Mac OS X 10.4 - 10.6: there is a problem
> with a compilation on 10.3 (*1), and a 32-bit binary can be made on
> 10.6 (*2) with a small patch (23.1) or as it is (CVS trunk).
>
> *1: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3917
> *2: http://lists.gnu.org/archive/html/emacs-devel/2009-08/msg01401.html

Thanks for the info.
I got TRUNK built successfully in 32 bit.
I dont know when, but I have dbus installed with Macports (maybe as
dependency for some app). I found I have to disable dbus otherwise Emacs
wont build.

To build TRUNK with ns port:

$CC='gcc -arch i386' ./configure --with-ns --disable-ns-self-contained
--without-dbus
$make bootstrap

I think it's a good candidate to add to etc/PROBLEMS.

I read the first bug link about problem building on 10.3. Searching
Xcode docs shows that these methods and constants are available on 10.4
and later (colorAtX:y, NSFontTraitsAttribute, NSFontWeightTrait etc.)
So I think Cocoa port can not build on 10.3. README file under nextstep/
should be revised to reflect this. 


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

Re: Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[David Reitter]

On Sep 5, 2009, at 3:47 AM, CHENG Gao wrote:
> Since Snow Leopard is out of cage, I am wondering if YAMAMOTO-san  
> intend
> to add mac port into Emacs trunk. I personally hope this can happen.
> With mac port added, the greatest befinet is Emacs can work on all
> MacOSX versions. And if I understand correctly, it's not possible for
> Cocoa port to achieve this easily.

What are the chances that improvements like the event loop from the  
Mac port are combined with the NextStep/Cocoa code?

> 1 Cocoa port uses 10.3 SDK to support MacOSX 10.3-10.5.

Everybody please note that there are probably very few people still  
left on 10.3.  It came out in 2003, with the last minor release made  
in early 2005.
Cheng Gao, perhaps you could provide a pointer to user statistics if  
you think 10.3 is a big deal.

If somebody needs to use the old OS X, they can certainly stick to an  
older (and still supported!) Emacs 22.  Developer resources are very  
scarce.  Supporting outdated platforms is not the best use of people's  
time.

Re: Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[Stephen J. Turnbull]

David Reitter writes:

 > Everybody please note that there are probably very few people still  
 > left on 10.3.  It came out in 2003, with the last minor release made  
 > in early 2005.

For practical purposes even 10.4 support is thin on the ground these
days.  It's been 6 months since I went more than two weeks without PPC
and/or 10.4-related breakage in MacPorts, for example.

OTOH, I have to suspect that Emacs users are hugely overrepresented in
the group that's still using 10.3. :-)

Re: Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[CHENG Gao]

*On Sat, 5 Sep 2009 08:15:41 -0400
* Also sprach David Reitter <david.reitter@gmail.com>:

> On Sep 5, 2009, at 3:47 AM, CHENG Gao wrote:
>> Since Snow Leopard is out of cage, I am wondering if YAMAMOTO-san
>> intend
>> to add mac port into Emacs trunk. I personally hope this can happen.
>> With mac port added, the greatest befinet is Emacs can work on all
>> MacOSX versions. And if I understand correctly, it's not possible for
>> Cocoa port to achieve this easily.
>
> What are the chances that improvements like the event loop from the
> Mac port are combined with the NextStep/Cocoa code?
>
>> 1 Cocoa port uses 10.3 SDK to support MacOSX 10.3-10.5.
>
> Everybody please note that there are probably very few people still
> left on 10.3.  It came out in 2003, with the last minor release made
> in early 2005.
> Cheng Gao, perhaps you could provide a pointer to user statistics if
> you think 10.3 is a big deal.
>
> If somebody needs to use the old OS X, they can certainly stick to an
> older (and still supported!) Emacs 22.  Developer resources are very
> scarce.  Supporting outdated platforms is not the best use of people's
> time.

I can not find anywhere in my postings that advertises support of 10.3.
If you open ns port Emacs project file, you can find it uses 10.3.9 SDK.
And its README tells it supports 10.3 and later, but it's wrong. 

Mac port supports 10.2-10.6 as explained by YAMAMOTO-san. As you said,
developer resources are very scarce, and since YAMAMOTO-san already
spent efforts to get it working across whole MACOSX line (except 10.0
and 10.1), I think it's good thing to get it merged into TRUNK. Anyway
supporting as many platforms is always good thing.

Re: Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[David Reitter]

On Sep 5, 2009, at 10:35 AM, CHENG Gao wrote:
> I can not find anywhere in my postings that advertises support of  
> 10.3.

OK, thanks for clarifying - apologies for any misunderstanding.

> developer resources are very scarce, and since YAMAMOTO-san already
> spent efforts to get it working across whole MACOSX line (except 10.0
> and 10.1), I think it's good thing to get it merged into TRUNK. Anyway
> supporting as many platforms is always good thing.

It's not a good thing because it takes up people's time that could be  
spent better elsewhere.  It's difficult to support old platforms when  
newer APIs can be used.  There are going to be more conditionals in  
the code, which makes it less readable.  People will be less likely to  
submit patches for these reasons.

Again: would it be possible to mix and merge parts of the ports, e.g.  
use YM's event handling code, which is possibly (!) superior?  I have  
seen a number of unexplained crashes with the Nextstep port which  
usually occur somewhere in the event handling code.  I don't know if  
this is the possible bug that Yamamoto-san pointed out a few times.
I would also like to try out the grand central dispatch method within  
the NextStep port.

Re: Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[CHENG Gao]

Out of curiosity, I tried to build Mac port (1.92) with clang, and found
it works well, while building 32bit ns port fails.

I compared building with gcc (4.2) and clang (on Snow Leopard), the
result is below:

1. With gcc 4.2

$time ./configure --with-mac

real	0m38.490s
user	0m8.163s
sys	0m10.563s

$time make -j3

real	2m21.291s
user	2m26.661s
sys	0m17.704s

2. With clang

$time CC='clang' ./configure --with-mac
real	0m20.890s
user	0m5.425s
sys	0m10.277s

$time make -j3
real	1m9.632s
user	1m33.100s
sys	0m13.372s

Seems clang is much faster than gcc.

Re: Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[Stefan Monnier]

> Since Snow Leopard is out of cage, I am wondering if YAMAMOTO-san intend
> to add mac port into Emacs trunk. I personally hope this can happen.

I think it is a it late for it now.  When the Carbon port lost its
maintainer and nobody was interested to port it to emacs-unicode,
it might have been a good option, but at that time Yamamoto-san didn't
seen too sure what he intended to do with his AppKit port, so we ended
up having to drop the Carbon code, at which point the Emacs.app code
started to look like a good solution.  Nowadays, I'm a lot more
interested in improving the Emacs.app port than integrating another
Mac port.

In other words, I'd recommend to anyone interested in Emacs-in-MacOsX to
focus on the Emacs.app code, possibly by integrating parts of other
ports's code into it.  IIUC the Emacs.app code needs a lot of work.


        Stefan

Re: Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 4939 bytes --]

On Sep 5, 2009, at 1:28 PM, David Reitter wrote:
> Again: would it be possible to mix and merge parts of the ports,  
> e.g. use YM's event handling code, which is possibly (!) superior?   
> I have seen a number of unexplained crashes with the Nextstep port  
> which usually occur somewhere in the event handling code.  I don't  
> know if this is the possible bug that Yamamoto-san pointed out a few  
> times.


Below is one of these crashes.  Another one that I experienced also  
happened in ns_read_socket + 769.


Process:         Aquamacs [2313]
Path:            /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/MacOS/ 
Aquamacs
Identifier:      org.gnu.AquamacsEmacs
Version:         23 (???)
Code Type:       X86 (Native)
Parent Process:  launchd [186]

Date/Time:       2009-09-08 14:40:06.587 -0400
OS Version:      Mac OS X 10.6 (10A432)
Report Version:  6

Interval Since Last Report:          37275 sec
Crashes Since Last Report:           1
Per-App Interval Since Last Report:  405898 sec
Per-App Crashes Since Last Report:   1
Anonymous UUID:                       
91FCF483-3023-4F2A-952D-036B2116B80B

Exception Type:  EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000004020000d
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Application Specific Information:
abort() called

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib             	0x9779b972 __kill + 10
1   libSystem.B.dylib             	0x9779b964 kill$UNIX2003 + 32
2   org.gnu.AquamacsEmacs         	0x000c3651 fatal_error_signal + 446
3   libSystem.B.dylib             	0x977a0bfb _sigtramp + 43
4   ???                           	0xffffffff 0 + 4294967295
5   libSystem.B.dylib             	0x9782eba5 raise + 26
6   libSystem.B.dylib             	0x97844c5c abort + 93
7   org.gnu.AquamacsEmacs         	0x001f5634 ns_term_shutdown + 118
8   org.gnu.AquamacsEmacs         	0x000c5e88 shut_down_emacs + 282
9   org.gnu.AquamacsEmacs         	0x000c35ee fatal_error_signal + 347
10  libSystem.B.dylib             	0x977a0bfb _sigtramp + 43
11  ???                           	0xffffffff 0 + 4294967295
12  com.apple.Foundation          	0x94072acc __delayedPerformCleanup  
+ 59
13  com.apple.CoreFoundation      	0x97455f22 CFRunLoopTimerInvalidate  
+ 786
14  com.apple.CoreFoundation      	0x9741119b __CFRunLoopRun + 7531
15  com.apple.CoreFoundation      	0x9740ed34 CFRunLoopRunSpecific + 452
16  com.apple.CoreFoundation      	0x9740eb61 CFRunLoopRunInMode + 97
17  com.apple.HIToolbox           	0x97e39fec  
RunCurrentEventLoopInMode + 392
18  com.apple.HIToolbox           	0x97e39cdf ReceiveNextEventCommon +  
158
19  com.apple.HIToolbox           	0x97e39c28  
BlockUntilNextEventMatchingListInMode + 81
20  com.apple.AppKit              	0x92937b99 _DPSNextEvent + 847
21  com.apple.AppKit              	0x9293740e -[NSApplication  
nextEventMatchingMask:untilDate:inMode:dequeue:] + 156
22  com.apple.AppKit              	0x928f95fb -[NSApplication run] + 821
23  org.gnu.AquamacsEmacs         	0x001f2391 ns_read_socket + 769
24  org.gnu.AquamacsEmacs         	0x000d37b0 read_avail_input + 165
25  org.gnu.AquamacsEmacs         	0x000d35fa gobble_input + 176
26  org.gnu.AquamacsEmacs         	0x000d3505 get_input_pending + 125
27  org.gnu.AquamacsEmacs         	0x000db253  
detect_input_pending_run_timers + 64
28  org.gnu.AquamacsEmacs         	0x000cb84b read_char + 1295
29  org.gnu.AquamacsEmacs         	0x000d7bda read_key_sequence + 2649
30  org.gnu.AquamacsEmacs         	0x000c8520 command_loop_1 + 1198
31  org.gnu.AquamacsEmacs         	0x00167030 internal_condition_case  
+ 304
32  org.gnu.AquamacsEmacs         	0x000c7ca2 command_loop_2 + 53
33  org.gnu.AquamacsEmacs         	0x001669c1 internal_catch + 215
34  org.gnu.AquamacsEmacs         	0x000c7c2b command_loop + 207
35  org.gnu.AquamacsEmacs         	0x000c71ff recursive_edit_1 + 181
36  org.gnu.AquamacsEmacs         	0x000c7408 Frecursive_edit + 323
37  org.gnu.AquamacsEmacs         	0x000c5710 main + 6412
38  org.gnu.AquamacsEmacs         	0x00002a16 start + 54

Thread 1:  Dispatch queue: com.apple.libdispatch-manager
0   libSystem.B.dylib             	0x9776110a kevent + 10
1   libSystem.B.dylib             	0x97761824 _dispatch_mgr_invoke + 215
2   libSystem.B.dylib             	0x97760ce1 _dispatch_queue_invoke +  
163
3   libSystem.B.dylib             	0x97760a86 _dispatch_worker_thread2  
+ 234
4   libSystem.B.dylib             	0x97760511 _pthread_wqthread + 390
5   libSystem.B.dylib             	0x97760356 start_wqthread + 30

Thread 0 crashed with X86 Thread State (32-bit):
   eax: 0x00000000  ebx: 0x000c34a0  ecx: 0xbfffd55c  edx: 0x9779b972
   edi: 0x105fa580  esi: 0x00000006  ebp: 0xbfffd578  esp: 0xbfffd55c
    ss: 0x0000001f  efl: 0x00000286  eip: 0x9779b972   cs: 0x00000007
    ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037
   cr2: 0x0076f000


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 08 Sep 2009 12:22:38 -0400, Stefan Monnier <monnier@IRO.UMontreal.CA> said:

>> Since Snow Leopard is out of cage, I am wondering if YAMAMOTO-san
>> intend to add mac port into Emacs trunk. I personally hope this can
>> happen.

> I think it is a it late for it now.  When the Carbon port lost its
> maintainer and nobody was interested to port it to emacs-unicode, it
> might have been a good option, but at that time Yamamoto-san didn't
> seen too sure what he intended to do with his AppKit port,

I said:

  For Emacs 23, I don't have a plan to develop the Carbon port.
  The Carbon+AppKit port may be for my personal use only (I already
  have the Core Text font backend driver for Leopard, and I can
  ignore multi-tty for my own use), unless the Cocoa/GNUstep port
  fails to become good enough.

  http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00419.html

and

  As I've been saying, if the Cocoa/GNUstep port becomes good enough, we
  don't have to do anything about the Carbon(+AppKit) port of Emacs 23.
  Maybe the maintainers can put some time schedule to judge if the
  Cocoa/GNUstep port is good enough for the official Emacs 23?

  I may develop the Carbon+AppKit port of Emacs 23 for my private use or
  just for fun.  But the quality and efforts required for the official
  distribution are quite different from those for the private use.  For
  the latter, I can limit the OS version to the latest one, and I can
  omit the features that I don't use.

  http://lists.gnu.org/archive/html/emacs-devel/2008-05/msg00208.html

I made it public because I thought the NS port was not good enough for
me as of the official release.

> so we ended up having to drop the Carbon code, at which point the
> Emacs.app code started to look like a good solution.

You thought that by examining the code, or because it was on Cocoa and
GNUstep?

I think dropping GUI implementation with Carbon, which is not
compatible with 64-bit, in the early stage of Emacs 23 development was
a right decision, as we can see in what happened at the Snow Leopard
release.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.a.cjp

Re: Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 08 Sep 2009 18:38:03 +0800, CHENG Gao <chenggao@gmail.com> said:

> Out of curiosity, I tried to build Mac port (1.92) with clang, and
> found it works well, while building 32bit ns port fails.

The Mac port and the Carbon+AppKit port have contained a small kludge
for LLVM-based compilers (llvm-gcc for 10.5, llvm-gcc and clang for
10.6) bundled with Xcode since their first versions.

RCS file: /cvsroot/emacs/emacs/src/m/intel386.h,v
retrieving revision 1.42.2.4
diff -c -p -r1.42.2.4 intel386.h
*** src/m/intel386.h	27 Feb 2008 23:32:04 -0000	1.42.2.4
--- src/m/intel386.h	6 Sep 2008 04:51:04 -0000
*************** NOTE-END */
*** 215,221 ****
  #endif
  
  #if defined (MAC_OSX) || defined (DARWIN)
! #ifdef _LP64
  /* For Intel Mac, with CC='gcc -arch x86_64'.  */
  #define NO_ARG_ARRAY
  #endif
--- 215,221 ----
  #endif
  
  #if defined (MAC_OSX) || defined (DARWIN)
! #if defined (_LP64) || defined (__llvm__)
  /* For Intel Mac, with CC='gcc -arch x86_64'.  */
  #define NO_ARG_ARRAY
  #endif

I'm not sure if it is applicable to all versions of LLVM-based
compilers or all target architectures.  So I just put it as a "kludge"
for unofficial ports.

You can also turn on link-time optimization option (-O4) on intel
processors though it takes much more time to build.  IIRC, it didn't
work well for ppc64.

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

Re: Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 05 Sep 2009 11:18:16 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> The second update of the Mac port, which is
> experimental/hackers-only, is also available from

>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1-mac-1.92.tar.gz

I've just put a patch for an experimental implementation of
`get_variation_glyphs' for the font backend driver in the Mac port:

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1-mac-1.92-uvs.patch.gz

This works on Mac OS X 10.5 and 10.6.  So, it is independent of the
Unicode Variation Sequences support introduced by Snow Leopard.
(Actually I tried to use it first, but I couldn't figure out which is
a variation selector in the Default UVS Table, because selectors
without UVS entries produce the same result with the default one.)

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

Re: Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[CHENG Gao]

*On Sat, 05 Sep 2009 11:18:16 +0900
* Also sprach YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>:

> The second update of the Mac port, which is experimental/hackers-only,
> is also available from
>
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1-mac-1.92.tar.gz
>
> In addition to the bug fixes and improvements above, it has the
> following experimental feature (only for Mac OS X 10.6 Snow Leopard):
>
> *** New implementation for the `select' emulation using Grand Central
> Dispatch instead of CFSocket.  It is enabled by default if built for
> Mac OS X 10.6.  If you find it unstable/problematic, then you can turn
> it off by compiling with "-DSELECT_USE_GCD=0".
>
> There is a change in how to report bugs.  Please read `README-mac' in
> the tarball.
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp

I just learned that Apple just open sourced GCD under Apache License,
Version 2.0[1]. If I understand right, Apache License 2.0 is GPLv3
compatible by FSF standard.

So this means Emacs can use it on most platforms it supports (maybe some
day)?


Footnotes: 
[1]  http://libdispatch.macosforge.org/post/libdispatch-is-open-source/

-- 
Volo, non valeo

Re: Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The eighth update of the Carbon+AppKit port is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-22.3-appkit-1.8.tar.gz

** Fixed bugs

*** Conversion between Lisp and NSPasteboard strings doesn't preserve
NUL characters.

*** Mouse face reacts even while tracking Dock menus or Stacks.

*** Control-Q does not work as the quote binding in file dialogs.


The third update of the Mac port, which is experimental/hackers-only,
is also available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1-mac-1.93.tar.gz

In addition to the bug fixes above, it has the following changes:

** Fixed bugs

*** Synthetic bold does not work for bitmap-only fonts on Mac OS X
10.6.

** Improvements

*** New events: wheel-left/right as in W32, and
swipe-up/down/left/right on Mac OS X 10.5.2 and later.

*** The Mac font backend driver now supports `get_variation_glyphs' on
Mac OS X 10.5 and later.  You need some OpenType font containing a
format 14 (Unicode Variation Sequences) subtable in its cmap table.

*** Simplified `select' emulation also for Mac OS X 10.5 and earlier.
Its design is similar to the one in the previous release with Grand
Central Dispatch.

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

Re: Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]

The ninth update of the Carbon+AppKit port is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-22.3-appkit-1.9.tar.gz

** Improvements

*** When delete-selection-mode is enabled, then the active region is
hidden while the marked text is being shown (so "Reverse conversion"
in Kotoeri looks better).

*** The current cursor position may be returned for a character
position query for text input even if the marked text is not displayed
or handled at the Lisp level yet (so auxiliary windows in AquaSKK 4
are placed better.)


The fourth update of the Mac port, which is experimental/hackers-only,
is also available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1-mac-1.94.tar.gz

In addition to the improvements above, it has the following changes:

** Fixed bugs

*** Kill/yank in tty frames causes an error.

** Improvements

*** SVG images are supported via WebKit on Mac OS X 10.4 and later.
If you have librsvg installed and you want to use WebKit for rendering
SVG images, then you need to specify --without-rsvg as a configure
option.

*** The Mac font backend driver now supports `get_variation_glyphs'
also on Mac OS X 10.4 and earlier.

*** Ideographic Variation Sequences (IVSes) also work for Hiragino
fonts, which don't have a format 14 (Unicode Variation Sequences)
subtable in their cmap table.


The attached screenshot shows a comparison of IVS support for Hiragino
among Emacs 23.1 Mac port (top), Safari, and TextEdit (bottom) on Mac
OS X 10.6.1.  Note that TextEdit on Mac OS X 10.6 can display
different glyphs for variants if you use some font containing a format
14 subtable in its cmap table.

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

[-- Attachment #2: variants.png --]
[-- Type: image/png, Size: 15299 bytes --]

Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The fifth update of the Mac port, which is experimental/hackers-only,
is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1.90-mac-1.95.tar.gz

This version is based on Emacs 23.1.90 pretest.

** Fixed bugs

*** Can't get Unicode Variation Sequences subtable for Hanazono font
(2009-12-01, TTF) on Mac OS X 10.4 and earlier.

** Improvements

*** Fullscreen works like with ewmh-compliant X11 window managers.
Note: currently, `fullboth' frames, which don't have a title bar, are
not shown in the window list in the Dock menu.

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

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The sixth update of the Mac port, which is experimental/hackers-only,
is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1.91-mac-1.96.tar.gz

This version is based on Emacs 23.1.91 pretest.

** Fixed bugs

*** The `fullboth' frames, which don't have a title bar, are not shown
in the window list in the Dock menu.

*** Mouse highlighting is not updated on popup (de)activations.

*** With `x-select-font', the first click in a list sometimes results
in a wrong selection.

*** Command line options specifying temporary preferences settings
(e.g., -AppleDisplayScaleFactor 1.25 -AppleAntiAliasingThreshold 14),
just as in other Cocoa applications, are regarded as if they are
specifying filenames to edit.

** Improvements

*** Change of text smoothing threshold setting in the Appearance pane
of the System Preferences is now reflected immediately.

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

Re: Emacs 23 Mac port

[Leo]

On 2009-12-31 11:46 +0000, YAMAMOTO Mitsuharu wrote:
> The sixth update of the Mac port, which is experimental/hackers-only,
> is now available from
>
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1.91-mac-1.96.tar.gz
>
> This version is based on Emacs 23.1.91 pretest.

I just tried this for the first time and it seems to be better than the
official ns port. in particular, ispell is extremely fast and the
fullscreen is superb.

However, my old font setting under ns does not seem to work:

  (create-fontset-from-fontset-spec
   (mapconcat 'identity
              '("-*-*-*-*-*-*-13-*-*-*-*-*-fontset-custom"
                "latin:-*-DejaVu_Sans_Mono-*-*-*-*-13-*-*-*-*-*-iso10646-1"
                ;; "greek:-*-Lucida_Grande-*-*-*-*-13-*-*-*-*-*-iso10646-1"
                "han:-*-STHeiti-*-*-*-*-13-*-*-*-*-*-iso10646-1"
                "cjk-misc:-*-Hiragino_Kaku_Gothic_ProN-*-*-*-*-13-*-*-*-*-*-iso10646-1"
                )
              ","))

  (set-frame-font "fontset-custom")

it produced an error that fontset-custom is unknown.

Also is there a way to disable tool-bar in such a way that it does not
display the tool-bar first and then hide it and shrink the window as
is done by (tool-bar-mode -1).

Thanks.
Leo

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 02 Jan 2010 01:27:32 +0000, Leo <sdl.web@gmail.com> said:

> However, my old font setting under ns does not seem to work:

Try replacing "_" in the family names with " ".  The font backend
driver of the Mac port, as well as the ones in X11, doesn't avoid
spaces in font family names.

To get font family names, you can use `(font-family-list)' or check
the result of `(x-select-font)' as in the GTK+ build.

> Also is there a way to disable tool-bar in such a way that it does not
> display the tool-bar first and then hide it and shrink the window as
> is done by (tool-bar-mode -1).

I assume you are using initial-frame-alist or something like
that.  This behavior can also be observed in the GTK+ build, and
a known workaround is to use X resources.  It is also applicable
to the Mac port.

  For permanent setting:
  $ defaults write org.gnu.Emacs 'Emacs*ToolBar' 0
  (This corresponds to adding the line 'Emacs*ToolBar:0' into
   ~/.Xresources)

  For temporary setting:
  $ .../Emacs.app/Contents/MacOS/Emacs -xrm 'Emacs*ToolBar:0'

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

Re: Emacs 23 Mac port

[Leo]

On 2010-01-02 04:21 +0000, YAMAMOTO Mitsuharu wrote:
>>>>>> On Sat, 02 Jan 2010 01:27:32 +0000, Leo <sdl.web@gmail.com> said:
>
>> However, my old font setting under ns does not seem to work:
>
> Try replacing "_" in the family names with " ".  The font backend
> driver of the Mac port, as well as the ones in X11, doesn't avoid
> spaces in font family names.
>
> To get font family names, you can use `(font-family-list)' or check
> the result of `(x-select-font)' as in the GTK+ build.

Many thanks.

>> Also is there a way to disable tool-bar in such a way that it does not
>> display the tool-bar first and then hide it and shrink the window as
>> is done by (tool-bar-mode -1).
>
> I assume you are using initial-frame-alist or something like
> that.  This behavior can also be observed in the GTK+ build, and
> a known workaround is to use X resources.  It is also applicable
> to the Mac port.
>
>   For permanent setting:
>   $ defaults write org.gnu.Emacs 'Emacs*ToolBar' 0
>   (This corresponds to adding the line 'Emacs*ToolBar:0' into
>    ~/.Xresources)

This is another plus. I like it and I now use it to set tool-bar off and
the default font ;) It seems the ns port does not even support this.
Many thanks.

>   For temporary setting:
>   $ .../Emacs.app/Contents/MacOS/Emacs -xrm 'Emacs*ToolBar:0'
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp

I don't know if this is a bug but it was surprising when I first saw it.

For example, when using emacs to edit .TeX files with AUCTeX which
allows you to view the output pdf (AUCTeX compiles to pdf files if
TeX-pdf-mode is t) file with key 'C-c C-v'. If you open a pdf file that
is not already open through 'C-c C-v', all pdf windows will be raised
above the Emacs window and obscure it, giving a feeling that Emacs just
disappeared (I thought it crashed in the first time). If the pdf file is
already opened, there's no such problem.

The ns port has this behaviour, only the new pdf window is raised and
the emacs window is still visible (i.e. it is consistent whether the
file is opened or not).

This emacs port provides a close feature set to that from GNU/Linux.
Thanks a million to make it available to emacs 23. I will use it heavily
and see if it is also stable.

Best wishes,

Leo

Re: Emacs 23 Mac port

[Leo]

On 2010-01-02 10:19 +0000, Leo wrote:
> I don't know if this is a bug but it was surprising when I first saw it.
>
> For example, when using emacs to edit .TeX files with AUCTeX which
> allows you to view the output pdf (AUCTeX compiles to pdf files if
> TeX-pdf-mode is t) file with key 'C-c C-v'. If you open a pdf file that
> is not already open through 'C-c C-v', all pdf windows will be raised
> above the Emacs window and obscure it, giving a feeling that Emacs just
> disappeared (I thought it crashed in the first time). If the pdf file is
> already opened, there's no such problem.
>
> The ns port has this behaviour, only the new pdf window is raised and
> the emacs window is still visible (i.e. it is consistent whether the
> file is opened or not).

Forget about this. Actually ns port behaves the same in this respect.

Sorry for this noise.

Leo

Re: Emacs 23 Mac port

[Leo]

On 2009-12-31 11:46 +0000, YAMAMOTO Mitsuharu wrote:
> The sixth update of the Mac port, which is experimental/hackers-only,
> is now available from
>
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1.91-mac-1.96.tar.gz
>
> This version is based on Emacs 23.1.91 pretest.

I configured Emacs.app as the default mailer and found a bug. Here's how
to reproduce:

 1. Emacs -q
 2. Click a mailto link on any website for example
    http://www.ianr.unl.edu/internet/mailto.html and A mail buffer will
    pop up.
 3. C-c C-k

And you will see 'C-c C-k is undefined' in the echo area. Subsequent
'C-c C-k' will do what it is supposed to do in the mail buffer. But the
first one is tested in the buffer before the mail buffer. For example,
if before the mail buffer appears, the point is in an rcirc buffer, the
fist C-c C-k in the mail buffer will invoke rcirc-cmd-kick.

Best wishes,

Leo

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 02 Jan 2010 20:56:03 +0000, Leo <sdl.web@gmail.com> said:

> I configured Emacs.app as the default mailer and found a bug. Here's how
> to reproduce:

>  1. Emacs -q
>  2. Click a mailto link on any website for example
>     http://www.ianr.unl.edu/internet/mailto.html and A mail buffer will
>     pop up.
>  3. C-c C-k

> And you will see 'C-c C-k is undefined' in the echo area. Subsequent
> 'C-c C-k' will do what it is supposed to do in the mail buffer. But the
> first one is tested in the buffer before the mail buffer. For example,
> if before the mail buffer appears, the point is in an rcirc buffer, the
> fist C-c C-k in the mail buffer will invoke rcirc-cmd-kick.

This seems to be because Apple event handlers are bound in
special-event-map.  A similar behavior can be observed with
dran-and-drop, which is also bound in special-event-map, even on
the GTK+ build.

  1. emacs -Q
  2. Drag-and-drop some C file (such as foo.c) into the Emacs frame.
  3. Click the Emacs frame title bar to get focus.
  4. C-c C-e
     => not found though it is bound to c-macro-expand
  5. C-c C-e
     => handled correctly

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

Re: Emacs 23 Mac port

[Leo]

On 2010-01-03 02:45 +0000, YAMAMOTO Mitsuharu wrote:
> This seems to be because Apple event handlers are bound in
> special-event-map.  A similar behavior can be observed with
> dran-and-drop, which is also bound in special-event-map, even on
> the GTK+ build.
>
>   1. emacs -Q
>   2. Drag-and-drop some C file (such as foo.c) into the Emacs frame.
>   3. Click the Emacs frame title bar to get focus.
>   4. C-c C-e
>      => not found though it is bound to c-macro-expand
>   5. C-c C-e
>      => handled correctly

Thank you. I filed a bug report on this.

Best wishes,
Leo

Re: Emacs 23 Mac port

[Stefan Monnier]

Could you move these discussions to some other mailing list, please?


        Stefan


>>>>> "Leo" == Leo  <sdl.web@gmail.com> writes:
> On 2009-12-31 11:46 +0000, YAMAMOTO Mitsuharu wrote:
>> The sixth update of the Mac port, which is experimental/hackers-only,
>> is now available from
>> 
>> ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1.91-mac-1.96.tar.gz
>> 
>> This version is based on Emacs 23.1.91 pretest.

> I configured Emacs.app as the default mailer and found a bug. Here's how
> to reproduce:

>  1. Emacs -q
>  2. Click a mailto link on any website for example
>     http://www.ianr.unl.edu/internet/mailto.html and A mail buffer will
>     pop up.
>  3. C-c C-k

> And you will see 'C-c C-k is undefined' in the echo area. Subsequent
> 'C-c C-k' will do what it is supposed to do in the mail buffer. But the
> first one is tested in the buffer before the mail buffer. For example,
> if before the mail buffer appears, the point is in an rcirc buffer, the
> fist C-c C-k in the mail buffer will invoke rcirc-cmd-kick.

> Best wishes,

> Leo

Re: Emacs 23 Mac port

[Jan Djärv]

YAMAMOTO Mitsuharu skrev:

> This seems to be because Apple event handlers are bound in
> special-event-map.  A similar behavior can be observed with
> dran-and-drop, which is also bound in special-event-map, even on
> the GTK+ build.
> 
>   1. emacs -Q
>   2. Drag-and-drop some C file (such as foo.c) into the Emacs frame.
>   3. Click the Emacs frame title bar to get focus.
>   4. C-c C-e
>      => not found though it is bound to c-macro-expand
>   5. C-c C-e
>      => handled correctly
> 

I've checked in a fix for this.  Keymaps weren't recalculated after a command 
from the special event map was run.

	Jan D.

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 12 Jan 2010 09:16:23 +0100, Jan Djärv <jan.h.d@swipnet.se> said:

>> This seems to be because Apple event handlers are bound in
>> special-event-map.  A similar behavior can be observed with
>> dran-and-drop, which is also bound in special-event-map, even on
>> the GTK+ build.
>> 
>> 1. emacs -Q
>> 2. Drag-and-drop some C file (such as foo.c) into the Emacs frame.
>> 3. Click the Emacs frame title bar to get focus.
>> 4. C-c C-e
>> => not found though it is bound to c-macro-expand
>> 5. C-c C-e
>> => handled correctly
>> 

> I've checked in a fix for this.  Keymaps weren't recalculated after
> a command from the special event map was run.

Thanks.  But then a special event such as SIGUSR1 cancels an
incomplete key sequence being typed.  How about doing this only when
the current buffer is changed by the special event?

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

=== modified file 'src/keyboard.c'
*** src/keyboard.c	2010-01-12 08:42:52 +0000
--- src/keyboard.c	2010-01-12 08:46:27 +0000
***************
*** 3187,3192 ****
--- 3187,3193 ----
        int count = SPECPDL_INDEX ();
        record_single_kboard_state ();
  #endif
+       struct buffer *prev_buffer = current_buffer;
  
        last_input_event = c;
        Fcommand_execute (tem, Qnil, Fvector (1, &last_input_event), Qt);
***************
*** 3205,3214 ****
        unbind_to (count, Qnil);
  #endif
  
!       /* The command may have changed the keymaps.  Pretend there is input
!          in another keyboard and return.  This will recalculate keymaps.  */
!       c = make_number (-2);
!       goto exit;
      }
  
    /* Handle things that only apply to characters.  */
--- 3206,3221 ----
        unbind_to (count, Qnil);
  #endif
  
!       if (current_buffer != prev_buffer)
! 	{
! 	  /* The command may have changed the keymaps.  Pretend there
! 	     is input in another keyboard and return.  This will
! 	     recalculate keymaps.  */
! 	  c = make_number (-2);
! 	  goto exit;
! 	}
!       else
! 	goto retry;
      }
  
    /* Handle things that only apply to characters.  */

Re: Emacs 23 Mac port

[Jan Djärv]

YAMAMOTO Mitsuharu skrev:
>>>>>> On Tue, 12 Jan 2010 09:16:23 +0100, Jan Djärv <jan.h.d@swipnet.se> said:
> 
>>> This seems to be because Apple event handlers are bound in
>>> special-event-map.  A similar behavior can be observed with
>>> dran-and-drop, which is also bound in special-event-map, even on
>>> the GTK+ build.
>>>
>>> 1. emacs -Q
>>> 2. Drag-and-drop some C file (such as foo.c) into the Emacs frame.
>>> 3. Click the Emacs frame title bar to get focus.
>>> 4. C-c C-e
>>> => not found though it is bound to c-macro-expand
>>> 5. C-c C-e
>>> => handled correctly
>>>
> 
>> I've checked in a fix for this.  Keymaps weren't recalculated after
>> a command from the special event map was run.
> 
> Thanks.  But then a special event such as SIGUSR1 cancels an
> incomplete key sequence being typed.  How about doing this only when
> the current buffer is changed by the special event?
> 

It makes sense.  Can you install it?
A dnd in the middle of a key sequence would still cancel the sequence, but I 
guess we can't do any better in that case?

	Jan D.


> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
> 
> === modified file 'src/keyboard.c'
> *** src/keyboard.c	2010-01-12 08:42:52 +0000
> --- src/keyboard.c	2010-01-12 08:46:27 +0000
> ***************
> *** 3187,3192 ****
> --- 3187,3193 ----
>         int count = SPECPDL_INDEX ();
>         record_single_kboard_state ();
>   #endif
> +       struct buffer *prev_buffer = current_buffer;
>   
>         last_input_event = c;
>         Fcommand_execute (tem, Qnil, Fvector (1, &last_input_event), Qt);
> ***************
> *** 3205,3214 ****
>         unbind_to (count, Qnil);
>   #endif
>   
> !       /* The command may have changed the keymaps.  Pretend there is input
> !          in another keyboard and return.  This will recalculate keymaps.  */
> !       c = make_number (-2);
> !       goto exit;
>       }
>   
>     /* Handle things that only apply to characters.  */
> --- 3206,3221 ----
>         unbind_to (count, Qnil);
>   #endif
>   
> !       if (current_buffer != prev_buffer)
> ! 	{
> ! 	  /* The command may have changed the keymaps.  Pretend there
> ! 	     is input in another keyboard and return.  This will
> ! 	     recalculate keymaps.  */
> ! 	  c = make_number (-2);
> ! 	  goto exit;
> ! 	}
> !       else
> ! 	goto retry;
>       }
>   
>     /* Handle things that only apply to characters.  */

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 12 Jan 2010 10:28:46 +0100, Jan Djärv <jan.h.d@swipnet.se> said:

>>> I've checked in a fix for this.  Keymaps weren't recalculated after
>>> a command from the special event map was run.
>> 
>> Thanks.  But then a special event such as SIGUSR1 cancels an
>> incomplete key sequence being typed.  How about doing this only when
>> the current buffer is changed by the special event?
>> 

> It makes sense.  Can you install it?

Done, and Bug#5295 closed.
(Oops, I should have added the bug# to the commit log.)

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

Re: Emacs 23 Mac port

[Stefan Monnier]

> Thanks.  But then a special event such as SIGUSR1 cancels an
> incomplete key sequence being typed.  How about doing this only when
> the current buffer is changed by the special event?

IIRC the general approach to these kinds of problems in
read-key-sequence is to only recompute the initial state if the current
key-sequence is still empty.
I.e. rather than check whether the special event has changed current
buffer, we would instead check whether the keybuf is still empty.


        Stefan

Re: Emacs 23 Mac port

[Jan Djärv]

Stefan Monnier skrev 2010-01-12 15.15:
>> Thanks.  But then a special event such as SIGUSR1 cancels an
>> incomplete key sequence being typed.  How about doing this only when
>> the current buffer is changed by the special event?
>
> IIRC the general approach to these kinds of problems in
> read-key-sequence is to only recompute the initial state if the current
> key-sequence is still empty.
> I.e. rather than check whether the special event has changed current
> buffer, we would instead check whether the keybuf is still empty.
>

But that can be wrong too.  In *scratch*:
C-c <drop .c-file> C-e

	Jan D.

Re: Emacs 23 Mac port

[Stefan Monnier]

>>> Thanks.  But then a special event such as SIGUSR1 cancels an
>>> incomplete key sequence being typed.  How about doing this only when
>>> the current buffer is changed by the special event?
>> IIRC the general approach to these kinds of problems in
>> read-key-sequence is to only recompute the initial state if the current
>> key-sequence is still empty.
>> I.e. rather than check whether the special event has changed current
>> buffer, we would instead check whether the keybuf is still empty.
> But that can be wrong too.  In *scratch*:
> C-c <drop .c-file> C-e

In which sense would it be wrong?  What would you consider to be "right"?


        Stefan

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 12 Jan 2010 09:15:11 -0500, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> Thanks.  But then a special event such as SIGUSR1 cancels an
>> incomplete key sequence being typed.  How about doing this only
>> when the current buffer is changed by the special event?

> IIRC the general approach to these kinds of problems in
> read-key-sequence is to only recompute the initial state if the
> current key-sequence is still empty.  I.e. rather than check whether
> the special event has changed current buffer, we would instead check
> whether the keybuf is still empty.

Well, at least, it seems to be much cleaner for read_char just to
return a special code (instead of -2) indicating a command is executed
via special event map, and let the caller determine what to do for
that case.

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

Re: Emacs 23 Mac port

[Jan D.]

On 2010-01-12 22:22, Stefan Monnier wrote:
>>>> Thanks.  But then a special event such as SIGUSR1 cancels an
>>>> incomplete key sequence being typed.  How about doing this only when
>>>> the current buffer is changed by the special event?
>>> IIRC the general approach to these kinds of problems in
>>> read-key-sequence is to only recompute the initial state if the current
>>> key-sequence is still empty.
>>> I.e. rather than check whether the special event has changed current
>>> buffer, we would instead check whether the keybuf is still empty.
>> But that can be wrong too.  In *scratch*:
>> C-c<drop .c-file>  C-e
>
> In which sense would it be wrong?  What would you consider to be "right"?
>
>

Well, given that we recompute only if the key-sequence is empty, the 
case above will then behave as the original bug.  I guess right would be 
to somehow detect that ketmaps need to be recomputed and do so without 
discarding any ongoing key sequence.

I'm just playing devils advocate here.  I don't think we can get it 100% 
correct easily.  Recompute on buffer change gets some border cases 
right, recompute on empty key-sequence gets some other border cases 
right.  But for the majority of cases, they are probably equivalent.

	Jan D.

Re: Emacs 23 Mac port

[Jan D.]

On 2010-01-13 00:35, YAMAMOTO Mitsuharu wrote:
>>>>>> On Tue, 12 Jan 2010 09:15:11 -0500, Stefan Monnier<monnier@iro.umontreal.ca>  said:
>
>>> Thanks.  But then a special event such as SIGUSR1 cancels an
>>> incomplete key sequence being typed.  How about doing this only
>>> when the current buffer is changed by the special event?
>
>> IIRC the general approach to these kinds of problems in
>> read-key-sequence is to only recompute the initial state if the
>> current key-sequence is still empty.  I.e. rather than check whether
>> the special event has changed current buffer, we would instead check
>> whether the keybuf is still empty.
>
> Well, at least, it seems to be much cleaner for read_char just to
> return a special code (instead of -2) indicating a command is executed
> via special event map, and let the caller determine what to do for
> that case.

The problem is read_char is called from many places.

	Jan D.

Re: Emacs 23 Mac port

[Stefan Monnier]

>>>>> Thanks.  But then a special event such as SIGUSR1 cancels an
>>>>> incomplete key sequence being typed.  How about doing this only when
>>>>> the current buffer is changed by the special event?
>>>> IIRC the general approach to these kinds of problems in
>>>> read-key-sequence is to only recompute the initial state if the current
>>>> key-sequence is still empty.
>>>> I.e. rather than check whether the special event has changed current
>>>> buffer, we would instead check whether the keybuf is still empty.
>>> But that can be wrong too.  In *scratch*:
>>> C-c<drop .c-file>  C-e
>> In which sense would it be wrong?  What would you consider to be "right"?
> Well, given that we recompute only if the key-sequence is empty, the case
> above will then behave as the original bug.

But it's very different, because the C-c C-e sequence was started in the
*scratch* buffer, so it's not at all obvious that it should be looked up
and run in the new buffer.

> I guess right would be to somehow detect that ketmaps need to be
> recomputed and do so without discarding any ongoing key sequence.

I don't think there is such a thing as "right" for such a case.  So the
only thing that truly matters is that we don't end up looking up the
command in the keymap of buffer A and then running the comand in buffer
B (which would clearly be wrong).  Actually, this should not only be
true of "current-buffer" but of position as well (i.e. if the
special-event-map causes point to move or text to change such that
the keymaps specified by text-propeties change, the same reasoning
applies).

For drag&drop, we could just throw away the partially-started key
sequence, but for SIGUSR1 (more likely to occur without direct user
intervention), this is not a good idea.


        Stefan

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The seventh update of the Mac port, which is experimental/hackers-only,
is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1.92-mac-1.97.tar.gz

This version is based on Emacs 23.1.92 pretest.

** Fixed bugs

*** Turning on the toolbar in a fullscreen frame leaves garbage if it
has non-zero internal border width.

** Improvements

*** When the clipboard has both textual and image data, yank inserts
the former and push both into the kill ring so the latter can be
inserted with yank-pop afterwards.

*** Use non-integral x positions for displaying antialiased
proportional fonts.  You can see the difference by putting the box
cursor over Helvetica 12pt `I', whose ideal width is 3.33398 but
displayed with the rounded width 3, for example.

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

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The eighth update of the Mac port, which is experimental/hackers-only,
is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1.93-mac-1.98.tar.gz

This version is based on Emacs 23.1.93 pretest.

** Fixed bugs

*** Menu selection via search field in the Help menu doesn't work on
Mac OS X 10.6.
Note: this seems to be still unstable on Mac OS X 10.5.8, crashing at
the function TestMenuSystemAttributes in the HIToolbox framework.
I've experienced similar crashes even with Safari on that version.

*** The function `menu-bar-open' does not activate the menu bar.

*** Menu bar does not get updated after Command-H -> Dock icon click
on Mac OS X 10.5.

** Improvements

*** Scroll bars are excluded from flashed area for visible bell in a
consistent way.

*** Several keyboard shortcuts (notably those for Keyboard Navigation)
listed in System Preferences now work.

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

Re: Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The tenth update of Emacs 22 Carbon+AppKit port is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-22.3-appkit-1.10.tar.gz

The list of changes is omitted here; mostly bugfixes backported from
Emacs 23 Mac port 1.96 - 1.99.

Though the Carbon port is part of the official GNU Emacs 22.3
distribution, I'd suggest avoiding it on Mac OS X 10.6 and using the
Carbon+AppKit port above instead if you do need native GUI support for
Emacs 22.  At least Mac OS X 10.6.2 has several bugs in the GUI
portions of the Carbon framework, and that causes some annoying
glitches in the Carbon port.  Meanwhile the Carbon+AppKit port uses
the Cocoa AppKit framework for GUI, which seems to be supported better
than the Carbon counterpart in Mac OS X 10.6.


The ninth update of the Mac port, which is experimental/hackers-only,
is also available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1.94-mac-1.99.tar.gz

This version is based on Emacs 23.1.94 pretest.

** Fixed bugs

*** Dictionary popped up with Command-Control-D is misplaced when a
word in a partially-visible line is looked up.

*** Drag-n-dropping a file into a Message buffer opens the file
instead of adding it as an attachment.  Reported by Leo.

*** Crash when a text is drag-n-dropped into the Dock icon.
Reported by Leo.

*** Not registered as a service provider on Mac OS X 10.4 and earlier,
even if there is no other instance of running Emacs.

*** Modifier mapping for the `fn' key does not work with the `A' key.

** Improvements

*** Reverse conversion in Kotoeri works even without selection.
Hitting Eisu/Kana key on JIS keyboard (or Control-Shift-;/J/K on US
keyboard) twice also works.

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

Re: Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[Giovanni Lanzani]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> The ninth update of the Mac port, which is experimental/hackers-only,
> is also available from
>
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1.94-mac-1.99.tar.gz
>
> This version is based on Emacs 23.1.94 pretest.

Dear Yamamoto-san, will this version build also the emacsclient?

Thanks

Giovanni

Re: Emacs 22 Carbon+AppKit port and Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 15 Mar 2010 19:12:10 +0100, Giovanni Lanzani <ulissesroc@gmail.com> said:

>> The ninth update of the Mac port, which is
>> experimental/hackers-only, is also available from
>> 
>> ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1.94-mac-1.99.tar.gz
>> 
>> This version is based on Emacs 23.1.94 pretest.

> Dear Yamamoto-san, will this version build also the emacsclient?

I suppose so.  But if you find a bug with respect this, and if it is
specific to the Mac port, then please report it to the address written
in the README-mac file in the tarball:

  *** IMPORTANT NOTE ***

  (snip)

  Also, if you find a bug, then please try to reproduce it with some
  official builds such as X11 or NS (Cocoa).  If it turns out to be
  specific to the Mac port, then please report it to
  "mituharu+bug-gnu-emacs-mac@math.s.chiba-u.ac.jp".  Otherwise (i.e.,
  it is also reproducible with official ones), report it using M-x
  report-emacs-bug *USING THE OFFICIAL BUILD* as such.

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

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The tenth update of the Mac port, which is experimental/hackers-only,
is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1.95-mac-1.990.tar.gz

This version is based on Emacs 23.1.95 pretest.

** Fixed bugs

*** Crash when showing a tooltip on a secondary monitor.

*** Can't quit while establishing a TCP connection.
Apply a fix for Bug#5723 as well as Helmut Eller's fix for Bug#5173.

** Improvements

*** When a maximized frame is moved with title bar dragging on a
multiple monitor environment, the destination monitor is determined by
the mouse position at the end of dragging.  If such a frame is moved
programmatically, the destination monitor is determined by the maximum
area of the contained part of the frame as before.

*** Menu item "Open Selected File in Emacs" is shown in Services or
context menu of other applications by default on Mac OS X 10.6 when
absolute pathname-like text is selected.

*** Emacs info nodes are accessible via search field in the Help menu
if compiled and run on Mac OS X 10.6.

*** "Click in the scroll bar to: Jump to the spot that's clicked"
setting in the System Preferences is supported.

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

Re: Emacs 23 Mac port

[Leo]

On 2010-04-03 03:26 +0100, YAMAMOTO Mitsuharu wrote:
> The tenth update of the Mac port, which is experimental/hackers-only,
> is now available from
>
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1.95-mac-1.990.tar.gz
>
> This version is based on Emacs 23.1.95 pretest.

Both make and make bootstrap give me this error:

Loading /Users/Shared/sources/emacs23.1.95/lisp/term/mac-win.el (source)...
Symbol's value as variable is void: image-load-path
make[2]: *** [bootstrap-emacs] Error 255
make[1]: *** [src] Error 2
make: *** [bootstrap] Error 2

Ideas?

Leo

Re: Emacs 23 Mac port

[Leo]

On 2010-04-03 15:55 +0100, Leo wrote:
> Both make and make bootstrap give me this error:
>
> Loading /Users/Shared/sources/emacs23.1.95/lisp/term/mac-win.el (source)...
> Symbol's value as variable is void: image-load-path
> make[2]: *** [bootstrap-emacs] Error 255
> make[1]: *** [src] Error 2
> make: *** [bootstrap] Error 2
>
> Ideas?
>
> Leo

Somehow this was resolved.

Leo

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 03 Apr 2010 15:55:43 +0100, Leo <sdl.web@gmail.com> said:

> On 2010-04-03 03:26 +0100, YAMAMOTO Mitsuharu wrote:
>> The tenth update of the Mac port, which is experimental/hackers-only,
>> is now available from
>> 
>> ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1.95-mac-1.990.tar.gz
>> 
>> This version is based on Emacs 23.1.95 pretest.

> Both make and make bootstrap give me this error:

> Loading /Users/Shared/sources/emacs23.1.95/lisp/term/mac-win.el (source)...
> Symbol's value as variable is void: image-load-path
> make[2]: *** [bootstrap-emacs] Error 255
> make[1]: *** [src] Error 2
> make: *** [bootstrap] Error 2

I could reproduce it only for `make bootstrap', which is not necessary
for the standard installation instruction.  Anyway, I think the
following patch will fix the bootstrap problem.

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

=== modified file 'lisp/term/mac-win.el'
*** lisp/term/mac-win.el	2010-04-01 23:46:17 +0000
--- lisp/term/mac-win.el	2010-04-04 04:34:32 +0000
***************
*** 1574,1581 ****
  
  ;;; Spotlight for Help (Mac OS X 10.6 and later, experimental)
  
! (eval-when-compile
!   (require 'info))
  
  (defvar mac-help-topics)
  
--- 1574,1583 ----
  
  ;;; Spotlight for Help (Mac OS X 10.6 and later, experimental)
  
! (declare-function info-initialize "info" nil)
! (declare-function Info-find-file "info" (filename &optional noerror))
! (declare-function Info-toc-build "info" (file))
! (declare-function Info-virtual-index "info" (topic))
  
  (defvar mac-help-topics)
  

Re: Emacs 23 Mac port

[Leo]

On 2010-04-04 06:36 +0100, YAMAMOTO Mitsuharu wrote:
> I could reproduce it only for `make bootstrap', which is not necessary
> for the standard installation instruction.  Anyway, I think the
> following patch will fix the bootstrap problem.

Thanks for the patch.

Leo

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The eleventh update of the Mac port, which is experimental/hackers-only,
is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1.96-mac-1.991.tar.gz

This version is based on Emacs 23.1.96 pretest.

I've just noticed that Command-Control-D, which has been used for
looking up a word under the mouse pointer in dictionary since Mac OS X
10.4, now looks up a word around the cursor if the mouse pointer is
invisible (e.g., just after some keyboard input) on Mac OS X 10.6.

** Fixed bugs

*** 64-bit binary built on Mac OS X 10.5 does not run on 10.6.

*** `make bootstrap' fails (though it is not required for normal
installation).  Reported by Leo.

** Improvements

*** `do-applescript' regards a given multibyte string as Unicode text.
It behaves as in Emacs 22 if the script is given as a unibyte string.

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

Re: Emacs 23 Mac port

[Leo]

On 2010-04-20 10:08 +0100, YAMAMOTO Mitsuharu wrote:
> *** `do-applescript' regards a given multibyte string as Unicode text.
> It behaves as in Emacs 22 if the script is given as a unibyte string.

Thank you for this.
Leo

Re: Emacs 23 Mac port

[Leo]

On 2010-04-20 10:08 +0100, YAMAMOTO Mitsuharu wrote:
> The eleventh update of the Mac port, which is experimental/hackers-only,
> is now available from
>
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1.96-mac-1.991.tar.gz
>
> This version is based on Emacs 23.1.96 pretest.

I sometimes run into alias files in dired and emacs treat them like a
normal file. Do you think this can be fixed? Thank you.

Leo

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 28 Apr 2010 09:57:15 +0100, Leo <sdl.web@gmail.com> said:

> I sometimes run into alias files in dired and emacs treat them like
> a normal file. Do you think this can be fixed? Thank you.

Perhaps do-applescript can be used for resolving an alias file like:

(do-applescript "tell application \"Finder\" to get POSIX path of (the
 original item of (the POSIX file \"SOME_ALIAS_FILE\" as alias) as alias)")

but this requires quoting and unquoting file name strings.

I'll add `mac-file-alias-p', which is supposed to be parallel to
`file-symlink-p', to the next release.  This would enable you to
advise some dired function, I guess.

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

=== modified file 'src/mac.c'
*** src/mac.c	2010-04-15 00:55:57 +0000
--- src/mac.c	2010-04-29 03:18:20 +0000
***************
*** 1826,1831 ****
--- 1826,1833 ----
  }
  
  \f
+ Lisp_Object Qmac_file_alias_p;
+ 
  void
  initialize_applescript ()
  {
***************
*** 2044,2049 ****
--- 2046,2103 ----
    return Qt;
  }
  
+ DEFUN ("mac-file-alias-p", Fmac_file_alias_p, Smac_file_alias_p, 1, 1, 0,
+        doc: /* Return non-nil if file FILENAME is the name of an alias file.
+ The value is the file referred to by the alias file, as a string.
+ Otherwise it returns nil.
+ 
+ This function returns t when given the name of an alias file
+ containing a unresolvable alias.  */)
+      (filename)
+      Lisp_Object filename;
+ {
+   OSStatus err;
+   Lisp_Object handler, result = Qnil;
+   FSRef fref;
+ 
+   CHECK_STRING (filename);
+   filename = Fexpand_file_name (filename, Qnil);
+ 
+   /* If the file name has special constructs in it,
+      call the corresponding file handler.  */
+   handler = Ffind_file_name_handler (filename, Qmac_file_alias_p);
+   if (!NILP (handler))
+     return call2 (handler, Qmac_file_alias_p, filename);
+ 
+   BLOCK_INPUT;
+   err = FSPathMakeRef (SDATA (ENCODE_FILE (filename)), &fref, NULL);
+   if (err == noErr)
+     {
+       Boolean alias_p = false, folder_p;
+ 
+       err = FSResolveAliasFileWithMountFlags (&fref, false,
+ 					      &folder_p, &alias_p,
+ 					      kResolveAliasFileNoUI);
+       if (err != noErr)
+ 	result = Qt;
+       else if (alias_p)
+ 	{
+ 	  char buf[MAXPATHLEN];
+ 
+ 	  err = FSRefMakePath (&fref, buf, sizeof (buf));
+ 	  if (err == noErr)
+ 	    {
+ 	      result = make_unibyte_string (buf, strlen (buf));
+ 	      if (buf[0] == '/' && index (buf, ':'))
+ 		result = concat2 (build_string ("/:"), result);
+ 	      result = DECODE_FILE (result);
+ 	    }
+ 	}
+     }
+   UNBLOCK_INPUT;
+ 
+   return result;
+ }
  
  /* Moving files to the system recycle bin.
     Used by `move-file-to-trash' instead of the default moving to ~/.Trash  */
***************
*** 3790,3795 ****
--- 3844,3852 ----
    Qdictionary = intern_c_string ("dictionary");	staticpro (&Qdictionary);
    Qdescription = intern_c_string ("description"); staticpro (&Qdescription);
  
+   Qmac_file_alias_p = intern_c_string ("mac-file-alias-p");
+   staticpro (&Qmac_file_alias_p);
+ 
    Qxml = intern_c_string ("xml");
    staticpro (&Qxml);
  
***************
*** 3823,3828 ****
--- 3880,3886 ----
    defsubr (&Smac_set_file_type);
    defsubr (&Smac_get_file_creator);
    defsubr (&Smac_get_file_type);
+   defsubr (&Smac_file_alias_p);
    defsubr (&Ssystem_move_file_to_trash);
    defsubr (&Sdo_applescript);
  

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The twelfth update of the Mac port, which is experimental/hackers-only,
is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.1.97-mac-1.992.tar.gz

This version is based on Emacs 23.1.97 pretest.

** Fixed bugs

*** Tooltips don't respect customized `tooltip' face font setting.

*** Font specs specified for non-ASCII characters in a non-default
fontset are not used in new frames.  Reported by Ichiro Enoki.

** Improvements

*** New function `mac-file-alias-p', which is parallel to
`file-symlink-p'.


Being a port of upcoming Emacs 23.2, the Mac port supports the
following features:

  * The `fullscreen' frame parameter, with all values supported:
    `fullboth', `fullwidth', `fullheight', and 'maximized'.  The
    fullboth frames, which don't have the title bar, still allow us to
    access the menu bar, the Dock (Mac OS X 10.3 and later), and the
    tool bars.  The menu bar can also be activated via
    `menu-bar-open', `Control-F2' (if full keyboard access enabled),
    or `Command-Shift-/' (on Mac OS X 10.5 and later) even for
    fullboth frames where the menu bar is usually hidden.  Changing
    fonts or internal-border-width in fullscreen frames does not
    clutter display.  On multiple monitor environments, one can move
    fullscreen frames to another monitor by setting the `left' and
    `top' frame parameters accordingly.  Attaching/detaching external
    monitors should work even with fullscreen frames.

  * The `sticky' frame parameter, which allows us to keep particular
    frames visible for all Spaces on Mac OS X 10.5 and later.

  * The function `system-move-file-to-trash', which can be specified
    as a value of `delete-by-moving-to-trash'.

  * SVG image display.  This can be done via the WebKit framework on
    Mac OS X 10.4 and later, so you don't need librsvg.

  * Multi-page TIFF images.

  * The function `x-select-font' that provides modal font selection
    dialog in a compatible way with GTK+ and W32 ones.  Note that a
    nonmodal counterpart has been available since Emacs 22 Carbon port
    via `mac-font-panel-mode'.

  * Unicode character display including non-BMP ones.

  * Complex text layout (left-to-right only) and text shaping.  They
    are implemented using the Core Text or NS Text layout engine, so
    you don't need libotf.

  * Glyph selection with variation selectors.  Most of Adobe-Japan1
    ideographic glyphs are accessible via IVSes (Ideographic Variation
    Sequences) even for the OS-bundled Hiragino fonts, which do not
    contain the UVS subtable in their cmap table as of Mac OS X 10.6.

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

Re: Emacs 23 Mac port

[Leo]

On 2010-05-04 03:35 +0100, YAMAMOTO Mitsuharu wrote:
> ** Fixed bugs
>
> *** Tooltips don't respect customized `tooltip' face font setting.
>
> *** Font specs specified for non-ASCII characters in a non-default
> fontset are not used in new frames.  Reported by Ichiro Enoki.
>
> ** Improvements
>
> *** New function `mac-file-alias-p', which is parallel to
> `file-symlink-p'.

Thank you.

The option + command + D to pop up a dictionary panel is useful at
times. However I have gotten used to using command as the meta key. Is
there other way to use the dictionary? Thank you.

Leo

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 04 May 2010 04:10:03 +0100, Leo <sdl.web@gmail.com> said:

> The option + command + D to pop up a dictionary panel is useful at
> times. However I have gotten used to using command as the meta
> key. Is there other way to use the dictionary? Thank you.

You can map this functionality to some key other than
"Command-Control-D".  It has been customizable via the Keyboard
Shortcuts in the System Preferences until Mac OS X 10.5.
Unfortunately, you need to edit
~/Library/Preferences/com.apple.symbolichotkeys.plist on Mac OS X 10.6
manually AT YOUR OWN RISK and re-login.  (I'm not sure if there's some
third-party helper tools.)

http://www.macosxhints.com/article.php?story=20090901102013924
http://www.macosxhints.com/article.php?story=20050801052917667

The 3 numbers in the `parameters' array seems to be char code, key
code, and modifiers, respectively.  The char code is roughly the ASCII
code, but 65535 seems to be OK for function keys.  For the key code,
find kVK_... in
/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Headers/Events.h
The meaning of the modifiers is mentioned in the second page above.

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

Re: Emacs 23 Mac port

[David Reitter]

On May 3, 2010, at 10:35 PM, YAMAMOTO Mitsuharu wrote:

> The twelfth update of the Mac port, which is experimental/hackers-only,

It would be nice to merge the improvements from this port into the NS port so that a larger group of users will eventually benefit from it.

Debugging something else, I came  across a statement with substantial foresight from you in 2005:

> As for Emacs 23, the Carbon port itself might become such that "it's
> difficult to understand why it should be supported".  From the users'
> point of view, it would be confusing to have two ports of Emacs that
> are the same version and have similar look-and-feel, provided that
> both of them are sufficiently stable and functional.

http://lists.gnu.org/archive/html/emacs-devel/2005-09/msg00773.html

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 5 May 2010 11:58:21 -0400, David Reitter <david.reitter@gmail.com> said:

> On May 3, 2010, at 10:35 PM, YAMAMOTO Mitsuharu wrote:
>> The twelfth update of the Mac port, which is
>> experimental/hackers-only,

> It would be nice to merge the improvements from this port into the
> NS port so that a larger group of users will eventually benefit from
> it.

Scratching the surface of the NS port doesn't make sense to me,
because it contains so many "I wouldn't design/implement so" in its
fundamental part.

> Debugging something else, I came across a statement with substantial
> foresight from you in 2005:

>> As for Emacs 23, the Carbon port itself might become such that
>> "it's difficult to understand why it should be supported".  From
>> the users' point of view, it would be confusing to have two ports
>> of Emacs that are the same version and have similar look-and-feel,
>> provided that both of them are sufficiently stable and functional.

> http://lists.gnu.org/archive/html/emacs-devel/2005-09/msg00773.html

I'm no longer maintaining "the Carbon port", and I think that now
(especially after the release of Snow Leopard) people agree it was a
right decision to abandon it early.  I could assign more time for
developing another port that uses Cocoa AppKit, seeing if the NS port
becomes good enough to me.

Also, I said "provided that both of them are sufficiently stable and
functional."  I don't encourage the person who think the NS port is
already sufficiently stable and functional to try the Mac port (the
README-mac file in the tarball says so at the beginning).

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

Re: Emacs 23 Mac port

[covici]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:

> >>>>> On Wed, 5 May 2010 11:58:21 -0400, David Reitter <david.reitter@gmail.com> said:
> 
> > On May 3, 2010, at 10:35 PM, YAMAMOTO Mitsuharu wrote:
> >> The twelfth update of the Mac port, which is
> >> experimental/hackers-only,
> 
> > It would be nice to merge the improvements from this port into the
> > NS port so that a larger group of users will eventually benefit from
> > it.
> 
> Scratching the surface of the NS port doesn't make sense to me,
> because it contains so many "I wouldn't design/implement so" in its
> fundamental part.
> 
> > Debugging something else, I came across a statement with substantial
> > foresight from you in 2005:
> 
> >> As for Emacs 23, the Carbon port itself might become such that
> >> "it's difficult to understand why it should be supported".  From
> >> the users' point of view, it would be confusing to have two ports
> >> of Emacs that are the same version and have similar look-and-feel,
> >> provided that both of them are sufficiently stable and functional.
> 
> > http://lists.gnu.org/archive/html/emacs-devel/2005-09/msg00773.html
> 
> I'm no longer maintaining "the Carbon port", and I think that now
> (especially after the release of Snow Leopard) people agree it was a
> right decision to abandon it early.  I could assign more time for
> developing another port that uses Cocoa AppKit, seeing if the NS port
> becomes good enough to me.
> 
> Also, I said "provided that both of them are sufficiently stable and
> functional."  I don't encourage the person who think the NS port is
> already sufficiently stable and functional to try the Mac port (the
> README-mac file in the tarball says so at the beginning).
> 
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
> 

I would like some port that uses the coco kit, because I use voiceover
and so the current emacs -- or at least one I tried a few months ago was
not accessible at all, so any influence I have in that direction -- I
hope someone can do something about this.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: Emacs 23 Mac port

[David Reitter]

On May 5, 2010, at 9:04 PM, YAMAMOTO Mitsuharu wrote:
> 
> Scratching the surface of the NS port doesn't make sense to me,
> because it contains so many "I wouldn't design/implement so" in its
> fundamental part.

Point well taken, but that doesn't have to mean it has to be Carbon again.
Carbon, unlike NS, is Apple-only.  Most importantly, Cocoa/NS is a cleaner, more readable, more flexible and future-proof interface.  Accessibility as pointed out by another poster is a further consideration.

I would encourage you to implement your design decisions (concerning event (or C-g?) handling, and what else you pointed out here a while ago) within the NS/Cocoa framework and integrate that with the NS port, so that more people could benefit from it.

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 06 May 2010 12:34:12 -0400, covici@ccs.covici.com said:

> I would like some port that uses the coco kit, because I use voiceover
> and so the current emacs -- or at least one I tried a few months ago
> was not accessible at all, so any influence I have in that direction
> -- I hope someone can do something about this.

If you are talking about the accessibility support for the custom view
that is used for Emacs frame contents, its experimental implementation
is halfway done (but not at the level that is usable for VoiceOver).
You can find some functions names containing "_ax_" in src/macterm.c
even in Emacs 22.3, and they are so named because they are intended to
use as part of accessibility implementation.

Its implementation is currently suspended because I've put stress on
completing Emacs 23 features that are available in other platforms.
But at least it has been on my todo list.

BTW, "Start speaking text" is removed from the Services menu in Mac OS
X 10.6?  It has been available on previous versions and that can be
used in both Emacs 22 Carbon(+AppKit) port and Emacs 23 Mac port.

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

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The thirteenth update of the Mac port, which is
experimental/hackers-only, is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.2-mac-1.993.tar.gz

This version is based on Emacs 23.2.  Again, the Mac port itself is
still experimental/hackers-only.

The Mac port provides a native GUI support for Mac OS X 10.2 - 10.6.
Note that Emacs 23 already contains the official GUI support via the
NS (Cocoa) port for Mac OS X 10.4 and later.  So if it is good enough
for you, then you don't need to try the Mac port.

** Improvements

*** Very experimental support for mouse wheel smooth scroll.  This
still has several glitches especially with respect to tall lines, so
disabled by default for now.  You can try this by setting
`mac-mouse-wheel-smooth-scroll' to t.  Note that this feature might be
withdrawn later.

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

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The fourteenth update of the Mac port, which is
experimental/hackers-only, is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.2-mac-1.994.tar.gz

This version is based on Emacs 23.2.  Again, the Mac port itself is
still experimental/hackers-only.

** Fixed bugs

*** Prefix keys defined in ~/Library/KeyBindings/DefaultKeyBinding.dict
need to be typed multiple times.  Reported by Peter Dyballa and Drew Hess.

*** Successive paste of different images from other applications via
the clipboard only inserts the first image.  Reported by Leo.

*** Successive SVG image loading in `vrend-clock' by Anders Waldenborg
(http://lists.gnu.org/archive/html/bug-gnu-emacs/2010-05/msg00521.html)
fails in a few seconds.

*** The variable `face-ignored-fonts' does not work.
Apply Kenichi Handa's fix for Bug#6287.
This is useful when you want to turn off synthetic bold for some fonts
like (add-to-list 'face-ignored-fonts "\\`-[^-]*-monaco-bold-").
Synthetic bold seems to become lighter if the background is darker
than the foreground and the LCD font smoothing is turned on.

** Improvements

*** "Speak selected text with when the key is pressed", which can be
customized in the Speech pane in the System Preferences, now works.

*** New events: magnify-up/down and rotate-left/right.  They are for
newer trackpads with Mac OS X 10.5.2 and later.  By default,
magnify-up/down, which are issued by pinch out/in, are bound to
scaling text size by text-scale-mode.  With the shift key, they turn
on/off fullscreen status of the frame.

*** Experimental support for accessibility with respect to the custom
view for Emacs frames.  Still there are several glitches.

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

Re: Emacs 23 Mac port

[John Higgins]

On Thu, 6 May 2010 13:31:17 -0400, 
David Reitter <david.reitter@gmail.com> wrote:
> Point well taken, but that doesn't have to mean it has to be Carbon again.
> Carbon, unlike NS, is Apple-only.  Most importantly, Cocoa/NS is a
> cleaner, more readable, more flexible and future-proof interface.
> Accessibility as pointed out by another poster is a further
> consideration.

> I would encourage you to implement your design decisions (concerning
> event (or C-g?) handling, and what else you pointed out here a while
> ago) within the NS/Cocoa framework and integrate that with the NS
> port, so that more people could benefit from it.

What are you talking about ?

Carbon is 32bit only and deprecated, the Mac port
uses Cocoa and it can be compiled as 64bit executable.

It also is very stable, has frequent updates with lots of activity,
and works way better on osx than the 'official' port which is an 
embarrassment unless you are one of the 5 people on this planet 
who run GNUstep that is.

If it wasn't for Mitsuharu's hard work and dedication, there would be
no 23.x Emacs for me and a lot of others on osx.

Re: Emacs 23 Mac port

[David Reitter]

On Jun 6, 2010, at 2:48 PM, John Higgins wrote:
> 
> Carbon is 32bit only and deprecated, the Mac port

Nobody said anything to the contrary.

> uses Cocoa and it can be compiled as 64bit executable.

I see a lot of Carbon in there, unlike in the NS port.

> 
> It also is very stable, has frequent updates with lots of activity,

It's great to see people like it.  This underscores my argument, namely that we should make sure the official NS port benefits from it.

> If it wasn't for Mitsuharu's hard work and dedication, there would be
> no 23.x Emacs for me and a lot of others on osx.


Absolutely.  Again, I'm keen to see some of this work integrated.

That said, I'm not sure I would talk badly about the NS port.
Aquamacs 2.0 currently contributes about 2,500 very regular users of the NS port (in its Aquamacs form running on a Mac, that is).  If they weren't happy, they wouldn't be using it. 
I don't know how many people use the pure NS port.

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 6 Jun 2010 17:28:25 -0400, David Reitter <david.reitter@gmail.com> said:

>> uses Cocoa and it can be compiled as 64bit executable.

> I see a lot of Carbon in there, unlike in the NS port.

As long as a program runs as a 64-bit binary, which implies its GUI
part is implemented with Cocoa, I don't think the (selective) use of
Carbon is problematic.  If it were, then Apple would have excluded it
from the 64-bit version of Carbon like they did for its GUI part.
Sometimes Carbon is useful for finer control, and sometimes it is
necessary to provide compatibility functions for older versions of Mac
OS X where Cocoa hadn't provided enough replacements.

Not using Carbon would be meaningful for the NS port, because it has
to support GNUstep, too.  But for 64-bit GUI Mac programs, it does not
make sense to prefer Cocoa-only to a hybrid of Carbon and Cocoa.
People would neither call Safari a Carbon app nor complain its use for
the reason that the program is linked with the Carbon framework.

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

Re: Emacs 23 Mac port

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]

On 6/6/10 8:53 PM, YAMAMOTO Mitsuharu wrote:
>>>>>> On Sun, 6 Jun 2010 17:28:25 -0400, David Reitter <david.reitter@gmail.com> said:
> 
>>> uses Cocoa and it can be compiled as 64bit executable.
> 
>> I see a lot of Carbon in there, unlike in the NS port.
> 
> As long as a program runs as a 64-bit binary, which implies its GUI
> part is implemented with Cocoa, I don't think the (selective) use of
> Carbon is problematic.  If it were, then Apple would have excluded it
> from the 64-bit version of Carbon like they did for its GUI part.
> Sometimes Carbon is useful for finer control, and sometimes it is
> necessary to provide compatibility functions for older versions of Mac
> OS X where Cocoa hadn't provided enough replacements.

Thanks for your work on the Appkit port. You're single-handedly
responsible for finally bringing me into the Emacs 23 world. I haven't
had any issues at all with the port so far.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The fifteenth update of the Mac port, which is
experimental/hackers-only, is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.2-mac-1.995.tar.gz

This version is based on Emacs 23.2.  Again, the Mac port itself is
still experimental/hackers-only.

** Fixed bugs

*** Text scaling by pinch out/in and by C-x C-+/C-- are not in sync.

*** Shift-Tab is recognized as Tab, and keyboard navigation after
Command-Shift-/ doesn't work on Mac OS X 10.6.  These are regressions
caused by the previous fix for the DefaultKeyBinding.dict problem.

*** Successive paste of the same image from other applications via the
clipboard causes duplication in the kill ring.  Reported by Leo.  This
is a regression caused by the previous fix.

*** Fonts in highlighted words with the pop-up dictionary
(Command-Control-D) are sometimes incorrect.  This is a regression
caused by refactoring for the accessibility support.

** Improvements

*** Font design destination can be specified via the `:destination'
font property.  The value 1 means the destination is video text as in
the XLFD Conventions, and screen font metrics are used in that case.
You can see the difference with (make-frame '((font
. "Monaco-9:antialias=off:destination=1"))), for example.

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

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The sixteenth update of the Mac port, which is
experimental/hackers-only, is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.2-mac-1.996.tar.gz

This version is based on Emacs 23.2.  Again, the Mac port itself is
still experimental/hackers-only.

** Fixed bugs

*** Boundary indicators in fringes are scrolled out if vscrolled.
Apply a fix for Bug#5634 and Bug#6325.
Now that this annoying problem is fixed, pixel-based mouse wheel
smooth scrolling is enabled by default.  Note that it still has
several glitches and you can turn it off by setting
`mac-mouse-wheel-smooth-scroll' to nil.

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

Re: Emacs 23 Mac port

[covici]

Any  progress on making the mode line and echo area accessible with
Voiceover?  Also, I discovered on the 94 version, that I could not read
the window I get when using tab completion.

Thanks for all your great work!

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:

> The sixteenth update of the Mac port, which is
> experimental/hackers-only, is now available from
> 
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.2-mac-1.996.tar.gz
> 
> This version is based on Emacs 23.2.  Again, the Mac port itself is
> still experimental/hackers-only.
> 
> ** Fixed bugs
> 
> *** Boundary indicators in fringes are scrolled out if vscrolled.
> Apply a fix for Bug#5634 and Bug#6325.
> Now that this annoying problem is fixed, pixel-based mouse wheel
> smooth scrolling is enabled by default.  Note that it still has
> several glitches and you can turn it off by setting
> `mac-mouse-wheel-smooth-scroll' to nil.
> 
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: Emacs 23 Mac port

[David Reitter]

On Jul 31, 2010, at 1:23 AM, YAMAMOTO Mitsuharu wrote:

> The sixteenth update of the Mac port, which is
> experimental/hackers-only, is now available from
> 
>    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.2-mac-1.996.tar.gz

Interesting.

Could you please explain what EmacsPosingWindow is intended to do?
I can see you re-implement the close and orderOut methods with ones that briefly run the event loop (if I understand this right), but why is this needed as opposed to overloading the functions in EmacsWindow and calling [super close] etc. regularly?

Thanks.

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The seventeenth update of the Mac port, which is
experimental/hackers-only, is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.2-mac-1.997.tar.gz

This version is based on Emacs 23.2.  Again, the Mac port itself is
still experimental/hackers-only.

** Fixed bugs

*** Text shaping does not respect the :destination setting.

** Improvements

*** One can send an Apple event and handle its reply asynchronously.
ODB Editor Suite support is added as an example.  (Only tested with
QuickCursor.  Add "<string>org.gnu.Emacs</string>" to the elements of
QCEditInChoices in QuickCursor.app/Contents/Info.plist.)

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

Re: Emacs 23 Mac port

[Leo]

On 2010-09-27 09:38 +0100, YAMAMOTO Mitsuharu wrote:
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.2-mac-1.997.tar.gz
>
> This version is based on Emacs 23.2.  Again, the Mac port itself is
> still experimental/hackers-only.

Thank you.

Leo

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The eighteenth update of the Mac port, which is
experimental/hackers-only, is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.2.90-mac-1.998.tar.gz

This version is based on Emacs 23.2.90 pretest.

** Fixed bugs

*** Fullscreen frame does not hide the Dock that is on a different
screen from the one containing the menu bar.
Note: we cannot hide only the menu bar while showing the Dock.  So the
Dock might be hidden even when the fullscreen frame is not on the
screen containing the Dock.


In addition to the standard Emacs 23.3 features, the Mac port includes
the following Mac-specific ones:

  * Pixel-based mouse wheel smooth scroll for newer mice/trackpads.
  * Gesture event handling for newer trackpads.  By default, pinch
    out/in are bound to text size scaling.  With the shift key, they
    turn on/off fullscreen status of the frame.
  * Apple event sending with (a)synchronous reply handling.  ODB
    Editor Suite support is added as an example.  (Only tested with
    QuickCursor.  Add "<string>org.gnu.Emacs</string>" to the elements
    of QCEditInChoices in QuickCursor.app/Contents/Info.plist.)
  * "Click in the scroll bar to: Jump to the spot that's clicked"
    setting in the System Preferences is supported.
  * Change of text smoothing threshold setting in the Appearance pane
    of the System Preferences is reflected immediately.
  * Several keyboard shortcuts (notably those for Keyboard Navigation)
    listed in System Preferences just work like other applications.
  * When the clipboard has both textual and image data, yank inserts
    the former and push both into the kill ring so the latter can be
    inserted with yank-pop afterwards.
  * Use non-integral x positions for displaying antialiased
    proportional fonts.  You can see the difference by putting the box
    cursor over Helvetica 12pt `I', whose ideal width is 3.33398 but
    displayed with the rounded width 3, for example.
  * Emacs info nodes are accessible via search field in the Help menu
    on Mac OS X 10.6.
  * Menu item "Open Selected File in Emacs" is shown in Services or
    context menu of other applications by default on Mac OS X 10.6
    when absolute pathname-like text is selected.
  * Reverse conversion in Kotoeri works even without selection.
    Hitting Eisu/Kana key on JIS keyboard (or Control-Shift-;/J/K on
    US keyboard) twice also works.
  * New function `mac-file-alias-p', which is parallel to
    `file-symlink-p'.
  * Experimental support for accessibility with respect to the custom
    view for Emacs frames.  Still there are several glitches.

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

Re: Emacs 23 Mac port

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

On 11/10/10 12:50 AM, YAMAMOTO Mitsuharu wrote:
> The eighteenth update of the Mac port, which is
> experimental/hackers-only, is now available from
> 
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.2.90-mac-1.998.tar.gz
> 
> This version is based on Emacs 23.2.90 pretest.
> 

Thanks for continuing to do this work. I still find the AppKit port to
be more reliable and useful than the NS one, and I hope it makes it into
mainline one day.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Emacs 23 Mac port

[Leo]

On 2010-11-15 05:47 +0800, Daniel Colascione wrote:
> Thanks for continuing to do this work. I still find the AppKit port to
> be more reliable and useful than the NS one, and I hope it makes it
> into mainline one day.

I second this.

Leo

Re: Emacs 23 Mac port

[covici]

Leo <sdl.web@gmail.com> wrote:

> On 2010-11-15 05:47 +0800, Daniel Colascione wrote:
> > Thanks for continuing to do this work. I still find the AppKit port to
> > be more reliable and useful than the NS one, and I hope it makes it
> > into mainline one day.
> 
> I second this.

I wonder about which one is more accessible -- the macport -- so far --
is the only one where VoiceOver reads anything, but it does not read the
mode line nor can I see completion buffers.  So, where is this appkit
port so I can test?  I did try a couple of other emacs ports for mac,
but none of them were accessible at all with Voiceover.

Thanks for any ideas.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: Emacs 23 Mac port

[Chad Brown]

On Nov 14, 2010, at 1:47 PM, Daniel Colascione wrote:
> Thanks for continuing to do this work. I still find the AppKit port to
> be more reliable and useful than the NS one, and I hope it makes it into
> mainline one day.


I wonder if you could be more specific about `reliable' and `useful' in this context?

I use the NS port every day, typically for several hours, and I don't see reliability issues at all.  I build from bzr HEAD every few days (at least).  Is the released version troublesome?  Is there some particularly key use that the appkit port enables but the NS port doesn't? 

I don't have any particular horse in this race -- I use the NS port simply because it's the one that allows me to keep up-to-date best.  I get the sense that there are adherents on each side, but that inertia (in both ``this is in bzr'' and the ``this one isn't merged into bzr'' directions) is the ruling factor at the moment.  With a prerelease in the field, it seems like an opportune time to merge or swap is in the nearish future.

Thanks,
*Chad

*Chad

Re: Emacs 23 Mac port

[Ted Zlatanov]

On Sun, 14 Nov 2010 13:47:20 -0800 Daniel Colascione <dan.colascione@gmail.com> wrote: 

DC> On 11/10/10 12:50 AM, YAMAMOTO Mitsuharu wrote:
>> The eighteenth update of the Mac port, which is
>> experimental/hackers-only, is now available from
>> 
>> ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.2.90-mac-1.998.tar.gz
>> 
>> This version is based on Emacs 23.2.90 pretest.

DC> Thanks for continuing to do this work. I still find the AppKit port to
DC> be more reliable and useful than the NS one, and I hope it makes it into
DC> mainline one day.

IIRC the AppKit port depends on the Carbon libraries and so is not a
good long-term solution.  Mitsuharu-san, is that still correct?

Ted

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 15 Nov 2010 09:23:54 -0600, Ted Zlatanov <tzz@lifelogs.com> said:

DC> Thanks for continuing to do this work. I still find the AppKit
DC> port to be more reliable and useful than the NS one, and I hope it
DC> makes it into mainline one day.

> IIRC the AppKit port depends on the Carbon libraries and so is not a
> good long-term solution.  Mitsuharu-san, is that still correct?

Not sure about "the Appkit port".

If you mean Emacs 22 Carbon+Appkit port, then I maintain this just
because I'm using it in our classroom.

If you mean Emacs 23 Mac port, see the following message in
http://lists.gnu.org/archive/html/emacs-devel/2010-06/msg00148.html

>>>>> On Mon, 07 Jun 2010 09:53:09 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>>>>> On Sun, 6 Jun 2010 17:28:25 -0400, David Reitter <david.reitter@gmail.com> said:

>>> uses Cocoa and it can be compiled as 64bit executable.

>> I see a lot of Carbon in there, unlike in the NS port.

> As long as a program runs as a 64-bit binary, which implies its GUI
> part is implemented with Cocoa, I don't think the (selective) use of
> Carbon is problematic.  If it were, then Apple would have excluded
> it from the 64-bit version of Carbon like they did for its GUI part.
> Sometimes Carbon is useful for finer control, and sometimes it is
> necessary to provide compatibility functions for older versions of
> Mac OS X where Cocoa hadn't provided enough replacements.

> Not using Carbon would be meaningful for the NS port, because it has
> to support GNUstep, too.  But for 64-bit GUI Mac programs, it does
> not make sense to prefer Cocoa-only to a hybrid of Carbon and Cocoa.
> People would neither call Safari a Carbon app nor complain its use
> for the reason that the program is linked with the Carbon framework.

FWIW, half of applications that are bundled with Mac OS X 10.6 are
linked with the Carbon framework.

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

Re: Emacs 23 Mac port

[Ted Zlatanov]

On Tue, 16 Nov 2010 10:25:41 +0900 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote: 

>>>>>> On Mon, 15 Nov 2010 09:23:54 -0600, Ted Zlatanov <tzz@lifelogs.com> said:
DC> Thanks for continuing to do this work. I still find the AppKit
DC> port to be more reliable and useful than the NS one, and I hope it
DC> makes it into mainline one day.

>> IIRC the AppKit port depends on the Carbon libraries and so is not a
>> good long-term solution.  Mitsuharu-san, is that still correct?

YM> Not sure about "the Appkit port".

It was the term used by the OP.  I believe he referred to the Emacs 23
Mac port.

YM> If you mean Emacs 22 Carbon+Appkit port, then I maintain this just
YM> because I'm using it in our classroom.

YM> If you mean Emacs 23 Mac port, see the following message in
YM> http://lists.gnu.org/archive/html/emacs-devel/2010-06/msg00148.html

So are you saying Carbon *is* a good long-term solution?

Or are you saying it's supported right now and that's good enough?

Carbon was not supposed to get a 64-bit upgrade when we first discussed
your Mac port IIRC; obviously it has one now.  I think the Emacs
maintainers still prefer the NS port because of the GNUStep support.

Ted

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 16 Nov 2010 08:11:01 -0600, Ted Zlatanov <tzz@lifelogs.com> said:

YM> If you mean Emacs 23 Mac port, see the following message in
YM> http://lists.gnu.org/archive/html/emacs-devel/2010-06/msg00148.html

> So are you saying Carbon *is* a good long-term solution?

> Or are you saying it's supported right now and that's good enough?

I mean what's currently supported in 64-bit Carbon is expected to
survive for a certain period of time, because Apple has already made
drastic cut for Carbon on the 64-bit transition.  Of course, I can't
speak for Apple.

> Carbon was not supposed to get a 64-bit upgrade when we first
> discussed your Mac port IIRC; obviously it has one now.

Typical misunderstanding about 64-bit Carbon.  It was the GUI portion
of HIToolbox that was not supposed to get a 64-bit upgrade from the
beginning.  Not the whole Carbon.  That's why I ported only the GUI
part from Carbon HIToolbox to Cocoa AppKit.

By the way, which is in your mind when you speak "Carbon", C APIs in
general or the Carbon framework (i.e.,
/System/Library/Frameworks/Carbon.framework/)?  The latter does not
include Core Foundation, Core Graphics, Core Text, or Image I/O, all
of which are C APIs supported and legitimate even in iOS.

> I think the Emacs maintainers still prefer the NS port because of
> the GNUStep support.

As I'm saying in the beginning of README-mac file in the Mac port, if
the NS port is good enough for you, then you don't need to try the Mac
port.

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

Re: Emacs 23 Mac port

[Ted Zlatanov]

On Wed, 17 Nov 2010 22:44:21 +0900 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote: 

>>>>>> On Tue, 16 Nov 2010 08:11:01 -0600, Ted Zlatanov <tzz@lifelogs.com> said:
YM> If you mean Emacs 23 Mac port, see the following message in
YM> http://lists.gnu.org/archive/html/emacs-devel/2010-06/msg00148.html

>> I think the Emacs maintainers still prefer the NS port because of
>> the GNUStep support.

YM> As I'm saying in the beginning of README-mac file in the Mac port, if
YM> the NS port is good enough for you, then you don't need to try the Mac
YM> port.

Right, but here we have posts saying your Mac port is much better than
the NS port.  We should at least consider what's different, how the NS
port can be improved, and if your Mac port should be reconsidered as the
main Mac OS X port.  So I asked about the Carbon support because that
was a concern last time; your response and opinion are, as always,
greatly appreciated.

Ted

Re: Emacs 23 Mac port

[David Reitter]

On Nov 17, 2010, at 9:57 AM, Ted Zlatanov wrote:
> 
> Right, but here we have posts saying your Mac port is much better than
> the NS port.  We should at least consider what's different, how the NS
> port can be improved, and if your Mac port should be reconsidered as the
> main Mac OS X port.  So I asked about the Carbon support because that
> was a concern last time; your response and opinion are, as always,
> greatly appreciated.

Yes, please consider this.

I'm not against it, but I'd like to suggest some mitigation w.r.t. four points:

1. Maintainability:  NS/Cocoa is cleaner code.  It's a cleaner, more modern API.    That's one reason why I like the NS port.

2. GNUStep support.  This might increase the chances of having more people work on it.

3. The existing, very substantial investment in code specific to the NS port (third party).  The 22/Carbon to 23/NS switchover was a major, major shift, with a substantial amount of time being invested in writing C-level and Lisp-level functions.  It is possible that a lot of this (e.g., printing, toolbar customization) can be ported easily to the 24/Appkit, but we don't know that.

4. Lack of integration in Bzr/Git.  Why is this not a branch in the repository?

Especially point 3 is my major concern.  I'd like to support the many users of this code.  A switch to the Appkit port may require such substantial extra work, for little benefit.

There are arguments in favor of the Appkit port, both technically, but also by way of YM supporting and developing it very actively.

Re: Emacs 23 Mac port

[ken manheimer]

On Sun, Nov 14, 2010 at 4:47 PM, Daniel Colascione
<dan.colascione@gmail.com> wrote:
> On 11/10/10 12:50 AM, YAMAMOTO Mitsuharu wrote:
>> The eighteenth update of the Mac port, which is
>> experimental/hackers-only, is now available from
>>
>>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.2.90-mac-1.998.tar.gz
>>
>> This version is based on Emacs 23.2.90 pretest.
>>
>
> Thanks for continuing to do this work. I still find the AppKit port to
> be more reliable and useful than the NS one, and I hope it makes it into
> mainline one day.

For whatever it's worth, mitsuharu-sans mac port is the only 23+ build
i've found in which the cursor stays visible when over embedded
graphics.  I needed that working for my day-to-day editing, though it
may not be as crucial for many other emacs users.

I filed a bug report yesterday about the problem:

    http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7412

(Having a properly functioning 23.x version will make it easier for me
to work on replacing pgg with epa/epg in allout mode.  Hopefully i'll
have something to show for that soon.)
-- 
ken manheimer
http://myriadicity.net

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 17 Nov 2010 16:49:39 -0500, ken manheimer <ken.manheimer@gmail.com> said:

> For whatever it's worth, mitsuharu-sans mac port is the only 23+
> build i've found in which the cursor stays visible when over
> embedded graphics.  I needed that working for my day-to-day editing,
> though it may not be as crucial for many other emacs users.

> I filed a bug report yesterday about the problem:

>     http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7412

One of the Mac port policy is to keep code-level similarity with the
other platforms, especially with X11.  So this type of bugs or
incompatibilities hardly happen on the Mac port.  I think this is
important to make the code "maintainable" with minimal effort.  That
also makes it possible for Mac port users to find bugs that are common
to most platforms, and for a developer of the port to contribute back
to free systems by proposing common fixes or improvements.

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

Re: Emacs 23 Mac port

[Leo]

On 2010-11-10 08:50 +0000, YAMAMOTO Mitsuharu wrote:
> The eighteenth update of the Mac port, which is
> experimental/hackers-only, is now available from
>
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.2.90-mac-1.998.tar.gz
>
> This version is based on Emacs 23.2.90 pretest.

I applied macport on emacs-23 branch. But I can't seem to get emacs to
bootstrap - "Symbol's value as variable is void: query-replace-map".
Ideas?

Leo

--------------------------------

Log:

cd lib-src; make all                            \
	  CC='gcc' CFLAGS='-g' CPPFLAGS='' \
	  LDFLAGS='' MAKE='make'
make[1]: Nothing to be done for `all'.
boot=bootstrap-emacs;                         \
	if [ ! -x "src/$boot" ]; then                                     \
	    cd src; make all                                    \
	      CC='gcc' CFLAGS='-g' CPPFLAGS=''         \
	      LDFLAGS='' MAKE='make' BOOTSTRAPEMACS="$boot"; \
	fi;
cd ../lisp; make  update-subdirs
wd=/Users/Shared/emacs/lisp; subdirs=`(cd $wd; find . -type d -print)`; for file in $subdirs; do case $file in */Old | */RCS | */CVS | */CVS/* | */.* | */.*/* | */=* | */cedet* ) ;; *) wins="$wins $wd/$file" ;; esac; done; \
	for file in $wins; do \
	   /Users/Shared/emacs/lisp/../update-subdirs $file; \
	done;
`/bin/pwd`/temacs --batch --load loadup bootstrap
Loading loadup.el (source)...
Using load-path (/Users/Shared/emacs/lisp /Users/Shared/emacs/lisp/emacs-lisp /Users/Shared/emacs/lisp/language /Users/Shared/emacs/lisp/international /Users/Shared/emacs/lisp/textmodes)
Loading emacs-lisp/byte-run (source)...
Loading emacs-lisp/backquote (source)...
Loading subr (source)...
Loading version.el (source)...
Loading widget (source)...
Loading custom (source)...
Loading emacs-lisp/map-ynp (source)...
Loading cus-start (source)...
Loading international/mule (source)...
Loading international/mule-conf (source)...
Loading env (source)...
Loading format (source)...
Loading bindings (source)...
Loading /Users/Shared/emacs/lisp/files.el (source)...
Loading /Users/Shared/emacs/lisp/cus-face.el (source)...
Loading /Users/Shared/emacs/lisp/faces.el (source)...
Loading /Users/Shared/emacs/lisp/minibuffer.el (source)...
Loading /Users/Shared/emacs/lisp/button.el (source)...
Loading /Users/Shared/emacs/lisp/startup.el (source)...
Loading /Users/Shared/emacs/lisp/ldefs-boot.el (source)...
Loading /Users/Shared/emacs/lisp/abbrev.el (source)...
Symbol's value as variable is void: query-replace-map
make[1]: *** [bootstrap-emacs] Error 255
make: *** [src] Error 2

Re: Emacs 23 Mac port

[Leo]

On 2010-12-01 03:34 +0000, Leo wrote:
> I applied macport on emacs-23 branch. But I can't seem to get emacs to
> bootstrap - "Symbol's value as variable is void: query-replace-map".
> Ideas?

Anyway, I (defvar query-replace-map nil) to get bootstrapping going then
remove it and use normal build process to build the Emacs I am using to
write this message.

BTW, `mac-mouse-wheel-smooth-scroll' does not work reliably. It can
freeze emacs (Can't be interrupted by C-g). So I am not using it for
now.

Cheers,
Leo

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 01 Dec 2010 10:43:26 +0000, Leo <sdl.web@gmail.com> said:

> BTW, `mac-mouse-wheel-smooth-scroll' does not work reliably. It can
> freeze emacs (Can't be interrupted by C-g). So I am not using it for
> now.

I've never experienced this.  If it does not happen with -Q, then your
configuration has something to do with this problem.

Also, because the actual scrolling code is mostly implemented at the
Lisp level (without touching inhibit-quit), your problem may indicate
that there is some infinite loop or hang possibly in the
platform-independent part such as redisplay.  Identifying the place of
infinite loop or hang using a debugger may help (see the "If the
symptom of the bug is that Emacs fails to respond" section in
etc/DEBUG).

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

Re: Emacs 23 Mac port

[Leo]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

On 2010-12-02 10:01 +0000, YAMAMOTO Mitsuharu wrote:
>> BTW, `mac-mouse-wheel-smooth-scroll' does not work reliably. It can
>> freeze emacs (Can't be interrupted by C-g). So I am not using it for
>> now.
>
> I've never experienced this.  If it does not happen with -Q, then your
> configuration has something to do with this problem.
>
> Also, because the actual scrolling code is mostly implemented at the
> Lisp level (without touching inhibit-quit), your problem may indicate
> that there is some infinite loop or hang possibly in the
> platform-independent part such as redisplay.  Identifying the place of
> infinite loop or hang using a debugger may help (see the "If the
> symptom of the bug is that Emacs fails to respond" section in
> etc/DEBUG).

Indeed there is an infinite loop. But I wasn't able to reproduce the
problem with a vanilla Emacs. The problem happens when I am scrolling up
(my hand move from bottom to top on the trackpad) and the infinite loop
happens in xdisp.c between line 12630 and 12789 (the gdb log is
attached).

I also find a way to reproduce this problem easily with Emacs -q:

1. eval

  (setq scroll-conservatively 100)
  (setq scroll-preserve-screen-position 'always)

2. try scrolling in a buffer


[-- Attachment #2: mac-bug.log --]
[-- Type: text/plain, Size: 10982 bytes --]

(gdb) bt
#0  0x000000010005ae61 in x_produce_glyphs (it=0x7fff5fbfb810) at xdisp.c:21134
#1  0x000000010004ab68 in append_space_for_newline (it=0x7fff5fbfb810, default_face_p=1) at xdisp.c:16111
#2  0x000000010004bea3 in display_line (it=0x7fff5fbfb810) at xdisp.c:16551
#3  0x0000000100043fa2 in try_window (window=4330623621, pos={charpos = 5874, bytepos = 5874}, flags=0) at xdisp.c:13995
#4  0x0000000100040067 in try_scrolling (window=4330623621, just_this_one_p=0, scroll_conservatively=100, scroll_step=0, temp_scroll_step=0, last_line_misfit=1) at xdisp.c:12768
#5  0x0000000100042b82 in redisplay_window (window=4330623621, just_this_one_p=0) at xdisp.c:13667
#6  0x000000010003df68 in redisplay_window_0 (window=4330623621) at xdisp.c:12235
#7  0x000000010018fc93 in internal_condition_case_1 (bfun=0x10003df26 <redisplay_window_0>, arg=4330623621, handlers=4320154102, hfun=0x10003def2 <redisplay_window_error>) at eval.c:1540
#8  0x000000010003ded0 in redisplay_windows (window=4330623621) at xdisp.c:12214
#9  0x000000010003cf72 in redisplay_internal (preserve_echo_area=1) at xdisp.c:11783
#10 0x000000010003d79d in redisplay_preserve_echo_area (from_where=2) at xdisp.c:12038
#11 0x0000000100010b6e in Fredisplay (force=4320133226) at dispnew.c:6687
#12 0x0000000100193005 in Ffuncall (nargs=2, args=0x7fff5fbfe570) at eval.c:3078
#13 0x00000001001f1276 in Fbyte_code (bytestr=4300055201, vector=4300055237, maxdepth=36) at bytecode.c:680
#14 0x0000000100193a9e in funcall_lambda (fun=4300055125, nargs=1, arg_vector=0x7fff5fbfebb8) at eval.c:3267
#15 0x0000000100193325 in Ffuncall (nargs=2, args=0x7fff5fbfebb0) at eval.c:3124
#16 0x0000000100191fad in Fapply (nargs=2, args=0x7fff5fbfebb0) at eval.c:2500
#17 0x0000000100192898 in apply1 (fn=4324793418, arg=4346422118) at eval.c:2827
#18 0x000000010018af80 in Fcall_interactively (function=4324793418, record_flag=4320133130, keys=4308614365) at callint.c:396
#19 0x000000010019307b in Ffuncall (nargs=4, args=0x7fff5fbfefb0) at eval.c:3084
#20 0x00000001001929a5 in call3 (fn=4320306074, arg1=4324793418, arg2=4320133130, arg3=4320133130) at eval.c:2904
#21 0x00000001000f3ee9 in Fcommand_execute (cmd=4324793418, record_flag=4320133130, keys=4320133130, special=4320133130) at keyboard.c:10636
#22 0x00000001000e1b59 in command_loop_1 () at keyboard.c:1930
#23 0x000000010018fae1 in internal_condition_case (bfun=0x1000dfb1a <command_loop_1>, handlers=4320204266, hfun=0x1000df2ae <cmd_error>) at eval.c:1492
#24 0x00000001000df7a9 in command_loop_2 () at keyboard.c:1379
#25 0x000000010018f406 in internal_catch (tag=4320197530, func=0x1000df77a <command_loop_2>, arg=4320133130) at eval.c:1228
#26 0x00000001000df73f in command_loop () at keyboard.c:1354
#27 0x00000001000ded41 in recursive_edit_1 () at keyboard.c:963
#28 0x00000001000def32 in Frecursive_edit () at keyboard.c:1025
#29 0x00000001000dd15d in main (argc=1, argv=0x7fff5fbff840) at emacs.c:1856
(gdb) step
21148		  boff = font->baseline_offset;
(gdb) step
21149		  if (font->vertical_centering)
(gdb) finish 
Run till exit from #0  x_produce_glyphs (it=0x7fff5fbfb810) at xdisp.c:21149
0x000000010004ab68 in append_space_for_newline (it=0x7fff5fbfb810, default_face_p=1) at xdisp.c:16111
16111		  PRODUCE_GLYPHS (it);
(gdb) finish 
Run till exit from #0  0x000000010004ab68 in append_space_for_newline (it=0x7fff5fbfb810, default_face_p=1) at xdisp.c:16111
0x000000010004bea3 in display_line (it=0x7fff5fbfb810) at xdisp.c:16551
16551		  else if ((append_space_for_newline (it, 1) && row->used[TEXT_AREA] == 1)
Value returned is $1 = 1
(gdb) finish 
Run till exit from #0  0x000000010004bea3 in display_line (it=0x7fff5fbfb810) at xdisp.c:16551
0x0000000100043fa2 in try_window (window=4330623621, pos={charpos = 5874, bytepos = 5874}, flags=0) at xdisp.c:13995
13995	      if (display_line (&it))
Value returned is $2 = 0
(gdb) finish 
Run till exit from #0  0x0000000100043fa2 in try_window (window=4330623621, pos={charpos = 5874, bytepos = 5874}, flags=0) at xdisp.c:13995
0x0000000100040067 in try_scrolling (window=4330623621, just_this_one_p=0, scroll_conservatively=100, scroll_step=0, temp_scroll_step=0, last_line_misfit=1) at xdisp.c:12768
12768	  if (!try_window (window, startp, 0))
Value returned is $3 = 1
(gdb) finish 
Run till exit from #0  0x0000000100040067 in try_scrolling (window=4330623621, just_this_one_p=0, scroll_conservatively=100, scroll_step=0, temp_scroll_step=0, last_line_misfit=1) at xdisp.c:12768
^C
Program received signal SIGINT, Interrupt.
0x000000010004d696 in display_line (it=0x7fff5fbf8890) at xdisp.c:16998
16998	  if (!NILP (Vshow_trailing_whitespace))
(gdb) finish 
Run till exit from #0  0x000000010004d696 in display_line (it=0x7fff5fbf8890) at xdisp.c:16998
0x0000000100043fa2 in try_window (window=4330623621, pos={charpos = 5874, bytepos = 5874}, flags=0) at xdisp.c:13995
13995	      if (display_line (&it))
Value returned is $4 = 0
(gdb) finish 
Run till exit from #0  0x0000000100043fa2 in try_window (window=4330623621, pos={charpos = 5874, bytepos = 5874}, flags=0) at xdisp.c:13995
0x0000000100040067 in try_scrolling (window=4330623621, just_this_one_p=0, scroll_conservatively=100, scroll_step=0, temp_scroll_step=0, last_line_misfit=1) at xdisp.c:12768
12768	  if (!try_window (window, startp, 0))
Value returned is $5 = 1
(gdb) finish 
Run till exit from #0  0x0000000100040067 in try_scrolling (window=4330623621, just_this_one_p=0, scroll_conservatively=100, scroll_step=0, temp_scroll_step=0, last_line_misfit=1) at xdisp.c:12768
next
^C
Program received signal SIGINT, Interrupt.
0x00000001000309bb in next_element_from_buffer (it=0x7fff5fbf8890) at xdisp.c:6536
6536	}
(gdb) finish 
Run till exit from #0  0x00000001000309bb in next_element_from_buffer (it=0x7fff5fbf8890) at xdisp.c:6536
0x000000010002da7b in get_next_display_element (it=0x7fff5fbf8890) at xdisp.c:5654
5654	  success_p = GET_NEXT_DISPLAY_ELEMENT (it);
Value returned is $6 = 0
(gdb) finish 
Run till exit from #0  0x000000010002da7b in get_next_display_element (it=0x7fff5fbf8890) at xdisp.c:5654
0x000000010004bdb7 in display_line (it=0x7fff5fbf8890) at xdisp.c:16543
16543	      if (!get_next_display_element (it))
Value returned is $7 = 0
(gdb) finish 
Run till exit from #0  0x000000010004bdb7 in display_line (it=0x7fff5fbf8890) at xdisp.c:16543
0x0000000100043fa2 in try_window (window=4330623621, pos={charpos = 5874, bytepos = 5874}, flags=0) at xdisp.c:13995
13995	      if (display_line (&it))
Value returned is $8 = 0
(gdb) finish 
Run till exit from #0  0x0000000100043fa2 in try_window (window=4330623621, pos={charpos = 5874, bytepos = 5874}, flags=0) at xdisp.c:13995
0x0000000100040067 in try_scrolling (window=4330623621, just_this_one_p=0, scroll_conservatively=100, scroll_step=0, temp_scroll_step=0, last_line_misfit=1) at xdisp.c:12768
12768	  if (!try_window (window, startp, 0))
Value returned is $9 = 1
(gdb) next
12770	  else if (w->cursor.vpos < 0)
(gdb) next
12778	      if (!just_this_one_p
(gdb) next
12781		w->base_line_number = Qnil;
(gdb) next
12785	      if (! cursor_row_fully_visible_p (w, extra_scroll_margin_lines <= 1, 0))
(gdb) next
12787		  clear_glyph_matrix (w->desired_matrix);
(gdb) next
12788		  ++extra_scroll_margin_lines;
(gdb) next
12789		  goto too_near_end;
(gdb) next
12633	  if (PT > CHARPOS (startp))
(gdb) next
12666	  if (scroll_down_p)
(gdb) 
12704	      struct text_pos scroll_margin_pos = startp;
(gdb) 
12708	      if (this_scroll_margin)
(gdb) 
12715	      if (PT < CHARPOS (scroll_margin_pos))
(gdb) 
12764	  startp = run_window_scroll_functions (window, startp);
(gdb) 
12768	  if (!try_window (window, startp, 0))
(gdb) 
12770	  else if (w->cursor.vpos < 0)
(gdb) 
12778	      if (!just_this_one_p
(gdb) 
12781		w->base_line_number = Qnil;
(gdb) 
12785	      if (! cursor_row_fully_visible_p (w, extra_scroll_margin_lines <= 1, 0))
(gdb) 
12787		  clear_glyph_matrix (w->desired_matrix);
(gdb) 
12788		  ++extra_scroll_margin_lines;
(gdb) 
12789		  goto too_near_end;
(gdb) 
12633	  if (PT > CHARPOS (startp))
(gdb) 
12666	  if (scroll_down_p)
(gdb) 
12704	      struct text_pos scroll_margin_pos = startp;
(gdb) 
12708	      if (this_scroll_margin)
(gdb) 
12715	      if (PT < CHARPOS (scroll_margin_pos))
(gdb) 
12764	  startp = run_window_scroll_functions (window, startp);
(gdb) 
12768	  if (!try_window (window, startp, 0))
(gdb) 
12770	  else if (w->cursor.vpos < 0)
(gdb) 
12778	      if (!just_this_one_p
(gdb) 
12781		w->base_line_number = Qnil;
(gdb) 
12785	      if (! cursor_row_fully_visible_p (w, extra_scroll_margin_lines <= 1, 0))
(gdb) 
12787		  clear_glyph_matrix (w->desired_matrix);
(gdb) 
12788		  ++extra_scroll_margin_lines;
(gdb) 
12789		  goto too_near_end;
(gdb) 
12633	  if (PT > CHARPOS (startp))
(gdb) 
12666	  if (scroll_down_p)
(gdb) 
12704	      struct text_pos scroll_margin_pos = startp;
(gdb) 
12708	      if (this_scroll_margin)
(gdb) 
12715	      if (PT < CHARPOS (scroll_margin_pos))
(gdb) 
12764	  startp = run_window_scroll_functions (window, startp);
(gdb) 
12768	  if (!try_window (window, startp, 0))
(gdb) 
12770	  else if (w->cursor.vpos < 0)
(gdb) 
12778	      if (!just_this_one_p
(gdb) 
12781		w->base_line_number = Qnil;
(gdb) 
12785	      if (! cursor_row_fully_visible_p (w, extra_scroll_margin_lines <= 1, 0))
(gdb) 
12787		  clear_glyph_matrix (w->desired_matrix);
(gdb) 
12788		  ++extra_scroll_margin_lines;
(gdb) 
12789		  goto too_near_end;
(gdb) 
12633	  if (PT > CHARPOS (startp))
(gdb) 
12666	  if (scroll_down_p)
(gdb) 
12704	      struct text_pos scroll_margin_pos = startp;
(gdb) 
12708	      if (this_scroll_margin)
(gdb) 
12715	      if (PT < CHARPOS (scroll_margin_pos))
(gdb) 
12764	  startp = run_window_scroll_functions (window, startp);
(gdb) 
12768	  if (!try_window (window, startp, 0))
(gdb) 
12770	  else if (w->cursor.vpos < 0)
(gdb) 
12778	      if (!just_this_one_p
(gdb) 
12781		w->base_line_number = Qnil;
(gdb) 
12785	      if (! cursor_row_fully_visible_p (w, extra_scroll_margin_lines <= 1, 0))
(gdb) 
12787		  clear_glyph_matrix (w->desired_matrix);
(gdb) 
12788		  ++extra_scroll_margin_lines;
(gdb) 
12789		  goto too_near_end;
(gdb) 
12633	  if (PT > CHARPOS (startp))
(gdb) 
12666	  if (scroll_down_p)
(gdb) 
12704	      struct text_pos scroll_margin_pos = startp;
(gdb) 
12708	      if (this_scroll_margin)
(gdb) 
12715	      if (PT < CHARPOS (scroll_margin_pos))
(gdb) 
12764	  startp = run_window_scroll_functions (window, startp);
(gdb) 
12768	  if (!try_window (window, startp, 0))
(gdb) 
12770	  else if (w->cursor.vpos < 0)
(gdb) 
12778	      if (!just_this_one_p
(gdb) 
12781		w->base_line_number = Qnil;
(gdb) p scroll_down_p
$10 = 0
(gdb) next
12785	      if (! cursor_row_fully_visible_p (w, extra_scroll_margin_lines <= 1, 0))
(gdb) 
12787		  clear_glyph_matrix (w->desired_matrix);
(gdb) 
12788		  ++extra_scroll_margin_lines;
(gdb) 
12789		  goto too_near_end;
(gdb) 
12633	  if (PT > CHARPOS (startp))
(gdb) 
12666	  if (scroll_down_p)
(gdb) 

[-- Attachment #3: Type: text/plain, Size: 13 bytes --]


Thanks.
Leo

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 02 Dec 2010 14:52:58 +0000, Leo <sdl.web@gmail.com> said:

> Indeed there is an infinite loop. But I wasn't able to reproduce the
> problem with a vanilla Emacs. The problem happens when I am
> scrolling up (my hand move from bottom to top on the trackpad) and
> the infinite loop happens in xdisp.c between line 12630 and 12789
> (the gdb log is attached).

I could reproduce the infinite loop in try_scrolling even with the X11
build, on both trunk and the emacs-23 branch.  C-g does not help.

1. emacs -Q
2. Evaluate the following expression in *scratch* with C-x C-e.
   (progn
     (setq scroll-conservatively 100)
     (setq scroll-preserve-screen-position 'always)
     (goto-char (point-min))
     (set-window-vscroll nil 1 t))

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

Re: Emacs 23 Mac port

[Leo]

On 2010-12-03 04:41 +0000, YAMAMOTO Mitsuharu wrote:
>> Indeed there is an infinite loop. But I wasn't able to reproduce the
>> problem with a vanilla Emacs. The problem happens when I am
>> scrolling up (my hand move from bottom to top on the trackpad) and
>> the infinite loop happens in xdisp.c between line 12630 and 12789
>> (the gdb log is attached).
>
> I could reproduce the infinite loop in try_scrolling even with the X11
> build, on both trunk and the emacs-23 branch.  C-g does not help.
>
> 1. emacs -Q
> 2. Evaluate the following expression in *scratch* with C-x C-e.
>    (progn
>      (setq scroll-conservatively 100)
>      (setq scroll-preserve-screen-position 'always)
>      (goto-char (point-min))
>      (set-window-vscroll nil 1 t))
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp

Bug filed.

Thanks.
Leo

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The nineteenth update of the Mac port, which is
experimental/hackers-only, is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.2.91-mac-1.999.tar.gz

This version is based on Emacs 23.2.91 pretest.

** Fixed bugs

*** Pixel-based mouse wheel smooth scrolling behavior is
unintentionally affected by some scroll-related variables.

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

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The twentieth update of the Mac port, which is
experimental/hackers-only, is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.2.92-mac-1.9990.tar.gz

This version is based on Emacs 23.2.92 pretest.

Note: On QuickCursor 2.0, you need to kill the buffer after saving it
in order to reflect the changes to the original text area.

This port will be useful to see if the problems (crash, hang,
slowness, or unexpected behavior) you find with the NS port are
NS-specific issues or not.

** Fixed bugs

*** Functions `mac-get-preference' and `mac-send-apple-event-internal'
may fall into unquittable infinite loop for circular args.

** Improvements

*** New function `mac-convert-property-list' for conversion of
CFPropertyList between several formats: xml1, binary1, and Lisp
representation.  Might be useful for processing webarchive data.

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

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The 21st update of the Mac port, which is experimental/hackers-only,
is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.2.93-mac-1.9991.tar.gz

This version is based on Emacs 23.2.93 pretest.

** Fixed bugs

*** flyspell-buffer for a large buffer doesn't get faster with a
faster machine.

** Improvements

*** flyspell-buffer for a large buffer gets even faster.
Apply Brandon Craig Rhodes's patch in Bug#7343.

*** You can optionally place the pure space to a read-only section by
uncommenting the line beginning with "//#define PURE_SECTION" in
src/s/darwin.h.

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

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 01 Feb 2011 18:40:25 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> The 21st update of the Mac port, which is experimental/hackers-only,
> is now available from

>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.2.93-mac-1.9991.tar.gz

> This version is based on Emacs 23.2.93 pretest.

For Emacs 23.2.94 pretest, I will skip the update of the Mac port; the
patch in the above tarball is also applicable to Emacs 23.2.94.

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

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The 22nd update of the Mac port, which is experimental/hackers-only,
is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3-mac-1.9992.tar.gz

This version is based on Emacs 23.3.  Again, the Mac port itself is
still experimental/hackers-only.

** Fixed bugs

*** Doesn't compile with Xcode 4.

*** Crash with invalid default-process-coding-system value.
Apply Kenichi Handa's fix for Bug#8162.

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

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The 23rd update of the Mac port, which is experimental/hackers-only,
is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3-mac-1.9993.tar.gz

This version is based on Emacs 23.3.  Again, the Mac port itself is
still experimental/hackers-only.

** Fixed bugs

*** Doesn't compile with Xcode 4.1.

*** Scroll bar thumb dragging doesn't work right on Mac OS X 10.7.

*** Static compositions sometimes get truncated.
(See also http://proofgeneral.inf.ed.ac.uk/trac/ticket/409)
Apply Kenichi Handa's fix for Bug#8703.

*** Static compositions by font-lock at the end of buffer cause crash.
(See also http://proofgeneral.inf.ed.ac.uk/trac/ticket/318)
Apply Kenichi Handa's fix for Bug#8915.

** Improvements

*** Color bitmap fonts such as Apple Color Emoji can be displayed if
compiled and run on Mac OS X 10.7.

*** Drag-and-drop highlights the frame under the pointer.

*** Option key temporarily inverts the "Jump to the spot that's
clicked" setting for scroll bars as in other applications.

*** Option key temporarily changes the behavior of line-up/down scroll
bar buttons to page-up/down as in other applications.

*** Holding shift key on startup is recognized as -Q option.

** Notes

*** This release is meant to make minimal adjustment for Mac OS X
10.7.  Don't expect integration with new features of Lion except the
color emoji display support mentioned above.

*** SVG support by WebKit is disabled on 64-bit executables for now,
because it may hang while initializing plugins in some cases.  If you
do need SVG display, then build as a 32-bit executable or use librsvg.

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

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 23 Jul 2011 12:28:38 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> *** SVG support by WebKit is disabled on 64-bit executables for now,
> because it may hang while initializing plugins in some cases.  If
> you do need SVG display, then build as a 32-bit executable or use
> librsvg.

I think I found what caused this problem.  Please apply the patch
available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3-mac-1.9993-svg64.patch.gz

if you need SVG display support on 64-bit executables of the Mac port.

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

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The 24th update of the Mac port, which is experimental/hackers-only,
is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3a-mac-1.9994.tar.gz

This version is based on Emacs 23.3a.  Again, the Mac port itself is
still experimental/hackers-only.

** Fixed bugs

*** SVG display by WebKit is disabled on 64-bit executables.

*** The "Special Characters ..." item in the "Edit" menu doesn't
appear in non-English locales.

*** LastResort font is not shown on Mac OS X 10.7.

*** Pointer shape around the edges/corners becomes the pointing arrow
rather than the resizing arrows on Mac OS X 10.7 when mouse moved.

** Improvements

*** Support for the full screen mode introduced in Mac OS X 10.7.
Now `fullscreen' and `fullboth' values for the `fullscreen' frame
parameter have different meanings on Mac OS X 10.7: the former means a
new system-wide full screen mode with a dedicated desktop (or Space),
and the latter means the existing fullscreen feature.

Known issues: the menu bar does not appear with Control-F2 or
Command-Shift-/, and the tool bar is shown when mouse is moved to the
top even when tool-bar-mode is turned off.  I think these are bugs
(already reported to Apple), and I'd like to see if the situation
is changed with some future OS updates rather than tweaking with some
workarounds.

*** On Mac OS X 10.7, double-tapping either a touch-sensitive mouse
with one finger or a trackpad with two fingers changes the buffer text
scaling to unscaled if previously scaled.  And if previously unscaled,
then the buffer text is scaled so the default font occupies at least
`mac-text-scale-standard-width' columns in the tapped window.

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

Re: Emacs 23 Mac port

[Dimitri Fontaine]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
> *** Support for the full screen mode introduced in Mac OS X 10.7.
> Now `fullscreen' and `fullboth' values for the `fullscreen' frame
> parameter have different meanings on Mac OS X 10.7: the former means a
> new system-wide full screen mode with a dedicated desktop (or Space),
> and the latter means the existing fullscreen feature.

Is there a reason why we don't have fullscreen support for MacOSX in GNU
Emacs?
-- 
dim

Re: Emacs 23 Mac port

[Jan Djärv]

Osx 10.7 style fullscreen is easy to do, but we are in feature freeze. The fullscreen patch that has floated around has not been made suitable for inclusion in Emacs.  I guess fullscren in Mitsuharus port isn't easy to include because of different api:s.


    Jan D. 

6 aug 2011 kl. 13:48 skrev Dimitri Fontaine <dim@tapoueh.org>:

> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>> *** Support for the full screen mode introduced in Mac OS X 10.7.
>> Now `fullscreen' and `fullboth' values for the `fullscreen' frame
>> parameter have different meanings on Mac OS X 10.7: the former means a
>> new system-wide full screen mode with a dedicated desktop (or Space),
>> and the latter means the existing fullscreen feature.
> 
> Is there a reason why we don't have fullscreen support for MacOSX in GNU
> Emacs?
> -- 
> dim

Re: Emacs 23 Mac port

[Alp Aker]

Jan Djärv <jan.h.d@swipnet.se> wrote:

> Osx 10.7 style fullscreen is easy to do, but we are in feature freeze. The
> fullscreen patch that has floated around has not been made suitable for
> inclusion in Emacs.  I guess fullscren in Mitsuharus port isn't easy to
> include because of different api:s.

The easy way to do fullscreen uses Cocoa methods that are only available for
10.6 or later (I'm assuming you're referring to the use of the "setStyleMask"
method for NSWindow).  It seems a little premature to give up on support for
10.4 and 10.5, not to mention giving up on GNUstep.  So if a fullscreen mode
were to implemented in GNU Emacs, it it probably worth it for the time being
to use a strategy like that "typester" patch that's been floating around, as
that doesn't have any version dependencies.

I've actually been working on this and was hoping to get it included as a
bug fix rather than a new feature.  Should I assume it's too late to get it
in 24.1?

Re: Emacs 23 Mac port

[Stefan Monnier]

> I've actually been working on this and was hoping to get it included
> as a bug fix rather than a new feature.  Should I assume it's too late
> to get it in 24.1?

I guess support for fullscreen would not really fall in the "bug
fix" definition, indeed.


        Stefan

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 7 Aug 2011 20:08:02 -0400, Alp Aker <alptekin.aker@gmail.com> said:

> I've actually been working on this and was hoping to get it included
> as a bug fix rather than a new feature.  Should I assume it's too
> late to get it in 24.1?

Perhaps you can use the following item explaining a feature of the Mac
port as a checklist for your implementation of fullscreen for the NS
port:

  * The `fullscreen' frame parameter, with all values supported:
    `fullboth', `fullwidth', `fullheight', and `maximized'.  The
    fullboth frames, which don't have the title bar, still allow us to
    access the menu bar, the Dock (Mac OS X 10.3 and later), and the
    tool bars.  The menu bar can also be activated via
    `menu-bar-open', `Control-F2' (if full keyboard access enabled),
    or `Command-Shift-/' (on Mac OS X 10.5 and later) even for
    fullboth frames where the menu bar is usually hidden.  Changing
    fonts or internal-border-width in fullscreen frames does not
    clutter display.  On multiple monitor environments, one can move
    fullscreen frames to another monitor by setting the `left' and
    `top' frame parameters accordingly.  Attaching/detaching external
    monitors should work even with fullscreen frames.

And also my post in
http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00578.html :

  >>>>> On Fri, 14 Jan 2011 17:23:22 +0100, Žiga Lenarčič <ziga.lenarcic@gmail.com> said:

  > Please include the Mac OS X fullscreen patch in the next version, so
  > I don't have to use separately compiled version.
  > http://cloud.github.com/downloads/typester/emacs/feature-fullscreen.patch

  Besides the interface issue Adrian mentioned, it doesn't do proper
  adjustment for operations that would involve position/size changes if
  they were applied to ordinary frames.  For example,

  (scroll-bar-mode)

  (set-frame-font "Courier-18")

  (set-frame-parameter nil 'left 100)

  (set-frame-parameter nil 'internal-border-width 30)

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

Re: Emacs 23 Mac port

[Jan Djärv]

8 aug 2011 kl. 02:08 skrev Alp Aker <alptekin.aker@gmail.com>:

> Jan Djärv <jan.h.d@swipnet.se> wrote:
> 
>> Osx 10.7 style fullscreen is easy to do, but we are in feature freeze. The
>> fullscreen patch that has floated around has not been made suitable for
>> inclusion in Emacs.  I guess fullscren in Mitsuharus port isn't easy to
>> include because of different api:s.
> 
> The easy way to do fullscreen uses Cocoa methods that are only available for
> 10.6 or later (I'm assuming you're referring to the use of the "setStyleMask"
> method for NSWindow).  It seems a little premature to give up on support for
> 10.4 and 10.5, not to mention giving up on GNUstep.  So if a fullscreen mode
> were to implemented in GNU Emacs, it it probably worth it for the time being
> to use a strategy like that "typester" patch that's been floating around, as
> that doesn't have any version dependencies.
> 

Well, I would expect fullscreen on 10.7 to work as other apps on 10.7.
If someone can take the time to fix other versions, that is fine.


> I've actually been working on this and was hoping to get it included as a
> bug fix rather than a new feature.  Should I assume it's too late to get it
> in 24.1?

I think so. Last I checked the author of the patch that floats around does not have papers.  So don't base your work on that.


    Jan D. 

Re: Emacs 23 Mac port

[David Reitter]

On Aug 7, 2011, at 8:08 PM, Alp Aker wrote:
> 
> The easy way to do fullscreen uses Cocoa methods that are only available for
> 10.6 or later (I'm assuming you're referring to the use of the "setStyleMask"
> method for NSWindow).  It seems a little premature to give up on support for
> 10.4 and 10.5, not to mention giving up on GNUstep.  

In the month of July, 15% of Aquamacs users were still on 10.5, and now 10.7 has come out.

However, if you only look at people who have recently (within the past two years or) have upgraded their installation to one based on Emacs 23 (from Emacs 22), this figure drops to 9%.  Among the users of the latest version of Aquamacs at the time, it's 7%.

Given that Emacs has very limited resources in terms of OS X developers, this suggests to me that supporting certain features only on newer OS variants is warranted; dropping support completely for 10.5 is probably a little early.  

The GNUStep argument may be a stronger one from an ideological standpoint.

> So if a fullscreen mode
> were to implemented in GNU Emacs, it it probably worth it for the time being
> to use a strategy like that "typester" patch that's been floating around, as
> that doesn't have any version dependencies.

As I've said before, feel free to take the Aquamacs code (which is based on typester's patch, combined with support for the standard frame parameters) and turn it into an Emacs patch.  Let me know if I can answer any questions.  (Y. Mitsuharu's 10.7 code sounds great, perhaps it can be used or reimplemented for Cocoa.)

Re: Emacs 23 Mac port

[David Reitter]

On Aug 8, 2011, at 5:48 AM, Jan Djärv wrote:
> 
> I think so. Last I checked the author of the patch that floats around does not have papers.  So don't base your work on that.

Daisuke Murase a.k.a. Typester?
I've exchanged (friendly) e-mails with him a year ago.  Did he say he won't sign papers?

Re: Emacs 23 Mac port

[Jan Djärv]

David Reitter skrev 2011-08-08 15:02:
> On Aug 8, 2011, at 5:48 AM, Jan Djärv wrote:
>>
>> I think so. Last I checked the author of the patch that floats around does not have papers.  So don't base your work on that.
>
> Daisuke Murase a.k.a. Typester?
> I've exchanged (friendly) e-mails with him a year ago.  Did he say he won't sign papers?

Not that I know.

	Jan D.

Re: Emacs 23 Mac port

[Dimitri Fontaine]

Alp Aker <alptekin.aker@gmail.com> writes:
> The easy way to do fullscreen uses Cocoa methods that are only available for
> 10.6 or later (I'm assuming you're referring to the use of the "setStyleMask"
> method for NSWindow).

That would be a start, and better than nothing.

Regards,
-- 
dim

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The 25th update of the Mac port, which is experimental/hackers-only,
is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3a-mac-1.9995.tar.gz

This version is based on Emacs 23.3a.  Again, the Mac port itself is
still experimental/hackers-only.

** Fixed bugs

*** Devanagari string U+0936 U+094D U+0930 U+093F (3 consonants
followed by 1 vowel, but the glyph corresponding to the last vowel
should be displayed first) is displayed wrong and may cause hang.
Reported by Tsuyoshi YASUMA.

*** Executables compiled on Mac OS X 10.6 with
MACOSX_DEPLOYMENT_TARGET=10.5 do not run on Mac OS X 10.5.  This is a
regression introduced in 1.9994.
Note: executables compiled on Mac OS X 10.7 with
MACOSX_DEPLOYMENT_TARGET=10.6 and some optimization flag still do not
run on Mac OS X 10.6, but I think this is a bug about weak linking in
the compiler or linker in Xcode 4.1 and already reported to Apple.

*** Updating display while a frame is resized from the bottom-right
corner does not work via Screen Sharing.  This is a regression
introduced in 1.9993.

*** Updating display while a frame is resized does not work from
non-bottom-right corners or edges on Mac OS X 10.7.

*** Some CPU consumption is observed even if executed with -Q -D (no
timer for cursor blinking) and M-x tool-bar-mode RET on Mac OS X 10.7.

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

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 27 Aug 2011 09:52:54 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> The 25th update of the Mac port, which is experimental/hackers-only,
> is now available from

>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3a-mac-1.9995.tar.gz

Mac OS X 10.7 users may occasionally find an unerased cursor in a line
where face is extended to end of line.  Please apply the patch
available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3a-mac-1.9995-unerased-cursor.patch.gz

Though I think it is rare that users of other versions Mac OS X find
this problem, that can happen in principle.  The root cause of the
problem is actually platform-independent, and I've just reported it as
Bug#9415 (with a patch).

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

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 01 Sep 2011 09:42:45 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>> The 25th update of the Mac port, which is
>> experimental/hackers-only, is now available from

>> ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3a-mac-1.9995.tar.gz

> Mac OS X 10.7 users may occasionally find an unerased cursor in a
> line where face is extended to end of line.  Please apply the patch
> available from

>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3a-mac-1.9995-unerased-cursor.patch.gz

Mac OS X 10.7 users may experience crash if a tool bar contains a
separator (e.g., AUCTeX).  Please apply the patch available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3a-mac-1.9995-lion-toolbar.patch.gz

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

Re: Emacs 23 Mac port

[Lars Magne Ingebrigtsen]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> Mac OS X 10.7 users may experience crash if a tool bar contains a
> separator (e.g., AUCTeX).  Please apply the patch available from
>
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3a-mac-1.9995-lion-toolbar.patch.gz

Could you please post the patches here on the list?  That will result in
a better review, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 06 Oct 2011 21:08:40 +0200, Lars Magne Ingebrigtsen <larsi@gnus.org> said:

> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>> Mac OS X 10.7 users may experience crash if a tool bar contains a
>> separator (e.g., AUCTeX).  Please apply the patch available from
>> 
>> ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3a-mac-1.9995-lion-toolbar.patch.gz

> Could you please post the patches here on the list?  That will
> result in a better review, I think.

The patch is for the Mac port I'm distributing at the place the patch
is uploaded to, and that's why I quoted the original announcement in
my previous post.  Also, the NS port is not affected by this issue.

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

Re: Emacs 23 Mac port

[Lars Magne Ingebrigtsen]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> The patch is for the Mac port I'm distributing at the place the patch
> is uploaded to, and that's why I quoted the original announcement in
> my previous post.  Also, the NS port is not affected by this issue.

Ah.  I misunderstood what the patches were for.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 02 Oct 2011 21:30:20 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>>> The 25th update of the Mac port, which is
>>> experimental/hackers-only, is now available from

>>> ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3a-mac-1.9995.tar.gz

>> Mac OS X 10.7 users may occasionally find an unerased cursor in a
>> line where face is extended to end of line.  Please apply the patch
>> available from

>> ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3a-mac-1.9995-unerased-cursor.patch.gz

> Mac OS X 10.7 users may experience crash if a tool bar contains a
> separator (e.g., AUCTeX).  Please apply the patch available from

>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3a-mac-1.9995-lion-toolbar.patch.gz

I tried adapting the Mac port for ARC (automatic reference counting)
introduced in Xcode 4.2.  I'm planning to include it to the next
release of the Mac port, but if you want to test it now, then apply
the following patch and run configure like "$ CC='clang -fobjc-arc'
./configure ...".

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3a-mac-1.9995-arc.patch.gz

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

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The 26th update of the Mac port, which is experimental/hackers-only,
is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3a-mac-1.9996.tar.gz

This version is based on Emacs 23.3a.  Again, the Mac port itself is
still experimental/hackers-only.

** Fixed bugs

*** The cursor is sometimes unerased.  This bug is not
platform-specific, but happens more frequently on Mac OS X 10.7.
Apply a fix for Bug#9415.

*** Crash when a separator is displayed in the tool bar on Mac OS X
10.7.

*** Can't toggle tool bar visibility for maximized frames on Mac OS X
10.7.

*** While executing AppleScript, pressing the down arrow key is
misinterpreted as `C-_' (usually bound to the undo command).
Reported by Leo.

*** Memory leak by y-or-n-p-with-timeout with GUI (Bug#9830).

** Improvements

*** Can compile with ARC (Automatic Reference Counting) on Xcode 4.2.
Specify CC='clang -fobjc-arc' on configure.

*** When running Ediff on a fullboth frame, it no longer gets obscured
by the menu bar or the Dock even if we focus Ediff Control Panel.

*** Unlike fullboth frames, fullscreen frames no longer occupy the
whole desktop area on Mac OS X 10.7 when the desktop width/height is
not a multiple of the nominal character width/height, respectively.

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

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The 27th update of the Mac port, which is experimental/hackers-only,
is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3b-mac-1.9997.tar.gz

This version is based on Emacs 23.3b.  Again, the Mac port itself is
still experimental/hackers-only.

Some random notes:

  * A few users asked me about the status/plans of the Mac port based
    on Emacs 24.  Currently I don't have any development branches for
    that.

  * The *Carbon* port (based on Emacs 22) executed on Mac OS X 10.7.2
    has a known crash problem when using some features that are
    actually implemented in Cocoa: file dialogs, font panel (via M-x
    mac-font-panel RET), or looking up in dictionary (via
    Command-Control-D or double-tapping a trackpad with three
    fingers).  I think this is not a bug at the application side but a
    problem in toll-free bridge handling in the Core Text framework,
    and have already reported to Apple.  Mac OS X 10.7 or 10.7.1
    didn't have this problem.


** Fixed bugs

*** Several redisplay bugs found in the trunk.
Backport revno 106534, 106517(Bug#10119), 106357, 106345(Bug#9496),
106279(Bug#9947), 106223, and 106220.

*** Several xfns.c bugs found in the trunk.
Adapt revno 106352(Bug#9999), 106293(Bug#9943), 106278(Bug#9943) and
105310 to macfns.c.

** Improvements

*** Toolbars can be hidden/shown from the context menu on Mac OS X
10.7, which doesn't have a toggle button on the title bar.

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

Re: Emacs 23 Mac port

[Carsten Mattner]

On Mon, Nov 28, 2011 at 11:45 AM, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
>  * A few users asked me about the status/plans of the Mac port based
>    on Emacs 24.  Currently I don't have any development branches for
>    that.

I'm late to notice this and would like to ask the following.
Are parts of the "mac port" applicable to Emacs 24 --with-ns Cocoa
fronted? I've had the Cocoa port crash more often than on GNU/Linux
with our without widgets ./configure'd. Also the Cocoa port, contrary to
MacVim.app, cannot display ' properly if I set the font to sgi-screen instead
of Terminus (both in mac dfont format).

Re: Emacs 23 Mac port

[Xu Xin]

On Mon, Nov 28, 2011 at 5:45 AM, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
> The 27th update of the Mac port, which is experimental/hackers-only,
> is now available from
>
>    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3b-mac-1.9997.tar.gz
>
> This version is based on Emacs 23.3b.  Again, the Mac port itself is
> still experimental/hackers-only.
>
> Some random notes:
>
>  * A few users asked me about the status/plans of the Mac port based
>    on Emacs 24.  Currently I don't have any development branches for
>    that.
>
>  * The *Carbon* port (based on Emacs 22) executed on Mac OS X 10.7.2
>    has a known crash problem when using some features that are
>    actually implemented in Cocoa: file dialogs, font panel (via M-x
>    mac-font-panel RET), or looking up in dictionary (via
>    Command-Control-D or double-tapping a trackpad with three
>    fingers).  I think this is not a bug at the application side but a
>    problem in toll-free bridge handling in the Core Text framework,
>    and have already reported to Apple.  Mac OS X 10.7 or 10.7.1
>    didn't have this problem.
>
>
> ** Fixed bugs
>
> *** Several redisplay bugs found in the trunk.
> Backport revno 106534, 106517(Bug#10119), 106357, 106345(Bug#9496),
> 106279(Bug#9947), 106223, and 106220.
>
> *** Several xfns.c bugs found in the trunk.
> Adapt revno 106352(Bug#9999), 106293(Bug#9943), 106278(Bug#9943) and
> 105310 to macfns.c.
>
> ** Improvements
>
> *** Toolbars can be hidden/shown from the context menu on Mac OS X
> 10.7, which doesn't have a toggle button on the title bar.
>
>                                     YAMAMOTO Mitsuharu
>                                mituharu@math.s.chiba-u.ac.jp
>
>

Hi All,

I built a self-contained bundle of Emacs 23 Mac port with the newest
patches, which can download from the link below.

https://github.com/downloads/railwaycat/emacs-mac-port/Emacs.zip

Wish it helpful.

Re: Emacs 23 Mac port

[Jan Djärv]

28 nov 2011 kl. 13:06 skrev Carsten Mattner:

> On Mon, Nov 28, 2011 at 11:45 AM, YAMAMOTO Mitsuharu
> <mituharu@math.s.chiba-u.ac.jp> wrote:
>>  * A few users asked me about the status/plans of the Mac port based
>>    on Emacs 24.  Currently I don't have any development branches for
>>    that.
> 
> I'm late to notice this and would like to ask the following.
> Are parts of the "mac port" applicable to Emacs 24 --with-ns Cocoa
> fronted? I've had the Cocoa port crash more often than on GNU/Linux
> with our without widgets ./configure'd. Also the Cocoa port, contrary to
> MacVim.app, cannot display ' properly if I set the font to sgi-screen instead
> of Terminus (both in mac dfont format).

If you are seeing crashes, I don't think picking parts from the mac port will help much.  Not that I know if there are parts that can be easily "taken".
How about running Emacs in gdb and submitting a bug report with a backtrace when the crash happens?

FWIW, the Fontbook app in OSX can't display ' for sgi-screen either.  So something is wrong in the font.  I guess MacVim.app substitues the bad character for a character from another font.

	Jan D.

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

The 28th update of the Mac port, which is experimental/hackers-only,
is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3.90-mac-1.9998.tar.gz

This version is based on Emacs 23.3.90 pretest.  I hope I can release
version 2.0 shortly after the Emacs 23.4 release.

** Fixed bugs

*** Wrong relief display for sliced images.
Adapt a fix for Bug#10500.

** Improvements

*** If Emacs.app is launched from Finder or via Resume, and there is
no ~/.MacOSX/environment.plist file, then it inherits environment
variable settings of user's login shell.  Note that if Emacs.app is
launched via the `open' command on Mac OS X 10.4 and later, then it
inherits environment variable settings of the shell where the command
is invoked, and this behavior is unchanged.

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

Re: Emacs 23 Mac port

[Xu Xin]

On Sun, Jan 15, 2012 at 1:07 AM, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
> The 28th update of the Mac port, which is experimental/hackers-only,
> is now available from
>
>    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3.90-mac-1.9998.tar.gz
>
> This version is based on Emacs 23.3.90 pretest.  I hope I can release
> version 2.0 shortly after the Emacs 23.4 release.
>
> ** Fixed bugs
>
> *** Wrong relief display for sliced images.
> Adapt a fix for Bug#10500.
>
> ** Improvements
>
> *** If Emacs.app is launched from Finder or via Resume, and there is
> no ~/.MacOSX/environment.plist file, then it inherits environment
> variable settings of user's login shell.  Note that if Emacs.app is
> launched via the `open' command on Mac OS X 10.4 and later, then it
> inherits environment variable settings of the shell where the command
> is invoked, and this behavior is unchanged.
>
>                                     YAMAMOTO Mitsuharu
>                                mituharu@math.s.chiba-u.ac.jp
>

Hi All,

I updated the self-contained build of Emacs 23 Mac port with the
newest patch emacs-23.3.90-mac-1.9998.

Check it out with
https://github.com/downloads/railwaycat/emacs-mac-port/Emacs.zip

--
枕流漱石

Re: Emacs 23 Mac port

[emacs user]

This version seems to have the same memory problem (not returning
memory to the OS) as the regular gnu emacs on OS X.  Aquamacs seems
not to have this issue...(?)

From:	 Xu Xin
On Sun, Jan 15, 2012 at 1:07 AM, YAMAMOTO Mitsuharu wrote:
> The 28th update of the Mac port, which is experimental/hackers-only,
> is now available from
>
>    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.3.90-mac-1.9998.tar.gz
>
> This version is based on Emacs 23.3.90 pretest.  I hope I can release
> version 2.0 shortly after the Emacs 23.4 release.
>
> ** Fixed bugs
>
> *** Wrong relief display for sliced images.
> Adapt a fix for Bug#10500.
>
> ** Improvements
>
> *** If Emacs.app is launched from Finder or via Resume, and there is
> no ~/.MacOSX/environment.plist file, then it inherits environment
> variable settings of user's login shell.  Note that if Emacs.app is
> launched via the `open' command on Mac OS X 10.4 and later, then it
> inherits environment variable settings of the shell where the command
> is invoked, and this behavior is unchanged.
>
>                                     YAMAMOTO Mitsuharu
>

Hi All,

I updated the self-contained build of Emacs 23 Mac port with the
newest patch emacs-23.3.90-mac-1.9998.

Check it out with
https://github.com/downloads/railwaycat/emacs-mac-port/Emacs.zip

--

Re: Emacs 23 Mac port

[Leo]

On 2012-01-16 19:32 +0800, emacs user wrote:
> This version seems to have the same memory problem (not returning
> memory to the OS) as the regular gnu emacs on OS X.  Aquamacs seems
> not to have this issue...(?)

My emacs (mac port 1.9998) is consuming 122M ram ATM. but it is only up
for 8 hours. My previous emacs (mac port 1.9992) has never crashed or
slowed down in any way. It is so perfect that I keep a copy of it in
both binary and source form. And it can run on end for over a month.
Very impressive.

Leo

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 16 Jan 2012 13:32:30 +0200, emacs user <user.emacs@gmail.com> said:

> This version seems to have the same memory problem (not returning
> memory to the OS) as the regular gnu emacs on OS X.  Aquamacs seems
> not to have this issue...(?)

Why is "not returning memory to the OS" a "problem"?  Whether or when
freed memory is returned to the system is up to the implementation of
the malloc library and not something applications should care about in
general.

I don't think the experiment like in

  http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00561.html

makes much sense.  What is more important is to identify whether the
crash "problem" you see with VM is caused by "not returning memory to
the OS" or other reasons.  Did you try the procedure I mentioned
earlier?

  http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00552.html

You should compare the addresses in heap between the second and the
third invocations for example, rather then one between before and
after the first invocation.

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

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 16 Jan 2012 13:32:30 +0200, emacs user <user.emacs@gmail.com> said:

> This version seems to have the same memory problem (not returning
> memory to the OS) as the regular gnu emacs on OS X.  Aquamacs seems
> not to have this issue...(?)

My guess is that Aquamacs is in 32-bit and the others are in 64-bit.

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

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 17 Jan 2012 12:47:38 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>> This version seems to have the same memory problem (not returning
>> memory to the OS) as the regular gnu emacs on OS X.  Aquamacs seems
>> not to have this issue...(?)

> My guess is that Aquamacs is in 32-bit and the others are in 64-bit.

I browsed the source code of the malloc library on Mac OS X 10.7.2,
and found that actually this difference of 32-bit vs. 64-bit affects
the behavior of caching.

For machines equipped with >= 1GB RAM, allocation for size >= 128kB is
handled by the "large" version of malloc/free etc.  And some large
allocations are cached by the malloc library.  For 64-bit executables,
up to 16 cache entries and each entry is up to 128MB.  For 32-bit
executables, up to 8 cache entries and each entry is up to 4MB.  For
both cases, the total cache size is up to 0.1% of RAM.

So if you kill 3 buffers each of which occupies 5MB in size on a 16GB
RAM machine, then 15MB memory is kept as cache by the malloc library
for the 64-bit case even after garbage collection, while it is
returned to the system for the 32-bit case.

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

Re: Emacs 23 Mac port

[YAMAMOTO Mitsuharu]

I am pleased to announce the release of Emacs 23 Mac port 2.0 today.
It is available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.4-mac-2.0.tar.gz

This version is based on Emacs 23.4.

** Fixed bugs

*** Wrong relief color calculation.

** Improvements

*** Add sections for the Mac port in the Emacs info.

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

Re: Emacs 23 Mac port

[Xu Xin]

On Tue, Jan 31, 2012 at 1:52 AM, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
> I am pleased to announce the release of Emacs 23 Mac port 2.0 today.
> It is available from
>
>    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.4-mac-2.0.tar.gz
>
> This version is based on Emacs 23.4.
>
> ** Fixed bugs
>
> *** Wrong relief color calculation.
>
> ** Improvements
>
> *** Add sections for the Mac port in the Emacs info.
>
>                                     YAMAMOTO Mitsuharu
>                                mituharu@math.s.chiba-u.ac.jp
>

Thanks Yamamoto-san for the great job!

I updated the self-contained build of Emacs 23 Mac port with the
newest patch emacs-23.4-mac-2.0

Check it out with
https://github.com/downloads/railwaycat/emacs-mac-port/Emacs.zip

Re: Emacs 23 Mac port

[John Wiegley]

>>>>> Xu Xin <railwaycat@gmail.com> writes:

> Thanks Yamamoto-san for the great job!

Yes, thank you very much for my favorite-of-all Emacs Mac ports!

> I updated the self-contained build of Emacs 23 Mac port with the newest
> patch emacs-23.4-mac-2.0

I've also created an easier means for distribution.  If you add the following
line to /opt/local/etc/macports/source.conf:

    http://www.newartisans.com/macports

Then you can install the latest Macport Emacs using:

    sudo port install emacs-macport

One thing to note: I've disabled file-interlocking behavior in this version
(those funny symbolic links starting with .# that get littered around),
because I find it never useful, and often annoying.  If someone really wants
it to be an option, let me know and I'll add a +interlocking variant.

John