Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.

[Glenn Morris]

Stefan Monnier wrote (on Sat, 23 Oct 2010 at 21:17 -0400):

> >   * lisp/term/pc-win.el (x-select-enable-clipboard):
> >   * lisp/term/x-win.el (x-select-enable-clipboard):
> >   * lisp/w32-vars.el (x-select-enable-clipboard): Make doc-strings identical.
> 
> Thanks.  Better yet would be to move them/it to lisp/term/common-win.el.

Done for x-win and w32-vars. Sadly common-win "common part of handling
window system" is not loaded by the MS-DOS (or Nextstep) ports.
So there needs to be a "really-common-win" for MS-Win+X+NS, and a
"really-really-common-win" for MS-Win+X+NS+DOS...

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.

[Dan Nicolaescu]

Glenn Morris <rgm@gnu.org> writes:

> Stefan Monnier wrote (on Sat, 23 Oct 2010 at 21:17 -0400):
>
>> >   * lisp/term/pc-win.el (x-select-enable-clipboard):
>> >   * lisp/term/x-win.el (x-select-enable-clipboard):
>> >   * lisp/w32-vars.el (x-select-enable-clipboard): Make doc-strings identical.
>> 
>> Thanks.  Better yet would be to move them/it to lisp/term/common-win.el.
>
> Done for x-win and w32-vars. Sadly common-win "common part of handling
> window system" is not loaded by the MS-DOS (or Nextstep) ports.

Last I looked ns-win doesn't have any good reason not to use common-win.

It duplicates functions (under new names), the only change is using
ns-invocation-args instead of x-invocation-args.

> So there needs to be a "really-common-win" for MS-Win+X+NS, and a
> "really-really-common-win" for MS-Win+X+NS+DOS...

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.

[Glenn Morris]

Dan Nicolaescu wrote:

> Last I looked ns-win doesn't have any good reason not to use common-win.
>
> It duplicates functions (under new names), the only change is using
> ns-invocation-args instead of x-invocation-args.

I saw that too. It is all very messy.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.

[Adrian Robert]

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

> 
> Dan Nicolaescu wrote:
> 
> > Last I looked ns-win doesn't have any good reason not to use common-win.
> >
> > It duplicates functions (under new names), the only change is using
> > ns-invocation-args instead of x-invocation-args.
> 
> I saw that too. It is all very messy.

ns-win was merged before common-win existed, but when the latter was created,
only x-win and w32-win were modified to use it.  I think, Dan, this was because
ns-win was still being cleaned up (partly by me) to better match the other
terms, is that correct?  So it was just bad timing.  Or was the creation of
common-win actually prompted by issues raised during the NS port merge? 
(That's, e.g., where menu.c came from.)

I haven't looked at the ns-win code in a while so I'm a little hesitant to
attempt the cleanup now, but if someone wants to try I'm happy to answer
questions about "why the heck is this thing in there?" etc. and test the
resulting changes.


thanks,
Adrian

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.

[Dan Nicolaescu]

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

> Glenn Morris <rgm <at> gnu.org> writes:
>
>> 
>> Dan Nicolaescu wrote:
>> 
>> > Last I looked ns-win doesn't have any good reason not to use common-win.
>> >
>> > It duplicates functions (under new names), the only change is using
>> > ns-invocation-args instead of x-invocation-args.
>> 
>> I saw that too. It is all very messy.
>
> ns-win was merged before common-win existed, but when the latter was created,
> only x-win and w32-win were modified to use it.  I think, Dan, this was because
> ns-win was still being cleaned up (partly by me) to better match the other
> terms, is that correct?  So it was just bad timing. 

Quite likely.  Or more like the ns cleanup was never completely finished.

> I haven't looked at the ns-win code in a while so I'm a little hesitant to
> attempt the cleanup now, but if someone wants to try I'm happy to answer
> questions about "why the heck is this thing in there?" etc. and test the
> resulting changes.

You are probably more qualified to do this that anyone else, and have
the advantage of being able to test the changes.
A related cleanup is to merge `command-line-ns-option-alist' in
`command-line-x-option-alist'.

ns-win.el [was Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.]

[Glenn Morris]

>> I haven't looked at the ns-win code in a while so I'm a little hesitant to
>> attempt the cleanup now, but if someone wants to try I'm happy to answer
>> questions about "why the heck is this thing in there?" etc. and test the
>> resulting changes.

I made ns load common-win.
The [x,ns]-handle-* stuff is still to be addressed.

Questions:

1. Are the 'ns specific menu adjustments that are now in menu-bar.el
really necessary? They seem so trivial as to be pointless.

An extra "spell" menu "for platform consistency", renaming the "Paste
from Kill Menu" item, etc.


2. Why all the wacky stuff in x-setup-function-keys? Why does the ns
port need to define the f1 key etc in system-key-alist, when no other
port does.


3. Why doesn't it define iso-lefttab in x-alternatives-map?


4. Is the before-make-frame-hook in ns-win really necessary?
Surely this is a window manager's job?


5. Does the ns port really need a special ns-print-buffer command?


6. ns-ignore-2-arg seems unused?


7. Can the 'mac- aliases be declared obsolete?


8. If running under GNUstep, rename "Help" to "Info". Is that really needed?
More generally, can the remaining menu-bar fiddling be done more
elegantly in menu-bar.el?

Re: ns-win.el

[Glenn Morris]

Oh, and my most important question: how are we supposed to spell
"Nextstep"? We have:

      2 NEXTSTEP
      1 NExTSTEP
      5 NeXTSTEP
      3 NeXTStep
     58 NeXTstep
      2 NextStep
     58 Nextstep
      9 nextstep

Re: ns-win.el

[CHENG Gao]

*On Tue, 26 Oct 2010 00:25:53 -0400
* Also sprach Glenn Morris <rgm@gnu.org>:

> Oh, and my most important question: how are we supposed to spell
> "Nextstep"? We have:
>
>       2 NEXTSTEP
>       1 NExTSTEP
>       5 NeXTSTEP
>       3 NeXTStep
>      58 NeXTstep
>       2 NextStep
>      58 Nextstep
>       9 nextstep

According to wiki (http://en.wikipedia.org/wiki/NeXTSTEP), NEXTSTEP is
used at the end of its life. NeXTSTEP is used most commonly by insiders.
So maybe choose from them.

Re: ns-win.el

[Adrian Robert]

On 2010/10/26, at 7:25, Glenn Morris wrote:

> 
> Oh, and my most important question: how are we supposed to spell
> "Nextstep"? We have:
> 
>      2 NEXTSTEP
>      1 NExTSTEP
>      5 NeXTSTEP
>      3 NeXTStep
>     58 NeXTstep
>      2 NextStep
>     58 Nextstep
>      9 nextstep

I'm no longer even sure myself but I suppose we could consolidate the minority ones into the majority at least.  ;-)

Re: ns-win.el

[Stefan Monnier]

> Oh, and my most important question: how are we supposed to spell
> "Nextstep"? We have:

Do we need to spell it?  Isn't there some other term that works as well
but doesn't excludes the non-proprietary parts?


        Stefan

Re: ns-win.el [was Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.]

[Adrian Robert]

On 2010/10/26, at 5:59, Glenn Morris wrote:

> 
>>> I haven't looked at the ns-win code in a while so I'm a little hesitant to
>>> attempt the cleanup now, but if someone wants to try I'm happy to answer
>>> questions about "why the heck is this thing in there?" etc. and test the
>>> resulting changes.
> 
> I made ns load common-win.

Thanks for tackling this.


> The [x,ns]-handle-* stuff is still to be addressed.

The 'nxopen' functions you removed fro ns-win are referenced from startup.el.  The -NSOpen argument is neither needed nor current any longer under OS X, but I think it might still be used under GNUstep.



> 1. Are the 'ns specific menu adjustments that are now in menu-bar.el
> really necessary? They seem so trivial as to be pointless.
> 
> An extra "spell" menu "for platform consistency", renaming the "Paste
> from Kill Menu" item, etc.

They are minor, but make a significant difference in making the menus seem less alien on the platform.  On the other hand anything less minor would deviate too much from the common emacs UI and confuse users coming from other platforms.  They are a compromise, but a reasonable one.

On the other hand, they were moved from menu-bar.el TO ns-win.el during the merge.  It was desired to keep these platform-specific things in the platform-specific file rather than cluttering up common files, and I've come to agree myself this is the best way.



> 2. Why all the wacky stuff in x-setup-function-keys? Why does the ns
> port need to define the f1 key etc in system-key-alist, when no other
> port does.

If you're talking about the systen-key-alist stuff, as I understand it that was there to define keys that existed on X platforms but not NeXT keyboards.  As such, some of it is obsolete.  Macs and GNUstep boxes have function keys now, so those can be removed.  Also the special ns- mappings that are no longer used can be removed.  This evening I will try removing as much as possible, and check the result in to trunk if it tests OK.



> 3. Why doesn't it define iso-lefttab in x-alternatives-map?

I don't have any opinion on this, but there was a recent related bug thread: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6616 .  I don't know enough to say if this is just something appropriate under X11 or if NS should use iso-lefttab as well.



> 4. Is the before-make-frame-hook in ns-win really necessary?
> Surely this is a window manager's job?

The result without doing that is making a new frame over the top one, because the left/top parameters default to those from the frame-alist.  This behavior is confusing to the user, so we put in this offset.



> 5. Does the ns port really need a special ns-print-buffer command?

It's a good idea to confirm a non-undoable action like printing beforehand.  I'd rather recommend to add a print-buffer-with-confirm to common code, or change the existing one to confirm.



> 6. ns-ignore-2-arg seems unused?

You are right, it can be removed.



> 7. Can the 'mac- aliases be declared obsolete?

I'd prefer to do so, but they are there for compatibility with the earlier Carbon port, and presumably Yamamoto Mitsuharu's current ports which are used by some people.  The Aquamacs community also uses these heavily.



> 8. If running under GNUstep, rename "Help" to "Info". Is that really needed?
> More generally, can the remaining menu-bar fiddling be done more
> elegantly in menu-bar.el?

See above under (1).



thanks,
Adrian

Re: ns-win.el

[Glenn Morris]

Adrian Robert wrote:

> The 'nxopen' functions you removed fro ns-win are referenced from
> startup.el.

I didn't remove any nxopen functions?

> On the other hand, they were moved from menu-bar.el TO ns-win.el
> during the merge. It was desired to keep these platform-specific
> things in the platform-specific file rather than cluttering up
> common files, and I've come to agree myself this is the best way.

Whoops. I have to say I disagree, since it is more work to change the
menus after they are defined, and it means requiring easymenu in the
dumped ns Emacs; and this means putting it in the DOC file for every
platform. I also find it much easier to see all the menu definitions at
one place rather than have them scattered over multiple files.

>> 7. Can the 'mac- aliases be declared obsolete?
>
> I'd prefer to do so, but they are there for compatibility with the
> earlier Carbon port, and presumably Yamamoto Mitsuharu's current
> ports which are used by some people. The Aquamacs community also
> uses these heavily.

No reason not to declare them obsolete in the nextstep port.

Re: ns-win.el

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Tue, 26 Oct 2010 02:45:13 -0400
> Cc: Dan Nicolaescu <dann@gnu.org>, emacs-devel@gnu.org
> 
> > On the other hand, they were moved from menu-bar.el TO ns-win.el
> > during the merge. It was desired to keep these platform-specific
> > things in the platform-specific file rather than cluttering up
> > common files, and I've come to agree myself this is the best way.
> 
> Whoops. I have to say I disagree, since it is more work to change the
> menus after they are defined, and it means requiring easymenu in the
> dumped ns Emacs; and this means putting it in the DOC file for every
> platform. I also find it much easier to see all the menu definitions at
> one place rather than have them scattered over multiple files.

FWIW, I agree.  There's no need to limit platform-specific stuff to
just a handful of platform-specific files.  We have a lot of platform
conditionals in many common Lisp files, and I see nothing wrong with
that.  By contrast, looking in *-win.el for something belonging to the
menu bar would be counter-intuitive, IMO.

Re: ns-win.el

[Adrian Robert]

On 2010/10/26, at 9:45, Glenn Morris wrote:

> Adrian Robert wrote:
> 
>> The 'nxopen' functions you removed fro ns-win are referenced from
>> startup.el.
> 
> I didn't remove any nxopen functions?

My mistake -- I confused lines when reading the changelog.



>> On the other hand, they were moved from menu-bar.el TO ns-win.el
>> during the merge. It was desired to keep these platform-specific
>> things in the platform-specific file rather than cluttering up
>> common files, and I've come to agree myself this is the best way.
> 
> Whoops. I have to say I disagree, since it is more work to change the
> menus after they are defined, and it means requiring easymenu in the
> dumped ns Emacs; and this means putting it in the DOC file for every
> platform. I also find it much easier to see all the menu definitions at
> one place rather than have them scattered over multiple files.

I don't feel strongly, but having it in ns-win.el makes it clearer what is done differently for that platform and keeps the clutter out for people reading the common code.  The code isn't that much "work" and it's limited to when the NS windowing system is actually used.  Does it really need to be in DOC file for all builds, or just builds that include NS?



>> They are minor, but make a significant difference in making the
>> menus seem less alien on the platform. On the other hand anything
>> less minor would deviate too much from the common emacs UI and
>> confuse users coming from other platforms. They are a compromise,
>> but a reasonable one.
> 
> BTW I kind of thought the point of Emacs was to look the same on all
> platforms; but I only use it on GNU/Linux.

I'd say the "point" of emacs is to provide second-to-none editing functionality, and a secondary point is to deliver it on as many platforms as possible with least overall friction for users.  If the port was remapping M-x or something like that, I'd see a problem.  This is much more "trivial" which interferes in no way with functionality but nonetheless helps the app feel more accessible and "at home" on the platform.



> See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4517


It "bugged" this reporter, but how to compare to the hundreds / thousands who remained silent, or perhaps benefited from being able to find the menu entry easily?

Re: ns-win.el

[Stefan Monnier]

>>> On the other hand, they were moved from menu-bar.el TO ns-win.el
>>> during the merge. It was desired to keep these platform-specific
>>> things in the platform-specific file rather than cluttering up
>>> common files, and I've come to agree myself this is the best way.

I can't remember why we moved these menu-bar thingies to ns-win.el, but
I think they're nicer where they are now: these differences are things
we want to stick out like sore-thumbs to remind us of the inconsistencies.

> I don't feel strongly, but having it in ns-win.el makes it clearer
> what is done differently for that platform and keeps the clutter out
> for people reading the common code.  The code isn't that much "work"
> and it's limited to when the NS windowing system is actually used.
> Does it really need to be in DOC file for all builds, or just builds
> that include NS?

Yes, we want to have a single DOC file, identical for all cases.

>>> They are minor, but make a significant difference in making the
>>> menus seem less alien on the platform. On the other hand anything
>>> less minor would deviate too much from the common emacs UI and
>>> confuse users coming from other platforms. They are a compromise,
>>> but a reasonable one.

I think it's usually good to have Emacs follow the platform guidelines.
It's also good to have Emacs be consistent across platforms.  So there's
sometimes a tension here.  Moving the Spell menu seems like a good
decision in this case.  Maybe we could even resolve this difference by
moving the Spell menu for all the platforms (this is a very weak
suggestion: I rarely if ever use the menus, so I have no idea what would
be a good change in this respect).


        Stefan

Re: ns-win.el

[Glenn Morris]

Another question:

ns-win.el adds `windows' to menu-bar-final-items, but doesn't seem to
define a "Windows" menu. So can this be removed?

Re: ns-win.el

[Adrian Robert]

On 2010/10/26, at 22:25, Glenn Morris wrote:

> 
> Another question:
> 
> ns-win.el adds `windows' to menu-bar-final-items, but doesn't seem to
> define a "Windows" menu. So can this be removed?

Yes.

Re: ns-win.el

[Glenn Morris]

Adrian Robert wrote:

>> An extra "spell" menu "for platform consistency", renaming the "Paste
>> from Kill Menu" item, etc.
>
> They are minor, but make a significant difference in making the
> menus seem less alien on the platform. On the other hand anything
> less minor would deviate too much from the common emacs UI and
> confuse users coming from other platforms. They are a compromise,
> but a reasonable one.

BTW I kind of thought the point of Emacs was to look the same on all
platforms; but I only use it on GNU/Linux.

See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4517

Re: ns-win.el

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Tue, 26 Oct 2010 02:50:30 -0400
> Cc: Dan Nicolaescu <dann@gnu.org>, emacs-devel@gnu.org
> 
> BTW I kind of thought the point of Emacs was to look the same on all
> platforms

Indeed.  For comparison, several requests to make Emacs on Windows
behave more Windows-like were rejected for this very reason.

Re: ns-win.el

[Ted Zlatanov]

On Tue, 26 Oct 2010 03:49:10 -0400 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Glenn Morris <rgm@gnu.org>
>> Date: Tue, 26 Oct 2010 02:50:30 -0400
>> Cc: Dan Nicolaescu <dann@gnu.org>, emacs-devel@gnu.org
>> 
>> BTW I kind of thought the point of Emacs was to look the same on all
>> platforms

EZ> Indeed.  For comparison, several requests to make Emacs on Windows
EZ> behave more Windows-like were rejected for this very reason.

What if the "native" look is optional and off by default?

Ted

Re: ns-win.el

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Tue, 26 Oct 2010 08:08:16 -0500
> 
> On Tue, 26 Oct 2010 03:49:10 -0400 Eli Zaretskii <eliz@gnu.org> wrote: 
> 
> >> From: Glenn Morris <rgm@gnu.org>
> >> Date: Tue, 26 Oct 2010 02:50:30 -0400
> >> Cc: Dan Nicolaescu <dann@gnu.org>, emacs-devel@gnu.org
> >> 
> >> BTW I kind of thought the point of Emacs was to look the same on all
> >> platforms
> 
> EZ> Indeed.  For comparison, several requests to make Emacs on Windows
> EZ> behave more Windows-like were rejected for this very reason.
> 
> What if the "native" look is optional and off by default?

That'd be fine, IMO.  We do that elsewhere.  For example, ls-lisp.el
has a few options whose non-default values make Dired behave like
Windows file managers do.

Re: ns-win.el

[Ted Zlatanov]

On Tue, 26 Oct 2010 10:42:00 -0400 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Tue, 26 Oct 2010 08:08:16 -0500
>> 
>> What if the "native" look is optional and off by default?

EZ> That'd be fine, IMO.  We do that elsewhere.  For example, ls-lisp.el
EZ> has a few options whose non-default values make Dired behave like
EZ> Windows file managers do.
On Tue, 26 Oct 2010 11:27:33 -0400 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

SM> I think it's usually good to have Emacs follow the platform guidelines.
SM> It's also good to have Emacs be consistent across platforms.  So there's
SM> sometimes a tension here.  Moving the Spell menu seems like a good
SM> decision in this case.  Maybe we could even resolve this difference by
SM> moving the Spell menu for all the platforms (this is a very weak
SM> suggestion: I rarely if ever use the menus, so I have no idea what would
SM> be a good change in this respect).

My suggestion (specifically on MacOS X, where user preferences are saved
in a consistent way and associated with the user account) is to ask once
on startup "do you want the native or the standard look?"

Then set a preference key accordingly and never ask the question again
as long as that key exists (but allow changing it in the Preferences
dialog).  Changing the value only takes effect on restart.

This is IMHO the best compromise to improve usability for everyone on
the Mac OS X platform.

Ted

Re: ns-win.el

[Daniel Pittman]

Adrian Robert <adrian.b.robert@gmail.com> writes:
> On 2010/10/26, at 5:59, Glenn Morris wrote:
>
>>>> I haven't looked at the ns-win code in a while so I'm a little hesitant to
>>>> attempt the cleanup now, but if someone wants to try I'm happy to answer
>>>> questions about "why the heck is this thing in there?" etc. and test the
>>>> resulting changes.
>>
>> I made ns load common-win.
>
> Thanks for tackling this.

[...]

>> 3. Why doesn't it define iso-lefttab in x-alternatives-map?
>
> I don't have any opinion on this, but there was a recent related bug thread:
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6616 .  I don't know enough to
> say if this is just something appropriate under X11 or if NS should use
> iso-lefttab as well.

Er, FWIW I recently needed to start using Emacs 23.2 on a MacOS-X 10.6 machine
and ran into the utterly surprising behaviour that S-tab was translated to C-y
for me.  I ended up poking about, then doing a 'global-set-key' binding for
S-tab that did what I wanted, but ... yeah.

More or less the same issue, and I would strongly support getting rid of that
translation as a surprised end user.

Regards,
        Daniel
-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.

[Eli Zaretskii]

> Date: Sat, 23 Oct 2010 22:02:54 -0400
> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > >   * lisp/term/pc-win.el (x-select-enable-clipboard):
> > >   * lisp/term/x-win.el (x-select-enable-clipboard):
> > >   * lisp/w32-vars.el (x-select-enable-clipboard): Make doc-strings identical.
> > 
> > Thanks.  Better yet would be to move them/it to lisp/term/common-win.el.
> 
> Done for x-win and w32-vars. Sadly common-win "common part of handling
> window system" is not loaded by the MS-DOS (or Nextstep) ports.
> So there needs to be a "really-common-win" for MS-Win+X+NS, and a
> "really-really-common-win" for MS-Win+X+NS+DOS...

When I revived the MS-DOS port 2 years ago, I had a good reason not to
load common-win.el.  I tried, and it caused trouble, so I removed it
from loadup.el and left behind a comment (which admittedly lacks
details).  I could try that again, if it's important, and report the
problems it causes, if any are left.

That said, I don't understand why selection-related stuff belongs to
*-win.el.  It has nothing to do with window systems; it's quite
possible that text terminals will be able to access selections (and I
understand some of them already do).  What will we do then--load
common-win.el on a tty as well?

So how about finding a better home for that stuff?  Like frame.el or
mouse.el, for example?

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.

[Glenn Morris]

Eli Zaretskii wrote:

> When I revived the MS-DOS port 2 years ago, I had a good reason not to
> load common-win.el.  I tried, and it caused trouble, so I removed it
> from loadup.el and left behind a comment (which admittedly lacks
> details).  

It was a helpful comment. More than the nextstep port has.

> I could try that again, if it's important, and report the problems
> it causes, if any are left.

I don't think it is important.

> That said, I don't understand why selection-related stuff belongs to
> *-win.el.  It has nothing to do with window systems; it's quite
> possible that text terminals will be able to access selections (and I
> understand some of them already do).  What will we do then--load
> common-win.el on a tty as well?

All this term/ stuff seems like a big mess.

> So how about finding a better home for that stuff? Like frame.el or
> mouse.el, for example?

Sounds like a good idea.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.

[Stefan Monnier]

>> So how about finding a better home for that stuff? Like frame.el or
>> mouse.el, for example?
> Sounds like a good idea.

Fine by me, yes.  I just want to get rid of the duplication.  We could
also try to correct names while we do that ("x-" should only be used
for X11-specific stuff, just like "w32-" and "ns-" are backend specific).


        Stefan

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.

[Glenn Morris]

Stefan Monnier wrote:

> Fine by me, yes.  I just want to get rid of the duplication.

I find it weird that when faced with the issue "we need to define a
function, eg x-display-list, on multiple platforms; it should have the
same arguments, doc-string, and behaviour on each platform" that Emacs
consistently chose to have three completely separate definitions in
three separate files; rather than just having one with #ifdefs for
each platform where needed.

Does anyone know what the reason for this design choice was? Was it
just that each port was developed independently by copying the X files
and modifying them, and nobody ever merged them? Or is/was there some
advantage to this duplication?

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.

[Stephen J. Turnbull]

Glenn Morris writes:

 > I find it weird that when faced with the issue "we need to define a
 > function, eg x-display-list, on multiple platforms; it should have the
 > same arguments, doc-string, and behaviour on each platform" that Emacs
 > consistently chose to have three completely separate definitions in
 > three separate files; rather than just having one with #ifdefs for
 > each platform where needed.

Some such strategy is necessary if you are going to support different
console types in the same binary.  Eg, it is possible to support both
native MS Windows displays and X displays at the same time.

It's true that for very similar display types such as Xt and GTK+
where much of the code can be reused[1], it may make sense to create a
single file with the common code, and include it multiple times with
preprocessor tweaking to make the names fit and to register driver
functions in the right tables.  But there's no point in this for X
drivers vs. MS Windows drivers; they're going to have very little
common code.

Footnotes: 
[1]  Whether that's a good idea or not is a separate question.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>     Eli Zaretskii <eliz@gnu.org>,
>     emacs-devel@gnu.org
> Date: Mon, 25 Oct 2010 17:03:40 +0900
> 
> It's true that for very similar display types such as Xt and GTK+
> where much of the code can be reused[1], it may make sense to create a
> single file with the common code, and include it multiple times with
> preprocessor tweaking to make the names fit and to register driver
> functions in the right tables.  But there's no point in this for X
> drivers vs. MS Windows drivers; they're going to have very little
> common code.

Actually, the common code is quite abundant, because the back-end
specific code is not well separated from the platform independent code
that manipulates Emacs internal objects.  This causes maintenance
headaches, whereby work on the same bug or feature needs to be done in
several places.

E.g., I recently discovered that various bugfixes and new features
introduced into mouse highlight were done only in the GUI parts of the
display engine, even though the TTY display also supports mouse
highlight (with GPM).  This was because the TTY code used a slightly
tailored version of a function that was originally written for in
xterm.c.  Then the GUI variant of that function was developed, while
the TTY variant was simply forgotten in its original shape.

So keeping the common code common makes sense even if Emacs will never
be used on X and MS-Windows in the same session, and even if the
back-ends are very different.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> From: Glenn Morris <rgm@gnu.org>
> Date: Mon, 25 Oct 2010 00:56:56 -0400
> 
> I find it weird that when faced with the issue "we need to define a
> function, eg x-display-list, on multiple platforms; it should have the
> same arguments, doc-string, and behaviour on each platform" that Emacs
> consistently chose to have three completely separate definitions in
> three separate files; rather than just having one with #ifdefs for
> each platform where needed.
> 
> Does anyone know what the reason for this design choice was?

It's not a conscious design choice, just a historical accident.

> Was it just that each port was developed independently by copying
> the X files and modifying them, and nobody ever merged them?

Yes.  Also because the original X-centric design never bothered to
separate the parts which are specific to X from purely Emacs
internals.  This made copy/paste job much easier than the refactoring
required for adding yet another windowing backend.

Btw, "nobody ever merged them" is not entirely true.  Over the years,
several such merges were done; as result, we now have menu.c where
previously there were only xmenu.c and w32menu.c, and also several
functions were moved from xterm.c/w32term.c to xdisp.c.  So it's more
accurate to say that the merge was never completed.

In my experience, most of the job that's left should start by defining
portable (and opaque, as far as possible) data types, and portable
wrapper functions, that will have different definitions on different
platforms.  If this is done well, the rest should be almost a
mechanical job.

> Or is/was there some advantage to this duplication?

No advantages; only disadvantages.

moving x-select* [was Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.]

[Glenn Morris]

>>> So how about finding a better home for that stuff? Like frame.el or
>>> mouse.el, for example?
[...]
> Fine by me, yes.  I just want to get rid of the duplication.

Is it OK to move x-select-enable-clipboard and x-select-text from
common-win and pc-win to select.el? I am a little unsure since the
condition for loading select.el in loadup is the presence of
mouse-support, a condition which is not present in the current *-win
files.

Re: moving x-select* [was Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.]

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>
> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 27 Oct 2010 23:54:45 -0400
> 
> Is it OK to move x-select-enable-clipboard and x-select-text from
> common-win and pc-win to select.el?

Fine with me, except...

> I am a little unsure since the condition for loading select.el in
> loadup is the presence of mouse-support, a condition which is not
> present in the current *-win files.

...this: selection is possible without a mouse (by shift-movement).
So I think conditioning this on the mouse would not be TRT (although
for now it is, because we don't have any build that can use
selections, but doesn't have a mouse).

Re: moving x-select* [was Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.]

[Jason Rumney]

On 28/10/2010 12:06, Eli Zaretskii wrote:

>> I am a little unsure since the condition for loading select.el in
>> loadup is the presence of mouse-support, a condition which is not
>> present in the current *-win files.
>>      
> ...this: selection is possible without a mouse (by shift-movement).
> So I think conditioning this on the mouse would not be TRT (although
> for now it is, because we don't have any build that can use
> selections, but doesn't have a mouse).
>    

Realistically though, we are not going to add a platform in 2010 or 
later that does not support a pointing device but does support selections.

Re: moving x-select* [was Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.]

[Chad Brown]

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


On Oct 27, 2010, at 10:32 PM, Jason Rumney wrote:
> Realistically though, we are not going to add a platform in 2010 or later that does not support a pointing device but does support selections.

I hate to be a bikeshedding nay-sayer, but there are a fair number of new touch-based UIs support selections without necessarily supporting pointing mouse cursor-like concepts (Android being an obvious potential candidate).

*Chad

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

Re: moving x-select*

[Jason Rumney]

Chad Brown <yandros@MIT.EDU> writes:

> I hate to be a bikeshedding nay-sayer, but there are a fair number of new
> touch-based UIs support selections without necessarily supporting pointing
> mouse cursor-like concepts (Android being an obvious potential candidate).

A touchscreen is a pointing device - that is why I did not say mouse.

Re: moving x-select*

[Chad Brown]

On Oct 28, 2010, at 6:54 AM, Jason Rumney wrote:

> Chad Brown <yandros@MIT.EDU> writes:
> 
>> I hate to be a bikeshedding nay-sayer, but there are a fair number of new
>> touch-based UIs support selections without necessarily supporting pointing
>> mouse cursor-like concepts (Android being an obvious potential candidate).
> 
> A touchscreen is a pointing device - that is why I did not say mouse.

Not in the sense that Emacs understands `pointing device'.  Android
*has* pointing device support, but the smartphone/tablet form factors
won't have one 99.9% of the time (for most of them, you'd have to add
the driver yourself).  This already came up in the maemo port, and I
really expect (hope) to see it again when the android tablets are
actually commonly available.

It's possible that I'm misunderstanding the original criteria, and
you're saying something more like ``since /some/ android devices
support a pointing device, all android ports will load the
pointing-device code even though many particular devices don't have
any support for it''.  If that case is fine in general, then what I'm
saying doesn't matter; I thought the original point was just that
having selection support depend on mouse support might be wrong.

This situation is on my mind lately, because I'm really hoping for a
decent android-based tablet that can usefully support emacs.   My
apologies if my enthusiasm has caused trouble.

*Chad

Re: moving x-select*

[Stefan Monnier]

>>>> So how about finding a better home for that stuff? Like frame.el or
>>>> mouse.el, for example?
> [...]
>> Fine by me, yes.  I just want to get rid of the duplication.

> Is it OK to move x-select-enable-clipboard and x-select-text from
> common-win and pc-win to select.el? I am a little unsure since the
> condition for loading select.el in loadup is the presence of
> mouse-support, a condition which is not present in the current *-win
> files.

To solve this problem, we could load select.el unconditionally.


        Stefan