Adrian Robert | 23 Jul 13:22 2009
Picon

Changes 2009-07-15/16 in branch?

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 <at> math.s.chiba-u.ac.jp>

(Continue reading)

YAMAMOTO Mitsuharu | 23 Jul 14:46 2009
Picon

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

>>>>> On Thu, 23 Jul 2009 07:22:55 -0400, Adrian Robert <adrian.b.robert <at> 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.

(Continue reading)

Stefan Monnier | 23 Jul 17:30 2009
Picon

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

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

YAMAMOTO Mitsuharu | 24 Jul 02:23 2009
Picon

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

>>>>> On Thu, 23 Jul 2009 11:30:21 -0400, Stefan Monnier <monnier <at> 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 <at> math.s.chiba-u.ac.jp

Stefan Monnier | 24 Jul 03:09 2009
Picon

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

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

YAMAMOTO Mitsuharu | 24 Jul 03:27 2009
Picon

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

>>>>> On Thu, 23 Jul 2009 21:09:20 -0400, Stefan Monnier <monnier <at> 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.
(Continue reading)

Stefan Monnier | 24 Jul 03:37 2009
Picon

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

> 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

YAMAMOTO Mitsuharu | 24 Jul 04:20 2009
Picon

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

>>>>> On Thu, 23 Jul 2009 21:37:36 -0400, Stefan Monnier <monnier <at> 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 <at> math.s.chiba-u.ac.jp

Stefan Monnier | 24 Jul 05:17 2009
Picon

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

> 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

YAMAMOTO Mitsuharu | 24 Jul 05:35 2009
Picon

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

>>>>> On Thu, 23 Jul 2009 23:17:25 -0400, Stefan Monnier <monnier <at> 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 <at> math.s.chiba-u.ac.jp

Jason Rumney | 24 Jul 05:44 2009
Picon

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

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.

YAMAMOTO Mitsuharu | 24 Jul 06:12 2009
Picon

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

>>>>> On Fri, 24 Jul 2009 11:44:10 +0800, Jason Rumney <jasonr <at> 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
(Continue reading)

YAMAMOTO Mitsuharu | 25 Jul 04:13 2009
Picon

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

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 <at> math.s.chiba-u.ac.jp

>>>>> On Fri, 24 Jul 2009 13:12:45 +0900, YAMAMOTO Mitsuharu <mituharu <at> 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.

Richard Stallman | 26 Jul 04:22 2009
Picon
Picon

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

    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.

(Continue reading)

YAMAMOTO Mitsuharu | 26 Jul 04:35 2009
Picon

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

>>>>> On Sat, 25 Jul 2009 22:22:24 -0400, Richard Stallman <rms <at> 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 <at> math.s.chiba-u.ac.jp

Miles Bader | 26 Jul 05:31 2009
Picon

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

YAMAMOTO Mitsuharu <mituharu <at> 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.

YAMAMOTO Mitsuharu | 26 Jul 05:45 2009
Picon

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

>>>>> On Sun, 26 Jul 2009 12:31:03 +0900, Miles Bader <miles <at> 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 <at> math.s.chiba-u.ac.jp

Richard Stallman | 27 Jul 04:44 2009
Picon
Picon

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

    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?

YAMAMOTO Mitsuharu | 27 Jul 05:20 2009
Picon

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

>>>>> On Sun, 26 Jul 2009 22:44:38 -0400, Richard Stallman <rms <at> 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.
(Continue reading)

Richard Stallman | 27 Jul 19:41 2009
Picon
Picon

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

    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?

Clifford Wulfman | 27 Jul 20:41 2009
Picon

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

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

Richard Stallman | 28 Jul 06:37 2009
Picon
Picon

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

    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?

Clifford Wulfman | 28 Jul 15:18 2009
Picon

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

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 <at> Princeton.EDU

Richard Stallman | 28 Jul 19:14 2009
Picon
Picon

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

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.

Alfred M. Szmidt | 28 Jul 20:39 2009
Picon

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

   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.

Ian Eure | 28 Jul 22:31 2009

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

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

(Continue reading)

Richard Stallman | 1 Aug 05:21 2009
Picon
Picon

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

    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.

Ian Eure | 1 Aug 06:10 2009

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

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.
(Continue reading)

Stephen J. Turnbull | 1 Aug 08:28 2009
Picon

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

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
(Continue reading)

Richard Stallman | 2 Aug 06:44 2009
Picon
Picon

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

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

James Cloos | 29 Jul 00:05 2009
Face

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

>>>>> "Richard" == Richard Stallman <rms <at> 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 <at> jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

(Continue reading)

Richard Stallman | 29 Jul 22:13 2009
Picon
Picon

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

Thanks for the explanation.

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

YAMAMOTO Mitsuharu | 30 Jul 00:05 2009
Picon

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

>>>>> On Wed, 29 Jul 2009 16:13:58 -0400, Richard Stallman <rms <at> 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 <at> math.s.chiba-u.ac.jp

YAMAMOTO Mitsuharu | 30 Jul 09:53 2009
Picon

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

>>>>> On Wed, 29 Jul 2009 16:13:58 -0400, Richard Stallman <rms <at> 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 <at> math.s.chiba-u.ac.jp

Chong Yidong | 30 Jul 16:01 2009

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

YAMAMOTO Mitsuharu <mituharu <at> 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.

YAMAMOTO Mitsuharu | 31 Jul 03:56 2009
Picon

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

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

> YAMAMOTO Mitsuharu <mituharu <at> 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
(Continue reading)

David De La Harpe Golden | 27 Jul 22:14 2009
Picon

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

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
(Continue reading)

YAMAMOTO Mitsuharu | 28 Jul 08:10 2009
Picon

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

>>>>> On Mon, 27 Jul 2009 21:14:06 +0100, David De La Harpe Golden <david <at> 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 <at> math.s.chiba-u.ac.jp

YAMAMOTO Mitsuharu | 28 Jul 02:53 2009
Picon

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

>>>>> On Mon, 27 Jul 2009 13:41:04 -0400, Richard Stallman <rms <at> 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.

(Continue reading)

Richard Stallman | 28 Jul 19:14 2009
Picon
Picon

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

    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?

Stefan Monnier | 24 Jul 21:25 2009
Picon

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

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

YAMAMOTO Mitsuharu | 29 Jul 02:22 2009
Picon

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

>>>>> On Thu, 23 Jul 2009 21:09:20 -0400, Stefan Monnier <monnier <at> 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 <at> math.s.chiba-u.ac.jp

Chong Yidong | 29 Jul 03:12 2009

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

YAMAMOTO Mitsuharu <mituharu <at> 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.

YAMAMOTO Mitsuharu | 29 Jul 03:18 2009
Picon

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

>>>>> On Tue, 28 Jul 2009 21:12:12 -0400, Chong Yidong <cyd <at> 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 <at> math.s.chiba-u.ac.jp

YAMAMOTO Mitsuharu | 29 Jul 06:48 2009
Picon

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

>>>>> On Wed, 29 Jul 2009 10:18:30 +0900, YAMAMOTO Mitsuharu <mituharu <at> 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 <at> math.s.chiba-u.ac.jp

YAMAMOTO Mitsuharu | 29 Jul 03:29 2009
Picon

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

>>>>> On Tue, 28 Jul 2009 21:12:12 -0400, Chong Yidong <cyd <at> 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 <at> math.s.chiba-u.ac.jp

Adrian Robert | 24 Jul 16:34 2009
Picon

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


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)
(Continue reading)

YAMAMOTO Mitsuharu | 25 Jul 03:15 2009
Picon

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

>>>>> On Fri, 24 Jul 2009 10:34:55 -0400, Adrian Robert <adrian.b.robert <at> 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  
(Continue reading)

Richard Stallman | 25 Jul 06:55 2009
Picon
Picon

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

    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?

Adrian Robert | 25 Jul 18:59 2009
Picon

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


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

Richard Stallman | 27 Jul 04:43 2009
Picon
Picon

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

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

Adrian Robert | 27 Jul 05:22 2009
Picon

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


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.

Harald Hanche-Olsen | 28 Jul 20:25 2009
Picon
Picon

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

+ Richard Stallman <rms <at> 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
(Continue reading)

Stephen J. Turnbull | 29 Jul 04:34 2009
Picon

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

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.

Lennart Borgman | 29 Jul 04:41 2009
Picon

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

On Wed, Jul 29, 2009 at 4:34 AM, Stephen J. Turnbull<stephen <at> 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?

Harald Hanche-Olsen | 29 Jul 04:56 2009
Picon
Picon

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

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

> On Wed, Jul 29, 2009 at 4:34 AM, Stephen J. Turnbull<stephen <at> 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

Stephen J. Turnbull | 29 Jul 05:33 2009
Picon

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

Lennart Borgman writes:
 > On Wed, Jul 29, 2009 at 4:34 AM, Stephen J. Turnbull<stephen <at> 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.

Richard Stallman | 29 Jul 22:14 2009
Picon
Picon

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

    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?

Chad Brown | 29 Jul 22:26 2009
Picon

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

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 gener al-purpose editors and/or user environments.

*Chad
Richard Stallman | 30 Jul 17:35 2009
Picon
Picon

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

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

Harald Hanche-Olsen | 30 Jul 18:37 2009
Picon
Picon

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

+ Richard Stallman <rms <at> 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 <at> example.com, which Emacs does not handle at present.
(But I think it should, if someone can figure out how.)

- Harald

Harald Hanche-Olsen | 29 Jul 22:31 2009
Picon
Picon

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

+ Richard Stallman <rms <at> 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

Richard Stallman | 30 Jul 17:35 2009
Picon
Picon

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

    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.

Harald Hanche-Olsen | 30 Jul 18:22 2009
Picon
Picon

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

+ Richard Stallman <rms <at> 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

Richard Stallman | 1 Aug 05:21 2009
Picon
Picon

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

    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.

CHENG Gao | 1 Aug 09:45 2009
Picon

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

*On Fri, 31 Jul 2009 23:21:54 -0400
* Also sprach Richard Stallman <rms <at> 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.

CHENG Gao | 1 Aug 11:36 2009
Picon

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

*On Sat, 01 Aug 2009 15:45:41 +0800
* Also sprach CHENG Gao <chenggao <at> 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/

Richard Stallman | 2 Aug 06:43 2009
Picon
Picon

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

    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?

CHENG Gao | 2 Aug 09:06 2009
Picon

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

*On Sun, 02 Aug 2009 00:43:55 -0400
* Also sprach Richard Stallman <rms <at> 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

Richard Stallman | 3 Aug 18:17 2009
Picon
Picon

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

    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?

CHENG Gao | 3 Aug 22:03 2009
Picon

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

*On Mon, 03 Aug 2009 12:17:15 -0400
* Also sprach Richard Stallman <rms <at> 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.

Stefan Monnier | 29 Jul 16:12 2009
Picon

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

> 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

YAMAMOTO Mitsuharu | 27 Jul 02:35 2009
Picon

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

>>>>> On Thu, 23 Jul 2009 07:22:55 -0400, Adrian Robert <adrian.b.robert <at> 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 <at> math.s.chiba-u.ac.jp

Adrian Robert | 27 Jul 05:12 2009
Picon

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


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

Sean O'Rourke | 29 Jul 05:23 2009

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

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


Gmane