Emacs 23 Mac port

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 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