Emacs Mac port

Emacs Mac port

[YAMAMOTO Mitsuharu]

Emacs 24 Mac port 3.0 is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.1-mac-3.0.tar.gz

This version is based on Emacs 24.1.

** Fixed bugs

*** The `page-curl' transition does not look right on Mac OS X 10.5.

*** Wrong display of the backside image for the
`page-curl-with-shadow' transition on Mac OS X 10.7 with HiDPI mode.

*** Wrong display of animations on Mac OS X 10.5 and 10.6 when
resolution independence is in effect.

*** Incomplete input area (aka "active input area", "marked text", or
"preedit area") does not respect buffer text scaling.
Apply Chong Yidong's fix for Bug#2066.


The first update of Emacs 23 Mac port 2.x is also available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.4-mac-2.1.tar.gz

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

Re: Emacs Mac port

[Paul Michael Reilly]

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

This looks like a nice piece of work so first let me thank you for your
efforts.  I will try it out shortly.

I would also like to understand if there is any reason your work cannot or
should not be installed into the bazaar source tree.  I have been building
my Mac binaries directly from bazaar with no ill effects yet but I am
probably not stressing some of the features or encountering some of the
bugs for which you have provided fixes.

Thanks,

-pmr

On Sun, Jun 10, 2012 at 5:29 AM, YAMAMOTO Mitsuharu <
mituharu@math.s.chiba-u.ac.jp> wrote:

> Emacs 24 Mac port 3.0 is now available from
>
>    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.1-mac-3.0.tar.gz
>
> This version is based on Emacs 24.1.
>
> ** Fixed bugs
>
> *** The `page-curl' transition does not look right on Mac OS X 10.5.
>
> *** Wrong display of the backside image for the
> `page-curl-with-shadow' transition on Mac OS X 10.7 with HiDPI mode.
>
> *** Wrong display of animations on Mac OS X 10.5 and 10.6 when
> resolution independence is in effect.
>
> *** Incomplete input area (aka "active input area", "marked text", or
> "preedit area") does not respect buffer text scaling.
> Apply Chong Yidong's fix for Bug#2066.
>
>
> The first update of Emacs 23 Mac port 2.x is also available from
>
>    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.4-mac-2.1.tar.gz
>
>                                     YAMAMOTO Mitsuharu
>                                mituharu@math.s.chiba-u.ac.jp
>
>

[-- Attachment #2: Type: text/html, Size: 2221 bytes --]

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 10 Jun 2012 18:29:26 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> Emacs 24 Mac port 3.0 is now available from

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

> This version is based on Emacs 24.1.

It turned out that the pixel-based mouse wheel smooth scroll had a
problem: scrolling up the contents of a buffer with a header line is
sometimes jumpy.  Please apply the patch below.  Sorry for the
inconvenience.

(This is due to some incompatibility between Emacs 23 and 24 I
overlooked, so do not apply it to Emacs 23 Mac port 2.1 .)

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

=== modified file 'lisp/term/mac-win.el'
*** lisp/term/mac-win.el	2012-06-01 11:45:25 +0000
--- lisp/term/mac-win.el	2012-06-11 07:14:04 +0000
***************
*** 1977,1982 ****
--- 1977,1987 ----
  				(cadr (pos-visible-in-window-p
  				       (posn-point target-posn) nil t)))
  			       (scrolled-pixel-height (- target-y first-y)))
+ 			  ;; Emacs 23 -> 24 incompatibility: the
+ 			  ;; actual row part of POSITION now counts
+ 			  ;; the header line.
+ 			  (if header-line-height
+ 			      (setq target-row (1- target-row)))
  			  (scroll-up (if (= delta-y scrolled-pixel-height)
  					 target-row
  				       (1+ target-row)))

Re: Emacs Mac port

[Donald Curtis]

In try to patch the latest version, I do,

patch < ../emacs-24.1-mac-3.0/patch-mac 

and i get an error,

patching file Makefile.in
patching file configure.in
patching file Makefile.in
Hunk #1 FAILED at 102.
1 out of 1 hunk FAILED -- saving rejects to file Makefile.in.rej
can't find file to patch at input line 372
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|
|=== modified file 'doc/emacs/anti.texi'
|*** doc/emacs/anti.texi	2012-01-23 06:52:18 +0000
|--- doc/emacs/anti.texi	2012-02-27 23:43:09 +0000
--------------------------
File to patch: 


And so I'm not sure what is happening as I've never had this happen before.  and the file is there… it just seems to be angry.  anyways, I thought you may have encountered this before and I didn't want to clog the mailing list.

On Jun 11, 2012, at 2:29 AM, YAMAMOTO Mitsuharu wrote:

>>>>>> On Sun, 10 Jun 2012 18:29:26 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:
> 
>> Emacs 24 Mac port 3.0 is now available from
> 
>> ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.1-mac-3.0.tar.gz
> 
>> This version is based on Emacs 24.1.
> 
> It turned out that the pixel-based mouse wheel smooth scroll had a
> problem: scrolling up the contents of a buffer with a header line is
> sometimes jumpy.  Please apply the patch below.  Sorry for the
> inconvenience.
> 
> (This is due to some incompatibility between Emacs 23 and 24 I
> overlooked, so do not apply it to Emacs 23 Mac port 2.1 .)
> 
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
> 
> === modified file 'lisp/term/mac-win.el'
> *** lisp/term/mac-win.el	2012-06-01 11:45:25 +0000
> --- lisp/term/mac-win.el	2012-06-11 07:14:04 +0000
> ***************
> *** 1977,1982 ****
> --- 1977,1987 ----
>  				(cadr (pos-visible-in-window-p
>  				       (posn-point target-posn) nil t)))
>  			       (scrolled-pixel-height (- target-y first-y)))
> + 			  ;; Emacs 23 -> 24 incompatibility: the
> + 			  ;; actual row part of POSITION now counts
> + 			  ;; the header line.
> + 			  (if header-line-height
> + 			      (setq target-row (1- target-row)))
>  			  (scroll-up (if (= delta-y scrolled-pixel-height)
>  					 target-row
>  				       (1+ target-row)))
> 
> 

Re: Emacs Mac port

[Donald Curtis]

IGNORE!  DUH...  -p0

seems so obvious that it should be applied automatically but i guess i need to brush up on my linux skills.

Sorry for the extra emails.

DC




On Jul 7, 2012, at 1:10 PM, Donald Curtis wrote:

> In try to patch the latest version, I do,
> 
> patch < ../emacs-24.1-mac-3.0/patch-mac 
> 
> and i get an error,
> 
> patching file Makefile.in
> patching file configure.in
> patching file Makefile.in
> Hunk #1 FAILED at 102.
> 1 out of 1 hunk FAILED -- saving rejects to file Makefile.in.rej
> can't find file to patch at input line 372
> Perhaps you should have used the -p or --strip option?
> The text leading up to this was:
> --------------------------
> |
> |=== modified file 'doc/emacs/anti.texi'
> |*** doc/emacs/anti.texi	2012-01-23 06:52:18 +0000
> |--- doc/emacs/anti.texi	2012-02-27 23:43:09 +0000
> --------------------------
> File to patch: 
> 
> 
> And so I'm not sure what is happening as I've never had this happen before.  and the file is there… it just seems to be angry.  anyways, I thought you may have encountered this before and I didn't want to clog the mailing list.
> 
> On Jun 11, 2012, at 2:29 AM, YAMAMOTO Mitsuharu wrote:
> 
>>>>>>> On Sun, 10 Jun 2012 18:29:26 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:
>> 
>>> Emacs 24 Mac port 3.0 is now available from
>> 
>>> ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.1-mac-3.0.tar.gz
>> 
>>> This version is based on Emacs 24.1.
>> 
>> It turned out that the pixel-based mouse wheel smooth scroll had a
>> problem: scrolling up the contents of a buffer with a header line is
>> sometimes jumpy.  Please apply the patch below.  Sorry for the
>> inconvenience.
>> 
>> (This is due to some incompatibility between Emacs 23 and 24 I
>> overlooked, so do not apply it to Emacs 23 Mac port 2.1 .)
>> 
>> 				     YAMAMOTO Mitsuharu
>> 				mituharu@math.s.chiba-u.ac.jp
>> 
>> === modified file 'lisp/term/mac-win.el'
>> *** lisp/term/mac-win.el	2012-06-01 11:45:25 +0000
>> --- lisp/term/mac-win.el	2012-06-11 07:14:04 +0000
>> ***************
>> *** 1977,1982 ****
>> --- 1977,1987 ----
>> 				(cadr (pos-visible-in-window-p
>> 				       (posn-point target-posn) nil t)))
>> 			       (scrolled-pixel-height (- target-y first-y)))
>> + 			  ;; Emacs 23 -> 24 incompatibility: the
>> + 			  ;; actual row part of POSITION now counts
>> + 			  ;; the header line.
>> + 			  (if header-line-height
>> + 			      (setq target-row (1- target-row)))
>> 			  (scroll-up (if (= delta-y scrolled-pixel-height)
>> 					 target-row
>> 				       (1+ target-row)))
>> 
>> 
> 

Re: Emacs Mac port

[Richard Stallman]

    seems so obvious that it should be applied automatically but i guess i need to brush up on my linux skills.

patch is not part of Linux.  None of the commands you type are part of
Linux -- it is a kernel.  So you probably mean your GNU skills, right?

See http://www.gnu.org/gnu/gnu-linux-faq.html for more explanation.

--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Re: Emacs Mac port

[Samuel Bronson]

On Jul 8, 2012, at 7:15 AM, Richard Stallman wrote:

>    seems so obvious that it should be applied automatically but i  
> guess i need to brush up on my linux skills.
>
> patch is not part of Linux.  None of the commands you type are part of
> Linux -- it is a kernel.  So you probably mean your GNU skills, right?
>
> See http://www.gnu.org/gnu/gnu-linux-faq.html for more explanation.

Oh, hush!  Nobody really cares in everyday conversation...

Re: Emacs Mac port

[Stefan Monnier]

> Oh, hush!  Nobody really cares in everyday conversation...

We do here,


        Stefan

Re: Emacs Mac port

[Donald Curtis]

Let it be known I'm just happy to receive an email from RMS.  August 7
is my birthday if he wants to correct me again on that day.

And yes, GNU is what I meant.


DC



On Jul 8, 2012, at 9:54, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> Oh, hush!  Nobody really cares in everyday conversation...
>
> We do here,
>
>
>        Stefan

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The first update of Emacs 24 Mac port 3.x is available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.1-mac-3.1.tar.gz

This version is based on Emacs 24.1.

** Fixed bugs

*** Scrolling up the contents of a buffer with a header line by mouse
wheel is sometimes jumpy.

*** Several glitches on PowerPC (such as not displaying fringe
bitmaps) due to overlooked WORDS_BIG_ENDIAN -> WORDS_BIGENDIAN change.

*** SVG image (rendered via WebKit) might be clipped if width or
height is unspecified.
Reported by Leo.
Now use max X or Y value of the bounding box if width or height is
specified as a percentage value or unspecified.

*** Double-tapping either a touch-sensitive mouse with one finger or a
trackpad with two fingers on Mac OS X 10.8 64-bit build is ignored.

** Improvements

*** Double-tapping either a touch-sensitive mouse with one finger or a
trackpad with two fingers on Mac OS X 10.7 and later now scales the
text to 150% if previously unscaled and the pointer lies between the
indentation and end of line.

*** Text scaling by gestures now tries to keep the vertical position
of the text under the pointer.

*** Support automatic selection of high resolution versions of images.
All supported image types respect the "@2x" file name convention.  SVG
images (via WebKit or librsvg) are rendered according to the backing
scale factor.  An appropriate image is selected from a multiimage TIFF
containing both 1x and 2x images if the image spec does not contain an
explicit `:index' property.

*** Prefer the integrated GPU to the discrete one for saving battery.
This requires Mac OS X 10.7 and Early 2011 MacBook Pro.


The second update of Emacs 23 Mac port 2.x is also available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.4-mac-2.2.tar.gz

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 26 Jul 2012 18:45:11 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> The first update of Emacs 24 Mac port 3.x is available from

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

> The second update of Emacs 23 Mac port 2.x is also available from

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

I found that the preferred font family selection mechanism in the
mac-ct font backend driver did not work on OS X 10.8 Mountain Lion.
Please apply the patch below.  This is not required for 10.7 and
earlier, though it also works on these versions.

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

=== modified file 'src/macfont.c'
*** src/macfont.c	2012-04-28 03:42:42 +0000
--- src/macfont.c	2012-07-26 21:39:20 +0000
***************
*** 2814,2840 ****
    if (charset_string
        && (length = CFStringGetLength (charset_string)) > 0)
      {
!       CTFontRef last_resort =
! 	CTFontCreateWithName (CFSTR ("LastResort"), 0, NULL);
  
!       if (last_resort)
  	{
! 	  CTFontRef font = CTFontCreateForString (last_resort, charset_string,
! 						  CFRangeMake (0, length));
  
! 	  if (font)
  	    {
! 	      result = CTFontCopyAttribute (font, kCTFontFamilyNameAttribute);
! 
! 	      if (CFStringCompare (result, CFSTR ("LastResort"), 0)
! 		  == kCFCompareEqualTo)
! 		{
! 		  CFRelease (result);
! 		  result = NULL;
! 		}
! 	      CFRelease (font);
  	    }
! 	  CFRelease (last_resort);
  	}
      }
  
--- 2814,2862 ----
    if (charset_string
        && (length = CFStringGetLength (charset_string)) > 0)
      {
!       CFAttributedStringRef attr_string = NULL;
!       CTLineRef ctline = NULL;
!       CFDictionaryRef attrs =
! 	CFDictionaryCreate (NULL, NULL, NULL, 0,
! 			    &kCFTypeDictionaryKeyCallBacks,
! 			    &kCFTypeDictionaryValueCallBacks);
  
!       if (attrs)
  	{
! 	  attr_string = CFAttributedStringCreate (NULL, charset_string, attrs);
! 	  CFRelease (attrs);
! 	}
!       if (attr_string)
! 	{
! 	  ctline = CTLineCreateWithAttributedString (attr_string);
! 	  CFRelease (attr_string);
! 	}
!       if (ctline)
! 	{
! 	  CFArrayRef runs = CTLineGetGlyphRuns (ctline);
! 	  CFIndex i, nruns = CFArrayGetCount (runs);
! 	  CTFontRef font;
  
! 	  for (i = 0; i < nruns; i++)
  	    {
! 	      CTRunRef run = CFArrayGetValueAtIndex (runs, i);
! 	      CFDictionaryRef attributes = CTRunGetAttributes (run);
! 	      CTFontRef font_in_run;
! 
! 	      if (attributes == NULL)
! 		break;
! 	      font_in_run =
! 		CFDictionaryGetValue (attributes, kCTFontAttributeName);
! 	      if (font_in_run == NULL)
! 		break;
! 	      if (i == 0)
! 		font = font_in_run;
! 	      else if (!mac_ctfont_equal_in_postscript_name (font, font_in_run))
! 		break;
  	    }
! 	  if (nruns > 0 && i == nruns)
! 	    result = CTFontCopyAttribute (font, kCTFontFamilyNameAttribute);
! 	  CFRelease (ctline);
  	}
      }
  

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 26 Jul 2012 18:45:11 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:
> The first update of Emacs 24 Mac port 3.x is available from

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

> The second update of Emacs 23 Mac port 2.x is also available from

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

If you build the Mac port with ARC (Automatic Reference Counting)
enabled using the latest Command Line Tools (OS X Lion) for Xcode -
August 2012 that has just released, then you will need to apply a
couple of patches for src/unexmacosx.c I installed into the emacs-24
branch:

  http://bzr.savannah.gnu.org/lh/emacs/emacs-24/revision/108091
  http://bzr.savannah.gnu.org/lh/emacs/emacs-24/revision/108094

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The second update of Emacs 24 Mac port 3.x is available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.2-mac-3.2.tar.gz

This version is based on Emacs 24.2.

** Fixed bugs

*** Preferred font family selection does not work on OS X 10.8.

** Improvements

*** If Emacs.app is launched from Finder or via Resume on OS X 10.8,
then it inherits environment variable settings of user's login shell
regardless of the existence of ~/.MacOSX/environment.plist, which is
ignored on OS X 10.8 anyway.

*** Use sRGB color space instead of device RGB.  This does not change
the appearance on OS X 10.8 which regards device RGB as sRGB.


The third update of Emacs 23 Mac port 2.x is also available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.4-mac-2.3.tar.gz

In addition to the bug fixes and improvements mentioned above, it
contains the following fixes included in the original Emacs 24.2:

** Fixed bugs

*** CVE-2012-3479: Security flaw in enable-local-eval.
(See http://lists.gnu.org/archive/html/emacs-devel/2012-08/msg00396.html)

*** The `nm' command reports src/emacs as a malformed object if built
on OS X 10.8.

*** Cannot build with ARC enabled using Command Line Tools (OS X Lion)
for Xcode - August 2012.

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 27 Aug 2012 16:40:10 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> The second update of Emacs 24 Mac port 3.x is available from
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.2-mac-3.2.tar.gz
> This version is based on Emacs 24.2.

> The third update of Emacs 23 Mac port 2.x is also available from
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.4-mac-2.3.tar.gz

I found a bug in text shaping with Arabic text examples given in

  http://lists.gnu.org/archive/html/bug-gnu-emacs/2012-09/msg00076.html

(especially for the Sheen-Kasratan case) and the Arial font setting as

 (set-fontset-font t 'arabic (font-spec :family "arial" :size 30)) .

Please try the following patch if you see strangeness in complex text
layout.

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

=== modified file 'src/macfont.c'
*** src/macfont.c	2012-08-27 08:21:38 +0000
--- src/macfont.c	2012-09-06 01:16:53 +0000
***************
*** 2419,2431 ****
        to -= j;
        LGLYPH_SET_TO (lglyph, to - 1);
  
!       if (unichars[gl->string_index] >= 0xD800
! 	  && unichars[gl->string_index] < 0xDC00)
! 	LGLYPH_SET_CHAR (lglyph, (((unichars[gl->string_index] - 0xD800) << 10)
! 				  + (unichars[gl->string_index + 1] - 0xDC00)
! 				  + 0x10000));
!       else
! 	LGLYPH_SET_CHAR (lglyph, unichars[gl->string_index]);
  
        LGLYPH_SET_CODE (lglyph, gl->glyph_id);
  
--- 2419,2439 ----
        to -= j;
        LGLYPH_SET_TO (lglyph, to - 1);
  
!       /* LGLYPH_CHAR is used in `describe-char' for checking whether
! 	 the composition is trivial.  */
!       {
! 	UTF32Char c;
! 
! 	if (unichars[gl->string_index] >= 0xD800
! 	    && unichars[gl->string_index] < 0xDC00)
! 	  c = (((unichars[gl->string_index] - 0xD800) << 10)
! 	       + (unichars[gl->string_index + 1] - 0xDC00) + 0x10000);
! 	else
! 	  c = unichars[gl->string_index];
! 	if (macfont_get_glyph_for_character (font, c) != gl->glyph_id)
! 	  c = 0;
! 	LGLYPH_SET_CHAR (lglyph, c);
!       }
  
        LGLYPH_SET_CODE (lglyph, gl->glyph_id);
  
***************
*** 3212,3219 ****
  	      CTRunGetPositions (ctrun, range, &position);
  	      gl->advance_delta = position.x - total_advance;
  	      gl->baseline_delta = position.y;
! 	      gl->advance = CTRunGetTypographicBounds (ctrun, range,
! 						       NULL, NULL, NULL);
  	      total_advance += gl->advance;
  	    }
  
--- 3220,3228 ----
  	      CTRunGetPositions (ctrun, range, &position);
  	      gl->advance_delta = position.x - total_advance;
  	      gl->baseline_delta = position.y;
! 	      gl->advance = (gl->advance_delta
! 			     + CTRunGetTypographicBounds (ctrun, range,
! 							  NULL, NULL, NULL));
  	      total_advance += gl->advance;
  	    }
  

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 27 Aug 2012 16:40:10 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> The second update of Emacs 24 Mac port 3.x is available from
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.2-mac-3.2.tar.gz
> This version is based on Emacs 24.2.

> The third update of Emacs 23 Mac port 2.x is also available from
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.4-mac-2.3.tar.gz

Custom full screen transition animations were not shown as intended on
OS X 10.8.  That's not fatal, but kind of ugly.  If you use this
feature frequently on 10.8, you may want to apply the following patch.

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

=== modified file 'src/macappkit.m'
*** src/macappkit.m	2012-08-16 05:06:02 +0000
--- src/macappkit.m	2012-09-18 05:20:09 +0000
***************
*** 3255,3262 ****
  - (NSArray *)customWindowsToEnterFullScreenForWindow:(NSWindow *)window
  {
    [self setupFullScreenTransitionWindow];
  
!   return [NSArray arrayWithObjects:window, fullScreenTransitionWindow, nil];
  }
  
  - (void)window:(NSWindow *)window
--- 3255,3265 ----
  - (NSArray *)customWindowsToEnterFullScreenForWindow:(NSWindow *)window
  {
    [self setupFullScreenTransitionWindow];
+   /* Custom windows for full screen transition must be on-screen on OS
+      X 10.8.  */
+   [fullScreenTransitionWindow orderFront:nil];
  
!   return [NSArray arrayWithObjects:fullScreenTransitionWindow, window, nil];
  }
  
  - (void)window:(NSWindow *)window
***************
*** 3274,3280 ****
      }
    frameRect = [self preprocessWindowManagerStateChange:fullScreenTargetState];
  
-   [fullScreenTransitionWindow orderFront:nil];
    [window setAlphaValue:0];
    [window setStyleMask:([window styleMask] | NSFullScreenWindowMask)];
  
--- 3277,3282 ----
***************
*** 3312,3319 ****
  - (NSArray *)customWindowsToExitFullScreenForWindow:(NSWindow *)window
  {
    [self setupFullScreenTransitionWindow];
  
!   return [NSArray arrayWithObjects:window, fullScreenTransitionWindow, nil];
  }
  
  - (void)window:(NSWindow *)window
--- 3314,3324 ----
  - (NSArray *)customWindowsToExitFullScreenForWindow:(NSWindow *)window
  {
    [self setupFullScreenTransitionWindow];
+   /* Custom windows for full screen transition must be on-screen on OS
+      X 10.8.  */
+   [fullScreenTransitionWindow orderFront:nil];
  
!   return [NSArray arrayWithObjects:fullScreenTransitionWindow, window, nil];
  }
  
  - (void)window:(NSWindow *)window
***************
*** 3329,3335 ****
      }
    destRect = [self preprocessWindowManagerStateChange:fullScreenTargetState];
  
-   [fullScreenTransitionWindow orderFront:nil];
    [window setAlphaValue:1];
    [window setStyleMask:([window styleMask] & ~NSFullScreenWindowMask)];
  
--- 3334,3339 ----

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 27 Aug 2012 16:40:10 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> The second update of Emacs 24 Mac port 3.x is available from
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.2-mac-3.2.tar.gz
> This version is based on Emacs 24.2.

> The third update of Emacs 23 Mac port 2.x is also available from
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.4-mac-2.3.tar.gz

If you build them with the Command Line Tools for Xcode 4.5 (on both
Lion and Mountain Lion) that has just been released, then it might be
better to apply the following patch that I've just installed to the
emacs-24 branch.  I don't know if there's a real problem without this
patch, but just in case...

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

=== modified file 'src/unexmacosx.c'
*** src/unexmacosx.c	2012-08-27 08:21:38 +0000
--- src/unexmacosx.c	2012-09-20 08:32:27 +0000
***************
*** 117,122 ****
--- 117,129 ----
  
  #include <assert.h>
  
+ /* LC_DATA_IN_CODE is not defined in mach-o/loader.h on OS X 10.7.
+    But it is used if we build with "Command Line Tools for Xcode 4.5
+    (OS X Lion) - Septemper 2012".  */
+ #ifndef LC_DATA_IN_CODE
+ #define LC_DATA_IN_CODE 0x29 /* table of non-instructions in __text */
+ #endif
+ 
  #ifdef _LP64
  #define mach_header			mach_header_64
  #define segment_command			segment_command_64
***************
*** 614,619 ****
--- 621,631 ----
        printf ("LC_MAIN          ");
        break;
  #endif
+ #ifdef LC_DATA_IN_CODE
+     case LC_DATA_IN_CODE:
+       printf ("LC_DATA_IN_CODE  ");
+       break;
+ #endif
  #ifdef LC_SOURCE_VERSION
      case LC_SOURCE_VERSION:
        printf ("LC_SOURCE_VERSION");
***************
*** 1217,1225 ****
  #endif
  
  #ifdef LC_FUNCTION_STARTS
! /* Copy a LC_FUNCTION_STARTS/LC_DYLIB_CODE_SIGN_DRS load command from
!    the input file to the output file, adjusting the data offset
!    field.  */
  static void
  copy_linkedit_data (struct load_command *lc, long delta)
  {
--- 1229,1237 ----
  #endif
  
  #ifdef LC_FUNCTION_STARTS
! /* Copy a LC_FUNCTION_STARTS/LC_DATA_IN_CODE/LC_DYLIB_CODE_SIGN_DRS
!    load command from the input file to the output file, adjusting the
!    data offset field.  */
  static void
  copy_linkedit_data (struct load_command *lc, long delta)
  {
***************
*** 1317,1322 ****
--- 1329,1337 ----
  #endif
  #ifdef LC_FUNCTION_STARTS
        case LC_FUNCTION_STARTS:
+ #ifdef LC_DATA_IN_CODE
+       case LC_DATA_IN_CODE:
+ #endif
  #ifdef LC_DYLIB_CODE_SIGN_DRS
        case LC_DYLIB_CODE_SIGN_DRS:
  #endif

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The third update of Emacs 24 Mac port 3.x is available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.2-mac-3.3.tar.gz

This version is based on Emacs 24.2.

** Fixed bugs

*** Wrong glyph advancement calculation in text shaping for non-zero
advance delta cases.

*** Full screen transition animations are not correct on OS X 10.8.

*** XBM foreground and background are not in sRGB color space.

*** mac-file-alias-p returns t for symbolic links on Mac OS X 10.6 and
later.
Reported by Leo.

*** Scroll bar thumb dragging is not right on Mac OS X 10.6 and
earlier (regression by the previous fix for Mac OS X 10.7 and later.)

** Improvements

*** Help key no longer activates "context help mode" (question-mark
mouse pointer).

*** Popup menu shown by C-mouse-down-1 now includes contextual menu on
Mac OS X 10.6 and later.  Other popup menus remain quiet.

*** Some combinations of regional indicator symbols such as U+1F1EF
followed by U+1F1F5 now display national flags in color emoji on Mac
OS X 10.7 and later.


The fourth update of Emacs 23 Mac port 2.x is also available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-23.4-mac-2.4.tar.gz

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 24.2.90 pretest is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.2.90-mac-3.90.tar.gz

This version (3.9X) should be regarded as experimental/hackers-only.
Things are subject to change/removal in an incompatible way.  Please
refrain from distributing this in any different form, including for
(binary) distribution basis, until the version gets to 4.0.

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

Re: Emacs Mac port

[Leo]

On 2012-11-25 15:26 +0800, YAMAMOTO Mitsuharu wrote:
> This version (3.9X) should be regarded as experimental/hackers-only.
> Things are subject to change/removal in an incompatible way.  Please
> refrain from distributing this in any different form, including for
> (binary) distribution basis, until the version gets to 4.0.

Built and running now.

One thing that is changed:

The toolbar started on even though it is turned off in
org.gnu.Emacs.plist like this:

	<key>Emacs.ToolBar</key>
	<string>off</string>

which works with previous version.

Leo

Re: Emacs Mac port

[chad]

On 25 Nov 2012, at 02:39, Leo <sdl.web@gmail.com> wrote:
> Built and running now.
> 
> One thing that is changed:
> 
> The toolbar started on even though it is turned off in
> org.gnu.Emacs.plist like this:
> 
> 	<key>Emacs.ToolBar</key>
> 	<string>off</string>
> 
> which works with previous version.

Separate from whether or not it stopped working in this revision, I think that you want that key to be Boolean `NO', not string `off'.  

Hope that helps,
~Chad

Re: Emacs Mac port

[Leo]

On 2012-11-25 18:59 +0800, chad wrote:
> Separate from whether or not it stopped working in this revision, I
> think that you want that key to be Boolean `NO', not string `off'.

The emacs manual says it accepts three values: no, off, 0.

Leo

Re: Emacs Mac port

[Glenn Morris]

YAMAMOTO Mitsuharu wrote:

> The Mac port based on Emacs 24.2.90 pretest is now available from
>
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.2.90-mac-3.90.tar.gz

No offence meant, but since this has nothing to do with GNU Emacs
really, maybe you could direct replies about this somewhere other than
emacs-devel.

Re: Emacs Mac port

[Leo]

On 2012-11-26 03:05 +0800, Glenn Morris wrote:
> No offence meant, but since this has nothing to do with GNU Emacs
> really, maybe you could direct replies about this somewhere other than
> emacs-devel.

I hope we can tolerate a few messages once in a few months. The MacPort
is used by many people and is the only way some of us can start using
emacs 24.2.90 in our work, find bugs and occasionally help to fix them.

HTH,
Leo

Re: Emacs Mac port

[John Wiegley]

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

> I hope we can tolerate a few messages once in a few months. The MacPort is
> used by many people and is the only way some of us can start using emacs
> 24.2.90 in our work, find bugs and occasionally help to fix them.

+1

John

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 25 Nov 2012 18:39:59 +0800, Leo <sdl.web@gmail.com> said:

> On 2012-11-25 15:26 +0800, YAMAMOTO Mitsuharu wrote:
>> This version (3.9X) should be regarded as experimental/hackers-only.
>> Things are subject to change/removal in an incompatible way.  Please
>> refrain from distributing this in any different form, including for
>> (binary) distribution basis, until the version gets to 4.0.

> Built and running now.

> One thing that is changed:

> The toolbar started on even though it is turned off in
> org.gnu.Emacs.plist like this:

> 	<key>Emacs.ToolBar</key>
> 	<string>off</string>

> which works with previous version.

Sorry, I overlooked a change in lisp/term/x-win.el.  Please apply the
patch below.

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

=== modified file 'lisp/term/mac-win.el'
*** lisp/term/mac-win.el	2012-11-25 07:28:13 +0000
--- lisp/term/mac-win.el	2012-11-26 03:17:45 +0000
***************
*** 2398,2403 ****
--- 2398,2404 ----
    (if (eq (lookup-key global-map [C-down-mouse-1]) 'mouse-buffer-menu)
        (global-set-key [C-down-mouse-1] 'mac-mouse-buffer-menu))
  
+   (x-apply-session-resources)
    (setq mac-initialized t))
  
  (add-to-list 'display-format-alist '("\\`Mac\\'" . mac))

Re: Emacs Mac port

[Stefan Monnier]

>> No offence meant, but since this has nothing to do with GNU Emacs
>> really, maybe you could direct replies about this somewhere other than
>> emacs-devel.
> I hope we can tolerate a few messages once in a few months.

You seem to have misunderstood Glenn's request.  He's not opposed to
seeing the announcements here, he's only asking for subsequent replies
to go elsewhere.

> The MacPort is used by many people and is the only way some of us can
> start using emacs 24.2.90 in our work, find bugs and occasionally help
> to fix them.

I know some people prefer the MacPort over our NS port (and vice-versa),
but I don't know that the difference can be such that the NS port is not
even an option.
Of course, maybe I just forgot about it.  Do we have a bug-number(s) for
the corresponding problem(s)?


        Stefan

Re: Emacs Mac port

[chad]

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

On 26 Nov 2012, at 12:38, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> I know some people prefer the MacPort over our NS port (and vice-versa),
> but I don't know that the difference can be such that the NS port is not
> even an option.
> Of course, maybe I just forgot about it.  Do we have a bug-number(s) for
> the corresponding problem(s)?

I had hoped to try to merge some of the mac port changes after
the last round of discussion indicated that merging was, let's
say unlikely. Aside from reliability issues in both ports (which
I assume are bugs to be hunted and killed as normal), I think the
biggest issue is the color space and font handling. Whether or
not this bothers you depends on your personal settings, in my
experience - when I first started looking into this, I used a set
of colors and fonts that really didn't show any important (to me)
differences between the two, but I have since started using a
zenburn theme that really highlights the issue. I'm including a
clipping that I hope illustrates the issue, with the mac port on
the left and the ns port on the right.

I'm hoping to take another shot at merging display approaches
when the ports line up again for 24.3, but I wouldn't wait anyone
to rely on me - I'm not familiar with the subsystems involved,
and my free time is sporadic.

I hope this helps,
~Chad






[-- Attachment #2.1: Type: text/html, Size: 2127 bytes --]

[-- Attachment #2.2: emacs-diff.png --]
[-- Type: image/png, Size: 70635 bytes --]

Re: Emacs Mac port

[Leo]

On 2012-11-27 04:38 +0800, Stefan Monnier wrote:
> You seem to have misunderstood Glenn's request.  He's not opposed to
> seeing the announcements here, he's only asking for subsequent replies
> to go elsewhere.

Yes, this is what I understood. Normally there is not much discussion
about issues in MacPort, so I hope they can live in this ML for now.

[snipped 4 lines]
> I know some people prefer the MacPort over our NS port (and vice-versa),
> but I don't know that the difference can be such that the NS port is not
> even an option.
> Of course, maybe I just forgot about it.  Do we have a bug-number(s) for
> the corresponding problem(s)?

I have used the NS port for more than one year if I remember correctly.
During that time there was little response to any bug report in the NS
port so I moved on. Things might have changed given all these years so I
have little idea what it is like these days.

In the two years that I have been using MacPort, I have reported via
private emails to its author a dozen bugs, all of which were fixed
within a day or two with detailed explanation of what was going on. I
highly appreciate such a quality support and feel safer and happier
using MacPort.

Having said that, I encourage new comers to use NS port
whenever/wherever I can.

Leo

Re: Emacs Mac port

[Leo]

On 2012-11-27 05:46 +0800, chad wrote:
> I'm hoping to take another shot at merging display approaches
> when the ports line up again for 24.3, but I wouldn't wait anyone
> to rely on me - I'm not familiar with the subsystems involved,
> and my free time is sporadic.

Thank you in advance for taking the time to look into this ;)

Leo

Re: Emacs Mac port

[Jan Djärv]

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

Hello.

It would help if you specified the colors used in the screenshot exactly. Then we could at least compare colors for X11 and Nextstep.

    Jan D.

26 nov 2012 kl. 22:46 skrev chad <yandros@MIT.EDU>:

> On 26 Nov 2012, at 12:38, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> I know some people prefer the MacPort over our NS port (and vice-versa),
>> but I don't know that the difference can be such that the NS port is not
>> even an option.
>> Of course, maybe I just forgot about it.  Do we have a bug-number(s) for
>> the corresponding problem(s)?
> 
> I had hoped to try to merge some of the mac port changes after
> the last round of discussion indicated that merging was, let's
> say unlikely. Aside from reliability issues in both ports (which
> I assume are bugs to be hunted and killed as normal), I think the
> biggest issue is the color space and font handling. Whether or
> not this bothers you depends on your personal settings, in my
> experience - when I first started looking into this, I used a set
> of colors and fonts that really didn't show any important (to me)
> differences between the two, but I have since started using a
> zenburn theme that really highlights the issue. I'm including a
> clipping that I hope illustrates the issue, with the mac port on
> the left and the ns port on the right.
> 
> I'm hoping to take another shot at merging display approaches
> when the ports line up again for 24.3, but I wouldn't wait anyone
> to rely on me - I'm not familiar with the subsystems involved,
> and my free time is sporadic.
> 
> I hope this helps,
> ~Chad
> 
> 
> <emacs-diff.png>
> 
> 

[-- Attachment #2: Type: text/html, Size: 2333 bytes --]

Re: Emacs Mac port

[chad]

On 26 Nov 2012, at 20:32, Jan Djärv <jan.h.d@swipnet.se> skrev:

> It would help if you specified the colors used in the screenshot exactly. Then we could at least compare colors for X11 and Nextstep.

Ah, good point; just giving the name isn't entirely clear.  I'm using the zenburn theme from:  https://github.com/bbatsov/zenburn-emacs.git

A bigger comparison shot of the zenburn theme (with rainbow-mode) between the mac port and bzr head this morning is here:

	http://www.mit.edu/~yandros/emacs-mac-ns-ports.png

Thanks!
~Chad

Re: Emacs Mac port

[Donald Curtis]

I don't know specifics, but in the home-brew (https://github.com/mxcl/homebrew) build script for emacs, there is an option `srgb` which does some color fixes in the NS version,

Specifically, in nsterm,

replace,
"*col = [NSColor colorWithCalibratedRed: r green: g blue: b alpha: 1.0];",

with,
"*col = [NSColor colorWithDeviceRed: r green: g blue: b alpha: 1.0];"

There is something about the calibrated version that made colors look different than in other versions of emacs, specifically X11. Well, I should say, they would look different than other programs generating the same color. And you can test this in OS X by using "DigitalColor Meter",

1. Set a background color in hex,
2. Use "DigitalColor Meter" to get the color from the window.

And you'll see that the color being generated is *not* the color you specified, well, at least it wasn't on Mac, but maybe this is not an issue on NS.  However this may be related to some of your struggles with color differences.

Here is the Homebrew bug report:
https://github.com/mxcl/homebrew/pull/5194

And here is the corresponding GNU bug report:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8402

I'm definitely more on the side of doing what the user *expects* (which is to use colorWithDeviceRed) over what is technically correct (the current way of using colorWithCalibratedRed). But it hasn't been an issue for me since I use home-brew and just specify the --srgb compile option.


	Donald




On Nov 27, 2012, at 1:33 PM, chad <yandros@MIT.EDU> wrote:

> On 26 Nov 2012, at 20:32, Jan Djärv <jan.h.d@swipnet.se> skrev:
> 
>> It would help if you specified the colors used in the screenshot exactly. Then we could at least compare colors for X11 and Nextstep.
> 
> Ah, good point; just giving the name isn't entirely clear.  I'm using the zenburn theme from:  https://github.com/bbatsov/zenburn-emacs.git
> 
> A bigger comparison shot of the zenburn theme (with rainbow-mode) between the mac port and bzr head this morning is here:
> 
> 	http://www.mit.edu/~yandros/emacs-mac-ns-ports.png
> 
> Thanks!
> ~Chad

Re: Emacs Mac port

[Jan Djärv]

Hello.

1 dec 2012 kl. 15:04 skrev Donald Curtis <dcurtis@gmail.com>:

> I don't know specifics, but in the home-brew (https://github.com/mxcl/homebrew) build script for emacs, there is an option `srgb` which does some color fixes in the NS version,
> 
> Specifically, in nsterm,
> 
> replace,
> "*col = [NSColor colorWithCalibratedRed: r green: g blue: b alpha: 1.0];",
> 
> with,
> "*col = [NSColor colorWithDeviceRed: r green: g blue: b alpha: 1.0];"

This is "The Wrong Thing To Do" (TM) according to all documentation.
FWIW, it makes no difference on the two Macs I tried. Are you running 10.6 or earlier?

> 
> There is something about the calibrated version that made colors look different than in other versions of emacs, specifically X11. Well, I should say, they would look different than other programs generating the same color. And you can test this in OS X by using "DigitalColor Meter",
> 
> 1. Set a background color in hex,
> 2. Use "DigitalColor Meter" to get the color from the window.
> 
> And you'll see that the color being generated is *not* the color you specified, well, at least it wasn't on Mac, but maybe this is not an issue on NS.  However this may be related to some of your struggles with color differences.

It is indeed the color I specified if I choose "Generic RGB".  I'm not sure which is the correct one to use, but you can choose between "Original values", "sRGB", "Generic RGB" and "Adobe RGB".

> Here is the Homebrew bug report:
> https://github.com/mxcl/homebrew/pull/5194
> 
> And here is the corresponding GNU bug report:
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8402
> 
> I'm definitely more on the side of doing what the user *expects* (which is to use colorWithDeviceRed) over what is technically correct (the current way of using colorWithCalibratedRed). But it hasn't been an issue for me since I use home-brew and just specify the --srgb compile option.

--srgb sounds like the wrong name for this option, if it just enables the use of device colors.
Is "the user" all users, ot just a subset of users using a particular OSX version?

We could have an option for using srgb color space or device color space, but I think calibrated is the right default.

	Jan D.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 24.2.91 pretest is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.2.91-mac-3.91.tar.gz

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

** Fixed bugs

*** Disabling tool bar mode via the Preference system (X resources
emulation) does not work.
Reported by Leo.

*** Tool bar visibility is not preserved when entering/exiting full
screen on Mac OS X 10.7 and later (actually this is a bug in AppKit).

*** Background color is not in sRGB color space for image types GIF,
PNG, TIFF, and IMAGE-IO.

** Improvements

*** You can run the executable from the build directory (via `open
mac/Emacs.app') without doing `make install'.  Forgot to mention in
the previous release.

*** Support alpha channel masks for image types GIF, PNG, TIFF, and
IMAGE-IO with keeping the postprocessing functionality (`:conversion'
and `:mask').  Not for SVG images rendered with WebKit because proper
text smoothing requires opaque background.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 24.2.92 pretest is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.2.92-mac-3.92.tar.gz

On Mac OS X 10.7 and later, you can test some composition features for
emoji characters by:

;;;; Emoji composition tests
;;; Regional indicators (#x1F1E6 - #x1F1FF)
(insert (mapconcat (lambda (s) (mapcar (lambda (c) (+ c (- #x1F1FF ?Z))) s))
		   '("CN" "DE" "ES" "FR" "GB" "IT" "JP" "KR" "RU" "US")
		   " "))
;;; Variation Selectors 15 (text-style) and 16 (emoji-style)
(insert (mapconcat
	 (lambda (c) (format "#x%04x:\t%c\uFE0E\u20E3 %c\uFE0F\u20E3" c c c))
	 (cdr (assq 'keycap mac-emoji-variation-characters-alist)) "\n")
	?\n
	(mapconcat
	 (lambda (c) (format "#x%04x:\t%c\uFE0E %c\uFE0F" c c c))
	 (mapconcat 'cdr mac-emoji-variation-characters-alist "") "\n"))

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

** Fixed bugs

*** Two-finger click with a trackpad on the mode-line causes errors on
OS X 10.8.

*** Key events are discarded while AppleScript is executed.

** Improvements

*** Add an info node for images and colors to the Mac port section.

*** Support Variation Selectors 15 (text-style) and 16 (emoji-style).

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 24.2.93 pretest is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.2.93-mac-3.93.tar.gz

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

** Fixed bugs

*** Rare crash in mac_get_selected_range.

*** Breakage of `--with-wide-int' on other builds.
Reported by Peter Dyballa.
Note: the option `--with-wide-int' is not eagerly tested on the Mac
port.  Use it at your own risk.

*** `emacsclient -c' does not work.
Reported by Piotr Kalinowski.

** Improvements

*** Work around the problem that scrolling may leave some spots when
LCD text smoothing is enabled.

Re: Emacs Mac port

[Piotr Kalinowski]

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

> The Mac port based on Emacs 24.2.93 pretest is now available from
>
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.2.93-mac-3.93.tar.gz
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
>
> ** Fixed bugs

[snip...]

> *** `emacsclient -c' does not work.
> Reported by Piotr Kalinowski.

Yes, thank you very much.

Regards,
Piotr Kalinowski

Re: Emacs Mac port

[Pavlo Martynenko]

On 9 Feb 2013, at 09:26, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:

> The Mac port based on Emacs 24.2.93 pretest is now available from
> 
>    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.2.93-mac-3.93.tar.gz
> 
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
> 
> ** Fixed bugs
> 
> *** Rare crash in mac_get_selected_range.
> 
> *** Breakage of `--with-wide-int' on other builds.
> Reported by Peter Dyballa.
> Note: the option `--with-wide-int' is not eagerly tested on the Mac
> port.  Use it at your own risk.
> 
> *** `emacsclient -c' does not work.
> Reported by Piotr Kalinowski.

"emacsclient -c" works fine when server was started from normally running emacs by (server-start).

But when the server was started with --daemon option. The first time when emacsclient connects emacs eats 100% of cpu in main thread. And after client disconnects and connects again the server crashes on EXC_BAD_ACCESS in check_x_display_info.

"emacsclient -t" terminates just after connect with exit code 1.

Also I noticed increased cpu usage from 0.3 up to 4.0% when emacs frame minimised in the Dock. The same can not be said about the NS port.

> ** Improvements
> 
> *** Work around the problem that scrolling may leave some spots when
> LCD text smoothing is enabled.
> 

Re: Emacs Mac port

[Piotr Kalinowski]

Pavlo Martynenko <pavelmart@gmail.com> writes:

> Also I noticed increased cpu usage from 0.3 up to 4.0% when emacs
> frame minimised in the Dock. The same can not be said about the NS
> port.

The exact numbers are different for me, but I can as well observe order
of magnitude increase in CPU usage for minimised frame.

Regards,
Piotr Kalinowski

-- 
Intelligence is like a river: the deeper it is, the less noise it makes.

Re: Emacs Mac port

[Dmitry Antipov]

On 02/15/2013 07:48 PM, Piotr Kalinowski wrote:

> Pavlo Martynenko <pavelmart@gmail.com> writes:
>
>> Also I noticed increased cpu usage from 0.3 up to 4.0% when emacs
>> frame minimised in the Dock. The same can not be said about the NS
>> port.
>
> The exact numbers are different for me, but I can as well observe order
> of magnitude increase in CPU usage for minimised frame.

Hm... can someone try bzr revision before r111594? This change was not
really tested on W32/NS.

My minimized 'emacs -Q' now eats 0.4% CPU on GNU/Linux, BTW.

Dmitry

Re: Emacs Mac port

[Eli Zaretskii]

> Date: Fri, 15 Feb 2013 20:03:20 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> Cc: pavelmart@gmail.com, emacs-devel@gnu.org
> 
> Hm... can someone try bzr revision before r111594? This change was not
> really tested on W32/NS.

No change in CPU usage on w32, when a frame is minimized.

Re: Emacs Mac port

[Glenn Morris]

>>> Also I noticed increased cpu usage from 0.3 up to 4.0% when emacs
>>> frame minimised in the Dock. The same can not be said about the NS port.
                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Note that the OP is reporting an issue that does not occur in GNU Emacs.
Once again, I don't know why this is being discussed on emacs-devel.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 14 Feb 2013 14:02:08 +0200, Pavlo Martynenko <pavelmart@gmail.com> said:

> "emacsclient -c" works fine when server was started from normally
> running emacs by (server-start).

> But when the server was started with --daemon option. The first time
> when emacsclient connects emacs eats 100% of cpu in main thread. And
> after client disconnects and connects again the server crashes on
> EXC_BAD_ACCESS in check_x_display_info.

> "emacsclient -t" terminates just after connect with exit code 1.

The Mac port is supposed to provide TTY-only sessions if invoked with
the --deamon option.  I'll look into this problem later so as to avoid
the crash at least.

> Also I noticed increased cpu usage from 0.3 up to 4.0% when emacs
> frame minimised in the Dock. The same can not be said about the NS
> port.

This is a serious problem and specific to the Mac port.  Please try
the following patch and send a report to me (not to the list) if you
find some problem with this patch.

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

=== modified file 'src/mac.c'
*** src/mac.c	2013-01-11 07:33:09 +0000
--- src/mac.c	2013-02-16 03:41:22 +0000
***************
*** 3117,3122 ****
--- 3117,3131 ----
    return event;
  }
  
+ static bool
+ mac_has_non_cgs_events_p (void)
+ {
+   ItemCount count = GetNumEventsInQueue (GetCurrentEventQueue ());
+ 
+   return (count > 1
+ 	  || (count == 1 && GetEventClass (mac_peek_next_event ()) != 'cgs '));
+ }
+ 
  #if !SELECT_USE_GCD
  static struct
  {
***************
*** 3272,3283 ****
  	     mac_run_loop_run_once again so as to avoid wasting CPU
  	     time caused by vacuous reactivation of delayed visible
  	     toolbar item validation via window update events issued
! 	     in the application event loop.  */
  	  do
  	    {
  	      timeoutval = mac_run_loop_run_once (timeoutval);
  	    }
! 	  while (timeoutval && !mac_peek_next_event ()
  		 && !detect_input_pending ());
  	  if (timeoutval == 0)
  	    timedout_p = 1;
--- 3281,3297 ----
  	     mac_run_loop_run_once again so as to avoid wasting CPU
  	     time caused by vacuous reactivation of delayed visible
  	     toolbar item validation via window update events issued
! 	     in the application event loop.
! 
! 	     Also, on Mac OS X 10.5 or later, the application receives
! 	     an event 'cgs '/15 if there is a miniaturized window.  We
! 	     don't want to break the loop in this case for a similar
! 	     reason.  */
  	  do
  	    {
  	      timeoutval = mac_run_loop_run_once (timeoutval);
  	    }
! 	  while (timeoutval && !mac_has_non_cgs_events_p ()
  		 && !detect_input_pending ());
  	  if (timeoutval == 0)
  	    timedout_p = 1;
***************
*** 3394,3400 ****
  	  timeoutval = mac_run_loop_run_once (timeoutval);
  	}
        while (timeoutval && !wokeup_from_run_loop_run_once_p
! 	     && !mac_peek_next_event () && !detect_input_pending ());
        if (timeoutval == 0)
  	timedout_p = 1;
  
--- 3408,3414 ----
  	  timeoutval = mac_run_loop_run_once (timeoutval);
  	}
        while (timeoutval && !wokeup_from_run_loop_run_once_p
! 	     && !mac_has_non_cgs_events_p () && !detect_input_pending ());
        if (timeoutval == 0)
  	timedout_p = 1;
  
***************
*** 3416,3422 ****
  	  timeoutval = mac_run_loop_run_once (timeoutval);
  	}
        while (timeoutval && !wokeup_from_run_loop_run_once_p
! 	     && !mac_peek_next_event () && !detect_input_pending ());
        if (timeoutval == 0)
  	timedout_p = 1;
  
--- 3430,3436 ----
  	  timeoutval = mac_run_loop_run_once (timeoutval);
  	}
        while (timeoutval && !wokeup_from_run_loop_run_once_p
! 	     && !mac_has_non_cgs_events_p () && !detect_input_pending ());
        if (timeoutval == 0)
  	timedout_p = 1;
  

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 16 Feb 2013 15:46:00 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>> Also I noticed increased cpu usage from 0.3 up to 4.0% when emacs
>> frame minimised in the Dock. The same can not be said about the NS
>> port.

> This is a serious problem and specific to the Mac port.  Please try
> the following patch and send a report to me (not to the list) if you
> find some problem with this patch.

Sorry, I found that key event handling became sluggish when there are
both iconified and uniconified frames.  It may take some time to solve
this problem.

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 16 Feb 2013 17:21:35 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>>> Also I noticed increased cpu usage from 0.3 up to 4.0% when emacs
>>> frame minimised in the Dock. The same can not be said about the NS
>>> port.

>> This is a serious problem and specific to the Mac port.  Please try
>> the following patch and send a report to me (not to the list) if
>> you find some problem with this patch.

> Sorry, I found that key event handling became sluggish when there
> are both iconified and uniconified frames.  It may take some time to
> solve this problem.

For the moment, please cancel the previous patch and apply the
following one.

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

=== modified file 'src/macappkit.m'
*** src/macappkit.m	2013-02-09 07:26:28 +0000
--- src/macappkit.m	2013-02-16 11:01:41 +0000
***************
*** 6970,6981 ****
  	      EmacsWindow *window = FRAME_MAC_WINDOW_OBJECT (f);
  
  	      x_flush (f);
! #if MAC_OS_X_VERSION_MIN_REQUIRED < 1050
! 	      /* Mac OS X 10.4 seems not to reset the flag
! 		 `viewsNeedDisplay' on autodisplay.  */
! 	      if (floor (NSAppKitVersionNumber) <= NSAppKitVersionNumber10_4)
! 		[window setViewsNeedDisplay:NO];
! #endif
  	      /* Check which frames are still visible.  We do this
  		 here because there doesn't seem to be any direct
  		 notification that the visibility of a window has
--- 6970,6976 ----
  	      EmacsWindow *window = FRAME_MAC_WINDOW_OBJECT (f);
  
  	      x_flush (f);
! 	      [window setViewsNeedDisplay:NO];
  	      /* Check which frames are still visible.  We do this
  		 here because there doesn't seem to be any direct
  		 notification that the visibility of a window has

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 24.3 release candidate 1 is now available
from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3-rc1-mac-3.94.tar.gz

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

Remove mac-system-locale.
When the locale setting is derived from the Preferences AppleLocale or
AppleLanguages (i.e., none of "LC_ALL", "LC_CTYPE" or "LANG" is set),
encoding is assumed to be UTF-8.

** Fixed bugs

*** Daemon mode crashes when connected from `emacsclient -c'.
Reported by Pavlo Martynenko.

*** Waste CPU time when there is an iconified frame.
Reported by Pavlo Martynenko.

*** Frame display is not updated immediately when deiconified.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 24.3 is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3-mac-4.0.tar.gz

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

** Fixed bugs

*** Smooth scrolling down the fancy splash screen causes an error.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The first update of Emacs 24.3 Mac port 4.x is available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3-mac-4.1.tar.gz

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

** Fixed bugs

*** Crash if an unknown font/fontset is set to default-frame-alist.

*** Invoking Service producing output does not replace the selected
text.
Reported by Nicholas Riley.

*** Invoking Service via C-mouse-down-1 may not insert the output
correctly.

** Improvements

*** Add sound support.  Like on other platforms, it is synchronous and
you cannot quit it with C-g.

*** Round frame bottom corners on OS X 10.7 and later, even when
internal-border-width is 0.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 11 Apr 2013 18:22:54 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> The first update of Emacs 24.3 Mac port 4.x is available from
> ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3-mac-4.1.tar.gz

> ** Improvements

> *** Round frame bottom corners on OS X 10.7 and later, even when
> internal-border-width is 0.

This change seems to trigger a *platform-independent* display bug.
The symptom is that the upper part of the cursor in the echo area is
sometimes unerased, especially during isearch in a large buffer.

It is due to inconsistency of the values of `cursor_in_echo_area'
between the update-time (i.e., drawing accompanied by the current
matrix construction) and the expose-time (drawing in response to the
Expose event).  Both cases may call the function
`get_window_cursor_type', which refers to the global variable
`cursor_in_echo_area'.  But its value might have been changed between
the two timings by a typical let-binding of the Lisp variable
`cursor-in-echo-area'.

The fix should be done in the platform-independent part of course, but
unfortunately that seems to become a nontrivial change.  For the
moment, please use the following workaround that is specific to the
Mac port if this bug is annoying for you.

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

=== modified file 'src/macappkit.h'
*** src/macappkit.h	2013-04-11 09:28:06 +0000
--- src/macappkit.h	2013-04-14 05:52:02 +0000
***************
*** 358,363 ****
--- 358,367 ----
    /* Whether scrollRect:by: has copied rounded bottom corner area.  */
    BOOL roundedBottomCornersCopied;
  
+   /* XXX: workaround for inconsistency of cursor_in_echo_area values
+      between update-time and expose-time.  */
+   BOOL cursorInEchoAreaSaved, savedCursorInEchoArea;
+ 
    /* Raw key event that is interpreted by intepretKeyEvents:.  */
    NSEvent *rawKeyEvent;
  
***************
*** 380,385 ****
--- 384,390 ----
  - (NSRect)firstRectForCharacterRange:(NSRange)aRange
  			 actualRange:(NSRangePointer)actualRange;
  - (void)viewFrameDidChange:(NSNotification *)notification;
+ - (void)saveCursorInEchoArea;
  @end
  
  /* Class for view in the overlay window of an Emacs frame window.  */

=== modified file 'src/macappkit.m'
*** src/macappkit.m	2013-04-11 09:28:06 +0000
--- src/macappkit.m	2013-04-14 05:52:02 +0000
***************
*** 2784,2789 ****
--- 2784,2791 ----
  	    {
  	      rect = [emacsView convertRect:rect fromView:nil];
  	      [emacsView setNeedsDisplayInRect:rect];
+ 	      if ([emacsView isKindOfClass:[EmacsMainView class]])
+ 		[(EmacsMainView *)emacsView saveCursorInEchoArea];
  	    }
  	}
      }
***************
*** 3864,3870 ****
--- 3866,3884 ----
  
  - (void)drawRect:(NSRect)aRect
  {
+   BOOL origCursorInEchoArea;
+ 
+   if (cursorInEchoAreaSaved)
+     {
+       origCursorInEchoArea = cursor_in_echo_area;
+       cursor_in_echo_area = savedCursorInEchoArea;
+     }
    [super drawRect:aRect];
+   if (cursorInEchoAreaSaved)
+     {
+       cursor_in_echo_area = origCursorInEchoArea;
+       cursorInEchoAreaSaved = NO;
+     }
    roundedBottomCornersCopied = NO;
  }
  
***************
*** 3894,3899 ****
--- 3908,3919 ----
      }
  }
  
+ - (void)saveCursorInEchoArea
+ {
+   cursorInEchoAreaSaved = YES;
+   savedCursorInEchoArea = cursor_in_echo_area;
+ }
+ 
  - (void)setMarkedText:(id)aString
  {
    if (markedText == aString)

Re: Emacs Mac port

[Eli Zaretskii]

> Date: Sun, 14 Apr 2013 15:31:05 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> This change seems to trigger a *platform-independent* display bug.
> The symptom is that the upper part of the cursor in the echo area is
> sometimes unerased, especially during isearch in a large buffer.
> 
> It is due to inconsistency of the values of `cursor_in_echo_area'
> between the update-time (i.e., drawing accompanied by the current
> matrix construction) and the expose-time (drawing in response to the
> Expose event).  Both cases may call the function
> `get_window_cursor_type', which refers to the global variable
> `cursor_in_echo_area'.  But its value might have been changed between
> the two timings by a typical let-binding of the Lisp variable
> `cursor-in-echo-area'.

Sorry, I don't understand: why would an expose event trigger erasing
of a cursor in the minibuffer window?

Could you possibly describe in detail the sequence of events that
leads to this problem, and perhaps also give a reproducible recipe?
And how is this related to the size of the buffer and isearch?

Better make all that a bug report.

Thanks.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 14 Apr 2013 14:49:56 +0300, Eli Zaretskii <eliz@gnu.org> said:

> Sorry, I don't understand: why would an expose event trigger erasing
> of a cursor in the minibuffer window?

> Could you possibly describe in detail the sequence of events that
> leads to this problem, and perhaps also give a reproducible recipe?
> And how is this related to the size of the buffer and isearch?

> Better make all that a bug report.

The actual scenario is rather complicated and mostly specific to the
newest version of the Mac port, and difficult to reproduce on the
other platforms (or earlier versions of the Mac port), because it is
difficult to predict when expose events happen.  I'll explain the
scenario at the end of this mail, but you can just skip it.  The point
is, the cursor shape depends on the *current value* of
`cursor-in-echo-area' and it may be different between the last
redisplay and the subsequent expose_frame.

Simply recording the value of `cursor-in-echo-area' seems to work and
need only a small change.  Recording the calculated cursor shape would
be more efficient, but would require nontrivial changes.

=== modified file 'src/dispextern.h'
*** src/dispextern.h	2013-03-28 14:04:49 +0000
--- src/dispextern.h	2013-04-15 01:48:51 +0000
***************
*** 665,670 ****
--- 665,674 ----
       line.  */
    unsigned header_line_p : 1;
  
+   /* Value of cursor_in_echo_area as of last window update.  Set in
+      set_window_cursor_after_update.  */
+   unsigned cursor_in_echo_area_p : 1;
+ 
  #ifdef GLYPH_DEBUG
    /* A string identifying the method used to display the matrix.  */
    char method[512];

=== modified file 'src/dispnew.c'
*** src/dispnew.c	2013-04-02 01:54:56 +0000
--- src/dispnew.c	2013-04-15 01:48:51 +0000
***************
*** 3860,3865 ****
--- 3860,3866 ----
    /* Not intended for frame matrix updates.  */
    eassert (FRAME_WINDOW_P (f));
  
+   w->current_matrix->cursor_in_echo_area_p = cursor_in_echo_area;
    if (cursor_in_echo_area
        && !NILP (echo_area_buffer[0])
        /* If we are showing a message instead of the mini-buffer,

=== modified file 'src/xdisp.c'
*** src/xdisp.c	2013-04-02 01:54:56 +0000
--- src/xdisp.c	2013-04-15 01:48:51 +0000
***************
*** 25481,25487 ****
    *active_cursor = 1;
  
    /* Echo area */
!   if (cursor_in_echo_area
        && FRAME_HAS_MINIBUF_P (f)
        && EQ (FRAME_MINIBUF_WINDOW (f), echo_area_window))
      {
--- 25481,25487 ----
    *active_cursor = 1;
  
    /* Echo area */
!   if (w->current_matrix && w->current_matrix->cursor_in_echo_area_p
        && FRAME_HAS_MINIBUF_P (f)
        && EQ (FRAME_MINIBUF_WINDOW (f), echo_area_window))
      {


The actual scenario on the latest version of the Mac port: (you can
skip it)

First of all, on OS X 10.7 and later, the bottom corners of an
ordinary window are rounded if every drawing happens in response to an
"expose" (in X11 terminology) event.  This does not apply to Emacs,
and the previous versions of the Mac port (and also the current NS
port) show square frame bottom corner(s) if internal-border-width is
0.

The newest version of the Mac port implements rounded bottom corners
by invalidating the bottom area (containing echo area partly) when
drawing operations outside "expose" events might have drawn into one
of the bottom corners.  This invalidation triggers an "expose" event
at the next event.

1. A Lisp program (e.g. isearch) shows a message with temporarily
   setting `cursor-in-echo-area' by let-binding.

2. Emacs performs redisplay.  At this moment, the cursor is drawn in
   the echo area because `cursor-in-echo-area' is set.

3. At the end of update, the invalidation explained above happens.
   The height of the invalidated area is 4 (~ the radius of the
   rounded corner) and it partially overlaps with the echo area.

4. At the next event loop, expose_frame is called, and the echo area
   is redrawn with setting the clipping area to the invalidated area.
   But at this moment, `cursor-in-echo-area' is already cleared.  So
   the cursor is not drawn and the lower half of the cursor is cleared
   and upper half remains displayed because of clipping.

5. The Lisp program shows the same message again, but
   `cursor-in-echo-area' is nil this time.

6. Redisplay happens again.  The display engine considers the cursor
   has already been cleared (at the last expose) and do not clear or
   draw the cursor.  As a result, the upper half of the cursor remains
   displayed and lower half looks cleared.

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

Re: Emacs Mac port

[Eli Zaretskii]

> Date: Mon, 15 Apr 2013 11:17:20 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: emacs-devel@gnu.org
> 
> Simply recording the value of `cursor-in-echo-area' seems to work and
> need only a small change.  Recording the calculated cursor shape would
> be more efficient, but would require nontrivial changes.
> 
> === modified file 'src/dispextern.h'
> *** src/dispextern.h	2013-03-28 14:04:49 +0000
> --- src/dispextern.h	2013-04-15 01:48:51 +0000
> ***************
> *** 665,670 ****
> --- 665,674 ----
>        line.  */
>     unsigned header_line_p : 1;
>   
> +   /* Value of cursor_in_echo_area as of last window update.  Set in
> +      set_window_cursor_after_update.  */
> +   unsigned cursor_in_echo_area_p : 1;
> + 
>   #ifdef GLYPH_DEBUG
>     /* A string identifying the method used to display the matrix.  */
>     char method[512];
> 
> === modified file 'src/dispnew.c'
> *** src/dispnew.c	2013-04-02 01:54:56 +0000
> --- src/dispnew.c	2013-04-15 01:48:51 +0000
> ***************
> *** 3860,3865 ****
> --- 3860,3866 ----
>     /* Not intended for frame matrix updates.  */
>     eassert (FRAME_WINDOW_P (f));
>   
> +   w->current_matrix->cursor_in_echo_area_p = cursor_in_echo_area;
>     if (cursor_in_echo_area
>         && !NILP (echo_area_buffer[0])
>         /* If we are showing a message instead of the mini-buffer,
> 
> === modified file 'src/xdisp.c'
> *** src/xdisp.c	2013-04-02 01:54:56 +0000
> --- src/xdisp.c	2013-04-15 01:48:51 +0000
> ***************
> *** 25481,25487 ****
>     *active_cursor = 1;
>   
>     /* Echo area */
> !   if (cursor_in_echo_area
>         && FRAME_HAS_MINIBUF_P (f)
>         && EQ (FRAME_MINIBUF_WINDOW (f), echo_area_window))
>       {
> --- 25481,25487 ----
>     *active_cursor = 1;
>   
>     /* Echo area */
> !   if (w->current_matrix && w->current_matrix->cursor_in_echo_area_p
>         && FRAME_HAS_MINIBUF_P (f)
>         && EQ (FRAME_MINIBUF_WINDOW (f), echo_area_window))
>       {
> 
> 
> The actual scenario on the latest version of the Mac port: (you can
> skip it)
> 
> First of all, on OS X 10.7 and later, the bottom corners of an
> ordinary window are rounded if every drawing happens in response to an
> "expose" (in X11 terminology) event.  This does not apply to Emacs,
> and the previous versions of the Mac port (and also the current NS
> port) show square frame bottom corner(s) if internal-border-width is
> 0.
> 
> The newest version of the Mac port implements rounded bottom corners
> by invalidating the bottom area (containing echo area partly) when
> drawing operations outside "expose" events might have drawn into one
> of the bottom corners.  This invalidation triggers an "expose" event
> at the next event.
> 
> 1. A Lisp program (e.g. isearch) shows a message with temporarily
>    setting `cursor-in-echo-area' by let-binding.
> 
> 2. Emacs performs redisplay.  At this moment, the cursor is drawn in
>    the echo area because `cursor-in-echo-area' is set.
> 
> 3. At the end of update, the invalidation explained above happens.
>    The height of the invalidated area is 4 (~ the radius of the
>    rounded corner) and it partially overlaps with the echo area.
> 
> 4. At the next event loop, expose_frame is called, and the echo area
>    is redrawn with setting the clipping area to the invalidated area.
>    But at this moment, `cursor-in-echo-area' is already cleared.  So
>    the cursor is not drawn and the lower half of the cursor is cleared
>    and upper half remains displayed because of clipping.
> 
> 5. The Lisp program shows the same message again, but
>    `cursor-in-echo-area' is nil this time.
> 
> 6. Redisplay happens again.  The display engine considers the cursor
>    has already been cleared (at the last expose) and do not clear or
>    draw the cursor.  As a result, the upper half of the cursor remains
>    displayed and lower half looks cleared.

Thanks.

I wish that platform-specific display tricks would not abuse
platform-independent display mechanisms in this way.  I mean, making
the window edges round by triggering expose events as result of
previous redisplay.  Can't this be done in the Mac display back-end
instead?

While adding a flag to the glyph matrix looks like a no-brainer at
first sight, doing so for a benefit of a single platform is something
that at the very least should be heavily commented (including the
above sequence).  Otherwise, a few years from now, when this issue is
no longer relevant, how can we even start thinking whether this flag
is still needed or not?

Also, there are several details that need to be figured out:

 . what about the same flag of the desired_matrix -- should it be
   cleared explicitly, and if so, where?

 . should this flag of the current_matrix be cleared after the cursor
   is displayed?  If not, how can we be sure that during the next
   redisplay cycle, optimizations that bypass most of glyph matrix
   construction will not use a stale value?

 . what if redisplay was preempted? in that case,
   set_window_cursor_after_update is not called, and the flag keeps
   its previous value even if cursor_in_echo_area has changed.

etc., etc.

IOW, I'm unhappy with this change, and would like much better a
solution that doesn't affect every platform out there (including
text-mode display, btw).

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 15 Apr 2013 08:44:04 +0300, Eli Zaretskii <eliz@gnu.org> said:

> I wish that platform-specific display tricks would not abuse
> platform-independent display mechanisms in this way.  I mean, making
> the window edges round by triggering expose events as result of
> previous redisplay.  Can't this be done in the Mac display back-end
> instead?

No, it's not an abuse at all.  Invalidating the area that needs to be
updated and let the "expose" handler draw is a very standard
(sometimes only) way of drawing even on GTK+.

The similar inconsistency in Emacs display can also happen on other
platforms in principle, depending on the timing of the "expose" event.
The only difference is the invalidation happens internally/actively or
externally/passively.  That's why the latter is difficult to
reproduce.

> While adding a flag to the glyph matrix looks like a no-brainer at
> first sight, doing so for a benefit of a single platform is
> something that at the very least should be heavily commented
> (including the above sequence).  Otherwise, a few years from now,
> when this issue is no longer relevant, how can we even start
> thinking whether this flag is still needed or not?

The reason is simple: the expose handler should recover the contents
of the previous redisplay with respect to the requested rectangle.  I
think it is natural and the expected behavior actually.  The current
code uses wrong information (i.e., the value of `cursor-in-echo-area'
as of "expose") in this respect.  Again, the bug itself is not
specific to a single platform.

> Also, there are several details that need to be figured out:

>  . what about the same flag of the desired_matrix -- should it be
> cleared explicitly, and if so, where?

The same question probably applies to the existing `begv' and 'zv'
members of `struct glyph_matrix': they are meaningful/used only for
the current matrix and never cleared.

>  . should this flag of the current_matrix be cleared after the
> cursor is displayed?  If not, how can we be sure that during the
> next redisplay cycle, optimizations that bypass most of glyph matrix
> construction will not use a stale value?

>  . what if redisplay was preempted? in that case,
> set_window_cursor_after_update is not called, and the flag keeps its
> previous value even if cursor_in_echo_area has changed.

> etc., etc.

> IOW, I'm unhappy with this change, and would like much better a
> solution that doesn't affect every platform out there (including
> text-mode display, btw).

If someone proposes more appropriate way and/or place to record the
status of the cursor so that the subsequent "expose" handler call can
recover the result of previous redisplay, I would really appreciate
it.

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

Re: Emacs Mac port

[Eli Zaretskii]

> Date: Mon, 15 Apr 2013 16:59:31 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: emacs-devel@gnu.org
> 
> >>>>> On Mon, 15 Apr 2013 08:44:04 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
> > I wish that platform-specific display tricks would not abuse
> > platform-independent display mechanisms in this way.  I mean, making
> > the window edges round by triggering expose events as result of
> > previous redisplay.  Can't this be done in the Mac display back-end
> > instead?
> 
> No, it's not an abuse at all.  Invalidating the area that needs to be
> updated and let the "expose" handler draw is a very standard
> (sometimes only) way of drawing even on GTK+.

I was talking specifically about invalidating fractions of screen
lines (a.k.a. "glyph rows").

I'm still interested to know why this cannot be done entirely in the
display back-end.

> The similar inconsistency in Emacs display can also happen on other
> platforms in principle, depending on the timing of the "expose" event.
> The only difference is the invalidation happens internally/actively or
> externally/passively.  That's why the latter is difficult to
> reproduce.

I suspect that triggering the event internally is the only situation
where this can happen, because it might cause the expose event be
delivered between two successive redisplay cycles that would normally
take care of the change in the value of cursor_in_echo_area.

> > While adding a flag to the glyph matrix looks like a no-brainer at
> > first sight, doing so for a benefit of a single platform is
> > something that at the very least should be heavily commented
> > (including the above sequence).  Otherwise, a few years from now,
> > when this issue is no longer relevant, how can we even start
> > thinking whether this flag is still needed or not?
> 
> The reason is simple: the expose handler should recover the contents
> of the previous redisplay with respect to the requested rectangle.

And yet we don't see the result on any other platform.

> >  . what about the same flag of the desired_matrix -- should it be
> > cleared explicitly, and if so, where?
> 
> The same question probably applies to the existing `begv' and 'zv'
> members of `struct glyph_matrix': they are meaningful/used only for
> the current matrix and never cleared.

Those members are only tested to see whether the last redisplay cycle
ran to completion, and whether the displayed buffer changed behind
redisplay's back.  A stale value here can at worst cause redundant
redisplays.  By contrast, the flag you are suggesting, if stale, will
cause the cursor be redrawn incorrectly, IIUC.

> If someone proposes more appropriate way and/or place to record the
> status of the cursor so that the subsequent "expose" handler call can
> recover the result of previous redisplay, I would really appreciate
> it.

I'm still interested to know why this cannot be handled in the Mac
specific display back-end code.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 15 Apr 2013 11:55:34 +0300, Eli Zaretskii <eliz@gnu.org> said:

>> No, it's not an abuse at all.  Invalidating the area that needs to
>> be updated and let the "expose" handler draw is a very standard
>> (sometimes only) way of drawing even on GTK+.

> I was talking specifically about invalidating fractions of screen
> lines (a.k.a. "glyph rows").

> I'm still interested to know why this cannot be done entirely in the
> display back-end.

I'm using the "expose" handler for recovering the display contents
through invalidation, because that is really what it is for.

On Mac, the "expose" handler is called in many situations than you
might expect including outside the control of application code: e.g.,
creating a snapshot of the window image for icons or "Exposé"
(http://support.apple.com/kb/HT2503).  I'm not sure about other
platforms/toolkits, but I wouldn't be surprised if similar things
happen there for providing some fancy features.  Nowadays, drawing
outside the "expose" handler is exceptional and subject to several
restrictions.

>> The similar inconsistency in Emacs display can also happen on other
>> platforms in principle, depending on the timing of the "expose"
>> event.  The only difference is the invalidation happens
>> internally/actively or externally/passively.  That's why the latter
>> is difficult to reproduce.

> I suspect that triggering the event internally is the only situation
> where this can happen, because it might cause the expose event be
> delivered between two successive redisplay cycles that would
> normally take care of the change in the value of
> cursor_in_echo_area.

What about this example?

(progn
  (let ((cursor-in-echo-area t))
    (message "foo")
    (sit-for 0))
  (sleep-for 10))

If the "expose" event happen for the echo area during the execution of
sleep-for, would the cursor be correctly recovered?

>> The reason is simple: the expose handler should recover the
>> contents of the previous redisplay with respect to the requested
>> rectangle.

> And yet we don't see the result on any other platform.

You don't agree the principle for the "expose" handler above (i.e., it
should recover the contents of the previous redisplay)?  Then what is
your expected behavior of the "expose" handler?

I don't insist my patch is correct.  But I'd say the current behavior
is wrong and the fix should be done in the platform-independent part
rather than in the code for a particular platform where the problem
happens to easily emerge.

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

Re: Emacs Mac port

[Eli Zaretskii]

> Date: Mon, 15 Apr 2013 18:48:29 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: emacs-devel@gnu.org
> 
> > I'm still interested to know why this cannot be done entirely in the
> > display back-end.
> 
> I'm using the "expose" handler for recovering the display contents
> through invalidation, because that is really what it is for.
> 
> On Mac, the "expose" handler is called in many situations than you
> might expect including outside the control of application code: e.g.,
> creating a snapshot of the window image for icons or "Exposé"
> (http://support.apple.com/kb/HT2503).  I'm not sure about other
> platforms/toolkits, but I wouldn't be surprised if similar things
> happen there for providing some fancy features.  Nowadays, drawing
> outside the "expose" handler is exceptional and subject to several
> restrictions.

Sorry, I don't understand.  I was asking why the code that makes the
corners of the window round cannot be run directly from the GUI
drawing code of the Mac display back-end, e.g., from the update_end
method.  Why does it _have_ to be run from the expose handler?

> (progn
>   (let ((cursor-in-echo-area t))
>     (message "foo")
>     (sit-for 0))
>   (sleep-for 10))
> 
> If the "expose" event happen for the echo area during the execution of
> sleep-for, would the cursor be correctly recovered?

I cannot make it produce an incorrect cursor, but maybe I don't
generate the expose event as you intended.  How did you do it?  Does
the expose event on the Mac interrupt sleep-for?

> >> The reason is simple: the expose handler should recover the
> >> contents of the previous redisplay with respect to the requested
> >> rectangle.
> 
> > And yet we don't see the result on any other platform.
> 
> You don't agree the principle for the "expose" handler above (i.e., it
> should recover the contents of the previous redisplay)?  Then what is
> your expected behavior of the "expose" handler?

I don't like the expose event being used for this purpose in the first
place.  Platform-specific pixel-level drawing shouldn't IMO be exposed
to the device-independent portions of the display engine.

And second, I don't think I understand what needs to be recovered
except what the glyph matrix describes.  The redisplay that happens in
response to the expose event needs to know where to draw the cursor
and how to draw it _at_the_moment_of_redisplay_; why is it important
where the cursor was during previous redisplay cycle, if it is no
longer there and shouldn't be there?

> I don't insist my patch is correct.  But I'd say the current behavior
> is wrong and the fix should be done in the platform-independent part
> rather than in the code for a particular platform where the problem
> happens to easily emerge.

I asked you to describe a series of events that could reproduce such a
problem, and your description was about a Mac-specific feature.  If
this is a platform-independent problem, there should be a way of
reproducing it on other platforms as well.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 15 Apr 2013 13:57:14 +0300, Eli Zaretskii <eliz@gnu.org> said:

>> I'm using the "expose" handler for recovering the display contents
>> through invalidation, because that is really what it is for.
>> 
>> On Mac, the "expose" handler is called in many situations than you
>> might expect including outside the control of application code:
>> e.g., creating a snapshot of the window image for icons or "Exposé"
>> (http://support.apple.com/kb/HT2503).  I'm not sure about other
>> platforms/toolkits, but I wouldn't be surprised if similar things
>> happen there for providing some fancy features.  Nowadays, drawing
>> outside the "expose" handler is exceptional and subject to several
>> restrictions.

> Sorry, I don't understand.  I was asking why the code that makes the
> corners of the window round cannot be run directly from the GUI
> drawing code of the Mac display back-end, e.g., from the update_end
> method.  Why does it _have_ to be run from the expose handler?

I actually tried to round the bottom corners by calling some
undocumented API from update_end_hook in the very first trial.
Repeated rounding made the corner shaper because of anti-aliasing
there.

Again, invalidating an area to let the "expose" handler draw
afterwards is a very standard, primary, canonical, and sometimes only
way of drawing nowadays.  (If you call it is an abuse or trick, you'll
be laughed.)  Application frameworks also treat it as primary, so the
other unusual drawing methods (i.e., outside the "expose" handler) are
not the primary target, and some newer features are not available if
you use "nonstandard" ways of drawing.  Bottom corner rounding is just
an example of such cases.

>> (progn (let ((cursor-in-echo-area t)) (message "foo") (sit-for 0))
>> (sleep-for 10))
>> 
>> If the "expose" event happen for the echo area during the execution
>> of sleep-for, would the cursor be correctly recovered?

> I cannot make it produce an incorrect cursor, but maybe I don't
> generate the expose event as you intended.  How did you do it?

If you use a window system implementation that uses "backing store" to
avoid frequent "expose", then it is difficult to produce the "expose"
event intentionally by uncovering the window.

> Does the expose event on the Mac interrupt sleep-for?

sleep-for is usually blocking at `select' (or its emulation) call,
which is supposed to return when some window system event (such as C-g
or expose) becomes available.  The "expose" handler is called there.

>> You don't agree the principle for the "expose" handler above (i.e.,
>> it should recover the contents of the previous redisplay)?  Then
>> what is your expected behavior of the "expose" handler?

> I don't like the expose event being used for this purpose in the
> first place.  Platform-specific pixel-level drawing shouldn't IMO be
> exposed to the device-independent portions of the display engine.

You can't tell how "expose" events are used from Application
frameworks or toolkits.  Whether you like it or not, contemporary ones
(such as GTK+ and Cocoa) treat the "expose" handler as the primary
drawing method and use it accordingly, regardless of the internal use
from the application code.

> And second, I don't think I understand what needs to be recovered
> except what the glyph matrix describes.  The redisplay that happens
> in response to the expose event needs to know where to draw the
> cursor and how to draw it _at_the_moment_of_redisplay_; why is it
> important where the cursor was during previous redisplay cycle, if
> it is no longer there and shouldn't be there?

What's displayed is assumed to be unchanged until the next redisplay
in the first place, even if several "expose" events happen in between.
Otherwise, you can't use several optimizations in redisplay that
reuse the existing contents.

>> I don't insist my patch is correct.  But I'd say the current
>> behavior is wrong and the fix should be done in the
>> platform-independent part rather than in the code for a particular
>> platform where the problem happens to easily emerge.

> I asked you to describe a series of events that could reproduce such
> a problem, and your description was about a Mac-specific feature.
> If this is a platform-independent problem, there should be a way of
> reproducing it on other platforms as well.

As I said above, you'll need a window system implementation that
doesn't use "backing store" in order to reproduce the phenomena
reliably.

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

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

>>>>> On Tue, 16 Apr 2013 09:17:33 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>> Sorry, I don't understand.  I was asking why the code that makes
>> the corners of the window round cannot be run directly from the GUI
>> drawing code of the Mac display back-end, e.g., from the update_end
>> method.  Why does it _have_ to be run from the expose handler?

> I actually tried to round the bottom corners by calling some
> undocumented API from update_end_hook in the very first trial.
> Repeated rounding made the corner shaper because of anti-aliasing
> there.

s/shaper/sharper/

The attached images shows the difference.


[-- Attachment #2: normal.png --]
[-- Type: image/png, Size: 1720 bytes --]

[-- Attachment #3: sharper.png --]
[-- Type: image/png, Size: 1765 bytes --]

[-- Attachment #4: Type: text/plain, Size: 2625 bytes --]


Below is the patch of the first trial that I finally rejected myself,
against the previous version (emacs-24.3-mac-4.0) of the Mac port.

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

=== modified file 'src/macappkit.h'
*** src/macappkit.h	2013-03-19 06:08:36 +0000
--- src/macappkit.h	2013-04-03 00:24:59 +0000
***************
*** 807,812 ****
--- 807,816 ----
  @end
  #endif
  
+ @interface NSWindow (Undocumented)
+ - (void)_maskRoundedBottomCorners:(NSRect)clipRect;
+ @end
+ 
  #if MAC_OS_X_VERSION_MAX_ALLOWED < 1060
  @interface NSMenu (AvailableOn1060AndLater)
  - (BOOL)popUpMenuPositioningItem:(NSMenuItem *)item

=== modified file 'src/macappkit.m'
*** src/macappkit.m	2013-04-03 00:08:55 +0000
--- src/macappkit.m	2013-04-03 00:24:59 +0000
***************
*** 3610,3615 ****
--- 3610,3616 ----
  
    unset_global_focus_view_frame ();
    [frameController unlockFocusOnEmacsView];
+   mac_mask_rounded_bottom_corners (f);
    [window enableFlushWindow];
  }
  
***************
*** 3715,3720 ****
--- 3716,3736 ----
    [frameController invalidateCursorRectsForEmacsView];
  }
  
+ void
+ mac_mask_rounded_bottom_corners (struct frame *f)
+ {
+   NSWindow *window = FRAME_MAC_WINDOW_OBJECT (f);
+ 
+   if ([window respondsToSelector:@selector(_maskRoundedBottomCorners:)])
+     {
+       NSView *contentView = [window contentView];
+       NSRect rect = [contentView visibleRect];
+ 
+       rect = [contentView convertRect:rect toView:nil];
+       [window _maskRoundedBottomCorners:rect];
+     }
+ }
+ 
  \f
  /************************************************************************
  			   View and Drawing

=== modified file 'src/macterm.c'
*** src/macterm.c	2013-01-12 05:16:32 +0000
--- src/macterm.c	2013-04-03 00:24:59 +0000
***************
*** 2836,2841 ****
--- 2836,2842 ----
    block_input ();
  
    mac_invert_rectangles (f, rects, nrects);
+   mac_mask_rounded_bottom_corners (f);
  
    x_flush (f);
  
***************
*** 2863,2868 ****
--- 2864,2870 ----
    }
  
    mac_invert_rectangles (f, rects, nrects);
+   mac_mask_rounded_bottom_corners (f);
  
    x_flush (f);
  

=== modified file 'src/macterm.h'
*** src/macterm.h	2013-03-18 02:33:51 +0000
--- src/macterm.h	2013-04-03 00:24:59 +0000
***************
*** 651,656 ****
--- 651,657 ----
  
  extern int mac_tracking_area_works_with_cursor_rects_invalidation_p (void);
  extern void mac_invalidate_frame_cursor_rects (struct frame *f);
+ extern void mac_mask_rounded_bottom_corners (struct frame *);
  extern int mac_webkit_supports_svg_p (void);
  
  extern CFTypeRef mac_sound_create (Lisp_Object, Lisp_Object);

Re: Emacs Mac port

[Eli Zaretskii]

> Date: Tue, 16 Apr 2013 09:17:33 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: emacs-devel@gnu.org
> 
> I actually tried to round the bottom corners by calling some
> undocumented API from update_end_hook in the very first trial.
> Repeated rounding made the corner shaper because of anti-aliasing
> there.

So how delegating this to the time expose event is handled overcomes
that problem?  IOW, what code handles the rounding in response to the
expose event, and why can't you call or trigger the same code from
update_end_hook?

> Again, invalidating an area to let the "expose" handler draw
> afterwards is a very standard, primary, canonical, and sometimes only
> way of drawing nowadays.  (If you call it is an abuse or trick, you'll
> be laughed.)

You can laugh, if you want, but I still think it's abuse, and won't be
convinced by being laughed at.

> If you use a window system implementation that uses "backing store" to
> avoid frequent "expose", then it is difficult to produce the "expose"
> event intentionally by uncovering the window.

Which window systems we support don't use "backing store"?

> > I don't like the expose event being used for this purpose in the
> > first place.  Platform-specific pixel-level drawing shouldn't IMO be
> > exposed to the device-independent portions of the display engine.
> 
> You can't tell how "expose" events are used from Application
> frameworks or toolkits.  Whether you like it or not, contemporary ones
> (such as GTK+ and Cocoa) treat the "expose" handler as the primary
> drawing method and use it accordingly, regardless of the internal use
> from the application code.

We have no control on how other software is written.  We only have
control on how Emacs is designed and implemented.

Look, I'm wearing here the hat of an Emacs maintainer who is concerned
about the maintainability of the Emacs display code in the long run.
Witness the amount of discussions lately that involve flags and
options for which no one remembers their purpose or intended use any
longer.  Witness the amount of changes done recently on the trunk to
rightfully remove ancient crud, which sometimes later turns out to be
needed, for reasons no one at the time cared to document clearly
enough.  You are suggesting to add one more such flag, don't you see?
Who will remember a few years from now why it was needed, which
problem on what platform(s) it fixed, and how that problem could be
reproduced?  I'll tell you: NO ONE WILL REMEMBER!!

So arguments that describe how other software works are of no value
here, because the size and activity of the maintenance teams of these
other projects are most probably very different from the "team" that
maintains the Emacs display code.  IOW, by telling time and again how
these techniques are used elsewhere, you are wasting your time.

> > And second, I don't think I understand what needs to be recovered
> > except what the glyph matrix describes.  The redisplay that happens
> > in response to the expose event needs to know where to draw the
> > cursor and how to draw it _at_the_moment_of_redisplay_; why is it
> > important where the cursor was during previous redisplay cycle, if
> > it is no longer there and shouldn't be there?
> 
> What's displayed is assumed to be unchanged until the next redisplay
> in the first place, even if several "expose" events happen in between.
> Otherwise, you can't use several optimizations in redisplay that
> reuse the existing contents.

Sorry, you lost me here.  An expose event just triggers another
redisplay, so what's that "unchanged until the next redisplay" about?

> >> I don't insist my patch is correct.  But I'd say the current
> >> behavior is wrong and the fix should be done in the
> >> platform-independent part rather than in the code for a particular
> >> platform where the problem happens to easily emerge.
> 
> > I asked you to describe a series of events that could reproduce such
> > a problem, and your description was about a Mac-specific feature.
> > If this is a platform-independent problem, there should be a way of
> > reproducing it on other platforms as well.
> 
> As I said above, you'll need a window system implementation that
> doesn't use "backing store" in order to reproduce the phenomena
> reliably.

If there are no such systems except the Mac, then in practice this
still is a problem specific to that single platform.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 16 Apr 2013 09:49:17 +0300, Eli Zaretskii <eliz@gnu.org> said:

>> I actually tried to round the bottom corners by calling some
>> undocumented API from update_end_hook in the very first trial.
>> Repeated rounding made the corner shaper because of anti-aliasing
>> there.

> So how delegating this to the time expose event is handled overcomes
> that problem?  IOW, what code handles the rounding in response to
> the expose event, and why can't you call or trigger the same code
> from update_end_hook?

The problem due to anti-aliasing happens if you round the corners
multiple times.  Exposing the bottom part can make sure that the
corners are freshly redrawn and rounding is always done exactly once.

That shows a typical reason why recent toolkits treat the "expose"
handler as the primary drawing method.  By freshly redrawing
invalidated area in a rear-to-front way, it can provide some fancy
appearances such as overlapped/translucent widgets in a correct way.

(Another problem with drawing outside the "expose" handler can be
observed with the NS port on Mac OS X 10.6 and earlier: the resize
handle at the right bottom corner gets overwritten.)

>> If you use a window system implementation that uses "backing store"
>> to avoid frequent "expose", then it is difficult to produce the
>> "expose" event intentionally by uncovering the window.

> Which window systems we support don't use "backing store"?

Some implementations of Xservers.  According to the manual, -bs option
seems to turn off the backing store support.

>> You can't tell how "expose" events are used from Application
>> frameworks or toolkits.  Whether you like it or not, contemporary
>> ones (such as GTK+ and Cocoa) treat the "expose" handler as the
>> primary drawing method and use it accordingly, regardless of the
>> internal use from the application code.

> We have no control on how other software is written.  We only have
> control on how Emacs is designed and implemented.

> Look, I'm wearing here the hat of an Emacs maintainer who is
> concerned about the maintainability of the Emacs display code in the
> long run.  Witness the amount of discussions lately that involve
> flags and options for which no one remembers their purpose or
> intended use any longer.  Witness the amount of changes done
> recently on the trunk to rightfully remove ancient crud, which
> sometimes later turns out to be needed, for reasons no one at the
> time cared to document clearly enough.  You are suggesting to add
> one more such flag, don't you see?  Who will remember a few years
> from now why it was needed, which problem on what platform(s) it
> fixed, and how that problem could be reproduced?  I'll tell you: NO
> ONE WILL REMEMBER!!

> So arguments that describe how other software works are of no value
> here, because the size and activity of the maintenance teams of
> these other projects are most probably very different from the
> "team" that maintains the Emacs display code.  IOW, by telling time
> and again how these techniques are used elsewhere, you are wasting
> your time.

I'm just saying that the current "expose" handler has a bug in the
platform-independent part with respect to cursor drawing.

It would be true that the "expose" hander is used to be considered
subsidiary drawing method and used in a limited situation
traditionally, but that is no longer true.

>> What's displayed is assumed to be unchanged until the next
>> redisplay in the first place, even if several "expose" events
>> happen in between.  Otherwise, you can't use several optimizations
>> in redisplay that reuse the existing contents.

> Sorry, you lost me here.  An expose event just triggers another
> redisplay, so what's that "unchanged until the next redisplay"
> about?

No.  Redisplay involves Lisp evaluation, which is prohibited in the
context of read_socket_hook where the "expose" handler is called.

>> As I said above, you'll need a window system implementation that
>> doesn't use "backing store" in order to reproduce the phenomena
>> reliably.

> If there are no such systems except the Mac, then in practice this
> still is a problem specific to that single platform.

Mac does have "backing store".  I meant Xserver implementation without
"backing store".  I vaguely remember Xvnc didn't have one and issued
"expose" events every time a window is uncovered, but I'm not sure
about the recent situation of Xservers.

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 16 Apr 2013 19:15:45 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> (Another problem with drawing outside the "expose" handler can be
> observed with the NS port on Mac OS X 10.6 and earlier: the resize
> handle at the right bottom corner gets overwritten.)

The resize handle can be recovered by invalidating the right bottom
corner at update_end_hook, just as in the case of the rounded bottom
corners in the latest version of the Mac port.  That's another example
where intentional invalidation is useful (arguably in another
platform).

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

Re: Emacs Mac port

[Stefan Monnier]

> That shows a typical reason why recent toolkits treat the "expose"
> handler as the primary drawing method.  By freshly redrawing
> invalidated area in a rear-to-front way, it can provide some fancy
> appearances such as overlapped/translucent widgets in a correct way.

So IIUC, the "new normal" way you describe goes something like:
- redisplay builds glyph matrices from Lisp data and invalidates the
  parts of the display that might need to be redrawn but does not draw.
- expose handlers use the glyph matrices to draw on the screen
  when/where needed.
That makes a lot of sense.


        Stefan

Re: Emacs Mac port

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Tue, 16 Apr 2013 09:20:15 -0400
> 
> > That shows a typical reason why recent toolkits treat the "expose"
> > handler as the primary drawing method.  By freshly redrawing
> > invalidated area in a rear-to-front way, it can provide some fancy
> > appearances such as overlapped/translucent widgets in a correct way.
> 
> So IIUC, the "new normal" way you describe goes something like:
> - redisplay builds glyph matrices from Lisp data and invalidates the
>   parts of the display that might need to be redrawn but does not draw.
> - expose handlers use the glyph matrices to draw on the screen
>   when/where needed.
> That makes a lot of sense.

Maybe I misunderstood, but I don't think the first item is accurate.
(And I don't think you can build glyph matrices, but not draw.)

I think the first step both draws _and_ invalidates, and then the
expose event redraws some small portion of the display.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 16 Apr 2013 09:20:15 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> That shows a typical reason why recent toolkits treat the "expose"
>> handler as the primary drawing method.  By freshly redrawing
>> invalidated area in a rear-to-front way, it can provide some fancy
>> appearances such as overlapped/translucent widgets in a correct way.

> So IIUC, the "new normal" way you describe goes something like:
> - redisplay builds glyph matrices from Lisp data and invalidates the
>   parts of the display that might need to be redrawn but does not draw.
> - expose handlers use the glyph matrices to draw on the screen
>   when/where needed.
> That makes a lot of sense.

Yes.  See also this post:

  http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg00821.html

(copied to the end of this mail.)

Currently, I don't think it is practical to prohibit the actual
drawing in redisplay time completely, at least in a short term, mainly
because of the item 4 in the above post.  But it makes sense to make
expose_frame more efficient (and correct).

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

>>>>> On Thu, 15 Jul 2010 12:00:05 -0400, Chong Yidong <address@hidden> said:

> A more promising route is the one that Yamamoto Mitsuharu has
> explored, mentioned earlier in this thread, which (IIUC) treats
> Cairo as a graphical terminal to render onto, on the same footing as
> the tty/X/Windows/NS terminals.  Here, I can see a reasonable path
> to real improvement.  For example, it might allow us to use the GTK
> printing infrastructure, which operates on Cairo contexts.  If you
> are interested in redisplay development, that is the direction I'd
> suggest looking into.

My proof-of-concept cairo port was primarily intended for the printing
support, not for screen drawing (though it does both).

http://lists.gnu.org/archive/html/emacs-devel/2009-04/msg00390.html

Screen drawing in the cairo port is not so efficient for several
reasons.  To make it more efficient, one would need some modest
modifications to the current drawing model in Emacs.

  1. Don't draw during redisplay, but mark the updated area dirty so
     the upcoming exposure event can trigger the actual redraw for the
     area to be updated.
  2. Restrict the actual drawings to those in response to exposure
     events.  This is the standard way in GTK+ and Cocoa.  That would
     make double-buffering straightforward in GTK+ builds.
  3. Make expose_window etc. more efficient.  For example, the
     foreground of same row might currently be redrawn three times for
     some cases in order to handle overlaps between rows with minimal
     flickering.  This can be eliminated if double-buffering is
     introduced and whole the background is drawn at once and then
     whole the foreground is drawn afterwards.
  4. Scrolling in redisplay (x_shift_glyphs_for_insert and
     x_scroll_run) might require special treatment because copied area
     might be marked dirty at the time of scrolling.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

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

>>>>> On Mon, 15 Apr 2013 18:48:29 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> On Mac, the "expose" handler is called in many situations than you
> might expect including outside the control of application code:
> e.g., creating a snapshot of the window image for icons or "Exposé"
> (http://support.apple.com/kb/HT2503).

Taking a snapshot inside the application itself is also useful.  The
Mac port uses it for animation effects such as fullscreen transition
and buffer switching triggered by touch-sensitive pointing devices,
for example.  It calls the "expose" handler behind the scenes when
creating the snapshot image.

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

[-- Attachment #2: page-curl.png --]
[-- Type: image/png, Size: 100621 bytes --]

Re: Emacs Mac port

[Jan Djärv]

17 apr 2013 kl. 01:52 skrev YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>:
> 
> My proof-of-concept cairo port was primarily intended for the printing
> support, not for screen drawing (though it does both).
> 
> http://lists.gnu.org/archive/html/emacs-devel/2009-04/msg00390.html
> 
> Screen drawing in the cairo port is not so efficient for several
> reasons.  To make it more efficient, one would need some modest
> modifications to the current drawing model in Emacs.
> 
>  1. Don't draw during redisplay, but mark the updated area dirty so
>     the upcoming exposure event can trigger the actual redraw for the
>     area to be updated.
>  2. Restrict the actual drawings to those in response to exposure
>     events.  This is the standard way in GTK+ and Cocoa.  That would
>     make double-buffering straightforward in GTK+ builds.

Double buffering in the Gtk+ is not turned off because of the expose handler, but because Gtk+ can not double buffer text/images not drawn with Gtk/Gdk primitives, and Emacs uses X primitives.  So changing the way expose handler works does absolutely nothing to make Gtk+ double buffering easier.

	Jan D.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 17 Apr 2013 07:08:25 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

> 17 apr 2013 kl. 01:52 skrev YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>:
>> 
>> My proof-of-concept cairo port was primarily intended for the printing
>> support, not for screen drawing (though it does both).
>> 
>> http://lists.gnu.org/archive/html/emacs-devel/2009-04/msg00390.html
>> 
>> Screen drawing in the cairo port is not so efficient for several
>> reasons.  To make it more efficient, one would need some modest
>> modifications to the current drawing model in Emacs.
>> 
>> 1. Don't draw during redisplay, but mark the updated area dirty so
>> the upcoming exposure event can trigger the actual redraw for the
>> area to be updated.
>> 2. Restrict the actual drawings to those in response to exposure
>> events.  This is the standard way in GTK+ and Cocoa.  That would
>> make double-buffering straightforward in GTK+ builds.

> Double buffering in the Gtk+ is not turned off because of the expose
> handler, but because Gtk+ can not double buffer text/images not
> drawn with Gtk/Gdk primitives, and Emacs uses X primitives.  So
> changing the way expose handler works does absolutely nothing to
> make Gtk+ double buffering easier.

That would be correct in itself.  But my description above is in the
context of cairo.  The cairo context passed via the expose handler is
automatically double-buffered.

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

Re: Emacs Mac port

[Jan Djärv]

Hello.

17 apr 2013 kl. 07:46 skrev YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>:

>>>>>> On Wed, 17 Apr 2013 07:08:25 +0200, Jan Djärv <jan.h.d@swipnet.se> said:
> 
>> 17 apr 2013 kl. 01:52 skrev YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>:
>>> 
>>> My proof-of-concept cairo port was primarily intended for the printing
>>> support, not for screen drawing (though it does both).
>>> 
>>> http://lists.gnu.org/archive/html/emacs-devel/2009-04/msg00390.html
>>> 
>>> Screen drawing in the cairo port is not so efficient for several
>>> reasons.  To make it more efficient, one would need some modest
>>> modifications to the current drawing model in Emacs.
>>> 
>>> 1. Don't draw during redisplay, but mark the updated area dirty so
>>> the upcoming exposure event can trigger the actual redraw for the
>>> area to be updated.
>>> 2. Restrict the actual drawings to those in response to exposure
>>> events.  This is the standard way in GTK+ and Cocoa.  That would
>>> make double-buffering straightforward in GTK+ builds.
> 
>> Double buffering in the Gtk+ is not turned off because of the expose
>> handler, but because Gtk+ can not double buffer text/images not
>> drawn with Gtk/Gdk primitives, and Emacs uses X primitives.  So
>> changing the way expose handler works does absolutely nothing to
>> make Gtk+ double buffering easier.
> 
> That would be correct in itself.  But my description above is in the
> context of cairo.  The cairo context passed via the expose handler is
> automatically double-buffered.
> 

This is not just for cairo. Gtk+ double buffers anything drawn with Gtk in the expose handler. For example, menus and toolbar in a Gtk Emacs are double buffered.

If moving things to the expose handler is considered, one must take into account non-Gtk X11 builds. X11 does not have a mechanism for invalidating regions for the purpose of generating an expose event. Gtk+ generates syntetic (internal) expose events.  I guess we could do the same, but it is work to be done by someone(tm).

I also suspect the synchronous nature of Elisp would make this complicated. For example, if Lisp code adds text or image to a buffer, the text or image would be visible to the user at some point in the future, not when the Lisp code is done. Unless some synchronization is added between Lisp code and the expose handler. 

     Jan D. 

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 17 Apr 2013 08:36:25 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

>>> Double buffering in the Gtk+ is not turned off because of the
>>> expose handler, but because Gtk+ can not double buffer text/images
>>> not drawn with Gtk/Gdk primitives, and Emacs uses X primitives.
>>> So changing the way expose handler works does absolutely nothing
>>> to make Gtk+ double buffering easier.
>> 
>> That would be correct in itself.  But my description above is in
>> the context of cairo.  The cairo context passed via the expose
>> handler is automatically double-buffered.

> This is not just for cairo. Gtk+ double buffers anything drawn with
> Gtk in the expose handler. For example, menus and toolbar in a Gtk
> Emacs are double buffered.

According to the document (*), (standard) drawing seems to be
eventually done via cairo on GTK+ 3.

*: https://developer.gnome.org/gtk3/3.0/gtk-migrating-2-to-3.html#id1526151

  In GTK+ 3, the GDK drawing API (which closely mimics the X drawing
  API, which is itself modeled after PostScript) has been removed. All
  drawing in GTK+ 3 is done via cairo.

> If moving things to the expose handler is considered, one must take
> into account non-Gtk X11 builds. X11 does not have a mechanism for
> invalidating regions for the purpose of generating an expose
> event. Gtk+ generates syntetic (internal) expose events.  I guess we
> could do the same, but it is work to be done by someone(tm).

Right.  Probably invalidated region management at the application
level is also meaningful/necessary for Cocoa, because scrolling or
pixel copying in AppKit, which will be used in x_scroll_run, does not
take account of the invalidated region managed by the framework.

> I also suspect the synchronous nature of Elisp would make this
> complicated. For example, if Lisp code adds text or image to a
> buffer, the text or image would be visible to the user at some point
> in the future, not when the Lisp code is done. Unless some
> synchronization is added between Lisp code and the expose handler.

The expose handler will be called when Emacs tries to read some input
from the window system.  If display is not updated for a long time
because of deferring, that means C-g is not handled for a long time
either.  If immediate update after redisplay is really necessary for
some cases, gdk_window_process_all_updates or something could be used
(after making sure that the current matrix is ready and clearing
f->garbaged).

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

Re: Emacs Mac port

[Jan Djärv]

Hello.

19 apr 2013 kl. 05:58 skrev YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>:

> According to the document (*), (standard) drawing seems to be
> eventually done via cairo on GTK+ 3.
> 
> *: https://developer.gnome.org/gtk3/3.0/gtk-migrating-2-to-3.html#id1526151
> 
>  In GTK+ 3, the GDK drawing API (which closely mimics the X drawing
>  API, which is itself modeled after PostScript) has been removed. All
>  drawing in GTK+ 3 is done via cairo.

Correct, but Emacs supports Gtk+ version 2.10 and upwards.

	Jan D.

Re: Emacs Mac port

[Nix]

On 16 Apr 2013, YAMAMOTO Mitsuharu stated:

>>>>>> On Tue, 16 Apr 2013 09:49:17 +0300, Eli Zaretskii <eliz@gnu.org> said:
>>> If you use a window system implementation that uses "backing store"
>>> to avoid frequent "expose", then it is difficult to produce the
>>> "expose" event intentionally by uncovering the window.
>
>> Which window systems we support don't use "backing store"?
>
> Some implementations of Xservers.  According to the manual, -bs option
> seems to turn off the backing store support.

This option does nothing nowadays, because backing store was entirely
removed from the X.org X server implementation before X server 1.5, in
2007. The idea now is that if you want the same effect you have to use a
compositing manager, which naturally provides double-buffering of
everything anyway.

> Mac does have "backing store".  I meant Xserver implementation without
> "backing store".  I vaguely remember Xvnc didn't have one and issued
> "expose" events every time a window is uncovered, but I'm not sure
> about the recent situation of Xservers.

Just use X.org and make sure your compositing manager is turned off :)

-- 
NULL && (void)

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 22 Apr 2013 09:54:33 +0100, Nix <nix@esperi.org.uk> said:

>>> Which window systems we support don't use "backing store"?
>> 
>> Some implementations of Xservers.  According to the manual, -bs
>> option seems to turn off the backing store support.

> This option does nothing nowadays, because backing store was
> entirely removed from the X.org X server implementation before X
> server 1.5, in 2007. The idea now is that if you want the same
> effect you have to use a compositing manager, which naturally
> provides double-buffering of everything anyway.

>> Mac does have "backing store".  I meant Xserver implementation
>> without "backing store".  I vaguely remember Xvnc didn't have one
>> and issued "expose" events every time a window is uncovered, but
>> I'm not sure about the recent situation of Xservers.

> Just use X.org and make sure your compositing manager is turned off
> :)

Thanks for the info.  With these hints, I could reproduce the problem
on CentOS 5.9, where no compositing manager seems to be used by
default and expose events are issued when a window is being uncovered.

1. Execute "emacs -Q -D &" from the terminal window.
2. Evaluate the following expression in the *scratch* buffer:

    (progn
      (sleep-for 5)
      (let ((cursor-in-echo-area t))
	(message "foo")
	(sit-for 0))
      (sleep-for 30))

3. Switch focus to the terminal window and wait 5 seconds for the
   message "foo" followed by the cursor to be displayed in the echo
   area.
4. Move the terminal window so it goes across the echo area.

Then the cursor in the echo area disappears.  If I try the same
experiment on Ubuntu 12.04 LTS, which has a compositing manager, then
the cursor does not disappear.

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The second update of Emacs 24.3 Mac port 4.x is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3-mac-4.2.tar.gz

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

** Fixed bugs

*** Cursor in the echo area is sometimes partially unerased on OS X
10.7 and later, notably on isearch in a large buffer.

** Improvements

*** Add multi-monitor support functions `frame-monitor-attributes' and
`display-monitor-attributes-list' (to appear in Emacs 24.4).

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The third update of Emacs 24.3 Mac port 4.x is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3-mac-4.3.tar.gz

As far as I tested, compilation with "clang -O4", which includes
link-time optimization, seems to work again for x86_64 with the latest
version of clang that can be installed by Xcode 5.0 on OS X 10.8.  You
can optionally try ARC (Automatic Reference Counting) by specifying
CC='clang -fobjc-arc' on configure.

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

** Fixed bugs

*** Invocation via "Login Items" or "Resume" does not respect PATH
setting in ~/.MacOSX/environment.plist on OS X 10.7 and earlier.
Note: OS X 10.8 does not use ~/.MacOSX/environment.plist anyway.

*** Spotlight in Help menu is not installed on Mac OS X 10.5 if
language setting is other than English.

*** Closing a window causes crash if compiled with ARC.
This primarily happens with the latest clang Apple LLVM version 5.0,
but also with earlier versions if the memory leak below is fixed.

*** Memory leaks with ARC on clang Apple LLVM version 4.2 (possibly
compiler bug).

** Improvements

*** Try built-in libxml2 on OS X 10.8 as a fallback.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The fourth update of Emacs 24.3 Mac port 4.x is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3-mac-4.4.tar.gz

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

** Fixed bugs

*** Default directory is set to `/' on OS X 10.9.

*** Some animation effects cause crash on OS X 10.9.

*** SVG images (via WebKit) cannot be loaded on OS X 10.9.

*** Clicking a menu bar in an inactive appearance shows bogus menus on
OS X 10.9.

*** Switching full screen state on multi-monitor environment may cause
exception on OS X 10.9.

*** Focusing on a `fullboth' frame in a non-primary monitor does not
hide the menu bars on OS X 10.9.
Note: the menu bar hidden by a `fullboth' frame in a non-primary
monitor does not appear automatically by moving the mouse to the place
where the menu bar was.  I suspect this is a bug in AppKit.

*** Battery status is not shown correctly on OS X 10.9.
Apply a fix for bug#15694 by Masashi Fujimoto and Glenn Morris.

** Improvements

*** Double clicking an emoji character in the Character Viewer now
complements the Variation Selector 16 if the character is sensitive to
the selector.

*** The image type `image-io' can now additionally rasterize data in
several document formats.  The list of supported formats can be
obtained by `(image-io-types)'.

Re: Emacs Mac port

[Leo Liu]

On 2013-10-24 16:40 +0800, YAMAMOTO Mitsuharu wrote:
> The fourth update of Emacs 24.3 Mac port 4.x is now available from
>
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3-mac-4.4.tar.gz
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp

Everything went well except it no longer linked to libxml2. Any idea how
to make it work again? Without libxml2 shr.el is pretty useless. Thanks
in advance.

Leo

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 24 Oct 2013 17:47:13 +0800, Leo Liu <sdl.web@gmail.com> said:

> Everything went well except it no longer linked to libxml2. Any idea
> how to make it work again? Without libxml2 shr.el is pretty
> useless. Thanks in advance.

I didn't notice that.  Thanks for spotting this.

It seems that the standard include files are no longer in the
/usr/include directory on OS X 10.9.  An immediate workaround would be
to run the configure script as:

  CPPFLAGS=-I"`xcrun --show-sdk-path`"/usr/include/libxml2 ./configure --with-mac

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 24 Oct 2013 19:18:57 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>> Everything went well except it no longer linked to libxml2. Any
>> idea how to make it work again? Without libxml2 shr.el is pretty
>> useless. Thanks in advance.

> I didn't notice that.  Thanks for spotting this.

> It seems that the standard include files are no longer in the
> /usr/include directory on OS X 10.9.  An immediate workaround would
> be to run the configure script as:

>   CPPFLAGS=-I"`xcrun --show-sdk-path`"/usr/include/libxml2 ./configure --with-mac

Below is the patch for configure{.ac,}.

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

=== modified file 'configure.ac'
*** configure.ac	2013-09-21 09:48:19 +0000
--- configure.ac	2013-10-25 00:25:37 +0000
***************
*** 2820,2833 ****
    # Built-in libxml2 on OS X 10.8 lacks libxml-2.0.pc.
    if test "${HAVE_LIBXML2}" != "yes" -a "$opsys" = "darwin"; then
      SAVE_CPPFLAGS="$CPPFLAGS"
!     CPPFLAGS="$CPPFLAGS -I/usr/include/libxml2"
      AC_CHECK_HEADER(libxml/HTMLparser.h,
        [AC_CHECK_DECL(HTML_PARSE_RECOVER, HAVE_LIBXML2=yes, ,
        		     [#include <libxml/HTMLparser.h>])])
      CPPFLAGS="$SAVE_CPPFLAGS"
      if test "${HAVE_LIBXML2}" = "yes"; then
        LIBXML2_LIBS="-lxml2"
!       LIBXML2_CFLAGS="-I/usr/include/libxml2"
      fi
    fi
    if test "${HAVE_LIBXML2}" = "yes"; then
--- 2820,2834 ----
    # Built-in libxml2 on OS X 10.8 lacks libxml-2.0.pc.
    if test "${HAVE_LIBXML2}" != "yes" -a "$opsys" = "darwin"; then
      SAVE_CPPFLAGS="$CPPFLAGS"
!     sdkdir="`xcrun --show-sdk-path 2> /dev/null`"
!     CPPFLAGS="$CPPFLAGS -I${sdkdir}/usr/include/libxml2"
      AC_CHECK_HEADER(libxml/HTMLparser.h,
        [AC_CHECK_DECL(HTML_PARSE_RECOVER, HAVE_LIBXML2=yes, ,
        		     [#include <libxml/HTMLparser.h>])])
      CPPFLAGS="$SAVE_CPPFLAGS"
      if test "${HAVE_LIBXML2}" = "yes"; then
        LIBXML2_LIBS="-lxml2"
!       LIBXML2_CFLAGS="-I${sdkdir}/usr/include/libxml2"
      fi
    fi
    if test "${HAVE_LIBXML2}" = "yes"; then

=== modified file 'configure'
*** configure	2013-09-21 09:48:19 +0000
--- configure	2013-10-25 00:31:48 +0000
***************
*** 13238,13244 ****
    # Built-in libxml2 on OS X 10.8 lacks libxml-2.0.pc.
    if test "${HAVE_LIBXML2}" != "yes" -a "$opsys" = "darwin"; then
      SAVE_CPPFLAGS="$CPPFLAGS"
!     CPPFLAGS="$CPPFLAGS -I/usr/include/libxml2"
      ac_fn_c_check_header_mongrel "$LINENO" "libxml/HTMLparser.h" "ac_cv_header_libxml_HTMLparser_h" "$ac_includes_default"
  if test "x$ac_cv_header_libxml_HTMLparser_h" = xyes; then :
    ac_fn_c_check_decl "$LINENO" "HTML_PARSE_RECOVER" "ac_cv_have_decl_HTML_PARSE_RECOVER" "#include <libxml/HTMLparser.h>
--- 13238,13245 ----
    # Built-in libxml2 on OS X 10.8 lacks libxml-2.0.pc.
    if test "${HAVE_LIBXML2}" != "yes" -a "$opsys" = "darwin"; then
      SAVE_CPPFLAGS="$CPPFLAGS"
!     sdkdir="`xcrun --show-sdk-path 2> /dev/null`"
!     CPPFLAGS="$CPPFLAGS -I${sdkdir}/usr/include/libxml2"
      ac_fn_c_check_header_mongrel "$LINENO" "libxml/HTMLparser.h" "ac_cv_header_libxml_HTMLparser_h" "$ac_includes_default"
  if test "x$ac_cv_header_libxml_HTMLparser_h" = xyes; then :
    ac_fn_c_check_decl "$LINENO" "HTML_PARSE_RECOVER" "ac_cv_have_decl_HTML_PARSE_RECOVER" "#include <libxml/HTMLparser.h>
***************
*** 13253,13259 ****
      CPPFLAGS="$SAVE_CPPFLAGS"
      if test "${HAVE_LIBXML2}" = "yes"; then
        LIBXML2_LIBS="-lxml2"
!       LIBXML2_CFLAGS="-I/usr/include/libxml2"
      fi
    fi
    if test "${HAVE_LIBXML2}" = "yes"; then
--- 13254,13260 ----
      CPPFLAGS="$SAVE_CPPFLAGS"
      if test "${HAVE_LIBXML2}" = "yes"; then
        LIBXML2_LIBS="-lxml2"
!       LIBXML2_CFLAGS="-I${sdkdir}/usr/include/libxml2"
      fi
    fi
    if test "${HAVE_LIBXML2}" = "yes"; then

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 24 Oct 2013 19:18:57 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>> Everything went well except it no longer linked to libxml2. Any
>> idea how to make it work again? Without libxml2 shr.el is pretty
>> useless. Thanks in advance.

> I didn't notice that.  Thanks for spotting this.

> It seems that the standard include files are no longer in the
> /usr/include directory on OS X 10.9.  An immediate workaround would
> be to run the configure script as:

>   CPPFLAGS=-I"`xcrun --show-sdk-path`"/usr/include/libxml2 ./configure --with-mac

Another way is to install the Command Line Developer Tools by

  $ xcode-select --install

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 24 Oct 2013 17:40:09 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> The fourth update of Emacs 24.3 Mac port 4.x is now available from

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

> *** The image type `image-io' can now additionally rasterize data in
> several document formats.  The list of supported formats can be
> obtained by `(image-io-types)'.

The supported document formats include RTF, HTML, WEBARCHIVE, DOC (and
SXW, ODT, DOCX on newer versions of OS X), etc., but not for PDF.
Actually, PDF support could be added easily and the patch is available
from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3-mac-4.4-pdf.patch.gz

Images for these document formats are automatically re-rasterized when
you move a frame between Retina and non-Retina monitors.

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The fifth update of Emacs 24.3 Mac port 4.x is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3-mac-4.5.tar.gz

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

** Fixed bugs

*** Resizing a frame from its top or left edge flaps on OS X 10.9.

*** Animation effects become invisible after exiting from full screen
on OS X 10.9.

*** Memory leaks by multiple installations of memory pressure/status
dispatch sources on OS X 10.9, caused by repeated start/stop of the
main event loop.
I think this is a bug in AppKit.  A workaround is added.

*** (insert-image (create-image "" 'image-io t)) causes crash.

*** Info directory in the application bundle is not respected.
Reported by Dave Abrahams.

** Improvements

*** Suppress confusing "Tags:" field in the "New File" dialog on OS X
10.9.

*** The image type `image-io' can now additionally rasterize data in
PDF format.

*** Document rasterization (including PDF) in the image type
`image-io' now caches the loaded documents for a while so as to avoid
loading a multi-page document several times when successively
rasterizing multiple pages of the document.

*** Respect the "Swipe between pages" setting for touch-sensitive
mice/trackpads.

*** Fonts used in the "CJK variety" line in the etc/HELLO file are
selected consistently regardless of the system language setting.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The sixth update of Emacs 24.3 Mac port 4.x is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3-mac-4.6.tar.gz

This time there are not so many changes from the previous version.  If
you still have a build tree for the previous one, then you only need
to update macappkit.m, macfns.c, and macfont.c in the src directory.

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

** Fixed bugs

*** 64-bit binary does not run if compiled on Mac OS X 10.5.

*** Typing Command-H while a tooltip is shown makes it unerasable.
Reported by Peter Dyballa.

*** Crash when a tooltip is shown in a non-primary monitor with
explicit geometry specified.
Reported by Robert Dallas Gray.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The seventh update of Emacs 24.3 Mac port 4.x is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3-mac-4.7.tar.gz

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

** Fixed bugs

*** Crash if a fullscreen frame is closed by C-x 5 0.
This is a regression introduced in 4.5 as the fix for invisible
animation effects on OS X 10.9.

*** M-x menu-bar-open RET always activates the menu bar in the primary
monitor on OS X 10.9 where a non-primary monitor can also have a menu
bar.

*** Command-Shift-/ does not activate the help menu for a fullscreen
frame on OS X 10.8 and later.

** Improvements

*** Moving focus to the menu bar by Control-F2 behaves much like other
applications.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The eighth update of Emacs 24.3 Mac port 4.x is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3-mac-4.8.tar.gz

This time there are not so many changes from the previous version.  If
you still have a build tree for the previous one, then you only need
to update src/macappkit.m, src/macterm.c, and optionally
mac/templates/Info.plist.in .

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

** Fixed bugs

*** Fringe does not get correctly updated under very specific
circumstances (Bug#16932).

*** In full screen mode, clicking the menu bar hides it on OS X 10.7.

*** Image background is not correctly drawn when it has a box
(Bug#17115).

*** While resizing a frame with mouse dragging, display is updated
only on pauses in motion.

Re: Emacs Mac port

[David Reitter]

Mitsuharu,

Do you keep a git repository for your port somewhere out there?



On Mar 31, 2014, at 9:10 PM, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:

> The eighth update of Emacs 24.3 Mac port 4.x is now available from
> 
>    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3-mac-4.8.tar.gz
> 
> This time there are not so many changes from the previous version.  If
> you still have a build tree for the previous one, then you only need
> to update src/macappkit.m, src/macterm.c, and optionally
> mac/templates/Info.plist.in .
> 
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
> 
> ** Fixed bugs
> 
> *** Fringe does not get correctly updated under very specific
> circumstances (Bug#16932).
> 
> *** In full screen mode, clicking the menu bar hides it on OS X 10.7.
> 
> *** Image background is not correctly drawn when it has a box
> (Bug#17115).
> 
> *** While resizing a frame with mouse dragging, display is updated
> only on pauses in motion.
> 

Re: Emacs Mac port

[Leo Liu]

On 2014-04-03 23:12 +0800, David Reitter wrote:
> Mitsuharu,
>
> Do you keep a git repository for your port somewhere out there?

I am also very interested in having access to the git repository if
available. It is absolutely a pleasure to use macport on OSX except
cannot use emacs trunk.

Leo

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 3 Apr 2014 11:12:23 -0400, David Reitter <david.reitter@gmail.com> said:

> Mitsuharu,
> Do you keep a git repository for your port somewhere out there?

I'm not maintaining any (private or public) git repositories for the
Mac port myself.  Actually I don't have enough experience with git
yet.  Probably I'll start practicing it after the upstream repository
has switched to git.

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

Re: Emacs Mac port

[Chris Van Dusen]

On Apr 3, 2014, at 12:30 PM, Leo Liu <sdl.web@gmail.com> wrote:

> On 2014-04-03 23:12 +0800, David Reitter wrote:
>> Mitsuharu,
>> 
>> Do you keep a git repository for your port somewhere out there?
> 
> I am also very interested in having access to the git repository if
> available. It is absolutely a pleasure to use macport on OSX except
> cannot use emacs trunk.
> 
> Leo
> 

I’ve been using the following for over a year, and have been pleased:

https://github.com/railwaycat/emacs-mac-port

Chris.

Re: Emacs Mac port

[Xu Xin]

On Thu, Apr 3, 2014 at 8:44 PM, Chris Van Dusen <cavandusen@gmail.com> wrote:
> On Apr 3, 2014, at 12:30 PM, Leo Liu <sdl.web@gmail.com> wrote:
>
>> On 2014-04-03 23:12 +0800, David Reitter wrote:
>>> Mitsuharu,
>>>
>>> Do you keep a git repository for your port somewhere out there?
>>
>> I am also very interested in having access to the git repository if
>> available. It is absolutely a pleasure to use macport on OSX except
>> cannot use emacs trunk.
>>
>> Leo
>>
>
> I’ve been using the following for over a year, and have been pleased:
>
> https://github.com/railwaycat/emacs-mac-port
>
> Chris.

Sorry Chris, this is not the developing git repo. This is a repo based on
every patches from here and to make the Homebrew script simpler.

- Xin

Re: Emacs Mac port

[Chris Van Dusen]

On Apr 3, 2014, at 8:24 PM, Xu Xin <railwaycat@gmail.com> wrote:
> 
> Sorry Chris, this is not the developing git repo. This is a repo based on
> every patches from here and to make the Homebrew script simpler.
> 
> - Xin

Ah, yes. I had forgotten.

Sorry for the confusion,
Chris.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 24.3.90 pretest is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3.90-mac-4.90.tar.gz
  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-hires-icons-1.0.tar.gz

This version (4.9X) should be regarded as experimental/hackers-only.
Things are subject to change/removal in an incompatible way.  Please
refrain from distributing this in any different form, including for
(binary) distribution basis, until the version gets to 5.0.

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

* emacs-24.3.90-mac-4.90 [experimental/hackers-only] (2014-04-14)
Based on Emacs 24.3.90.
High-resolution icons are now distributed as a separate package.
File notification is supported via GLib (you'll also need `pkg-config'
when running the configure command).
The `image-io' image type supports `:max-width', `:max-height', and
`:format' keywords just as in `imagemagick'.
Now that Image mode supports multi-frame image navigation (`f', 'b',
and `F'), you can browse multi-page documents in several formats that
`image-io' supports (e.g., PDF and DOC) with the setting like this:
  (when (and (image-type-available-p 'image-io)
	     (not (boundp 'imagemagick-render-type)))
     ;; Image I/O is used as a fallback of ImageMagick.
     (setq imagemagick-enabled-types t)
     (setq imagemagick-types-inhibit
	  (cons 'XML (delq 'PDF imagemagick-types-inhibit)))
     (imagemagick-register-types))
Note: if you have ImageMagick installed, you need to build the Mac
port executable without the genuine ImageMagick support so `image-io'
can be used as a fallback of `imagemagick'.

** Improvements

*** Graphical drawing operations might be performed in non-main
threads via GCD (Grand Central Dispatch) on Mac OS X 10.6 and later.
You can turn this off by setting `mac-drawing-use-gcd' to nil.

*** DocView mode generates pixel-doubled "@2x" bitmap image files in
addition to normal ones on high-resolution environments such as Retina
display or HiDPI mode.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 14 Apr 2014 12:00:01 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> The Mac port based on Emacs 24.3.90 pretest is now available from
>   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3.90-mac-4.90.tar.gz
>   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-hires-icons-1.0.tar.gz

Please apply the following patch, too.  This fixes wrong return value
of display-monitor-attributes-list (reported by Leo Liu).  Sorry for
the inconvenience.

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3.90-mac-4.90-monitor-attributes.patch.gz

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 24.3.91 pretest is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3.91-mac-4.91.tar.gz

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

*** Wrong return value of display-monitor-attributes-list.
Reported by Leo.

*** If you point to the left "%", which has both left and right
overhangs for Monaco 12pt, of "%%" in the mode line, then the right
one is also drawn with upper and lower box.

** Improvements

*** New variables mac-right-control-modifier,
mac-right-command-modifier, and mac-right-option-modifier.
Note: the left and right versions cannot be distinguished on some
environments such as Screen Sharing.  Also, certain combinations of a
key with both versions of the same modifier do not emit events at the
system level.

*** A single physical modifier key can be mapped to different Emacs
modifiers depending on its input type (ordinary keys, function keys,
or mouse operations) using the property list format `(:ordinary SYMBOL
:function SYMBOL :mouse SYMBOL)'.  By default, the option key works as
the normal Mac option key for the ordinary keys, and as the Alt
modifier for the function keys and the mouse operations.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 24.3.92 pretest is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3.92-mac-4.92.tar.gz

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

Carbon version in mac-carbon-version-string now uses the bundle
version rather than what's obtained by Gestalt.

** Fixed bugs

*** Left scroll bar was not included in the window animation area.

** Improvements
o
*** New full screen transition animation.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 24.3.93 pretest is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3.93-mac-4.93.tar.gz

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

Remove mac-ts-script-language-on-focus, which hasn't had any effect
on 64-bit executables.

** Fixed bugs

*** Several glitches in pixel-based smooth scrolling.

*** Crash when closing a fullscreen frame on OS X 10.10 Beta.

*** Full screen transition animation is broken on OS X 10.10 Beta.

*** Title bar buttons are misplaced if we toggle the tool bar on
a fullscreen frame on OS X 10.10 Beta.
I think this is a bug in AppKit.  A workaround is added.

** Improvements

*** Blend and blur fringe background of the focused frame with the
contents behind it on OS X 10.10 Beta.
This is currently experimental, hard-coded, and subject to change.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 24.3.94 pretest is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3.94-mac-4.94.tar.gz

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

** Fixed bugs

*** Right fringe on the row containing a hollow cursor at the tab
character in a non-selected window sometimes gets erased on wheel
scrolling.

*** M-x toggle-frame-fullscreen RET -> M-x tool-bar-mode RET -> M-x
toggle-frame-fullscreen RET does not preserve tool bar visibility on
OS X 10.7 - 10.9.

** Improvements

*** Add mouse pointer color support.

*** Animation-related properties of animated GIF are added to metadata
of images in the `image-io' image type.  Likewise for animated PNG on
OS X 10.10.

Re: Emacs Mac port

[Angelo Graziosi]

YAMAMOTO Mitsuharu wrote:
> The Mac port based on Emacs 24.3.94 pretest is now available from

It is the first time I build Emacs Mac port (I build OB the nextstep 
version following nextstep/INSTALL) but, maybe, I am missing something..

I have tried to follow the README-mac..

Downloaded the tarballs:

wget ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.3.94.tar.xz 
ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3.94-mac-4.94.tar.gz

Unpacked:

tar -xf emacs-24.3.94.tar.xz
tar -xf emacs-24.3.94-mac-4.94.tar.gz

as suggested in 'a.' of README-mac

Then, README-mac says:

  b. Apply the patch `patch-mac' to the source tree.


and I did this:

cd emacs-24.3.94

patch < ../emacs-24.3.94-mac-4.94/patch-mac
patching file Makefile.in
patching file configure.ac
patching file Makefile.in
Hunk #1 FAILED at 135.
Hunk #2 FAILED at 165.
2 out of 2 hunks FAILED -- saving rejects to file Makefile.in.rej
can't find file to patch at input line 425
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|
|=== modified file 'doc/emacs/emacs.texi'
|*** doc/emacs/emacs.texi       2014-07-21 03:31:36 +0000
|--- doc/emacs/emacs.texi       2014-08-15 04:42:44 +0000
--------------------------
File to patch:


It seems something is wrong or I haven't understood something...


Ciao,
  Angelo.

Re: Emacs Mac port

[Xin Xu]

Hi Angelo,

Try:

patch -p0 < ../emacs-24.3.94-mac-4.94/patch-mac

Thanks,
- Xin

> On Oct 3, 2014, at 10:27, Angelo Graziosi <angelo.graziosi@alice.it> wrote:
> 
> YAMAMOTO Mitsuharu wrote:
>> The Mac port based on Emacs 24.3.94 pretest is now available from
> 
> It is the first time I build Emacs Mac port (I build OB the nextstep version following nextstep/INSTALL) but, maybe, I am missing something..
> 
> I have tried to follow the README-mac..
> 
> Downloaded the tarballs:
> 
> wget ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.3.94.tar.xz ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3.94-mac-4.94.tar.gz
> 
> Unpacked:
> 
> tar -xf emacs-24.3.94.tar.xz
> tar -xf emacs-24.3.94-mac-4.94.tar.gz
> 
> as suggested in 'a.' of README-mac
> 
> Then, README-mac says:
> 
> b. Apply the patch `patch-mac' to the source tree.
> 
> 
> and I did this:
> 
> cd emacs-24.3.94
> 
> patch < ../emacs-24.3.94-mac-4.94/patch-mac
> patching file Makefile.in
> patching file configure.ac
> patching file Makefile.in
> Hunk #1 FAILED at 135.
> Hunk #2 FAILED at 165.
> 2 out of 2 hunks FAILED -- saving rejects to file Makefile.in.rej
> can't find file to patch at input line 425
> Perhaps you should have used the -p or --strip option?
> The text leading up to this was:
> --------------------------
> |
> |=== modified file 'doc/emacs/emacs.texi'
> |*** doc/emacs/emacs.texi       2014-07-21 03:31:36 +0000
> |--- doc/emacs/emacs.texi       2014-08-15 04:42:44 +0000
> --------------------------
> File to patch:
> 
> 
> It seems something is wrong or I haven't understood something...
> 
> 
> Ciao,
> Angelo.
> 
> 

Re: Emacs Mac port

[Angelo Graziosi]

Il 03/10/2014 23:25, Xin Xu ha scritto:
> Hi Angelo,
>
> Try:
>
> patch -p0 < ../emacs-24.3.94-mac-4.94/patch-mac

Argh... obviously!

OK, now I have build the Emacs Mac port pretest.. And if I want to build 
trunk?

Thanks,
  Angelo.

Re: Emacs Mac port

[Angelo Graziosi]

Il 04/10/2014 01:20, Angelo Graziosi ha scritto:
>
> OK, now I have build the Emacs Mac port pretest..

Comparing to nextstep (NS) build, I notice the following.

1. The M- key seems be realized by COMMAND-key. For example, to execute the

   M-x delete-trailing-whitespace

on NS (as on other systems), I type

   Alt_Option-x delete-trailing-whitespace

instead on Emacs Mac Port (EMP) I have to type

   COMMAND-x delete-trailing-whitespace


2. To copy/paste on NS one uses

   COMMAND-C  (copy)
   COMMAND-V  (paste)

but on EMP,

   COMMAND-W
   C-Y  (C  for CTRL)

which looks a little asymmetric.

3. The tool-bar icons have their name...


Is the above to be expected in EMP?


Ciao,
   Angelo.

Re: Emacs Mac port

[Kazu Yamamoto]

Yamamoto-san,

> The Mac port based on Emacs 24.3.94 pretest is now available from
> 
>  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3.94-mac-4.94.tar.gz

Thank you for emacs-24.3.94-mac-4.94! This makes Emacs much stabler on
Mavericks. Pure Emacs often gets segfaults but I have not experienced
a segfault with emacs-24.3.94-mac in normal usage.

However, I noticed two bugs so far. I would like to report one of them
here. I'm using two Mavericks. emacs-24.3.94-mac-4.94 gets a segfault
if it is operated through Mac's *screen share*.

I can reproduce this bug 100%. And I confirmed that this bug does not
exist in pure emacs-24.3.94.

--Kazu

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 06 Oct 2014 13:21:10 +0900 (JST), Kazu Yamamoto (山本和彦) <kazu@iij.ad.jp> said:

> However, I noticed two bugs so far. I would like to report one of
> them here. I'm using two Mavericks. emacs-24.3.94-mac-4.94 gets a
> segfault if it is operated through Mac's *screen share*.

> I can reproduce this bug 100%. And I confirmed that this bug does
> not exist in pure emacs-24.3.94.

I could reproduce the bug, and it is a regression introduced in
emacs-24.3.91-mac-4.91 .  Please try the patch below.

Thanks for reporting this.  Next time, please report Mac port specific
bugs to mituharu+bug-gnu-emacs-mac@math.s.chiba-u.ac.jp as guided with
M-x report-emacs-bug RET.

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

=== modified file 'src/macappkit.h'
*** src/macappkit.h	2014-10-02 03:58:26 +0000
--- src/macappkit.h	2014-10-06 08:14:09 +0000
***************
*** 975,980 ****
--- 975,981 ----
  #if MAC_OS_X_VERSION_MAX_ALLOWED < 1050
  @interface NSEvent (AvailableOn1050AndLater)
  - (CGEventRef)CGEvent;
+ - (const void * /* EventRef */)eventRef;
  @end
  #endif
  

=== modified file 'src/macappkit.m'
*** src/macappkit.m	2014-10-02 03:58:26 +0000
--- src/macappkit.m	2014-10-06 08:14:09 +0000
***************
*** 318,323 ****
--- 318,342 ----
  		  pressure:[self pressure]];
  }
  
+ static void
+ mac_cgevent_set_unicode_string_from_event_ref (CGEventRef cgevent,
+ 					       EventRef eventRef)
+ {
+   ByteCount size;
+ 
+   if (GetEventParameter (eventRef, kEventParamKeyUnicodes,
+ 			 typeUnicodeText, NULL, 0, &size, NULL) == noErr)
+     {
+       UniChar *text = alloca (size);
+ 
+       if (GetEventParameter (eventRef, kEventParamKeyUnicodes,
+ 			     typeUnicodeText, NULL, size, NULL,
+ 			     text) == noErr)
+ 	CGEventKeyboardSetUnicodeString (cgevent, size / sizeof (UniChar),
+ 					 text);
+     }
+ }
+ 
  - (CGEventRef)coreGraphicsEvent
  {
    CGEventRef event;
***************
*** 328,334 ****
      {
        event = [self CGEvent];
        if (event)
! 	return event;
      }
  
    /* Workaround for a bug on Mac OS X 10.4.  */
--- 347,370 ----
      {
        event = [self CGEvent];
        if (event)
! 	{
! 	  /* Unicode string is not set if the keyboard event comes
! 	     from Screen Sharing on Mac OS X 10.6 and later.  */
! 	  if (NSEventMaskFromType ([self type]) & (NSKeyDownMask | NSKeyUpMask))
! 	    {
! 	      UniCharCount length;
! 
! 	      CGEventKeyboardGetUnicodeString (event, 0, &length, NULL);
! 	      if (length == 0)
! 		{
! 		  EventRef eventRef = (EventRef) [self eventRef];
! 
! 		  mac_cgevent_set_unicode_string_from_event_ref (event,
! 								 eventRef);
! 		}
! 	    }
! 	  return event;
! 	}
      }
  
    /* Workaround for a bug on Mac OS X 10.4.  */
***************
*** 369,389 ****
  #if __LP64__
        /* This seems to be unnecessary for 32-bit executables.  */
        {
- 	ByteCount size;
  	UInt32 keyboard_type;
  	EventRef eventRef = (EventRef) [self eventRef];
  
! 	if (GetEventParameter (eventRef, kEventParamKeyUnicodes,
! 			       typeUnicodeText, NULL, 0, &size, NULL) == noErr)
! 	  {
! 	    UniChar *text = alloca (size);
! 
! 	    if (GetEventParameter (eventRef, kEventParamKeyUnicodes,
! 				   typeUnicodeText, NULL, size, NULL,
! 				   text) == noErr)
! 	      CGEventKeyboardSetUnicodeString (event, size / sizeof (UniChar),
! 					       text);
! 	  }
  	if (GetEventParameter (eventRef, kEventParamKeyboardType,
  			       typeUInt32, NULL, sizeof (UInt32), NULL,
  			       &keyboard_type) == noErr)
--- 405,414 ----
  #if __LP64__
        /* This seems to be unnecessary for 32-bit executables.  */
        {
  	UInt32 keyboard_type;
  	EventRef eventRef = (EventRef) [self eventRef];
  
! 	mac_cgevent_set_unicode_string_from_event_ref (event, eventRef);
  	if (GetEventParameter (eventRef, kEventParamKeyboardType,
  			       typeUInt32, NULL, sizeof (UInt32), NULL,
  			       &keyboard_type) == noErr)

Re: Emacs Mac port

[Kazu Yamamoto]

Hi Yamamoto-san,

> I could reproduce the bug, and it is a regression introduced in
> emacs-24.3.91-mac-4.91 .  Please try the patch below.

Fixed with this patch. Great. Thanks.

> Thanks for reporting this.  Next time, please report Mac port specific
> bugs to mituharu+bug-gnu-emacs-mac@math.s.chiba-u.ac.jp as guided with
> M-x report-emacs-bug RET.

OK. I will send another bug report according to the procedure above.

--Kazu

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 02 Oct 2014 12:54:42 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> The Mac port based on Emacs 24.3.94 pretest is now available from
>   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.3.94-mac-4.94.tar.gz

I'll skip the Mac port release for Emacs 24.4 release candidate 1,
because our site becomes unreachable this weekend.  Fortunately, the
previous version above seems to be applicable to the rc1 tarball.  If
you are using Screen Sharing.app, then also apply the patch in
http://lists.gnu.org/archive/html/emacs-devel/2014-10/msg00110.html .

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 24.4 is now available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.4-mac-5.0.tar.gz

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

** Fixed bugs

*** Keyboard input via Screen Sharing causes crash.
Reported by Kazu Yamamoto.

** Changes from emacs-24.3-mac-4.8

*** High-resolution icons are now distributed as a separate
package, which is available from
ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-hires-icons-1.0.tar.gz

*** File notification is supported via GLib (you'll also need
`pkg-config' when running the configure command).

*** The `image-io' image type supports `:max-width',
`:max-height', and `:format' keywords just as in `imagemagick'.

*** Now that Image mode supports multi-frame image
navigation (`f', 'b', and `F'), you can browse multi-page
documents in several formats that `image-io' supports (e.g., PDF
and DOC) with the setting like this:
  (when (and (image-type-available-p 'image-io)
	     (not (boundp 'imagemagick-render-type)))
     ;; Image I/O is used as a fallback of ImageMagick.
     (setq imagemagick-enabled-types t)
     (setq imagemagick-types-inhibit
	  (cons 'XML (delq 'PDF imagemagick-types-inhibit)))
     (imagemagick-register-types))
Note: if you have ImageMagick installed, you need to build the Mac
port executable without the genuine ImageMagick support so `image-io'
can be used as a fallback of `imagemagick'.

*** New variables mac-right-control-modifier,
mac-right-command-modifier, and mac-right-option-modifier.
Note: the left and right versions cannot be distinguished on some
environments such as Screen Sharing.  Also, certain combinations of a
key with both versions of the same modifier do not emit events at the
system level.

*** A single physical modifier key can be mapped to different Emacs
modifiers depending on its input type (ordinary keys, function keys,
or mouse operations) using the property list format `(:ordinary SYMBOL
:function SYMBOL :mouse SYMBOL)'.  By default, the option key works as
the normal Mac option key for the ordinary keys, and as the Alt
modifier for the function keys and the mouse operations.

*** Remove mac-ts-script-language-on-focus, which hasn't had any
effect on 64-bit executables.

*** Blend and blur fringe background of the focused frame with the
contents behind it on OS X 10.10.
This is currently experimental, hard-coded, and subject to change.

*** Add mouse pointer color support.

*** Animation-related properties of animated GIF are added to metadata
of images in the `image-io' image type.  Likewise for animated PNG on
OS X 10.10.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 21 Oct 2014 13:44:44 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> The Mac port based on Emacs 24.4 is now available from
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.4-mac-5.0.tar.gz

> ** Changes from emacs-24.3-mac-4.8

I forgot to add two items:

*** Graphical drawing operations might be performed in non-main
threads via GCD (Grand Central Dispatch) on Mac OS X 10.6 and later.
You can turn this off by setting `mac-drawing-use-gcd' to nil.

*** DocView mode generates pixel-doubled "@2x" bitmap image files in
addition to normal ones on high-resolution environments such as Retina
display or HiDPI mode.


Also, the previous version (emacs-24.3.94-mac-4.94.tar.gz) seems to be
missing in the server during the last week.  The contents were
inadvertently rolled back on server update.  Sorry for inconvenience.

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The first update of Emacs 24.4 Mac port 5.x is available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.4-mac-5.1.tar.gz

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

** Fixed bugs

*** "C-_" on JIS keyboard is recognized as "_".
Reported by OHKAWA Yuichi.

*** Checking "Reduce translucency" in the Accessibility pane in the
System Preferences on OS X 10.10 makes fringe areas translucent.
Reported by Nicholas Riley.

** Improvements

*** Blend-and-blur of fringe background on OS X 10.10 is no longer
hard-coded.  It can be customized per face by specifying a special
name `alpha:ALPHA' as a value of the background stipple attribute.
For example,
  (set-face-stipple 'fringe "alpha:50%")
or
  defaults write org.gnu.Emacs Emacs.fringe.attributeStipple alpha:.5
will (mostly) recover the appearance of the previous release.
Note: Setting stipple for the default face may not work as you expect.
This is the same limitation as the standard stipple feature on X11.
Also, blend-and-blur is temporarily turned off during animations.

*** New experimental functions `mac-osa-language-list' and
`mac-osa-script'.  The latter is like `do-applescript', but can
execute JavaScript as well as AppleScript on OS X 10.10.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 03 Nov 2014 16:08:01 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> The first update of Emacs 24.4 Mac port 5.x is available from
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.4-mac-5.1.tar.gz

> *** New experimental functions `mac-osa-language-list' and
> `mac-osa-script'.  The latter is like `do-applescript', but can
> execute JavaScript as well as AppleScript on OS X 10.10.

I found a ridiculous mistake in the processing of handler args in
`mac-osa-script'.  It is not serious for normal use, but if you want
to play with this new function, please apply the patch below.

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

=== modified file 'src/macappkit.m'
*** src/macappkit.m	2014-11-03 07:13:33 +0000
--- src/macappkit.m	2014-11-03 12:34:50 +0000
***************
*** 10998,11004 ****
  	  NSString *handlerName;
  
  	  for (i = 0; i < nargs; i++)
! 	    mac_ae_put_lisp (&param_list, i, args[i]);
  
  	  target = [NSAppleEventDescriptor nullDescriptor];
  	  result = [NSAppleEventDescriptor
--- 10998,11004 ----
  	  NSString *handlerName;
  
  	  for (i = 0; i < nargs; i++)
! 	    mac_ae_put_lisp (&param_list, 0, args[i]);
  
  	  target = [NSAppleEventDescriptor nullDescriptor];
  	  result = [NSAppleEventDescriptor

Re: Emacs Mac port

[Leo Liu]

On 2014-11-03 21:56 +0900, YAMAMOTO Mitsuharu wrote:
> I found a ridiculous mistake in the processing of handler args in
> `mac-osa-script'.  It is not serious for normal use, but if you want
> to play with this new function, please apply the patch below.

Could you update the instruction to include how to build with libxml2?
Thanks.

Leo

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The second update of Emacs 24.4 Mac port 5.x is available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.4-mac-5.2.tar.gz

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

*** The function `mac-osa-script' does not process ARGS (6th and later
arguments) correctly.

** Improvements

*** Even if the current keyboard layout maps some key with the control
modifier to insertion of a character, which would be recognized as an
ordinary insertion in applications that use the standard Cocoa text
view, it is interpreted as a combination with the control modifier.
This behavior is consistent with the Mac port version 4.x and earlier,
and also obviates the previous fix for "C-_" on JIS keyboard.

*** If /usr/include does not exist, then the Xcode SDK dir is examined
as a candidate of libxml2 header location if it does not contain any
special characters or blanks.

*** The function `mac-osa-script' now accepts compiled code, which can
be generated by a new function `mac-osa-compile', and a file name as
well as a script source.
Note: As of OS X 10.10.1, specifying compiled code generated from a
JavaScript source causes crash.  I think this is a bug in OSAKit.

*** New function `mac-do-applescript', which is implemented on top of
`mac-osa-script' and intended as a future replacement of
`do-applescript'.

*** New functions and hooks for interaction with the Text Input Source
Services on Mac OS X 10.5 and later: `mac-input-source',
`mac-input-source-list', `mac-select-input-source',
`mac-deselect-input-source',
`mac-selected-keyboard-input-source-change-hook', and
`mac-enabled-keyboard-input-sources-change-hook'.

*** New global minor mode `mac-auto-ascii-mode' for Mac OS X 10.5 and
later.  If enabled, it automatically selects the most-recently-used
ASCII-capable keyboard input source on some occasions: after prefix
key (bound in the global keymap) press such as C-x and M-g, and at the
start of minibuffer input.
Note: Strictly speaking, its implementation has a timing issue: the
Lisp event queue may already have some input events that have been
processed by some previous keyboard input source but yet to be
processed by the Lisp interpreter.

Re: Emacs Mac port

[Kazu Yamamoto]

Yamamoto-san,

Thank you for your efforts always. I remember that you said you will
prepare your git repo for Mac port when Emacs switches its repo to
git. Now Emacs have done it. It would be highly appreciated if you
open your repo of Mac port.

--Kazu

> The second update of Emacs 24.4 Mac port 5.x is available from
> 
>     ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.4-mac-5.2.tar.gz
> 
> 			     YAMAMOTO Mitsuharu
> 			mituharu@math.s.chiba-u.ac.jp
> ** Fixed bugs
> 
> *** The function `mac-osa-script' does not process ARGS (6th and later
> arguments) correctly.
> 
> ** Improvements
> 
> *** Even if the current keyboard layout maps some key with the control
> modifier to insertion of a character, which would be recognized as an
> ordinary insertion in applications that use the standard Cocoa text
> view, it is interpreted as a combination with the control modifier.
> This behavior is consistent with the Mac port version 4.x and earlier,
> and also obviates the previous fix for "C-_" on JIS keyboard.
> 
> *** If /usr/include does not exist, then the Xcode SDK dir is examined
> as a candidate of libxml2 header location if it does not contain any
> special characters or blanks.
> 
> *** The function `mac-osa-script' now accepts compiled code, which can
> be generated by a new function `mac-osa-compile', and a file name as
> well as a script source.
> Note: As of OS X 10.10.1, specifying compiled code generated from a
> JavaScript source causes crash.  I think this is a bug in OSAKit.
> 
> *** New function `mac-do-applescript', which is implemented on top of
> `mac-osa-script' and intended as a future replacement of
> `do-applescript'.
> 
> *** New functions and hooks for interaction with the Text Input Source
> Services on Mac OS X 10.5 and later: `mac-input-source',
> `mac-input-source-list', `mac-select-input-source',
> `mac-deselect-input-source',
> `mac-selected-keyboard-input-source-change-hook', and
> `mac-enabled-keyboard-input-sources-change-hook'.
> 
> *** New global minor mode `mac-auto-ascii-mode' for Mac OS X 10.5 and
> later.  If enabled, it automatically selects the most-recently-used
> ASCII-capable keyboard input source on some occasions: after prefix
> key (bound in the global keymap) press such as C-x and M-g, and at the
> start of minibuffer input.
> Note: Strictly speaking, its implementation has a timing issue: the
> Lisp event queue may already have some input events that have been
> processed by some previous keyboard input source but yet to be
> processed by the Lisp interpreter.
> 

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 27 Nov 2014 10:43:39 +0900 (JST), Kazu Yamamoto (山本和彦) <kazu@iij.ad.jp> said:

> Yamamoto-san, Thank you for your efforts always. I remember that you
> said you will prepare your git repo for Mac port when Emacs switches
> its repo to git. Now Emacs have done it. It would be highly
> appreciated if you open your repo of Mac port.

Actually, I didn't say anything about making my repository public,
because my git experiences were far from that level:

  I'm not maintaining any (private or public) git repositories for the
  Mac port myself.  Actually I don't have enough experience with git
  yet.  Probably I'll start practicing it after the upstream
  repository has switched to git.

The situation is still almost the same: I don't have any git
repositories for the Mac port.  I don't have to be in a hurry for the
development of the Mac port because the current version is based on
Emacs 24.4, which is also in the old bzr repository.  The transition
will be made around the pretest of 24.5 or 25.1.  Whether I make my
repository public or not will probably depend on how much I can
acquire my git knowledge and skills by that time.

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

Re: Emacs Mac port

[Sam Steingold]

It is alleged (http://emacs.stackexchange.com/a/3917/795) that your port
passes C-f2 to the OS.
What is the change that implements that?
Thanks!
Sam.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1343
http://www.childpsy.net/ http://truepeace.org http://mideasttruth.com
http://palestinefacts.org http://memri.org http://americancensorship.org
The only thing worse than X Windows: (X Windows) - X

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The third update of Emacs 24.4 Mac port 5.x is available from

    ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.4-mac-5.3.tar.gz

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

Blend-and-blur of background color on OS X 10.10 is temporarily
disabled to avoid mode-line erasure on frame focus switch.  For some
reason, mode-line row's `enabled_p' flag in the current matrix is
sometimes reset even if it is visible.  This causes blank mode-line on
"expose" (drawRect:) events.  In principle, this mode-line erasure can
also happen on older versions of OS X or this version of Emacs Mac
port.  But it is usually observed on OS X 10.10 together with previous
5.x versions of Emacs Mac port, because the use of NSVisualEffectView,
which provides the blend-and-blur feature, triggers full frame
"exposure" on focus switch.

** Fixed bugs

*** Special-display completion frame becomes transparent.
Reported by Alan Shumitt.
Adapt a fix for Bug#16619.

*** `mac-auto-ascii-mode' on TTY terminals disables prefix keys with
the meta key.

*** Control-F2 is passed to the system even if
mac-pass-control-to-system is set to nil.

*** Synthetic bold text looks thinner on Retina display/HiDPI mode.
This is because stroke line width for text drawing is not correctly
scaled (whereas it is correctly scaled when drawn to bitmaps) on such
environments.  I've been reporting this to Apple on every OS X update
since it was 10.7.4, but I couldn't get any response until recently.
At last Apple answers that there are no plans to address this issue
(rdar://11644870) currently.  So I added a workaround that would cause
a bad reverse effect if the original issue were fixed.

*** `mac-ae-set-reply-parameter', which is used for reporting an error
in Apple event hander, has not been working since emacs-24.2-mac-3.2.

*** Input source functions ignore disabled input source ID strings.

** Improvements

*** URL handler via Apple events now accepts the `org-protocol' scheme
as well as `mailto'.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 24.4.90 pretest is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.4.90-mac-5.4.tar.gz

Although it is based on a pretest version of Emacs, I don't mark this
version (5.4 rather than 5.90) of the Mac port as
experimental/hackers-only this time.

Now the `patch-mac' file is generated by `git diff', you will need to
specify `-p1' rather than `-p0' when applying the patch.

Git repository is also available at

  http://www.math.s.chiba-u.ac.jp/~mituharu/emacs-mac.git

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

* emacs-24.4.90-mac-5.4 (2015-02-18)
Based on 24.4.90.

Blend-and-blur of background color on OS X 10.10 is enabled again
because the mode-line erasure issue (Bug#19721) is fixed upstream.
The function `do-applescript' is now an alias of `mac-do-applescript',
which is implemented on top of `mac-osa-script'.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 18 Feb 2015 19:13:42 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> Git repository is also available at

>   http://www.math.s.chiba-u.ac.jp/~mituharu/emacs-mac.git

Sorry, I found several glitches.  I withdraw it for now.

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 24.4.91 pretest is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.4.91-mac-5.5.tar.gz

and Git repository is also available at

  http://www.math.s.chiba-u.ac.jp/~mituharu/emacs-mac.git

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

** Fixed bugs

*** Focusing a fullscreen frame whose menu-bar-lines value is 0
causes bouncing Spaces back.
Reported by Marius Kjeldahl.

** Improvements

*** Press and hold for accents is no longer unconditionally disabled.
You can enable it via the Preference system (e.g., "defaults write
org.gnu.Emacs ApplePressAndHoldEnabled YES").

*** Support emoji modifiers for skin tones (if the system and fonts
support them).

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 24.5 release candidate 1 is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-rc1-mac-5.6.tar.gz

and Git repository is also available at

  http://www.math.s.chiba-u.ac.jp/~mituharu/emacs-mac.git

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

** Fixed bugs

*** Pure space overflow on 32-bit build.

*** LookupViewService invoked by Command-Control-D or three-finger tap
crashes on OS X 10.10.3.
Not tested for "force clicking" with pressure-sensitive trackpads,
which require MacBook Pro (Retina, 13-inch, Early 2015) as of writing.

Re: Emacs Mac port

[Sam Steingold]

> * YAMAMOTO Mitsuharu <zvghuneh@zngu.f.puvon-h.np.wc> [2015-03-27 19:55:13 +0900]:
>
> The Mac port based on Emacs 24.5 release candidate 1 is now available from
>   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-rc1-mac-5.6.tar.gz
> and Git repository is also available at
>   http://www.math.s.chiba-u.ac.jp/~mituharu/emacs-mac.git

why is this not in the official tree?

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1344
http://www.childpsy.net/ http://jihadwatch.org http://dhimmi.org
http://palestinefacts.org http://www.memritv.org http://memri.org
Rottweiler puppy for sale, eats everything, loves children.

Re: Emacs Mac port

[Steinar Bang]

>>>>> Sam Steingold <sds@gnu.org>:

> why is this not in the official tree?

I'm guessing because the emacs git master was rebased after it had been
merged into the mac git, so they are seeing some of the bad side effects
of repeated merges of rebased commits: duplicate history log entries

Re: Emacs Mac port

[John Wiegley]

>>>>> Steinar Bang <sb@dod.no> writes:

> I'm guessing because the emacs git master was rebased after it had been
> merged into the mac git, so they are seeing some of the bad side effects of
> repeated merges of rebased commits: duplicate history log entries

The "Mac port" variant is maintained as a patch set, so there should be no
problem whatever with including it.  The real question is whether the FSF
wants to support a Carbon-based Emacs port, rather than the GNUstep port it
currently uses.

John

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 31 Mar 2015 20:42:43 +0200, Steinar Bang <sb@dod.no> said:

>>>>> Sam Steingold <sds@gnu.org>:
>> why is this not in the official tree?

> I'm guessing because the emacs git master was rebased after it had
> been merged into the mac git, so they are seeing some of the bad
> side effects of repeated merges of rebased commits: duplicate
> history log entries

Actually I don't understand what "the emacs git master was rebased"
means exactly, maybe because I'm very new to git.  The Mac port git
repository I published was first constructed on top of a clone of the
Emacs git repository as of January 2015.  I'm adding (a pushable copy
of) the Mac port git repository as a "git remote" onto the clone of
the Emacs repository created with the instructions in
admin/notes/git-workflow.

$ git remote -v
emacs-mac	localhost:src/emacs-mac.git (fetch)
emacs-mac	localhost:src/emacs-mac.git (push)
origin	git://git.savannah.gnu.org/emacs.git (fetch)
origin	git://git.savannah.gnu.org/emacs.git (push)

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

Re: Emacs Mac port

[Sam Steingold]

> * YAMAMOTO Mitsuharu <zvghuneh@zngu.f.puvon-h.np.wc> [2015-04-01 09:06:30 +0900]:
>
>>>>>> Sam Steingold <sds@gnu.org>:
>>> why is this not in the official tree?
>
> Actually I don't understand what "the emacs git master was rebased"
> means exactly, maybe because I'm very new to git.  The Mac port git
> repository I published was first constructed on top of a clone of the
> Emacs git repository as of January 2015.  I'm adding (a pushable copy
> of) the Mac port git repository as a "git remote" onto the clone of
> the Emacs repository created with the instructions in
> admin/notes/git-workflow.
>
> $ git remote -v
> emacs-mac	localhost:src/emacs-mac.git (fetch)
> emacs-mac	localhost:src/emacs-mac.git (push)
> origin	git://git.savannah.gnu.org/emacs.git (fetch)
> origin	git://git.savannah.gnu.org/emacs.git (push)

so, do you have any code which have not been pushed to origin?

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1344
http://www.childpsy.net/ http://openvotingconsortium.org http://www.memritv.org
http://think-israel.org http://www.dhimmitude.org http://honestreporting.com
Live free or die.

Re: Emacs Mac port

[Stefan Monnier]

> So, do you have any code which have not been pushed to origin?

Yes: all the code specific to the "Mac port" is only in his repository,
because it is not intended for inclusion in Emacs (where we use another
codebase for that same purpose).


        Stefan

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 27 Mar 2015 19:55:13 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> The Mac port based on Emacs 24.5 release candidate 1 is now available from

>   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-rc1-mac-5.6.tar.gz

> and Git repository is also available at

>   http://www.math.s.chiba-u.ac.jp/~mituharu/emacs-mac.git

I don't release the tarball for Emacs 24.5 release candidate 2: the
previous one applies to it.  The repository above is updated to
incorporate the release candidate 2.

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 02 Apr 2015 09:04:59 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>> The Mac port based on Emacs 24.5 release candidate 1 is now
>> available from

>> ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-rc1-mac-5.6.tar.gz

>> and Git repository is also available at

>> http://www.math.s.chiba-u.ac.jp/~mituharu/emacs-mac.git

> I don't release the tarball for Emacs 24.5 release candidate 2: the
> previous one applies to it.  The repository above is updated to
> incorporate the release candidate 2.

Ditto for release candidate 3.

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 24.5 is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.7.tar.gz

and Git repository is also available at

  http://www.math.s.chiba-u.ac.jp/~mituharu/emacs-mac.git

Note: Maybe I've once uploaded the repository above in a premature
state.  Please pull it again if you have already pulled it very
recently (within one hour before this announcement).

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

** Improvements

*** Update the list of emoji modifier base characters according to UTR
#51 version 1.0 (draft 8).

Re: Emacs Mac port

[John Wiegley]

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

> The Mac port based on Emacs 24.5 is now available from
>   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.7.tar.gz

Nix (from GitHub) has been updated with nixpkgs.emacs24Macport_24_5, which
includes this patch release.

John

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The first update of the Mac port based on Emacs 24.5 is available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.8.tar.gz

and Git repository is also available at

  http://www.math.s.chiba-u.ac.jp/~mituharu/emacs-mac.git

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

** Fixed bugs

*** Display may corrupt just after loading fonts.
Adapt a fix for Bug#20410.

*** System-wide popups (such as "Emoji & Symbols") are placed wrong
when the cursor is at end of line.

*** The symbol `left' for mac-right-*-modifier variables is not
properly presented in customization buffers.

** Improvements

*** Support ZWJ (ZERO WIDTH JOINER) sequences for emoji on OS X 10.10.3.

*** Now the `:button' property in the value of a modifier variable
(e.g., `mac-option-modifier') can be used for mapping button numbers.
The default setting maps the primary button with `fn' to mouse-2.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The second update of the Mac port based on Emacs 24.5 is available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.9.tar.gz

and Git repository is also available at

  http://www.math.s.chiba-u.ac.jp/~mituharu/emacs-mac.git

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

** Fixed bugs

*** Progress indicator is shown while tracking popup menu.

*** Command-H followed by clicking the dock icon may create a new
frame on OS X 10.10.

*** Cancel/OK buttons in font dialog look fat on OS X 10.10.

*** Several full screen glitches on OS X 10.11 Beta.
Custom transition animation is disabled to work around some problems
including crash.

*** Visible bell not visible on OS X 10.11 Beta.

** Improvements

*** New function `mac-application-state' to obtain the current status
as a GUI application.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The third update of the Mac port based on Emacs 24.5 is available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.10.tar.gz

and Git repository is also available at

  http://www.math.s.chiba-u.ac.jp/~mituharu/emacs-mac.git

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

** Fixed bugs

*** Crash when pressing Command + power button on OS X 10.9 and later.

** Improvements

*** Accept localized font family names on Mac OS X 10.6 and later.

*** Some resize operations on OS X 10.7 and later now involve
transition animations by decomposing and distributing the current
contents.  Examples include dragging with shift/option key pressed,
zooming, and dragging full screen tiling border on OS X 10.11 Beta.

*** New global minor mode `mac-auto-operator-composition-mode'.  If
enabled, it composes consecutive ASCII symbolic characters into a
special glyph when the font supports such a composition typically via
ligatures for operators in programming languages.  Tested with Hasklig
and Fira Code.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The fourth update of the Mac port based on Emacs 24.5 is available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.11.tar.gz

and Git repository is also available at

  http://www.math.s.chiba-u.ac.jp/~mituharu/emacs-mac.git

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

** Fixed bugs

*** Crash when closing a fullscreen frame on OS X 10.11 GM Candidate.

*** Daemon mode does not exec after fork at startup.  This is a
regression introduced in 3.90.

*** Display corrupts when zooming twice quickly.

*** Crash when displaying etc/HELLO file on OS X 10.11 GM Candidate.
It crashes when displaying Oriya characters with Arial Unicode MS.
This happens even with TextEdit.app if you explicitly select the font.
A workaround is added so Oriya Sangam MN is preferred by default.

** Improvements

*** Extend mode line areas while showing resize transition animation.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The fifth update of the Mac port based on Emacs 24.5 is available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.12.tar.gz

and Git repository is also available at

  http://www.math.s.chiba-u.ac.jp/~mituharu/emacs-mac.git

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

** Fixed bugs

*** Invoking Ediff from a fullscreen frame creates a fullscreen
Control Panel on OS X 10.11 (does not happen on OS X 10.11.1).

*** Changing a frame to/from fullboth does not make the frame key
window on OS X 10.11.

*** Making a fullboth frame fullscreen does not keep the tool bar
visibility on OS X 10.7 and later.

*** If the executable is built on an older OS/SDK and run on OS X
10.11, the frame placed in the left part of Split View gets maximized.
Reported by Alan Schmitt.

*** Crash when making a frame fullscreen/fullboth on Mac OS X 10.4.

*** Crash by infinite recursion while displaying box face.
Apply a fix for Bug#21428.

*** Crash when redisplaying a window changes faces or fonts.
Apply a fix for Bug#21428.

** Improvements

*** Fullscreen/fullboth frames no longer hide the Dock unnecessarily
if compiled and run on OS X 10.11.

*** Fullscreen transition animation looks a bit better on OS X 10.11.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 30 Oct 2015 11:52:28 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> The fifth update of the Mac port based on Emacs 24.5 is available from
>   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.12.tar.gz

> and Git repository is also available at

>   http://www.math.s.chiba-u.ac.jp/~mituharu/emacs-mac.git

I've just made another release to fix a crash bug.

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.13.tar.gz

If you already have emacs-24.5-mac-5.12.tar.gz, then you only need to
apply the patch below.  Sorry for the inconvenience.

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

** Fixed bugs

*** Closing a fullscreen frame may cause crash or Lisp error in
frame-live-p.

** Improvements

*** Fullboth frames are no longer eligible to become fullscreen via
Mission Control on OS X 10.11 (this change is actually made in 5.12).


diff --git a/src/macappkit.m b/src/macappkit.m
index 574bfb3..2a91aa0 100644
--- a/src/macappkit.m
+++ b/src/macappkit.m
@@ -4078,6 +4078,10 @@ static CGRect unset_global_focus_view_frame (void);
   EmacsFrameController * __unsafe_unretained weakSelf = self;
   BOOL savedToolbarVisibility;
 
+  /* Called also when a full screen window is being closed.  */
+  if (overlayWindow == nil)
+    return;
+
   if (fullScreenTargetState & WM_STATE_DEDICATED_DESKTOP)
     {
       /* Exiting full screen is triggered by external events rather
@@ -4093,15 +4097,11 @@ static CGRect unset_global_focus_view_frame (void);
   if (!(floor (NSAppKitVersionNumber) <= NSAppKitVersionNumber10_10_Max))
     [self preprocessWindowManagerStateChange:fullScreenTargetState];
 
-  /* Called also when a full screen window is being closed.  */
-  if (overlayWindow)
-    {
-      [self detachOverlayWindow];
-      [self addFullScreenTransitionCompletionHandler:^(EmacsWindow *window,
-						       BOOL success) {
-	  [weakSelf attachOverlayWindow];
-	}];
-    }
+  [self detachOverlayWindow];
+  [self addFullScreenTransitionCompletionHandler:^(EmacsWindow *window,
+						   BOOL success) {
+      [weakSelf attachOverlayWindow];
+    }];
 
   /* This is a workaround for the problem of not preserving toolbar
      visibility value.  */

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The seventh update of the Mac port based on Emacs 24.5 is available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.14.tar.gz

and Git repository is also available at

  http://www.math.s.chiba-u.ac.jp/~mituharu/emacs-mac.git

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

** Fixed bugs

*** mac-auto-operator-composition-mode breaks syntax highlighting.
Reported by James Reeves.

*** Hang when canceling pop-up dictionary with C-g on OS X 10.11.
Reported by Max Siegel.

** Improvements

*** Force clicking with a pressure-sensitive trackpad now pops up a
Quick Look window to look up the word under the pointer in the
dictionaries.
Note: This is currently hard-coded.  Also, unlike Command-Control-D or
three-finger tap, it is not easy or often impossible to specify the
region of the text you look up because down-mouse-1 event resets it.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 09 Dec 2015 12:28:59 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> The seventh update of the Mac port based on Emacs 24.5 is available from
>   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.14.tar.gz

> and Git repository is also available at

>   http://www.math.s.chiba-u.ac.jp/~mituharu/emacs-mac.git

I've just made another release to fix an invocation bug.  Sorry for
the short release interval again.

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.15.tar.gz

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

** Fixed bugs

*** Pure space overflow on 32-bit build.

*** Can't invoke from Finder if user's login shell is fish.
This is a regression introduced in 5.12.

*** Changing default font causes display corruption in some cases.
Reported by Leo.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on the `emacs-25' branch is now available from

  https://bitbucket.org/mituharu/emacs-mac.git (the `work' branch)

Note that this is a bare development branch and documentations are not
updated yet.  You don't have to specify --with-mac for configure
options because it is the default now.

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

Re: Emacs Mac port

[John Wiegley]

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

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

> The Mac port based on the `emacs-25' branch is now available from
> https://bitbucket.org/mituharu/emacs-mac.git (the `work' branch)

> Note that this is a bare development branch and documentations are not
> updated yet. You don't have to specify --with-mac for configure options
> because it is the default now.

Thank you, Yamamoto-san! This is fantastic, and will help me to track the
latest development more closely than a build I only use for testing.

How much work would it be for us to merge this build flavor into the main
emacs-25 branch?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 24 Dec 2015 09:28:35 -0800, John Wiegley <jwiegley@gmail.com> said:

>> The Mac port based on the `emacs-25' branch is now available from
>> https://bitbucket.org/mituharu/emacs-mac.git (the `work' branch)

>> Note that this is a bare development branch and documentations are
>> not updated yet. You don't have to specify --with-mac for configure
>> options because it is the default now.

> Thank you, Yamamoto-san! This is fantastic, and will help me to
> track the latest development more closely than a build I only use
> for testing.

> How much work would it be for us to merge this build flavor into the
> main emacs-25 branch?

Originally, the Mac port was not intended for inclusion to the
main distribution, but for my private and classroom use.  But if
the inclusion is useful and meaningful for many people, then I'll
make some effort to do that.

I have one concern about the inclusion of the Mac port, that is,
whether it can be merged with its full features.  If not, then I'll
have to provide some additional patch anyway, and that's not
beneficial to the current users of the Mac port.  In particular, I
suspect the inclusion of the following features might be controversial
whether they can be regarded as specific to Mac:

  * Pixel-based mouse wheel smooth scroll for newer mice/trackpads.
  * 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.
  * The function `mac-start-animation' provides several animation
    effects via Core Animation.  You can see the default
    animations with buffer switching by horizontal
    swiping/flicking (horizontal movement), exiting from the
    splash screen by typing "q" (fade out), and the "About
    Emacs" (ripple effect) and "Preferences..." menu items (swipe
    effect) in the application menu in the menu bar.
  * Emoji display, with support of variation sequences (text-style
    vs. emoji-style) and modifiers (skin tones) if the font supports
    them.
  * Blend-and-blur of background color on OS X 10.10 and later
    via face's stipple attribute: e.g., (set-face-stipple
    'fringe "alpha:50%").

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

Re: Emacs Mac port

[Bozhidar Batsov]

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

We should aim to provide the best possible Emacs experience on every
platform, so I doubt there will be much opposition to making that cocoa
port better. We've discussed with Jan a while back, that it's ok to add OS
X-specific features, as long as they are enabled conditionally and the the
GNUStep version is not affected by them.

I suspect that a lot of Emacs users are OS X users these days (many friends
of mine who were long-time GNU/Linux users work on OS X today, me
included), so the impact of improving the cocoa port can be potentially
huge!

On 28 December 2015 at 08:51, YAMAMOTO Mitsuharu <
mituharu@math.s.chiba-u.ac.jp> wrote:

> >>>>> On Thu, 24 Dec 2015 09:28:35 -0800, John Wiegley <jwiegley@gmail.com>
> said:
>
> >> The Mac port based on the `emacs-25' branch is now available from
> >> https://bitbucket.org/mituharu/emacs-mac.git (the `work' branch)
>
> >> Note that this is a bare development branch and documentations are
> >> not updated yet. You don't have to specify --with-mac for configure
> >> options because it is the default now.
>
> > Thank you, Yamamoto-san! This is fantastic, and will help me to
> > track the latest development more closely than a build I only use
> > for testing.
>
> > How much work would it be for us to merge this build flavor into the
> > main emacs-25 branch?
>
> Originally, the Mac port was not intended for inclusion to the
> main distribution, but for my private and classroom use.  But if
> the inclusion is useful and meaningful for many people, then I'll
> make some effort to do that.
>
> I have one concern about the inclusion of the Mac port, that is,
> whether it can be merged with its full features.  If not, then I'll
> have to provide some additional patch anyway, and that's not
> beneficial to the current users of the Mac port.  In particular, I
> suspect the inclusion of the following features might be controversial
> whether they can be regarded as specific to Mac:
>
>   * Pixel-based mouse wheel smooth scroll for newer mice/trackpads.
>   * 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.
>   * The function `mac-start-animation' provides several animation
>     effects via Core Animation.  You can see the default
>     animations with buffer switching by horizontal
>     swiping/flicking (horizontal movement), exiting from the
>     splash screen by typing "q" (fade out), and the "About
>     Emacs" (ripple effect) and "Preferences..." menu items (swipe
>     effect) in the application menu in the menu bar.
>   * Emoji display, with support of variation sequences (text-style
>     vs. emoji-style) and modifiers (skin tones) if the font supports
>     them.
>   * Blend-and-blur of background color on OS X 10.10 and later
>     via face's stipple attribute: e.g., (set-face-stipple
>     'fringe "alpha:50%").
>
>                                      YAMAMOTO Mitsuharu
>                                 mituharu@math.s.chiba-u.ac.jp
>
>

[-- Attachment #2: Type: text/html, Size: 4026 bytes --]

Re: Emacs Mac port

[John Wiegley]

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

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

> Originally, the Mac port was not intended for inclusion to the main
> distribution, but for my private and classroom use. But if the inclusion is
> useful and meaningful for many people, then I'll make some effort to do
> that.

It would not only be useful and meaningful to me, but it also has been to
every other Mac user I've recommended it to. They may not be on their list to
chime in, so allow me to proxy for them.

I'd very much like to see this included in the main distribution.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Emacs Mac port

[David Engster]

John Wiegley writes:
>>>>>> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>> Originally, the Mac port was not intended for inclusion to the main
>> distribution, but for my private and classroom use. But if the inclusion is
>> useful and meaningful for many people, then I'll make some effort to do
>> that.
>
> It would not only be useful and meaningful to me, but it also has been to
> every other Mac user I've recommended it to. They may not be on their list to
> chime in, so allow me to proxy for them.
>
> I'd very much like to see this included in the main distribution.

You skipped over this concern from Yamamoto-san, which I think is very
valid:

> In particular, I suspect the inclusion of the following features might
> be controversial whether they can be regarded as specific to Mac:

AFAIK I think it is not OK to have features that are specific to a
non-free plattform, so I'd suggest to discuss this with Richard first
before encouraging work on a possible merge.

-David

Re: Emacs Mac port

[John Wiegley]

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

>>>>> David Engster <deng@randomsample.de> writes:

> AFAIK I think it is not OK to have features that are specific to a non-free
> plattform, so I'd suggest to discuss this with Richard first before
> encouraging work on a possible merge.

It was my understanding that it is fine to have features that a volunteer is
willing to do the work for, just not to promote features that would make a
non-GNU platform more attractive (such as, by devoting any other resources to
their development, or giving them special status in any way).

If Yamamoto-san is doing the work and giving it to the Emacs project freely,
is there a reason to turn it down? I suppose this is indeed a matter for
Richard to weigh in on.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Emacs Mac port

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > We should aim to provide the best possible Emacs experience on every
  > platform,

Usually, but not always.  The purpose of GNU Emacs is to be a good
part of the GNU system and thus to make the GNU system better; other
platforms are secondary.  GNU Emacs should never offer people a
practical reason to use some other system instead of GNU.

Therefore, when someone implements a useful new feature but only for a
non-GNU system, we do not accept it that form.  Instead we say, "Make
it work equally well on GNU, and we will accept it."

  > many friends
  > of mine who were long-time GNU/Linux users work on OS X today, me
  > included

This is a VERY bad thing.  Can we find ways to discourage this?

In principle, adding nice features to Emacs that work on GNU/Linux and
do not work on MacOS could help.  But I don't see much scope for
success that way.  I think our principal hope of influencing people is
through influencing the way they think about the choice of system.
For instance, by teaching them to value freedom (which MacOS denies)
more and convenience (which Apple might offer them) less.

If we took the attitude that we aim to "serve the users" wherever they
happen to be, that would convey the message, "Sure, switch to MacOS --
we will make it easier for you."  For us, a self-defeating approach.

Thus our stance is that a person who moves from GNU/Linux to MacOS is
being self-destructively foolish.  We take this seriously and we must
speak and act in accord with it.  This way, we can influence some
people.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Emacs Mac port

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It was my understanding that it is fine to have features that a volunteer is
  > willing to do the work for, just not to promote features that would make a
  > non-GNU platform more attractive (such as, by devoting any other resources to
  > their development, or giving them special status in any way).

That is basically right.  More precisely, we don't want GNU Emacs to give
people any practical reason to prefer some other system to GNU.

  > If Yamamoto-san is doing the work and giving it to the Emacs project freely,
  > is there a reason to turn it down? I suppose this is indeed a matter for
  > Richard to weigh in on.

Could someone explain to me, first, what these features do?


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Emacs Mac port

[Jean-Christophe Helary]

> On Dec 29, 2015, at 15:47, Richard Stallman <rms@gnu.org> wrote:
> 
>> many friends
>> of mine who were long-time GNU/Linux users work on OS X today, me
>> included
> 
> Thus our stance is that a person who moves from GNU/Linux to MacOS is
> being self-destructively foolish.  We take this seriously and we must
> speak and act in accord with it.  This way, we can influence some
> people.

My personal opinion is that people do not switch to MacOS but rather to Apple machines which are typically better built than standard Intel based machines. It is the robustness of the hardware that appeals to most users, not the OS.

To have more people switch to a GNU/Linux system, you would have to find a maker that builds high quality machines for a price similar to what Apple offers (which is in all likeliness not possible) and offers similar flawless integration between the OS and the machine (which is possible).

Jean-Christophe Helary

Re: Emacs Mac port

[David Kastrup]

Jean-Christophe Helary <jean.christophe.helary@gmail.com> writes:

>> On Dec 29, 2015, at 15:47, Richard Stallman <rms@gnu.org> wrote:
>> 
>>> many friends
>>> of mine who were long-time GNU/Linux users work on OS X today, me
>>> included
>> 
>> Thus our stance is that a person who moves from GNU/Linux to MacOS is
>> being self-destructively foolish.  We take this seriously and we must
>> speak and act in accord with it.  This way, we can influence some
>> people.
>
> My personal opinion is that people do not switch to MacOS but rather
> to Apple machines which are typically better built than standard Intel
> based machines. It is the robustness of the hardware that appeals to
> most users, not the OS.

Shrug.  Linus Torvalds at one time used a Macbook Air for his
development IIRC, but obviously not running MacOS X on it.  So his
personal freedom was not hampered much more than with other typical
hardware choices.  It still lends financial support to a powerful
company who is rather firmly invested against the goals of the GNU
project for one thing and a number of issues concerning freedom and
computing for another.

> To have more people switch to a GNU/Linux system, you would have to
> find a maker that builds high quality machines for a price similar to
> what Apple offers (which is in all likeliness not possible) and offers
> similar flawless integration between the OS and the machine (which is
> possible).

Shrug.  To have more people switch to a GNU/Linux system, you need to
make them care about software freedom.  Locking people into their
choices results in money and power, both of which can partly be
reinvested to sweeten the deal.

It's the "Open Source movement" which thinks it can "win" on those
terms.  But you don't "fight" an empire by waiting until it
self-destructs before starting recruitment.  We will not beat Apple at
their game.  We can just offer a good way forward for those willing to
quit Apple's game.  And what we can offer these days requires much less
determination to choose than it did at one time.

But there will always be a personal cost to stop running with the herd
as long as the herd is not going straight off a cliff.

-- 
David Kastrup

Re: Emacs Mac port

[CHENG Gao]

*On Tue, 29 Dec 2015 18:40:29 +0900
* Also sprach Jean-Christophe Helary <jean.christophe.helary@gmail.com>:

>> On Dec 29, 2015, at 15:47, Richard Stallman <rms@gnu.org> wrote:
>> 
>>> many friends of mine who were long-time GNU/Linux users work on OS
>>> X today, me included
>>  Thus our stance is that a person who moves from GNU/Linux to MacOS
>> is being self-destructively foolish. We take this seriously and we
>> must speak and act in accord with it. This way, we can influence
>> some people.
>
> My personal opinion is that people do not switch to MacOS but rather
> to Apple machines which are typically better built than standard Intel
> based machines. It is the robustness of the hardware that appeals to
> most users, not the OS.
>
> To have more people switch to a GNU/Linux system, you would have to
> find a maker that builds high quality machines for a price similar to
> what Apple offers (which is in all likeliness not possible) and offers
> similar flawless integration between the OS and the machine (which is
> possible).
>
> Jean-Christophe Helary
>
Statements: I use MacOS (id. Mac computer), for long time.
            I wish hard work of Yamamoto san and even Aquamacs' be
            merged into Emacs, for long time. Since I think otherwise
            much man hours are not fully used and don't beneficit as
            many users as possible.

Personal experience:
I switched to Mac not because of it's vogue and chic etc. Only reason is
I was fed up with Wind-oz, which is not as romaintic as it sounds. I
started to use GNU/Linux, but you know at that time RedHat was not
playing well with my crappy computer. At last I switched to Mac since
after all it's UNIX. Then I just get used to it though I also run
GNU/Linux hardwares (in fact several of them).

With all above said, here comes MHO.

I don't think MacOS and GNU/Linux are comparable. They are apple versus
gnu, no matter literally ot not.

Mac(OS) is a self-contained ecosystem. It has its own business model,
and it doesn't carry that much historical burden on its shoulders. On
the contrary as few as it decides to. They can tailor their application
to few hardwares they choose. When decided to abandon Carbon, voila
Carbon abandoned. When decided your Mac is not qualified for next big
story, boys and girls, time to smash your piggy bank.

Can GNU/Linux shrugs these burden off? Or even can Wind-oz?

I bet if Emacs is only targeted to run on, say, 1Ghz+ 4-core+ CPU with
4G+ memory hardware, it will be entirely different beast. Found bugs in
Emacs 23? 22? Man, I am sorry, but we only do Emacs 25. So suit yourself
or shoot yourself.

I just think it's philosophical difference or gap.

Just my RMB2 cents.

Re: Emacs Mac port

[Rasmus]

Richard Stallman <rms@gnu.org> writes:

>   > If Yamamoto-san is doing the work and giving it to the Emacs
>   > project freely,
>   > is there a reason to turn it down? I suppose this is indeed a matter for
>   > Richard to weigh in on.
>
> Could someone explain to me, first, what these features do?

This was outlined by Yamamoto-san in this message:

     http://permalink.gmane.org/gmane.emacs.devel/196996

Here's the relevant quotation from Yamamoto-san:

    Originally, the Mac port was not intended for inclusion to the
    main distribution, but for my private and classroom use.  But if
    the inclusion is useful and meaningful for many people, then I'll
    make some effort to do that.

    I have one concern about the inclusion of the Mac port, that is,
    whether it can be merged with its full features.  If not, then I'll
    have to provide some additional patch anyway, and that's not
    beneficial to the current users of the Mac port.  In particular, I
    suspect the inclusion of the following features might be controversial
    whether they can be regarded as specific to Mac:

      * Pixel-based mouse wheel smooth scroll for newer mice/trackpads.
      * 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.
      * The function `mac-start-animation' provides several animation
        effects via Core Animation.  You can see the default
        animations with buffer switching by horizontal
        swiping/flicking (horizontal movement), exiting from the
        splash screen by typing "q" (fade out), and the "About
        Emacs" (ripple effect) and "Preferences..." menu items (swipe
        effect) in the application menu in the menu bar.
      * Emoji display, with support of variation sequences (text-style
        vs. emoji-style) and modifiers (skin tones) if the font supports
        them.
      * Blend-and-blur of background color on OS X 10.10 and later
        via face's stipple attribute: e.g., (set-face-stipple
        'fringe "alpha:50%").

-- 
Vote for proprietary math!

Re: Emacs Mac port

[John Wiegley]

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

>>>>> Richard Stallman <rms@gnu.org> writes:

> Could someone explain to me, first, what these features do?

      * Pixel-based mouse wheel smooth scroll for newer mice/trackpads.

You can scroll by pixels rather than by lines, is my understanding.

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

This should be self-explanatory. I think we could probably do this on
GNU/Linux also.

      * The function `mac-start-animation' provides several animation
        effects via Core Animation.  You can see the default
        animations with buffer switching by horizontal
        swiping/flicking (horizontal movement), exiting from the
        splash screen by typing "q" (fade out), and the "About
        Emacs" (ripple effect) and "Preferences..." menu items (swipe
        effect) in the application menu in the menu bar.

Core Animation is a Mac OS X facility for performing certain animations using
hardware accelerated rendering, and is the basis for the way the UI "feels".
This makes some of these animations available to Emacs, such as when buffer
switching by swiping on the trackpad. I would consider a feature like this
completely optional.

      * Emoji display, with support of variation sequences (text-style
        vs. emoji-style) and modifiers (skin tones) if the font supports
        them.

Emojis (like graphical smileys) can support more styling. Not sure if the
typography library on GNU/Linux makes this information available yet or not.

      * Blend-and-blur of background color on OS X 10.10 and later
        via face's stipple attribute: e.g., (set-face-stipple
        'fringe "alpha:50%").

When enabling transparency, allows another algorithm for blending with the
content of the desktop behind Emacs. I don't know if GNU/Linux could support
this, as it probably requires support from the window manager?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Emacs Mac port

[Clément Pit--Claudel]

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

On 12/29/2015 06:14 PM, John Wiegley wrote:
>>>>>> Richard Stallman <rms@gnu.org> writes:
>> Could someone explain to me, first, what these features do?
> 
> * Emoji display, with support of variation sequences (text-style vs.
> emoji-style) and modifiers (skin tones) if the font supports them.
> 
> Emojis (like graphical smileys) can support more styling.

That's not exactly it: it means support for a different set of fonts, whose glyphs are multi-color pictures instead of monochrome shapes.

I asked about this feature two weeks ago, and got many replies (most of them lukewarm). I think Richard and you also replied:

  > On 12/17/2015 06:25 PM, John Wiegley wrote:
  >>>>>>> Richard Stallman <rms@gnu.org> writes:
  >>> I suggest that we give low priority to this feature. If someone wants to
  >>> implement it and does a good job, we can accept it, but otherwise we don't
  >>> care.
  >>
  >> Agreed.

> Not sure if the typography library on GNU/Linux makes this
> information available yet or not.

Freetype has supported it since 2012. Emacs' has a direct interface to Freetype, but it seems to essentially be dead code. libXft doesn't expose Freetype's support for this feature, and I didn't get a reply from the devs on their mailing list about this. Cairo doesn't expose Freetype's support either, though Mozilla implemented support for it in their own branch. All in all it seems that it will be some time before GNU/Linux users get access to this feature.


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

Re: Emacs Mac port

[Clément Pit--Claudel]

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

On 12/29/2015 07:51 AM, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > It was my understanding that it is fine to have features that a volunteer is
>   > willing to do the work for, just not to promote features that would make a
>   > non-GNU platform more attractive (such as, by devoting any other resources to
>   > their development, or giving them special status in any way).
> 
> That is basically right.  More precisely, we don't want GNU Emacs to give
> people any practical reason to prefer some other system to GNU.

Yet this is precisely what we do, unwillingly: GNU Emacs lack of features on GNU Linux (compared to forks available on other systems) gives people practical reasons to use a non-GNU Emacs, on a non-free platform (that's where Emacs (but not GNU Emacs) works best).

Thus not accepting these MacOS-specific features in GNU Emacs only encourages people to prefer a non-GNU fork of Emacs; it doesn't do anything to prevent them from switching to a non-free platform. In conclusion, instead of using GNU Emacs on a non-free platform, people use a non-GNU Emacs on a non-free platform.


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

Re: Emacs Mac port

[Dmitry Gutov]

On 12/29/2015 08:00 PM, Clément Pit--Claudel wrote:

> Yet this is precisely what we do, unwillingly: GNU Emacs lack of features on GNU Linux (compared to forks available on other systems) gives people practical reasons to use a non-GNU Emacs, on a non-free platform (that's where Emacs (but not GNU Emacs) works best).
>
> Thus not accepting these MacOS-specific features in GNU Emacs only encourages people to prefer a non-GNU fork of Emacs; it doesn't do anything to prevent them from switching to a non-free platform. In conclusion, instead of using GNU Emacs on a non-free platform, people use a non-GNU Emacs on a non-free platform.

I think we consider people using non-GNU Emacs less of a problem than 
people using non-free platforms (or, worse, moving to them). Forks of 
Emacs are still libre software, after all.

Since adding feature to GNU Emacs that give more advantage to non-free 
platforms might encourage the latter, this seems to make a stronger case 
in favor of adding support for all (?) of the features in question on 
GNU/Linux than doing anything else, like merging Emacs Mac Port.

Re: Emacs Mac port

[David Kastrup]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 12/29/2015 08:00 PM, Clément Pit--Claudel wrote:
>
>> Yet this is precisely what we do, unwillingly: GNU Emacs lack of
>> features on GNU Linux (compared to forks available on other systems)
>> gives people practical reasons to use a non-GNU Emacs, on a non-free
>> platform (that's where Emacs (but not GNU Emacs) works best).
>>
>> Thus not accepting these MacOS-specific features in GNU Emacs only
>> encourages people to prefer a non-GNU fork of Emacs; it doesn't do
>> anything to prevent them from switching to a non-free platform. In
>> conclusion, instead of using GNU Emacs on a non-free platform,
>> people use a non-GNU Emacs on a non-free platform.
>
> I think we consider people using non-GNU Emacs less of a problem than
> people using non-free platforms (or, worse, moving to them). Forks of
> Emacs are still libre software, after all.

Not if you have to agree to onerous conditions in order to even compile
them.  Please take a look at the XCode use conditions.

-- 
David Kastrup

Re: Emacs Mac port

[Clément Pit--Claudel]

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

On 12/29/2015 07:09 PM, Dmitry Gutov wrote:
> Since adding feature to GNU Emacs that give more advantage to 
> non-free platforms might encourage the latter

I don't think many people care whether they are using GNU Emacs or a fork thereof, so I'm not sure it would change much to the current situation (people on MacOS can use a version of Emacs that has more features than the ones available on GNU/Linux).

> this seems to make a stronger case in favor of adding support for all
> (?) of the features in question on GNU/Linux than doing anything
> else, like merging Emacs Mac Port.

Fully agreed; it seems clear to me that the priority is in getting more of these features in Emacs for GNU/Linux.

I was just pointing out that as due to the current situation, I've had people point out to me that my Emacs experience would be nicer on MacOS than on GNU/Linux (and they are right: the best Emacs experience today is not on GNU/Linux). These people were not running GNU Emacs, but indeed that doesn't matter in terms of freedom (though it does matter in terms of using GNU Emacs to promote the GNU project).


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

Re: Emacs Mac port

[Christopher W Carpenter]

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


Clément Pit--Claudel <clement.pit@gmail.com> writes:

> On 12/29/2015 07:09 PM, Dmitry Gutov wrote:
>> Since adding feature to GNU Emacs that give more advantage to 
>> non-free platforms might encourage the latter
>
> I don't think many people care whether they are using GNU Emacs or a fork thereof, so I'm not sure it would change much to the current situation (people on MacOS can use a version of Emacs that has more features than the ones available on GNU/Linux).
>
>> this seems to make a stronger case in favor of adding support for all
>> (?) of the features in question on GNU/Linux than doing anything
>> else, like merging Emacs Mac Port.
>
> Fully agreed; it seems clear to me that the priority is in getting more of these features in Emacs for GNU/Linux.
>
> I was just pointing out that as due to the current situation, I've had people
> point out to me that my Emacs experience would be nicer on MacOS than on
> GNU/Linux (and they are right: the best Emacs experience today is not on
> GNU/Linux). These people were not running GNU Emacs, but indeed that doesn't
> matter in terms of freedom (though it does matter in terms of using GNU Emacs to
> promote the GNU project).


FWIW emacs of Mac OS X (any of the versions I tried before just
installing debian on my macbook) have significantly degraded buffer
performance compared to Linux. I believe bugs were filed about it but
most of the core dev team don't have a mac to test on.

If you do any heavy buffer updating (like using emacs as a terminal
emulator) you can actually slow down the process creating the output.

So no, even from a practical sense you would not have a nicer experience
in MacOS IMHO.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Emacs Mac port

[Clément Pit--Claudel]

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

On 12/29/2015 07:57 PM, Christopher W Carpenter wrote:
> Clément Pit--Claudel <clement.pit@gmail.com> writes:
> 
>> On 12/29/2015 07:09 PM, Dmitry Gutov wrote:
>>> Since adding feature to GNU Emacs that give more advantage to 
>>> non-free platforms might encourage the latter
>>
>> I don't think many people care whether they are using GNU Emacs or a fork thereof, so I'm not sure it would change much to the current situation (people on MacOS can use a version of Emacs that has more features than the ones available on GNU/Linux).
>>
>>> this seems to make a stronger case in favor of adding support for all
>>> (?) of the features in question on GNU/Linux than doing anything
>>> else, like merging Emacs Mac Port.
>>
>> Fully agreed; it seems clear to me that the priority is in getting more of these features in Emacs for GNU/Linux.
>>
>> I was just pointing out that as due to the current situation, I've had people
>> point out to me that my Emacs experience would be nicer on MacOS than on
>> GNU/Linux (and they are right: the best Emacs experience today is not on
>> GNU/Linux). These people were not running GNU Emacs, but indeed that doesn't
>> matter in terms of freedom (though it does matter in terms of using GNU Emacs to
>> promote the GNU project).
> 
> 
> FWIW emacs of Mac OS X (any of the versions I tried before just
> installing debian on my macbook) have significantly degraded buffer
> performance compared to Linux. I believe bugs were filed about it but
> most of the core dev team don't have a mac to test on.
> 
> If you do any heavy buffer updating (like using emacs as a terminal
> emulator) you can actually slow down the process creating the output.
> 
> So no, even from a practical sense you would not have a nicer experience
> in MacOS IMHO.

I see. I don't own a Mac, so I can't tell; it's good news that GNU Emacs on GNU/Linux still has an edge over the Mac versions :)
I've heard people say a lot of good things about smooth scrolling on Mac; I imagine they didn't run into the problem that you pointed out.


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

Re: Emacs Mac port

[Dmitry Gutov]

On 12/29/2015 08:19 PM, David Kastrup wrote:

> Not if you have to agree to onerous conditions in order to even compile
> them.  Please take a look at the XCode use conditions.

Does Homebrew require XCode to be installed, and those conditions accepted?

Either way, though, IIUC most Mac OS users install GNU Emacs the same 
way (using Homebrew).

Re: Emacs Mac port

[John Wiegley]

>>>>> Christopher W Carpenter <mordocai@mordocai.net> writes:

> If you do any heavy buffer updating (like using emacs as a terminal
> emulator) you can actually slow down the process creating the output.

And this is the default Cocoa build, right? Because I think this is one of the
very things that the Mac Port build variant from Yamamoto-san fixes.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Emacs Mac port

[Christopher W Carpenter]

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

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Christopher W Carpenter <mordocai@mordocai.net> writes:
>
>> If you do any heavy buffer updating (like using emacs as a terminal
>> emulator) you can actually slow down the process creating the output.
>
> And this is the default Cocoa build, right? Because I think this is one of the
> very things that the Mac Port build variant from Yamamoto-san fixes.

It has been many months since I did it and I didn't keep great notes so
i'm not sure, but I believe I tried the binary from
http://emacsformacosx.com/ as well as many different options using brew
and got the same results. Not sure if I got Yamamoto-San's version while
trying things or not.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Emacs Mac port

[Alex Dunn]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Does Homebrew require XCode to be installed, and those conditions accepted?

Clang and related build tools are provided by Xcode and the Xcode
Command-Line Tools, so for software that needs to be compiled; yes.  But
pre-compiled binaries can be installed without.  So it might be
possible—I haven’t tried—to installed Homebrew’s “bottled” GCC, then use
that for software that needs to be compiled from source, all without
agreeing to the Xcode terms.

Re: Emacs Mac port

[John Wiegley]

>>>>> Alex Dunn <dunn.alex@gmail.com> writes:

> Clang and related build tools are provided by Xcode and the Xcode
> Command-Line Tools, so for software that needs to be compiled; yes. But
> pre-compiled binaries can be installed without. So it might be possible—I
> haven’t tried—to installed Homebrew’s “bottled” GCC, then use that for
> software that needs to be compiled from source, all without agreeing to the
> Xcode terms.

Just as a side note: the Nix build of Emacs on Mac does not require Xcode to
be installed. It downloads and builds clang or gcc itself in order to build
Emacs. Xcode is no longer necessary on Mac for building free software.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Emacs Mac port

[David Kastrup]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Alex Dunn <dunn.alex@gmail.com> writes:
>
>> Clang and related build tools are provided by Xcode and the Xcode
>> Command-Line Tools, so for software that needs to be compiled; yes. But
>> pre-compiled binaries can be installed without. So it might be possible—I
>> haven’t tried—to installed Homebrew’s “bottled” GCC, then use that for
>> software that needs to be compiled from source, all without agreeing to the
>> Xcode terms.
>
> Just as a side note: the Nix build of Emacs on Mac does not require
> Xcode to be installed. It downloads and builds clang or gcc itself in
> order to build Emacs. Xcode is no longer necessary on Mac for building
> free software.

For command line applications, namely the kind of stuff that would also
run under Darwin alone.  I don't think that popular versions of Emacs
would be in that category.

-- 
David Kastrup

Re: Emacs Mac port

[John Wiegley]

>>>>> David Kastrup <dak@gnu.org> writes:

> For command line applications, namely the kind of stuff that would also run
> under Darwin alone. I don't think that popular versions of Emacs would be in
> that category.

For any kind of application. I'm using the fully graphical Mac Port version of
Emacs as an application, without Xcode.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Emacs Mac port

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > My personal opinion is that people do not switch to MacOS but
  > rather to Apple machines which are typically better built than
  > standard Intel based machines. It is the robustness of the
  > hardware that appeals to most users, not the OS.

GNU/Linux works on those machines, so when you meet people who use
them with MacOS, how about suggesting that they install GNU/Linux?

  > To have more people switch to a GNU/Linux system, you would have
  > to find a maker that builds high quality machines for a price
  > similar to what Apple offers

It is true that that would help our cause -- true, but not useful,
since we have no control and hardly any influence over manufacturers.

Fortunately, the claim that that's the _only_ way is not true.  It
applies only to users who judge _only_ based on convenience.

Those people are many, but what they are doing is folly (c'est fou).
They are ignoring the issue of freedom and how their software
subjugates them and mistreats them.

Our overall goal is to free them from user-subjugating software
(logiciel privateur).  If we call their attention to this issue, some
of them will be disgusted with what they have accepted until now,
and some of them will change.

I suggest showing people fsf.org/tedx,
http://gnu.org/philosophy/free-software-even-more-important.html
(..fr.html is the French translation), and http://gnu.org/proprietary.

You can help spread this issue by making your own decisions based
on freedom, and showing your friends and associates that you do.

David Kastrup said it very well:

  > It's the "Open Source movement" which thinks it can "win" on those
  > terms.  But you don't "fight" an empire by waiting until it
  > self-destructs before starting recruitment.  We will not beat Apple at
  > their game.  We can just offer a good way forward for those willing to
  > quit Apple's game.  And what we can offer these days requires much less
  > determination to choose than it did at one time.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Emacs Mac port

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I bet if Emacs is only targeted to run on, say, 1Ghz+ 4-core+ CPU with
  > 4G+ memory hardware, it will be entirely different beast. Found bugs in
  > Emacs 23? 22? Man, I am sorry, but we only do Emacs 25. So suit yourself
  > or shoot yourself.

I am not sure what you mean -- it is like a Chinese poem, leading
to a long discussion about the meaning.

Could you say what you think we should do, and why?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Emacs Mac port

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]


  >       * Blend-and-blur of background color on OS X 10.10 and later
  >         via face's stipple attribute: e.g., (set-face-stipple
  >         'fringe "alpha:50%").

  > When enabling transparency, allows another algorithm for blending with the
  > content of the desktop behind Emacs. I don't know if GNU/Linux could support
  > this, as it probably requires support from the window manager?

I don't think the window manager has anything to do with it,
but it requires support from the X server and library, or whatever
is used now instead of that.

We can install the MacOS support for this if and when we also support
it on GNU/Linux.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Emacs Mac port

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I was just pointing out that as due to the current situation, I've
  > had people point out to me that my Emacs experience would be nicer
  > on MacOS than on GNU/Linux (and they are right: the best Emacs
  > experience today is not on GNU/Linux).

If there are technical advantages to running Emacs on MacOS rather
than on GNU,that is a bad thing.  Adding more MacOS-only features to
GNU Emacs would make it worse.

To correct this technical problem entails (1) putting support into X
display for these features and (2) making Emacs interface to them.
Since (1) is the hard job and (2) is comparatively easy, our proper
technical response is to urge people to work on (1).  Would you like
to work on it?

However, our response should not be purely technical, because the
problem is not purely technical.  A big part of the problem is that
these people judge the "best" experience in a shallow, superficial
way, considering convenience alone and disregarding freedom.  When you
judge based on freedom, SmackOS is a horrible experience.

We need to do more to point out this issue to the people who habitually
disregard it, or don't know about it.

I suggest showing other people fsf.org/tedx and
http://gnu.org/philosophy/free-software-even-more-important.html.
Also http://gnu.org/proprietary/malware-apple.html.

Your personal example can influence people.  If you put GNU/Linux on
your Mac, and tell your friends, "I want freedom.  I will sacrifice
some convenience so I can be free," you will influence some of them
somewhat.

See http://gnu.org/philosophy/compromise.html.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Emacs Mac port

[CHENG Gao]

*On Tue, 29 Dec 2015 14:37:40 -0800
* Also sprach John Wiegley <jwiegley@gmail.com>:

>>>>>> Alex Dunn <dunn.alex@gmail.com> writes:
>
>> Clang and related build tools are provided by Xcode and the Xcode
>> Command-Line Tools, so for software that needs to be compiled; yes.
>> But pre-compiled binaries can be installed without. So it might be
>> possible—I haven’t tried—to installed Homebrew’s “bottled” GCC, then
>> use that for software that needs to be compiled from source, all
>> without agreeing to the Xcode terms.
>
> Just as a side note: the Nix build of Emacs on Mac does not require
> Xcode to be installed. It downloads and builds clang or gcc itself in
> order to build Emacs. Xcode is no longer necessary on Mac for building
> free software.

Just FYI only in case someone needs. In Github there is an
osx-gcc-installer, which could install build essentials.

Yes Xcode is not necessary for building free softwares.

Re: Emacs Mac port

[CHENG Gao]

*On Wed, 30 Dec 2015 01:09:38 -0500
* Also sprach Richard Stallman <rms@gnu.org>:

> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]] [[[
> foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I bet if Emacs is only targeted to run on, say, 1Ghz+ 4-core+ CPU
>   > with 4G+ memory hardware, it will be entirely different beast.
>   > Found bugs in Emacs 23? 22? Man, I am sorry, but we only do Emacs
>   > 25. So suit yourself or shoot yourself.
>
> I am not sure what you mean -- it is like a Chinese poem, leading to a
> long discussion about the meaning.
>
> Could you say what you think we should do, and why?

What I mean is GNU/Linux world carries heavy burden and has to acccomodate
oceans of hardwares spanning decades. So it's not proper and fair to
compare GNU/Linux with MacOS since Mac(OS) is a self-contained ecosystem
and distates hardware - generally after several major releases (like two
or three) you have to ditch your computer and buy a latest one to use
latest OS.

Just arguing with OP. I didn't suggest anything.

Re: Emacs Mac port

[David Kastrup]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> David Kastrup <dak@gnu.org> writes:
>
>> For command line applications, namely the kind of stuff that would
>> also run under Darwin alone. I don't think that popular versions of
>> Emacs would be in that category.
>
> For any kind of application. I'm using the fully graphical Mac Port
> version of Emacs as an application, without Xcode.

And you compiled it yourself without reverting to Xcode?

-- 
David Kastrup

Re: Emacs Mac port

[Clément Pit--Claudel]

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

On 12/30/2015 07:11 AM, Richard Stallman wrote:
> To correct this technical problem entails (1) putting support into X
> display for these features and (2) making Emacs interface to them.
> Since (1) is the hard job and (2) is comparatively easy, our proper
> technical response is to urge people to work on (1).  Would you like
> to work on it?

If anyone knows a libXft maintainer, I'll be happy to talk to them; my email to their mailing list gathered exactly one response, which I can unfortunately not make any sense of:

}} -------- Forwarded Message --------
}} Subject: Re: Color bitmap support in Xft?
}} Date: Fri, 18 Dec 2015 08:16:37 +0100
}} From: Michael Titke <michael.tiedtke@o2online.de>
}} To: xorg@lists.x.org
}}
}} Just add a video mode font (we'll need to "typeset" videos intext anyway - what was layout then?) and replace user input with random noise where DSP would have told those smart ones ...
}}
}} On 17/12/2015 21:23, Clément Pit--Claudel wrote:
}} > Hi all,
}} >
}} > I'm looking into adding support for color emoji to Emacs. Color emoji use a new feature of OpenType fonts that allows font designers to embed full-color images in a font for certain glyphs. Fonts such as Google Noto Emoji or Apple Color Emoji thus have a table mapping certain Unicode points to raster color images. This feature is frequently used on smartphones, and was more recently added to Chrome and Firefox (both get it throught Freetype).
}} >
}} > Freetype has support for these multicolor glyphs since version 2.5 (2013). So does FontConfig (and, apparently, Skia). However, it does not seem to be possible to use this feature through Xft.
}} > Has there been efforts to support it?
}} >
}} > IIUC, the required changes would involve extending case matches that look at the FT_Pixel_Mode enumeration (it gained a new member FT_PIXEL_MODE_BGRA), and passing an extra flag to Freetype. Here is the relevant documentation:
}} >
}} >> FT_PIXEL_MODE_BGRA
}} >>
}} >> An image with four 8-bit channels per pixel, representing a color
}} >> image (such as emoticons) with alpha channel. For each pixel, the
}} >> format is BGRA, which means, the blue channel comes first in memory.
}} >> The color channels are pre-multiplied and in the sRGB colorspace. For
}} >> example, full red at half-translucent opacity will be represented as
}} >> ‘00,00,80,80’, not ‘00,00,FF,80’. See also FT_LOAD_COLOR.
}} >> FT_LOAD_COLOR
}} >>
}} >> This flag is used to request loading of color embedded-bitmap
}} >> images. The resulting color bitmaps, if available, will have the
}} >> FT_PIXEL_MODE_BGRA format. When the flag is not used and color
}} >> bitmaps are found, they will be converted to 256-level gray bitmaps
}} >> transparently. Those bitmaps will be in the FT_PIXEL_MODE_GRAY
}} >> format
}} > Has such an extension been discussed before? Or am I taking the wrong approach?
}} >
}} > Clément.

On the other hand, the person who implemented support in Freetype said that he would look into it (in an exchange at https://github.com/googlei18n/color-emoji/issues/5).
Having no experience with this (and seeing that a patch adding support for it was proposed to libXft at http://lists.x.org/archives/xorg-devel/2015-August/047175.html last August but received no responses), I'm not sure what more to do. Advice is very welcome though!

Clément.


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

Re: Emacs Mac port

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> However, our response should not be purely technical, because the
> problem is not purely technical.  A big part of the problem is that
> these people judge the "best" experience in a shallow, superficial
> way, considering convenience alone and disregarding freedom.  When you
> judge based on freedom, SmackOS is a horrible experience.
>
> We need to do more to point out this issue to the people who
> habitually disregard it, or don't know about it.
>
> I suggest showing other people fsf.org/tedx and
> http://gnu.org/philosophy/free-software-even-more-important.html.
> Also http://gnu.org/proprietary/malware-apple.html.
>
> Your personal example can influence people.  If you put GNU/Linux on
> your Mac, and tell your friends, "I want freedom.  I will sacrifice
> some convenience so I can be free," you will influence some of them
> somewhat.

Personally, these days I find that the most convincing treatises about
the importance of software freedom are written by Apple and Microsoft
themselves.

Just read the "license agreement" of their software to users and ask
them for every sentence whether they really agree (plan plenty of time
for that: I think the "privacy agreement" for Windows 10 alone runs to
about 20 pages).  It was solemn for MSDOS, sobering for Windows 3.1,
troubling for Windows 95, and has become so outlandish since then that
it's hard to believe if you read the entire thing.

These days "don't agree to stuff you haven't read" is pretty much
sufficient for leaving little but Free Software as a serious option.

-- 
David Kastrup

Re: Emacs Mac port

[John Wiegley]

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

>>>>> Richard Stallman <rms@gnu.org> writes:

>> * Blend-and-blur of background color on OS X 10.10 and later
>> via face's stipple attribute: e.g., (set-face-stipple
>> 'fringe "alpha:50%").

> We can install the MacOS support for this if and when we also support it on
> GNU/Linux.

Very well. Yamamoto-san, I imagine this will mean you still have to maintain a
separate patch for Mac Port, but now covering only those features that the FSF
does not yet accept into GNU Emacs. All the rest of your work can be merged in
when you are ready. This should leave you with a much smaller patch to manage
separately.

I would like to see this work applied to the emacs-25 branch, as I have been
using it daily for years and can vouch for its readiness. We also need a new
section in the NEWS to describe what it offers as a build flavor for Mac
users, and a section in the INSTALL file describing how to select it.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Emacs Mac port

[Chad Brown]

> On 30 Dec 2015, at 11:57, John Wiegley <jwiegley@gmail.com> wrote:
> 
> Very well. Yamamoto-san, I imagine this will mean you still have to maintain a
> separate patch for Mac Port, but now covering only those features that the FSF
> does not yet accept into GNU Emacs. All the rest of your work can be merged in
> when you are ready. This should leave you with a much smaller patch to manage
> separately.
> 
> I would like to see this work applied to the emacs-25 branch, as I have been
> using it daily for years and can vouch for its readiness. We also need a new
> section in the NEWS to describe what it offers as a build flavor for Mac
> users, and a section in the INSTALL file describing how to select it.

Personally, I would like to see the Mac Port gain support for the
NS port’s relocatable application bundle (that is, everything
Emacs uses is inside Emacs.app, and /usr/local is not touched).
This makes keeping multiple versions of emacs on the same machine
much nicer.

This support already works for NS and GNUStep, so it shouldn’t be
too hard to add to the Mac Port. Other platforms don’t use the
“.app” functionality, so it shouldn’t impact them, except to make
the functionality more portable if someone wants to try to adapt
it there.

I had meant to do this myself, and will get to it eventually, but
my hacking time is almost non-existant at this point,
unfortunately.

Thank you,
~Chad

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 30 Dec 2015 11:57:43 -0800, John Wiegley <jwiegley@gmail.com> said:

>>> * Blend-and-blur of background color on OS X 10.10 and later via
>>> face's stipple attribute: e.g., (set-face-stipple 'fringe
>>> "alpha:50%").

>> We can install the MacOS support for this if and when we also
>> support it on GNU/Linux.

> Very well. Yamamoto-san, I imagine this will mean you still have to
> maintain a separate patch for Mac Port, but now covering only those
> features that the FSF does not yet accept into GNU Emacs. All the
> rest of your work can be merged in when you are ready. This should
> leave you with a much smaller patch to manage separately.

The above feature is the least important one among what I gave in the
previous mail.  Probably I'll just disable it and I won't provide a
separate patch.

I'll start with committing a few changes that are currently included
in the Mac port but actually not specific to it.

What should I do for the copyright lines at the beginning of the
port-specific files?  Currently, the first lines in src/mac.c look
like:

  /* Unix emulation routines for GNU Emacs on the Mac OS.
     Copyright (C) 2000-2008  Free Software Foundation, Inc.
     Copyright (C) 2009-2015  YAMAMOTO Mitsuharu

because this file is derived from the corresponding one in Emacs 22
where the Carbon port (the precedessor of the Mac port) was a part of
the standard distribution.

The copyright lines in a file that are not derived from the Carbon
port look like

  /* Definitions and headers for AppKit framework on the Mac OS.
     Copyright (C) 2008-2015  YAMAMOTO Mitsuharu

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

Re: Emacs Mac port

[Paul Eggert]

YAMAMOTO Mitsuharu wrote:
>       Copyright (C) 2000-2008  Free Software Foundation, Inc.
>       Copyright (C) 2009-2015  YAMAMOTO Mitsuharu

You've assigned copyright to the FSF, right? So, change this to:

   Copyright (C) 2000-2015 Free Software Foundation, Inc.

>      Copyright (C) 2008-2015  YAMAMOTO Mitsuharu

and change this to:

   Copyright (C) 2008-2015 Free Software Foundation, Inc.

Re: Emacs Mac port

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Thanks for showing me the list.  I will look at them one by one.

        > * Pixel-based mouse wheel smooth scroll for newer mice/trackpads.

I think we support this already on various systems.
If that is so, there is no reason not to support it on MacOS also.

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

Does the clipboard on X support images?  If so, can Emacs handle them?
If this feature works on other systems, it is ok to support it on MacOS too.

        > * The function `mac-start-animation' provides several animation
        >   effects via Core Animation.

It looks like this feature would only be for MacOS, so we should not
install it.  If you would like to help the cause of freedom, one way
you can do so is by not releasing this code at all.

        > * Emoji display, with support of variation sequences (text-style
        >   vs. emoji-style) and modifiers (skin tones) if the font supports
        >   them.

Reportedly this needs changes in other parts of GNU/Linux first.
Until then, we should not install it.

        > * Blend-and-blur of background color on OS X 10.10 and later
        >   via face's stipple attribute: e.g., (set-face-stipple
        >   'fringe "alpha:50%").

Likewise for this, I think.

Above all, we need to avoid falling into thinking with the wrong values.
Our freedom is more important than any number of features like these.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Emacs Mac port

[Richard Stallman]

I know even less about libXft than you.  I don't really know what job
it does.  For help in understanding that, I suggest asking people who
already know something about it.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Emacs Mac port

[Adrian.B.Robert]

John Wiegley <jwiegley@gmail.com> writes:

> ...
> I would like to see this work applied to the emacs-25 branch, as I have been
> using it daily for years and can vouch for its readiness. We also need a new
> section in the NEWS to describe what it offers as a build flavor for Mac
> users, and a section in the INSTALL file describing how to select it.

What is the status of multi-TTY support in the Mac Port?  From this post
it looks like it is not there yet?

https://www.reddit.com/r/emacs/comments/3vvrln/emacsmacport_and_the_daemon_problem/

If not, I suppose it will be worth mentioning this, and perhaps the
workarounds given in Reddit, in the INSTALL or NEWS.

Also, it may be worth to mention major user-visible differences from the main
NS version.  Not necessarily the bells and whistles, but functional items such
as the Meta/Super mapping mentioned in another thread (if it remains a
difference).

Re: Emacs Mac port

[Chad Brown]

> On 30 Dec 2015, at 22:30, Richard Stallman <rms@gnu.org> wrote:
> 
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>> * The function `mac-start-animation' provides several animation
>>  effects via Core Animation.
> 
> It looks like this feature would only be for MacOS, so we should not
> install it.  If you would like to help the cause of freedom, one way
> you can do so is by not releasing this code at all.

In case it wasn’t clear, this code just turns on a basic OS feature that
is built in to MacOS. The code isn’t creating animations for emacs or
adding animation support to the OS.

~Chad

Re: Emacs Mac port

[Random832]

Chad Brown <yandros@gmail.com> writes:
> In case it wasn’t clear, this code just turns on a basic OS feature that
> is built in to MacOS. The code isn’t creating animations for emacs or
> adding animation support to the OS.

It's not clear from the description here what the animations are or when
they are used. From a description elsewhere it sounds like it uses a
"sliding pages" effect for switching buffers with certain mouse
gestures? Is there anything else?

Incidentally, I did find some information suggesting that GNUstep is
planning work and/or has done work on CoreAnimation.

http://heronsperch.blogspot.com/2013/06/gnustep-mythbusting.html
https://github.com/gnustep/quartzcore

Does anyone here use ns-emacs on GNUstep?

Re: Emacs Mac port

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >> * The function `mac-start-animation' provides several animation
  > >>  effects via Core Animation.
  > > 
  > > It looks like this feature would only be for MacOS, so we should not
  > > install it.  If you would like to help the cause of freedom, one way
  > > you can do so is by not releasing this code at all.

  > In case it wasn’t clear, this code just turns on a basic OS feature that
  > is built in to MacOS.

I supposed it was that way.  So this is no surprise, but it is
unfortunate.

If the code to do the hard work were in Emacs, we could probably
easily make it work on other systems.  And we could more or less take
for granted someone would soon do so.  So it would be ok to install.

Since the implementation is mostly in MacOS, making it work on
GNU/Linux is a bigger job.  We must stand firm and say, "If you want
this to work on MacOS, implement it for GNU."

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Emacs Mac port

[Daniel Colascione]

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

On 12/30/2015 10:30 PM, Richard Stallman wrote:
>         > * The function `mac-start-animation' provides several animation
>         >   effects via Core Animation.
> 
> It looks like this feature would only be for MacOS, so we should not
> install it.  If you would like to help the cause of freedom, one way
> you can do so is by not releasing this code at all.

You'll probably just interpret this email as an attack on free software
or something, so I really shouldn't bother sending it --- but I really
can't help in this particular instance pointing out how absurd it is to
claim that someone shouldn't provide a trivial interface to platform
graphical facilities, and support emojis, merely because nobody's
bothered to implement these facilities on GNU/X11/GTK/Linux.

I probably shouldn't point this out, but Emacs on OS X already supports
invoking AppleScript. There's no GNU/Linux equivalent. Quelle horreur!

>         > * Emoji display, with support of variation sequences (text-style
>         >   vs. emoji-style) and modifiers (skin tones) if the font supports
>         >   them.
> 
> Reportedly this needs changes in other parts of GNU/Linux first.
> Until then, we should not install it.

Why don't *you* send a patch?

That way, we can make both Emacs and GNU/Linux better instead of making
Emacs worse to accomplish making GNU/Linux look marginally better ---
actually, in accomplish nothing, since nobody's fooled into thinking OS
X lacks features merely because Emacs doesn't support them.

>         > * Blend-and-blur of background color on OS X 10.10 and later
>         >   via face's stipple attribute: e.g., (set-face-stipple
>         >   'fringe "alpha:50%").
> 
> Likewise for this, I think.
> 
> Above all, we need to avoid falling into thinking with the wrong values.
> Our freedom is more important than any number of features like these.

Do you even care that your strategy hasn't been working?


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

Re: Emacs Mac port

[Jean-Christophe Helary]

> On Jan 1, 2016, at 15:54, Daniel Colascione <dancol@dancol.org> wrote:
> 
> I probably shouldn't point this out, but Emacs on OS X already supports
> invoking AppleScript. There's no GNU/Linux equivalent. Quelle horreur!

That's an external mode for users to install.

> Do you even care that your strategy hasn't been working?

Emacs has been around longer than a huge amount of software and is bound to stay for a long time and outlive most of the editors that exist today. So it's hard to demonstrate that the "strategy" is not working. In fact, as was pointed earlier in this thread, a huge lot of Emacs users use it within OSX and *not* for it's ability to display emojis...

Jean-Christophe Helary 

Re: Emacs Mac port

[Daniel Colascione]

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

On 12/31/2015 11:36 PM, Jean-Christophe Helary wrote:
> 
>> On Jan 1, 2016, at 15:54, Daniel Colascione <dancol@dancol.org> wrote:
>>
>> I probably shouldn't point this out, but Emacs on OS X already supports
>> invoking AppleScript. There's no GNU/Linux equivalent. Quelle horreur!
> 
> That's an external mode for users to install.

No it isn't. Grep for ns-do-applescript.

>> Do you even care that your strategy hasn't been working?
> 
> Emacs has been around longer than a huge amount of software and is bound to stay for a long time and outlive most of the editors that exist today. So it's hard to demonstrate that the "strategy" is not working. In fact, as was pointed earlier in this thread, a huge lot of Emacs users use it within OSX and *not* for it's ability to display emojis...

Let's talk about how keeping features out of GCC led to the total defeat
of Clang.


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

Re: Emacs Mac port

[Ingo Lohmar]

On Thu, Dec 31 2015 23:47 (-0800), Daniel Colascione wrote:

> On 12/31/2015 11:36 PM, Jean-Christophe Helary wrote:
>> 
>>> On Jan 1, 2016, at 15:54, Daniel Colascione <dancol@dancol.org> wrote:
>>>
>>> I probably shouldn't point this out, but Emacs on OS X already supports
>>> invoking AppleScript. There's no GNU/Linux equivalent. Quelle horreur!
>> 
>> That's an external mode for users to install.
>
> No it isn't. Grep for ns-do-applescript.
>

To my knowledge, calling external AppleScript does not make anything
possible or easy that is not easy to do using other means (external
scripts) on GNU/Linux.

>>> Do you even care that your strategy hasn't been working?
>> 
>> Emacs has been around longer than a huge amount of software and is bound to stay for a long time and outlive most of the editors that exist today. So it's hard to demonstrate that the "strategy" is not working. In fact, as was pointed earlier in this thread, a huge lot of Emacs users use it within OSX and *not* for it's ability to display emojis...
>
> Let's talk about how keeping features out of GCC led to the total defeat
> of Clang.

Firstly, you are switching the example from Emacs to GCC simply because
it suits your argument.  What "works" in one instance might not work in
another one, of course.

More importantly, you imply that the "total defeat of Clang" is the goal
of the GNU project and GCC in particular (presumably, something along
those lines is what you mean when you say a strategy "works" or does not
"work").  I do not speak for the project or for anybody else, but if you
read up on just the few most fundamental essays on/of the free software
movement, it should become very clear that this is completely besides
the point (and would be more closely in line with the "open source"
point of view).

Re: Emacs Mac port

[Bozhidar Batsov]

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

I feel this discussion went in the wrong direction. Let's just focus on how
much of the Emacs Mac port can we merge into GNU Emacs. It's clear at this
point we can't get all the functionality in, but I'd still take every
improvement that I can.

On 1 January 2016 at 17:01, Ingo Lohmar <i.lohmar@gmail.com> wrote:

> On Thu, Dec 31 2015 23:47 (-0800), Daniel Colascione wrote:
>
> > On 12/31/2015 11:36 PM, Jean-Christophe Helary wrote:
> >>
> >>> On Jan 1, 2016, at 15:54, Daniel Colascione <dancol@dancol.org> wrote:
> >>>
> >>> I probably shouldn't point this out, but Emacs on OS X already supports
> >>> invoking AppleScript. There's no GNU/Linux equivalent. Quelle horreur!
> >>
> >> That's an external mode for users to install.
> >
> > No it isn't. Grep for ns-do-applescript.
> >
>
> To my knowledge, calling external AppleScript does not make anything
> possible or easy that is not easy to do using other means (external
> scripts) on GNU/Linux.
>
> >>> Do you even care that your strategy hasn't been working?
> >>
> >> Emacs has been around longer than a huge amount of software and is
> bound to stay for a long time and outlive most of the editors that exist
> today. So it's hard to demonstrate that the "strategy" is not working. In
> fact, as was pointed earlier in this thread, a huge lot of Emacs users use
> it within OSX and *not* for it's ability to display emojis...
> >
> > Let's talk about how keeping features out of GCC led to the total defeat
> > of Clang.
>
> Firstly, you are switching the example from Emacs to GCC simply because
> it suits your argument.  What "works" in one instance might not work in
> another one, of course.
>
> More importantly, you imply that the "total defeat of Clang" is the goal
> of the GNU project and GCC in particular (presumably, something along
> those lines is what you mean when you say a strategy "works" or does not
> "work").  I do not speak for the project or for anybody else, but if you
> read up on just the few most fundamental essays on/of the free software
> movement, it should become very clear that this is completely besides
> the point (and would be more closely in line with the "open source"
> point of view).
>
>

[-- Attachment #2: Type: text/html, Size: 2899 bytes --]

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 1 Jan 2016 19:35:17 +0000, Bozhidar Batsov <bozhidar@batsov.com> said:

> I feel this discussion went in the wrong direction. Let's just focus
> on how much of the Emacs Mac port can we merge into GNU Emacs. It's
> clear at this point we can't get all the functionality in, but I'd
> still take every improvement that I can.

I'd rather like to avoid having/maintaining multiple versions of the
Mac port, because that doesn't look better than the present situation.
Currently I feel inclined to keep it separated from the standard
distribution.

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

Re: Emacs Mac port

[John Wiegley]

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

> I'd rather like to avoid having/maintaining multiple versions of the Mac
> port, because that doesn't look better than the present situation. Currently
> I feel inclined to keep it separated from the standard distribution.

Unless I misunderstand, right now you are maintaining a patch. If we merge
most of your work (though apparently not all), doesn't this just meant that
the size of the patch you maintain becomes much smaller? I'd think that no
matter what, this is a win for any fork maintainer.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 02 Jan 2016 14:21:00 -0800, John Wiegley <jwiegley@gmail.com> said:
>> I'd rather like to avoid having/maintaining multiple versions of
>> the Mac port, because that doesn't look better than the present
>> situation. Currently I feel inclined to keep it separated from the
>> standard distribution.

> Unless I misunderstand, right now you are maintaining a patch. If we
> merge most of your work (though apparently not all), doesn't this
> just meant that the size of the patch you maintain becomes much
> smaller? I'd think that no matter what, this is a win for any fork
> maintainer.

The size of the patch is not an issue; actually, the Mac specific
files are currently distributed as raw files rather than in the patch
form.  Also, most of the port-independent part has already been
committed to the emacs-25 branch.

Maintaining a single version is much simpler especially when it comes
to processing bug reports, reproducing them, and trying fix
candidates.

If there were no alternative for Mac-native GUI ports, or there is a
consensus that it is not good enough, then it would be meaningful to
have an FSF-policy compliant version as well as a full-feature version
despite the maintenance burden.  But that is not the case.

I don't think it is a good idea to have a restricted version of the
Mac port whereas the developer is not willing to provide it and most
of the current Mac port users would skip it preferring the
full-feature version.

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

Re: Emacs Mac port

[Bozhidar Batsov]

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

On 3 January 2016 at 07:13, YAMAMOTO Mitsuharu <
mituharu@math.s.chiba-u.ac.jp> wrote:

> >>>>> On Sat, 02 Jan 2016 14:21:00 -0800, John Wiegley <jwiegley@gmail.com>
> said:
> >> I'd rather like to avoid having/maintaining multiple versions of
> >> the Mac port, because that doesn't look better than the present
> >> situation. Currently I feel inclined to keep it separated from the
> >> standard distribution.
>
> > Unless I misunderstand, right now you are maintaining a patch. If we
> > merge most of your work (though apparently not all), doesn't this
> > just meant that the size of the patch you maintain becomes much
> > smaller? I'd think that no matter what, this is a win for any fork
> > maintainer.
>
> The size of the patch is not an issue; actually, the Mac specific
> files are currently distributed as raw files rather than in the patch
> form.  Also, most of the port-independent part has already been
> committed to the emacs-25 branch.
>

What exactly has been committed to the emacs-25 branch? I recall no major
improvements to the cocoa port in Emacs 25.


>
> Maintaining a single version is much simpler especially when it comes
> to processing bug reports, reproducing them, and trying fix
> candidates.
>

I'm not sure what would change if some of the functionality was moved to
GNU Emacs. You still use it, as the basis for the Mac port and you always
support just the latest version.



>
> If there were no alternative for Mac-native GUI ports, or there is a
> consensus that it is not good enough, then it would be meaningful to
> have an FSF-policy compliant version as well as a full-feature version
> despite the maintenance burden.  But that is not the case.
>
> I don't think it is a good idea to have a restricted version of the
> Mac port whereas the developer is not willing to provide it and most
> of the current Mac port users would skip it preferring the
> full-feature version.
>
>                                      YAMAMOTO Mitsuharu
>                                 mituharu@math.s.chiba-u.ac.jp
>
>

[-- Attachment #2: Type: text/html, Size: 3057 bytes --]

Re: Emacs Mac port

[John Wiegley]

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

>>>>> Richard Stallman <rms@gnu.org> writes:

> Above all, we need to avoid falling into thinking with the wrong values. Our
> freedom is more important than any number of features like these.

I don't even care about the features, it's losing the contributor because we
aren't willing to include their work that hurts the most in this case. Yes he
still maintains his fork, but I'd have loved to bring him more closely into
the fold. The platform he's supporting may not be free, but his work is.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 3 Jan 2016 12:36:40 +0000, Bozhidar Batsov <bozhidar@batsov.com> said:

>> The size of the patch is not an issue; actually, the Mac specific
>> files are currently distributed as raw files rather than in the
>> patch form.  Also, most of the port-independent part has already
>> been committed to the emacs-25 branch.

> What exactly has been committed to the emacs-25 branch? I recall no major
> improvements to the cocoa port in Emacs 25.

* 30f4a89..: YAMAMOTO Mitsuharu 2015-12-31 Move variables to inner loop, preparing for Mac port merge
* 6ee327d..: YAMAMOTO Mitsuharu 2015-12-31 Add handle_user_signal_hook
* 47580e0..: YAMAMOTO Mitsuharu 2015-12-31 Avoid writing to purespace
* 0588be7..: YAMAMOTO Mitsuharu 2015-12-31 Remove unused variable
* 89e7483..: YAMAMOTO Mitsuharu 2015-12-31 * configure.ac: Find libxml2 headers in Xcode SDK dir on Darwin.
* 3b95e9c..: YAMAMOTO Mitsuharu 2015-12-31 Use posix_openpt instead of openpty on Darwin

These changes have been in the Mac port for a long time.  You wouldn't
notice anything unless you try to build Emacs without the Command Line
Developer Tools.  If you noticed any visible differences, then that
means I have injected a bug.

>> Maintaining a single version is much simpler especially when it
>> comes to processing bug reports, reproducing them, and trying fix
>> candidates.

> I'm not sure what would change if some of the functionality was
> moved to GNU Emacs. You still use it, as the basis for the Mac port
> and you always support just the latest version.

Do I need to elaborate this?  When I receive a bug report, I try to
reproduce the bug on my side.  If I have two variants of the Mac port,
restricted and fully-featured, then I have to try it for both of the
variants.  As is often the case, a typical bug report lacks clear
description of versions, configurations, and concrete steps to
reproduce, so it involves trial-and-error even for a single variant.
Also, I have to make sure that a fix candidate doesn't break either of
the variants.

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

Re: Emacs Mac port

[John Wiegley]

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

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

> Do I need to elaborate this? When I receive a bug report, I try to reproduce
> the bug on my side. If I have two variants of the Mac port, restricted and
> fully-featured, then I have to try it for both of the variants.

You really only have to try it in your variant. Any of us on Mac will be
trying to reproduce it in the restricted variant. If I believe it might be
fixed in the fully-featured version, I'll try it there before notifying you
about the bug.

By moving your code into core, it should actually reduce your workload. There
will be more eyes on your bugs, others verifying reproduction steps, more
people to participate in the conversation, use of our bug tracker, etc.

Come, Yamamoto-san, join us!!

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Emacs Mac port

[Xu Xin]

On Thu, Dec 31, 2015 at 4:36 PM, Random832 <random832@fastmail.com> wrote:
> Chad Brown <yandros@gmail.com> writes:
>> In case it wasn’t clear, this code just turns on a basic OS feature that
>> is built in to MacOS. The code isn’t creating animations for emacs or
>> adding animation support to the OS.
>
> It's not clear from the description here what the animations are or when
> they are used. From a description elsewhere it sounds like it uses a
> "sliding pages" effect for switching buffers with certain mouse
> gestures? Is there anything else?
>
> Incidentally, I did find some information suggesting that GNUstep is
> planning work and/or has done work on CoreAnimation.
>
> http://heronsperch.blogspot.com/2013/06/gnustep-mythbusting.html
> https://github.com/gnustep/quartzcore
>

> Does anyone here use ns-emacs on GNUstep?
Also would like to know the answer. Just for my curiousness.
>
>

- Xin

Re: Emacs Mac port

[Andrés Ramírez]

Hi Xu and Emacsers.
On Mon, 04 Jan 2016 17:31:04 -0500,
Xu Xin wrote:
> 
> On Thu, Dec 31, 2015 at 4:36 PM, Random832 <random832@fastmail.com> wrote:
> > Chad Brown <yandros@gmail.com> writes:
> >> In case it wasn’t clear, this code just turns on a basic OS feature that
> >> is built in to MacOS. The code isn’t creating animations for emacs or
> >> adding animation support to the OS.
> >
> > It's not clear from the description here what the animations are or when
> > they are used. From a description elsewhere it sounds like it uses a
> > "sliding pages" effect for switching buffers with certain mouse
> > gestures? Is there anything else?
> >
> > Incidentally, I did find some information suggesting that GNUstep is
> > planning work and/or has done work on CoreAnimation.
> >
> > http://heronsperch.blogspot.com/2013/06/gnustep-mythbusting.html
> > https://github.com/gnustep/quartzcore
> >
> 
> > Does anyone here use ns-emacs on GNUstep?
> Also would like to know the answer. Just for my curiousness.

In the past. I have tried it on GNU/Linux with window maker
https://wiki.archlinux.org/index.php/Window_Maker

In my opinion, Some people from the Darwin side should try it on
GNU/Linux. It needs a lot of customization on GNU/Linux, for some old
images see (this bug was closed by Jan, and calendar did render perfectly):
https://lists.gnu.org/archive/html/emacs-devel/2014-07/msg00190.html

Jan  Djärv should have a better opinion than me. About this.

Before this experience. I had the idea than was not possible to run
ns-port on GNU/Linux. For improving It. It need more users (manpower).

Best Regards
ps: I am going to try to compile again and see how it renders now.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 03 Jan 2016 16:42:23 -0800, John Wiegley <jwiegley@gmail.com> said:

>> Do I need to elaborate this? When I receive a bug report, I try to
>> reproduce the bug on my side. If I have two variants of the Mac
>> port, restricted and fully-featured, then I have to try it for both
>> of the variants.

> You really only have to try it in your variant. Any of us on Mac
> will be trying to reproduce it in the restricted variant. If I
> believe it might be fixed in the fully-featured version, I'll try it
> there before notifying you about the bug.

> By moving your code into core, it should actually reduce your
> workload. There will be more eyes on your bugs, others verifying
> reproduction steps, more people to participate in the conversation,
> use of our bug tracker, etc.

> Come, Yamamoto-san, join us!!

I've been subscribing to the bug-gnu-emacs list, and occasionally try
to reproduce the reported NS port bugs on the Mac port, in case they
are common to OS X or Cocoa (e.g., bug#21573).  In a sense, I've
already been joining.

I really appreciate your encouragement, but I'm skeptical about
reduction of my workload by others' cooperation from my experience
with the Carbon port in Emacs 22 and the situation involving the NS
port especially with respect to GNUstep.

Also, frankly, I feel uncomfortable with aligning the current default
modifier key setting of the Mac port (Command -> Meta, Option ->
"compose") to that of the NS port (Command -> Super (emulating Mac
shortcut), Option -> Meta), which I don't think is a good default
especially for those who are using a keyboard that cannot enter all of
the ASCII characters without the option key.

I'd like to hear what others think.  Do you want to have a restricted
version of the Mac port in the mainline?  Will you use it in
preference to the full-feature version distributed separately (e.g.,
via another git repository)?

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

Re: Emacs Mac port

[Chad Brown]

> On 04 Jan 2016, at 17:00, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:
> 
> I'd like to hear what others think.  Do you want to have a restricted
> version of the Mac port in the mainline?  Will you use it in
> preference to the full-feature version distributed separately (e.g.,
> via another git repository)?

Speaking for myself: I do not use any form of the Mac port, but
instead use the NS port (under Mac OSX), because I want to track
the mainline (or the release candidate when such exists). From
what I’ve seen, there are things in the Mac port that I would
like to have (e.g. with regards to select), but I forgo in order
to help (minimally) emacs development.

Thanks,
~Chad

Re: Emacs Mac port

[John Wiegley]

>>>>> Chad Brown <yandros@gmail.com> writes:

> Speaking for myself: I do not use any form of the Mac port, but instead use
> the NS port (under Mac OSX), because I want to track the mainline (or the
> release candidate when such exists). From what I’ve seen, there are things
> in the Mac port that I would like to have (e.g. with regards to select), but
> I forgo in order to help (minimally) emacs development.

Thanks, Chad, this highlights a reason beyond the personal why I'd like Mac
Port in the main-line: I recommend it every Mac user I know, but many are not
willing to go through the extra effort of patching their sources to build it.
Instead, they download binaries from emacsformacosx.com, and never get to
experience how nice Emacs can be on OS X.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Emacs Mac port

[Martin Yrjölä]

Hi Chad and Yamamoto.

Chad Brown <yandros@gmail.com> writes:

>> On 04 Jan 2016, at 17:00, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:
>> 
>> I'd like to hear what others think.  Do you want to have a restricted
>> version of the Mac port in the mainline?  Will you use it in
>> preference to the full-feature version distributed separately (e.g.,
>> via another git repository)?
>
> Speaking for myself: I do not use any form of the Mac port, but
> instead use the NS port (under Mac OSX), because I want to track
> the mainline (or the release candidate when such exists). From
> what I’ve seen, there are things in the Mac port that I would
> like to have (e.g. with regards to select), but I forgo in order
> to help (minimally) emacs development.
>
> Thanks,
> ~Chad

I'm in the same boat. I want to track the mainline and maybe get into
Emacs development, but I'm missing many of the Mac port's excellent
features, especially the improved integration with OS X. Even having a
restricted version merged to mainline would make me happier. However, I
hope that everything could be merged some time in the future, when we
figure out a way to support the same features on Linux.

I'm wondering what this merge would mean to the NS port? Is the NS port
made obsolete by the Mac port? I think it would be less effort to
maintain a single port for OS X.

Best regards,
Martin Yrjölä

Re: Emacs Mac port

[João Távora]

On Tue, Jan 5, 2016 at 1:00 AM, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
> I'd like to hear what others think.  Do you want to have a restricted
> version of the Mac port in the mainline?  Will you use it in
> preference to the full-feature version distributed separately (e.g.,
> via another git repository)?

Yes!

Mostly due to the fact that, while the mac port's features are super-nice,
I want to develop in emacs's trunk, and so I almost always decide to
use the normal nextstep  build.

I miss a lot of the mac port's features there... But I don't use it anymore.

To be honest, I haven't looked if there's a way to "git merge" the tip of
the mac port with the tip of trunk for to do development while having nice
mac-port features for doing that development.

João

Re: Emacs Mac port

[Paul Michael Reilly]

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

I'll add my voice to the emerging crescendo, I want to build and run the
mac port out of the mainline sources but I do not want to deal with patch
files.  I crave smooth scrolling and to learn what other gems are in the
mac ports version.  I also echo the sentiment that I hate, hate, hate the
notion of mucking up the command and option keys.  I want someone walking
up to my keyboard to get pretty close to normal key behavior from the
command key if it happens that I am in Emacs at the time, which is pretty
much always the case.  Please Yamamoto-san, join the fray and help solve
your issues for both yourself and those of us who so admire and respect
your work, but just don't have the bandwidth to live in multiple Emacs
worlds.

On Tue, Jan 5, 2016 at 7:38 AM João Távora <joaotavora@gmail.com> wrote:

> On Tue, Jan 5, 2016 at 1:00 AM, YAMAMOTO Mitsuharu
> <mituharu@math.s.chiba-u.ac.jp> wrote:
> > I'd like to hear what others think.  Do you want to have a restricted
> > version of the Mac port in the mainline?  Will you use it in
> > preference to the full-feature version distributed separately (e.g.,
> > via another git repository)?
>
> Yes!
>
> Mostly due to the fact that, while the mac port's features are super-nice,
> I want to develop in emacs's trunk, and so I almost always decide to
> use the normal nextstep  build.
>
> I miss a lot of the mac port's features there... But I don't use it
> anymore.
>
> To be honest, I haven't looked if there's a way to "git merge" the tip of
> the mac port with the tip of trunk for to do development while having nice
> mac-port features for doing that development.
>
> João
>
> --
-pmr

[-- Attachment #2: Type: text/html, Size: 2143 bytes --]

Re: Emacs Mac port

[Alan Schmitt]

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

On 2016-01-04 20:53, John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Chad Brown <yandros@gmail.com> writes:
>
>> Speaking for myself: I do not use any form of the Mac port, but instead use
>> the NS port (under Mac OSX), because I want to track the mainline (or the
>> release candidate when such exists). From what I’ve seen, there are things
>> in the Mac port that I would like to have (e.g. with regards to select), but
>> I forgo in order to help (minimally) emacs development.
>
> Thanks, Chad, this highlights a reason beyond the personal why I'd like Mac
> Port in the main-line: I recommend it every Mac user I know, but many are not
> willing to go through the extra effort of patching their sources to build it.
> Instead, they download binaries from emacsformacosx.com, and never get to
> experience how nice Emacs can be on OS X.

Building it with homebrew is fairly simple:
https://github.com/railwaycat/homebrew-emacsmacport

Best,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated December 28, 2015, Mauna Loa Obs.): 402.60 ppm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The ninth update of the Mac port based on Emacs 24.5 is available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.16.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

A bare development branch (no documentation updates yet) based on the
pretest versions of Emacs 25.1 is also available from the "work"
branch of the above repository.


** Fixed bugs

*** M-x tool-bar-mode RET for a fullheight/maximized frame fails on
its first invocation.

*** Wrong size calculations for 2x genuine imagemagick images.  For
example, (image-size (create-image "splash.png" 'imagemagick nil
:max-height 300)) is larger than the one without the :max-height
property if the frame is on a Retina display.

** Improvements

*** For frames on a Retina display, image-io/imagemagick image
descriptors involving non-integral transformations such as shrinking
or rotation are now processed with 2x pixel buffer even if the source
image file/data is for 1x.  For example, (insert-image (create-image
"gnus/gnus.png" 'imagemagick nil :max-height 100)) now looks crisper.

*** Org mode LaTeX fragments preview may also create 2x images.


The patch below is a quick hack (see the "XXX" comment below) for PDF
Tools to display 2x images on Retina display.

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

diff --git a/lisp/pdf-annot.el b/lisp/pdf-annot.el
index 32cb237..bb63a71 100644
--- a/lisp/pdf-annot.el
+++ b/lisp/pdf-annot.el
@@ -921,6 +921,7 @@ other annotations."
                (pdf-cache-renderpage-highlight
                 page (car size)
                 `("white" "steel blue" 0.35 ,@edges))
+	     :width (car size)
              :map (pdf-view-apply-hotspot-functions
                    window page size))))
         (pdf-util-scroll-to-edges
diff --git a/lisp/pdf-info.el b/lisp/pdf-info.el
index 6a5edb8..62da214 100644
--- a/lisp/pdf-info.el
+++ b/lisp/pdf-info.el
@@ -1514,7 +1514,15 @@ Return the data of the corresponding PNG image."
     'renderpage
     (pdf-info--normalize-file-or-buffer file-or-buffer)
     page
-    width
+    (* width
+       ;; XXX This does not give optimal results when you have both
+       ;; Retina and non-Retina displays connected.  For true
+       ;; high-resolution support, one should use either TIFF, "@2x"
+       ;; convention, or resolution-independent formats such as PDF.
+       (or (and (memq (pdf-view-image-type) '(imagemagick image-io))
+		(fboundp 'frame-monitor-attributes)
+		(cdr (assq 'backing-scale-factor (frame-monitor-attributes))))
+	   1))
     (let (transformed)
       (while (cdr commands)
         (let ((kw (pop commands))
diff --git a/lisp/pdf-isearch.el b/lisp/pdf-isearch.el
index bffbd3b..674d295 100644
--- a/lisp/pdf-isearch.el
+++ b/lisp/pdf-isearch.el
@@ -728,7 +728,7 @@ MATCH-BG LAZY-FG LAZY-BG\)."
                                  occur-hack-p)
                              (eq page (pdf-view-current-page)))
                     (pdf-view-display-image
-                     (pdf-view-create-image data))))))))
+                     (pdf-view-create-image data :width width))))))))
       (pdf-info-renderpage-text-regions
        page width t nil
        `(,fg1 ,bg1 ,@(pdf-util-scale-pixel-to-relative
diff --git a/lisp/pdf-view.el b/lisp/pdf-view.el
index 555032e..406ab98 100644
--- a/lisp/pdf-view.el
+++ b/lisp/pdf-view.el
@@ -725,7 +725,7 @@ See also `pdf-view-set-slice-from-bounding-box'."
   "Return the image-type which should be used.
 
 The return value is either imagemagick (if available and wanted
-or if png is not available) or png.
+or if png is not available), image-io (on the Mac port), or png.
 
 Signal an error, if neither imagemagick nor png is available.
 
@@ -733,6 +733,8 @@ See also `pdf-view-use-imagemagick'."
   (cond ((and pdf-view-use-imagemagick
               (fboundp 'imagemagick-types))
          'imagemagick)
+        ((image-type-available-p 'image-io)
+         'image-io)
         ((image-type-available-p 'png)
          'png)
         ((fboundp 'imagemagick-types)
@@ -741,8 +743,8 @@ See also `pdf-view-use-imagemagick'."
          (error "PNG image supported not compiled into Emacs"))))
 
 (defun pdf-view-use-scaling-p ()
-  (and (eq 'imagemagick
-           (pdf-view-image-type))
+  (and (memq (pdf-view-image-type)
+	     '(imagemagick image-io))
        pdf-view-use-scaling))
 
 (defmacro pdf-view-create-image (data &rest props)
@@ -1195,7 +1197,8 @@ This is more useful for commands like
               `(,(car colors) ,(cdr colors) 0.35 ,@region))
            (pdf-info-renderpage-text-regions
             page width nil nil
-            `(,(car colors) ,(cdr colors) ,@region)))))))
+            `(,(car colors) ,(cdr colors) ,@region)))
+       :width width))))
     
 (defun pdf-view-kill-ring-save ()
   "Copy the region to the `kill-ring'."

Re: Emacs Mac port

[Angelo Graziosi]

YAMAMOTO Mitsuharu wrote:
> The ninth update of the Mac port based on Emacs 24.5 is available from
>
>   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.16.tar.gz
>
> and Git repository is also available at
>
>   https://bitbucket.org/mituharu/emacs-mac.git
>
> A bare development branch (no documentation updates yet) based on the
> pretest versions of Emacs 25.1 is also available from the "work"
> branch of the above repository.

If I understand, the Mac port build, by default, installs things both in 
Emacs.app and in /usr/local.

How can we setup the build so all things go in Emacs.app (so that we can 
move all the Emacs.app tree in /Applications or /opt)?

I see that MacPorts people do this manually 
(https://trac.macports.org/browser/trunk/dports/aqua/emacs-mac-app/Portfile) 
instead it would be useful that we can have a choice.

Maybe Mac port build needs a mac/INSTALL.MAC


  Angelo

Re: Emacs Mac port

[Angelo Graziosi]

BTW, I downloaded

https://bitbucket.org/mituharu/emacs-mac/get/master.tar.gz

and build it. I find "make install" puts things in

share/emacs/24.5/...

But is it to be expected a '24.5' version number for master?

On GNU/Linux and Windows I find '25.1.50', which I think is the right 
value..


  Angelo


Il 23/04/2016 15:03, Angelo Graziosi ha scritto:
> YAMAMOTO Mitsuharu wrote:
>> The ninth update of the Mac port based on Emacs 24.5 is available from
>>
>>   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.16.tar.gz
>>
>> and Git repository is also available at
>>
>>   https://bitbucket.org/mituharu/emacs-mac.git
>>
>> A bare development branch (no documentation updates yet) based on the
>> pretest versions of Emacs 25.1 is also available from the "work"
>> branch of the above repository.
>
> If I understand, the Mac port build, by default, installs things both in
> Emacs.app and in /usr/local.
>
> How can we setup the build so all things go in Emacs.app (so that we can
> move all the Emacs.app tree in /Applications or /opt)?
>
> I see that MacPorts people do this manually
> (https://trac.macports.org/browser/trunk/dports/aqua/emacs-mac-app/Portfile)
> instead it would be useful that we can have a choice.
>
> Maybe Mac port build needs a mac/INSTALL.MAC
>
>
>  Angelo

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 24 Apr 2016 21:40:37 +0200, Angelo Graziosi <angelo.graziosi@alice.it> said:

> BTW, I downloaded
> https://bitbucket.org/mituharu/emacs-mac/get/master.tar.gz

> and build it. I find "make install" puts things in

> share/emacs/24.5/...

> But is it to be expected a '24.5' version number for master?

Yes.  The master branch of the emacs-mac repository is for (the latest
major) release versions.

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 23 Apr 2016 08:51:45 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> The ninth update of the Mac port based on Emacs 24.5 is available from
>   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.16.tar.gz

This release was mainly intended for enhancement on Retina display
environments, but actually there was a nasty bug in that part when the
Mac port was compiled with ImageMagick.  I've just made another
release:

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.17.tar.gz

The only changed file is `patch-mac'.  So, if you still have a build
tree, then you can just unapply the `patch-mac' file in the previous
version and apply the new one.  Sorry for the inconvenience.

> and Git repository is also available at

>   https://bitbucket.org/mituharu/emacs-mac.git

> A bare development branch (no documentation updates yet) based on the
> pretest versions of Emacs 25.1 is also available from the "work"
> branch of the above repository.

** Fixed bugs

*** Shrunken image size on a Retina display is wrong if it is created
from the raw data using genuine ImageMagick.
Reported by Sean Farley.

** Improvements

*** When you create an image from the raw data as opposed to a file,
you can now provide 2x data for high-resolution environments via the
`:data-2x' property.  It can be specified either as a property of the
image descriptor or as a text property of the first character of the
standard resolution data (if it is given as a string).


> The patch below is a quick hack (see the "XXX" comment below) for PDF
> Tools to display 2x images on Retina display.

Also, I made the patch below for preview-latex in AUCTeX so preview
images look fine on Retina displays.  It now makes Ghostscript
generate PDF files instead of PNG ones, and let the Mac port render
them using the `image-io' image type via PDFKit.  So moving a frame
between Retina and non-Retina displays works gracefully unlike my
previous patch for PDF Tools.

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

diff --git a/preview.el.in b/preview.el.in
index 8a58104..48f0608 100644
--- a/preview.el.in
+++ b/preview.el.in
@@ -188,7 +188,10 @@ spec to avoid unnecessary evaluation time."
 	  (close preview-gs-close))
     (tiff (open preview-gs-open)
 	  (place preview-gs-place)
-	  (close preview-gs-close)))
+	  (close preview-gs-close))
+    (image-io (open preview-gs-open)
+	      (place preview-gs-place)
+	      (close preview-gs-close)))
   "Define functions for generating images.
 These functions get called in the process of generating inline
 images of the specified type.  The open function is called
@@ -218,17 +221,23 @@ function args" :inline t sexp))
     (dvipng png "-sDEVICE=png16m")
     (jpeg jpeg "-sDEVICE=jpeg")
     (pnm pbm "-sDEVICE=pnmraw")
-    (tiff tiff "-sDEVICE=tiff12nc"))
+    (tiff tiff "-sDEVICE=tiff12nc")
+    (image-io (image-io pdf t) "-sDEVICE=pdfwrite"))
   "*Alist of image types and corresponding Ghostscript options.
 The `dvipng' and `postscript' (don't use) entries really specify
 a fallback device when images can't be processed by the requested
 method, like when PDFTeX was used."
   :group 'preview-gs
   :type '(repeat (list :tag nil (symbol :tag "preview image-type")
-		       (symbol :tag "Emacs image-type")
+		       (choice (symbol :tag "Emacs image-type")
+			       (list :tag "Extended setting"
+				     (symbol :tag "Emacs image-type")
+				     (symbol :tag "File name extension")
+				     (boolean :tag "Produces vector output")))
 		       (repeat :inline t :tag "Ghostscript options" string))))
 
-(defcustom preview-image-type 'png
+(defcustom preview-image-type
+  (if (preview-supports-image-type 'image-io) 'image-io 'png)
   "*Image type to be used in images."
   :group 'preview-gs
   :type (append '(choice)
@@ -372,6 +381,13 @@ See also `preview-gs-command'."
   :group 'preview-gs
   :type '(repeat string))
 
+(defcustom preview-gs-vector-options '("-q" "-dDELAYSAFER" "-dNOPAUSE"
+				       "-DNOPLATFONTS" "-dPrinted")
+  "*Like `preview-gs-options', but used when gs produces vector outputs.
+See also `preview-gs-command'."
+  :group 'preview-gs
+  :type '(repeat string))
+
 (defvar preview-gs-queue nil
   "List of overlays to convert using gs.
 Buffer-local to the appropriate TeX process buffer.")
@@ -406,6 +422,14 @@ follow changes in the displayed buffer area faster."
   "Image type for gs produced images.")
 (make-variable-buffer-local 'preview-gs-image-type)
 
+(defvar preview-gs-image-extension nil
+  "Image file name extension for gs produced images.")
+(make-variable-buffer-local 'preview-gs-image-extension)
+
+(defvar preview-gs-image-vector-p nil
+  "Non-nil if gs produces vector output images.")
+(make-variable-buffer-local 'preview-gs-image-vector-p)
+
 (defvar preview-gs-sequence nil
   "Pair of sequence numbers for gs produced images.")
 (make-variable-buffer-local 'preview-gs-sequence)
@@ -696,7 +720,7 @@ Gets the usual PROCESS and STRING parameters, see
 			     (format "%s/pr%d-%%d.%s"
 				     (car TeX-active-tempdir)
 				     (car preview-gs-sequence)
-				     preview-gs-image-type))))
+				     preview-gs-image-extension))))
 	   (process
 	    (apply #'start-process
 		   "Preview-Ghostscript"
@@ -726,11 +750,20 @@ Gets the usual PROCESS and STRING parameters, see
 (defun preview-gs-open (&optional setup)
   "Start a Ghostscript conversion pass.
 SETUP may contain a parser setup function."
-  (let ((image-info (assq preview-image-type preview-gs-image-type-alist)))
-    (setq preview-gs-image-type (nth 1 image-info))
+  (let* ((image-info (assq preview-image-type preview-gs-image-type-alist))
+	 (image-type-info (nth 1 image-info)))
+    (if (not (consp image-type-info))
+	(setq preview-gs-image-type image-type-info
+	      preview-gs-image-extension image-type-info
+	      preview-gs-image-vector-p nil)
+      (setq preview-gs-image-type (nth 0 image-type-info)
+	    preview-gs-image-extension (nth 1 image-type-info)
+	    preview-gs-image-vector-p (nth 2 image-type-info)))
     (setq preview-gs-sequence nil)
     (setq preview-gs-command-line (append
-				   preview-gs-options
+				   (if (not preview-gs-image-vector-p)
+				       preview-gs-options
+				     preview-gs-vector-options)
 				   (nthcdr 2 image-info))
 	  preview-gs-init-string
 	  (format "{DELAYSAFER{.setsafe}if}stopped pop\
@@ -833,7 +866,7 @@ Pure borderless black-on-white will return an empty string."
     (let ((process (preview-start-dvips preview-fast-conversion)))
       (setq TeX-sentinel-function #'preview-gs-dvips-sentinel)
       (list process (current-buffer) TeX-active-tempdir preview-ps-file
-	    preview-gs-image-type))))
+	    preview-gs-image-extension))))
 
 (defun preview-dvipng-process-setup ()
   "Set up dvipng process for conversion."
@@ -861,7 +894,7 @@ Pure borderless black-on-white will return an empty string."
   (let ((process (preview-start-pdf2dsc)))
     (setq TeX-sentinel-function #'preview-pdf2dsc-sentinel)
     (list process (current-buffer) TeX-active-tempdir preview-ps-file
-	  preview-gs-image-type)))
+	  preview-gs-image-extension)))
 
 (defun preview-dvips-abort ()
   "Abort a Dvips run."
@@ -1248,11 +1281,13 @@ given as ANSWER."
 	      (overlay-put ov 'filenames (cdr filenames))
 	      (preview-replace-active-icon
 	       ov
-	       (preview-create-icon (car newfile)
-				    preview-gs-image-type
-				    (preview-ascent-from-bb
-				     bbox)
-				    (aref preview-colors 2))))
+	       (apply #'preview-create-icon
+		      (car newfile)
+		      preview-gs-image-type
+		      (preview-ascent-from-bb bbox)
+		      (aref preview-colors 2)
+		      (and preview-gs-image-vector-p
+			   (list (preview-size-from-bb bbox))))))
 	    (overlay-put ov 'queued nil)))))
     (while (and (< (length preview-gs-outstanding)
 		   preview-gs-outstanding-limit)
@@ -1269,7 +1304,7 @@ given as ANSWER."
 					     (format "pr%d-%d.%s"
 						     (car preview-gs-sequence)
 						     (cdr preview-gs-sequence)
-						     preview-gs-image-type)
+						     preview-gs-image-extension)
 					     TeX-active-tempdir))))))
 		 (bbox (aset queued 0
 			     (or (and preview-prefer-TeX-bb
@@ -1459,6 +1494,24 @@ numbers (can be float if available)."
 	(round (* 100.0 (/ (- top 720.0) (- top bottom))))
       100)))
 
+(defun preview-size-from-bb (bb)
+  "This calculates the image pixel size from its bounding box.
+When the ghostscript device produces vector outputs, the `-r'
+option does not change the page size of the produced output, but
+specifies the resolution for pattern fills and fonts that must be
+converted to bitmaps.  This function is used for calculating the
+size in pixels from the value passed to the `-r' option and the
+given bounding box."
+  (let ((res '(72.0 . 72.0)))
+    (dolist (option preview-gs-command-line)
+      (if (string-match "\\`-r\\([0-9.]+\\)x\\([0-9.]+\\)\\'" option)
+	  (setq res (cons (string-to-number (match-string 1 option))
+			  (string-to-number (match-string 2 option))))))
+    (cons (round (* (- (aref bb 2) (aref bb 0))
+		    (/ (car res) 72.0)))
+	  (round (* (- (aref bb 3) (aref bb 1))
+		    (/ (cdr res) 72.0))))))
+
 (defface preview-face '((((background dark))
 			 (:background "dark slate gray"))
 			(t
@@ -3556,6 +3609,7 @@ If not a regular release, the date of the last change.")
        preview-pdf2dsc-command
        preview-gs-command
        preview-gs-options
+       preview-gs-vector-options
        preview-gs-image-type-alist
        preview-fast-conversion
        preview-prefer-TeX-bb
diff --git a/prv-emacs.el b/prv-emacs.el
index 9f40736..07c4018 100644
--- a/prv-emacs.el
+++ b/prv-emacs.el
@@ -80,19 +80,20 @@ Consults `preview-transparent-color'."
 			  (nth 1 preview-transparent-color)
 			  'default)))))
 
-(defsubst preview-create-icon-1 (file type ascent border)
+(defsubst preview-create-icon-1 (file type ascent border &optional size)
   `(image
     :file ,file
     :type ,type
     :ascent ,ascent
     ,@(and border
-	   '(:mask (heuristic t)))))
+	   '(:mask (heuristic t)))
+    ,@(and size
+	   `(:width ,(car size) :height ,(cdr size)))))
 
-(defun preview-create-icon (file type ascent border)
+(defun preview-create-icon (file type ascent border &optional size)
   "Create an icon from FILE, image TYPE, ASCENT and BORDER."
-  (list
-   (preview-create-icon-1 file type ascent border)
-   file type ascent border))
+  `(,(preview-create-icon-1 file type ascent border size)
+    ,file ,type ,ascent ,border ,@(and size (list size))))
 
 (put 'preview-filter-specs :type
      #'(lambda (keyword value &rest args)
@@ -590,7 +591,8 @@ The fourth value is the transparent border thickness."
 				(nth 2 image)
 				(if (< (length image) 4)
 				    (preview-get-heuristic-mask)
-				  (nth 3 image))))))
+				  (nth 3 image))
+				(nth 4 image)))))
 
 (defsubst preview-supports-image-type (imagetype)
   "Check if IMAGETYPE is supported."

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 30 Apr 2016 14:57:54 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>> The patch below is a quick hack (see the "XXX" comment below) for
>> PDF Tools to display 2x images on Retina display.

> Also, I made the patch below for preview-latex in AUCTeX so preview
> images look fine on Retina displays.  It now makes Ghostscript
> generate PDF files instead of PNG ones, and let the Mac port render
> them using the `image-io' image type via PDFKit.  So moving a frame
> between Retina and non-Retina displays works gracefully unlike my
> previous patch for PDF Tools.

Another merit of this approach over creation of doubled bitmap images
is it can take advantage of LCD smoothing (I've just noticed that).
So this might be meaningful even on non-Retina environments (unless
you hate LCD smoothing).

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The eleventh update of the Mac port based on Emacs 24.5 is available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.18.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

If you are using the Mac port on OS X 10.11 and find it less
responsive than the NS port, then please try this version.  Some
behavior on window flushing has been changed between OS X 10.10 and
10.11.  The NS port straightforwardly benefited from this change, but
some workarounds in the Mac port for older versions of OS X prevented
the change from taking effect (it actually gives a reverse effect).

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

** Fixed bugs

*** On OS X 10.11, the result of Typometer is much worse than that on
the NS port, although better than the both ports on OS X 10.10.  This
is because the Mac port manually defers and coalesces screen flushes
in order to work around slow flyspell.  This seems to be unnecessary
on OS X 10.11, and actually gives a reverse effect as above.

** Improvements

*** Emoji data is updated to Unicode 9.0.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 25.1 release candidate 1 is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-25.1-rc1-mac-5.90.tar.gz
  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-hires-icons-2.0.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

Get it from the "master" branch.  The "work" branch is for bare
development and not for release (candidate) versions.

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

** Fixed bugs

*** Crash when closing a fullscreen frame on macOS 10.12 Beta.

*** Can't resize a frame by dragging its edge on macOS 10.12 Beta.

*** Cyrillic text composition in HELLO file is shown wrong with Menlo.

** Improvements

*** New functions `mac-export-frames', `mac-page-setup-dialog',
`mac-get-page-setup', and `mac-print-frames-dialog'.  They correspond
to x-* functions provided in the cairo build together with GTK+.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 25.1 release candidate 2 is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-25.1-rc2-mac-5.91.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

Get it from the "master" branch.  The "work" branch is for bare
development and not for release (candidate) versions.

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

** Improvements

*** Update emoji sequence data to version 4.0 draft.

Re: Emacs Mac port

[Marius Kjeldahl]

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

Thanks, did a quick test and seems to work fine as usual. One noticeable
difference is that in your build, the fonts are weighted heavier. On my
iMac5K, your version looks bold compared to the regular version. I've
posted a link to screenshots below, although it's less visible in a
compressed image than on my actual screen.

https://snag.gy/aiqFch.jpg

Anyways, thanks!

Marius K.

On Mon, 22 Aug 2016 at 02:38 YAMAMOTO Mitsuharu <
mituharu@math.s.chiba-u.ac.jp> wrote:

> The Mac port based on Emacs 25.1 release candidate 2 is now available from
>
>   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-25.1-rc2-mac-5.91.tar.gz
>
> and Git repository is also available at
>
>   https://bitbucket.org/mituharu/emacs-mac.git
>
> Get it from the "master" branch.  The "work" branch is for bare
> development and not for release (candidate) versions.
>
>                                      YAMAMOTO Mitsuharu
>                                 mituharu@math.s.chiba-u.ac.jp
>
> ** Improvements
>
> *** Update emoji sequence data to version 4.0 draft.
>
>

[-- Attachment #2: Type: text/html, Size: 1815 bytes --]

Re: Emacs Mac port

[Marius Kjeldahl]

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

Following up on my own post, I now noticed that there was a setting in my
.emacs file that selected the bold weighting. Why "stock" Emacs did not
respect that setting and this "Mac port" did I have no idea. Changed the
default weight to normal and now both versions have identical fonts. A
curious mind might want to know why the "stock" Emacs OSX build does not
respect the bold weight. The specific setting from my .emacs is:

(custom-set-faces
 ;; custom-set-faces was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(default ((t (:stipple nil :inverse-video nil :box nil :strike-through
nil :overline nil :underline nil :slant normal :weight normal :height 120
:width normal :family "Andale Mono")))))

Thanks,

Marius K.

On Mon, 22 Aug 2016 at 09:31 Marius Kjeldahl <marius.kjeldahl@gmail.com>
wrote:

> Thanks, did a quick test and seems to work fine as usual. One noticeable
> difference is that in your build, the fonts are weighted heavier. On my
> iMac5K, your version looks bold compared to the regular version. I've
> posted a link to screenshots below, although it's less visible in a
> compressed image than on my actual screen.
>
> https://snag.gy/aiqFch.jpg
>
> Anyways, thanks!
>
> Marius K.
>
> On Mon, 22 Aug 2016 at 02:38 YAMAMOTO Mitsuharu <
> mituharu@math.s.chiba-u.ac.jp> wrote:
>
>> The Mac port based on Emacs 25.1 release candidate 2 is now available from
>>
>>   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-25.1-rc2-mac-5.91.tar.gz
>>
>> and Git repository is also available at
>>
>>   https://bitbucket.org/mituharu/emacs-mac.git
>>
>> Get it from the "master" branch.  The "work" branch is for bare
>> development and not for release (candidate) versions.
>>
>>                                      YAMAMOTO Mitsuharu
>>                                 mituharu@math.s.chiba-u.ac.jp
>>
>> ** Improvements
>>
>> *** Update emoji sequence data to version 4.0 draft.
>>
>>

[-- Attachment #2: Type: text/html, Size: 3234 bytes --]

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 22 Aug 2016 10:41:45 +0000, Marius Kjeldahl <marius.kjeldahl@gmail.com> said:

> Following up on my own post, I now noticed that there was a setting
> in my .emacs file that selected the bold weighting. Why "stock"
> Emacs did not respect that setting and this "Mac port" did I have no
> idea. Changed the default weight to normal and now both versions
> have identical fonts. A curious mind might want to know why the
> "stock" Emacs OSX build does not respect the bold weight. The
> specific setting from my .emacs is:

Probably this is due to the following workaround only in the Mac port:

* emacs-24.4-mac-5.3 (2015-01-29)
http://lists.gnu.org/archive/html/emacs-devel/2015-01/msg01040.html

** Fixed bugs

*** Synthetic bold text looks thinner on Retina display/HiDPI mode.
This is because stroke line width for text drawing is not correctly
scaled (whereas it is correctly scaled when drawn to bitmaps) on such
environments.  I've been reporting this to Apple on every OS X update
since it was 10.7.4, but I couldn't get any response until recently.
At last Apple answers that there are no plans to address this issue
(rdar://11644870) currently.  So I added a workaround that would cause
a bad reverse effect if the original issue were fixed.

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

Re: Emacs Mac port

[Alan Third]

On 23 August 2016 at 01:07, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
>
> Probably this is due to the following workaround only in the Mac port:
>
> * emacs-24.4-mac-5.3 (2015-01-29)
> http://lists.gnu.org/archive/html/emacs-devel/2015-01/msg01040.html
>
> ** Fixed bugs
>
> *** Synthetic bold text looks thinner on Retina display/HiDPI mode.
> This is because stroke line width for text drawing is not correctly
> scaled (whereas it is correctly scaled when drawn to bitmaps) on
> such environments. I've been reporting this to Apple on every OS X
> update since it was 10.7.4, but I couldn't get any response until
> recently. At last Apple answers that there are no plans to address
> this issue (rdar://11644870) currently. So I added a workaround that
> would cause a bad reverse effect if the original issue were fixed.

Is it possible to apply this fix to the NS port or would we need to
come up with another solution?

-- 
Alan Third

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 23 Aug 2016 10:02:47 +0100, Alan Third <alan@idiocy.org> said:

> On 23 August 2016 at 01:07, YAMAMOTO Mitsuharu
> <mituharu@math.s.chiba-u.ac.jp> wrote:
>> 
>> Probably this is due to the following workaround only in the Mac port:
>> 
>> * emacs-24.4-mac-5.3 (2015-01-29)
>> http://lists.gnu.org/archive/html/emacs-devel/2015-01/msg01040.html
>> 
>> ** Fixed bugs
>> 
>> *** Synthetic bold text looks thinner on Retina display/HiDPI mode.
>> This is because stroke line width for text drawing is not correctly
>> scaled (whereas it is correctly scaled when drawn to bitmaps) on
>> such environments. I've been reporting this to Apple on every OS X
>> update since it was 10.7.4, but I couldn't get any response until
>> recently. At last Apple answers that there are no plans to address
>> this issue (rdar://11644870) currently. So I added a workaround that
>> would cause a bad reverse effect if the original issue were fixed.

> Is it possible to apply this fix to the NS port or would we need to
> come up with another solution?

The workaround is simple, but the current code uses some
Mac-port-specific variables.  So at least it cannot be applied to the
NS port directly.

	  /* Stroke line width for text drawing is not correctly
	     scaled on Retina display/HiDPI mode when drawn to screen
	     (whereas it is correctly scaled when drawn to bitmaps),
	     and synthetic bold looks thinner on such environments.
	     Apple says there are no plans to address this issue
	     (rdar://11644870) currently.  So we add a workaround.  */
	  if (FRAME_BACKING_SCALE_FACTOR (f) != 1
	      && !FRAME_SYNTHETIC_BOLD_WORKAROUND_DISABLED_P (f)
	      && (mac_operating_system_version.minor >= 7
		  || mac_operating_system_version.major > 10))
	    bold_factor = synthetic_bold_factor * 2;
	  else
	    bold_factor = synthetic_bold_factor;

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 25.1 is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-25.1-mac-6.0.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

The twelfth update of the Mac port based on Emacs 24.5, containing
changes for upcoming macOS 10.12, is also available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.19.tar.gz

The corresponding branch in the Git repository is `mac-24'.  The old
repository URL is now forwarded to the Bitbucket one.

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

** Fixed bugs

*** Several glitches in frame tabbing on macOS 10.12.
To address this issue in a simple and consistent way, we now round the
frame size according to the character size only on resize by mouse
dragging or changes of the `fullscreen' frame parameter.  This may
cause some incompatibility.

*** Fullscreen frames contain space at the top on OS X 10.10.

** Improvements

*** New variable `mac-frame-tabbing' specifying tabbing behavior of a
frame that is becoming visible on macOS 10.12.

*** C-x 5 5 ... behaves like the C-x 5 prefix, but temporarily changes
tabbing behavior if "5" is typed repeatedly on macOS 10.12.

Re: Emacs Mac port

[martin rudalics]

 > ... we now round the
 > frame size according to the character size only on resize by mouse
 > dragging or changes of the `fullscreen' frame parameter.

Can you kindly explain what this means?  IMHO the behavior should be
such as to

- not round when mouse dragging or changing the `fullscreen' parameter

- round otherwise (if requested).

I don't know whether you implemented `frame-resize-pixelwise'.

martin

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 18 Sep 2016 09:32:22 +0200, martin rudalics <rudalics@gmx.at> said:

>> ... we now round the
>> frame size according to the character size only on resize by mouse
>> dragging or changes of the `fullscreen' frame parameter.

> Can you kindly explain what this means?  IMHO the behavior should be
> such as to

> - not round when mouse dragging or changing the `fullscreen' parameter

> - round otherwise (if requested).

> I don't know whether you implemented `frame-resize-pixelwise'.

The change I described was about the case that the variable
`frame-resize-pixelwise' is nil.  If it is t, then the rounding never
occurs.

When `frame-resize-pixelwise' is nil, the previous versions of the Mac
port always respected the window size hints and did rounding.  But
this appears to interfere with "automatic window tabbing" introduced
in macOS 10.12, so I restricted the cases where the size hints is
respected.

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

Re: Emacs Mac port

[martin rudalics]

 > When `frame-resize-pixelwise' is nil, the previous versions of the Mac
 > port always respected the window size hints and did rounding.  But
 > this appears to interfere with "automatic window tabbing" introduced
 > in macOS 10.12, so I restricted the cases where the size hints is
 > respected.

I must be still missing something: Originally you said that

   "we now round the frame size according to the character size only on
   resize by mouse dragging or changes of the `fullscreen' frame
   parameter"

which doesn't make sense to me: Rounding on resize by mouse dragging
doesn't seem reasonable to me because the frame edge will not follow the
mouse pointer but rather jump instead.  Rounding when maximizing or
making a fullscreen frame, however, is much worse because it may leave a
maximized or fullscreen frame with empty space at anedge of the screen.

So I'm curious whether your description above just inverts the meaning
of what you actually do.

martin

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 18 Sep 2016 10:15:47 +0200, martin rudalics <rudalics@gmx.at> said:

>> When `frame-resize-pixelwise' is nil, the previous versions of the Mac
>> port always respected the window size hints and did rounding.  But
>> this appears to interfere with "automatic window tabbing" introduced
>> in macOS 10.12, so I restricted the cases where the size hints is
>> respected.

> I must be still missing something: Originally you said that

>    "we now round the frame size according to the character size only on
>    resize by mouse dragging or changes of the `fullscreen' frame
>    parameter"

> which doesn't make sense to me: Rounding on resize by mouse dragging
> doesn't seem reasonable to me because the frame edge will not follow the
> mouse pointer but rather jump instead.  Rounding when maximizing or
> making a fullscreen frame, however, is much worse because it may leave a
> maximized or fullscreen frame with empty space at anedge of the screen.

> So I'm curious whether your description above just inverts the meaning
> of what you actually do.

Not actually.  I think some of X11 window managers do rounding on
resize by mouse dragging if `frame-resize-pixelwise' is nil (at least,
quartz-wm does so).  If user wants resize by mouse dragging to follow
the mouse strictly, then she or he can set `frame-resize-pixelwise' to
t.

Also, unlike the NS port, the Mac port does not "white out" the screen
during mouse dragging but updates the contents, and it is a bit heavy
operation.  Rounding during mouse dragging also acts as "coalescing"
screen updates.

(Actually, the way to implement this screen updating during mouse
 dragging on the Mac port interferes with "window snapping" introduced
 in macOS 10.12, so it is disabled if running on that version.)

Rounding does not happen for the axis that is specified to be
maximized/full so that it does not leave spaces.  So, rounding happens
only for horizontal axis when the fullscreen frame parameter is set to
'fullheight if `frame-resize-pixelwise' is nil.

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

Re: Emacs Mac port

[martin rudalics]

 > Not actually.  I think some of X11 window managers do rounding on
 > resize by mouse dragging if `frame-resize-pixelwise' is nil (at least,
 > quartz-wm does so).

Hopefully all of them do.  I (silently) do not round on Windows because
there we do not have those line x column indicators which are (IMO) the
sole good reason for rounding on X11.  Apart from performance problems.

 > If user wants resize by mouse dragging to follow
 > the mouse strictly, then she or he can set `frame-resize-pixelwise' to
 > t.

That's the idea, yes.

 > Also, unlike the NS port, the Mac port does not "white out" the screen
 > during mouse dragging but updates the contents, and it is a bit heavy
 > operation.  Rounding during mouse dragging also acts as "coalescing"
 > screen updates.

Makes sense.

 > (Actually, the way to implement this screen updating during mouse
 >   dragging on the Mac port interferes with "window snapping" introduced
 >   in macOS 10.12, so it is disabled if running on that version.)

So what do you do with "window snapping"?  Can you ask for a "white
out"?

 > Rounding does not happen for the axis that is specified to be
 > maximized/full so that it does not leave spaces.  So, rounding happens
 > only for horizontal axis when the fullscreen frame parameter is set to
 > 'fullheight if `frame-resize-pixelwise' is nil.

Sounds reasonable.  Hmm...

Leaves me with one question: When do you suppress rounding with
`frame-resize-pixelwise' nil?  Only for "for the axis that is specified
to be maximized/full"?  Or are there other cases?

martin

Re: Emacs Mac port

[Eli Zaretskii]

> Date: Sun, 18 Sep 2016 11:52:44 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: emacs-devel@gnu.org
> 
> I (silently) do not round on Windows

Is it wise to have Emacs on MS-Windows behave differently in this
regard?  (Is it even documented?)

Re: Emacs Mac port

[martin rudalics]

 > Is it wise to have Emacs on MS-Windows behave differently in this
 > regard?

Windows doesn't support anything but pixelwise resizing of its windows.
This means that the final shape of a frame visually indicated by Windows
when mouse dragging a border or an edge would not be implemented by a
chracter size oriented Emacs.  Rather, Emacs would snap window sizes
back as it did in older versions.

 > (Is it even documented?)

Look up `frame-resize-pixelwise' in the Elisp manual.

martin

Re: Emacs Mac port

[Eli Zaretskii]

> Date: Sun, 18 Sep 2016 17:15:42 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: mituharu@math.s.chiba-u.ac.jp, emacs-devel@gnu.org
> 
>  > Is it wise to have Emacs on MS-Windows behave differently in this
>  > regard?
> 
> Windows doesn't support anything but pixelwise resizing of its windows.
> This means that the final shape of a frame visually indicated by Windows
> when mouse dragging a border or an edge would not be implemented by a
> chracter size oriented Emacs.  Rather, Emacs would snap window sizes
> back as it did in older versions.

I'm asking why it is wrong to do that in newer versions, as long as
frame-resize-pixelwise is nil.  Especially since we behave like that
on other systems.

>  > (Is it even documented?)
> 
> Look up `frame-resize-pixelwise' in the Elisp manual.

But frame resizing by dragging by a mouse is a user-visible feature,
not only for Lisp programmers.

Re: Emacs Mac port

[martin rudalics]

 > I'm asking why it is wrong to do that in newer versions, as long as
 > frame-resize-pixelwise is nil.

Because we want to give users a nice experience, by default.

 > Especially since we behave like that
 > on other systems.

The "other systems" have window managers that do support size hints.
Windows doesn't.  We can not tell Windows where to draw the desired
shape of the frame.

Basically, our Windows code does not behave differently from X code at
all: Emacs simply respects the requested size.  If it didn't on Windows
- that is, if we applied some character size based rounding - we would
immediately get Aero Snap requests wrong which may ask, for example, to
have a window occupy the left or right half of the screen.  We cannot
distinguish whether any such request is the result of dragging a frame
edge with the mouse or that of an Aero routine.

 >>   > (Is it even documented?)
 >>
 >> Look up `frame-resize-pixelwise' in the Elisp manual.
 >
 > But frame resizing by dragging by a mouse is a user-visible feature,
 > not only for Lisp programmers.

Why bother users with something that works out of the box and without a
single complaint over the past years?  The one and only problem users
had so far is that of window managers trying to maximize frames
characterwise and failing miserably.  That problem is addressed in the
user manual.

martin

Re: Emacs Mac port

[Eli Zaretskii]

> Date: Sun, 18 Sep 2016 19:06:29 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: mituharu@math.s.chiba-u.ac.jp, emacs-devel@gnu.org
> 
>  > I'm asking why it is wrong to do that in newer versions, as long as
>  > frame-resize-pixelwise is nil.
> 
> Because we want to give users a nice experience, by default.

So basically, no matter what is the value of frame-resize-pixelwise,
we behave the same on Windows?  If so, I think we deprive users of the
flexibility to experience the other behavior, however unimportant it
may seem, and that is IMO a pity.

>  >> Look up `frame-resize-pixelwise' in the Elisp manual.
>  >
>  > But frame resizing by dragging by a mouse is a user-visible feature,
>  > not only for Lisp programmers.
> 
> Why bother users

Because that's what manuals are about: bothering users with the
details of how the software works.  Those who don't want to read,
don't have to.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 18 Sep 2016 11:52:44 +0200, martin rudalics <rudalics@gmx.at> said:

>> (Actually, the way to implement this screen updating during mouse
>> dragging on the Mac port interferes with "window snapping" introduced
>> in macOS 10.12, so it is disabled if running on that version.)

> So what do you do with "window snapping"?  Can you ask for a "white
> out"?

For "window snapping" introduced in macOS Sierra, see
https://www.youtube.com/watch?v=pzJGeTS49f4 .

The difficulty in updating the frame contents during resize by mouse
dragging on OS X/macOS comes from the fact that it is processed in a
modal loop.  To reflect the frame size change in Emacs, we have to go
back to Lisp event loop so it triggers redisplay, but the modal loop
does not allow us to do so.

Screen updating during mouse dragging is handled by generating fake
events press -> drag -> release -> press -> drag -> release -> ...
internally during a single dragging session.  Between (fake) release
and press, we go back to the Lisp event loop to trigger redisplay.

Unfortunately, this fake event generation does not work with "window
snapping" introduced in upcoming macOS 10.12 Sierra, probably because
the contextual information is lost by fragmented drag events.  I don't
want to make a frame all white as in the NS port, so I capture the
frame contents as a bitmap, decompose it to window (Emacs terminology)
contents, and distribute them proportionally during resize by mouse
dragging.

>> Rounding does not happen for the axis that is specified to be
>> maximized/full so that it does not leave spaces.  So, rounding happens
>> only for horizontal axis when the fullscreen frame parameter is set to
>> 'fullheight if `frame-resize-pixelwise' is nil.

> Sounds reasonable.  Hmm...

> Leaves me with one question: When do you suppress rounding with
> `frame-resize-pixelwise' nil?  Only for "for the axis that is specified
> to be maximized/full"?  Or are there other cases?

No other cases.  It is handled in the delegate method
windowWillResize:toSize: (you can think it as a callback) at
https://bitbucket.org/mituharu/emacs-mac/src/550234fa179601d4bace2cf32b693fc33f3d1266/src/macappkit.m?at=master&fileviewer=file-view-default#macappkit.m-2915
.

Rounding is done in the method hintedWindowFrameSize:allowsLarger: at 
https://bitbucket.org/mituharu/emacs-mac/src/550234fa179601d4bace2cf32b693fc33f3d1266/src/macappkit.m?at=master&fileviewer=file-view-default#macappkit.m-2302
.

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

Re: Emacs Mac port

[martin rudalics]

 > So basically, no matter what is the value of frame-resize-pixelwise,
 > we behave the same on Windows?

Correct.  ‘frame-resize-pixelwise’ is responsible for which size hints
are passed to the window manager.  There are no size hints on Windows.

 > If so, I think we deprive users of the
 > flexibility to experience the other behavior, however unimportant it
 > may seem, and that is IMO a pity.

It's a pity that you did not comment even one of the issues I mentioned
in my previous posts.  My primary concern is to make Emacs stable and
predictable when resizing frames and windows.  On every platform I can
work on.  I don't intend to trade stability for flexibility.

When a window manager or the OS ask Emacs to resize its window in a
certain way, I comply.  This doctrine was established by Jan many years
ago and fully applies to all X based platforms.

Earlier we refused non-characterwise resize requests on Windows because
we considered leaving empty space within the Emacs window the greater
evil.  Such refusal was a gross hack, breaking tiling and all sorts of
maximization/fullscreen requests.  With pixelwise frame resizing we can
fill any empty space within the Emacs window with text and apply Jan's
rule to Windows builds as well.

 >> Why bother users
 >
 > Because that's what manuals are about: bothering users with the
 > details of how the software works.

I was convinced that the "details of how the software works" belong to
the Elisp manual.  Presumably I was wrong.

 > Those who don't want to read,
 > don't have to.

It makes me a bit sad that you apparently believe that I have chosen the
way of handling resize requests on Windows deliberately.  It took me
quite some time to arrive at the present solution and I am glad that so
far we never got any bug reports in this area.  I wished I could say the
same thing about the remaining platforms.

martin

Re: Emacs Mac port

[martin rudalics]

 > For "window snapping" introduced in macOS Sierra, see
 > https://www.youtube.com/watch?v=pzJGeTS49f4 .

IIUC this video shows only how snapping works when moving windows around
the screen.  There's no resizing involved.  Do windows also "snap" while
they get resized?

 > The difficulty in updating the frame contents during resize by mouse
 > dragging on OS X/macOS comes from the fact that it is processed in a
 > modal loop.  To reflect the frame size change in Emacs, we have to go
 > back to Lisp event loop so it triggers redisplay, but the modal loop
 > does not allow us to do so.

I understand.  But simply moving windows does not resize them.  No need
to trigger redisplay.

 > Screen updating during mouse dragging is handled by generating fake
 > events press -> drag -> release -> press -> drag -> release -> ...
 > internally during a single dragging session.  Between (fake) release
 > and press, we go back to the Lisp event loop to trigger redisplay.
 >
 > Unfortunately, this fake event generation does not work with "window
 > snapping" introduced in upcoming macOS 10.12 Sierra, probably because
 > the contextual information is lost by fragmented drag events.  I don't
 > want to make a frame all white as in the NS port, so I capture the
 > frame contents as a bitmap, decompose it to window (Emacs terminology)
 > contents,

... to avoid that scroll bars appear in the wrong place, I presume ...

 > and distribute them proportionally during resize by mouse
 > dragging.

Thanks for the information, martin

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 19 Sep 2016 10:19:22 +0200, martin rudalics <rudalics@gmx.at> said:

>> For "window snapping" introduced in macOS Sierra, see
>> https://www.youtube.com/watch?v=pzJGeTS49f4 .

> IIUC this video shows only how snapping works when moving windows around
> the screen.  There's no resizing involved.  Do windows also "snap" while
> they get resized?

Yes.

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The first update of the Mac port based on Emacs 25.1 is now available
from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-25.1-mac-6.1.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

The thirteenth update of the Mac port based on Emacs 24.5 is also
available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.20.tar.gz

The corresponding branch in the Git repository is `mac-24'.

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

** Fixed bugs

*** Incremental search with a Japanese text in an empty buffer fails.
Reported by Takaaki Ishikawa.

*** Crash when showing a tooltip on macOS 10.12 if compiled with
enable-checking.

*** Crash with C-x 5 5 2 -> C-x 5 2 -> close the first frame with the
red "x" button on macOS 10.12.

*** Fullscreen transition animation looks awkward on OS X 10.7.
This is a regression introduced in 6.0 as the fix for "fullscreen
frames contain space at the top on OS X 10.10".

*** Proxy icon is sometimes not updated.

*** M-x battery RET does not show battery info on macOS 10.12.
Apply a fix for Bug#24537.

*** Emacs sometimes becomes unresponsive to Dock icon clicks (though
it reacts to Command-Tab) if its frames are completely covered by
other applications for a while on macOS 10.12.

** Improvements

*** Ligature glyph width is adjusted to a multiple of space width for
monospace fonts.

*** Screen update during resize now works on macOS 10.12 if
frame-resize-pixelwise is nil.

*** Character Picker is shown in Touch Bar.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 25.2 release candidate 1 is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-25.2-rc1-mac-6.2.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

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

** Fixed bugs

*** Can't resize a frame by dragging its edge on macOS 10.12 via
Screen Sharing.app.

*** mac-auto-operator-composition-mode does not compose "{." for Fira
Code.

*** On Mac OS X 10.7 - OS X 10.9, Emacs consumes CPU time even when it
is idle if tool bars are shown.  This is a regression introduced in
the previous version.

*** Crash when pressing Command + power button on OS X 10.9 and later
if mac-pass-command-to-system is nil.
Reported by Leo.

*** Drag-and-dropping URL does not respect dnd-protocol-alist.

*** Lisp representation of CFNumber may overflow on 64-bit binary.

*** Crash when evaluating (mac-coerce-ae-data "furl" "file:///.file/"
'undecoded-file-name)

*** Closing a tab in a full screen space causes error on macOS 10.12.

** Improvements

*** Show text input candidates and dialog buttons in Touch Bar.

*** Update emoji data to UTR #51 version 4.0.

Re: Emacs Mac port

[Xu Xin]

On Sat, Feb 4, 2017 at 12:46 AM, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
> The Mac port based on Emacs 25.2 release candidate 1 is now available from
>
>   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-25.2-rc1-mac-6.2.tar.gz
>
> and Git repository is also available at
>
>   https://bitbucket.org/mituharu/emacs-mac.git
>
>                                      YAMAMOTO Mitsuharu
>                                 mituharu@math.s.chiba-u.ac.jp
>
> ** Fixed bugs
>
> *** Can't resize a frame by dragging its edge on macOS 10.12 via
> Screen Sharing.app.
>
> *** mac-auto-operator-composition-mode does not compose "{." for Fira
> Code.
>
> *** On Mac OS X 10.7 - OS X 10.9, Emacs consumes CPU time even when it
> is idle if tool bars are shown.  This is a regression introduced in
> the previous version.
>
> *** Crash when pressing Command + power button on OS X 10.9 and later
> if mac-pass-command-to-system is nil.
> Reported by Leo.
>
> *** Drag-and-dropping URL does not respect dnd-protocol-alist.
>
> *** Lisp representation of CFNumber may overflow on 64-bit binary.
>
> *** Crash when evaluating (mac-coerce-ae-data "furl" "file:///.file/"
> 'undecoded-file-name)
>
> *** Closing a tab in a full screen space causes error on macOS 10.12.
>
> ** Improvements
>
> *** Show text input candidates and dialog buttons in Touch Bar.
>
> *** Update emoji data to UTR #51 version 4.0.
>

Looks there's no "emacs-25.2-rc1-mac-6.2" tag in Bitbucket Git repository?

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 4 Feb 2017 21:35:57 -0500, Xu Xin <railwaycat@gmail.com> said:

> Looks there's no "emacs-25.2-rc1-mac-6.2" tag in Bitbucket Git repository?

Oops, I forgot to push the tag.  Thanks for letting me know.

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 25.2 is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-25.2-mac-6.3.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

The fourteenth update of the Mac port based on Emacs 24.5 is also
available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.21.tar.gz

The corresponding branch in the Git repository is `mac-24'.

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

** Fixed bugs

*** call-process is slow especially when there are many/large frames.
Adapt a fix for Bug#26397.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The first update of the Mac port based on Emacs 25.2 is now available
from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-25.2-mac-6.4.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

The fifteenth update of the Mac port based on Emacs 24.5 is also
available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-24.5-mac-5.22.tar.gz

The corresponding branch in the Git repository is `mac-24'.

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

** Fixed bugs

*** call-process(-region) hangs occasionally.  This is a regression
introduced in the previous version.
Reported by Andreas Fuchs.

*** Multi-font compositions may be displayed wrong.
Apply a fix for Bug#26742.

** Improvements

*** Update emoji data to UTS #51 version 5.0.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The second update of the Mac port based on Emacs 25.2 is now available
from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-25.2-mac-6.5.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

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

** Fixed bugs

*** The option --chdir is ignored when the stdin is not a tty.
Reported by Mark Abney.

*** SVG does not import external images specified by relative URLs.

*** "Services" -> "Capture Selection From Screen" inserts a large
image on a Retina display.

*** Crash when some display vector is an empty string.
Apply a fix for Bug#27504.

*** "Show All Tabs" in the tab context menu leads to crash on macOS
10.13 Beta.

** Improvements

*** New function mac-frame-tab-group-property to inspect tab group
properties.  Corresponding setter function is still in development.

*** Pixel-based mouse wheel smooth scrolling is now snappier
especially on large frames or when flipping directions.

*** On OS X 10.10 and later, animation by mac-start-animation is no
longer suppressed when the frame is not completely opaque.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The third update of the Mac port based on Emacs 25.2 is now available
from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-25.2-mac-6.6.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

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

** Fixed bugs

*** Infinite recursion under prettify-symbols-mode and linum-mode.
Apply a fix for Bug#27761.

*** Crash when resizing a frame too small by mouse dragging.

*** Can't resize a frame by dragging on macOS 10.13 Beta via Screen
Sharing.app.

** Improvements

*** The fancy splash screen look vibrant on OS X 10.10 and later.
For non-Retina display users, it is recommended to replace
etc/images/splash.png with the alpha-channeled version:
https://bytebucket.org/mituharu/emacs-mac/raw/82af04a197db41d8b9cc3bc04127be2bf01d255f/etc/images/splash.png
This effect can be turned off with "Reduce translucency" in the
Accessibility pane of the System Preferences.

*** On OS X 10.10 and later, if the frame background color is light,
then scroll bars look slightly translucent.
This effect can be turned off with "Reduce translucency" in the
Accessibility pane of the System Preferences.

*** On OS X 10.10 and later, if the frame background color is dark,
then the title bar, the tool bar, (the tab bar on macOS 10.12), scroll
bars, and popup menus look also dark.
The title/tool/tab bars have already looked translucent on macOS 10.12
regardless of the frame background color types.  Text smoothing in
these bars for the focused frame seems to be problematic if the
contents contain Core Animation layers that use Core Image filters
especially with dark window background colors and non-Retina displays.
A change in the last version with respect to window/view hierarchy
manifested this problem, and the use of dark bars works around it.

*** Magnify and rotate events now contain the :phase property.
Now absence of the :phase property in a magnify event means it is a
"smart magnify" event rather than what is caused by a pinch gesture.
On OS X 10.10 and later, its value is either `began', `changed', or
`ended'.  On earlier versions, it is always `none'.

*** New function mac-send-action that sends the specified Cocoa action
using the responder chain for action messages.
Some useful examples Cocoa actions are `zoom', `hide', `unhide',
`activate', `hideOtherApplications', `unhideAllApplications', and
`orderFrontCharacterPalette'.

*** New function mac-frame-tab-group-property to set tab group
properties.

*** New menu items (mostly in the "Buffers" menu), key bindings
(Control-Tab, Control-Shift-Tab) for tabbing on macOS 10.12 and later.

*** On macOS 10.13 Beta, the pinch close gesture triggers tab group
overview.  If you want to make the text size smaller, first pinch open
and then pinch close without releasing the fingers from the trackpad.
Alternatively, remap the corresponding command as:
  (global-set-key [remap mac-magnify-text-scale-or-overview-tab-group]
                  'mac-magnify-text-scale)

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 25.3 is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-25.3-mac-6.7.tar.gz

The Git repository at bitbucket is not updated yet.  I'll do that once
Emacs 25.3 gets available in the repository upstream.

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

** Fixed bugs

*** The format "%x" in `org-capture-templates' does not work.

** Improvements

*** Support the frame parameter `scroll-bar-background'.
If it is nil, which is the default, then the frame background color is
used instead.  Its color also affects the appearance of other GUI
parts: the title bar, the tool bar, (the tab bar on macOS 10.12 and
later), scroll bars, and popup menus become light (or dark) if the
color is considered light (or dark, respectively).  On macOS 10.12 and
later, the title/tool/tab bars look slightly colored with the value of
the `scroll-bar-background' frame parameter (or the frame background
color) if the frame is focused and not in fullscreen.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 12 Sep 2017 14:31:23 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> The Git repository at bitbucket is not updated yet.  I'll do that
> once Emacs 25.3 gets available in the repository upstream.

Done.  Available from https://bitbucket.org/mituharu/emacs-mac.git as
usual.

I also created a new branch `experimental/mac-gui-thread' in the above
repository for preparation of multi-thread support in Emacs 26.  The
branch itself is still based on Emacs 25 to test this new design and
code on top of a stable basis.

It runs the Lisp REPL in a non-main thread, so the main thread is
dedicated to GUI tasks, which might be requested from multiple Lisp
threads if we switch to version 26.  The GUI and Lisp threads run
mostly cooperatively (i.e., do not run simultaneously) except in the
`select' emulation.  Note that the variable `main_thread' in sysdep.c
no longer corresponds to the "main thread" in a usual sense.

> ** Improvements

> *** Support the frame parameter `scroll-bar-background'.
> If it is nil, which is the default, then the frame background color is
> used instead.  Its color also affects the appearance of other GUI
> parts: the title bar, the tool bar, (the tab bar on macOS 10.12 and
> later), scroll bars, and popup menus become light (or dark) if the
> color is considered light (or dark, respectively).  On macOS 10.12 and
> later, the title/tool/tab bars look slightly colored with the value of
> the `scroll-bar-background' frame parameter (or the frame background
> color) if the frame is focused and not in fullscreen.

If you want light scroll bars, title bars, etc. while using a dark
frame background color as it used to be, then customize the
`scroll-bar-background' frame parameter to "white", for example.

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The first update of the Mac port based on Emacs 25.3 is now available
from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-25.3-mac-6.8.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

Courageous users are invited to try the `experimental/mac-gui-thread'
branch in the above repository.

>>>>> On Wed, 13 Sep 2017 12:46:51 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> I also created a new branch `experimental/mac-gui-thread' in the
> above repository for preparation of multi-thread support in Emacs
> 26.  The branch itself is still based on Emacs 25 to test this new
> design and code on top of a stable basis.

> It runs the Lisp REPL in a non-main thread, so the main thread is
> dedicated to GUI tasks, which might be requested from multiple Lisp
> threads if we switch to version 26.  The GUI and Lisp threads run
> mostly cooperatively (i.e., do not run simultaneously) except in the
> `select' emulation.  Note that the variable `main_thread' in
> sysdep.c no longer corresponds to the "main thread" in a usual
> sense.

In addition to the usual configure options for debugging, I'd
recommend using "the Main Thread Checker" introduced in Xcode 9 by
setting the environment variable DYLD_INSERT_LIBRARIES to

  /Applications/Xcode.app/Contents/Developer/usr/lib/libMainThreadChecker.dylib

If you are using lldb, then you can set it as follows:

  (lldb) settings set target.env-vars DYLD_INSERT_LIBRARIES=/Applications/Xcode.app/Contents/Developer/usr/lib/libMainThreadChecker.dylib 

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

** Fixed bugs

*** Frame parameter `alpha' does not work in tooltip-frame-parameters.

*** Switching to/from `fullboth' frame does not preserve tool bar.

*** Hourglass (progress indicator) on a dark title bar is invisible.

*** Live resize transition animation does not respect internal border.

*** Some input methods (e.g., Japanese one) on macOS 10.13 do not
recognize Control+Space even if it is unchecked in the system-wide
short cut settings.  This issue is registered in the Apple Bug
Reporter as rdar://33842041, but still open.  A workaround is added.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The bare development branch of the Mac port is now based on Emacs
26.0.90 pretest:

  https://bitbucket.org/mituharu/emacs-mac.git

The branch name is "work".  It should be considered as
experimental/hackers-only.

At the moment, the new frame parameters `parent-frame' and
`undecorated' are not supported yet.  I have some premature code
internally, but not included in the repository above.

In order to support concurrency on Emacs 26 properly, I've redesigned
the `select' emulation code.  It runs the Lisp REPL in a non-main
thread, so the main thread is dedicated to GUI tasks, which might be
requested from multiple Lisp threads.  The GUI and Lisp threads run
mostly cooperatively (i.e., do not run simultaneously) except in the
`select' emulation.  Note that the variable `main_thread_id' in
sysdep.c no longer corresponds to the "main thread" in a usual sense.

Thanks to this new design, all the following examples can work without
hang or crash:

  (make-thread
   (lambda ()
     (let (last-nonmenu-event)
       (setq test (y-or-n-p-with-timeout "test" 2 'timeout)))))

  (make-thread 'buffer-menu-open)

  (make-thread
   (lambda ()
     (let (last-nonmenu-event)
       (call-interactively 'find-file))))

  (make-thread
   (lambda ()
     (setq test (x-select-font))))

In addition to the usual configure options for debugging, I'd
recommend using "the Main Thread Checker" introduced in Xcode 9 by
setting the environment variable DYLD_INSERT_LIBRARIES to

  /Applications/Xcode.app/Contents/Developer/usr/lib/libMainThreadChecker.dylib

If you are using lldb, then you can set it as follows:

  (lldb) settings set target.env-vars DYLD_INSERT_LIBRARIES=/Applications/Xcode.app/Contents/Developer/usr/lib/libMainThreadChecker.dylib 

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

Re: Emacs Mac port

[Konrad Podczeck]

First, of course, thanks for your work with the Emacs Macport.

With the new version, I see the following two problems:

(1) (a) Open some larger file, which contains some word, foo say, rather often.

    (b) Do: customize-variable -> special-display-regexps ->*occur*

    (c) In the Buffer containing the original file do: occor->foo
                 
    (d) Switch to the frame containing the occur-buffer and do:
        
        next-error-follow-minor-mode

    (e) Now go up and down in the occur-buffer frame by the arrow keys, and an annoying flicker in the    

        frame showing the original frame happens; the effect is actually more drastic if I press and 

        hold down some arrow key.

        This is not the case with the master-version and not with the work-versions up to and   
        
        including 79dba490b3bc.

(2) Putting the mouse over a tool-bar button, so that the corresponding tooltip appear, and then quickly dragging the frame with the mouse to another place on the screen, the tooltip is still shown for some time at the original screen position.

Konrad

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 16 Oct 2017 18:01:16 +0200, Konrad Podczeck <konrad.podczeck@univie.ac.at> said:

> With the new version, I see the following two problems:

> (1) (a) Open some larger file, which contains some word, foo say, rather often.
>     (b) Do: customize-variable -> special-display-regexps ->*occur*
>     (c) In the Buffer containing the original file do: occor->foo
>     (d) Switch to the frame containing the occur-buffer and do:
>         next-error-follow-minor-mode
>     (e) Now go up and down in the occur-buffer frame by the arrow keys, and an annoying flicker in the    
>         frame showing the original frame happens; the effect is actually more drastic if I press and 
>         hold down some arrow key.
>         This is not the case with the master-version and not with the work-versions up to and   
>         including 79dba490b3bc.

Thanks for reporting.  I've updated the repository so the Mac port
based on Emacs 26.0.90 behaves like the version based on Emacs 25.3
with respect to frame raising.

Note that the flicker/flutter happens even with X11, and with the Mac
port based on Emacs 25.3 running on older versions (< 10.11) of macOS.
Probably newer versions of macOS do some coalescing.

> (2) Putting the mouse over a tool-bar button, so that the corresponding tooltip appear, and then quickly dragging the frame with the mouse to another place on the screen, the tooltip is still shown for some time at the original screen position.

I'll look into it later.

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 17 Oct 2017 10:41:11 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>> (2) Putting the mouse over a tool-bar button, so that the
>> corresponding tooltip appear, and then quickly dragging the frame
>> with the mouse to another place on the screen, the tooltip is still
>> shown for some time at the original screen position.

> I'll look into it later.

I think I could find the cause of this problem finally.  It took a
long time because it was in the platform-independent part.  I'm still
not sure if the patch below is the right way, but could you check if
this also works for your case?

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

diff --git a/src/xdisp.c b/src/xdisp.c
index 45eabb10d7..e5e1319e18 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -31029,9 +31029,6 @@ note_mouse_highlight (struct frame *f, int x, int y)
 	  && part != ON_HEADER_LINE))
     clear_mouse_face (hlinfo);
 
-  /* Reset help_echo_string. It will get recomputed below.  */
-  help_echo_string = Qnil;
-
 #ifdef HAVE_WINDOW_SYSTEM
   /* If the cursor is on the internal border of FRAME and FRAME's
      internal border is draggable, provide some visual feedback.  */
@@ -31090,6 +31087,9 @@ note_mouse_highlight (struct frame *f, int x, int y)
   if (!WINDOWP (window))
     return;
 
+  /* Reset help_echo_string. It will get recomputed below.  */
+  help_echo_string = Qnil;
+
   /* Convert to window-relative pixel coordinates.  */
   w = XWINDOW (window);
   frame_to_window_pixel_xy (w, &x, &y);

Re: Emacs Mac port

[martin rudalics]

 >>> (2) Putting the mouse over a tool-bar button, so that the
 >>> corresponding tooltip appear, and then quickly dragging the frame
 >>> with the mouse to another place on the screen, the tooltip is still
 >>> shown for some time at the original screen position.

How can you reproduce that?  Here the tooltip disappears immediately
when moving the mouse from the tool bar button to the frame border.

 > I think I could find the cause of this problem finally.  It took a
 > long time because it was in the platform-independent part.  I'm still
 > not sure if the patch below is the right way, but could you check if
 > this also works for your case?

You mean that the help_echo_string built by

       if (cursor != FRAME_X_OUTPUT (f)->nontext_cursor)
	{
	  /* Do we really want a help echo here?  */
	  help_echo_string = build_string ("drag-mouse-1: resize frame");
	  goto set_cursor;

should be immediately erased when we "have a window" and be left as is
when we just "have a frame"?  Or am I missing something else?

martin

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 30 Oct 2017 09:25:46 +0100, martin rudalics <rudalics@gmx.at> said:

>>>> (2) Putting the mouse over a tool-bar button, so that the
>>>> corresponding tooltip appear, and then quickly dragging the frame
>>>> with the mouse to another place on the screen, the tooltip is still
>>>> shown for some time at the original screen position.

> How can you reproduce that?  Here the tooltip disappears immediately
> when moving the mouse from the tool bar button to the frame border.

The Mac port is a bit special in the sense that the tooltip for a
toolkit tool bar button is not shown by the toolkit but as a Emacs tip
frame.  Also, unlike the case of GTK+ (with x-gtk-use-system-tooltips
= nil) which has callbacks to show/hide tooltips, it is processed by
the callback for mouse movement events as in non-toolkit tool bars on
X11.

>> I think I could find the cause of this problem finally.  It took a
>> long time because it was in the platform-independent part.  I'm still
>> not sure if the patch below is the right way, but could you check if
>> this also works for your case?

> You mean that the help_echo_string built by

>        if (cursor != FRAME_X_OUTPUT (f)->nontext_cursor)
> 	{
> 	  /* Do we really want a help echo here?  */
> 	  help_echo_string = build_string ("drag-mouse-1: resize frame");
> 	  goto set_cursor;

> should be immediately erased when we "have a window" and be left as is
> when we just "have a frame"?  Or am I missing something else?

As I said in the previous mail, I'm still not sure this is the right
way (especially about the tooltip for internal border resizing).  I
just tried reverting a part of change between Emacs 25.3, which does
not show the problem the OP described, and Emacs 26.0.90.

I think the problem is that help_echo_string can be set to nil without
hiding the tooltip, if returning early (i.e., when !WINDOWP (window))
from note_mouse_highlight. The code to show/hide tooltip for the tool
bar in the Mac port is similar to the one on X11 below:

  8568	    case MotionNotify:
  8569	      {
  8570	        x_display_set_last_user_time (dpyinfo, event->xmotion.time);
  8571	        previous_help_echo_string = help_echo_string;
  8572	        help_echo_string = Qnil;

	:

  8648	        /* If the contents of the global variable help_echo_string
  8649	           has changed, generate a HELP_EVENT.  */
  8650	        if (!NILP (help_echo_string)
  8651	            || !NILP (previous_help_echo_string))
  8652		  do_help = 1;
  8653	        goto OTHER;
  8654	      }

If help_echo_string = nil at Line 8572 but the tooltip is actually
shown, and the lines between 8573 and 8648 do not set help_echo_string
(as no help string to show), then the do_help is not set and thus the
tooltip is not hidden.

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

Re: Emacs Mac port

[Konrad Podczeck]

Together with this second patch, the 26-based Mac port work for me as great as the 25-based one. Thanks for all your effort.

Konrad

> Am 30.10.2017 um 08:38 schrieb YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>:
> 
>>>>>> On Tue, 17 Oct 2017 10:41:11 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:
> 
>>> (2) Putting the mouse over a tool-bar button, so that the
>>> corresponding tooltip appear, and then quickly dragging the frame
>>> with the mouse to another place on the screen, the tooltip is still
>>> shown for some time at the original screen position.
> 
>> I'll look into it later.
> 
> I think I could find the cause of this problem finally.  It took a
> long time because it was in the platform-independent part.  I'm still
> not sure if the patch below is the right way, but could you check if
> this also works for your case?
> 
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
> 
> diff --git a/src/xdisp.c b/src/xdisp.c
> index 45eabb10d7..e5e1319e18 100644
> --- a/src/xdisp.c
> +++ b/src/xdisp.c
> @@ -31029,9 +31029,6 @@ note_mouse_highlight (struct frame *f, int x, int y)
> 	  && part != ON_HEADER_LINE))
>     clear_mouse_face (hlinfo);
> 
> -  /* Reset help_echo_string. It will get recomputed below.  */
> -  help_echo_string = Qnil;
> -
> #ifdef HAVE_WINDOW_SYSTEM
>   /* If the cursor is on the internal border of FRAME and FRAME's
>      internal border is draggable, provide some visual feedback.  */
> @@ -31090,6 +31087,9 @@ note_mouse_highlight (struct frame *f, int x, int y)
>   if (!WINDOWP (window))
>     return;
> 
> +  /* Reset help_echo_string. It will get recomputed below.  */
> +  help_echo_string = Qnil;
> +
>   /* Convert to window-relative pixel coordinates.  */
>   w = XWINDOW (window);
>   frame_to_window_pixel_xy (w, &x, &y);

Re: Emacs Mac port

[martin rudalics]

 > I think the problem is that help_echo_string can be set to nil without
 > hiding the tooltip, if returning early (i.e., when !WINDOWP (window))
 > from note_mouse_highlight. The code to show/hide tooltip for the tool
 > bar in the Mac port is similar to the one on X11 below:

Thanks for the explanation, martin

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 26.1 release candidate 1 is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.1-rc1-mac-6.90.tar.gz
  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-hires-icons-3.0.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

Get it from the "master" branch.  The "work" branch is for bare
development and not for release (candidate) versions.

The second update of the Mac port based on Emacs 25.3 is also
available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-25.3-mac-6.9.tar.gz
  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-hires-icons-3.0.tar.gz
  (Hiresolution icons are the same as those for emacs-26.1-rc1-mac-6.90)

The corresponding branch in the Git repository is "mac-25".

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

** Fixed bugs

*** The function `get-free-disk-space' gives free inode count rather
than free data block space on OS X 10.8 and later (Bug#28639).

*** Crash on macOS 10.13 with pinch close to invoke tab overview over
some highlighted text and then clicking the input source menu in the
menu bar.

*** On macOS 10.13.1, pinch close gesture with shift key causes exit
and then enter fullboth.

*** Making frame fullboth is slow on macOS 10.13.1.

*** Crash when showing menu help strings while minibuffer is invisible.
Reported by Konrad Podczeck.

*** Entering fullboth from a fullscreen frame makes it maximized.
This is a regression introduced in 5.90.

*** Entering and then exiting from fullboth makes the frame shorter.

*** Space width for monospace fonts may be wrong.  This is a
regression introduced in 6.1 as "ligature glyph width adjustment".

** Improvements

*** Adopt CFBundleDocumentTypes part from the NS port.
Contributed by Xin Xu.

*** Update emoji data to UTS #51 version 11.0.

*** On macOS 10.13, the pinch close gesture makes the text shrunken
(rather than triggering tab group overview) if the text is magnified.

*** New variable `mac-ignore-accessibility'.
Emacspeak users may want to set this variable so it may not interfere
with the system accessibility services such as VoiceOver.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 26.1 is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.1-mac-7.0.tar.gz
  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-hires-icons-3.0.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

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

** Fixed bugs

*** Circular dependency in mac/Emacs.app/Contents for in-tree build.
Contributed by Jose Arroyo.

*** Symlinks autocomplete as directories on OS X 10.9 and earlier
(Bug#31305).  A workaround is added.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The first update of the Mac port based on Emacs 26.1 is now available
from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.1-mac-7.1.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

This is an urgent bug fix release.

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

** Fixed bugs

*** mouse-wheel-flip-direction does not have any effect.
Reported by Yuen Ho Wang.

*** C-g does not quit call-process.
Reported by xristos.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The second update of the Mac port based on Emacs 26.1 is now available
from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.1-mac-7.2.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

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

** Fixed bugs

*** Buffer contents are not displayed on macOS 10.14.
This is mainly because now NSViews are backed by Core Animation Layer
(layer-backed) by default and non-deferred drawing into views no
longer works.  Instead of switching to deferred drawing (i.e., draw
only inside -[NSView drawRect:]), we draw into our own backing bitmap
in a non-deferred way as before, and update the view contents with the
resulting image via -[NSView updateLayer].  This "application-side
double buffering" is also available on OS X 10.8 - macOS 10.13 if you
set the frame parameter `inhibit-double-buffering' to nil when
creating a frame.  Just like on macOS 10.14, such a frame does not do
LCD smoothing.

*** Screenshot grabbed via Services is displayed in wrong size when we
have display mirroring between Retina and non-Retina displays.

*** Cursor movement just after frame resize sometimes leaves garbage.

*** Crash by the Fall_threads call from the GUI thread at the select
emulation when there are multiple Lisp threads.

*** Info title has ASCII underline unlike other window systems.

*** Vertical scroll bar is created as horizontal if frame font height
is short.

** Improvements

*** macOS 10.14 adds property :appearance to (mac-application-state).
The value may be "NSAppearanceNameAqua" or "NSAppearanceNameDarkAqua".

*** Add new color format "mac:COLOR-LIST-NAME:COLOR-NAME" and
"mac:COLOR-NAME" (shorthand for "mac:System:COLOR-NAME").  The actual
color may be different depending on the global appearance setting on
macOS 10.14.  For example, "mac:textColor" is black on the Light Mode
but is white on the Dark Mode.

*** Default frame colors respect appearance setting on macOS 10.14.
Now the default frame foreground/background color is
"mac:textColor"/"mac:textBackgroundColor", respectively.  Changes of
the system setting of the global appearance are dynamically reflected.

*** New function `mac-color-list-alist' to get the available
combinations of COLOR-LIST-NAMEs and COLOR-NAMEs.  Note that this
value is dependent on user environment and OS version.  Also, some
combinations may represent image patterns rather than colors.  For the
former cases, `(color-values "mac:COLOR-LIST-NAME:COLOR-NAME")'
returns nil.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The third update of the Mac port based on Emacs 26.1 is now available
from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.1-mac-7.3.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

The third update of the Mac port based on Emacs 25.3 is also available
from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-25.3-mac-6.10.tar.gz

The corresponding branch in the Git repository is "mac-25".

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

* emacs-26.1-mac-7.3 (2018-10-24)

** Fixed bugs

*** Underline for converted text is invisible on dark background.

*** Possible stack overflow (Bug#31995 and Bug#32338).

*** Changing tool bar style (either via the variable tool-bar-style or
tool bar context menu) may make the frame blank with application-side
double buffering, which is forced on macOS 10.14.

*** CPU load is high if application-side double buffering is used.
This is mainly caused by the use of layer-backed views together with
other CALayers involving Core Image filters, and that seems to lead to
excessive CPU time consumption by the CVDisplayLink thread.  Now
overlay views, which host CALayers that use Core Image filters for
several animation effects and drag-and-drop highlighting, are added
into the view hierarchy in an on-demand way to avoid this phenomenon.

*** Drag-and-drop into Emacs frame does not work on Mac OS X 10.6.
This is a regression introduced in 7.2.

*** U+1F9B5 and U+1F9B6 are missing from list of emoji modifier bases.

*** Frames that use application-side double buffering cannot do LCD
font smoothing even on OS X 10.8 - macOS 10.13.
On macOS 10.14, LCD font smoothing is globally disabled by default.
You need to execute "$ defaults write org.gnu.Emacs
CGFontRenderingFontSmoothingDisabled -bool NO" to enable it.

*** Sending Apple Events to other applications causes an error on
macOS 10.14.

*** Fail to launch on OS X 10.8.
This is a regression introduced in 7.2.

** Improvement

*** In addition to TIFF, PDF is accepted as pasteboard image data.
Now "Scan Documents" in the context menu on macOS 10.14 can insert PDF
data scanned by your nearby iOS devices (Continuity Camera).

*** New experimental configure option `--with-mac-metal' to use GPU
for pixel copy operations in the frames using application-side double
buffering on OS X 10.11 or later with supported hardware (see
https://support.apple.com/HT205073).  If you are using this feature in
the selected frame, then the expression below will be evaluated to t:
  (and (frame-monitor-attribute 'metal-device-name)
       (not (frame-parameter nil 'inhibit-double-buffering)))
On the Mac port, setting the value of the frame parameter
`inhibit-double-buffering' is only effective at the frame creation
time.  So on OS X 10.11 - macOS 10.13, you need to specify it either
as (make-frame '((inhibit-double-buffering))), by default-frame-alist,
or by X resources emulation via Preferences system (see Mac port
section in Info).  On macOS 10.14, there is no choice other than
application-side double buffering, so you don't need to care about it.
Currently this feature is only tested in very limited environments.
In particular, I can't test it with dynamic switching between
integrated and discrete GPUs.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

> The third update of the Mac port based on Emacs 26.1 is now available
> The third update of the Mac port based on Emacs 25.3 is also available

I received a report that SVG rendering via WebKit has become so slow.
This happens both with the Mac port version 7.2/7.3 based on Emacs
26.1 and with version 6.10 based on Emacs 25.3 when built on macOS
10.13 or later.  I'll address this issue in the next release.  For the
moment, please build the executable with

  $ make CFLAGS="-g3 -O2 -DWK_API_ENABLED=0"

if SVG rendering performance is crucial for you.  It will show some
deprecation warnings on macOS 10.14, but still usable.  Sorry for the
inconvenience.

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The fourth update of the Mac port based on Emacs 26.1 is now available
from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.1-mac-7.4.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

If you see the error message like

  error: no type or protocol named 'NSMenuItemValidation'

when compiling it on macOS 10.14.1, then you have most likely
(unconsciously) installed Command Line Tools (macOS 10.13) for Xcode
10.1.  Please check your installations with the following command:

  $ softwareupdate --history --all | grep Command

This can reportedly be fixed by downloading Command Line Tools (macOS
10.14) for Xcode 10.1 from https://developer.apple.com/download/more/
and installing it manually.

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

* emacs-26.1-mac-7.4 (2018-11-16)
Turn on the configure option `--with-mac-metal' by default.

** Fixed bugs

*** Crash when clicking on the menu bar on some environments.
Reported by John Nicola and Darren Hoo.

*** Redraw needlessly on mouse movement if application-side double
buffering is used.

*** Synthetic bold is stronger on Retina display if application-side
double buffering is used.

*** Animation effect is displayed with wrong colors if
application-side double buffering is used with Metal.

*** SVG rendering via WebKit is slow if built on macOS 10.13 or later.
Reported by Bibek Pokharel.

Re: Emacs Mac port

[Aaron Madlon-Kay]

In reply to https://lists.gnu.org/r/emacs-devel/2018-11/msg00246.html

> If you see the error message like
>
>  error: no type or protocol named 'NSMenuItemValidation'
>
> when compiling it on macOS 10.14.1, then you have most likely
> (unconsciously) installed Command Line Tools (macOS 10.13) for Xcode
> 10.1.  Please check your installations with the following command:
>
>  $ softwareupdate --history --all | grep Command
>
> This can reportedly be fixed by downloading Command Line Tools (macOS
> 10.14) for Xcode 10.1 from https://developer.apple.com/download/more/
> and installing it manually.

I was unfortunately a victim of this inadvertent installation of old
CLI tools, and on both my home and work machines so I suspect it may
be widespread.

Merely reinstalling the correct Command Line Tools package was
insufficient to solve the problem for me. I had to also install the
newly-optional headers package found here:

/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg

More details on why this is necessary here:
https://github.com/macports/macports-ports/pull/3036#issuecomment-439789796

-Aaron

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

On Mon, 19 Nov 2018 16:21:34 +0900,
Aaron Madlon-Kay wrote:
> 
> Merely reinstalling the correct Command Line Tools package was
> insufficient to solve the problem for me. I had to also install the
> newly-optional headers package found here:
> 
> /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
> 

It is supposed to build without /usr/include, unless some bogus
pkgconfig files point there (which happens with Homebrew, see
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32927).

You seem to use MacPorts rather than Homebrew.  Could you send me the
exact error messages when building the Mac port after temporary
renaming /usr/include to some other name?  Also, please show me the
output of the following commands:

  $ pkg-config --cflags --libs "libxml-2.0 > 2.6.17"
  $ pkg-config --variable pcfiledir "libxml-2.0 > 2.6.17"

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

Re: Emacs Mac port

[Aaron Madlon-Kay]

(Resending to list as well; apologies to Mr. Yamamoto.)

> It is supposed to build without /usr/include

My understanding is that it's not /usr/include that was the problem,
but rather headers in /System/Library/Frameworks and
/System/Library/PrivateFrameworks that were bad. The High Sierra CLI
tools package installs these, whereas the Mojave package does not,
thus requiring macOS_SDK_headers_for_macOS_10.14.pkg to fix.

> You seem to use MacPorts rather than Homebrew.  Could you send me the
> exact error messages when building the Mac port after temporary
> renaming /usr/include to some other name?

macOS's SIP (https://en.wikipedia.org/wiki/System_Integrity_Protection)
prevents me from merely renaming /usr/include, and it's a pain to turn
on and off, so I apologize but I'm not willing to do this.

> Also, please show me the output of the following commands:

Sure:

$ pkg-config --cflags --libs "libxml-2.0 > 2.6.17"
-I/opt/local/include/libxml2 -L/opt/local/lib -lxml2
$ pkg-config --variable pcfiledir "libxml-2.0 > 2.6.17"
/opt/local/lib/pkgconfig

(MacPorts as a rule requires dependencies to come from other MacPorts
packages; the emacs-mac-app port depends on the libxml2 port, which
would be installed in /opt/local, so as far as I can tell this output
is correct.)

-Aaron

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

On Tue, 20 Nov 2018 10:07:11 +0900,
Aaron Madlon-Kay wrote:
> 
> > It is supposed to build without /usr/include
> 
> My understanding is that it's not /usr/include that was the problem,
> but rather headers in /System/Library/Frameworks and
> /System/Library/PrivateFrameworks that were bad. The High Sierra CLI
> tools package installs these, whereas the Mojave package does not,
> thus requiring macOS_SDK_headers_for_macOS_10.14.pkg to fix.

> > You seem to use MacPorts rather than Homebrew.  Could you send me the
> > exact error messages when building the Mac port after temporary
> > renaming /usr/include to some other name?
> 
> macOS's SIP (https://en.wikipedia.org/wiki/System_Integrity_Protection)
> prevents me from merely renaming /usr/include, and it's a pain to turn
> on and off, so I apologize but I'm not willing to do this.

Oh, I thought macOS_SDK_headers_for_macOS_10.14.pkg would only install
header files into /usr/include, but that is not the case actually.
Thanks for clarifying this.  Never mind about renaming /usr/include.
I hope there is a way to uninstall Command Line Tools (macOS 10.13)
for Xcode 10.1 without resorting to macOS_SDK_headers_for_macOS_10.14.pkg.

> > Also, please show me the output of the following commands:
> 
> Sure:
> 
> $ pkg-config --cflags --libs "libxml-2.0 > 2.6.17"
> -I/opt/local/include/libxml2 -L/opt/local/lib -lxml2
> $ pkg-config --variable pcfiledir "libxml-2.0 > 2.6.17"
> /opt/local/lib/pkgconfig
> 
> (MacPorts as a rule requires dependencies to come from other MacPorts
> packages; the emacs-mac-app port depends on the libxml2 port, which
> would be installed in /opt/local, so as far as I can tell this output
> is correct.)

Thanks.  There seems to be no problem with them.

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

Re: Emacs Mac port

[Leo Liu]

On 2018-11-16 18:56 +0900, YAMAMOTO Mitsuharu wrote:
> The fourth update of the Mac port based on Emacs 26.1 is now available
> from
>
>   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.1-mac-7.4.tar.gz

After upgrade to mojave 10.14.2 (from 10.12) I have noticed one rather
inconvenient change from the OS. M-% is now intercepted by the OS to
capture screen. Is there any workaround for this?

Thanks,
Leo

Re: Emacs Mac port

[Tim Cross]

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

Nothing Emacs can do here as it never sees the key press. You need to
modify your keyboard shortcut preferences in macOS using System Preferences
-> keyboard -> shortcuts. You will likely find other useful Emacs bindings
which have been stolen by macOS and which will also need to be
adjusted/removed


On Sat, 22 Dec 2018 at 09:29, Leo Liu <sdl.web@gmail.com> wrote:

> On 2018-11-16 18:56 +0900, YAMAMOTO Mitsuharu wrote:
> > The fourth update of the Mac port based on Emacs 26.1 is now available
> > from
> >
> >   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.1-mac-7.4.tar.gz
>
> After upgrade to mojave 10.14.2 (from 10.12) I have noticed one rather
> inconvenient change from the OS. M-% is now intercepted by the OS to
> capture screen. Is there any workaround for this?
>
> Thanks,
> Leo
>
>

-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 1451 bytes --]

Re: Emacs Mac port

[Eli Zaretskii]

> From: Leo Liu <sdl.web@gmail.com>
> Date: Sat, 22 Dec 2018 06:28:18 +0800
> Cc: emacs-devel@gnu.org
> 
> After upgrade to mojave 10.14.2 (from 10.12) I have noticed one rather
> inconvenient change from the OS. M-% is now intercepted by the OS to
> capture screen. Is there any workaround for this?

A (somewhat inconvenient) workaround is to use "ESC %" instead.

Re: Emacs Mac port

[Leo Liu]

On 2018-12-22 09:59 +1100, Tim Cross wrote:
> Nothing Emacs can do here as it never sees the key press. You need to
> modify your keyboard shortcut preferences in macOS using System Preferences
> -> keyboard -> shortcuts. You will likely find other useful Emacs bindings
> which have been stolen by macOS and which will also need to be
> adjusted/removed
>

Thanks for the info.

On 2018-12-22 09:31 +0200, Eli Zaretskii wrote:
>
> A (somewhat inconvenient) workaround is to use "ESC %" instead.
>

Yeah I already use this as a workaround it is a bit slower to type. I
suppose I have to move the system key to somewhere else.

Thanks for suggesting.

Leo

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 26.2 release candidate 1 is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.2-rc1-mac-7.5.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

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

** Fixed bugs

*** Rare crash when popping up a dialog.

*** Rare crash when drawing into a tooltip frame.

*** Fail to insert Apple logo if mac-system-coding-system is mac-roman.

*** The name attribute is missing in display-monitor-attributes-list
if the display serial number value is negative in signed int.

** Improvements

*** Update emoji data to UTS #51 version 12.0.

*** Add stipple support.  The "@2x" file name convention and the
`:data-2x' text property at the first byte of the data are also
available to support optional 2x bitmaps for Retina display.

Re: Emacs Mac port

[Konstantin Kharlamov]

Thanks! I have a silly question: why are these improvements is a 
separate project instead of being in upstream? I've read the overview, 
and tried searching around a bit, but don't see.

On Пт, Mar 22, 2019 at 08:28:09, YAMAMOTO Mitsuharu 
<mituharu@math.s.chiba-u.ac.jp> wrote:
> The Mac port based on Emacs 26.2 release candidate 1 is now available 
> from
> 
>   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.2-rc1-mac-7.5.tar.gz
> 
> and Git repository is also available at
> 
>   https://bitbucket.org/mituharu/emacs-mac.git
> 
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
> 
> ** Fixed bugs
> 
> *** Rare crash when popping up a dialog.
> 
> *** Rare crash when drawing into a tooltip frame.
> 
> *** Fail to insert Apple logo if mac-system-coding-system is 
> mac-roman.
> 
> *** The name attribute is missing in display-monitor-attributes-list
> if the display serial number value is negative in signed int.
> 
> ** Improvements
> 
> *** Update emoji data to UTS #51 version 12.0.
> 
> *** Add stipple support.  The "@2x" file name convention and the
> `:data-2x' text property at the first byte of the data are also
> available to support optional 2x bitmaps for Retina display.
> 

Re: Emacs Mac port

[Stefan Monnier]

> Thanks! I have a silly question: why are these improvements is a separate
> project instead of being in upstream? I've read the overview, and tried
> searching around a bit, but don't see.

Here was my explanation last time this came up (it was on reddit,
hidden within a discussion about Helm):

    FWIW, the reason the mac port is separate has nothing to do with the
    policy of not supporting features specific to proprietary code.
    It's mostly a historical accident: when the old Carbon code for
    "Emacs on Mac" had to be replaced, the only established option was
    the "Emacs.app" port.  Yamamoto's mac port was announced but not
    really materialized yet, and the Emacs.app promised to also work on
    GNUstep which was a great side benefit.  So the Emacs.app code was
    integrated.  Since then the GNUstep promise has not really
    materialized (tho it's been just usable enough to be able to fix
    a handful of MacOS bugs, IIUC), and the Emacs.app (aka "cocoa") code
    did not get much support (as a general rule, while Emacs has many
    MacOS users, it seems very few of them are interested in
    contributing to fix bugs and improve the code :-( ).  I don't think
    there'd be much resistance to switching the MacOS support code to
    the one in the mac port (it might support MacOS-only features, but
    so did the Emacs.app port: it's not a reason to reject it) if that
    port was significantly better, but from what I hear the difference
    is not large enough to motivate such a switch.


-- Stefan

Re: Emacs Mac port

[Konrad Podczeck]

The differences are not so minor: On MacOS Mojave, bug#32864 is still present with the NS port, which makes this port almost unusable, if one likes to work with menus. The Mac port, on the other hand, worked out of the box from the beginning when Mojave came out, without any problems.

Re: Emacs Mac port

[Van L]

>     did not get much support (as a general rule, while Emacs has many
>     MacOS users, it seems very few of them are interested in
>     contributing to fix bugs and improve the code :-( ).  I don't think
>     there'd be much resistance to switching the MacOS support code to
>     the one in the mac port (it might support MacOS-only features, but
>     so did the Emacs.app port: it's not a reason to reject it) if that

The mac port's daemon-server for gui/tty doesn't just work.
A fix there is sorely wanting. IME the mac port's configure, make is
able to find the image library directory whereas the source at origin complains
they are missing. Here is an opportunity for help both ways.

--
© 2019 Van L
gpg using EEF2 37E9 3840 0D5D 9183  251E 9830 384E 9683 B835
"The beauty of astronomy is that if you have a wrong idea
you can realise it because it is not just a factor of three
off it's like a factor 10 to the 24 off." - Massimo Stiavelli

Re: Emacs Mac port

[Jean-Christophe Helary]

> On Mar 23, 2019, at 3:11, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
> (as a general rule, while Emacs has many
>    MacOS users, it seems very few of them are interested in
>    contributing to fix bugs and improve the code :-(

Which is really too bad.

Even though I am not a programmer by any stretch of the imagination, my very first contribution to Emacs (and my first code in lisp too) was fixing a bug that involved the macOS Services dispatched from Emacs.

Regarding the macOS port, could Mitsuharu provide a list of items that he thinks should be ported to the mac port so as to remove the need for his current port ?

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Emacs Mac port

[Alan Third]

On Sat, Mar 23, 2019 at 09:15:32AM +0900, Jean-Christophe Helary wrote:
> 
> 
> > On Mar 23, 2019, at 3:11, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > 
> > (as a general rule, while Emacs has many
> >    MacOS users, it seems very few of them are interested in
> >    contributing to fix bugs and improve the code :-(

My suspicion is that Objective C coders on Mac all use XCode, and the
people using Emacs are web developers and so on.

> Regarding the macOS port, could Mitsuharu provide a list of items
> that he thinks should be ported to the mac port so as to remove the
> need for his current port ?

I don’t know the Mac port code base very well, so apologies in advance
if I accidentally slander it, but I think the NS port has the
potential to be a leaner, simpler port than the Mac port. To get there
it needs a lot of refactoring, and ideally it would drop support for
GNUstep, and possibly some older macOS versions. I’m finding it
increasingly difficult to maintain backwards compatibility,
particularly with things like fullscreen.

OTOH, WRT the massive refactoring: if it aint broke don’t fix it. And
if we did drop GNUstep it would, IMO, defeat the purpose, and we’d be
as well switching to the Mac port because...

The Mac port has a better maintainer than me, who knows the toolkit
and things better than I could ever hope to. It ties into macOS better
(I use very little macOS specific software, and the whole ‘services’
thing is a mystery to me, for example). It doesn’t have the Mojave
redraw problems that have me completely scunnered at the moment. It
handles concurrency better. It is simply better maintained.

But then again, the Mac port makes use of things that gcc doesn’t
support, like ObjC blocks, so that would probably rule it out as an
official port immediately.

The duplication of effort to maintain two ports seems like a waste to
me, but there are definitely barriers to joining forces and having
only one, official, port.

But Apple may solve this one for us anyway:

    https://www.theregister.co.uk/2019/03/20/macos_clampdown_rumors/
    
;)
-- 
Alan Third

Re: Emacs Mac port

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > (as a general rule, while Emacs has many
  > >    MacOS users, it seems very few of them are interested in
  > >    contributing to fix bugs and improve the code :-(

  > Which is really too bad.

We could encourage MacOS users to run Emacs, but that is not ideal.
What we really ought to encourage is that they switch from MacOS
to GNU/Linux.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs Mac port

[Van L]

> We could encourage MacOS users to run Emacs, but that is not ideal.
> What we really ought to encourage is that they switch from MacOS
> to GNU/Linux.

A way to reach out is to draw inspiration from the Hackers(1995) clip
of the scene where risc-v architecture is mentioned and on the table is
Emacs/i3wm demonstrated in 30 seconds.

Re: Emacs Mac port

[Charles A. Roelli]

> Date: Sat, 23 Mar 2019 11:57:14 +0000
> From: Alan Third <alan@idiocy.org>
> 
> I don’t know the Mac port code base very well, so apologies in advance
> if I accidentally slander it, but I think the NS port has the
> potential to be a leaner, simpler port than the Mac port. To get there
> it needs a lot of refactoring, and ideally it would drop support for
> GNUstep, and possibly some older macOS versions. I’m finding it
> increasingly difficult to maintain backwards compatibility,
> particularly with things like fullscreen.

I hope we can do at least one more release (Emacs 27) that supports
older macOS versions, since recent improvements (like your native
image scaling) work well on these versions.  We could then drop
support for the older macOS versions in Emacs 28.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 26.2 is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.2-mac-7.6.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

The fourth update of the Mac port based on Emacs 25.3 is also
available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-25.3-mac-6.11.tar.gz

The corresponding branch in the Git repository is "mac-25".

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

* emacs-26.2-mac-7.6 (2019-04-14)
Based on Emacs 26.2.

** Fixed bugs

*** Candidates window for input methods is often misplaced.
Add heuristics so it works in many cases including candidates windows
popped up during isearch.
We cannot make this placement strictly correct because of a timing
problem: the system asks for the cursor position while there are still
some pending Lisp events and the redisplay is not completed yet.

*** New Space is created when making a child frame visible while a
fullscreen frame is focused.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 26.3 release candidate 1 is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.3-rc1-mac-7.7.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

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

** Fixed bugs

*** The command move-tab-to-new-frame hangs.
Reported by JD Smith.

*** Dired on non-ASCII directories may cause an error if
file-name-coding-system set to utf-8-hfs-unix.
Reported by Sungbin Jo.
This is a regression introduced in 6.9.

*** (set-mouse-color "black") on Dark Mode makes the mouse pointer
invisible.

** Improvements

*** OpenType-SVG color fonts are drawn on macOS 10.14 and later.

*** New configure option --enable-mac-self-contained to have "make
install" create a self-contained bundle under the "mac" subdirectory.
(or the directory specified by --enable-mac-app[=DIR]).  The default
is off.
Contributed by Xin Xu.

\f
* emacs-26.2-mac-7.6 (2019-04-14)
Based on Emacs 26.2.
https://lists.gnu.org/r/emacs-devel/2019-04/msg00582.html

** Fixed bugs

*** Candidates window for input methods is often misplaced.
Add heuristics so it works in many cases including candidates windows
popped up during isearch.
We cannot make this placement strictly correct because of a timing
problem: the system asks for the cursor position while there are still
some pending Lisp events and the redisplay is not completed yet.

*** New Space is created when making a child frame visible while a
fullscreen frame is focused.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 26.3 is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.3-mac-7.7.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

No updates from the previous emacs-26.3-rc1-mac-7.7 other than release
notes.

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

On Thu, 29 Aug 2019 09:54:55 +0900,
YAMAMOTO Mitsuharu wrote:
> 
> The Mac port based on Emacs 26.3 is now available from
> 
>   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.3-mac-7.7.tar.gz
> 
> and Git repository is also available at
> 
>   https://bitbucket.org/mituharu/emacs-mac.git
> 
> No updates from the previous emacs-26.3-rc1-mac-7.7 other than release
> notes.

As far as I tested, the Mac port can be built and executed on macOS
10.15 Catalina, but you'll observe several glitches in animation
effects for unknown reasons (unlike previous releases, we don't have
AppKit Release Notes for macOS 10.15 yet).

A temporary workaround is either to build it on macOS 10.14 (make sure
you have the Command Line Developer Tools installed if you use Xcode
11) and use the resulting executable on macOS 10.15, or to specify a
fake linker option as

 $ make LD_SWITCH_SYSTEM=-Wl,-platform_version,macos,10.15.0,10.14

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The first update of the Mac port based on Emacs 26.3 is now available
from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.3-mac-7.8.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

The fifth update of the Mac port based on Emacs 25.3 is also
available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-25.3-mac-6.12.tar.gz

The corresponding branch in the Git repository is "mac-25".

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

* emacs-26.3-mac-7.8 (2019-12-03)

** Fixed bugs

*** mac-auto-operator-composition-mode does not compose sequences
containing "\".

*** Several animation effect glitches for executables linked on 10.15.

*** Can't switch application in Split View after resizing on macOS
10.14 and later.

*** Clicking "+" in tab group overview creates a new frame instead of
tab on macOS 10.15.

*** High CPU load on dialog display.
Reported by Konrad Podczeck.

*** Mouse pointer color is inverted on Dark Mode.
Though the old behavior is consistent with emacs -rv on X11, it was
actually introduced in version 7.2 as a workaround for the
(set-mouse-color "black") bug, which was fixed in the previous
version.  So the workaround is no longer necessary.

** Improvements

*** Resize transition is also in effect for unfocused frames in Split
View on macOS 10.15.

*** Improve typing response on application-side double buffering.

*** Recognize three-finger editing gestures in Sidecar on macOS 10.15.

Re: Emacs Mac port

[Pankaj Jangid]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
> The first update of the Mac port based on Emacs 26.3 is now available
> from
>
>   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.3-mac-7.8.tar.gz
>

Does it solve the problem of iCloud Directory permissions? This issue -
https://github.com/caldwell/build-emacs/issues/84 Regards,
-- 
Pankaj Jangid

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

On Tue, 03 Dec 2019 18:02:31 +0900,
Pankaj Jangid wrote:
> 
> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
> > The first update of the Mac port based on Emacs 26.3 is now available
> > from
> >
> >   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.3-mac-7.8.tar.gz
> >
> 
> Does it solve the problem of iCloud Directory permissions? This issue -
> https://github.com/caldwell/build-emacs/issues/84 Regards,

I've never seen this issue on the Mac port.  It pops up a dialog
asking for permission to access the directory on the first attempt.

Did you experience this issue on some older version of the Mac port?

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

Re: Emacs Mac port

[VanL]

An earlier version of emacs-mac-app had the ability to fill
½-fullscreen on long press of the maximize button. The current
version does not do that.

--->  Installing emacs-mac-app @7.8_1+rsvg
--->  Activating emacs-mac-app @7.8_1+rsvg

Re: Emacs Mac port

[Pankaj Jangid]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>> > The first update of the Mac port based on Emacs 26.3 is now
>> > available from
>> >   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.3-mac-7.8.tar.gz
>> Does it solve the problem of iCloud Directory permissions? This issue
>> - https://github.com/caldwell/build-emacs/issues/84 Regards,
>
> I've never seen this issue on the Mac port.  It pops up a dialog
> asking for permission to access the directory on the first attempt.
>
> Did you experience this issue on some older version of the Mac port?

Actually, I was confused. I was talking about the build which is
distributed via [[https://emacsformacosx.com/]] website. This build uses
ruby wrappers and the issue occurs because of that.

Your build is plain emacs build directly from the official emacs git
repository. This build works fine.

Regards,
-- 
Pankaj Jangid

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

On Wed, 04 Dec 2019 19:45:36 +0900,
VanL wrote:
> 
> 
> An earlier version of emacs-mac-app had the ability to fill
> ½-fullscreen on long press of the maximize button. The current
> version does not do that.
> 
> --->  Installing emacs-mac-app @7.8_1+rsvg
> --->  Activating emacs-mac-app @7.8_1+rsvg

Works here.  Which version of macOS are you using?
Is it reproducible without any customizations?
(say, $ open /Applications/MacPorts/EmacsMac.app --args -Q)
If so, please describe concrete steps to reproduce, together with
expected and actual results.

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

On Wed, 04 Dec 2019 21:09:20 +0900,
Pankaj Jangid wrote:
> 
> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
> >> > The first update of the Mac port based on Emacs 26.3 is now
> >> > available from
> >> >   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.3-mac-7.8.tar.gz
> >> Does it solve the problem of iCloud Directory permissions? This issue
> >> - https://github.com/caldwell/build-emacs/issues/84 Regards,
> >
> > I've never seen this issue on the Mac port.  It pops up a dialog
> > asking for permission to access the directory on the first attempt.
> >
> > Did you experience this issue on some older version of the Mac port?
> 
> Actually, I was confused. I was talking about the build which is
> distributed via [[https://emacsformacosx.com/]] website. This build uses
> ruby wrappers and the issue occurs because of that.
> 
> Your build is plain emacs build directly from the official emacs git
> repository. This build works fine.

No.  You are referring to the NS port.  The Mac port is not a modified
version of the NS port, but a different GUI implementation on macOS.
They have different designs, policies, and histories.

NS port-specific Obj-C files and LOC (as of Emacs 26.3):

    1514 nsfont.m
     197 nsgui.h
     513 nsimage.m
    1893 nsmenu.m
     511 nsselect.m
    1323 nsterm.h
    9460 nsterm.m
   18754 total

Mac port-specific C/Obj-C files and LOC (as of Emacs 26.3 Mac 7.8):

    3237 mac.c
    1436 macappkit.h
   17097 macappkit.m
    5434 macfns.c
     279 macgui.h
     896 macmenu.c
    1141 macselect.c
    6326 macterm.c
     793 macterm.h
   36639 total

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

Re: Emacs Mac port

[Pankaj Jangid]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
> No.  You are referring to the NS port.  The Mac port is not a modified
> version of the NS port, but a different GUI implementation on macOS.
> They have different designs, policies, and histories.
>
> NS port-specific Obj-C files and LOC (as of Emacs 26.3):
>
>     1514 nsfont.m
>      197 nsgui.h
>      513 nsimage.m
>     1893 nsmenu.m
>      511 nsselect.m
>     1323 nsterm.h
>     9460 nsterm.m
>    18754 total
>
> Mac port-specific C/Obj-C files and LOC (as of Emacs 26.3 Mac 7.8):
>
>     3237 mac.c
>     1436 macappkit.h
>    17097 macappkit.m
>     5434 macfns.c
>      279 macgui.h
>      896 macmenu.c
>     1141 macselect.c
>     6326 macterm.c
>      793 macterm.h
>    36639 total

Okay I didn't know this as well. But the problem that I was referring to
was specific to the build distributed from
[[https://emacsformacosx.com/]]. This is NS build with some ruby
wrappers.

I have built my own NS build and that works as expected with the new
MacOS permissions.

Regards,
-- 
Pankaj Jangid

Re: Emacs Mac port

[VanL]

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

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

>> An earlier version of emacs-mac-app had the ability to fill
>> ½-fullscreen on long press of the maximize button. The current
>> version does not do that.
>> 
>> --->  Installing emacs-mac-app @7.8_1+rsvg
>> --->  Activating emacs-mac-app @7.8_1+rsvg
>
> Works here.  Which version of macOS are you using?
> Is it reproducible without any customizations?
> (say, $ open /Applications/MacPorts/EmacsMac.app --args -Q)

Starting EmacsMac.app as suggested allows the expected, desired
behavior.

The macOS version string is
GNU Emacs 26.3 (build 1, x86_64-apple-darwin15.6.0, Carbon Version 157 AppKit 1404.47)
 of 2019-12-04

Something in my customization has introduced the undesired behavior.


[-- Attachment #2: undesired behavior introduced in emacs customization --]
[-- Type: application/emacs-lisp, Size: 4894 bytes --]

Re: Emacs Mac port

[VanL]

VanL <van@scratch.space> writes:

>> (say, $ open /Applications/MacPorts/EmacsMac.app --args -Q)
>
> Starting EmacsMac.app as suggested allows the expected, desired
> behavior.
>
> Something in my customization has introduced the undesired behavior.

Commenting out '(menu-bar-mode nil) returns the expected, desired
behavior.

#+BEGIN_SRC emacs-lisp
  (custom-set-variables
   ;; custom-set-variables was added by Custom.
   ;; If you edit it by hand, you could mess it up, so be careful.
   ;; Your init file should contain only one such instance.
   ;; If there is more than one, they won't work right.
   '(canlock-password "600dcbcafd9de585fe73fa9e0b97b5bec1f2dab1")
   '(display-buffer-reuse-frames t)
   '(electric-indent-mode nil)
   '(epa-pinentry-mode (quote loopback))
   '(gnus-summary-line-format "%U%R%z%I%(%[%4L: %-2,2f%]%) %s
  ")
   '(mac-command-modifier (quote alt))
   '(mac-option-modifier (quote meta))
   '(mac-right-command-modifier (quote super))
   '(mac-right-option-modifier (quote hyper))
  ;; '(menu-bar-mode nil) ;; xxx
   '(org-return-follows-link t)
   '(ring-bell-function (quote ignore))
   '(safe-local-variable-values (quote ((eval auto-revert-mode t))))
   '(same-window-buffer-names (quote ("*vc-diff*" "*vc-change-log*")))
   '(scroll-bar-mode nil)
   '(tool-bar-mode nil))

#+END_SRC

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The second update of the Mac port based on Emacs 26.3 is now available
from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.3-mac-7.9.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

The sixth update of the Mac port based on Emacs 25.3 is also
available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-25.3-mac-6.13.tar.gz

The corresponding branch in the Git repository is "mac-25".

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

* emacs-26.3-mac-7.9 (2020-03-23)

** Fixed bugs

*** Crash by a file descriptor that is greater than or equal to
FD_SETSIZE.

*** Can't unexec on macOS 10.15.4.

*** Crash when editing iCloud Drive files on macOS 10.15 - 10.15.3.
This is due to Mach port leaks on these versions.  A workaround is
added, and proxy icons are not shown for iCloud Drive files.

*** Selecting a menu item having submenus generates a prefix event.
Reported by Konrad Podczeck.

** Improvements

*** Update emoji data to version 13.0.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

On Mon, 23 Mar 2020 14:34:57 +0900,
YAMAMOTO Mitsuharu wrote:
> 
> The second update of the Mac port based on Emacs 26.3 is now available
> from
> 
>   ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.3-mac-7.9.tar.gz
> 
> and Git repository is also available at
> 
>   https://bitbucket.org/mituharu/emacs-mac.git

The "work" branch of the repository is now based on Emacs 27.0.90.
Still in early development.

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

Re: Emacs Mac port

[HaiJun Zhang]

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

It seems that “—without-makeinfo” for configure doesn’t has effect while It works well for the origin emacs-26.

在 2020年3月24日 +0800 AM11:26，YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>，写道：
> On Mon, 23 Mar 2020 14:34:57 +0900,
> YAMAMOTO Mitsuharu wrote:
> >
> > The second update of the Mac port based on Emacs 26.3 is now available
> > from
> >
> > ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-26.3-mac-7.9.tar.gz
> >
> > and Git repository is also available at
> >
> > https://bitbucket.org/mituharu/emacs-mac.git
>
> The "work" branch of the repository is now based on Emacs 27.0.90.
> Still in early development.
>
> YAMAMOTO Mitsuharu
> mituharu@math.s.chiba-u.ac.jp
>

[-- Attachment #2: Type: text/html, Size: 1350 bytes --]

Re: Emacs Mac port

[Eli Zaretskii]

> Date: Sat, 4 Apr 2020 19:22:33 +0800
> From: HaiJun Zhang <netjune@outlook.com>
> 
> It seems that “—without-makeinfo” for configure doesn’t has effect while It works well for the origin
> emacs-26. 

Why do you need that option?  If the manuals in the Info format are
part of the tarball, you will not need to run makeinfo anyway.

And please also show the error messages or any other manifestations of
the problem.

Re: Emacs Mac port

[HaiJun Zhang]

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

Sorry. Please ignore the it. It is because my manual configure failed. The configure command:

./configure —with-mac --with-modules --disable-acl --without-makeinfo CFLAGS="-O2 -g0"

The error message:
————————————————
config.status: creating src/config.h
config.status: executing src/epaths.h commands
make: *** No rule to make target `epaths-force’. Stop.
config.status: error: ‘src/epaths.h’ could not be made.
————————————————-


在 2020年4月4日 +0800 PM7:34，Eli Zaretskii <eliz@gnu.org>，写道：
> > Date: Sat, 4 Apr 2020 19:22:33 +0800
> > From: HaiJun Zhang <netjune@outlook.com>
> >
> > It seems that “—without-makeinfo” for configure doesn’t has effect while It works well for the origin
> > emacs-26.
>
> Why do you need that option? If the manuals in the Info format are
> part of the tarball, you will not need to run makeinfo anyway.
>

It is because the makeinfo command on macOS is too old to make.


[-- Attachment #2: Type: text/html, Size: 1960 bytes --]

Re: Emacs Mac port

[HaiJun Zhang]

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

在 2020年4月4日 +0800 PM7:46，HaiJun Zhang <netjune@outlook.com>，写道：
> Sorry. Please ignore the it. It is because my manual configure failed. The configure command:
>
> ./configure —with-mac --with-modules --disable-acl --without-makeinfo CFLAGS="-O2 -g0"
>
> The error message:
> ————————————————
> config.status: creating src/config.h
> config.status: executing src/epaths.h commands
> make: *** No rule to make target `epaths-force’. Stop.
> config.status: error: ‘src/epaths.h’ could not be made.
> ————————————————-
>

[You can ignore this message.]

Things just happened:

My manual configure failed and the error message was not noticable so I didn’t notice it. Then I run ‘make’. It triggered the default configure without “—without-makeinfo” and the makeinfo on macOS is too old. So the configure failed again with following message:

—————————————————-
configure: error: You do not seem to have makeinfo >= 4.13, and your
source tree does not seem to have pre-built manuals in the ‘info’ directory.
Either install a suitable version of makeinfo, or re-run configure
with the ‘—without-makeinfo’ option to build without the manuals.
——————————————————

This made me thought that “—without-makeinfo” has no effect.


[-- Attachment #2: Type: text/html, Size: 2589 bytes --]

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 27.1 is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-27.1-mac-8.0.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

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

** Fixed bugs

*** Raising a child frame is no-op and lowering it lowers the parent.

*** Crash when creating a GUI frame on macOS Big Sur Beta.

** Improvements

*** image-multi-frame-p also works for HEIC Sequences (macOS 10.15 and
later) and WebP animations (macOS 11.0 and later).

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The first update of the Mac port based on Emacs 27.1 is now available
from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-27.1-mac-8.1.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

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

** Fixed bugs

*** Crash when emacs --daemon is connected from emacsclient -t.
Reported by Akinori MUSHA.

*** Hang when preparing the menu bar on macOS Big Sur.

** Improvements

*** Use system symbols as tool bar icons on macOS Big Sur.

*** Update emoji data to version 13.1.

*** The image type `image-io' (and its `imagemagick' fallback) now
supports SVG with scaling, cropping, and arbitrary rotation.

Re: Emacs Mac port

[Jean Louis]

* YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> [2020-11-12 11:10]:
> *** The image type `image-io' (and its `imagemagick' fallback) now
> supports SVG with scaling, cropping, and arbitrary rotation.

That sounds good. Is that something you will bring to main stream
Emacs too? Or maybe as a package?

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

On Thu, 12 Nov 2020 17:34:32 +0900,
Jean Louis wrote:
> 
> * YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> [2020-11-12 11:10]:
> > *** The image type `image-io' (and its `imagemagick' fallback) now
> > supports SVG with scaling, cropping, and arbitrary rotation.
> 
> That sounds good. Is that something you will bring to main stream
> Emacs too? Or maybe as a package?

The mainstream Emacs already supports it if compiled with the
ImageMagick support (though it is no longer the default).

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

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 27.2 is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-27.2-mac-8.2.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

If you build from the repository on M1 Mac with newer autoconf, then
you will need to do "git restore build-aux" after "./autogen.sh".

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

The configure option --with-mac-metal is disabled by default.
I originally turned it on because it lowered the CPU load.
But I recently realized that it was caused by its lower frame rate.
M1 Mac accomplishes 60fps with or without Metal even with large
frames, and the CPU load does not get an advantage from the use of
Metal there.

** Fixed bugs

*** Some light weight fonts are not recognized on Big Sur.
Contributed by Frank Patz-Brockmann.

*** Crash when displaying multiple SVG images on High Sierra/Mojave.
Reported by Adam Sneller.

*** Unintended frame switch when showing hourglasses.
Reported by JD Smith.

*** Crash if the stack size limit is not a multiple of page size.
Reported by Christos Kalkanis.

*** Scroll by scroll bar slot press is too fast on Catalina and later.

*** org-protocol does not open file when there is file-path returned.
Contributed by Shi Schspa.

*** Sometimes hexadecimal color name is not recognized.
Reported by Nicolas P. Rougier.

*** Changing tool bar icon size from context menu clobbers display.

** Improvements

*** New hook mac-effective-appearance-change-hook.
Contributed by Peter Hardy.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The first update of the Mac port based on Emacs 27.2 is now available
from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-27.2-mac-8.3.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

If you build from the repository on M1 Mac with newer autoconf, then
you will need to do "git restore build-aux" after "./autogen.sh".

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

** Fixed bugs

*** Frame may become blank with rapid repetitive zoomings.

*** Frame may become blank with isearch if the executable is compiled
with SDK 10.15 or earlier and runs on some later versions of macOS 11,
or NSWindowSupportsAutomaticInlineTitle is set to NO on macOS 11.
Note: NSWindowSupportsAutomaticInlineTitle has no effect on macOS 12.

** Improvements

*** Incorporate process creation code that uses posix_spawn.
This is a workaround for slow process creation on macOS 12, where
vfork is declared deprecated and mostly identical to fork.  The new
process creation code is incorporated from the posix-spawn-no-gnulib
branch upstream, and enabled by default on macOS 10.15 and later.  If
you have a problem with this new code, then set the variable
darwin-try-posix-spawn to nil so as to revert to the original one.

*** Avoid copying whole bitmap in application-side double buffering.

*** Update emoji data to version 14.0.

*** Live resize transition animation takes account of tab bar area.

Re: Emacs Mac port

[Jean-Christophe Helary]

It looks like make && make install does require a few sudos.

Is that expected ?

Jean-Christophe 

> On Nov 13, 2021, at 16:51, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:
> 
> The first update of the Mac port based on Emacs 27.2 is now available
> from
> 
>  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-27.2-mac-8.3.tar.gz
> 
> and Git repository is also available at
> 
>  https://bitbucket.org/mituharu/emacs-mac.git

Re: Emacs Mac port

[Po Lu]

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

> The first update of the Mac port based on Emacs 27.2 is now available
> from

Hello, Yamamoto.

I recently implemented support for pixel deltas in wheel events on X,
and I've been trying to implement pixel scrolling support based on that.

I haven't been able to write or find any Lisp code for that which runs
faster than the code in mac-term.el, but AFAIU it hasn't undergone
copyright assignment and can't be included in Emacs.

Would you be interested in contributing that code to Emacs proper?

Thanks!

Re: Emacs Mac port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 22 Nov 2021 21:33:35 +0800
> 
> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
> 
> > The first update of the Mac port based on Emacs 27.2 is now available
> > from
> 
> Hello, Yamamoto.
> 
> I recently implemented support for pixel deltas in wheel events on X,
> and I've been trying to implement pixel scrolling support based on that.
> 
> I haven't been able to write or find any Lisp code for that which runs
> faster than the code in mac-term.el, but AFAIU it hasn't undergone
> copyright assignment and can't be included in Emacs.

Yamamoto-san has a copyright assignment on file, so if he wrote that
file, it can be included in Emacs with no problems.

> Would you be interested in contributing that code to Emacs proper?

We do want the confirmation of the contribution, though.

TIA

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

On Mon, 22 Nov 2021 23:55:51 +0900,
Eli Zaretskii wrote:
> 
> > From: Po Lu <luangruo@yahoo.com>
> > Cc: emacs-devel@gnu.org
> > Date: Mon, 22 Nov 2021 21:33:35 +0800
> > 
> > YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
> > 
> > > The first update of the Mac port based on Emacs 27.2 is now available
> > > from
> > 
> > Hello, Yamamoto.
> > 
> > I recently implemented support for pixel deltas in wheel events on X,
> > and I've been trying to implement pixel scrolling support based on that.
> > 
> > I haven't been able to write or find any Lisp code for that which runs
> > faster than the code in mac-term.el, but AFAIU it hasn't undergone
> > copyright assignment and can't be included in Emacs.
> 
> Yamamoto-san has a copyright assignment on file, so if he wrote that
> file, it can be included in Emacs with no problems.
> 
> > Would you be interested in contributing that code to Emacs proper?
> 
> We do want the confirmation of the contribution, though.

No contribution from others for the pixel-based mouse wheel smooth
scrolling code in the Mac port.  So, feel free to use it.

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

Re: Emacs Mac port

[Po Lu]

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

> No contribution from others for the pixel-based mouse wheel smooth
> scrolling code in the Mac port.  So, feel free to use it.

Thanks!

Re: Emacs Mac port

[Eli Zaretskii]

> Date: Tue, 23 Nov 2021 15:16:21 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org
> 
> > We do want the confirmation of the contribution, though.
> 
> No contribution from others for the pixel-based mouse wheel smooth
> scrolling code in the Mac port.  So, feel free to use it.

Thank you.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 28.1 is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-28.1-mac-9.0.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

The second update of the Mac port based on Emacs 27.2 is also
available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-27.2-mac-8.4.tar.gz

The corresponding branch in the Git repository is `mac-27'.

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

Drop support for Mac OS X 10.6 - OS X 10.9.
Emoji composition handling is aligned with upstream.  You may find
some incompatibilities with the previous versions.

** Fixed bugs

*** Rotated SVG is clipped when dimension is specified by percentage.

*** Typing F10 on a full-screen frame causes hang on Monterey.
Reported by Brandon Bremen.
It no longer hangs, but still F10 does not activate the menu bar for a
full-screen frame on Monterey if the "Automatically hide and show the
menu bar in full screen" setting is checked (default).

*** When posix_spawn is used, emacs-gdb doesn't work properly.
Apply a fix for Bug#54667.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

The Mac port based on Emacs 28.2 is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-28.2-mac-9.1.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

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

Based on Emacs 28.2.

** Fixed bugs

*** DJVU to TIFF converter in DocView does not properly support @2x.

*** SVG rendering via WebKit 2 does not support local file references.
Reported by Howard Melman.

Re: Emacs Mac port

[YAMAMOTO Mitsuharu]

**********************************************************************
This is an announcement of the release of the Mac port of GNU Emacs.
It is not provided by the official Emacs project, unlike the macOS GUI
support via the NextStep port.  They are different in feature sets,
development policy, design, and history.
**********************************************************************

The Mac port based on Emacs 29.1 is now available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-29.1-mac-10.0.tar.gz

and Git repository is also available at

  https://bitbucket.org/mituharu/emacs-mac.git

The Mac port based on Emacs 28.3 Release Candidate 1 is also
available from

  ftp://ftp.math.s.chiba-u.ac.jp/emacs/emacs-28.3-rc1-mac-9.2.tar.gz

The corresponding branch in the Git repository is `mac-28'.

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

* emacs-29.1-mac-10.0 (2023-08-05)
Based on Emacs 29.1.
Currently, pixel-based mouse wheel smooth scrolling and pinch gesture
are supported via traditional Mac port code rather than newly-added
upstream one.  This may change in a future version.
WebP image support does not require libwebp on macOS 11 and later.

** Fixed bugs

*** Wrong live resize transition and export to PDF on macOS 14 Beta.


* emacs-28.3-rc1-mac-9.2 (2023-08-02)
Based on Emacs 28.3 Release Candidate.

** Fixed bugs

*** mouse-drag-and-drop-region across frames does not work.

*** Selection is not properly converted to filename pasteboard data.

*** Wrong sign extension in converting Apple Event bytes to integer.

*** Freeze on macOS 12 and later when waking up from sleep with a
fullscreen frame on a secondary display.
Reported by Willem Leitso.

*** Wrong animation effect on macOS 13.