Discussion:
Emacs Mac port
(too old to reply)
YAMAMOTO Mitsuharu
2012-06-10 09:29:26 UTC
Permalink
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
***@math.s.chiba-u.ac.jp
Paul Michael Reilly
2012-06-11 00:36:04 UTC
Permalink
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 <
***@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
> ***@math.s.chiba-u.ac.jp
>
>
YAMAMOTO Mitsuharu
2012-06-11 07:29:51 UTC
Permalink
>>>>> On Sun, 10 Jun 2012 18:29:26 +0900, YAMAMOTO Mitsuharu <***@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
***@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)))
Donald Curtis
2012-07-07 18:10:17 UTC
Permalink
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 <***@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
> ***@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)))
>
>
Donald Curtis
2012-07-07 18:13:04 UTC
Permalink
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 <***@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
>> ***@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)))
>>
>>
>
Richard Stallman
2012-07-08 11:15:30 UTC
Permalink
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
Samuel Bronson
2012-07-08 14:16:08 UTC
Permalink
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...
Stefan Monnier
2012-07-08 14:54:05 UTC
Permalink
> Oh, hush! Nobody really cares in everyday conversation...

We do here,


Stefan
Donald Curtis
2012-07-08 14:58:06 UTC
Permalink
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 <***@iro.umontreal.ca> wrote:

>> Oh, hush! Nobody really cares in everyday conversation...
>
> We do here,
>
>
> Stefan
YAMAMOTO Mitsuharu
2012-07-26 09:45:11 UTC
Permalink
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
***@math.s.chiba-u.ac.jp
YAMAMOTO Mitsuharu
2012-07-26 21:50:22 UTC
Permalink
>>>>> On Thu, 26 Jul 2012 18:45:11 +0900, YAMAMOTO Mitsuharu <***@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
***@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);
}
}
YAMAMOTO Mitsuharu
2012-08-08 06:01:04 UTC
Permalink
>>>>> On Thu, 26 Jul 2012 18:45:11 +0900, YAMAMOTO Mitsuharu <***@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
***@math.s.chiba-u.ac.jp
YAMAMOTO Mitsuharu
2012-08-27 07:40:10 UTC
Permalink
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
***@math.s.chiba-u.ac.jp
YAMAMOTO Mitsuharu
2012-09-06 01:35:44 UTC
Permalink
>>>>> On Mon, 27 Aug 2012 16:40:10 +0900, YAMAMOTO Mitsuharu <***@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
***@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;
}
YAMAMOTO Mitsuharu
2012-09-18 09:37:17 UTC
Permalink
>>>>> On Mon, 27 Aug 2012 16:40:10 +0900, YAMAMOTO Mitsuharu <***@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
***@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 ----
YAMAMOTO Mitsuharu
2012-09-20 08:51:44 UTC
Permalink
>>>>> On Mon, 27 Aug 2012 16:40:10 +0900, YAMAMOTO Mitsuharu <***@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
***@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
YAMAMOTO Mitsuharu
2012-10-27 04:57:44 UTC
Permalink
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
***@math.s.chiba-u.ac.jp
YAMAMOTO Mitsuharu
2012-11-25 07:26:41 UTC
Permalink
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
***@math.s.chiba-u.ac.jp
Leo
2012-11-25 10:39:59 UTC
Permalink
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
chad
2012-11-25 10:59:55 UTC
Permalink
On 25 Nov 2012, at 02:39, Leo <***@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
Leo
2012-11-25 12:05:45 UTC
Permalink
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
YAMAMOTO Mitsuharu
2012-11-26 03:26:49 UTC
Permalink
>>>>> On Sun, 25 Nov 2012 18:39:59 +0800, Leo <***@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
***@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))
Glenn Morris
2012-11-25 19:05:59 UTC
Permalink
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.
Leo
2012-11-26 02:14:43 UTC
Permalink
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
John Wiegley
2012-11-26 02:46:28 UTC
Permalink
>>>>> Leo <***@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
Stefan Monnier
2012-11-26 20:38:35 UTC
Permalink
>> 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
chad
2012-11-26 21:46:10 UTC
Permalink
On 26 Nov 2012, at 12:38, Stefan 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
Leo
2012-11-27 02:35:27 UTC
Permalink
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
Jan Djärv
2012-11-27 04:32:44 UTC
Permalink
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 <***@MIT.EDU>:

> On 26 Nov 2012, at 12:38, Stefan 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>
>
>
chad
2012-11-27 19:33:19 UTC
Permalink
On 26 Nov 2012, at 20:32, Jan Djärv <***@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
Donald Curtis
2012-12-01 14:04:05 UTC
Permalink
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 <***@MIT.EDU> wrote:

> On 26 Nov 2012, at 20:32, Jan Djärv <***@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
Jan Djärv
2012-12-03 18:58:59 UTC
Permalink
Hello.

1 dec 2012 kl. 15:04 skrev Donald Curtis <***@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.
Leo
2012-11-27 02:34:25 UTC
Permalink
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
YAMAMOTO Mitsuharu
2012-12-16 05:07:42 UTC
Permalink
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
***@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.
YAMAMOTO Mitsuharu
2013-01-11 07:28:00 UTC
Permalink
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
***@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).
YAMAMOTO Mitsuharu
2013-02-09 07:26:01 UTC
Permalink
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
***@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.
Piotr Kalinowski
2013-02-11 12:53:45 UTC
Permalink
YAMAMOTO Mitsuharu <***@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
> ***@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
Pavlo Martynenko
2013-02-14 12:02:08 UTC
Permalink
On 9 Feb 2013, at 09:26, YAMAMOTO Mitsuharu <***@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
> ***@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.
>
Piotr Kalinowski
2013-02-15 15:48:11 UTC
Permalink
Pavlo Martynenko <***@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.
Dmitry Antipov
2013-02-15 16:03:20 UTC
Permalink
On 02/15/2013 07:48 PM, Piotr Kalinowski wrote:

> Pavlo Martynenko <***@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
Eli Zaretskii
2013-02-15 18:16:13 UTC
Permalink
> Date: Fri, 15 Feb 2013 20:03:20 +0400
> From: Dmitry Antipov <***@yandex.ru>
> Cc: ***@gmail.com, emacs-***@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.
Glenn Morris
2013-02-15 19:27:32 UTC
Permalink
>>> 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.
YAMAMOTO Mitsuharu
2013-02-16 06:46:00 UTC
Permalink
>>>>> On Thu, 14 Feb 2013 14:02:08 +0200, Pavlo Martynenko <***@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
***@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;
YAMAMOTO Mitsuharu
2013-02-16 08:21:35 UTC
Permalink
>>>>> On Sat, 16 Feb 2013 15:46:00 +0900, YAMAMOTO Mitsuharu <***@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
***@math.s.chiba-u.ac.jp
YAMAMOTO Mitsuharu
2013-02-16 11:08:51 UTC
Permalink
>>>>> On Sat, 16 Feb 2013 17:21:35 +0900, YAMAMOTO Mitsuharu <***@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
***@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
YAMAMOTO Mitsuharu
2013-03-05 06:02:37 UTC
Permalink
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
***@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.
YAMAMOTO Mitsuharu
2013-03-11 03:41:13 UTC
Permalink
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
***@math.s.chiba-u.ac.jp

** Fixed bugs

*** Smooth scrolling down the fancy splash screen causes an error.
YAMAMOTO Mitsuharu
2013-04-11 09:22:54 UTC
Permalink
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
***@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.
YAMAMOTO Mitsuharu
2013-04-14 06:31:05 UTC
Permalink
>>>>> On Thu, 11 Apr 2013 18:22:54 +0900, YAMAMOTO Mitsuharu <***@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
***@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)
Eli Zaretskii
2013-04-14 11:49:56 UTC
Permalink
> Date: Sun, 14 Apr 2013 15:31:05 +0900
> From: YAMAMOTO Mitsuharu <***@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.
YAMAMOTO Mitsuharu
2013-04-15 02:17:20 UTC
Permalink
>>>>> On Sun, 14 Apr 2013 14:49:56 +0300, Eli Zaretskii <***@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
***@math.s.chiba-u.ac.jp
Eli Zaretskii
2013-04-15 05:44:04 UTC
Permalink
> Date: Mon, 15 Apr 2013 11:17:20 +0900
> From: YAMAMOTO Mitsuharu <***@math.s.chiba-u.ac.jp>
> Cc: emacs-***@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).
YAMAMOTO Mitsuharu
2013-04-15 07:59:31 UTC
Permalink
>>>>> On Mon, 15 Apr 2013 08:44:04 +0300, Eli Zaretskii <***@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
***@math.s.chiba-u.ac.jp
Eli Zaretskii
2013-04-15 08:55:34 UTC
Permalink
> Date: Mon, 15 Apr 2013 16:59:31 +0900
> From: YAMAMOTO Mitsuharu <***@math.s.chiba-u.ac.jp>
> Cc: emacs-***@gnu.org
>
> >>>>> On Mon, 15 Apr 2013 08:44:04 +0300, Eli Zaretskii <***@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.
YAMAMOTO Mitsuharu
2013-04-15 09:48:29 UTC
Permalink
>>>>> On Mon, 15 Apr 2013 11:55:34 +0300, Eli Zaretskii <***@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
***@math.s.chiba-u.ac.jp
Eli Zaretskii
2013-04-15 10:57:14 UTC
Permalink
> Date: Mon, 15 Apr 2013 18:48:29 +0900
> From: YAMAMOTO Mitsuharu <***@math.s.chiba-u.ac.jp>
> Cc: emacs-***@gnu.org
>=20
> > I'm still interested to know why this cannot be done entirely in =
the
> > display back-end.
>=20
> I'm using the "expose" handler for recovering the display contents
> through invalidation, because that is really what it is for.
>=20
> 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=E9"
> (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))
>=20
> 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.
>=20
> > And yet we don't see the result on any other platform.
>=20
> 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 firs=
t
place. Platform-specific pixel-level drawing shouldn't IMO be expose=
d
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 i=
n
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 behavi=
or
> is wrong and the fix should be done in the platform-independent par=
t
> 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.
YAMAMOTO Mitsuharu
2013-04-16 00:17:33 UTC
Permalink
>>>>> On Mon, 15 Apr 2013 13:57:14 +0300, Eli Zaretskii <***@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
***@math.s.chiba-u.ac.jp
YAMAMOTO Mitsuharu
2013-04-16 02:11:40 UTC
Permalink
>>>>> On Tue, 16 Apr 2013 09:17:33 +0900, YAMAMOTO Mitsuharu <***@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.
Eli Zaretskii
2013-04-16 06:49:17 UTC
Permalink
> Date: Tue, 16 Apr 2013 09:17:33 +0900
> From: YAMAMOTO Mitsuharu <***@math.s.chiba-u.ac.jp>
> Cc: emacs-***@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.
YAMAMOTO Mitsuharu
2013-04-16 10:15:45 UTC
Permalink
>>>>> On Tue, 16 Apr 2013 09:49:17 +0300, Eli Zaretskii <***@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
***@math.s.chiba-u.ac.jp
YAMAMOTO Mitsuharu
2013-04-16 10:48:22 UTC
Permalink
>>>>> On Tue, 16 Apr 2013 19:15:45 +0900, YAMAMOTO Mitsuharu <***@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
***@math.s.chiba-u.ac.jp
Stefan Monnier
2013-04-16 13:20:15 UTC
Permalink
> 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
Eli Zaretskii
2013-04-16 14:38:17 UTC
Permalink
> From: Stefan Monnier <***@iro.umontreal.ca>
> Cc: Eli Zaretskii <***@gnu.org>, emacs-***@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.
YAMAMOTO Mitsuharu
2013-04-16 23:52:31 UTC
Permalink
>>>>> On Tue, 16 Apr 2013 09:20:15 -0400, Stefan 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
***@math.s.chiba-u.ac.jp

>>>>> On Thu, 15 Jul 2010 12:00:05 -0400, Chong Yidong <***@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.
Jan Djärv
2013-04-17 05:08:25 UTC
Permalink
17 apr 2013 kl. 01:52 skrev YAMAMOTO Mitsuharu <***@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.
YAMAMOTO Mitsuharu
2013-04-17 05:46:41 UTC
Permalink
>>>>> On Wed, 17 Apr 2013 07:08:25 +0200, Jan Djärv <***@swipnet.se> said:

> 17 apr 2013 kl. 01:52 skrev YAMAMOTO Mitsuharu <***@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
***@math.s.chiba-u.ac.jp
Jan Djärv
2013-04-17 06:36:25 UTC
Permalink
Hello.

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

>>>>>> On Wed, 17 Apr 2013 07:08:25 +0200, Jan Djärv <***@swipnet.se> said:
>
>> 17 apr 2013 kl. 01:52 skrev YAMAMOTO Mitsuharu <***@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.
YAMAMOTO Mitsuharu
2013-04-19 03:58:17 UTC
Permalink
>>>>> On Wed, 17 Apr 2013 08:36:25 +0200, Jan Djärv <***@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
***@math.s.chiba-u.ac.jp
Jan Djärv
2013-04-19 07:08:47 UTC
Permalink
Hello.

19 apr 2013 kl. 05:58 skrev YAMAMOTO Mitsuharu <***@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.
Nix
2013-04-22 08:54:33 UTC
Permalink
On 16 Apr 2013, YAMAMOTO Mitsuharu stated:

>>>>>> On Tue, 16 Apr 2013 09:49:17 +0300, Eli Zaretskii <***@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)
YAMAMOTO Mitsuharu
2013-04-23 03:18:33 UTC
Permalink
>>>>> On Mon, 22 Apr 2013 09:54:33 +0100, 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
***@math.s.chiba-u.ac.jp
YAMAMOTO Mitsuharu
2013-04-17 01:09:43 UTC
Permalink
>>>>> On Mon, 15 Apr 2013 18:48:29 +0900, YAMAMOTO Mitsuharu <***@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
***@math.s.chiba-u.ac.jp
YAMAMOTO Mitsuharu
2013-05-11 06:43:30 UTC
Permalink
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
***@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).
YAMAMOTO Mitsuharu
2013-09-21 09:23:50 UTC
Permalink
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
***@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.
YAMAMOTO Mitsuharu
2013-10-24 08:40:09 UTC
Permalink
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
***@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)'.
Leo Liu
2013-10-24 09:47:13 UTC
Permalink
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
> ***@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
YAMAMOTO Mitsuharu
2013-10-24 10:18:57 UTC
Permalink
>>>>> On Thu, 24 Oct 2013 17:47:13 +0800, Leo Liu <***@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
***@math.s.chiba-u.ac.jp
YAMAMOTO Mitsuharu
2013-10-25 00:56:56 UTC
Permalink
>>>>> On Thu, 24 Oct 2013 19:18:57 +0900, YAMAMOTO Mitsuharu <***@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
***@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
YAMAMOTO Mitsuharu
2013-10-25 04:38:58 UTC
Permalink
>>>>> On Thu, 24 Oct 2013 19:18:57 +0900, YAMAMOTO Mitsuharu <***@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
***@math.s.chiba-u.ac.jp
YAMAMOTO Mitsuharu
2013-10-27 06:42:07 UTC
Permalink
>>>>> On Thu, 24 Oct 2013 17:40:09 +0900, YAMAMOTO Mitsuharu <***@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
***@math.s.chiba-u.ac.jp
YAMAMOTO Mitsuharu
2013-11-06 08:18:24 UTC
Permalink
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
***@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.
YAMAMOTO Mitsuharu
2013-12-27 08:29:42 UTC
Permalink
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
***@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.
YAMAMOTO Mitsuharu
2014-02-27 10:03:16 UTC
Permalink
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
***@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.
YAMAMOTO Mitsuharu
2014-04-01 01:10:29 UTC
Permalink
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
***@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.
David Reitter
2014-04-03 15:12:23 UTC
Permalink
Mitsuharu,

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



On Mar 31, 2014, at 9:10 PM, YAMAMOTO Mitsuharu <***@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
> ***@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.
>
Leo Liu
2014-04-03 17:30:52 UTC
Permalink
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
Chris Van Dusen
2014-04-04 00:44:08 UTC
Permalink
On Apr 3, 2014, at 12:30 PM, Leo Liu <***@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.
Xu Xin
2014-04-04 01:24:41 UTC
Permalink
On Thu, Apr 3, 2014 at 8:44 PM, Chris Van Dusen <***@gmail.com> wrote:
> On Apr 3, 2014, at 12:30 PM, Leo Liu <***@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
Chris Van Dusen
2014-04-04 01:59:14 UTC
Permalink
On Apr 3, 2014, at 8:24 PM, Xu Xin <***@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.
YAMAMOTO Mitsuharu
2014-04-04 00:07:33 UTC
Permalink
>>>>> On Thu, 3 Apr 2014 11:12:23 -0400, 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
***@math.s.chiba-u.ac.jp
YAMAMOTO Mitsuharu
2014-04-14 03:00:01 UTC
Permalink
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
***@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.
YAMAMOTO Mitsuharu
2014-04-14 08:16:38 UTC
Permalink
>>>>> On Mon, 14 Apr 2014 12:00:01 +0900, YAMAMOTO Mitsuharu <***@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
***@math.s.chiba-u.ac.jp
YAMAMOTO Mitsuharu
2014-05-12 08:42:44 UTC
Permalink
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
***@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.
Randal L. Schwartz
2013-03-11 18:58:57 UTC
Permalink
The current emacs HEAD, corresponding to this commit:

Author: Thierry Volpiatto <***@gmail.com>
Date: Mon Mar 11 14:30:49 2013 -0400

* lisp/net/net-utils.el (net-utils-remove-ctrl-m-filter):
Use with-current-buffer and don't move point.
(net-utils-run-simple): Remove useless code.
(net-utils-remove-ctl-m): Remove unused custom.

is failing to build on OSX, ending with:

Loading loadup.el (source)...
Using load-path (/Users/merlyn/MIRROR/emacs-GIT/lisp /Users/merlyn/MIRROR/emacs-GIT/lisp/emacs-lisp /Users/merlyn/MIRROR/emacs-GIT/lisp/language /Users/merlyn/MIRROR/emacs-GIT/lisp/international /Users/merlyn/MIRROR/emacs-GIT/lisp/textmodes)
Loading emacs-lisp/byte-run (source)...
Symbol's function definition is void: \`
make[1]: *** [bootstrap-emacs] Error 1
make: *** [src] Error 2

Is this a known problem, or would someone like me to bisect with my last
known good version, which appears to be:

Author: Dmitry Gutov <***@yandex.ru>
Date: Thu Mar 7 20:08:33 2013 +0400

* lisp/progmodes/js.el (js--multi-line-declaration-indentation):
Merge
from js2-mode (https://github.com/mooz/js2-mode/issues/89).

Please let me know if you need more info.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<***@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
Randal L. Schwartz
2013-03-11 19:43:57 UTC
Permalink
>>>>> "Randal" == Randal L Schwartz <***@stonehenge.com> writes:

Randal> The current emacs HEAD, corresponding to this commit:

Randal> Author: Thierry Volpiatto <***@gmail.com>
Randal> Date: Mon Mar 11 14:30:49 2013 -0400

Randal> * lisp/net/net-utils.el (net-utils-remove-ctrl-m-filter):
Randal> Use with-current-buffer and don't move point.
Randal> (net-utils-run-simple): Remove useless code.
Randal> (net-utils-remove-ctl-m): Remove unused custom.

Randal> is failing to build on OSX, ending with:

Randal> Loading loadup.el (source)...
Randal> Using load-path (/Users/merlyn/MIRROR/emacs-GIT/lisp /Users/merlyn/MIRROR/emacs-GIT/lisp/emacs-lisp /Users/merlyn/MIRROR/emacs-GIT/lisp/language /Users/merlyn/MIRROR/emacs-GIT/lisp/international /Users/merlyn/MIRROR/emacs-GIT/lisp/textmodes)
Randal> Loading emacs-lisp/byte-run (source)...
Randal> Symbol's function definition is void: \`
Randal> make[1]: *** [bootstrap-emacs] Error 1
Randal> make: *** [src] Error 2

Randal> Is this a known problem, or would someone like me to bisect with my last
Randal> known good version, which appears to be:

Randal> Author: Dmitry Gutov <***@yandex.ru>
Randal> Date: Thu Mar 7 20:08:33 2013 +0400

Randal> * lisp/progmodes/js.el (js--multi-line-declaration-indentation):
Randal> Merge
Randal> from js2-mode (https://github.com/mooz/js2-mode/issues/89).

Randal> Please let me know if you need more info.

Here's the bad commit:

3cf6bbda579e3cf3136ca0a199578a6ad0d278b6 is the first bad commit
commit 3cf6bbda579e3cf3136ca0a199578a6ad0d278b6
Author: Stefan Monnier <***@iro.umontreal.ca>
Date: Sun Mar 10 17:40:55 2013 -0400

* lisp/emacs-lisp/byte-run.el (dont-compile): Declare obsolete.
(with-no-warnings): Use `declare'.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<***@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
Darren Hoo
2013-03-12 10:44:54 UTC
Permalink
***@stonehenge.com (Randal L. Schwartz) writes:

> Is this a known problem, or would someone like me to bisect with my last
> known good version, which appears to be:
>
> Author: Dmitry Gutov <***@yandex.ru>
> Date: Thu Mar 7 20:08:33 2013 +0400

forgive me for being off-topic, but how can you guys do bisect using
bzr? I once used bzr bisect and got really frustrated with it.

Can you give a recipie how to do it?
Dmitry Gutov
2013-03-12 11:55:05 UTC
Permalink
Darren Hoo <***@gmail.com> writes:

> ***@stonehenge.com (Randal L. Schwartz) writes:
>
>> Is this a known problem, or would someone like me to bisect with my last
>> known good version, which appears to be:
>>
>> Author: Dmitry Gutov <***@yandex.ru>
>> Date: Thu Mar 7 20:08:33 2013 +0400
>
> forgive me for being off-topic, but how can you guys do bisect using
> bzr? I once used bzr bisect and got really frustrated with it.

I've used it a few times, and it works similarly enough to git bisect.

It feels kinda clunky, but I haven't encountered any real problems with
it, on GNU/Linux or MS Windows.

> Can you give a recipie how to do it?

http://doc.bazaar.canonical.com/plugins/en/bisect-plugin.html
Tassilo Horn
2013-03-12 13:52:12 UTC
Permalink
Dmitry Gutov <***@yandex.ru> writes:

>>> Is this a known problem, or would someone like me to bisect with my
>>> last known good version, which appears to be:
>>>
>>> Author: Dmitry Gutov <***@yandex.ru>
>>> Date: Thu Mar 7 20:08:33 2013 +0400
>>
>> forgive me for being off-topic, but how can you guys do bisect using
>> bzr? I once used bzr bisect and got really frustrated with it.
>
> I've used it a few times, and it works similarly enough to git bisect.
>
> It feels kinda clunky, but I haven't encountered any real problems with
> it, on GNU/Linux or MS Windows.

I've tried that once, and it didn't work that well for me. Since then,
I simply bisect using the git mirror.

Bye,
Tassilo
Randal L. Schwartz
2013-03-12 15:02:28 UTC
Permalink
>>>>> "Tassilo" == Tassilo Horn <***@gnu.org> writes:

Tassilo> I've tried that once, and it didn't work that well for me.
Tassilo> Since then, I simply bisect using the git mirror.

As do I. I'm tracking via git, which is why I don't talk about commits
via some bzr tag.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<***@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
Glenn Morris
2013-03-12 16:04:18 UTC
Permalink
Darren Hoo wrote:

> forgive me for being off-topic, but how can you guys do bisect using
> bzr? I once used bzr bisect and got really frustrated with it.
>
> Can you give a recipie how to do it?

In Emacs:
admin/notes/bzr
Loading...