Changes 2009-07-15/16 in branch?

Changes 2009-07-15/16 in branch?

[Adrian Robert]

Hello Yamamoto-san,

Did you mean to check the changes below into the branch?  I *think*  
these are pretty safe, but it seems a bit close to release for such  
feature changes, even in the name of standardization.  My vote would  
be to do these on trunk only for now.

Also:

ns_get_color(): Shouldn't the description comment for ns_get_color()  
be updated further?  It looks like something was just chopped off,  
leaving the rest making little sense.  What is the bug or problem this  
change fixes?

ns_color_to_lisp(): The function could be simplified now that you have  
eliminated a special case.

nsfont_draw(): Would setting the foreground instead of the background  
color to the bitmap constitute a corrected implementation?

ns-set-background-alpha: The implementation you just removed was  
superior to that for (set-frame-parameter nil 'alpha ##): it does not  
alter the alpha of the titlebar, scrollbars, modeline, or text.  This  
makes it usable, instead of a curiosity.  It also provides access via  
an interactive function.  The correct fix would be to improve the (set- 
frame-parameter) version, not remove this while no alternative exists  
for users.


2009-07-16  YAMAMOTO Mitsuharu  <mituharu@math.s.chiba-u.ac.jp>

         * nsfns.m (Fns_set_alpha): Remove function.
         (syms_of_nsfns): Don't defsubr it.

         * nsterm.m (ns_get_color): Remove incompatible color formats.
         (ns_color_to_lisp): Generate #rrggbb color format string.

2009-07-15  YAMAMOTO Mitsuharu  <mituharu@math.s.chiba-u.ac.jp>

         * nsfont.m (nsfont_draw): Remove code for stippling, which  
actually
         does tiling.

         * nsterm.m (ns_maybe_dumpglyphs_background): Likewise.

2009-07-16  YAMAMOTO Mitsuharu  <mituharu@math.s.chiba-u.ac.jp>

	* term/ns-win.el (ns-set-alpha): Don't declare.
	(ns-set-background-alpha): Remove function.

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 23 Jul 2009 07:22:55 -0400, Adrian Robert <adrian.b.robert@gmail.com> said:

> Hello Yamamoto-san, Did you mean to check the changes below into the
> branch?  I *think* these are pretty safe, but it seems a bit close
> to release for such feature changes, even in the name of
> standardization.  My vote would be to do these on trunk only for
> now.

Chong Yidong already made a query to me via a private mail.  Below is
my reply:

  It's essential to make these changes in the release branch so users
  may not use the incompatible formats by accident and introduce
  compatibility problems when they are removed in some future version.
  Upcoming version is the first one for the NS port.  Effectiveness is
  much lowered if such changes are deferred to the later versions.

  I've warned about such incompatibility issues that I think
  indispensable for the first official release version, but the author
  has not tried to address them (not just for this one!).

  Even if by any chance there's overlooked code as you say, it's only
  in the NS-specific part and relatively minor compared with total
  unstableness of the port itself.  Removing incompatible features at
  this timing is much more important unless the port is marked
  experimental/hackers-only.

  Anyway, let's wait at least a few days before making any changes in
  this respect.

> Also:

> ns_get_color(): Shouldn't the description comment for ns_get_color()
> be updated further?  It looks like something was just chopped off,
> leaving the rest making little sense.  What is the bug or problem
> this change fixes?

> ns_color_to_lisp(): The function could be simplified now that you
> have eliminated a special case.

I know the changes are not optimal.  But I wanted to keep them quite
straightforward so as to avoid regression.

> nsfont_draw(): Would setting the foreground instead of the
> background color to the bitmap constitute a corrected
> implementation?

I don't know if I understand your intention correctly from the above
sentence.  But if you believe you understand stippling correctly this
time, maybe you can make the change into the trunk.

> ns-set-background-alpha: The implementation you just removed was
> superior to that for (set-frame-parameter nil 'alpha ##): it does
> not alter the alpha of the titlebar, scrollbars, modeline, or text.
> This makes it usable, instead of a curiosity.  It also provides
> access via an interactive function.  The correct fix would be to
> improve the (set- frame-parameter) version, not remove this while no
> alternative exists for users.

I knew their difference.  I removed it because it belongs to "NS-only
implementation for features that are not inherently specific to NS."
(http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00594.html)

I think it's really bad for the "first-class" port to have such
features because they may be superseded in a platform-independent way
by some future versions and that introduces unnecessary
incompatibilities.

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

Re: Changes 2009-07-15/16 in branch?

[Stefan Monnier]

>> Hello Yamamoto-san, Did you mean to check the changes below into the
>> branch?  I *think* these are pretty safe, but it seems a bit close to
>> release for such feature changes, even in the name of
>> standardization.  My vote would be to do these on trunk only for now.

I'd agree.


        Stefan

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 23 Jul 2009 11:30:21 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>>> Hello Yamamoto-san, Did you mean to check the changes below into
>>> the branch?  I *think* these are pretty safe, but it seems a bit
>>> close to release for such feature changes, even in the name of
>>> standardization.  My vote would be to do these on trunk only for
>>> now.

> I'd agree.

All these changes are straightforward removal of the codes for
features that are not found in other platforms, and nevertheless not
inherently NS-specific.  I didn't add any code to provide new features
at all.

See also:
http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00630.html

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

Re: Changes 2009-07-15/16 in branch?

[Stefan Monnier]

>>>> Hello Yamamoto-san, Did you mean to check the changes below into
>>>> the branch?  I *think* these are pretty safe, but it seems a bit
>>>> close to release for such feature changes, even in the name of
>>>> standardization.  My vote would be to do these on trunk only for
>>>> now.

>> I'd agree.

> All these changes are straightforward removal of the codes for
> features that are not found in other platforms, and nevertheless not
> inherently NS-specific.  I didn't add any code to provide new features
> at all.

I know, but I think such changes so late in the pretest aren't
a good idea.  Only critical bugs deserve to be fixed now.


        Stefan

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 23 Jul 2009 21:09:20 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>>>>> Hello Yamamoto-san, Did you mean to check the changes below into
>>>>> the branch?  I *think* these are pretty safe, but it seems a bit
>>>>> close to release for such feature changes, even in the name of
>>>>> standardization.  My vote would be to do these on trunk only for
>>>>> now.

>>> I'd agree.

>> All these changes are straightforward removal of the codes for
>> features that are not found in other platforms, and nevertheless
>> not inherently NS-specific.  I didn't add any code to provide new
>> features at all.

> I know, but I think such changes so late in the pretest aren't a
> good idea.  Only critical bugs deserve to be fixed now.

I know.  But there are several peculiarities for the NS port.

  * The upcoming version is the first official one for the NS port.
    "First" means there's no previous one to care about compatibility.
    If we defer these changes to the next version (say 23.2), then
    compatibility problems occur between 23.1 and 23.2.
  * I've warned these incompatibilities several times hoping that the
    author himself fixes them.  I don't understand why he wants to
    break compatibility by keeping them.

And I don't think there's justification to keep the features I
removed.  Of course, there are plenty of them to remove.

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

Re: Changes 2009-07-15/16 in branch?

[Stefan Monnier]

> I know.  But there are several peculiarities for the NS port.

>   * The upcoming version is the first official one for the NS port.
>     "First" means there's no previous one to care about compatibility.
>     If we defer these changes to the next version (say 23.2), then
>     compatibility problems occur between 23.1 and 23.2.
>   * I've warned these incompatibilities several times hoping that the
>     author himself fixes them.  I don't understand why he wants to
>     break compatibility by keeping them.

> And I don't think there's justification to keep the features I
> removed.  Of course, there are plenty of them to remove.

I agree with all your points, but now is too late for 23.1.


        Stefan

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 23 Jul 2009 21:37:36 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> I know.  But there are several peculiarities for the NS port.

>>   * The upcoming version is the first official one for the NS port.
>>     "First" means there's no previous one to care about compatibility.
>>     If we defer these changes to the next version (say 23.2), then
>>     compatibility problems occur between 23.1 and 23.2.
>>   * I've warned these incompatibilities several times hoping that the
>>     author himself fixes them.  I don't understand why he wants to
>>     break compatibility by keeping them.

>> And I don't think there's justification to keep the features I
>> removed.  Of course, there are plenty of them to remove.

> I agree with all your points, but now is too late for 23.1.

So, what's your idea to prevent 23.1 users from unintended use of the
features that are incompatible with the other platforms and to be
removed in 23.2?

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

Re: Changes 2009-07-15/16 in branch?

[Stefan Monnier]

> So, what's your idea to prevent 23.1 users from unintended use of the
> features that are incompatible with the other platforms and to be
> removed in 23.2?

I don't think it's a problem that necessarily needs to be solved.


        Stefan

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 23 Jul 2009 23:17:25 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> So, what's your idea to prevent 23.1 users from unintended use of
>> the features that are incompatible with the other platforms and to
>> be removed in 23.2?

> I don't think it's a problem that necessarily needs to be solved.

I don't agree in this respect.  Reverting the changes in the branch
will result in breaking compatibility TWICE:

  * On 23.1, between the NS port and the other platforms.
  * On the NS port, between 23.1 and 23.2.

We should provide some care compensating for these breakages.

Note that I'm trying to find a constructive solution as we agree in
many other respects.

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

Re: Changes 2009-07-15/16 in branch?

[Jason Rumney]

YAMAMOTO Mitsuharu wrote:
> I don't agree in this respect.  Reverting the changes in the branch
> will result in breaking compatibility TWICE:
>
>   * On 23.1, between the NS port and the other platforms.
>   * On the NS port, between 23.1 and 23.2.
>
> We should provide some care compensating for these breakages.
>
> Note that I'm trying to find a constructive solution as we agree in
> many other respects.
>   

One solution is for 23.2 to provide an ns-compat.el library containing 
wrapper functions mapping the incompatible features
to their platform-independent replacements and emitting warnings to 
inform the user that they should change to use the platform-independent 
equivalents. Then in 23.3 or 24.1 we could remove this library from 
Emacs and require users to get it from elsewhere if they still want to 
use the incompatible features.

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 24 Jul 2009 11:44:10 +0800, Jason Rumney <jasonr@gnu.org> said:

> YAMAMOTO Mitsuharu wrote:
>> I don't agree in this respect.  Reverting the changes in the branch
>> will result in breaking compatibility TWICE:
>> 
>> * On 23.1, between the NS port and the other platforms.
>> * On the NS port, between 23.1 and 23.2.
>> 
>> We should provide some care compensating for these breakages.
>> 
>> Note that I'm trying to find a constructive solution as we agree in
>> many other respects.
>> 

> One solution is for 23.2 to provide an ns-compat.el library containing 
> wrapper functions mapping the incompatible features
> to their platform-independent replacements and emitting warnings to 
> inform the user that they should change to use the platform-independent 
> equivalents. Then in 23.3 or 24.1 we could remove this library from 
> Emacs and require users to get it from elsewhere if they still want to 
> use the incompatible features.

Perhaps this can be applied to some of the features I removed.  Let's
take a more closer look.  There might be a possibility of different
solutions for different changes.

What I removed was:

  1. Code for stippling.  This is wrongly implemented as tiling, which
     has been controversial whether or not to be included in the other
     platforms, IIUC.
  2. Code for interpreting incompatible color formats: RGBrrggbb,
     ARGBaarrggbb, HSVhhssvv, AHSVaahhssvv, and CMYKccmmyykk.  Besides
     the format itself, support for the alpha-component in color is
     not found in the other platforms but not inherently NS-specific.
  3. Lisp primitive ns-set-alpha (nsfns.m), which sets the alpha
     component of the given color to the specified value.  As in the
     argument for the alpha-component above, this is not inherently
     NS-specific.
  4. Lisp function ns-set-background-alpha (ns-win.el), which sets
     alpha-component of frame background color.  It is different from
     the frame parameter `alpha' as Adrian explained.  Again, this is
     not inherently NS-specific.

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

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

Richard, is it OK with you to keep the following features only for a
proprietary platform (Cocoa) in the Emacs 23.1 release?  Note that the
GNUstep port is now completely unusable.

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

>>>>> On Fri, 24 Jul 2009 13:12:45 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> What I removed was:

>   1. Code for stippling.  This is wrongly implemented as tiling, which
>      has been controversial whether or not to be included in the other
>      platforms, IIUC.
>   2. Code for interpreting incompatible color formats: RGBrrggbb,
>      ARGBaarrggbb, HSVhhssvv, AHSVaahhssvv, and CMYKccmmyykk.  Besides
>      the format itself, support for the alpha-component in color is
>      not found in the other platforms but not inherently NS-specific.
>   3. Lisp primitive ns-set-alpha (nsfns.m), which sets the alpha
>      component of the given color to the specified value.  As in the
>      argument for the alpha-component above, this is not inherently
>      NS-specific.
>   4. Lisp function ns-set-background-alpha (ns-win.el), which sets
>      alpha-component of frame background color.  It is different from
>      the frame parameter `alpha' as Adrian explained.  Again, this is
>      not inherently NS-specific.

Re: Changes 2009-07-15/16 in branch?

[Richard Stallman]

    Richard, is it OK with you to keep the following features only for a
    proprietary platform (Cocoa) in the Emacs 23.1 release?

    >   1. Code for stippling.  This is wrongly implemented as tiling, which
    >      has been controversial whether or not to be included in the other
    >      platforms, IIUC.

An incorrect implementation of stippling is somewhat of a bug,
but it might be better than no implementation of stippling.
Anyway, I don't see a reason to object that this is only on MacOS.

    >   2. Code for interpreting incompatible color formats: RGBrrggbb,
    >      ARGBaarrggbb, HSVhhssvv, AHSVaahhssvv, and CMYKccmmyykk.  Besides
    >      the format itself, support for the alpha-component in color is
    >      not found in the other platforms but not inherently NS-specific.

These are minor things, nothing to object to.

    >   3. Lisp primitive ns-set-alpha (nsfns.m), which sets the alpha
    >      component of the given color to the specified value.  As in the
    >      argument for the alpha-component above, this is not inherently
    >      NS-specific.

    >   4. Lisp function ns-set-background-alpha (ns-win.el), which sets
    >      alpha-component of frame background color.  It is different from
    >      the frame parameter `alpha' as Adrian explained.  Again, this is
    >      not inherently NS-specific.

These too are rather minor, nothing to object to.

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 25 Jul 2009 22:22:24 -0400, Richard Stallman <rms@gnu.org> said:

>     Richard, is it OK with you to keep the following features only
> for a proprietary platform (Cocoa) in the Emacs 23.1 release?

>> 1. Code for stippling.  This is wrongly implemented as tiling,
>> which has been controversial whether or not to be included in the
>> other platforms, IIUC.

> An incorrect implementation of stippling is somewhat of a bug, but
> it might be better than no implementation of stippling.  Anyway, I
> don't see a reason to object that this is only on MacOS.

>> 2. Code for interpreting incompatible color formats: RGBrrggbb,
>> ARGBaarrggbb, HSVhhssvv, AHSVaahhssvv, and CMYKccmmyykk.  Besides
>> the format itself, support for the alpha-component in color is not
>> found in the other platforms but not inherently NS-specific.

> These are minor things, nothing to object to.

They sound like a really important policy change: allowing a
proprietary platform to be the first one to have features that are not
specific to the platform.  Are you sure?

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

Re: Changes 2009-07-15/16 in branch?

[Miles Bader]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>> An incorrect implementation of stippling is somewhat of a bug, but
>> it might be better than no implementation of stippling.  Anyway, I
>> don't see a reason to object that this is only on MacOS.

Note that stippling has never really worked correctly even on X.

[I fixed some of the bugs on my tiling branch, as the issues are similar
to those of image backgrounds.]

-Miles

-- 
Hers, pron. His.

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 26 Jul 2009 12:31:03 +0900, Miles Bader <miles@gnu.org> said:

>>> An incorrect implementation of stippling is somewhat of a bug, but
>>> it might be better than no implementation of stippling.  Anyway, I
>>> don't see a reason to object that this is only on MacOS.

> Note that stippling has never really worked correctly even on X.

> [I fixed some of the bugs on my tiling branch, as the issues are
> similar to those of image backgrounds.]

Yes, that's one of the reasons I didn't try to implement stippling on
the Carbon port: I expected that inclusion of the tiling patch would
make the whole situation much nicer and also make it possible to port
both stippling and tiling in a cleaner way.

FWIW, the W32 port doesn't have implementation of stippling either.
Keeping a wrong implementation of stippling in the NS port doesn't
make any sense.

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

Re: Changes 2009-07-15/16 in branch?

[Richard Stallman]

    They sound like a really important policy change: allowing a
    proprietary platform to be the first one to have features that are not
    specific to the platform.  Are you sure?

I don't think that description applies to these things.
I would call them adaptations of existing features
to fit the platform.

Specifying colors with a slightly different format is not particularly
useful except for compatibility with MacOS.  If we ever find that
discourages someone from moving away from the Macintosh, we could make
Emacs accept those formats on other platforms -- it won'tbe hard --
but I doubt that will happen.

As for tiling instead of stippling, perhaps  I have misunderstood.  Do
you think some users will see that as a feature?

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 26 Jul 2009 22:44:38 -0400, Richard Stallman <rms@gnu.org> said:

>     They sound like a really important policy change: allowing a
>     proprietary platform to be the first one to have features that
>     are not specific to the platform.  Are you sure?

> I don't think that description applies to these things.  I would
> call them adaptations of existing features to fit the platform.

I don't think so.

> Specifying colors with a slightly different format is not
> particularly useful except for compatibility with MacOS.  If we ever
> find that discourages someone from moving away from the Macintosh,
> we could make Emacs accept those formats on other platforms -- it
> won'tbe hard -- but I doubt that will happen.

These NS-port-specific formats are not what's defined by Apple, IIUC.
They are arbitrarily defined by the author.

Different format is actually a problem of compatibility, but not so
important for the GNU policy.

What I'm concerning about with respect to the GNU policy is the
"alpha-component" (or maybe "alpha-channel" is more familiar) support,
which was added only for Cocoa.  Alpha-component/alpha-channel
controls translucency of colors by specifying how opaque it is.  This
feature is not specific to NS or Cocoa: X11 can do this with cairo
and/or some extensions, but it is not yet implemented for Emacs on
free platforms at all.

> As for tiling instead of stippling, perhaps I have misunderstood.
> Do you think some users will see that as a feature?

What Miles pointed out as "never really worked correctly" does not
mean X11 does tiling instead of stippling.  X11 actually does
stippling, but you will soon see some inconsistent result if you apply
pictorial stippling to large area and do some editing:

  (set-face-stipple 'default "eschernot")

On the other hand, tiling support for X11 has been controversial about
its inclusion, and it has not been added to the main line whereas
there has been an implementation by Miles Bader for a long time.  I
don't understand why the NS port can add the tiling support under the
name of "stippling".  (Of course, I believe that mistake happened
unintentionally.)

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

Re: Changes 2009-07-15/16 in branch?

[Richard Stallman]

    What I'm concerning about with respect to the GNU policy is the
    "alpha-component" (or maybe "alpha-channel" is more familiar) support,
    which was added only for Cocoa.  Alpha-component/alpha-channel
    controls translucency of colors by specifying how opaque it is.

Is this a feature users might actually want to use?
I don't see what it is good for.
Can someone explain what a user might want to do with this?

Re: Changes 2009-07-15/16 in branch?

[Clifford Wulfman]

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

> 
>     What I'm concerning about with respect to the GNU policy is the
>     "alpha-component" (or maybe "alpha-channel" is more familiar) support,
>     which was added only for Cocoa.  Alpha-component/alpha-channel
>     controls translucency of colors by specifying how opaque it is.
> 
> Is this a feature users might actually want to use?
> I don't see what it is good for.
> Can someone explain what a user might want to do with this?
> 
> 
I use this feature all the time on my laptop to enable me to see what's
underneath my editing window (a manual page, some data I'm transcribing, etc.)

Re: Changes 2009-07-15/16 in branch?

[Richard Stallman]

    I use this feature all the time on my laptop to enable me to see what's
    underneath my editing window (a manual page, some data I'm transcribing, etc.)

How do you use it?  Temporarily for a moment?
What command do you give, when you want to use it?

Is this feature unique to Emacs on MacOS, or do other apps have it too?

Re: Changes 2009-07-15/16 in branch?

[Clifford Wulfman]

On Jul 28, 2009, at 12:37 AM, Richard Stallman wrote:

>    I use this feature all the time on my laptop to enable me to see  
> what's
>    underneath my editing window (a manual page, some data I'm  
> transcribing, etc.)
>
> How do you use it?  Temporarily for a moment?
> What command do you give, when you want to use it?
>
> Is this feature unique to Emacs on MacOS, or do other apps have it  
> too?

I usually set it to .9 just for effect and leave it there; when I'm  
working on something that requires more transparency (e.g.,  
transcribing something, refactoring code, describing something that's  
displayed in another window, etc.) I'll increase it.  To set it, I use  
ns-set-background-alpha from the minibuffer.

I don't know many apps on the Mac that have this feature; the  
Terminal.app does, and I use it in a similar fashion.


Dr. Clifford E. Wulfman
Coordinator of Library Digital Initiatives
Princeton University Library
cwulfman@Princeton.EDU

Re: Changes 2009-07-15/16 in branch?

[Richard Stallman]

Thanks for the info.
Is it hard to implement background transparency on X?

However, Applescript is a potentially much more important issue.
I have not received an answer to my questions about Applescript,
so I cannot start to evaluate the issue.

Please don't make a release tomorrow, or until this issue gets
addressed.

Re: Changes 2009-07-15/16 in branch?

[Alfred M. Szmidt]

   However, Applescript is a potentially much more important issue.  I
   have not received an answer to my questions about Applescript, so I
   cannot start to evaluate the issue.

I did some digging, it seems to be a non-free scripting engine for OS
X that makes it possible for users to talk to other programs, and
create macros for automatic things.  I could not find any free version
of it for GNU, nor any support for it in GNUStep; only OSX uses it.

Re: Changes 2009-07-15/16 in branch?

[Ian Eure]

On Jul 28, 2009, at 11:39 AM, Alfred M. Szmidt wrote:

>   However, Applescript is a potentially much more important issue.  I
>   have not received an answer to my questions about Applescript, so I
>   cannot start to evaluate the issue.
>
> I did some digging, it seems to be a non-free scripting engine for OS
> X that makes it possible for users to talk to other programs, and
> create macros for automatic things.  I could not find any free version
> of it for GNU, nor any support for it in GNUStep; only OSX uses it.
>
More specifically, it's a combination of the Open Scripting  
Architecture and the AppleScript programming language. OSA is a  
mechanism which allows applications to expose functionality to other  
programs in order to automate tasks.

Access to this functionality is provided by way of OSA Scripting  
Components, which is a way to plug new programming languages into OSA.  
There are components available for free languages, such as Ruby,  
JavaScript, and Python.

AppleScript is a natural-language (i.e. English-like) programming  
language which is the default language to use with OSA scripting.

The AppleScript support in the Cocoa port allows one to execute  
AppleScripts from inside Emacs to control Mac OS or applications  
running on it.

  - Ian

Re: Changes 2009-07-15/16 in branch?

[Richard Stallman]

    More specifically, it's a combination of the Open Scripting  
    Architecture and the AppleScript programming language. OSA is a  
    mechanism which allows applications to expose functionality to other  
    programs in order to automate tasks.

    Access to this functionality is provided by way of OSA Scripting  
    Components, which is a way to plug new programming languages into OSA.  
    There are components available for free languages, such as Ruby,  
    JavaScript, and Python.

If it is normal for apps on MacOS to expose their functionality for
access thru OSA, I think it is proper for Emacs to follow.

Is this the functionality that some have said is comparable to Dbus?

    The AppleScript support in the Cocoa port allows one to execute  
    AppleScripts from inside Emacs to control Mac OS or applications  
    running on it.

Surely this is something that most apps don't have.  So we should
delete this from Emacs.

Re: Changes 2009-07-15/16 in branch?

[Ian Eure]

On Jul 31, 2009, at 8:21 PM, Richard Stallman wrote:

>    More specifically, it's a combination of the Open Scripting
>    Architecture and the AppleScript programming language. OSA is a
>    mechanism which allows applications to expose functionality to  
> other
>    programs in order to automate tasks.
>
>    Access to this functionality is provided by way of OSA Scripting
>    Components, which is a way to plug new programming languages into  
> OSA.
>    There are components available for free languages, such as Ruby,
>    JavaScript, and Python.
>
> If it is normal for apps on MacOS to expose their functionality for
> access thru OSA, I think it is proper for Emacs to follow.
>
It would be very nice, though I don't know what's involved to make it  
work. I'd prefer to see the existing problems with the NS port fixed.


> Is this the functionality that some have said is comparable to Dbus?
>
I'm not familiar with D-Bus, so I can't say.


>    The AppleScript support in the Cocoa port allows one to execute
>    AppleScripts from inside Emacs to control Mac OS or applications
>    running on it.
>
> Surely this is something that most apps don't have.  So we should
> delete this from Emacs.

>

Most apps don't do what Emacs does. The programs I'm aware of which  
have a similar capability (Script Editor and Xcode) are tools for  
developing and testing software, as Emacs is. So it's not inconsistent  
to maintain it.

I think it would be unfortunate if it were removed. As Emacs can be  
used to develop AppleScript (or other OSA supported languages) this  
feature would be needed to run them from within Emacs to test the  
code. Without it, you must rely on other tools outside of Emacs for  
this functionality.

  - Ian

Re: Changes 2009-07-15/16 in branch?

[Stephen J. Turnbull]

Ian Eure writes:

 > I think it would be unfortunate if it were removed. As Emacs can be
 > used to develop AppleScript (or other OSA supported languages) this
 > feature would be needed to run them from within Emacs to test the
 > code. Without it, you must rely on other tools outside of Emacs for
 > this functionality.

Yeah, but as Harald pointed out, you only have to go as far as
osascript (part of Mac OS, or maybe Xcode) and .emacs:

;; Copyright 2009 Stephen J. Turnbull
;; this code and inlined documentation is licensed to you under the
;; GNU GPL, v2 or later at your option
;; tested in XEmacs 21.5.29, YMMV (see the NO WARRANTY clause of the license)
(defun osascript (script &rest args)
  "Run string SCRIPT as an OSA script \(eg, Applescript), with arguments ARGS.
Each element of the list ARGS is added to the invocation of osascript(1)
formatted with \" %s\".
BUG: in interactive use, ARGS must be provided as a Lisp list."

  ;; A custom read-list could be provided to allow the following style
  ;; of interface.  Example script from osascript(1).
  ;; Prompts abbreviated, user input only:

  ;; M-x osascript RET
  ;; SCRIPT: on run argv C-q C-j
  ;;    return "hello, " & item 1 of argv & "." C-q C-j
  ;; end run C-q C-j RET
  ;; ARG: world RET
  ;; ARG: moon RET
  ;; ARG: RET

  ;; and the empty arg terminates the list and runs the command.

  (interactive "sEnter the text of the script (use C-q C-j for newlines): 
xScript arguments (as a Lisp list): ")

  ;; kludge to deal with `interactive's lack of awareness of &rest
  (when (interactive-p)
    (setq args (car args)))
  (shell-command (concat (format "osascript -e '%s'" script)
                         (mapconcat (lambda (x) (format " %s" x)) args ""))))

Re: Changes 2009-07-15/16 in branch?

[Richard Stallman]

    > If it is normal for apps on MacOS to expose their functionality for
    > access thru OSA, I think it is proper for Emacs to follow.
    >
    It would be very nice, though I don't know what's involved to make it  
    work. I'd prefer to see the existing problems with the NS port fixed.

We may be having a misunderstanding.  I thought that this is part
of what is already implemented, and what I'm saying is that there is no
need to delete it.

As for the Applescript feature, what you are saying is that you find
it useful.  I am sure it is, but the point is that that is not the
only criterion.

Re: Changes 2009-07-15/16 in branch?

[James Cloos]

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

Richard> Is it hard to implement background transparency on X?

Not too hard.  A number of terminal apps do it.

The X server needs to support the XCOMPOSITE extension, a compositing
manager must be running (akin to a window manager, but it is responsible
for blending the clients' windows together on top of the root window
based on how they are stacked and on their per-pixel alpha values) and
the client needs to use an x11 visual with an alpha channel.

Normally the last is a 32 bit 8/8/8/8 ARGB visual (8 bits each of Alpha,
Red, Green and Blue), but colour spaces like 2/10/10/10 ARGB are possible.

Anyone running the latest versions of the popular gnu-on-linux dists on
recent hardware is probably using a suitable setup for transparent windows.

To add transparent support to a client, you just need to use a suitable
visual and include the alpha bits in each colour.

I know that rxvt-unicode (http://software.schmorp.de/) gnome-terminal
and KDE's terminal all have transparency support and are all Freely
licensed.  Any of them should provide a more precise recipe for
supporting translucent windows on X11.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Changes 2009-07-15/16 in branch?

[Richard Stallman]

Thanks for the explanation.

We should remove the background transparency feature from 23.1
and implement it for multiple platforms in a future release.

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 29 Jul 2009 16:13:58 -0400, Richard Stallman <rms@gnu.org> said:

> Thanks for the explanation.  We should remove the background
> transparency feature from 23.1 and implement it for multiple
> platforms in a future release.

To explain the current status of the EMACS_23_1_RC branch, some
convenience Lisp functions for background transparency are removed.
But the essential part for alpha-component support that implements
background transparency in the NS port was once removed by me but then
reverted by Yidong, and that feature is still accessible from the user
using some incompatible color format like:

  (set-face-background 'default "ARGBccffffff")

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

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 29 Jul 2009 16:13:58 -0400, Richard Stallman <rms@gnu.org> said:

> We should remove the background transparency feature from 23.1 and
> implement it for multiple platforms in a future release.

Maintainers, shouldn't you explain why you released Emacs 23.1 without
removing the Cocoa-only background transparent feature?

I've explained reasons why it should be removed in so many aspects.
But I've never heard of logical reasons from you.

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

Re: Changes 2009-07-15/16 in branch?

[Chong Yidong]

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

> Maintainers, shouldn't you explain why you released Emacs 23.1 without
> removing the Cocoa-only background transparent feature?
>
> I've explained reasons why it should be removed in so many aspects.
> But I've never heard of logical reasons from you.

As I've explained before, it was too late to make drastic internals
changes.  I agreed to the removal of the user commands for setting the
alpha channel---a "removal", I might add, that actually consisted of not
reverting your unannounced, unagreed-upon changes to a release branch in
heavy freeze---but your other changes to the ns*.m internals were too
risky for the marginal "benefit" provided (that "benefit" being to make
it slightly harder for users to set the alpha in an incompatible way).
Now, I'm confident that someone of your intelligence will be able to
find some persnickety arguments against this decision.  But I've little
inclination to engage in more such debate, so you'll unfortunately have
to live with it.

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 30 Jul 2009 10:01:08 -0400, Chong Yidong <cyd@stupidchicken.com> said:

> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>> Maintainers, shouldn't you explain why you released Emacs 23.1
>> without removing the Cocoa-only background transparent feature?
>> 
>> I've explained reasons why it should be removed in so many aspects.
>> But I've never heard of logical reasons from you.

> As I've explained before, it was too late to make drastic internals
> changes.  I agreed to the removal of the user commands for setting
> the alpha channel---a "removal", I might add, that actually
> consisted of not reverting your unannounced, unagreed-upon changes
> to a release branch in heavy freeze---but your other changes to the
> ns*.m internals were too risky for the marginal "benefit" provided
> (that "benefit" being to make it slightly harder for users to set
> the alpha in an incompatible way).

What do you mean by "slightly harder"?  Does it mean the users can
specify alpha-component and use background transparent feature in some
harder way even if you don't revert the part of my change?  It was
intended for users to make it completely impossible to specify
alpha-component.

Also, the above reason ("too late") does not explain why you reverted
the change also in the trunk.  If you are against some of the reasons
I've given, please explain.

> Now, I'm confident that someone of your intelligence will be able to
> find some persnickety arguments against this decision.  But I've
> little inclination to engage in more such debate, so you'll
> unfortunately have to live with it.

I don't think the argument on the GNU policy infringement
"persnickety".  Moreover, this should have been addressed before the
release whether or not I've made some change about it.

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

Re: Changes 2009-07-15/16 in branch?

[David De La Harpe Golden]

Richard Stallman wrote:
>     What I'm concerning about with respect to the GNU policy is the
>     "alpha-component" (or maybe "alpha-channel" is more familiar) support,
>     which was added only for Cocoa.  Alpha-component/alpha-channel
>     controls translucency of colors by specifying how opaque it is.
> 
> Is this a feature users might actually want to use?
> I don't see what it is good for.
> Can someone explain what a user might want to do with this?
> 
> 
> 

Well, my understanding (possibly outdated) is the NS port only uses its 
alpha value in very limited fashion.  It just lets you sort of see 
what's underneath the emacs window.

It's AFAIK not doing the in-emacs alpha-blending I proposed (without 
working implementation...)  a while back to allow translucent overlays - 
e.g. a translucent region letting highlighted text "underneath" show 
through /with highlighting still visible/.  That would be much more useful.

But if I was doing that in-emacs alphablending (not saying I will 
successfully, just if...), I personally would not use the peculiar NS 
chosen syntax for colors with alpha values. I'd probably prefer to have 
separate float face properties, foreground-alpha and background-alpha, 
to allow me to continue to use named X11 colors
i.e. background: "midnightblue" background-alpha: 0.5

(yes, I suppose it would be possible to support both external
and in-color-name alphas, messily.  But if I was doing that, I'm still
not keen on the NS chosen syntax. Note how css and x11 both nowadays
user separated values e.g. rgb(r, g, b) or rgb:r/g/b )

OTOH, color names are currently parsed in a platform dependent manner 
anyway - i.e. you can't expect a color specification that works on X11 
to work on w32. X11 emacs actually does a call out to XParseColor() on 
X11, which means emacs might get end-user defined named colors for all 
it knows*, so I'm not sure there's any particular harm in letting the NS 
port have its own interpretation of the color name strings.

* e.g. Place following in ~/.xcms.txt

XCMS_COLORDB_START 0.1
Blobby    rgb:7fe2/ffe1/331a
XCMS_COLORDB_END

(note that the syntax demands a _tab_ between color name
and rgb: spec)

then do
export XCMSDB=~/.xcms.txt

Now run x11 emacs, and note how  if you enter Blobby (or indeed some
rgb:r/g/b value) in emacs for a color, x11 emacs recognises it.

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 27 Jul 2009 21:14:06 +0100, David De La Harpe Golden <david@harpegolden.net> said:

> But if I was doing that in-emacs alphablending (not saying I will
> successfully, just if...), I personally would not use the peculiar
> NS chosen syntax for colors with alpha values. I'd probably prefer
> to have separate float face properties, foreground-alpha and
> background-alpha, to allow me to continue to use named X11 colors
> i.e. background: "midnightblue" background-alpha: 0.5

> (yes, I suppose it would be possible to support both external and
> in-color-name alphas, messily.  But if I was doing that, I'm still
> not keen on the NS chosen syntax. Note how css and x11 both nowadays
> user separated values e.g. rgb(r, g, b) or rgb:r/g/b )

IIUC, neither Carbon nor Cocoa defines the standard textual
representation formats of colors.  So I think Emacs on such platforms
should adopt some other standards (e.g., X11 or maybe CSS) like in the
W32 or Carbon port rather than inventing new own formats as in the NS
port.  Own formats does not enhance interchangeability in any ways.

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

Re: Changes 2009-07-15/16 in branch?

[David De La Harpe Golden]

Adrian Robert wrote:

> This sort of thing [in-emacs alphablending] would likely layer 
 > over alpha support at the lower level such as that provided by the NS 
port.

Not necessarily at all, all realised colors could be without alpha,
the idea was raised in the context of 256-color terminal users in fact
where alpha computations would be internal to emacs.
(otoh might as well pass it through if it's also there at the OS level, 
  but that would just be a "final alpha" as an output of the blending 
process).

> Does emacs support rgb(r, g, b) or rgb:r/g/b already?
> 

The latter on X11, but N.B. it's really X11 itself supporting it, not 
emacs - i.e. emacs directly asks X11 for colors via the libX11 
XParseColor() API [1] (internally emulated on most other platforms and
text terminals IIRC)

X11 supports  a range of device-dependent and (rather obscure for most 
people) device-independent color specification strings, as well as 
previously mentioned well-known and user-defined names for those colors. 
(None include alpha since alpha isn't historically part of the X color)

Given your interest is alpha and hsv (hsl is neater...), maybe imitating 
the CSS2/3 syntax which includes alpha might be better - and is more 
likely to avoid clashing if X.org extend XParseColor() one fine day. 
CSS syntax could also serve to indicate an sRGB colorspace 
interpretation of rgb triples.
rgb()
rgba()
hsl()
hsla()


[1]
http://linux.die.net/man/3/xparsecolor
e.g.
rgb:<red>/<green>/<blue>
rgbi:<red>/<green>/<blue>
CIEXYZ:<X>/<Y>/<Z>
CIEuvY:<u>/<v>/<Y>
CIExyY:<x>/<y>/<Y>
CIELab:<L>/<a>/<b>
CIELuv:<L>/<u>/<v>
TekHVC:<H>/<V>/<C>

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 27 Jul 2009 13:41:04 -0400, Richard Stallman <rms@gnu.org> said:

>     What I'm concerning about with respect to the GNU policy is the
>     "alpha-component" (or maybe "alpha-channel" is more familiar)
>     support, which was added only for Cocoa.
>     Alpha-component/alpha-channel controls translucency of colors by
>     specifying how opaque it is.

> Is this a feature users might actually want to use?  I don't see
> what it is good for.  Can someone explain what a user might want to
> do with this?

Emacs 23 already has a frame opacity control feature whose
design/implementation is different from what I mentioned above.  I
guess this was added because they considered that some users would
want this kind of feature:

Quote etc/NEWS:

  *** Emacs can now set the frame opacity.
  The opacity of a frame can be controlled by setting the `alpha' frame
  parameter.  This only takes effect on a compositing window manager for
  the X Window System, such as Compiz, Beryl and Compiz Fusion, on Mac
  OS X, or on Windows 2000 and later versions of Windows.

  The alpha parameter should be an integer between 0 (transparent) and
  100 (opaque), or a float number between 0.0 and 1.0.  It can also be a
  cons cell (ACTIVE . INACTIVE), where ACTIVE is the opacity of an
  active frame and INACTIVE is the opacity of non-active frames.

  The variable `frame-alpha-lower-limit' defines a lower bound for the
  opacity; the default is 20.

Some find its effect unsatisfactory because it makes both foreground
and background colors translucent.  Adrian says the alpha-component
support in the NS port is superior and actually the latter can make
background translucent while keeping foreground opaque.

Actually the implementation of alpha-component support in the NS port
has some annoying glitch as I pointed out in
http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg01340.html .
I think it's ridiculous to add such a feature to the release version

  * without broader discussion about the specification for such a
    general (i.e., non platform-specific) feature.
  * with a premature implementation only for a non-free platform.
  * with a risk of compatibility breakage in future.
  * with a risk of infringing the GNU policy.

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

Re: Changes 2009-07-15/16 in branch?

[Richard Stallman]

    Some find its effect unsatisfactory because it makes both foreground
    and background colors translucent.  Adrian says the alpha-component
    support in the NS port is superior and actually the latter can make
    background translucent while keeping foreground opaque.

Is there a difficulty in implementing backhground-only transparency on
the other platforms?

Re: Changes 2009-07-15/16 in branch?

[Stefan Monnier]

>>> So, what's your idea to prevent 23.1 users from unintended use of
>>> the features that are incompatible with the other platforms and to
>>> be removed in 23.2?
>> I don't think it's a problem that necessarily needs to be solved.
> I don't agree in this respect.

I know.


        Stefan

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 23 Jul 2009 21:09:20 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

> I know, but I think such changes so late in the pretest aren't a
> good idea.  Only critical bugs deserve to be fixed now.

I think infringement of GNU policy (in particular, about adding a
general feature to a non-free platform first) is so critical for Emacs
that it should be considered a critical bug that deserves to be fixed
now.

What do maintainers think?

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

Re: Changes 2009-07-15/16 in branch?

[Chong Yidong]

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

> I think infringement of GNU policy (in particular, about adding a
> general feature to a non-free platform first) is so critical for Emacs
> that it should be considered a critical bug that deserves to be fixed
> now.
>
> What do maintainers think?

I think this issue isn't worth the time that's been spent on it.

I've reverted some of your changes on the branch.  Your removal of
ns-set-alpha and ns-set-background-alpha is fine.  However, I restored
the code that supports alpha channel internally.  I think this is an
acceptable compromise, so let's stop arguing about this now.

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 28 Jul 2009 21:12:12 -0400, Chong Yidong <cyd@stupidchicken.com> said:

>> I think infringement of GNU policy (in particular, about adding a
>> general feature to a non-free platform first) is so critical for
>> Emacs that it should be considered a critical bug that deserves to
>> be fixed now.
>> 
>> What do maintainers think?

> I think this issue isn't worth the time that's been spent on it.

I agree in that point.  It's apparent that tiling and alpha-component
support in the NS port are infringing the GNU policy unless these
features will never be added to free platforms.

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

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 29 Jul 2009 10:18:30 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> It's apparent that tiling and alpha-component support in the NS port
> are infringing the GNU policy unless these features will never be
> added to free platforms.

And combination of these features introduces another bug in the NS
port.

 (set-face-background 'default "ARGBfeffffff") ;; almost opaque white color
 (set-face-stipple 'default "splash.png") ;; actually not stippling but tiling

Then the background of the tiling image suddenly becomes completely
transparent.

Again, keeping these features in the release version only produces
variety kinds of problems.

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

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 28 Jul 2009 21:12:12 -0400, Chong Yidong <cyd@stupidchicken.com> said:

> I've reverted some of your changes on the branch.  Your removal of
> ns-set-alpha and ns-set-background-alpha is fine.  However, I
> restored the code that supports alpha channel internally.  I think
> this is an acceptable compromise, so let's stop arguing about this
> now.

In case I misunderstand "internally", the alpha-component support is
still accessible from the user:

  (set-face-background 'default "ARGBaaffffff")

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

Re: Changes 2009-07-15/16 in branch?

[Adrian Robert]

On Jul 23, 2009, at 8:46 AM, YAMAMOTO Mitsuharu wrote:

>  It's essential to make these changes in the release branch so users
>  may not use the incompatible formats by accident and introduce
>  compatibility problems when they are removed in some future version.
>  Upcoming version is the first one for the NS port.  Effectiveness is
>  much lowered if such changes are deferred to the later versions.
>
>  I've warned about such incompatibility issues that I think
>  indispensable for the first official release version, but the author
>  has not tried to address them (not just for this one!).

There are others working on the port, but speaking for myself, my time  
has been limited and I've prioritized fixing bugs (as I've mentioned  
before).  I've advocated for and assisted others with  
standardization / cleanup efforts.



>  Even if by any chance there's overlooked code as you say, it's only
>  in the NS-specific part and relatively minor compared with total
>  unstableness of the port itself.  Removing incompatible features at
>  this timing is much more important unless the port is marked
>  experimental/hackers-only.

Then let's mark it such, as there are many more features of this sort  
that should be removed by your criteria (some of which were  
unfortunately adopted by the Carbon port following Emacs.app in the  
Sourceforge days, but were never subjected to the same scrutiny):

- modifier key customization (standard methods exist)
- services integration (no counterpart on other platforms)
- applescript integration (use DBUS instead)
- font panel (unneeded, incompatible)
- nonstandard antialiasing controls (standard methods exist)
- nonstandard way of hiding/showing toolbar (unneeded, incompatible)
- open/save panels (unneeded, incompatible)
- about panel (unneeded)

All of these things belong in distributions, or in add-on packages  
such as:

http://www.emacswiki.org/emacs/NSPlatformSupport



>> ns_color_to_lisp(): The function could be simplified now that you
>> have eliminated a special case.
>
> I know the changes are not optimal.  But I wanted to keep them quite
> straightforward so as to avoid regression.

OK, then at least a cleaned-up version could have gone into the trunk.



>> nsfont_draw(): Would setting the foreground instead of the
>> background color to the bitmap constitute a corrected
>> implementation?
>
> I don't know if I understand your intention correctly from the above
> sentence.  But if you believe you understand stippling correctly this
> time, maybe you can make the change into the trunk.

I gathered that you understood it better than I so I was wondering if  
there was some reason to just remove code when fixing it would have  
been as easy.



>> ns-set-background-alpha: The implementation you just removed was
>> superior to that for (set-frame-parameter nil 'alpha ##): it does
>> not alter the alpha of the titlebar, scrollbars, modeline, or text.
>> This makes it usable, instead of a curiosity.  It also provides
>> access via an interactive function.  The correct fix would be to
>> improve the (set- frame-parameter) version, not remove this while no
>> alternative exists for users.
>
> I knew their difference.  I removed it because it belongs to "NS-only
> implementation for features that are not inherently specific to NS."
> (http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00594.html)

"Inherently specific" is an ambiguous call, and I don't think it's a  
reasonable litmus test.  But if the Cocoa APIs provide alpha  
capabilities beyond what is available on X11 and W32, it is inherent  
in some sense.  The right thing would be to fix the frame-parameter  
implementation (at least on NS), but failing that the other option  
should be left in for users.



> I think it's really bad for the "first-class" port to have such
> features because they may be superseded in a platform-independent way
> by some future versions and that introduces unnecessary
> incompatibilities.

It seems there are several problems listed in the email you cite that  
either do not impact or actually hurt users; why not work on these (on  
the trunk), or on fixing bugs?

As far as the superseded / platform independent argument, as I've said  
before, many features first appeared on X11 or GTK without  
counterparts on other platforms.  This continues to happen now.  It's  
a double-standard to police the NS port so stringently without  
considering implementing the counterparts.

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 24 Jul 2009 10:34:55 -0400, Adrian Robert <adrian.b.robert@gmail.com> said:

> On Jul 23, 2009, at 8:46 AM, YAMAMOTO Mitsuharu wrote:

>> It's essential to make these changes in the release branch so users
>> may not use the incompatible formats by accident and introduce
>> compatibility problems when they are removed in some future version.
>> Upcoming version is the first one for the NS port.  Effectiveness is
>> much lowered if such changes are deferred to the later versions.
>> 
>> I've warned about such incompatibility issues that I think
>> indispensable for the first official release version, but the author
>> has not tried to address them (not just for this one!).

> There are others working on the port, but speaking for myself, my time  
> has been limited and I've prioritized fixing bugs (as I've mentioned  
> before).  I've advocated for and assisted others with  
> standardization / cleanup efforts.

They would hesitate to remove the code even if it breaks compatibility
unless you explicitly ask it.

>> Even if by any chance there's overlooked code as you say, it's only
>> in the NS-specific part and relatively minor compared with total
>> unstableness of the port itself.  Removing incompatible features at
>> this timing is much more important unless the port is marked
>> experimental/hackers-only.

> Then let's mark it such, as there are many more features of this sort  
> that should be removed by your criteria (some of which were  
> unfortunately adopted by the Carbon port following Emacs.app in the  
> Sourceforge days, but were never subjected to the same scrutiny):

> - modifier key customization (standard methods exist)
> - services integration (no counterpart on other platforms)
> - applescript integration (use DBUS instead)
> - font panel (unneeded, incompatible)
> - nonstandard antialiasing controls (standard methods exist)
> - nonstandard way of hiding/showing toolbar (unneeded, incompatible)
> - open/save panels (unneeded, incompatible)
> - about panel (unneeded)

Whether or not to mark experimental/hackers-only is up to the
maintainers, and I actually asked them about the status of the port
before removing the code.

http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00594.html
http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00630.html

And actually I considered whether I can remove some of the
incompatible features you listed above, say open/save panel.  But it
is too drastic to do so without some replacement code.  Addition of
such code is "too late" and regression-prone, so I restricted myself
to the features that just removal is sufficient.

>>> nsfont_draw(): Would setting the foreground instead of the
>>> background color to the bitmap constitute a corrected
>>> implementation?
>> 
>> I don't know if I understand your intention correctly from the above
>> sentence.  But if you believe you understand stippling correctly this
>> time, maybe you can make the change into the trunk.

> I gathered that you understood it better than I so I was wondering if  
> there was some reason to just remove code when fixing it would have  
> been as easy.

As I said above, I avoided adding replacement code.

>>> ns-set-background-alpha: The implementation you just removed was
>>> superior to that for (set-frame-parameter nil 'alpha ##): it does
>>> not alter the alpha of the titlebar, scrollbars, modeline, or text.
>>> This makes it usable, instead of a curiosity.  It also provides
>>> access via an interactive function.  The correct fix would be to
>>> improve the (set- frame-parameter) version, not remove this while no
>>> alternative exists for users.
>> 
>> I knew their difference.  I removed it because it belongs to "NS-only
>> implementation for features that are not inherently specific to NS."
>> (http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00594.html)

> "Inherently specific" is an ambiguous call, and I don't think it's a  
> reasonable litmus test.  But if the Cocoa APIs provide alpha  
> capabilities beyond what is available on X11 and W32, it is inherent  
> in some sense.  The right thing would be to fix the frame-parameter  
> implementation (at least on NS), but failing that the other option  
> should be left in for users.

I think fundamental features such as alpha-component needs some
consensus among platforms about its specification.  Of course,
platform-specific proof-of-concept code is sometimes useful to call
for discussion, but it doesn't fit with the official release version
as it is.

>> I think it's really bad for the "first-class" port to have such
>> features because they may be superseded in a platform-independent way
>> by some future versions and that introduces unnecessary
>> incompatibilities.

> It seems there are several problems listed in the email you cite that  
> either do not impact or actually hurt users; why not work on these (on  
> the trunk), or on fixing bugs?

As I already said, I suspect the port has fundamental design flaw (not
100% sure, so you can possibly refute it).  And design and policy are
too different from mine.

What I would do with Cocoa can be found in my Carbon+AppKit port.

> As far as the superseded / platform independent argument, as I've said  
> before, many features first appeared on X11 or GTK without  
> counterparts on other platforms.  This continues to happen now.  It's  
> a double-standard to police the NS port so stringently without  
> considering implementing the counterparts.

I thought RMS is strongly against adding features to proprietary
platforms first.  Of course, it is not applied to inherently
platform-specific features (such as Apple Event handling).  Maybe if
you make the GNUstep port much more stable and usable enough as
"first-class" port, then you can add some features first to the
platform, but I'm not sure.

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

Re: Changes 2009-07-15/16 in branch?

[Richard Stallman]

    unfortunately adopted by the Carbon port following Emacs.app in the  
    Sourceforge days, but were never subjected to the same scrutiny):

Most of the things in that list seem harmless adaptations to the Mac
environment, but these two make me worry.

    - services integration (no counterpart on other platforms)
    - applescript integration (use DBUS instead)

Can you explain what they do?

Re: Changes 2009-07-15/16 in branch?

[Adrian Robert]

On Jul 25, 2009, at 12:55 AM, Richard Stallman wrote:

>    unfortunately adopted by the Carbon port following Emacs.app in the
>    Sourceforge days, but were never subjected to the same scrutiny):
>
> Most of the things in that list seem harmless adaptations to the Mac
> environment, but these two make me worry.
>
>    - services integration (no counterpart on other platforms)
>    - applescript integration (use DBUS instead)

They are two protocols for interapp communication.  The first one,  
services, exists on MacOS and GNUstep and was added originally by the  
Cocoa port as a consumer-only implementation.  The second exists only  
on MacOS and was added by the Carbon port.

After the merge, to support users migrating from Carbon, provider  
functionality was added to the Cocoa services implementation, and some  
Applescript functionality.  I'd recommend backing these out in 23.2,  
as they go beyond the minimum platform compliance requires (services  
provider), and/or support a proprietary-only feature (Applescript).

Re: Changes 2009-07-15/16 in branch?

[Richard Stallman]

    >    - services integration (no counterpart on other platforms)
    >    - applescript integration (use DBUS instead)

    They are two protocols for interapp communication.  The first one,  
    services, exists on MacOS and GNUstep and was added originally by the  
    Cocoa port as a consumer-only implementation.  The second exists only  
    on MacOS and was added by the Carbon port.

In that case, the first one sound justified because of the GNUstep
support for it.  But the second might be bad.  I need to know
more about it.

What is Applescript?  What does it do?  Can you show me an example
of what people do with it?  How does it relate to Emacs?  Does it mean
people can extend Emacs with Applescript programs?  Or can they
only run Emacs from it, like from a shell script?

    After the merge, to support users migrating from Carbon, provider  
    functionality was added to the Cocoa services implementation,

Does this mean that the "services integration" includes some features
that work on GNUstep and some that do not?

Re: Changes 2009-07-15/16 in branch?

[Adrian Robert]

On Jul 26, 2009, at 10:43 PM, Richard Stallman wrote:

> What is Applescript?  What does it do?  Can you show me an example
> of what people do with it?  How does it relate to Emacs?  Does it mean
> people can extend Emacs with Applescript programs?  Or can they
> only run Emacs from it, like from a shell script?

I'm not sure about this, and wasn't involved in the implementation in  
either port.  Maybe one of those who were can say something.



>    After the merge, to support users migrating from Carbon, provider
>    functionality was added to the Cocoa services implementation,
>
> Does this mean that the "services integration" includes some features
> that work on GNUstep and some that do not?

No.  But a consumer implementation is something that all apps on both  
MacOS and GNUstep have; to leave it out of Emacs would be a glaring  
deficit to users.  A provider implementation, where Emacs exports menu  
entries for interapplication services to other apps, is nice, but is  
only done by a minority of apps on either platform, so it goes beyond  
what is needed for Emacs to be a first-class desktop citizen and might  
as well be left for distributions.

Re: Changes 2009-07-15/16 in branch?

[Harald Hanche-Olsen]

+ Richard Stallman <rms@gnu.org>:

> We need to delete the "provider implementation" from Emacs 23.1.

Agreed, I think ... One of those menu items is Services -> Emacs.app
-> Send Email to Selected Address, which works. On the other hand,
what does NOT work, but really SHOULD (this falls into the "glaring
deficiency" category), is to let emacs handle a mailto: URL.

On the mac, one can declare that application A should handle URL
scheme U. By default, mailto: URLs are handled by Mail.app, so that
clicking on a mailto: link on a web page causes Mail.app to open a
new draft message addressed to the given address. If I change this to
let emacs handle it, clicking on a mailto: link does activate emacs,
but nothing more happens.

This is a "glaring deficiency" because, after all, clicking on mailto:
links on web pages is quite common, and if emacs cannot handle this,
we discourage users from using emacs for their mail.

Should I file a bug report requesting this feature?

- Harald

Re: Changes 2009-07-15/16 in branch?

[Stefan Monnier]

> This is a "glaring deficiency" because, after all, clicking on mailto:
> links on web pages is quite common, and if emacs cannot handle this,
> we discourage users from using emacs for their mail.

> Should I file a bug report requesting this feature?

I think so, yes, please,
thank you,


        Stefan

Re: Changes 2009-07-15/16 in branch?

[David Kastrup]

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

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:

> + Richard Stallman <rms@gnu.org>:
>
>> We need to delete the "provider implementation" from Emacs 23.1.
>
> Agreed, I think ... One of those menu items is Services -> Emacs.app
> -> Send Email to Selected Address, which works. On the other hand,
> what does NOT work, but really SHOULD (this falls into the "glaring
> deficiency" category), is to let emacs handle a mailto: URL.
>
> On the mac, one can declare that application A should handle URL
> scheme U. By default, mailto: URLs are handled by Mail.app, so that
> clicking on a mailto: link on a web page causes Mail.app to open a
> new draft message addressed to the given address. If I change this to
> let emacs handle it, clicking on a mailto: link does activate emacs,
> but nothing more happens.
>
> This is a "glaring deficiency" because, after all, clicking on mailto:
> links on web pages is quite common, and if emacs cannot handle this,
> we discourage users from using emacs for their mail.
>
> Should I file a bug report requesting this feature?

What I use is a helper script that looks like


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: emacs-url --]
[-- Type: text/x-sh, Size: 72 bytes --]

#!/bin/sh
/usr/local/bin/emacsclient -a "" --eval "(browse-url \"$1\")"

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


It should really be, for quoting reasons,

/usr/local/bin/emacsclient -a "" --eval "(browse-url (pop argv))" "$1"

but emacsclient's option handling is not similar enough to that of emacs
yet to have this work.

-- 
David Kastrup

Re: Changes 2009-07-15/16 in branch?

[Harald Hanche-Olsen]

+ David Kastrup <dak@gnu.org>:

> Harald Hanche-Olsen <hanche@math.ntnu.no> writes:
> 
> > On the mac, one can declare that application A should handle URL
> > scheme U. By default, mailto: URLs are handled by Mail.app, so that
> > clicking on a mailto: link on a web page causes Mail.app to open a
> > new draft message addressed to the given address. If I change this to
> > let emacs handle it, clicking on a mailto: link does activate emacs,
> > but nothing more happens.
> >
> > This is a "glaring deficiency" because, after all, clicking on mailto:
> > links on web pages is quite common, and if emacs cannot handle this,
> > we discourage users from using emacs for their mail.
> >
> > Should I file a bug report requesting this feature?
> 
> What I use is a helper script that looks like [...]

Are you a Mac user? Your email header seems to indicate that you are
primarily a gnu/linux user. On the Mac, there is no way that I can see
to talk Firefox into running a script or arbitrary program to handle a
mailto: URL. On the contrary, the mechanism in place involves
activating a fullblown Mac application, then sending it an Apple event
indicating the desired action. I suspect, though I haven't checked,
that the same is true of Opera, Camino, and Safari. This is the way
applications communicate on Mac OS X. I don't see that any shell
script is gonna work around this.

There *is* one possible workaround that I haven't checked, though:
Make a small, simple application that knows just enough to act as an
application, receive the Apple event, and run emacsclient. Most users
are going to find this awkward and unnatural.

The biggest problem is to find out what needs to be done. I dug around
a bit in nsterm.m and ns-win.el to try to figure out how the nextstep
event loop works, but not knowing how to read Objective C turns out to
be too big an obstacle. I think we need a real expert to look at it.
Maybe Adrian Robert is the only one who can do it? I don't know if he
left it out because he didn't think of it, or because he couldn't
figure it out either.

- Harald

Re: Changes 2009-07-15/16 in branch?

[Harald Hanche-Olsen]

+ Richard Stallman <rms@gnu.org>:

> What is Applescript?  What does it do?

It provides a way for programs to control applications without the
need for GUI interaction. (IMO, an absolute necessity in a
GUI-dominated world.)

>  Can you show me an example of what people do with it?

Here is a banal example:

(ns-do-applescript
 "tell application \"TextEdit\" to open \"/Users/hanche/Desktop/Info.rtf\"")

This opens an existing RTF file in TextEdit and returns t if
successful. More specialized control is possible if the application in
question provides a dictionary of applescript commands pertaining to
that program.

I am not sure how this functionality can be replaced by DBUS, unless
someone comes up with a program that will accept applescript requests
via DBUS and run them. I can't comment on the feasibility of writing
such a program.

> How does it relate to Emacs?  Does it mean people can extend Emacs
> with Applescript programs?  Or can they only run Emacs from it, like
> from a shell script?

As far as I can tell, emacs does not provide an applescript
dictionary, so only rudimentary control is available. For instance,
you can run

  osascript -e 'tell application "emacs" to open "/etc/passwd"'

from the command line and it does what you might expect. But extending
emacs with applescript? I don't think so.

Does this answer your question?

- Harald

Re: Changes 2009-07-15/16 in branch?

[Stephen J. Turnbull]

Harald Hanche-Olsen writes:

 > I am not sure how this functionality can be replaced by DBUS,

The point is not that AppleScript functionality can be replaced by
dbus on Mac OS X, it is that dbus provides roughly analogous
functionality on free platforms.

Re: Changes 2009-07-15/16 in branch?

[Lennart Borgman]

On Wed, Jul 29, 2009 at 4:34 AM, Stephen J. Turnbull<stephen@xemacs.org> wrote:
> Harald Hanche-Olsen writes:
>
>  > I am not sure how this functionality can be replaced by DBUS,
>
> The point is not that AppleScript functionality can be replaced by
> dbus on Mac OS X, it is that dbus provides roughly analogous
> functionality on free platforms.

Does this mean that dbus does not work on Mac OS X? Why?

Re: Changes 2009-07-15/16 in branch?

[Harald Hanche-Olsen]

+ Lennart Borgman <lennart.borgman@gmail.com>:

> On Wed, Jul 29, 2009 at 4:34 AM, Stephen J. Turnbull<stephen@xemacs.org> wrote:
> > Harald Hanche-Olsen writes:
> >
> >  > I am not sure how this functionality can be replaced by DBUS,
> >
> > The point is not that AppleScript functionality can be replaced by
> > dbus on Mac OS X, it is that dbus provides roughly analogous
> > functionality on free platforms.
> 
> Does this mean that dbus does not work on Mac OS X? Why?

Not at all. Installing dbus is as easy as typing "port install dbus"
for those who run macports.

- Harald

Re: Changes 2009-07-15/16 in branch?

[Stephen J. Turnbull]

Lennart Borgman writes:
 > On Wed, Jul 29, 2009 at 4:34 AM, Stephen J. Turnbull<stephen@xemacs.org> wrote:
 > > Harald Hanche-Olsen writes:
 > >
 > >  > I am not sure how this functionality can be replaced by DBUS,
 > >
 > > The point is not that AppleScript functionality can be replaced by
 > > dbus on Mac OS X, it is that dbus provides roughly analogous
 > > functionality on free platforms.
 > 
 > Does this mean that dbus does not work on Mac OS X? Why?

No and yes.  As Harald points out, installing dbus on Mac OS X is not
particularly difficult.

However, using dbus on Mac OS is like speaking English in Tokyo.  Your
conversation partners are very limited, mostly to foreigners.

Re: Changes 2009-07-15/16 in branch?

[Richard Stallman]

    The point is not that AppleScript functionality can be replaced by
    dbus on Mac OS X, it is that dbus provides roughly analogous
    functionality on free platforms.

"Roughly analogous" is means you see some similarity in what can be
done with them.  I will take your word for that, but it isn't enough
to judge the answer to whether it is objectionable.  I need more
information.

One question is, do most apps on MacOS have _the same_ Applescript
capability that has been put into Emacs?

Re: Changes 2009-07-15/16 in branch?

[Chad Brown]

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

On Jul 29, 2009, at 1:14 PM, Richard Stallman wrote:
> One question is, do most apps on MacOS have _the same_ Applescript
> capability that has been put into Emacs?

Having only the level of capability that has been put into Emacs is  
considered a disadvantage in most applications.  The disadvantage is  
typically (in my experience) considered medium-to-light in general  
applications, and medium-to-serious in fundamental applications like  
general-purpose editors and/or user environments.

*Chad

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

Re: Changes 2009-07-15/16 in branch?

[Richard Stallman]

    > One question is, do most apps on MacOS have _the same_ Applescript
    > capability that has been put into Emacs?

    Having only the level of capability that has been put into Emacs is  
    considered a disadvantage in most applications.

Could you name and describe the different levels of capability
that apps can have, and say which one of them corresponds to Emacs?

Re: Changes 2009-07-15/16 in branch?

[Harald Hanche-Olsen]

+ Richard Stallman <rms@gnu.org>:

>     > One question is, do most apps on MacOS have _the same_ Applescript
>     > capability that has been put into Emacs?
> 
>     Having only the level of capability that has been put into Emacs is  
>     considered a disadvantage in most applications.
> 
> Could you name and describe the different levels of capability
> that apps can have, and say which one of them corresponds to Emacs?

I think every app that uses the cocoa framework, as Emacs does, can
respond to some basic applescript commands, such as activate, quit,
open file. This comes with the framework and is there whether we want
it or not. (I am not 100% sure on this.)

In addition, apps can (but Emacs does not) provide more Applescript
commands that other apps can use to control it. These extensions can
vary from a few simple commands to large collections of commands and
data structures that let you control almost every aspect of the app.

When it comes to being able to control other apps via Applescript, I
don't think many apps can do it. Such scripts are generally run using
the script editor, an app that lets you edit and execute scripts as
well as compile them into standalone scripts. Plus there is the
command line driven osascript, to which you can feed any bit of
applescript and have it executed. Example:

; osascript -e 'tell application "Emacs" to open "/etc/passwd"'


Now apart from Applescript and services (covered in a separate
message), applications may respond to other kinds of events. One that
Emacs does well is "open file"; the script above actually triggers
such an event. Another one is a request to handle an URL such as
mailto:nobody@example.com, which Emacs does not handle at present.
(But I think it should, if someone can figure out how.)

- Harald

Re: Changes 2009-07-15/16 in branch?

[Harald Hanche-Olsen]

+ Richard Stallman <rms@gnu.org>:

> One question is, do most apps on MacOS have _the same_ Applescript
> capability that has been put into Emacs?

Most? I don't think so. Small and simple apps generally don't, bigger
and more sophisticated ones generally do. Apple's own apps are more
likely to have provide services, but many non-Apple ones do, such as
Emacs (duh), LaTeXit, Opera, Quicksilver, Skim, Skype.

Relatively few apps have the capability of sending user supplied
Applescript commands to other apps, but I would suggest keeping that
capability, since it strengthens Emacs' position as a useful tool on
the Mac. (Though one could get much the same functionality by running
osascript as an external command.)

-- 
* Harald Hanche-Olsen     <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
  when there is no ground whatsoever for supposing it is true.
  -- Bertrand Russell

Re: Changes 2009-07-15/16 in branch?

[Richard Stallman]

    Most? I don't think so. Small and simple apps generally don't, bigger
    and more sophisticated ones generally do. Apple's own apps are more
    likely to have provide services, but many non-Apple ones do, such as
    Emacs (duh), LaTeXit, Opera, Quicksilver, Skim, Skype.

"Provide services" is somewhat cryptic.  Which services does that refer to?

    Relatively few apps have the capability of sending user supplied
    Applescript commands to other apps, but I would suggest keeping that
    capability, since it strengthens Emacs' position as a useful tool on
    the Mac. (Though one could get much the same functionality by running
    osascript as an external command.)

It seems to me that this is precisely the sort of thing we should avoid,
since it is a feature limited to a proprietary system and not even most
programs on that system have it.

Re: Changes 2009-07-15/16 in branch?

[Harald Hanche-Olsen]

+ Richard Stallman <rms@gnu.org>:

>     Most? I don't think so. Small and simple apps generally don't, bigger
>     and more sophisticated ones generally do. Apple's own apps are more
>     likely to have provide services, but many non-Apple ones do, such as
>     Emacs (duh), LaTeXit, Opera, Quicksilver, Skim, Skype.
> 
> "Provide services" is somewhat cryptic.  Which services does that refer to?

Note that every application on the mac uses the menu bar at the top of
the screen. Drop down menus at the menu bar, starting from the left,
are the Apple menu (mostly for system-wide stuff), the application
menu, and whatever other menu items the app might provide (File and
Edit usually come next).

In the application menu of every application there is a submenu called
Services. And the Services menu has a submenu for every app that
actually does provide a service (some apps provide only one service,
in which case the submenu is dispensed with)

The usual way to use a service provided by another app is to select
something with the mouse, be it text, graphics or a more complicated
object, and then select the desired service from the menu. The other
app will receive the selected stuff and do something with it.

Services provided by Emacs are these four:

  Email selection (i.e., put the selection in the body of a new message)
  New buffer containing selection
  Open selected file (the selection had better name a file)
  Send mail to selected address

A semirandom selection of services offered by other applications:

  Open URL
  Make new Applescript
  Run as Applescript
  Send file to bluetooth device
  Add contact (Skype)
  Call (Skype)
  Send SMS (Skype)

>     Relatively few apps have the capability of sending user supplied
>     Applescript commands to other apps, but I would suggest keeping that
>     capability, since it strengthens Emacs' position as a useful tool on
>     the Mac. (Though one could get much the same functionality by running
>     osascript as an external command.)
> 
> It seems to me that this is precisely the sort of thing we should
> avoid, since it is a feature limited to a proprietary system and not
> even most programs on that system have it.

I for one won't lose any sleep if it goes away, for as I said one can
always run osascript as an external program. If others disagree, they
will surely speak up.

- Harald

Re: Changes 2009-07-15/16 in branch?

[Richard Stallman]

    Services provided by Emacs are these four:

      Email selection (i.e., put the selection in the body of a new message)
      New buffer containing selection
      Open selected file (the selection had better name a file)
      Send mail to selected address

This seems legitimate.  It just lets Emacs respond to other
programs in a way that is normally used on MacOs.  So this
is not a MacOS-specific feature, but rather implementation
of a MacOS interface to Emacs.

    Now apart from Applescript and services (covered in a separate
    message), applications may respond to other kinds of events. One that
    Emacs does well is "open file"; the script above actually triggers
    such an event.

Ditto.

However, running Applescript programs FROM Emacs is a system-specific
feature for MacOS.  That is what ought to be deleted.

Re: Changes 2009-07-15/16 in branch?

[CHENG Gao]

*On Fri, 31 Jul 2009 23:21:54 -0400
* Also sprach Richard Stallman <rms@gnu.org>:


>     Now apart from Applescript and services (covered in a separate
>     message), applications may respond to other kinds of events. One that
>     Emacs does well is "open file"; the script above actually triggers
>     such an event.
>
> Ditto.
>
> However, running Applescript programs FROM Emacs is a system-specific
> feature for MacOS.  That is what ought to be deleted.

As I know, people have talked about replacing Applescript with
Javascript for fairly lone time. And there is a working implementation
called JSTalk
(http://gusmueller.com/blog/archives/2009/03/introducing_jstalk__an_alternative_to_applescript.html).

People also talked about replacing Applescript with Ruby
(http://macdevcenter.com/pub/a/mac/2007/02/27/replacing-applescript-with-ruby.html).

I must confess I never tried them.

I dont know the intention to delete this feature is due to MacOS or
Applescript or even both. If it's only because of Applescript, deletion
of it will hurt those efforts (as mentioned above).

Personally I wish this feature stays. I really like org-remember, but I
dont know if it's possible or how to org-remember information outside of
Emacs. Say for example I browse some webpage, and find I need to
remember something, I wish I could select a region and org-remember it
into my notes file. I trust I have to use this Applescript (or some
non-proprietary implementation like Javascript, Ruby etc.).

I wish this feature could stay.

Re: Changes 2009-07-15/16 in branch?

[CHENG Gao]

*On Sat, 01 Aug 2009 15:45:41 +0800
* Also sprach CHENG Gao <chenggao@gmail.com>:

> Personally I wish this feature stays. I really like org-remember, but I
> dont know if it's possible or how to org-remember information outside of
> Emacs. Say for example I browse some webpage, and find I need to
> remember something, I wish I could select a region and org-remember it
> into my notes file. I trust I have to use this Applescript (or some
> non-proprietary implementation like Javascript, Ruby etc.).
>
> I wish this feature could stay.

After posting this I did some web serach and found org-mac-protocol[1],
which is exactly what I need. It needs Applescript to function.



Footnotes: 
[1]  http://claviclaws.net/org/

Re: Changes 2009-07-15/16 in branch?

[Richard Stallman]

    As I know, people have talked about replacing Applescript with
    Javascript for fairly lone time. And there is a working implementation
    called JSTalk
    (http://gusmueller.com/blog/archives/2009/03/introducing_jstalk__an_alternative_to_applescript.html).

Can you explain what it means to "replace Applescript with Javascript"?
Do you mean changing MacOS to get rid of Applescript entirely?
Or making Emacs use Javascript on GNU-like systems the same way it
uses Applescript on MacOS?

Re: Changes 2009-07-15/16 in branch?

[CHENG Gao]

*On Sun, 02 Aug 2009 00:43:55 -0400
* Also sprach Richard Stallman <rms@gnu.org>:

>     As I know, people have talked about replacing Applescript with
>     Javascript for fairly lone time. And there is a working implementation
>     called JSTalk
>     (http://gusmueller.com/blog/archives/2009/03/introducing_jstalk__an_alternative_to_applescript.html).
>
> Can you explain what it means to "replace Applescript with Javascript"?
> Do you mean changing MacOS to get rid of Applescript entirely?
> Or making Emacs use Javascript on GNU-like systems the same way it
> uses Applescript on MacOS?

It means you can use Javascript instead of Applescript to write scripts
to communicate between applications on MacOS.I can't say Apple'll dump
Applescript and replace it with Javascript, but users can use Javascript
to do what Applescript can do. 

-- 
Numquam minus solus quam cum solus

Re: Changes 2009-07-15/16 in branch?

[Richard Stallman]

    It means you can use Javascript instead of Applescript to write scripts
    to communicate between applications on MacOS.I can't say Apple'll dump
    Applescript and replace it with Javascript, but users can use Javascript
    to do what Applescript can do. 

That sounds good.

Will this work also on GNU systems and GNU-like systems?

Re: Changes 2009-07-15/16 in branch?

[CHENG Gao]

*On Mon, 03 Aug 2009 12:17:15 -0400
* Also sprach Richard Stallman <rms@gnu.org>:

>     It means you can use Javascript instead of Applescript to write scripts
>     to communicate between applications on MacOS.I can't say Apple'll dump
>     Applescript and replace it with Javascript, but users can use Javascript
>     to do what Applescript can do. 
>
> That sounds good.
>
> Will this work also on GNU systems and GNU-like systems?

I dont too much about other systems， but as I know from GNUstep[1]
website, GNUstep (This's what NS port for besides MacOSX) has the same
scripting mechanism as MacOSX. The difference is MacOSX use Apple's
proprietary Applescript, while GNUstep uses StepTalk (SmallTalk as
scripting language) and GNUstep-Guile (Guile as scripting language). You
can check GNUstep's Developer Tools page[2].

And it's possible to use other scripting languages as Javascript, Ruby
to do scripting on MacOSX. I suppose it's possible to use other
scripting languages on GNUstep.



Footnotes: 
[1]  http://www.gnustep.org

[2]  http://www.gnustep.org/experience/DeveloperTools.html

-- 
The enemies of Freedom do not argue; they shout and they shoot.

Re: Changes 2009-07-15/16 in branch?

[Stefan Monnier]

> What is Applescript?  What does it do?  Can you show me an example
> of what people do with it?  How does it relate to Emacs?  Does it mean
> people can extend Emacs with Applescript programs?  Or can they
> only run Emacs from it, like from a shell script?

Also, AFAIK, Applescript support was already present in Emacs-22.
And it can be seen as "the D-Bus feature for Mac OS X", although we
haven't tried to provide an API that unifies them.

We may want to phase it out at some point (e.g. mark it obsolete if the
Services thingy can provide replacement functionality), but I don't
think we should eliminate it at this point.


        Stefan

Re: Changes 2009-07-15/16 in branch?

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 23 Jul 2009 07:22:55 -0400, Adrian Robert <adrian.b.robert@gmail.com> said:

> ns-set-background-alpha: The implementation you just removed was
> superior to that for (set-frame-parameter nil 'alpha ##): it does
> not alter the alpha of the titlebar, scrollbars, modeline, or text.
> This makes it usable, instead of a curiosity.

The implementation of the "superior" transparency has an annoying
glitch that it sometimes leaves "ghost letters" of the previous
contents on screen.  It is ridiculous to include such a premature
implementation recklessly in the release version, whereas the
alpha-component support in the other platforms (notably GNU/Linux) is
unimplemented yet.

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

Re: Changes 2009-07-15/16 in branch?

[Adrian Robert]

On Jul 26, 2009, at 8:35 PM, YAMAMOTO Mitsuharu wrote:

>>>>>> On Thu, 23 Jul 2009 07:22:55 -0400, Adrian Robert <adrian.b.robert@gmail.com 
>>>>>> > said:
>
>> ns-set-background-alpha: The implementation you just removed was
>> superior to that for (set-frame-parameter nil 'alpha ##): it does
>> not alter the alpha of the titlebar, scrollbars, modeline, or text.
>> This makes it usable, instead of a curiosity.
>
> The implementation of the "superior" transparency has an annoying
> glitch that it sometimes leaves "ghost letters" of the previous
> contents on screen.

I was not aware this issue was still present.  I had noticed it at one  
point a couple of years ago but thought it had been resolved once some  
indirectly-related issues with text rendering and GUI updates had been  
ironed out.  It's possible it returned after later changes in those  
areas.

Re: Changes 2009-07-15/16 in branch?

[Sean O'Rourke]

I use these features, and luckily have not recompiled since their
crippling.  I *think* reverting the following Git commits (to
git://git.sv.gnu.org/emacs.git) will undo the damage:

73f1096bb293917b7fb53db856c62f913d41676f
36384c4ea8d8f27d7065ea4d7bd51ee9cf2a8d3d
88cc3775afae928c4fc358334bb793801cc20aac
e9b54d75b4d998adf9001050afe883e944c405de

but I haven't tried recompiling yet.  Have I missed any?

Thanks,
Sean