Emacs on OS X development

Emacs on OS X development

[Lars Magne Ingebrigtsen]

While doing some bug triage this weekend (I'm done now for this time!
Promise!) I noticed that the single biggest grouping of unhandled bug
reports seem to deal with OS X-related bugs.

Would it be an idea to issue some kind of "EMACS NEEDS YOU to fix OS
X-related bugs" statement on reddit or something to try to attract more
OS X-using developers?  Or are there other reasons for the situation?  I
seem to remember somebody doing OS X development out-of-tree for some
reason? 

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Emacs on OS X development

[Rasmus]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I seem to remember somebody doing OS X development out-of-tree for
> some reason?

Aquamacs is doing a Macs Ox Emacs.  But in cacao or whatever their
`X-toolkit' is called.

–Rasmus

-- 
Sent from my Emacs

Re: Emacs on OS X development

[Glenn Morris]

Rasmus wrote:

> Aquamacs is doing a Macs Ox Emacs.  But in cacao or whatever their
> `X-toolkit' is called.

Umm, that is GNU Emacs (with extra packages and tweaks).
Many of the bug reports come from there.

Re: Emacs on OS X development

[Adrian Robert]

Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:


> Would it be an idea to issue some kind of "EMACS NEEDS YOU to fix OS
> X-related bugs" statement on reddit or something to try to attract more
> OS X-using developers?


More developers are needed and welcome.  Especially those that would sign
papers, and would care about full-screen (probably the biggest missing feature
right now, but none of the main devs really use it so they aren't motivated
to work on it).

Re: Emacs on OS X development

[John Wiegley]

>>>>> Adrian Robert <Adrian.B.Robert@gmail.com> writes:

> More developers are needed and welcome.  Especially those that would sign
> papers, and would care about full-screen (probably the biggest missing
> feature right now, but none of the main devs really use it so they aren't
> motivated to work on it).

"Mac port" Emacs, the set of patches by Yamamoto Mitsuharu, does fullscreen
beautifully on Mac OS X.  Why is his code not being used in the official
distribution?

John

Re: Emacs on OS X development

[Glenn Morris]

John Wiegley wrote:

> "Mac port" Emacs, the set of patches by Yamamoto Mitsuharu, does fullscreen
> beautifully on Mac OS X.  Why is his code not being used in the official
> distribution?

This has been discussed in the past on this list a few times, see eg

http://lists.gnu.org/archive/html/emacs-devel/2009-09/msg00199.html

Re: Emacs on OS X development

[John Wiegley]

>>>>> Glenn Morris <rgm@gnu.org> writes:

> John Wiegley wrote:
>> "Mac port" Emacs, the set of patches by Yamamoto Mitsuharu, does fullscreen
>> beautifully on Mac OS X.  Why is his code not being used in the official
>> distribution?

> This has been discussed in the past on this list a few times, see eg

> http://lists.gnu.org/archive/html/emacs-devel/2009-09/msg00199.html

Thanks for the heads up.

My biggest problem with the Emacs.app code -- and why I'm not using it anymore
-- is that subprocess communication is horribly laggy.  It makes several Emacs
services, such as flyspell, simply unusable.  "Mac port" Emacs doesn't have
this problem at all, such that flyspell works with the same speed it does on
Linux.

People have commented about this flyspell issue many times, and from what I've
seen the blame keeps getting directed at aspell.  But actually, it's Emacs.app
that is the problem.  I've seen it with other things too, like Tramp and gdb,
though it's quite as pronounced there since users already expect to wait
longer.

John

Re: Emacs on OS X development

[Glenn Morris]

John Wiegley wrote:

> My biggest problem with the Emacs.app code -- and why I'm not using it
> anymore -- is that subprocess communication is horribly laggy. It
> makes several Emacs services, such as flyspell, simply unusable.

Yes, this is http://debbugs.gnu.org/cgi/bugreport.cgi?bug=2056
(and several others).

From my position of just reading the bug list (not using Emacs.app), I
would have thought that this, and the relatively large number of crashes
that seem to get reported, were the main issues facing the ns port,
rather than the lack of a fullscreen mode.

Re: Emacs on OS X development

[David Reitter]

On Sep 13, 2011, at 2:56 PM, Glenn Morris wrote:
> From my position of just reading the bug list (not using Emacs.app), I
> would have thought that this, and the relatively large number of crashes
> that seem to get reported, were the main issues facing the ns port,
> rather than the lack of a fullscreen mode.

I agree that crashes are a problem.  In Aquamacs, I have recently enabled semi-automatic crash reporting (we get an e-mail with the crash log the next time the user starts up the app, and chooses to send the report).  I get a lot of those - 134 in August, and rising, as people upgrade to the latest version.

These are way more crash reports that I can act on, so they never end up on the Emacs bug reporting database.
Out of 300-something reports since June, the last Emacs functions (and Emacs versions)  reported are listed below, ordered by number of occurrences (showing only those with more than 2 crashes). Some of them are spurious, obviously, such as the "Fsignal" ones. (Mind you, the actual crashes often occur in the OS, but chances are they're happening because we're doing something wrong.)

The full reports are available publicly:  http://lists.aquamacs.org/pipermail/aquamacs-bugs/

And by the way, I freely admit that Aquamacs is buggier than the original Emacs, but that said, I should think that such statistics may be a starting point in prioritizing the work.  x_set_frame_parameters(), ns_findfonts(), nsfont_open().   



   2 23.3.50; Crash in -[EmacsApp sendEvent:] + 165
   2 23.3.50; Crash in -[EmacsView windowDidResize:] + 83
   2 23.3.50; Crash in Fns_do_applescript + 166
   2 23.3.50; Crash in Fx_show_tip + 438
   2 23.3.50; Crash in expose_area + 403
   2 23.3.50; Crash in note_mouse_highlight + 275
   2 23.3.50; Crash in ns_focus + 231
   2 23.3.50; Crash in ns_get_color + 913
   2 23.3; Crash in TERM: Undefined variable.mark_object + 1083
   2 23.3; Crash in next_frame + 115
   2 23.3; Crash in ns_read_socket + 128
   2 23.3; Crash in ns_release_object + 34
   2 24.0.50; Crash in Fx_popup_dialog + 31
   2 24.0.50; Crash in ns_read_socket + 769
   3 23.3.50; Crash in delete_frame + 1711
   3 23.3.50; Crash in draw_glyphs + 4085
   3 23.3.50; Crash in ns_read_socket + 545 (nsterm.m:3289)
   3 23.3.50; Crash in ns_update_begin + 48
   3 23.3; Crash in -[EmacsApp sendEvent:] + 165
   3 23.3; Crash in -[EmacsMenu clear] + 114
   3 23.3; Crash in -[EmacsView windowDidResize:] + 92
   3 23.3; Crash in Fns_popup_save_panel + 522
   3 23.3; Crash in draw_glyphs + 4085
   3 23.3; Crash in expose_area + 403
   3 23.3; Crash in if: Expression Syntax.-[EmacsApp sendEvent:] + 165
   3 23.3; Crash in ns_findfonts + 1526
   4 23.3.50; Crash in -[EmacsApp extractArgumentsFromOdocEvent:] + 247
   4 23.3.50; Crash in Fns_popup_save_panel + 244
   4 23.3; Crash in nsfont_open + 354
   5 23.3; Crash in mark_object + 1083
   5 24.0.50; Crash in Fsignal + 150
   6 23.3.50; Crash in update_frame_tool_bar + 1214
   6 23.3; Crash in check_message_stack + 42
   6 23.3; Crash in update_frame_tool_bar + 1214
   6 23.3; Crash in x_set_frame_parameters + 841
   8 23.3.50; Crash in ns_findfonts + 1526
   9 23.3.50; Crash in check_message_stack + 42
   9 23.3.50; Crash in ns_send_appdefined + 381
  10 23.3.50; Crash in Fsignal + 511
  11 23.3; Crash in - 0x1f9ffb +org.gnu.Aquamacs 2.2 (2.2.)
  12 23.3; Crash in Fsignal + 511
  17 23.3.50; Crash in ns_read_socket + 307
  17 23.3.50; Crash in x_set_frame_parameters + 841
  29 23.3; Crash in ns_read_socket + 307

Re: Emacs on OS X development

[Jan Djärv]

Hello.

13 sep 2011 kl. 18:37 skrev Adrian Robert <Adrian.B.Robert@gmail.com>:

> Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:
> 
> 
>> Would it be an idea to issue some kind of "EMACS NEEDS YOU to fix OS
>> X-related bugs" statement on reddit or something to try to attract more
>> OS X-using developers?
> 
> 
> More developers are needed and welcome.  Especially those that would sign
> papers, and would care about full-screen (probably the biggest missing feature
> right now, but none of the main devs really use it so they aren't motivated
> to work on it).
> 

That is not totally true. I use fullscreen all the time, but on Lion. Given that Lion has changed the game w.r.t. fullscreen, the motivation to do X11-style fullscreen for older versions of OSX is almost zero.


   Jan D. 

Re: Emacs on OS X development

[Adrian Robert]

On 2011/09/13, at 15:51, Jan Djärv wrote:

> Hello.
> 
> 13 sep 2011 kl. 18:37 skrev Adrian Robert <Adrian.B.Robert@gmail.com>:
> 
>> Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:
>> 
>> 
>>> Would it be an idea to issue some kind of "EMACS NEEDS YOU to fix OS
>>> X-related bugs" statement on reddit or something to try to attract more
>>> OS X-using developers?
>> 
>> 
>> More developers are needed and welcome.  Especially those that would sign
>> papers, and would care about full-screen (probably the biggest missing feature
>> right now, but none of the main devs really use it so they aren't motivated
>> to work on it).
>> 
> 
> That is not totally true. I use fullscreen all the time, but on Lion. Given that Lion has changed the game w.r.t. fullscreen, the motivation to do X11-style fullscreen for older versions of OSX is almost zero.


Ah, OK.  I wasn't aware the Lion fullscreen patch had been merged.

Re: Emacs on OS X development

[Richard Stallman]

Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:

    > Would it be an idea to issue some kind of "EMACS NEEDS YOU to fix OS
    > X-related bugs" statement on reddit or something to try to attract more
    > OS X-using developers?

This must not be said in the name of the GNU Project.
We ask people to make GNU/Linux support their priority.
More generally, we ask them to give free systems priority.
We accept changes to support nonfree systems, but we
don't put our effort into them.

To give priority in this way to nonfree MacOS would represent
a disastrous surrender.



-- 
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 free telephony http://directory.fsf.org/category/tel/

Re: Emacs on OS X development

[Jan Djärv]

Hi.

Nothing has been merged, we are in feature freeze. I use my own locally modified tree.

    Jan D.

13 sep 2011 kl. 21:57 skrev Adrian Robert <adrian.b.robert@gmail.com>:

> 
> On 2011/09/13, at 15:51, Jan Djärv wrote:
> 
>> Hello.
>> 
>> 13 sep 2011 kl. 18:37 skrev Adrian Robert <Adrian.B.Robert@gmail.com>:
>> 
>>> Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:
>>> 
>>> 
>>>> Would it be an idea to issue some kind of "EMACS NEEDS YOU to fix OS
>>>> X-related bugs" statement on reddit or something to try to attract more
>>>> OS X-using developers?
>>> 
>>> 
>>> More developers are needed and welcome.  Especially those that would sign
>>> papers, and would care about full-screen (probably the biggest missing feature
>>> right now, but none of the main devs really use it so they aren't motivated
>>> to work on it).
>>> 
>> 
>> That is not totally true. I use fullscreen all the time, but on Lion. Given that Lion has changed the game w.r.t. fullscreen, the motivation to do X11-style fullscreen for older versions of OSX is almost zero.
> 
> 
> Ah, OK.  I wasn't aware the Lion fullscreen patch had been merged.
> 
> 

Re: Emacs on OS X development

[John Wiegley]

>>>>> Richard Stallman <rms@gnu.org> writes:

> Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:
>> Would it be an idea to issue some kind of "EMACS NEEDS YOU to fix OS
>> X-related bugs" statement on reddit or something to try to attract more OS
>> X-using developers?

> This must not be said in the name of the GNU Project.  We ask people to make
> GNU/Linux support their priority.  More generally, we ask them to give free
> systems priority.  We accept changes to support nonfree systems, but we
> don't put our effort into them.

> To give priority in this way to nonfree MacOS would represent a disastrous
> surrender.

Its perfectly legitimate to call on the aid of OS X programmers to help
improve the OS X port.  That in no way detracts from your organizational focus
on GNU/Linux.

John

Re: Emacs on OS X development

[Leo]

On 2011-09-14 02:43 +0800, John Wiegley wrote:
> Thanks for the heads up.
>
> My biggest problem with the Emacs.app code -- and why I'm not using it anymore
> -- is that subprocess communication is horribly laggy.  It makes several Emacs
> services, such as flyspell, simply unusable.  "Mac port" Emacs doesn't have
> this problem at all, such that flyspell works with the same speed it does on
> Linux.
>
> People have commented about this flyspell issue many times, and from what I've
> seen the blame keeps getting directed at aspell.  But actually, it's Emacs.app
> that is the problem.  I've seen it with other things too, like Tramp and gdb,
> though it's quite as pronounced there since users already expect to wait
> longer.

I agree completely. People who have used macport would never want to go
back to nsport. The difference is that noticeable. We have been hoping
the nsport get better. It seems 3 years have passed.

Leo
-- 
Your time is limited, so don’t waste it living someone else’s life.

Re: Emacs on OS X development

[Stefan Monnier]

> back to nsport. The difference is that noticeable. We have been hoping
> the nsport get better. It seems 3 years have passed.

Waiting ain't gonna fix it, indeed.


        Stefan

Re: Emacs on OS X development

[Richard Stallman]

    Its perfectly legitimate to call on the aid of OS X programmers to help
    improve the OS X port.  That in no way detracts from your organizational focus
    on GNU/Linux.

YOU can say that if you want.  What you shouldn't do is recruit them
in the name of the GNU Project -- for instance, saying "EMACS NEEDS
YOU to fix OS X-related bugs."

-- 
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 free telephony http://directory.fsf.org/category/tel/

Re: Emacs on OS X development

[John Wiegley]

>>>>> Richard Stallman <rms@gnu.org> writes:

> YOU can say that if you want.  What you shouldn't do is recruit them in the
> name of the GNU Project -- for instance, saying "EMACS NEEDS YOU to fix OS
> X-related bugs."

Well, EMACS does need us.  We love Emacs.  Just maybe the FSF doesn't. ;)

John

Re: Emacs on OS X development

[chad]

On Sep 13, 2011, at 6:13 PM, Leo wrote:

> On 2011-09-14 02:43 +0800, John Wiegley wrote:
>> My biggest problem with the Emacs.app code -- and why I'm not using it anymore
>> -- is that subprocess communication is horribly laggy.  It makes several Emacs
>> services, such as flyspell, simply unusable.  "Mac port" Emacs doesn't have
>> this problem at all, such that flyspell works with the same speed it does on
>> Linux.
>> 
>> People have commented about this flyspell issue many times, and from what I've
>> seen the blame keeps getting directed at aspell.  But actually, it's Emacs.app
>> that is the problem.  I've seen it with other things too, like Tramp and gdb,
>> though it's quite as pronounced there since users already expect to wait
>> longer.
> 
> I agree completely. People who have used macport would never want to go
> back to nsport. The difference is that noticeable. We have been hoping
> the nsport get better. It seems 3 years have passed.

Interesting; this is not my experience.

Since switching to macosx I've used both Aquamacs and the mac port, and have always switched back to stock gnu emacs, because what little bit of help I can add seemed best directed there.  Most of my time for the last ~10 years has been spent writing english text, rather than coding, so my use of emacs features is pretty spare (text-mode, html-mode; as of ~3 years ago, org-mode). I basically never use tramp, gud/gdb, SLIME, or the like anymore. 

I just checked flyspell in one of my recent (org-mode) projects, and it seems more or less instantaneous. I also don't see emacs crashes, although I don't let emacs run for weeks like I used to.  I run straight from bzr, rebuilding head every few days.

I'll see if I can make some time this weekend to chase down the common reports, but if a kind someone could let me know what general things seem to be tickling the emacs bugs, I might be able to help out.

*Chad

Re: Emacs on OS X development

[Lars Magne Ingebrigtsen]

chad <yandros@MIT.EDU> writes:

> I'll see if I can make some time this weekend to chase down the common
> reports,

Great!

> but if a kind someone could let me know what general things seem to be
> tickling the emacs bugs, I might be able to help out.

I'd recommend installing GNU ELPA and then saying

(debbugs-gnu nil '("ns"))

to list all the OS X-related bugs.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Emacs on OS X development

[Jan D.]

Leo skrev 2011-09-14 03:13:
> On 2011-09-14 02:43 +0800, John Wiegley wrote:
>> Thanks for the heads up.
>>
>> My biggest problem with the Emacs.app code -- and why I'm not using it anymore
>> -- is that subprocess communication is horribly laggy.  It makes several Emacs
>> services, such as flyspell, simply unusable.  "Mac port" Emacs doesn't have
>> this problem at all, such that flyspell works with the same speed it does on
>> Linux.
>>
>> People have commented about this flyspell issue many times, and from what I've
>> seen the blame keeps getting directed at aspell.  But actually, it's Emacs.app
>> that is the problem.  I've seen it with other things too, like Tramp and gdb,
>> though it's quite as pronounced there since users already expect to wait
>> longer.
> 
> I agree completely. People who have used macport would never want to go
> back to nsport. The difference is that noticeable. We have been hoping
> the nsport get better. It seems 3 years have passed.
> 

I tried it and went back.  That is because it is based on the Emacs 23 tree.

	Jan D.

Re: Emacs on OS X development

[Richard Stallman]

GNU Emacs is part of the GNU system, and our motto is.
"It runs best on GNU."

-- 
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 free telephony http://directory.fsf.org/category/tel/

Re: Emacs on OS X development

[Stephen Eilert]

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

On Wed, Sep 14, 2011 at 11:10 AM, Richard Stallman <rms@gnu.org> wrote:

> GNU Emacs is part of the GNU system, and our motto is.
> "It runs best on GNU."
>
>
Why have the ports been merged then? Following this reasoning, people who
wanted to run it on other operating systems would have to maintain their own
patches, therefore not wasting FSF resources.


-- Stephen

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

Re: Emacs on OS X development

[Glenn Morris]

Stephen Eilert wrote:

> Why have the ports been merged then? Following this reasoning, people
> who wanted to run it on other operating systems would have to maintain
> their own patches, therefore not wasting FSF resources.

Obviously this kind of issue has been covered many times in the history
of the GNU project. See eg
http://www.gnu.org/prep/maintain/maintain.html#Platforms

Re: Emacs on OS X development

[Richard Stallman]

    > GNU Emacs is part of the GNU system, and our motto is.
    > "It runs best on GNU."
    >
    >
    Why have the ports been merged then?

Why not?  Our motto isn't "It runs only on GNU."

					 Following this reasoning, people who
    wanted to run it on other operating systems would have to maintain their own
    patches, therefore not wasting FSF resources.

You may be mistaken about what our line of reasoning is.  It does not
lead to that conclusion.


-- 
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 free telephony http://directory.fsf.org/category/tel/

Re: Emacs on OS X development

[John Wiegley]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> back to nsport. The difference is that noticeable. We have been hoping the
>> nsport get better. It seems 3 years have passed.

> Waiting ain't gonna fix it, indeed.

Stefan, I want to bring up again the possibility of switching the Mac port
over to Yamamoto's code.  Is there any reason not to?  I just tried the ns
port again, and within minutes couldn't tolerate it:

 1. The colors are washed out, compared to Mac-Port.

 2. The leading on Courier is all wrong.  Example: The pixels from the top of
    capital letters run into the mode-line.  I need to set line-spacing to 3
    just to make text look decent.

 3. If I switch to *scratch* and turn on flyspell, I can out-type Emacs very
    easily, the lag is that bad.

Why are we sticking with the ns port again, when Yamamoto has been so active
in keeping the Mac-Port patch maintained?

John

Re: Emacs on OS X development

[Paul Michael Reilly]

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

On Thu, Jul 12, 2012 at 8:23 PM, John Wiegley <johnw@newartisans.com> wrote:

> >>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> >> back to nsport. The difference is that noticeable. We have been hoping
> the
> >> nsport get better. It seems 3 years have passed.
>
> > Waiting ain't gonna fix it, indeed.
>
> Stefan, I want to bring up again the possibility of switching the Mac port
> over to Yamamoto's code.  Is there any reason not to?  I just tried the ns
> port again, and within minutes couldn't tolerate it:
>
>  1. The colors are washed out, compared to Mac-Port.
>
>  2. The leading on Courier is all wrong.  Example: The pixels from the top
> of
>     capital letters run into the mode-line.  I need to set line-spacing to
> 3
>     just to make text look decent.
>
>  3. If I switch to *scratch* and turn on flyspell, I can out-type Emacs
> very
>     easily, the lag is that bad.
>
> Why are we sticking with the ns port again, when Yamamoto has been so
> active
> in keeping the Mac-Port patch maintained?
>

This sounds strange to me.  I've been compiling the devel source on my Mac
Mini and thinking that it was as good as it gets.   So I have two questions:

1) Can someone summarize the pros and cons of each approach to give those
of us who care a chance to weigh in, and

2) Are there any prebuilt binaries for the alternative Mac approach that I
can try out?

fwiw, my experience with using MacPorts and other Mac package suppliers has
been less than joyful.  To be brutally honest I found it to be a royal pain
in the butt.  But if the benefit of overcoming the pain yields a
substantial Emacs reward, then I will gladly give it another shot.

-pmr

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

Re: Emacs on OS X development

[chad]

On Jul 12, 2012, at 5:23 PM, John Wiegley wrote:

>>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>>> back to nsport. The difference is that noticeable. We have been hoping the
>>> nsport get better. It seems 3 years have passed.
> 
>> Waiting ain't gonna fix it, indeed.
> 
> Stefan, I want to bring up again the possibility of switching the Mac port
> over to Yamamoto's code.  Is there any reason not to?  I just tried the ns
> port again, and within minutes couldn't tolerate it:
> 
> 1. The colors are washed out, compared to Mac-Port.
> 
> 2. The leading on Courier is all wrong.  Example: The pixels from the top of
>    capital letters run into the mode-line.  I need to set line-spacing to 3
>    just to make text look decent.
> 
> 3. If I switch to *scratch* and turn on flyspell, I can out-type Emacs very
>    easily, the lag is that bad.

I use the ns port on macosx 10.7.4 every day, compiled from bazaar
every few days, and have never seen any of these problems. I've been
doing this for years, with the current bzr head and OS release, without
trouble. I write a lot more english prose than code these days, maybe 
that's the difference?

> Why are we sticking with the ns port again, when Yamamoto has been so active
> in keeping the Mac-Port patch maintained?


There hasn't been a viable mac-port for emacs-24 until very recently
(it was announced 31 days ago today). The previous mac port lacked
lexbind and bidi, for example.

As near as I can tell, something about various people's set-up,
hardware, and/or usage patterns makes either the mac port or the ns
port really painful (it really does go both ways). Since many of us
aren't feeling your pain, and do feel different pain when we try your
preferred approach, it shouldn't be too surprising that there's been
little motion.

It looks like the future-support questions are probably not an issue
anymore, so I've been meaning to try out the 24.1-based mac port, but
I don't really want to revert from bzr if I can help it. It would be
nice if there were an easy way to try to mac port with the current
bazaar sources, if if you're looking for some way to spur along the
process.

Hope that helps,
*Chad

Re: Emacs on OS X development

[Samuel Bronson]

On Sep 14, 2011, at 10:10 AM, Richard Stallman wrote:

> GNU Emacs is part of the GNU system, and our motto is.
> "It runs best on GNU."

Actually, it seems to have segfaulted during byte-compilation: <https://buildd.debian.org/status/fetch.php?pkg=emacs24&arch=hurd-i386&ver=24.1%2B1-2&stamp=1341460085 
 >

Re: Emacs on OS X development

[chad]

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


On Jul 12, 2012, at 5:57 PM, Paul Michael Reilly wrote:
> fwiw, my experience with using MacPorts and other Mac package suppliers has been less than joyful.  

In this context, Mac Port means `a variant of the ui code that use Carbon and native mac toolkits, as opposed to the NS port that's in the tree', not anything to do with the MacPorts package system.  It's available here:

On Jun 11, 2012, at 12:29 AM, YAMAMOTO Mitsuharu 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

Search the list archives for `Emacs Mac port'; there's a small patch that you probably want if you're going to try it out.

*Chad


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

Re: Emacs on OS X development

[John Wiegley]

>>>>> chad  <yandros@gmail.com> writes:

> As near as I can tell, something about various people's set-up, hardware,
> and/or usage patterns makes either the mac port or the ns port really
> painful (it really does go both ways). Since many of us aren't feeling your
> pain, and do feel different pain when we try your preferred approach, it
> shouldn't be too surprising that there's been little motion.

Ok, I hear you.  Let me take some time to collect some evidence on this, and
compare it with -Q and using different fonts.  I'll come back when I have some
screenshots and timings.

John

Re: Emacs on OS X development

[Le Wang]

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

On Fri, Jul 13, 2012 at 8:23 AM, John Wiegley <johnw@newartisans.com> wrote:


> Why are we sticking with the ns port again, when Yamamoto has been so
> active
> in keeping the Mac-Port patch maintained?
>

For me the ns port was extremely unstable running helm.  Emacs crashed very
frequently (several times a day).

When I switched to Yamamoto's Mac-Port, the stability problems went away
completely (at least the helm related ones, I've had it crash once in the
last few months).  It has completely salvaged my Emacs experience on the
Mac.

-- 
Le

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

Re: Emacs on OS X development

[Jan Djärv]

13 jul 2012 kl. 02:23 skrev John Wiegley:

>>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>>> back to nsport. The difference is that noticeable. We have been hoping the
>>> nsport get better. It seems 3 years have passed.
> 
>> Waiting ain't gonna fix it, indeed.
> 
> Stefan, I want to bring up again the possibility of switching the Mac port
> over to Yamamoto's code.  Is there any reason not to?  I just tried the ns
> port again, and within minutes couldn't tolerate it:
> 

Compability with GNUStep is one reason.  I havent looked at the lates Mac-Port, but previously it lacked features like bidi.

> 1. The colors are washed out, compared to Mac-Port.

Please provide screenshots in a bug report.  I have not see this.  Also, make sure the bug remains when starting with -Q.

> 
> 2. The leading on Courier is all wrong.  Example: The pixels from the top of
>    capital letters run into the mode-line.  I need to set line-spacing to 3
>    just to make text look decent.

Some people report corrupted rendering, some have no problem.  Obviosly there is some dependence on the osx version used, or perhaps the language settings.  But as it is not easily reproducable by the few presons that fixes NS-port bugs it is not easy to fix.

> 
> 3. If I switch to *scratch* and turn on flyspell, I can out-type Emacs very
>    easily, the lag is that bad.

That is a real problem.  I am looking in to this, but my time is very limited.

	Jan D.

Re: Emacs on OS X development

[Ivan Andrus]

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

On Jul 13, 2012, at 12:02 PM, Jan Djärv wrote:
> 13 jul 2012 kl. 02:23 skrev John Wiegley:
> 
>> 2. The leading on Courier is all wrong.  Example: The pixels from the top of
>>   capital letters run into the mode-line.  I need to set line-spacing to 3
>>   just to make text look decent.
> 
> Some people report corrupted rendering, some have no problem.  Obviosly there is some dependence on the osx version used, or perhaps the language settings.  But as it is not easily reproducable by the few presons that fixes NS-port bugs it is not easy to fix.

I haven't seen this exact problem, but I have a few problems with emacs window being slightly the wrong size. For example I have a space between the fringe and the edge of the window in terms of where the scroll bar is placed.  It gets corrupted pixels (as seen below) and never redisplays.  I haven't worried about it because it's only cosmetic, but I mention it now because it might be related. If NSEmacs is calculating the wrong size for the window, courier might get shoved into the mode line.  This is just a wild guess.

[-- Attachment #2: fringe-problem.png --]
[-- Type: image/png, Size: 20636 bytes --]

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


>> 3. If I switch to *scratch* and turn on flyspell, I can out-type Emacs very
>>   easily, the lag is that bad.
> 
> That is a real problem.  I am looking in to this, but my time is very limited.

You'll make several people very happy.  Would it help if there were an incentive set up at http://www.freedomsponsors.com/ for example?

-Ivan

Re: Emacs on OS X development

[Stefan Monnier]

>>> back to nsport. The difference is that noticeable. We have been hoping the
>>> nsport get better. It seems 3 years have passed.
>> Waiting ain't gonna fix it, indeed.
> Stefan, I want to bring up again the possibility of switching the Mac port
> over to Yamamoto's code.  Is there any reason not to?

The main reason is that the ns code can work under GNUstep.
The only thing missing for the ns port is man power.
So if you could try and help us make it work better, that would be
great,


        Stefan

Re: Emacs on OS X development

[René Kyllingstad]

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

On Fri, Jul 13, 2012 at 2:09 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> >>> back to nsport. The difference is that noticeable. We have been hoping
> the
> >>> nsport get better. It seems 3 years have passed.
> >> Waiting ain't gonna fix it, indeed.
> > Stefan, I want to bring up again the possibility of switching the Mac
> port
> > over to Yamamoto's code.  Is there any reason not to?
>
> The main reason is that the ns code can work under GNUstep.
>

At this point it seems like OS X and GNUstep are two different systems with
a common ancestor in NeXTSTEP.

Adding the Mac Port to bzr would allow them to develop along with the
system they target, at the same time as it makes it much easier to share
code where it makes sense.


-- René

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

Re: Emacs on OS X development

[John Wiegley]

>>>>> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> The main reason is that the ns code can work under GNUstep.  The only thing
> missing for the ns port is man power.  So if you could try and help us make
> it work better, that would be great,

That's the problem, I know nothing about GUI apps.  I asked Yamamoto if he'd
be willing to apply his considerable talents to the NS port, but he declined
and linked me to:

  http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00206.html

John

Re: Emacs on OS X development

[John Wiegley]

>>>>> René Kyllingstad <Rene@Kyllingstad.com> writes:

> At this point it seems like OS X and GNUstep are two different systems with
> a common ancestor in NeXTSTEP.

> Adding the Mac Port to bzr would allow them to develop along with the system
> they target, at the same time as it makes it much easier to share code where
> it makes sense.

Yes, I really think that GNUstep and OS X should be regarding as different
targets, while sharing as much code as makes sense.  OS X will only keep
diverging.

John

Re: Emacs on OS X development

[Jan Djärv]

Hello.

13 jul 2012 kl. 19:48 skrev John Wiegley:

>>>>>> René Kyllingstad <Rene@Kyllingstad.com> writes:
> 
>> At this point it seems like OS X and GNUstep are two different systems with
>> a common ancestor in NeXTSTEP.
> 
>> Adding the Mac Port to bzr would allow them to develop along with the system
>> they target, at the same time as it makes it much easier to share code where
>> it makes sense.
> 
> Yes, I really think that GNUstep and OS X should be regarding as different
> targets, while sharing as much code as makes sense.  OS X will only keep
> diverging.

This might be true in some sense, but it is not practical.  GNUStep does not get much attention in Emacs, but it is more likely that a developer that has looked at the OSX code takes a stab at it if they are similar and use the same API:s.  If we bring in the Mac port, I think we must drop GNUStep due to lack of developer time.

Also, while not perfect, a developer making big sweeping changes across all platforms can at least compile for GNUStep if there is no OSX-machine at hand.

As for OSX and GNUStep diverging, that is natural.  Gtk+ 2 and Gtk+ 3 keep diverging also, but it is not a big problem.

	Jan D.

Re: Emacs on OS X development

[Glenn Morris]

Jan Djärv wrote:

> This might be true in some sense, but it is not practical. GNUStep
> does not get much attention in Emacs, but it is more likely that a
> developer that has looked at the OSX code takes a stab at it if they
> are similar and use the same API:s. If we bring in the Mac port, I
> think we must drop GNUStep due to lack of developer time.
>
> Also, while not perfect, a developer making big sweeping changes
> across all platforms can at least compile for GNUStep if there is no
> OSX-machine at hand.

Yes. I have actually been able to make some (small) changes to the ns
port, because I can compile it for GNUstep (I don't have a Mac) and see
that the changes work.

Re: Emacs on OS X development

[John Wiegley]

>>>>> Jan Djärv <jan.h.d@swipnet.se> writes:

> This might be true in some sense, but it is not practical.  GNUStep does not
> get much attention in Emacs, but it is more likely that a developer that has
> looked at the OSX code takes a stab at it if they are similar and use the
> same API:s.  If we bring in the Mac port, I think we must drop GNUStep due
> to lack of developer time.

Isn't the lack of developer time being spent on GNUstep a fact that there
aren't many developers interested in maintaining it?

By not splitting these two, you are losing out on the consistent efforts of
Yamamoto Mitsuharu, who has done a superlative job at providing an excellent
experience for Mac users.  If we use his code, we also gain him as an active
developer for a very active platform.  By sticking with GNUstep, however much
the FSF may want that, we are restricting ourselves to a developer pool
interested in GNUstep -- which is not going to include many people from the
Mac development camp.

John

Re: Emacs on OS X development

[Paul Michael Reilly]

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

On Fri, Jul 13, 2012 at 3:54 PM, John Wiegley <johnw@newartisans.com> wrote:

> >>>>> Jan Djärv <jan.h.d@swipnet.se> writes:
>
> > This might be true in some sense, but it is not practical.  GNUStep does
> not
> > get much attention in Emacs, but it is more likely that a developer that
> has
> > looked at the OSX code takes a stab at it if they are similar and use the
> > same API:s.  If we bring in the Mac port, I think we must drop GNUStep
> due
> > to lack of developer time.
>
> Isn't the lack of developer time being spent on GNUstep a fact that there
> aren't many developers interested in maintaining it?
>
> By not splitting these two, you are losing out on the consistent efforts of
> Yamamoto Mitsuharu, who has done a superlative job at providing an
> excellent
> experience for Mac users.  If we use his code, we also gain him as an
> active
> developer for a very active platform.  By sticking with GNUstep, however
> much
> the FSF may want that, we are restricting ourselves to a developer pool
> interested in GNUstep -- which is not going to include many people from the
> Mac development camp.


If there were another alternative to the ns tree that would produce an OS X
Emacs binary, I would build it in a heartbeat and then choose between the
two which one I will put time into supporting.  Seems crazy to me not to
give Yamamoto's tree a chance to grow.  Is there a git-able source tree
somewhere or is it strictly a patch on top of the ns tree?

-pmr

>

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

Re: Emacs on OS X development

[Ivan Andrus]

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


On Jul 13, 2012, at 10:12 PM, Paul Michael Reilly wrote:

> On Fri, Jul 13, 2012 at 3:54 PM, John Wiegley <johnw@newartisans.com> wrote:
> >>>>> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
> > This might be true in some sense, but it is not practical.  GNUStep does not
> > get much attention in Emacs, but it is more likely that a developer that has
> > looked at the OSX code takes a stab at it if they are similar and use the
> > same API:s.  If we bring in the Mac port, I think we must drop GNUStep due
> > to lack of developer time.
> 
> Isn't the lack of developer time being spent on GNUstep a fact that there
> aren't many developers interested in maintaining it?
> 
> By not splitting these two, you are losing out on the consistent efforts of
> Yamamoto Mitsuharu, who has done a superlative job at providing an excellent
> experience for Mac users.  If we use his code, we also gain him as an active
> developer for a very active platform.  By sticking with GNUstep, however much
> the FSF may want that, we are restricting ourselves to a developer pool
> interested in GNUstep -- which is not going to include many people from the
> Mac development camp.
> 
> If there were another alternative to the ns tree that would produce an OS X Emacs binary, I would build it in a heartbeat and then choose between the two which one I will put time into supporting.  Seems crazy to me not to give Yamamoto's tree a chance to grow.  Is there a git-able source tree somewhere or is it strictly a patch on top of the ns tree?


There is https://github.com/railwaycat/emacs-mac-port though it's not maintained by Yamamoto as near as I can tell.

-Ivan

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

Re: Emacs on OS X development

[John Wiegley]

>>>>> Paul Michael Reilly <pmr@pajato.com> writes:

> If there were another alternative to the ns tree that would produce an OS X
> Emacs binary, I would build it in a heartbeat and then choose between the
> two which one I will put time into supporting.  Seems crazy to me not to
> give Yamamoto's tree a chance to grow.  Is there a git-able source tree
> somewhere or is it strictly a patch on top of the ns tree?

If you clone this repository:

    http://github.com/jwiegley/emacs-release

I track all official Emacs releases there.  If you checkout the "mac-port"
branch, I track Yamamoto's patch of Emacs releases there.

John

Re: Emacs on OS X development

[chad]

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


On Jul 13, 2012, at 2:04 PM, John Wiegley wrote:
> 
> If you clone this repository:
> 
>    http://github.com/jwiegley/emacs-release
> 
> I track all official Emacs releases there.  If you checkout the "mac-port"
> branch, I track Yamamoto's patch of Emacs releases there.

Does this track the emacs 24.1 + mac 3.0 release (plus that small bugfix he posted to the list), or the development head + mac 3.0 release? I'm more interested in following the dev tip than the mac port, and I'm having some trouble building a mac port branch that correctly understands macosx relocatable apps (it keeps trying to shove things into /usr/local).

I'm sure it's something I'm doing wrong, since I haven't had the spare time to do more than mindless follow the install steps while working on other things, but it would be nice to not have to marge from 24.1 up to the trunk myself. :-)

Thanks,
*Chad
P.S. Sending to emacs-devel because I suspect at least 3-4 others on the list would also like to know.  If not, mea culpa.



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

Re: Emacs on OS X development

[John Wiegley]

>>>>> chad  <yandros@gmail.com> writes:

> Does this track the emacs 24.1 + mac 3.0 release (plus that small bugfix he
> posted to the list), or the development head + mac 3.0 release? I'm more
> interested in following the dev tip than the mac port, and I'm having some
> trouble building a mac port branch that correctly understands macosx
> relocatable apps (it keeps trying to shove things into /usr/local).

emacs-release follows only official FSF releases of Emacs, and announced
releases of Mac port.  So it has 24.1-mac-3.0, but without the small bugfix
posted to the list.  When there's a new release from Yamamoto, I'll update the
repo.

> I'm sure it's something I'm doing wrong, since I haven't had the spare time
> to do more than mindless follow the install steps while working on other
> things, but it would be nice to not have to marge from 24.1 up to the trunk
> myself. :-)

I tried applying the Mac-port patch to Emacs trunk, but failed.  I couldn't
even apply it to the emacs-24 branch.  So for now, I just stay on released
versions.

John

Re: Emacs on OS X development

[Jan Djärv]

Hello.

13 jul 2012 kl. 12:45 skrev Ivan Andrus:

> On Jul 13, 2012, at 12:02 PM, Jan Djärv wrote:
>> 13 jul 2012 kl. 02:23 skrev John Wiegley:
>>> 3. If I switch to *scratch* and turn on flyspell, I can out-type Emacs very
>>>  easily, the lag is that bad.
>> 
>> That is a real problem.  I am looking in to this, but my time is very limited.
> 
> You'll make several people very happy.  Would it help if there were an incentive set up at http://www.freedomsponsors.com/ for example?

Thanks, but it would not matter.  The problem is that this thing called "life" also has things to be done, and Emacs time has lower precedence.

	Jan D.

Re: Emacs on OS X development

[Jan Djärv]

13 jul 2012 kl. 21:54 skrev John Wiegley:

> By sticking with GNUstep, however much
> the FSF may want that, we are restricting ourselves to a developer pool
> interested in GNUstep -- which is not going to include many people from the
> Mac development camp.
> 

I think that for the Emacs project it is more important to support other GNU projects than to make the best Emacs we can on non-GNU platforms.  That is my impression at least.

	Jan D.

Re: Emacs on OS X development

[Sudish Joseph]

chad <yandros@gmail.com> writes:
> Does this track the emacs 24.1 + mac 3.0 release (plus that small
> bugfix he posted to the list), or the development head + mac 3.0
> release? I'm more interested in following the dev tip than the mac
> port, and I'm having some trouble building a mac port branch that
> correctly understands macosx relocatable apps (it keeps trying to
> shove things into /usr/local).

https://github.com/railwaycat/emacs-mac-port contains a
build-emacs.app.sh script that builds the relocatable mac port app
you're looking for.  It doesn't track the dev tree, however.

It's been a couple months since I switched from tracking the bzr dev
tree and --with-ns to the mac port.  The big improvements for me are
font rendering, font scaling, fullscreen support and gesture support.
C-g seems to behave better in general.

It's the most native and smooth Emacs experience under OS X yet.  That
said, the ns port does have more integration in some places (open file
events are ignored by the mac port).

Emacs 24.1's ns port has ns-auto-hide-menu-bar and it's possible to
emulate fullscreen pretty reasonably using it.  See below for what I was
using for a good while.  The mac port provides native support for the
relevant frame parameters - it also supports Lion's new fullscreen mode.

-Sudish

(when (boundp 'ns-auto-hide-menu-bar)
  (define-key global-map [(super S-return)] 'sj/ns-toggle-menu-bar)
  (defun sj/ns-toggle-menu-bar ()
    "Toggle the auto-hide of the menu bar."
    (interactive)
    (setq ns-auto-hide-menu-bar (not ns-auto-hide-menu-bar)))
  (define-key global-map [(super return)] 'sj/ns-make-frame-fullscreen)
  (defun sj/ns-make-frame-fullscreen ()
    "Make the current frame fullscreen."
    (interactive)
    (setq ns-auto-hide-menu-bar t)
    (labels ((fp (p) (frame-parameter (selected-frame) p)))
      ;; Make this frame large enough to cover the whole screen.
      ;; set-frame-size takes character rows and columns, so convert
      ;; all the pixel-based values accordingly.
      (let* ((rows (/ (display-pixel-height) (frame-char-height)))
	     (cols (/ (display-pixel-width)  (frame-char-width)))
	     (fringe-pixels (+ (fp 'left-fringe) (fp 'right-fringe)))
	     (fringe (/ fringe-pixels (frame-char-width)))
	     (scrollbar (/ (fp 'scroll-bar-width) (frame-char-width)))
	     (real-cols (- cols fringe scrollbar)))
	(set-frame-size (selected-frame) real-cols rows))
      ;; Move this frame's window decoration offscreen.
      ;; - The magic number here is the size of the decorator in pixels.
      ;; - vertical-gap is any leftover vertical space (pixels) after
      ;;   computing the number of rows above. We distribute this evenly
      ;;   at the top and bottom.
      ;; - vertical-offset must be negative to move the window decoration
      ;;   offscreen.
      (let* ((decorator-size 24)
	     (vertical-gap (mod (display-pixel-height) (frame-char-height)))
	     (vertical-offset (- (/ vertical-gap 2) decorator-size)))
	(set-frame-position (selected-frame) 0 vertical-offset)))))

(when (boundp 'mac-carbon-version-string)
  (defun sj/mac-carbon-toggle-frame-fullscreen ()
    "Make the current frame fullscreen."
    (interactive)
    (let* ((frame (selected-frame))
	   (fs-param (if (eq (frame-parameter frame 'fullscreen) 'fullboth)
			 nil
		       'fullboth)))
      (set-frame-parameter frame 'fullscreen fs-param)))
  (define-key global-map [(super return)] 'sj/mac-carbon-toggle-frame-fullscreen))

Re: Emacs on OS X development

[John Wiegley]

>>>>> Jan Djärv <jan.h.d@swipnet.se> writes:

> I think that for the Emacs project it is more important to support other GNU
> projects than to make the best Emacs we can on non-GNU platforms.  That is
> my impression at least.

I think this is a really bad precedent to set.  By making Emacs inferior to
benefit the GNU project, I think we hurt Emacs more than we benefit GNU.

If GNU needs so much help that we should sacrifice the excellence of Emacs at
its altar, that speaks volumes right there.

John

Re: Emacs on OS X development

[Chong Yidong]

John Wiegley <johnw@newartisans.com> writes:

>>>>>> Jan Djärv <jan.h.d@swipnet.se> writes:
>
>> I think that for the Emacs project it is more important to support
>> other GNU projects than to make the best Emacs we can on non-GNU
>> platforms.  That is my impression at least.
>
> I think this is a really bad precedent to set.  By making Emacs
> inferior to benefit the GNU project, I think we hurt Emacs more than
> we benefit GNU.
>
> If GNU needs so much help that we should sacrifice the excellence of
> Emacs at its altar, that speaks volumes right there.

This is an old, old argument that I have zero interest in re-hashing.

Look, no one is saying that you're not allowed to improve the Mac OS
part of the Nextstep port, or that the GNUstep part must must work
exactly as well as the Mac OS part.  On the contrary; if you want to
help improve it, go right ahead.

Here's the historical context.  Way back during the Emacs 23 development
cycle, the Carbon port was completely broken; it could not even compile.
It remained so for a period of (IIRC) almost a year, because Yamamoto
Mitsuharu was at the time unwilling to keep it up to date with the
changes to the terminal and font systems, and apparently no one else
could fix it.  Since the Cocoa port was in the process of being merged,
it was then decided that rather than keep two Mac ports---one of them
broken for the indefinite future---we'd just go with Cocoa and work on
improving it.

As a significant bonus, the Cocoa port would, if whipped into shape,
provide GNUstep support along the way.

Since then, of course, Yamamoto Mitsuharu has been able to keep the
Carbon port alive.  More power to him, and great for those users who
like that alternative.  But AFAICT he's happy to follow his own timing.
For instance, for a long period of time during the Emacs 24 cycle, the
Mac port was purely 23-only.

Hence the decision made during the Emacs 23 pretest remains valid.
There's no point including two Mac ports in the tree, with all the
attendant demands on documentation and bug reporting, especially if one
of those ports keeps going in and out of sync with the rest of Emacs
based on when its maintainer decides to update it.  Having the Mac port
live outside the Emacs tree, under Mitsuharu's control, is an amicable
compromise.

Now, the problem is that the quality of the Cocoa port has not been
improving as quickly as I'd like.  But this is essentially because most
active Emacs hackers don't work on Mac OS, and those that do are
interested in working on stuff other than the Cocoa code.  Maybe somehow
it's impossible to improve the Cocoa port to get it to work as well as
the Carbon port (or at least the Carbon port when the stars are aligned
and it's in sync with the development tip).  But we are engaged in
software programming, not magic!  There's nothing that can't be fixed,
if someone steps up to the plate to fix it.  Even if there are
fundamental problems with the Cocoa port, if anyone would like to
propose big code changes to fix those flaws, we're perfectly happy to
consider/accept them.

Re: Emacs on OS X development

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 15 Jul 2012 08:54:48 +0800, Chong Yidong <cyd@gnu.org> said:

> Here's the historical context.  Way back during the Emacs 23
> development cycle, the Carbon port was completely broken; it could
> not even compile.  It remained so for a period of (IIRC) almost a
> year, because Yamamoto Mitsuharu was at the time unwilling to keep
> it up to date with the changes to the terminal and font systems, and
> apparently no one else could fix it.  Since the Cocoa port was in
> the process of being merged, it was then decided that rather than
> keep two Mac ports---one of them broken for the indefinite
> future---we'd just go with Cocoa and work on improving it.

I stopped supporting the Carbon port for Emacs 23 in the early stage
because Apple announced GUI via Carbon was not going to 64-bit.  I'm
confident that was the right decision, though there were some
complaints at that time.

> Since then, of course, Yamamoto Mitsuharu has been able to keep the
> Carbon port alive.

That sounds inaccurate.  I didn't keep the "Carbon port" alive.
Instead, I assigned my resource toward another port (the
"Carbon+AppKit" port, the direct predecessor of the Mac port) on Emacs
22, by replacing the GUI-specific part of the Carbon port so it uses
Cocoa Appkit rather than Carbon HIToolbox, reusing the remaining part
of the code.  I was sticking to Emacs 22 rather than 23 first, because
I wanted to concentrate on the switch of GUI implementation basis
only, without being bothered with the difference between versions.  Of
course, I wasn't sure if such an attempt would succeed when I started
it.  The very first internal version started to work in one or two
months, but it took another year to make it public, and yet another
year to stabilize it.

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

Re: Emacs on OS X development

[John Wiegley]

>>>>> Chong Yidong <cyd@gnu.org> writes:

> Look, no one is saying that you're not allowed to improve the Mac OS part of
> the Nextstep port, or that the GNUstep part must must work exactly as well
> as the Mac OS part.  On the contrary; if you want to help improve it, go
> right ahead.

And I am doing so right now, by suggesting we adopt Yamamoto's work. :)

John

Re: Emacs on OS X development

[Paul Michael Reilly]

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

On Sat, Jul 14, 2012 at 11:40 PM, John Wiegley <johnw@newartisans.com>wrote:

> >>>>> Chong Yidong <cyd@gnu.org> writes:
>
> > Look, no one is saying that you're not allowed to improve the Mac OS
> part of
> > the Nextstep port, or that the GNUstep part must must work exactly as
> well
> > as the Mac OS part.  On the contrary; if you want to help improve it, go
> > right ahead.
>
> And I am doing so right now, by suggesting we adopt Yamamoto's work. :)
>

And I concur.  Perhaps someone can explain to me the downside of having
Yamamoto place his tree as a sibling to the ns tree.  I do not understand
why this would be a bad thing.  On the other hand, having both side by side
will undoubtedly allow me to figure out much more about (and more easily)
what is going on and why one version is better than the other, etc. It just
seems intuitively obvious that having both sit side by side will increase
interest that will likely improve both.  At least for a while.  Over the
long haul I suspect most development will favor one over the other.  My
preference is to give them both a chance to thrive together.

That said, I use the ns tree daily and love it.  The fonts look pretty good
to me.  I click on the green maximize button (twice) and get a full screen
experience that works for me.  Speed has never been an issue.  So I'm
scratching my head over where the pain point is in the ns code.  Maybe I
should just fix a bug or two, if only to start feeling Yamamoto's pain wrt
the quality of the coding experience inside the ns tree.

Someday, when it is trivially easy to build the Yamamoto code, I will try
that instance too just to see the differences and compare the approaches.

-pmr

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

Re: Emacs on OS X development

[chad]

On Jul 15, 2012, at 6:12 AM, Paul Michael Reilly wrote:
> 
> And I concur.  Perhaps someone can explain to me the downside of having Yamamoto place his tree as a sibling to the ns tree. [...]
> 
> That said, I use the ns tree daily and love it. [...]

This, I think, is the practical problem we keep running into.  The mac port has never integrated with the development head well (in the 2+ years I've been watching), and it doesn't look like it will live next to the ns port without significant effort.  On the flip side, while some people seem to have a much better experience with the mac port than the ns port, others (including myself) have the opposite experience. 

Right now, we're the closest we've ever been to being able to try the mac port code with the current emacs (not the last release, but the current code), and from what I'm hearing 2-4 people have made small attempts at integrating the two and failed.  I'm sure that a dedicated effort would succeed, but it won't be trivial, and it might not even be easy.  This really seems like a place where arguing pre-code is not very helpful - let's get a working dev+mac tree somewhere, and then figure out what to do with them.

Hopefully this isn't making things worse,
*Chad

Re: Emacs on OS X development

[Donald Curtis]

For anyone using Homebrew on OS X that wants to try the "mac" version, I have updated the "emacs.rb" build recipe to allow a "--mac" option when building Emacs.  It is working for me but not accepted in the main Homebrew tree because the maintainers weren't sure how many people would use it.

Here is the pull request:

https://github.com/mxcl/homebrew/pull/13298




On Jul 15, 2012, at 12:50 PM, chad wrote:

> 
> On Jul 15, 2012, at 6:12 AM, Paul Michael Reilly wrote:
>> 
>> And I concur.  Perhaps someone can explain to me the downside of having Yamamoto place his tree as a sibling to the ns tree. [...]
>> 
>> That said, I use the ns tree daily and love it. [...]
> 
> This, I think, is the practical problem we keep running into.  The mac port has never integrated with the development head well (in the 2+ years I've been watching), and it doesn't look like it will live next to the ns port without significant effort.  On the flip side, while some people seem to have a much better experience with the mac port than the ns port, others (including myself) have the opposite experience. 
> 
> Right now, we're the closest we've ever been to being able to try the mac port code with the current emacs (not the last release, but the current code), and from what I'm hearing 2-4 people have made small attempts at integrating the two and failed.  I'm sure that a dedicated effort would succeed, but it won't be trivial, and it might not even be easy.  This really seems like a place where arguing pre-code is not very helpful - let's get a working dev+mac tree somewhere, and then figure out what to do with them.
> 
> Hopefully this isn't making things worse,
> *Chad
> 
> 

Re: Emacs on OS X development

[Donald Curtis]

I have found that there are problems using the current ns version over screen sharing (input to the GUI fails).  I have also noticed that when doing HTTP connections, things tended to get stuck on the ns-port until I gave some keyboard or mouse input over the GUI.  

All of these issues have been reported but I now use the Mac port and am much happier.  My only complaint is that now that Yamamoto has included the GUI animation stuff, it triggers my discrete GPU on my laptop, something I would like it to not do.

Anyways, my point want to commend the work and put in my vote for the mac version.  I guess the only thing I can do is attempt to try an merge in the changes, but it sounds like people more educated on the matter myself have tried and failed.

It seems like merging the two may be worse though, possibly what we need is a special branch, one that is supported by the project?

And interested parties should get their "copyright / permission" forms faxed in ;)


DC


On Jul 15, 2012, at 12:50 PM, chad wrote:

> 
> On Jul 15, 2012, at 6:12 AM, Paul Michael Reilly wrote:
>> 
>> And I concur.  Perhaps someone can explain to me the downside of having Yamamoto place his tree as a sibling to the ns tree. [...]
>> 
>> That said, I use the ns tree daily and love it. [...]
> 
> This, I think, is the practical problem we keep running into.  The mac port has never integrated with the development head well (in the 2+ years I've been watching), and it doesn't look like it will live next to the ns port without significant effort.  On the flip side, while some people seem to have a much better experience with the mac port than the ns port, others (including myself) have the opposite experience. 
> 
> Right now, we're the closest we've ever been to being able to try the mac port code with the current emacs (not the last release, but the current code), and from what I'm hearing 2-4 people have made small attempts at integrating the two and failed.  I'm sure that a dedicated effort would succeed, but it won't be trivial, and it might not even be easy.  This really seems like a place where arguing pre-code is not very helpful - let's get a working dev+mac tree somewhere, and then figure out what to do with them.
> 
> Hopefully this isn't making things worse,
> *Chad
> 
> 

Re: Emacs on OS X development

[Stefan Monnier]

> developer for a very active platform.  By sticking with GNUstep, however much
> the FSF may want that, we are restricting ourselves to a developer pool
> interested in GNUstep

You're confused: while the current NS port also supports GNUstep, you do
not need to be interested in GNUstep to work on it because it uses
perfectly standard, well supported, OS X libraries.


        Stefan

Re: Emacs on OS X development

[chad]

On Jul 15, 2012, at 2:34 PM, Donald Curtis wrote:

> All of these issues have been reported

Thanks for reporting these problems!

> Anyways, my point want to commend the work and put in my vote for the mac version.

Do you use a relocatable .app bundle, or does your mac version scatter lots of stuff around /usr/local?  This latter is a pet peeve of mine that I had surprising trouble avoiding.

> I guess the only thing I can do is attempt to try an merge in the changes, but it sounds like people more educated on the matter myself have tried and failed.

I don't think that anyone has put much effort into trying this; for myself, I tried to see if it was easy, and it wasn't.  I imagine that it's not actually very hard, but I don't have the time to dedicate to an effort beyond `easy' right now.  It will surely require time to either dig into the differences or experimentation to figure out how to deal with the many conflicts, but I don't think it requires pre-existing advanced knowledge of emacs or macosx; just time and attention.

> It seems like merging the two may be worse though, possibly what we need is a special branch, one that is supported by the project?

I don't know that many people see a value to adding a bzr branch for non-mergable code at this point.  Secretly, I suspect that many of the people who are interested in merging the wo branches would prefer to work from git while they're merging, but that's entirely supposition on my part (based on how many people are shadowing Yamamoto-san's tree in git).

Lest I be confusing based on not having time to shorten the message further:  I believe that this is a useful area for expending energy, and it doesn't require an overly large amount of expertise, but it also isn't trivial or simple.  Thanks in advance if you find time and energy to work on it!

*Chad

Re: Emacs on OS X development

[David Reitter]

On Jul 14, 2012, at 8:54 PM, Chong Yidong wrote:

> Now, the problem is that the quality of the Cocoa port has not been
> improving as quickly as I'd like.  But this is essentially because most
> active Emacs hackers don't work on Mac OS, and those that do are
> interested in working on stuff other than the Cocoa code. 

I've been using the NS port in Aquamacs for a long time, and it's actually quite usable for us.
Of course I had to work around certain issues (ispell), and I receive a good number of crash reports (but not more than would be reasonably expected from some 14,000 daily users).  I wish some of these things could be addressed. 

The Emacs project has made a commitment to the NS port, and that's what is important to me as a downstream user.  The NS port is also very patchable due to its consequent use of Objective C APIs and some object-oriented code.  Given my deep respect for YM's qualities as a coder, I sincerely hope that he can one day combine the AppKit portion of his port with the NS port (and leave the Carbon APIs behind).

Re: Emacs on OS X development

[David Reitter]

On Jul 15, 2012, at 5:34 PM, Donald Curtis wrote:

> I have found that there are problems using the current ns version over screen sharing (input to the GUI fails).  

If this is the problem with recognizing modifier keys: I fixed that in Aquamacs a long time ago (a problem with bitmasks that insist on left/right bits set, IIRC), and the patch just needs to be imported.

Re: Emacs on OS X development

[Richard Stallman]

GNU Emacs is a component of the GNU system.  We improve GNU Emacs so
that the GNU system will be bettter.  The GNU system needs help, and
the purpose of GNU Emacs is to provide some.

Supporting GNU Emacs on other platforms is fine, but it is secondary,
and we should not let this distract us from the primary goal.

This is why we have the rule that every feature in Emacs should work
in the GNU system, and should work at least as well in the GNU system
as it does on any other platform.

However, this doesn't mean you shouldn't work on making Emacs work as
well on Mac OS as it does on other platforms.

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

Re: Emacs on OS X development

[Pavlo Martynenko]

I've been using Mac Port since march and it is really great!
While NS port looks ugly, and works with problems (it has problems with C-g, font rendering, modifier keys, multiprocessing, networking).
NS port may be used on GNUStep, but not on osx.


On 16 Jul 2012, at 01:11, chad wrote:

> Do you use a relocatable .app bundle, or does your mac version scatter lots of stuff around /usr/local?  This latter is a pet peeve of mine that I had surprising trouble avoiding.

I don't. I'm using homebrew, and console version of emacs in /usr/local is fine for me.
But it is nice to have it as an option.


On 16 Jul 2012, at 00:34, Donald Curtis wrote:

> I have found that there are problems using the current ns version over screen sharing (input to the GUI fails).  I have also noticed that when doing HTTP connections, things tended to get stuck on the ns-port until I gave some keyboard or mouse input over the GUI.  

True.

> My only complaint is that now that Yamamoto has included the GUI animation stuff, it triggers my discrete GPU on my laptop, something I would like it to not do.

Agree, GUI animation in Mac port is unnecessary. The less GPU, the more battery.


On 16 Jul 2012, at 00:20, Donald Curtis wrote:

> For anyone using Homebrew on OS X that wants to try the "mac" version, I have updated the "emacs.rb" build recipe to allow a "--mac" option when building Emacs.  It is working for me but not accepted in the main Homebrew tree because the maintainers weren't sure how many people would use it.

And how much maintainer wants? You may count on me + one or two :)



	Pavlo

Re: Emacs on OS X development

[William Stevenson]

>> My only complaint is that now that Yamamoto has included the GUI
>> animation stuff, it triggers my discrete GPU on my laptop, something
>> I would like it to not do.
>
> Agree, GUI animation in Mac port is unnecessary. The less GPU, the
> more battery.

gfxCardStatus is a menu bar application for OS X that allows users of
15" and 17" late 2008 — 2012 MacBook Pros to view which GPU is in use at
a glance, and switch between them on-demand.

http://codykrieger.com/gfxCardStatus

Re: Emacs on OS X development

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 15 Jul 2012 16:34:06 -0500, Donald Curtis <dcurtis@gmail.com> said:

> My only complaint is that now that Yamamoto has included the GUI
> animation stuff, it triggers my discrete GPU on my laptop, something
> I would like it to not do.

Which one?  I think I've added animations only for limited situations
that do not happen frequently, but I may have overlooked something.

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

Re: Emacs on OS X development

[John Wiegley]

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

>>>>> On Sun, 15 Jul 2012 16:34:06 -0500, Donald Curtis <dcurtis@gmail.com> said:
>> My only complaint is that now that Yamamoto has included the GUI animation
>> stuff, it triggers my discrete GPU on my laptop, something I would like it
>> to not do.

> Which one?  I think I've added animations only for limited situations that
> do not happen frequently, but I may have overlooked something.

I also found that graphics switched immediately upon running Emacs.

John

Re: Emacs on OS X development

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 17 Jul 2012 21:56:36 -0500, "John Wiegley" <johnw@newartisans.com> said:

>>> My only complaint is that now that Yamamoto has included the GUI
>>> animation stuff, it triggers my discrete GPU on my laptop,
>>> something I would like it to not do.

>> Which one?  I think I've added animations only for limited
>> situations that do not happen frequently, but I may have overlooked
>> something.

> I also found that graphics switched immediately upon running Emacs.

Does the patch below help?  I can't test it because I don't have
MacBook Pro.

It seems this requires Mac OS X Lion and Early 2011 MacBook Pro.
(http://developer.apple.com/library/mac/#qa/qa1734/)

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

=== modified file 'mac/Emacs.app/Contents/Info.plist'
*** mac/Emacs.app/Contents/Info.plist	2012-06-01 11:45:25 +0000
--- mac/Emacs.app/Contents/Info.plist	2012-07-18 03:39:53 +0000
***************
*** 157,161 ****
--- 157,163 ----
  			</array>
  		</dict>
  	</array>
+ 	<key>NSSupportsAutomaticGraphicsSwitching</key>
+ 	<true/>
  </dict>
  </plist>

Re: Emacs on OS X development

[Pavlo Martynenko]

Yes. It helps.
Thank you.

On 18 Jul 2012, at 06:42, YAMAMOTO Mitsuharu wrote:

>>>>>> On Tue, 17 Jul 2012 21:56:36 -0500, "John Wiegley" <johnw@newartisans.com> said:
> 
>>>> My only complaint is that now that Yamamoto has included the GUI
>>>> animation stuff, it triggers my discrete GPU on my laptop,
>>>> something I would like it to not do.
> 
>>> Which one?  I think I've added animations only for limited
>>> situations that do not happen frequently, but I may have overlooked
>>> something.
> 
>> I also found that graphics switched immediately upon running Emacs.
> 
> Does the patch below help?  I can't test it because I don't have
> MacBook Pro.
> 
> It seems this requires Mac OS X Lion and Early 2011 MacBook Pro.
> (http://developer.apple.com/library/mac/#qa/qa1734/)
> 
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
> 
> === modified file 'mac/Emacs.app/Contents/Info.plist'
> *** mac/Emacs.app/Contents/Info.plist	2012-06-01 11:45:25 +0000
> --- mac/Emacs.app/Contents/Info.plist	2012-07-18 03:39:53 +0000
> ***************
> *** 157,161 ****
> --- 157,163 ----
>  			</array>
>  		</dict>
>  	</array>
> + 	<key>NSSupportsAutomaticGraphicsSwitching</key>
> + 	<true/>
>  </dict>
>  </plist>
> 
> 

	Pavlo

Re: Emacs on OS X development

[Richard Stallman]

What is this "GUI animation stuff"?
What does it do?

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

Re: Emacs on OS X development

[Donald Curtis]

This is perfect.

Yamamoto, is it easy to have an update of your 24.1 patches uploaded to FTP?  Incorporating this one and the one that you mailed out recently to the list?


After thinking about all the discussion here, and the rule that "every feature in Emacs should work in the GNU system, and should work at least as well in the GNU system as it does on any other platform" puts these "mac" patches in a predicament.  Things like animation support—that is taken care of mainly by the Cocoa libraries?—may not be easy to do well on the GNU system.  And it seems like, based on the bits I have read from Yamamoto, it would also not be easy to incorporate the "mac" changes into mainline because of fundamental design choices in the NS port.  But MacVIM is an example of this same problem dealt with by the Vim camp; it is an extension to Vim—by default support GTK and Gnome—and adds a nice Cocoa layer.

My only concern is that Yamamoto not get burnt out maintaing this; I don't know how time consuming it is but I assume there is some challenge. So the only question I have is if Yamamoto would consider keeping the source for his port in a VCS somewhere online so that people can help by submitting bugs and things. And maybe even build a small website to promote that version.  Maybe this would not be desirable for Yamamoto though, but it seems like it would build a bit more community for it, and also let people play with the HEAD version. Just an idea; I may have missed the discussion about this already...

And I believe no matter what the outcome, this is a win for all. More attention to Emacs on any platform will eventually trickle down to the GNU system in some way or another.  Maybe all the changes will get incorporated into the main tree or maybe none will, but I suspect the reality is a middle ground where some patches stay in the Mac port and some get the main tree.

I will try to work on creating .app binaries for this.  There has to be a simple way as someone is packaging Emacs.app now...


Donald



On Jul 17, 2012, at 10:42 PM, YAMAMOTO Mitsuharu wrote:

>>>>>> On Tue, 17 Jul 2012 21:56:36 -0500, "John Wiegley" <johnw@newartisans.com> said:
> 
>>>> My only complaint is that now that Yamamoto has included the GUI
>>>> animation stuff, it triggers my discrete GPU on my laptop,
>>>> something I would like it to not do.
> 
>>> Which one?  I think I've added animations only for limited
>>> situations that do not happen frequently, but I may have overlooked
>>> something.
> 
>> I also found that graphics switched immediately upon running Emacs.
> 
> Does the patch below help?  I can't test it because I don't have
> MacBook Pro.
> 
> It seems this requires Mac OS X Lion and Early 2011 MacBook Pro.
> (http://developer.apple.com/library/mac/#qa/qa1734/)
> 
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
> 
> === modified file 'mac/Emacs.app/Contents/Info.plist'
> *** mac/Emacs.app/Contents/Info.plist	2012-06-01 11:45:25 +0000
> --- mac/Emacs.app/Contents/Info.plist	2012-07-18 03:39:53 +0000
> ***************
> *** 157,161 ****
> --- 157,163 ----
>  			</array>
>  		</dict>
>  	</array>
> + 	<key>NSSupportsAutomaticGraphicsSwitching</key>
> + 	<true/>
>  </dict>
>  </plist>
> 
> 

Re: Emacs on OS X development

[chad]

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


On Jul 18, 2012, at 1:43 PM, Donald Curtis wrote:
> 
> After thinking about all the discussion here, and the rule that "every feature in Emacs should work in the GNU system, and should work at least as well in the GNU system as it does on any other platform" puts these "mac" patches in a predicament.

This is really more of a strong guideline than an absolute rule - things that don't make sense on other platforms but are considered standard or core for the non-GNU platform are allowed.  

> I will try to work on creating .app binaries for this.  There has to be a simple way as someone is packaging Emacs.app now...

Earlier in this thread, Sudish Joseph pointed out a script that supposedly creates relocatable mac apps from that tree:

On Jul 14, 2012, at 3:35 AM, Sudish Joseph wrote:

> https://github.com/railwaycat/emacs-mac-port contains a
> build-emacs.app.sh script that builds the relocatable mac port app
> you're looking for.  

Maybe this will help; I haven't tried it, since I'm more interested in the dev tree than the mac port (the ns port has worked well for me for several years).

Hope that helps,
*Chad


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

Re: Emacs on OS X development

[Jan Djärv]

Hello.

18 jul 2012 kl. 22:43 skrev Donald Curtis:

> And I believe no matter what the outcome, this is a win for all. More attention to Emacs on any platform will eventually trickle down to the GNU system in some way or another.  Maybe all the changes will get incorporated into the main tree or maybe none will, but I suspect the reality is a middle ground where some patches stay in the Mac port and some get the main tree.
> 

I don't see much evidence for that.  The opposite seems to be true, platform specific parts/fixes  stay in forked versions and don't get merged in to the main version.

	Jan D.

Re: Emacs on OS X development

[Pavlo Martynenko]

small screencast

https://vimeo.com/46028049

On 18 Jul 2012, at 20:19, Richard Stallman wrote:

> What is this "GUI animation stuff"?
> What does it do?
> 
> --
> 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
> 

	Pavlo

Re: Emacs on OS X development

[Ted Zlatanov]

On Thu, 12 Jul 2012 18:07:43 -0700 chad <yandros@gmail.com> wrote: 

c> I use the ns port on macosx 10.7.4 every day, compiled from bazaar
c> every few days, and have never seen any of these problems. I've been
c> doing this for years, with the current bzr head and OS release, without
c> trouble.

Same here, with heavy Gnus and Tramp usage.  I haven't seen it crash in
a while (last time was due to a misplaced GnuTLS library).

Ted

Re: Emacs on OS X development

[Pavlo Martynenko]

I can repeat it again.
NS port is ugly, and has problems with C-g, font rendering, modifier keys, multiprocessing, networking.
Some times NS port stops respond on network requests and C-g does not help.
See the difference on https://vimeo.com/46028049. (look and feel only)

And what systems do you use with tramp?
I have problem with FreeBSD.

After opening file on remote freebsd host at the end of the file I see.

$ _echo\b \b\b \b\b \b\b \b\b \bstty icanon erase ^H cols 32767_echo\b \b\b \b\b \b\b \b\b \b
#$ 

Tramp versions from 2.2.3 up to 2.2.6-pre.

On 20 Jul 2012, at 16:51, Ted Zlatanov wrote:

> On Thu, 12 Jul 2012 18:07:43 -0700 chad <yandros@gmail.com> wrote: 
> 
> c> I use the ns port on macosx 10.7.4 every day, compiled from bazaar
> c> every few days, and have never seen any of these problems. I've been
> c> doing this for years, with the current bzr head and OS release, without
> c> trouble.
> 
> Same here, with heavy Gnus and Tramp usage.  I haven't seen it crash in
> a while (last time was due to a misplaced GnuTLS library).
> 
> Ted
> 
> 

	Pavlo

Re: Emacs on OS X development

[Michael Albinus]

Pavlo Martynenko <pavelmart@gmail.com> writes:

> And what systems do you use with tramp?
> I have problem with FreeBSD.
>
> After opening file on remote freebsd host at the end of the file I see.
>
> $ _echo\b \b\b \b\b \b\b \b\b \bstty icanon erase ^H cols 32767_echo\b \b\b \b\b \b\b \b\b \b
> #$ 
>
> Tramp versions from 2.2.3 up to 2.2.6-pre.

Please report it as Tramp bug, see Tramp's manual for details. It would
help, if you could supply the debug buffer, after setting
`tramp-verbose' to 6.

Btw, does it depend whether you use the NS port or the Mac port?

> 	Pavlo

Best regards, Michael.

Re: Emacs on OS X development

[chad]

On Jul 21, 2012, at 2:40 AM, Pavlo Martynenko wrote:

> I can repeat it again.
> NS port is ugly, and has problems with C-g, font rendering, modifier keys, multiprocessing, networking.

And I'll say again that these problems are not universal, and that several people have been using the NS port heavily for years without seeing any of these problems.

> See the difference on https://vimeo.com/46028049. (look and feel only)

If this video purports to show anything except that the mac port has gui animations added to it, then I don't see it (the gui animations themselves are a source of problems, as has been reported here twice).  Assuming that by `ugly' you mean 'lacks gui animations', I wonder if you can provide a bug report or video describing problems with C-g, font rendering, modifier keys, multiprocessing, or networking?

There was a modifier keys issue reported to the list a few days ago that only crops up in unusual remote desktop situations, if that's also your problem, pmr mentioned that he already has a fix for it.

Thanks,
*Chad

Re: Emacs on OS X development

[Stefan Monnier]

> NS port is ugly, and has problems with C-g, font rendering, modifier keys,
> multiprocessing, networking.

None of that is inherent, i.e. it can all be fixed without having to use
a different API.  So we need to someone to step up to the plate and
provide patches.


        Stefan

Re: Emacs on OS X development

[Paul Michael Reilly]

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

On Sun, Jul 22, 2012 at 5:31 AM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> > NS port is ugly, and has problems with C-g, font rendering, modifier
> keys,
> > multiprocessing, networking.
>
> None of that is inherent, i.e. it can all be fixed without having to use
> a different API.  So we need to someone to step up to the plate and
> provide patches.
>

First, I think someone needs to step up to the plate and prove the
allegations.  There have been a few of us, at least, who have spoken up
that these behaviors do not occur for us.  So I'm guessing the problem lies
in how the binary is built and/or tested.

That said, should there be a real problem with the ns port, or a valuable
feature inherent to the mac port, I will be glad to apply effort where
needed.

I also think you are giving short shrift to the ageless problem of
engineers finding it distasteful to work on an existing body of code.  This
is what I conclude happened with Yamamoto wrt the ns port.  And if you were
to argue that what one engineer finds distasteful, another might find
elegant ... I would rest your case. :-)

-pmr

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

Re: Emacs on OS X development

[Ivan Andrus]

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

On Jul 23, 2012, at 12:16 AM, Paul Michael Reilly wrote:

> On Sun, Jul 22, 2012 at 5:31 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > NS port is ugly, and has problems with C-g, font rendering, modifier keys,
> > multiprocessing, networking.
> 
> None of that is inherent, i.e. it can all be fixed without having to use
> a different API.  So we need to someone to step up to the plate and
> provide patches.
> 
> First, I think someone needs to step up to the plate and prove the allegations.  There have been a few of us, at least, who have spoken up that these behaviors do not occur for us.  So I'm guessing the problem lies in how the binary is built and/or tested.

What would it take to "prove" to you that, for example, flyspell is painfully slow?  I'd be happy to provide profiling information or something if that would convince you.  I have built from bzr for several years now with just `--with-ns`.  

-Ivan

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

Re: Emacs on OS X development

[Stefan Monnier]

> That said, should there be a real problem with the ns port, or a valuable
> feature inherent to the mac port, I will be glad to apply effort where
> needed.

AFAIK, there's a "fundamental" problem in the way C-g (and generally
the event-loop) is handled which can cause excessive delays.
I do not know enough to say much more, but if someone could take on the
task of trying to fix this problem, I'm sure he'd find people here who
could better explain the problem.


        Stefan

Re: Emacs on OS X development

[Paul Michael Reilly]

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

On Mon, Jul 23, 2012 at 4:46 AM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> > That said, should there be a real problem with the ns port, or a valuable
> > feature inherent to the mac port, I will be glad to apply effort where
> > needed.
>
> AFAIK, there's a "fundamental" problem in the way C-g (and generally
> the event-loop) is handled which can cause excessive delays.
> I do not know enough to say much more, but if someone could take on the
> task of trying to fix this problem, I'm sure he'd find people here who
> could better explain the problem.
>

If I can repeat the bad behavior, then I will work on coming up with a fix.

btw, I replied to Ivan on the flyspell issue saying pretty much the same
thing but neglected to cc emacs-devel.  My bad.

-pmr

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

Re: Emacs on OS X development

[Ted Zlatanov]

On Sat, 21 Jul 2012 12:40:01 +0300 Pavlo Martynenko <pavelmart@gmail.com> wrote: 

PM> I can repeat it again.
PM> NS port is ugly, and has problems with C-g, font rendering, modifier keys, multiprocessing, networking.
PM> Some times NS port stops respond on network requests and C-g does not help.
PM> See the difference on https://vimeo.com/46028049. (look and feel only)

I was not saying you and the other people complaining about the NS port
are wrong, just wanted to say I haven't experienced those problems.  The
first step to finding and fixing bugs and problems is to understand
where and why they happen.  Maybe the NS port's problems are linked to
something in the OS or user environment.  Do you compile your own
binaries, for instance?  Do you have problems with some specific
network connections?

As far as "ugly" I have no opinion, and haven't noticed font issues or
other visual problems.  The NS port's functionality has been all right
for me, especially keyboard entry, multiprocessing, and networking.  I'd
file bugs if I couldn't use Gnus and the other functionality I mentioned
earlier.

Ted

Re: Emacs on OS X development

[John Wiegley]

>>>>> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> None of that is inherent, i.e. it can all be fixed without having to use a
> different API.  So we need to someone to step up to the plate and provide
> patches.

We have an existing body of code that it seems no one is excited to maintain,
and a fork that at least one person is very eager to maintain.

Is the correct answer to say that we're not moving forward until someone gains
interest in something currently unexciting?  Or should we migrate to a
code-base where we have a guaranteed active developer?

Waiting until NS finds its star developer does not seem like a real strategy
to me -- unless you don't have a problem with NS currently.  But this is a
genuine issue for many of us.  It prevents me, personally, from following
trunk and providing fixes/bug reports relative to trunk.

Simply because non-OS X users don't seem to care what happens on OS X, doesn't
mean it should be this easy to ignore the problem.  It hasn't "gone away" in a
few years now, and I don't see why that's suddenly going to change now.

Can everyone who has issues with NS please help by gathering data about your
environment and use cases?  The problems I have manifest even with -Q.  I
build as follows:

  configure --with-ns --enable-checking --enable-check-lisp-object-type
            --prefix=$INSTALL_DIR CC=clang CXX=clang++ LD=clang
            CFLAGS='-g -O0 -fno-omit-frame-pointer'
            LDFLAGS="$CFLAGS"

I then change my font to:

  "-*-Courier-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1"

When in a scratch buffer, if I enable flyspell-mode, I can type fast enough
that Emacs can't insert the characters as quickly as I can type.

It's this last problem that makes the NS port entirely unusable to me.  The
poor font rendering (at least of Courier) is mostly cosmetic.

John

Re: Emacs on OS X development

[Eli Zaretskii]

> From: "John Wiegley" <johnw@newartisans.com>
> Date: Mon, 23 Jul 2012 14:45:34 -0500
> 
> Waiting until NS finds its star developer does not seem like a real strategy
> to me

Then don't wait.  Sit down and start hacking.  You will get a lot of
support from everyone here, as soon as you start asking technical
questions and seek advice how to attack specific problems.

> Simply because non-OS X users don't seem to care what happens on OS X, doesn't
> mean it should be this easy to ignore the problem.  It hasn't "gone away" in a
> few years now, and I don't see why that's suddenly going to change now.

This line of argument won't get you anywhere, believe me.  Been there
done that -- I waited for 6 years for Someone™ to come and incorporate
the bidi reordering engine into Emacs redisplay, which I wrote and
debugged back in 2002, but finally had to do it myself.  If I hadn't,
Emacs would still live in unidirectional world today.

> When in a scratch buffer, if I enable flyspell-mode, I can type fast enough
> that Emacs can't insert the characters as quickly as I can type.
> 
> It's this last problem that makes the NS port entirely unusable to
> me.

Then attack this one first.

For starters, flyspell.el is not supposed to do anything until it sees
that you completed a word.  So as long as you type letters with no
whitespace or punctuation, the slowdown should be minimal to
non-existent, and the external speller program is not involved.  Do
you still see significant slowdown while typing a single long word?
Or does it get slow only as soon as a word is completed and flyspell
starts talking to the speller?

Re: Emacs on OS X development

[Paul Eggert]

On 07/23/2012 12:45 PM, John Wiegley wrote:
> I build as follows:
> 
>   configure --with-ns --enable-checking --enable-check-lisp-object-type
>             --prefix=$INSTALL_DIR CC=clang CXX=clang++ LD=clang
>             CFLAGS='-g -O0 -fno-omit-frame-pointer'
>             LDFLAGS="$CFLAGS"

I tried to reproduce the problem by building with above recipe,
on Ubuntu 12.04.  The LDFLAGS="$CFLAGS" part can't be right, since
this doesn't clone the CFLAGS settings of the previous line.  I
tried using LDFLAGS='-g -O0 -fno-omit-frame-pointer' but that
didn't link (the first diagnostic was
"nsterm.m:297: undefined reference to `objc_lookup_class'").

Can you please give a revised recipe?

> I then change my font to:
> 
>   "-*-Courier-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1"

How did you change your font?  Giving details here will make it
easier for others to reproduce the problem.

I notice that you're enabling multiple debugging options;
this might cause Emacs to be slow for you even if it works
fine for others.

Re: Emacs on OS X development

[Jan Djärv]

Hello.

23 jul 2012 kl. 21:45 skrev John Wiegley:

>>>>>> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> 
>> None of that is inherent, i.e. it can all be fixed without having to use a
>> different API.  So we need to someone to step up to the plate and provide
>> patches.
> 
> We have an existing body of code that it seems no one is excited to maintain,
> and a fork that at least one person is very eager to maintain.

Bugs do get fixed in the NS port.  I use it on OSX every weekday (at work), so I try to fix bugs.  Others do too from time to time.  In the last 6 months or so, I'd say that the NS port has gotten as much attention as the Gtk+ port.  Granted that the NS-port may have had more problems to begin with.

> 
> Is the correct answer to say that we're not moving forward until someone gains
> interest in something currently unexciting?  Or should we migrate to a
> code-base where we have a guaranteed active developer?

It depends on what you mean by moving forwards.  As has been stated, many people use the NS port (myself included) without the problems others seem to have.  I have tried hard to come up with a crash or a display corruption, but so far failed, with the exception of 11484.  But I haven't have time to fix that yet.  

It may seem to you as nothing is done about the problems you face, but so far nobody has been able to come up with a single case that is reproducable by someone that may fix ns-port bugs.  Not even 11541, 11684 or 11792 craches for me, and I have tried all sorts of compiler and configuration options.

> Waiting until NS finds its star developer does not seem like a real strategy
> to me -- unless you don't have a problem with NS currently.  But this is a
> genuine issue for many of us.  It prevents me, personally, from following
> trunk and providing fixes/bug reports relative to trunk.

I don't see how seeing a bug in the NS-port stops you from providing a fix to that bug.

> 
> Can everyone who has issues with NS please help by gathering data about your
> environment and use cases?  The problems I have manifest even with -Q.  I
> build as follows:
> 
>  configure --with-ns --enable-checking --enable-check-lisp-object-type
>            --prefix=$INSTALL_DIR CC=clang CXX=clang++ LD=clang
>            CFLAGS='-g -O0 -fno-omit-frame-pointer'
>            LDFLAGS="$CFLAGS"
> 
> I then change my font to:
> 
>  "-*-Courier-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1"

How do you set this font? In .emacs, in default-frame-alist, via customize, via the font dialog?

Locale and system language probably also has something to do with the problems.

Does compiling emacs with just --with-ns give you any different results (w.r.t. craches as in 11541, 11684 or 11792 , the slowdown below will presist)?

> 
> When in a scratch buffer, if I enable flyspell-mode, I can type fast enough
> that Emacs can't insert the characters as quickly as I can type.
> 

This is a known issue, partly to do with how the event loop is implemented.  A smarter loop doubles the speed, but it is still slower than say X.

	Jan D.

Re: Emacs on OS X development

[Paul Michael Reilly]

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

On Mon, Jul 23, 2012 at 4:46 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:

> Hello

...

> >
> > When in a scratch buffer, if I enable flyspell-mode, I can type fast
> enough
> > that Emacs can't insert the characters as quickly as I can type.
> >
>
> This is a known issue, partly to do with how the event loop is
> implemented.  A smarter loop doubles the speed, but it is still slower than
> say X.
>

Does this issue have a bug number?  Any discussions on fixes that are
relevant?  A simple way to illustrate the problem?

Thanks,

-pmr

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

Re: Emacs on OS X development

[Jan Djärv]

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

Hello.

23 jul 2012 kl. 23:17 skrev Paul Michael Reilly:

> On Mon, Jul 23, 2012 at 4:46 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> Hello
> ... 
> >
> > When in a scratch buffer, if I enable flyspell-mode, I can type fast enough
> > that Emacs can't insert the characters as quickly as I can type.
> >
> 
> This is a known issue, partly to do with how the event loop is implemented.  A smarter loop doubles the speed, but it is still slower than say X.
> 
> Does this issue have a bug number?  Any discussions on fixes that are relevant?  A simple way to illustrate the problem?
> 

See 7761.

	Jan D.



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

Re: Emacs on OS X development

[chad]

On Jul 23, 2012, at 12:45 PM, John Wiegley wrote:

>>>>>> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> 
>> None of that is inherent, i.e. it can all be fixed without having to use a
>> different API.  So we need to someone to step up to the plate and provide
>> patches.
> 
> We have an existing body of code that it seems no one is excited to maintain,
> and a fork that at least one person is very eager to maintain.

This viewpoint that does not match the reality I see. Several people
on emacs-devel use the ns port heavily every day, and bugs are both
reported and fixed regularly.  

> I then change my font to:
> 
>  "-*-Courier-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1"

Interesting. I see a problem with this font spec if the emacs window
pre-font-change is tall enough that the post-change window won't fit
on the display. If I use my normal nearly-full-height window with your
font spec, it looks like emacs thinks that window is taller than it
actually is; the scrollbar is the wrong size, the cursor can go above
the window, and there are some display turds that you might expect
from a window that is taller than it thinks it is (most easily seen
with the tool-bar enabled).

If I make the emacs window short enough before changing the font,
everything seems to work fine even with your spec. Hopefully, this
will help someone knowledgeable about the display engine narrow 
down the problem area.

> When in a scratch buffer, if I enable flyspell-mode, I can type fast enough
> that Emacs can't insert the characters as quickly as I can type.

I have written a few hundred thousand words of flyspell'd english text
in the ns port, primarily in text-mode and org-mode. Flyspell isn't
fast, due to a known annoyance with the ns port event loop, but it is
certainly not unusable for me (and for many others here), using
relatively modern but not top-of-the-line hardware. I would love to
see if the mac port's approach could improve this; it is far and away
the most exciting potential of the mac port (to me).

Do you still have this problem with flyspell if you run emacs -Q?

*Chad

Re: Emacs on OS X development

[John Wiegley]

>>>>> chad  <yandros@gmail.com> writes:

>> When in a scratch buffer, if I enable flyspell-mode, I can type fast enough
>> that Emacs can't insert the characters as quickly as I can type.

> I have written a few hundred thousand words of flyspell'd english text in
> the ns port, primarily in text-mode and org-mode. Flyspell isn't fast, due
> to a known annoyance with the ns port event loop, but it is certainly not
> unusable for me (and for many others here), using relatively modern but not
> top-of-the-line hardware. I would love to see if the mac port's approach
> could improve this; it is far and away the most exciting potential of the
> mac port (to me).

> Do you still have this problem with flyspell if you run emacs -Q?

Yes, I can confirm that it happens with -Q.

John

Re: Emacs on OS X development

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> Waiting until NS finds its star developer does not seem like a real strategy
>> to me

> Then don't wait.  Sit down and start hacking.  You will get a lot of support
> from everyone here, as soon as you start asking technical questions and seek
> advice how to attack specific problems.

I'm not a GUI developer, and don't plan on becoming one simply to fix my
editor.

>> Simply because non-OS X users don't seem to care what happens on OS X,
>> doesn't mean it should be this easy to ignore the problem.  It hasn't "gone
>> away" in a few years now, and I don't see why that's suddenly going to
>> change now.

> This line of argument won't get you anywhere, believe me.  Been there done
> that -- I waited for 6 years for Someone™ to come and incorporate the bidi
> reordering engine into Emacs redisplay, which I wrote and debugged back in
> 2002, but finally had to do it myself.  If I hadn't, Emacs would still live
> in unidirectional world today.

You probably know that I contribute to Emacs on a regular basis, mostly in the
Lisp areas.  The reason I'm complaining here about this, rather than doing
something more constructive, is that the problem lies far outside my area of
knowledge.

Plus, another developer, Yamamoto, *has* my solution.  I've been using it for
over a year now, and I'm happy with the way he has solved my issues for the
release versions of Emacs.  So, I'm arguing for inclusion of his work, not for
you to fix something for me.

If we can get NS fixed, great; if we can get Mac-port merged, great; either
path would allow me to become an active contributor gain to development on
trunk.

>> When in a scratch buffer, if I enable flyspell-mode, I can type fast enough
>> that Emacs can't insert the characters as quickly as I can type.
>> 
>> It's this last problem that makes the NS port entirely unusable to me.

> Then attack this one first.

> For starters, flyspell.el is not supposed to do anything until it sees that
> you completed a word.  So as long as you type letters with no whitespace or
> punctuation, the slowdown should be minimal to non-existent, and the
> external speller program is not involved.  Do you still see significant
> slowdown while typing a single long word?  Or does it get slow only as soon
> as a word is completed and flyspell starts talking to the speller?

Ok, these are great questions.  First off, I pulled the -g -O0 thing from my
'emacs-build' script, which I've been using to build trunk lately.  The same
problem happens if I use -O3, with no other flags.  Also, for the -O3 build, I
only use the --with-ns flag, nothing else.

I'm rebuilding my trunk version now, and will do some more tests.  I'll be
back when I have some more concrete results.

John

Re: Emacs on OS X development

[John Wiegley]

>>>>> Paul Eggert <eggert@cs.ucla.edu> writes:

>> I then change my font to:
>> 
>> "-*-Courier-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1"

> How did you change your font?  Giving details here will make it easier for
> others to reproduce the problem.

Sorry for being imprecise on that one.  I have this in my init.el:

(custom-set-variables
 '(default-frame-alist (quote ((font . "-apple-Courier-medium-normal-normal-*-15-*-*-*-m-0-iso10646-1") (cursor-color . "#b247ee")))))

> I notice that you're enabling multiple debugging options; this might cause
> Emacs to be slow for you even if it works fine for others.

It happens to me with -O3 and no debug options too.

John

Re: Emacs on OS X development

[John Wiegley]

>>>>> Jan Djärv <jan.h.d@swipnet.se> writes:

>> We have an existing body of code that it seems no one is excited to maintain,
>> and a fork that at least one person is very eager to maintain.

> Bugs do get fixed in the NS port.  I use it on OSX every weekday (at work),
> so I try to fix bugs.  Others do too from time to time.  In the last 6
> months or so, I'd say that the NS port has gotten as much attention as the
> Gtk+ port.  Granted that the NS-port may have had more problems to begin
> with.

But do we have a "leader" for the NS port, somebody in charge of that piece
willing to drive it toward perfection?  Fixing bugs as they come up is great,
but will only solve the problems for which there are reproducible bugs.  Is NS
improving in other ways?

Mac-port is gaining new capabilities with each release.  It already had
excellent fullscreen support, now it has swiping gestures and great scrolling
too.

John

Re: Emacs on OS X development

[Stefan Monnier]

>>> This is a known issue, partly to do with how the event loop is
>>> implemented.  A smarter loop doubles the speed, but it is still slower
>>> than say X.
>> Does this issue have a bug number?  Any discussions on fixes that are
>> relevant?  A simple way to illustrate the problem?
> See 7761.

This bug number does not seem to discuss much this event-loop problem.
Is there some place where this problem is discussed?
I hope someone can try and tackle it, e.g. starting by comparing the
approach used currently in the NS port compared to the X, Gtk, Windows
or Mac ports, so as to devise a plan.


        Stefan

Re: Emacs on OS X development

[chad]

On Jul 23, 2012, at 4:15 PM, John Wiegley wrote:
> Is NS improving in other ways?

Until about 45 days ago, the ns port had bidi, cedet, and lexbind
support while the mac port didn't. Right now, it has highly
experimental widget support that the mac port doesn't. Basically,
every time I have tried the mac port, it was lacking some
important-to-me functionality from the mainline. Of course, I'm
sure other people have different priorities.

By choosing to periodically play catch-up with the infrequent
emacs releases, it's basically guaranteed to be behind the times.
Excitingly, it's currently not *that* far behind, and there's hope 
that it might catch up.

*Chad

Re: Emacs on OS X development

[Leo]

On 2012-07-24 05:45 +0800, chad wrote:
> This viewpoint that does not match the reality I see. Several people
> on emacs-devel use the ns port heavily every day, and bugs are both
> reported and fixed regularly.

I have used the ns-port for more than a year and reported quite a few
bugs. I have to leave ns-port seeking other alternatives and mac port
was what I found that brings real emacs experience to OSX.

I don't know how much ns-port has improved since (2009) but looking at
the code changes in those files, it cannot be much and most serious bugs
are still open in the bug tracker.

So people experiencing real pain using the ns port have given the ns
port more than a cursory look and find it painful to use.

I wonder why can't we have the mac port sit in a bzr branch. It would be
a good source of inspiration for people working on the ns-port and save
some of us pain who cannot help fixing ns-port. We are using a DVS
anyway.

Leo

Re: Emacs on OS X development

[Jan Djärv]

Hello.


24 jul 2012 kl. 01:26 skrev Stefan Monnier <monnier@IRO.UMontreal.CA>:

>>>> This is a known issue, partly to do with how the event loop is
>>>> implemented.  A smarter loop doubles the speed, but it is still slower
>>>> than say X.
>>> Does this issue have a bug number?  Any discussions on fixes that are
>>> relevant?  A simple way to illustrate the problem?
>> See 7761.
> 
> This bug number does not seem to discuss much this event-loop problem.
> Is there some place where this problem is discussed?

It has a way to see the problem. Ian not aware of any event loop discussion, it is something I saw when investigating that bug. 

> I hope someone can try and tackle it, e.g. starting by comparing the
> approach used currently in the NS port compared to the X, Gtk, Windows
> or Mac ports, so as to devise a plan.

I have a plan to do more or less what Gdk does on OSX, use lower level (Core Foundation) API:s. The NS-port has many special things (resizing, redrawing and more) that depends on how things are done now, so it isn't just a replacement of a few functions.

I haven't looked at the Mac port, but if it uses CF for the event loop, code may be reused from there.

The basic concept is to have one thread for file descriptors and let the main thread deal with Cocoa events.  The code today does something similar, but it relies on polling each 0.1 second.

    Jan D.

Re: Emacs on OS X development

[Pavlo Martynenko]

On 21 Jul 2012, at 17:02, Michael Albinus wrote:

> Btw, does it depend whether you use the NS port or the Mac port?

No. It is a Trump bug.

	Pavlo

Re: Emacs on OS X development

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 24 Jul 2012 08:25:41 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

>> I hope someone can try and tackle it, e.g. starting by comparing
>> the approach used currently in the NS port compared to the X, Gtk,
>> Windows or Mac ports, so as to devise a plan.

> I have a plan to do more or less what Gdk does on OSX, use lower
> level (Core Foundation) API:s. The NS-port has many special things
> (resizing, redrawing and more) that depends on how things are done
> now, so it isn't just a replacement of a few functions.

> I haven't looked at the Mac port, but if it uses CF for the event
> loop, code may be reused from there.

The Mac port uses CF for that purpose only on older versions of Mac OS
X.  For newer versions, it uses Grand Central Dispatch instead:

  http://lists.gnu.org/archive/html/emacs-devel/2012-01/msg00035.html

I'm not sure about the recent situation, but I remember neither of
them was (widely, at least) available on GNUstep.

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

Re: Emacs on OS X development

[Stefan Monnier]

> I have a plan to do more or less what Gdk does on OSX, use lower level (Core
> Foundation) API:s. The NS-port has many special things (resizing, redrawing
> and more) that depends on how things are done now, so it isn't
> just a replacement of a few functions.
> I haven't looked at the Mac port, but if it uses CF for the event loop, code
> may be reused from there.
> The basic concept is to have one thread for file descriptors and let the
> main thread deal with Cocoa events.  The code today does something similar,
> but it relies on polling each 0.1 second.

Could you add this discussion to etc/TODO, adding as much detail as you
(and others) can about how it works now and how it could be changed?
BTW, why not use the main thread for file-descriptors?


        Stefan

Re: Emacs on OS X development

[Pavlo Martynenko]

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


On 21 Jul 2012, at 19:53, chad wrote:

> If this video purports to show anything except that the mac port has gui animations added to it, then I don't see it (the gui animations themselves are a source of problems, as has been reported here twice).

The main purpose is to show better scrolling and buffer switching with two fingers. "Look and feel" and animation. Nothing more.

> Assuming that by `ugly' you mean 'lacks gui animations', I wonder if you can provide a bug report or video describing problems with C-g, font rendering, modifier keys, multiprocessing, or networking?

I meant it looks ugly. Even animations is not important. Mac Port looks native, while NS port looks and behaves alien to OS X. It is like big step backward in time.



NS port is on the left where the font is narrow and faint. Same font but different frame height. And where is the true brown?

As for modifier keys, multiprocessing and network I'd like to switch to NS port for a while, and inform about them, if there is one (I hope there is none now). But I will terribly miss nice smooth scrolling and buffer switching with two fingers. Instead I'l be happy to provide any information about Mac Port.

I applied Mac Port patch on trunk (just monkey patching). But the resulting Emacs has a really bad response on keyboard entry and mouse/trackpad.

Btw. Mac Port has more great features. Triple tap on selected word calls dictionary. 



And here is difference in flymake highlighting. Startup configs are the same.




On 23 Jul 2012, at 21:57, Ted Zlatanov wrote:

> Do you compile your own binaries, for instance?

Yes.

> Do you have problems with some specific network connections?

Yes in slow and bad networks. It looks like after loosing some packets comes problem with C-g, and the only way was to killall -9 Emacs.

> As far as "ugly" I have no opinion, and haven't noticed font issues or
> other visual problems. The NS port's functionality has been all right
> for me, especially keyboard entry, multiprocessing, and networking.

Did you noticed that NS port is just fine only for those who never tried Mac Port, and those who are not using OS X every day?

I have used NS port today, and I have to agree it response very well and looks better than two month ago but it still ugly.

	Pavlo





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

[-- Attachment #2.2: Screen Shot 2012-07-24 at 12.17.54.png --]
[-- Type: image/png, Size: 406763 bytes --]

[-- Attachment #2.3: Screen Shot 2012-07-24 at 12.19.31.png --]
[-- Type: image/png, Size: 97494 bytes --]

[-- Attachment #2.4: Screen Shot 2012-07-24 at 13.16.21.png --]
[-- Type: image/png, Size: 28234 bytes --]

Re: Emacs on OS X development

[Ted Zlatanov]

On Tue, 24 Jul 2012 16:04:50 +0300 Pavlo Martynenko <pavelmart@gmail.com> wrote: 

PM> On 23 Jul 2012, at 21:57, Ted Zlatanov wrote:

TZ>     Do you compile your own binaries, for instance?

PM> Yes.

Could you provide the configure invocation you use and the summary of
libraries used?

PM>     Do you have problems with some specific network connections?

PM> Yes in slow and bad networks. It looks like after loosing some packets
PM> comes problem with C-g, and the only way was to killall -9 Emacs.

Using what package(s) to create the connections?  GnuTLS or plain connections?

TZ>     As far as "ugly" I have no opinion, and haven't noticed font
TZ>     issues or other visual problems. The NS port's functionality has
TZ>     been all right for me, especially keyboard entry,
TZ>     multiprocessing, and networking.

PM> Did you noticed that NS port is just fine only for those who never
PM> tried Mac Port, and those who are not using OS X every day?

Again, I don't claim there is no problem, only that I haven't
experienced the problems others have.  I would like us all to figure out
common things between our environments that contribute to the
reported instability of the NS port.

To answer your implied question, yes I have tried the Mac port, and yes
I use OS X (and the NS port on it) every day.  But with the Inconsolata
font at 18 pt size, I don't see visual issues and ugliness.

I can't say I care much for dictionary definitions and two-finger buffer
switching (I use helm and `C-x b'), but I see your point and hope
Mitsuharu-san's work can benefit all Emacs users on Mac OS X
eventually.  These are neat native features; my only concern is that
they take work to implement and lock users into a non-free platform.
I'd rather see features that benefit all Emacs users on all platforms.

I do think the best way forward is to merge the NS port and the Mac port
in a way that makes the NS port developers and Mitsuharu-san willing to
keep contributing.  In other words, rather than trying to "pick A over
B," let's find a way to have everyone work together to improve Emacs.

Ted

Re: Emacs on OS X development

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Tue, 24 Jul 2012 08:25:41 +0200
> Cc: Paul Michael Reilly <pmr@pajato.com>,
> 	"emacs-devel@gnu.org" <emacs-devel@gnu.org>,
> 	John Wiegley <johnw@newartisans.com>
> 
> The basic concept is to have one thread for file descriptors and let the main thread deal with Cocoa events.  The code today does something similar, but it relies on polling each 0.1 second.

Once in 100 msec is an awfully low frequency.  What happens if the
period is decreased to 10 or even 5 msec?

Re: Emacs on OS X development

[John Wiegley]

>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:

> I do think the best way forward is to merge the NS port and the Mac port in
> a way that makes the NS port developers and Mitsuharu-san willing to keep
> contributing.  In other words, rather than trying to "pick A over B," let's
> find a way to have everyone work together to improve Emacs.

I couldn't agree more, and I think this is the best solution, if we can make
it work.

John

Re: Emacs on OS X development

[chad]

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


On Jul 24, 2012, at 6:04 AM, Pavlo Martynenko wrote:
>> 
> <Screen Shot 2012-07-24 at 12.17.54.png>
> 
> NS port is on the left where the font is narrow and faint. Same font but different frame height. And where is the true brown?

I zoomed in on your screenshot (specifically on the word `This' at the top) and did not see any font differences.  I do see the inter-line spacing being different, and I prefer the NS port version.  It's possible that I could find some if I looked harder.  

Here's a screenshot of the two renderings of `This' side by side.  Can you point out the differences between them, so that we (by which I mostly mean `someone more knowledgable than I') can look into the problems?



I'm not sure what you meant by `true brown', but if you're talking about the info headers being brown on the ns port and red on the mac port, the face uses the color `brown', so I'm not sure that helps.  Do you not see that the red text in the mac port labelled itself `brown'?  Is this a color-perception issue, maybe on my part?

> Btw. Mac Port has more great features. [...] 

Yeah, I understand that there are nifty features in each that would be good to have in both.  I don't think anyone disagrees with that.  Some of them might be tricky to add to the GNU Emacs project, since we try to never make non-Free systems `better' than Free systems, but I think many of the features you're talking about are reasonably thought of as `basic functionality for that system'.  Certainly, modern macosx applications respond to multi-touch gestures and full-screen requests better than the current ns port.


> Yes in slow and bad networks. It looks like after loosing some packets comes problem with C-g, and the only way was to killall -9 Emacs.

Are these network connections made from within emacs, or problems with using emacs over a network connection?  If you can report bugs for these, that would be great.  I don't make much use of emacs network connections these days, but several others do.

>> As far as "ugly" I have no opinion, and haven't noticed font issues or
>> other visual problems. The NS port's functionality has been all right
>> for me, especially keyboard entry, multiprocessing, and networking.
> 
> Did you noticed that NS port is just fine only for those who never tried Mac Port, and those who are not using OS X every day?

As I already mentioned, I use OSX every day, and have been using the ns port for years. I have been trying the mac port frequently, as it developed.  I have never used it for more than a day or two, because it is/was always missing features that the NS port had, and never offered me anything I wanted more than those features. 

I neither doubt nor feel threatened by the existence of people who prefer the mac port. I do say that people who say that the mac port is clearly superior in every way are either confused or wrong, but I also don't think that's interesting - I would much prefer to have the best of both worlds.  For me, saying ``just use the mac port'' is demonstrably NOT the best of both worlds. I'm hopeful that we can get there, especially now that the mac port is closer than ever to the ns port (sadly not close enough for trivial patching, but still pretty close).

Thanks,
*Chad


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

[-- Attachment #2.2: ThisThis.png --]
[-- Type: image/png, Size: 11252 bytes --]

Re: Emacs on OS X development

[Jan Djärv]

Hello. 

24 jul 2012 kl. 10:36 skrev YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>:

>>>>>> On Tue, 24 Jul 2012 08:25:41 +0200, Jan Djärv <jan.h.d@swipnet.se> said:
> 
>>> I hope someone can try and tackle it, e.g. starting by comparing
>>> the approach used currently in the NS port compared to the X, Gtk,
>>> Windows or Mac ports, so as to devise a plan.
> 
>> I have a plan to do more or less what Gdk does on OSX, use lower
>> level (Core Foundation) API:s. The NS-port has many special things
>> (resizing, redrawing and more) that depends on how things are done
>> now, so it isn't just a replacement of a few functions.
> 
>> I haven't looked at the Mac port, but if it uses CF for the event
>> loop, code may be reused from there.
> 
> The Mac port uses CF for that purpose only on older versions of Mac OS
> X.  For newer versions, it uses Grand Central Dispatch instead:
> 
>  http://lists.gnu.org/archive/html/emacs-devel/2012-01/msg00035.html
> 
> I'm not sure about the recent situation, but I remember neither of
> them was (widely, at least) available on GNUstep.

No, CF is not available on GNUStep. I planned to use a modified version of the current loop, that removes the timeout. After some experiments it seems that this gives you almost all the performance gains. I'm going to try on a  slower machine also.
If it looks good then we might as well skip CF.

There is still the problem why the NS-port does not redraw during resize.

    Jan D.

Re: Emacs on OS X development

[Jan Djärv]

Hello.

24 jul 2012 kl. 11:01 skrev Stefan Monnier <monnier@IRO.UMontreal.CA>:

>> I have a plan to do more or less what Gdk does on OSX, use lower level (Core
>> Foundation) API:s. The NS-port has many special things (resizing, redrawing
>> and more) that depends on how things are done now, so it isn't
>> just a replacement of a few functions.
>> I haven't looked at the Mac port, but if it uses CF for the event loop, code
>> may be reused from there.
>> The basic concept is to have one thread for file descriptors and let the
>> main thread deal with Cocoa events.  The code today does something similar,
>> but it relies on polling each 0.1 second.
> 
> Could you add this discussion to etc/TODO, adding as much detail as you
> (and others) can about how it works now and how it could be changed?

I will do that within couple of days. 

> BTW, why not use the main thread for file-descriptors?

When Emacs isn't talking to subprocesses or the network there are no file descriptors. In that case we can manage with just the normal NS event loop and we do not need to communicate with another thread. I think this is a very common case (that is, it is how I use Emacs most of the time :-). 

Also, the NS event loop is already setup in the main thread, it requires some setup in other threads.

Communicate the data and result for a select call between threads is much easier than handling events between threads.

     Jan D. 

Re: Emacs on OS X development

[Jan Djärv]

Hello. 

24 jul 2012 kl. 18:09 skrev Eli Zaretskii <eliz@gnu.org>:

>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Tue, 24 Jul 2012 08:25:41 +0200
>> Cc: Paul Michael Reilly <pmr@pajato.com>,
>>    "emacs-devel@gnu.org" <emacs-devel@gnu.org>,
>>    John Wiegley <johnw@newartisans.com>
>> 
>> The basic concept is to have one thread for file descriptors and let the main thread deal with Cocoa events.  The code today does something similar, but it relies on polling each 0.1 second.
> 
> Once in 100 msec is an awfully low frequency.  What happens if the
> period is decreased to 10 or even 5 msec?

It does not make much difference. The overhead of other stuff (enter and exit the loop) takes over. 

     Jan D. 

Re: Emacs on OS X development

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 25 Jul 2012 09:27:36 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

>> The Mac port uses CF for that purpose only on older versions of Mac
>> OS X.  For newer versions, it uses Grand Central Dispatch instead:
>> 
>> http://lists.gnu.org/archive/html/emacs-devel/2012-01/msg00035.html
>> 
>> I'm not sure about the recent situation, but I remember neither of
>> them was (widely, at least) available on GNUstep.

> No, CF is not available on GNUStep. I planned to use a modified
> version of the current loop, that removes the timeout. After some
> experiments it seems that this gives you almost all the performance
> gains. I'm going to try on a slower machine also.  If it looks good
> then we might as well skip CF.

Solving a problem with the NS port in a way that doesn't work on
GNUstep sounds really bad, so it would be nice if CF can be skipped.

> There is still the problem why the NS-port does not redraw during
> resize.

The Mac port does that, as long as no modifier keys are pressed during
resize.  As Mac OS X 10.7 introduced resizing from non-corner edges,
which can also initiate "move" rather than "resize" depending on the
initial drag direction, the code will become much more complicated if
the current strategy in the NS port is inherited.

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

Re: Emacs on OS X development

[Michael Albinus]

Pavlo Martynenko <pavelmart@gmail.com> writes:

> On 21 Jul 2012, at 17:02, Michael Albinus wrote:
>
>> Btw, does it depend whether you use the NS port or the Mac port?
>
> No. It is a Trump bug.

Then file a bug report, please.

> 	Pavlo

Best regards, Michael.

Re: Emacs on OS X development

[Ted Zlatanov]

On Tue, 24 Jul 2012 22:00:45 -0500 "John Wiegley" <johnw@newartisans.com> wrote: 

>>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I do think the best way forward is to merge the NS port and the Mac port in
>> a way that makes the NS port developers and Mitsuharu-san willing to keep
>> contributing.  In other words, rather than trying to "pick A over B," let's
>> find a way to have everyone work together to improve Emacs.

JW> I couldn't agree more, and I think this is the best solution, if we can make
JW> it work.

OK, then: Mitsuharu-san, is there any way to have the NS port and your
Mac port merged, preserving the desirable features of both?  For
instance, if GCD is available, to use GCD, but otherwise fall back to NS
behavior?  Are you interested in that level of integration today, or do
you prefer to keep your Mac port separate and fully under your control?

(sideways cc sent to Adrian Robert, one of the NS port maintainers)

Ted

Re: Emacs on OS X development

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 25 Jul 2012 10:41:33 -0400, Ted Zlatanov <tzz@lifelogs.com> said:

> OK, then: Mitsuharu-san, is there any way to have the NS port and
> your Mac port merged, preserving the desirable features of both?
> For instance, if GCD is available, to use GCD, but otherwise fall
> back to NS behavior?  Are you interested in that level of
> integration today, or do you prefer to keep your Mac port separate
> and fully under your control?

I don't think such merging makes a lot of sense.

Most of the C APIs used in the Mac port (e.g., Core Foundation, Core
Graphics, Core Text, and Grand Central Dispatch) are available and
widely used on iOS as well as Mac OS X.  (Ironically, major difference
between them lies in UIKit vs. AppKit, being C APIs mentioned above
almost identical.)  If GNUstep incorporates these "Core" C APIs (IIUC,
it is going to that direction more or less), then many part of the Mac
port can be reused.  This doesn't require any knowledge of Emacs
internals, and moreover benefits outside Emacs.

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

Re: Emacs on OS X development

[Pavlo Martynenko]

On 25 Jul 2012, at 10:17, chad <yandros@gmail.com> wrote:

>>> I zoomed in on your screenshot (specifically on the word `This' at the top) and did not see any font differences.  I do see the inter-line spacing being different, and I prefer the NS port version.  It's possible that I could find some if I looked harder.  
> Here's a screenshot of the two renderings of `This' side by side.  Can you point out the differences between them, so that we (by which I mostly mean `someone more knowledgable than I') can look into the problems?
> <ThisThis.png>

Actually good example how small things (font rendering or inter-line spacing) can have great impact. There is more than one word in the frame even more than one line, and summed together they can change overall perception of the hole frame making it looks faint.

> I'm not sure what you meant by `true brown', but if you're talking about the info headers being brown on the ns port and red on the mac port, the face uses the color `brown', so I'm not sure that helps.  Do you not see that the red text in the mac port labelled itself `brown'?  Is this a color-perception issue, maybe on my part?

They values are different #b1784b vs #af4d4c. And I wander where is the true one. And how it can impact rainbow-mode. Emacs has modes for css editing and makes hints for designer by changing the background of the colour number and it has to do it properly.

>> Yes in slow and bad networks. It looks like after loosing some packets comes problem with C-g, and the only way was to killall -9 Emacs.
> Are these network connections made from within emacs, or problems with using emacs over a network connection?  

From emacs by using tramp, cssh, el-get, gnus.

> If you can report bugs for these, that would be great.  I don't make much use of emacs network connections these days, but several others do.

I surely do if stumble upon one by using Mac port.

> For me, saying ``just use the mac port'' is demonstrably NOT the best of both worlds. I'm hopeful that we can get there, especially now that the mac port is closer than ever to the ns port (sadly not close enough for trivial patching, but still pretty close).

I vote for both of them. NS port for GNUStep and Mac port for OS X. But not to merge Mac port into the NS port. They are different. And from my point of view NS port makes great editor Emacs looks like an old type machine. And users will never know about how great it is and prefer ordinary non-Free editors like TextMate or else.

And here https://vimeo.com/46309150 is GUI bug in NS port.

	Pavlo

Re: Emacs on OS X development

[Donald Curtis]

Yamamoto, 


Are you interested in hosting your "working" patches on Github or some other public VCS so that other people can help contribute?  It would also be nice if I could build against HEAD in BZR with your patches, but I am not sure that I am currently able to adapt patches from 24.1 to the development version of Emacs.

I'm not sure that you even maintain this list, rather, maybe you just update your patches when a new release of Emacs happens. 



Donald

Re: Emacs on OS X development

[Ted Zlatanov]

On Fri, 27 Jul 2012 07:58:35 +0900 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote: 

>>>>>> On Wed, 25 Jul 2012 10:41:33 -0400, Ted Zlatanov <tzz@lifelogs.com> said:
>> OK, then: Mitsuharu-san, is there any way to have the NS port and
>> your Mac port merged, preserving the desirable features of both?
>> For instance, if GCD is available, to use GCD, but otherwise fall
>> back to NS behavior?  Are you interested in that level of
>> integration today, or do you prefer to keep your Mac port separate
>> and fully under your control?

YM> I don't think such merging makes a lot of sense.

YM> Most of the C APIs used in the Mac port (e.g., Core Foundation, Core
YM> Graphics, Core Text, and Grand Central Dispatch) are available and
YM> widely used on iOS as well as Mac OS X.  (Ironically, major difference
YM> between them lies in UIKit vs. AppKit, being C APIs mentioned above
YM> almost identical.)  If GNUstep incorporates these "Core" C APIs (IIUC,
YM> it is going to that direction more or less), then many part of the Mac
YM> port can be reused.  This doesn't require any knowledge of Emacs
YM> internals, and moreover benefits outside Emacs.

Let me ask a different series of questions, hoping to understand how we
can improve the Emacs experience on Mac OS X.

If the Mac port was part of Emacs, would you continue to contribute to
it there, handle Emacs bugs against it, and keep up with core changes
that affect it?

If we found a way for the two ports to coexist in one source tree inside
Emacs by using #ifdefs and other mechanisms, would you keep working on
the Mac port?  Or does it have to be a separate source tree?

Are there special tools required to build the Mac port, which casual
developers won't have?

Could you and the NS developers collaborate to accomplish this
coexistence?

Thanks
Ted

Re: Emacs on OS X development

[Óscar Fuentes]

Ted Zlatanov <tzz@lifelogs.com> writes:

[snip]

> If we found a way for the two ports to coexist in one source tree inside
> Emacs by using #ifdefs and other mechanisms, would you keep working on
> the Mac port?  Or does it have to be a separate source tree?

I'll suggest to use different branches for every port (including MS
Windows). This way you can avoid most part of the #ifdef crazyness,
keeping the code much cleaner and responsability divisions better
defined.

A consequence of this would be to have to distribute several source
tarballs (one per port) instead of just a monolithic one, but I think it
is a lesser price to pay.

[snip]

Re: Emacs on OS X development

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 30 Jul 2012 02:04:27 +0200
> 
> I'll suggest to use different branches for every port (including MS
> Windows).

IMNSHO, this is a bad idea.  Its only sure consequence will be
divergence and bitrot of code, at least for MS Windows, because none
of the people who care about that port have time to invest on merges.
(FWIW, I don't see anything different on the NS side, but maybe I'm
mistaken.)  Given our style of committing changes to the master
repository, which involves almost no discussions, let alone formal
peer review before the commit, which would involve explaining the
rationale for the changes needed to consider whether to merge or not,
and given the sheer rate of commits, this divergence will be fast and
cruel.

> This way you can avoid most part of the #ifdef crazyness, keeping
> the code much cleaner and responsability divisions better defined.
> 
> A consequence of this would be to have to distribute several source
> tarballs (one per port) instead of just a monolithic one, but I think it
> is a lesser price to pay.

The real price to pay will be the bugs we miss on each separate
platform, which are only revealed on the other, due to a different
compiler/library/environment/memory arrangement/whatever.  How many
times in the past bugs in the Emacs code were found on Windows (or
even in the MS-DOS port)?  Segregate the ports, and you will lose all
that.  In effect, the project will be split into several ones that
hardly ever communicate.

At some time in the past, developers understood very well the value of
the diversity for the quality of their packages.  I lament that time.

Re: Emacs on OS X development

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> I'll suggest to use different branches for every port (including MS
>> Windows).
>
> IMNSHO, this is a bad idea.  Its only sure consequence will be
> divergence and bitrot of code, at least for MS Windows, because none
> of the people who care about that port have time to invest on merges.

If platform-specific code is well isolated, almost all merges are
conflict-less, automatic operations.

[snip]

> The real price to pay will be the bugs we miss on each separate
> platform, which are only revealed on the other, due to a different
> compiler/library/environment/memory arrangement/whatever.  How many
> times in the past bugs in the Emacs code were found on Windows (or
> even in the MS-DOS port)?  Segregate the ports, and you will lose all
> that.  In effect, the project will be split into several ones that
> hardly ever communicate.

I don't see how using a branch instead of #ifdef's with its associated
platform-specific macro definitions makes any difference here. With the
current setup hackers working on GNU/Linux are oblivious of bugs that
manifest only on MS Windows and depend on reports from other hackers or
users. If anything, using branches for ports would help to determine
where the bug was introduced: on platform-specific code or in the shared
code, as discriminating changes among those areas would be easy looking
at the VCS history.

[snip]

Re: Emacs on OS X development

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 30 Jul 2012 06:48:07 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I'll suggest to use different branches for every port (including MS
> >> Windows).
> >
> > IMNSHO, this is a bad idea.  Its only sure consequence will be
> > divergence and bitrot of code, at least for MS Windows, because none
> > of the people who care about that port have time to invest on merges.
> 
> If platform-specific code is well isolated, almost all merges are
> conflict-less, automatic operations.

That's true, but in Emacs, most of the platform-specific code is not
isolated.  In fact, it is rarely even marked as platform-specific.
The display engine is a good example.

Another pertinent example is the way whole portions of code are copied
from xfns.c to w32fns.c and back, with minor changes.  The same goes
for w32term.c and xterm.c (and the ns* files as well).

> I don't see how using a branch instead of #ifdef's with its associated
> platform-specific macro definitions makes any difference here.

That's too bad.

> With the current setup hackers working on GNU/Linux are oblivious of
> bugs that manifest only on MS Windows and depend on reports from
> other hackers or users.

That's not the dynamics you see now on emacs-devel and bug-gnu-emacs.

Separating ports will lead to alienation and lack of communications
very fast.

Re: Emacs on OS X development

[Stefan Monnier]

> If platform-specific code is well isolated, almost all merges are
> conflict-less, automatic operations.

If it's well isolated, you don't need #ifdefs either.

So the real answer is to better isolate platform-specific code, reducing
redundancy between w32*.c, x*.c, and ns*.m.
There's a lot of room for improvement there.


        Stefan

Re: Emacs on OS X development

[Paul Eggert]

On 07/29/2012 09:48 PM, Óscar Fuentes wrote:
> using branches for ports would help to determine
> where the bug was introduced

I don't see why.  In either case, one must look
at the history.  With branches, the history is less
complicated to some extent (because one sometimes needs to look
only at one branch's history) but more complicated in
other respects (because one must sometimes look at
another branch's history, if a merge introduces
a problem); overall, using branches doesn't seem like
it'd help much here.

Certainly Emacs could be organized better, by isolating
platform-specific code and by removing duplication among
the ports we have, but branches quite possibly would make
that (big) job even harder than it is now.

Re: Emacs on OS X development

[Óscar Fuentes]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 07/29/2012 09:48 PM, Óscar Fuentes wrote:
>> using branches for ports would help to determine
>> where the bug was introduced
>
> I don't see why.  In either case, one must look
> at the history.  With branches, the history is less
> complicated to some extent (because one sometimes needs to look
> only at one branch's history) but more complicated in
> other respects (because one must sometimes look at
> another branch's history, if a merge introduces
> a problem);

If a merge introduced a problem into a branch, the merged history
already is in that branch, i.e. no need to look at the other branch.

If a bug is reproducible on the "canonical" or master branch (let's say
that it is the one devoted to GNU/Linux and compatible systems) you
don't need to walk through unrelated, port-specific commits while
searching for suspects. If the bug is known to affect only a given port,
you don't need to isolate the port-specific commits from the rest, as
the DAG will show them nicely. Plus, bisection effort is greatly
reduced.

IMO, the idea of using a branch per port is not something that would
bring in great advantages to Emacs. I think of it as something to
consider. At some point in the past I devoted a slice of time to study
the Emacs C sources and it was a bit of an inconvenience to discriminate
which parts contained the relevant code, among so much obsolete stuff
(quite a bit of that was cleared since) and port-specific code that was
either intermixed with the rest (there are some #ifdef...#endif chunks
that comprise hundreds of lines!) or on files that becomes noise on the
listings. If emacs goes the route of adidng new ports to the core source
base, those annoyances would become worse and worse. I know of projects
that, for every platform they support, the number of relevant files is a
minority within the whole set. Not saying that Emacs will reach that
state anytime soon, but it is something that is better to avoid, if
possible, even while it is a lesser problem.

[snip]

Re: Emacs on OS X development

[Nix]

On 30 Jul 2012, Óscar Fuentes spake thusly:

> Eli Zaretskii <eliz@gnu.org> writes:
>> The real price to pay will be the bugs we miss on each separate
>> platform, which are only revealed on the other, due to a different
>> compiler/library/environment/memory arrangement/whatever.  How many
>> times in the past bugs in the Emacs code were found on Windows (or
>> even in the MS-DOS port)?  Segregate the ports, and you will lose all
>> that.  In effect, the project will be split into several ones that
>> hardly ever communicate.
>
> I don't see how using a branch instead of #ifdef's with its associated
> platform-specific macro definitions makes any difference here.

Well, you can if you like think of a branch as being equivalent to a
giant #ifdef around every single file, splitting each file into sections
as large as the whole file is now, one for each platform.

And that is where the problem lies. Right now, most of the code in Emacs
is generic, and people who encounter bugs (or mistaken portability
assumptions) in that code on one platform, and fix it, fix it on all.
With multiple per-platform branches, that doesn't happen. (Particularly
with bzr as bad as it is at keeping branches in synch. Cross-branch
merges? Really?)

Splitting ports into their own branches might be done because the port
maintainer just can't get on with the other maintainers, or because
their port is churning hard in early bringup phase and they're planning
to merge back to trunk when it settles down, but I can't see a
*sensible* reason to do it long-term.

-- 
NULL && (void)

Re: Emacs on OS X development

[Ted Zlatanov]

On Mon, 30 Jul 2012 02:04:27 +0200 Óscar Fuentes <ofv@wanadoo.es> wrote: 

ÓF> I'll suggest to use different branches for every port (including MS
ÓF> Windows). This way you can avoid most part of the #ifdef crazyness,
ÓF> keeping the code much cleaner and responsability divisions better
ÓF> defined.

I asked Mitsuharu-san about a single source tree for his code and the NS
port for a specific reason: a branch encourages divergence, while a
single source tree discourages it.  Our goal should be to have a good
experience on Mac OS X, not to offer the NS port and the Mac port
separately.  Also I think keeping the whole Mac port in a Bazaar branch
would be painful for the maintainers and developers, but that's an
inconvenience and not an impediment.

Several people have suggested the Mac port, with its single developer,
should be used instead of the NS port.  Whether the Mac port is added to
the NS port or replaces it, that requires a commitment from
Mitsuharu-san to keep his code up to date with the rest of the
development team; to consider how new features could be added to benefit
all platforms and not just Mac OS X; and to fix bugs other developers
may have introduced.  It's not simply a matter of "let's use this port,
it looks great and has the features I like."  That's my view, anyhow,
and I welcome anyone else's opinion.

Ted

Re: Emacs on OS X development

[Adrian Robert]

On 2012/07/25, at 10:41, Ted Zlatanov wrote:

...
> OK, then: Mitsuharu-san, is there any way to have the NS port and your
> Mac port merged, preserving the desirable features of both?  For
> instance, if GCD is available, to use GCD, but otherwise fall back to NS
> behavior?  Are you interested in that level of integration today, or do
> you prefer to keep your Mac port separate and fully under your control?
> 
> (sideways cc sent to Adrian Robert, one of the NS port maintainers)


Here is how I see the current situation:

- Basic functionality on OS X:

  Some users continue to be adversely affected by bugs on the NS port, while the Mac port seems less buggy.

  -> advantage Mac port

  
- GNUstep functionality:

  The Mac port does not offer anything here, and I don't think relying on GNUstep to replicate multiple levels of evolving Apple APIs will ever bring it much closer.

  -> advantage NS port


- OS X platform integration:

  The Mac port currently sounds like it does this better, though ironically the NS port was originally resurrected partly because of similar deficiencies in the ancestor Carbon port.  However, most of this is "distribution"-level stuff (like Aquamacs) that would not survive a merge to mainline.

  -> advantage neither


- Developer participation:

  The NS port has a few people that fix bugs and make improvements, but some of them stay stuck outside of the tree (Aquamacs), and there is no high time-and-ability maintainer.  The Mac port has only one person, but doing a good job.  More might come in if the source code were made accessible and better tied to mainline.

  -> advantage neither


As far as a merge, one way would be to bring in the event-handling from the Mac port to the NS port.  When I looked at this it seemed practical, but would be a fairly intense effort, say 5 full-time days, probably an underestimate since a solution for GNUstep would need to be maintained.  Then there would also be the text rendering.  Since that is more modular, it might be possible to bring in Yamamoto's backend almost whole as a compile-time option.  I also don't think the current NS backend has that many deficiencies, but for whatever reason they've stayed there (text shaping, line spacing, font selection).

The second merge option would be to rework portions of the Mac port to more heavily utilize the Cocoa APIs, to the point it could be ifdef'd to run on GNUstep.  Yamamoto could provide the best assessment here, but my feeling when I looked at it was that it would not be easy.  Definitely more work than going the other way.


-Adrian

Re: Emacs on OS X development

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 29 Jul 2012 18:31:04 -0400, Ted Zlatanov <tzz@lifelogs.com> said:

> Let me ask a different series of questions, hoping to understand how
> we can improve the Emacs experience on Mac OS X.

> If the Mac port was part of Emacs, would you continue to contribute
> to it there, handle Emacs bugs against it, and keep up with core
> changes that affect it?

I'm not willing to do that if OS X users consider the NS port enough.
The maintainers wouldn't agree for the inclusion of the Mac port
unless many OS X users say the NS port is not good enough, anyway.

From my experience in the maintenance of the Carbon port, keeping it
work with short delay in the trunk requires enough motivation.  If
many people consider the Mac port simply full of features that are
only meaningful for specific kind of people among OS X users, then I
would rather keep it separated and avoid being bothered with frequent
catch-up.

> If we found a way for the two ports to coexist in one source tree
> inside Emacs by using #ifdefs and other mechanisms, would you keep
> working on the Mac port?  Or does it have to be a separate source
> tree?

The Mac port is supposed not to break the other builds, though I don't
test it in every release.

> Are there special tools required to build the Mac port, which casual
> developers won't have?

No.  You don't even need to install external libraries such as librsvg
or libotf to support SVG display or text shaping, respectively.  Image
scaling/rotation/cropping, which would be provided via ImageMagick for
X11 builds, are emulated using the Image I/O framework that is bundled
with OS X as well as iOS (GNUstep is also to support it via Opal?).
Optionally you can use librsvg or ImageMagick if you really want them.

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

Re: Emacs on OS X development

[Ted Zlatanov]

On Tue, 31 Jul 2012 14:31:30 -0400 Adrian Robert <adrian.b.robert@gmail.com> wrote: 

AR> As far as a merge, one way would be to bring in the event-handling
AR> from the Mac port to the NS port.  When I looked at this it seemed
AR> practical, but would be a fairly intense effort, say 5 full-time days,
AR> probably an underestimate since a solution for GNUstep would need to
AR> be maintained.  Then there would also be the text rendering.  Since
AR> that is more modular, it might be possible to bring in Yamamoto's
AR> backend almost whole as a compile-time option.  I also don't think the
AR> current NS backend has that many deficiencies, but for whatever reason
AR> they've stayed there (text shaping, line spacing, font selection).

AR> The second merge option would be to rework portions of the Mac port to
AR> more heavily utilize the Cocoa APIs, to the point it could be ifdef'd
AR> to run on GNUstep.  Yamamoto could provide the best assessment here,
AR> but my feeling when I looked at it was that it would not be easy.
AR> Definitely more work than going the other way.

Based on your and Mitsuharu-san's reply, I think merging his work into
the NS port is the better path rather than trying to bring the Mac port
into the Emacs tree.  If you can define the work necessary to do the
event handling and text rendering rework, plus the other specific
features of the Mac port that are missing in the NS port, that would be
a helpful TODO list for any contributors.

Thanks
Ted

Re: Emacs on OS X development

[Adrian Robert]

I think Jan is closer to the event-handling code than I have been lately, so I'd rely on his judgment as to whether what I'm saying is accurate or realistic, and how it could be carried out.

Also, merging this code would just be a way to improve the current NS port for users, it is not an answer to whether the Mac port should replace it, etc. etc..  (Which has already been covered in this thread as well as we can cover it for now.)

thanks,
Adrian




On 2012/08/03, at 16:08, Ted Zlatanov wrote:

> The following message is a courtesy copy of an article
> that has been posted to gmane.emacs.devel as well.
> 
> On Tue, 31 Jul 2012 14:31:30 -0400 Adrian Robert <adrian.b.robert@gmail.com> wrote: 
> 
> AR> As far as a merge, one way would be to bring in the event-handling
> AR> from the Mac port to the NS port.  When I looked at this it seemed
> AR> practical, but would be a fairly intense effort, say 5 full-time days,
> AR> probably an underestimate since a solution for GNUstep would need to
> AR> be maintained.  Then there would also be the text rendering.  Since
> AR> that is more modular, it might be possible to bring in Yamamoto's
> AR> backend almost whole as a compile-time option.  I also don't think the
> AR> current NS backend has that many deficiencies, but for whatever reason
> AR> they've stayed there (text shaping, line spacing, font selection).
> 
> AR> The second merge option would be to rework portions of the Mac port to
> AR> more heavily utilize the Cocoa APIs, to the point it could be ifdef'd
> AR> to run on GNUstep.  Yamamoto could provide the best assessment here,
> AR> but my feeling when I looked at it was that it would not be easy.
> AR> Definitely more work than going the other way.
> 
> Based on your and Mitsuharu-san's reply, I think merging his work into
> the NS port is the better path rather than trying to bring the Mac port
> into the Emacs tree.  If you can define the work necessary to do the
> event handling and text rendering rework, plus the other specific
> features of the Mac port that are missing in the NS port, that would be
> a helpful TODO list for any contributors.
> 
> Thanks
> Ted

Re: Emacs on OS X development

[Dave Abrahams]

on Thu Aug 02 2012, YAMAMOTO Mitsuharu <mituharu-AT-math.s.chiba-u.ac.jp> wrote:

>>>>>> On Sun, 29 Jul 2012 18:31:04 -0400, Ted Zlatanov <tzz@lifelogs.com> said:
>
>> If the Mac port was part of Emacs, would you continue to contribute
>> to it there, handle Emacs bugs against it, and keep up with core
>> changes that affect it?
>
> I'm not willing to do that if OS X users consider the NS port enough.
> The maintainers wouldn't agree for the inclusion of the Mac port
> unless many OS X users say the NS port is not good enough, anyway.

<de-lurk>
It's not good enough
<re-lurk>

-- 
Dave Abrahams
BoostPro Computing                  Software Development        Training
http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost

Re: Emacs on OS X development

[Jan Djärv]

3 aug 2012 kl. 22:28 skrev Adrian Robert:

> I think Jan is closer to the event-handling code than I have been lately, so I'd rely on his judgment as to whether what I'm saying is accurate or realistic, and how it could be carried out.

I agree with the points below.  The main issue with the NS event loop is that it doesn't redraw on resize.  But besides that, I think it can be improved to the point of being good enough for both OSX and GNUStep.

The NS font backend works, its main problem is that it uses some old deprecated methods.  Bringing in the Mac port font end is a more modular operation, and does not have much impact.


	Jan D.

> 
> Also, merging this code would just be a way to improve the current NS port for users, it is not an answer to whether the Mac port should replace it, etc. etc..  (Which has already been covered in this thread as well as we can cover it for now.)
> 
> thanks,
> Adrian
> 
> 
> 
> 
> On 2012/08/03, at 16:08, Ted Zlatanov wrote:
> 
>> The following message is a courtesy copy of an article
>> that has been posted to gmane.emacs.devel as well.
>> 
>> On Tue, 31 Jul 2012 14:31:30 -0400 Adrian Robert <adrian.b.robert@gmail.com> wrote: 
>> 
>> AR> As far as a merge, one way would be to bring in the event-handling
>> AR> from the Mac port to the NS port.  When I looked at this it seemed
>> AR> practical, but would be a fairly intense effort, say 5 full-time days,
>> AR> probably an underestimate since a solution for GNUstep would need to
>> AR> be maintained.  Then there would also be the text rendering.  Since
>> AR> that is more modular, it might be possible to bring in Yamamoto's
>> AR> backend almost whole as a compile-time option.  I also don't think the
>> AR> current NS backend has that many deficiencies, but for whatever reason
>> AR> they've stayed there (text shaping, line spacing, font selection).
>> 
>> AR> The second merge option would be to rework portions of the Mac port to
>> AR> more heavily utilize the Cocoa APIs, to the point it could be ifdef'd
>> AR> to run on GNUstep.  Yamamoto could provide the best assessment here,
>> AR> but my feeling when I looked at it was that it would not be easy.
>> AR> Definitely more work than going the other way.
>> 
>> Based on your and Mitsuharu-san's reply, I think merging his work into
>> the NS port is the better path rather than trying to bring the Mac port
>> into the Emacs tree.  If you can define the work necessary to do the
>> event handling and text rendering rework, plus the other specific
>> features of the Mac port that are missing in the NS port, that would be
>> a helpful TODO list for any contributors.
>> 
>> Thanks
>> Ted
> 

Re: Emacs on OS X development

[Ted Zlatanov]

On Sun, 5 Aug 2012 14:51:38 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote: 

JD> The main issue with the NS event loop is that it doesn't redraw on
JD> resize.  But besides that, I think it can be improved to the point
JD> of being good enough for both OSX and GNUStep.

Is there a list of TODOs or bugs that can be connected to this?

JD> The NS font backend works, its main problem is that it uses some old
JD> deprecated methods.  Bringing in the Mac port font end is a more
JD> modular operation, and does not have much impact.

Jan and Adrian, can you define the work in such a way that someone will
be able to do it, especially what functions need to be modified or
rewritten, and what parts of the Mac port are relevant?

Thanks
Ted

Re: Emacs on OS X development

[Jan Djärv]

Hello.

21 dec 2012 kl. 18:20 skrev Ted Zlatanov <tzz@lifelogs.com>:

> On Sun, 5 Aug 2012 14:51:38 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote: 
> 
> JD> The main issue with the NS event loop is that it doesn't redraw on
> JD> resize.  But besides that, I think it can be improved to the point
> JD> of being good enough for both OSX and GNUStep.
> 
> Is there a list of TODOs or bugs that can be connected to this?
> 

There is a TODO on the NS event loop and redraw.

> JD> The NS font backend works, its main problem is that it uses some old
> JD> deprecated methods.  Bringing in the Mac port font end is a more
> JD> modular operation, and does not have much impact.
> 
> Jan and Adrian, can you define the work in such a way that someone will
> be able to do it, especially what functions need to be modified or
> rewritten, and what parts of the Mac port are relevant?

I looked at the Mac port font code and it uses Carbon.  That means that we still have to keep the current backend around for GNUStep.  So there is no gain in bringing it in w.r.t. maintenance, quite the opposite.

The work is basically "bring in a new font end".  If I have to specify more details than that, it will take longer time than actually do the work.

	Jan D.

Re: Emacs on OS X development

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 23 Dec 2012 15:50:18 +0100, Jan Djärv <jan.h.d@swipnet.se> said:

> I looked at the Mac port font code and it uses Carbon.  That means
> that we still have to keep the current backend around for GNUStep.
> So there is no gain in bringing it in w.r.t. maintenance, quite the
> opposite.

The font backend driver for the Mac port actually uses C APIs, such as
Core Foundation, Core Graphics, and Core Text, all of which are also
available on iOS but not on GNUstep (though there are several attempts
to support them).  Anyway, they are not usually called "Carbon".

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

Re: Emacs on OS X development

[Jan Djärv]

Hello.

24 dec 2012 kl. 01:23 skrev YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>:

>>>>>> On Sun, 23 Dec 2012 15:50:18 +0100, Jan Djärv <jan.h.d@swipnet.se> said:
> 
>> I looked at the Mac port font code and it uses Carbon.  That means
>> that we still have to keep the current backend around for GNUStep.
>> So there is no gain in bringing it in w.r.t. maintenance, quite the
>> opposite.
> 
> The font backend driver for the Mac port actually uses C APIs, such as
> Core Foundation, Core Graphics, and Core Text, all of which are also
> available on iOS but not on GNUstep (though there are several attempts
> to support them).  Anyway, they are not usually called "Carbon".

I just looked at what it included, i.e. 
#include <Carbon/Carbon.h>
in macgui.h.  But you are right, Core API:s are not Carbon.  But from a GNUStep point of view, Core API:s and Carbon are the same, that is mostly unavailable.

	Jan D.