bug#1993: 23.0.60; Emacs.app has only transparent window background

bug#1993: 23.0.60; Emacs.app has only transparent window background

[Peter Dyballa]

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

Hello!

When I build Emacs.app from source from yesterday evening (18:00 UTC)

	In GNU Emacs 23.0.60.1 (powerpc-apple-darwin8.11.0, NS apple- 
appkit-824.48)
	 of 2009-01-22 on localhost
	Windowing system distributor `Apple', version 10.3.824
	configured using `configure  '--without-sound' '--without-pop' '-- 
with-dbus' '--with-libotf' '--with-ns' '--disable-ns-self-contained'  
'--enable-locallisppath=/Library/Application Support/Emacs/ 
calendar23:/Library/Application Support/Emacs' 'PKG_CONFIG_PATH=/sw/ 
lib/xft2/lib/pkgconfig:/sw/lib/fontconfig2/lib/pkgconfig:/sw/lib/ 
freetype219/lib/pkgconfig:/sw/lib/pango-ft219/lib/pkgconfig:/sw/lib/ 
qt4-x11/lib/pkgconfig:/sw/lib/system-openssl/lib/pkgconfig:/sw/lib/ 
pkgconfig:/sw/share/pkgconfig:/usr/X11R6/lib/pkgconfig:/usr/local/lib/ 
pkgconfig:/usr/lib/pkgconfig' 'CFLAGS=-g -Wno-pointer-sign - 
bind_at_load -H -pipe -fPIC -mcpu=7450 -mtune=7450 -fast -mpim- 
altivec -ftree-vectorize -foptimize-register-move -freorder-blocks - 
freorder-blocks-and-partition -fthread-jumps -fpeephole -fno- 
crossjumping' 'CPPFLAGS=-no-cpp-precomp' 'LDFLAGS=-bind_at_load - 
dead_strip -multiply_defined suppress -L/sw/lib/ncurses''

or today (12:00 UTC)

	In GNU Emacs 23.0.60.2 (powerpc-apple-darwin8.11.0, NS apple- 
appkit-824.48)
	 of 2009-01-22 on localhost
	Windowing system distributor `Apple', version 10.3.824
	configured using `configure  '--without-sound' '--without-pop' '-- 
with-dbus' '--with-libotf' '--with-ns' '--disable-ns-self-contained'  
'--enable-locallisppath=/Library/Application Support/Emacs/ 
calendar23:/Library/Application Support/Emacs' 'PKG_CONFIG_PATH=/sw/ 
lib/xft2/lib/pkgconfig:/sw/lib/fontconfig2/lib/pkgconfig:/sw/lib/ 
freetype219/lib/pkgconfig:/sw/lib/pango-ft219/lib/pkgconfig:/sw/lib/ 
qt4-x11/lib/pkgconfig:/sw/lib/system-openssl/lib/pkgconfig:/sw/lib/ 
pkgconfig:/sw/share/pkgconfig:/usr/X11R6/lib/pkgconfig:/usr/local/lib/ 
pkgconfig:/usr/lib/pkgconfig' 'CFLAGS=-Wno-pointer-sign -bind_at_load  
-H -pipe -fPIC -mcpu=7450 -mtune=7450 -fast -mpim-altivec -ftree- 
vectorize -foptimize-register-move -freorder-blocks -freorder-blocks- 
and-partition -fthread-jumps -fpeephole -fno-crossjumping' 'CPPFLAGS=- 
no-cpp-precomp' 'LDFLAGS=-bind_at_load -dead_strip -multiply_defined  
suppress -L/sw/lib/ncurses''

and have these settings after I've launched it as 'nextstep/Emacs.app/ 
Contents/MacOS/Emacs -Q --debug-init' (after a 'sudo make install')

	Important settings:
	  value of $LC_ALL: nil
	  value of $LC_COLLATE: nil
	  value of $LC_CTYPE: de_DE.UTF-8
	  value of $LC_MESSAGES: nil
	  value of $LC_MONETARY: nil
	  value of $LC_NUMERIC: nil
	  value of $LC_TIME: nil
	  value of $LANG: de_DE.UTF-8
	  value of $XMODIFIERS: nil
	  locale-coding-system: utf-8-unix
	  default-enable-multibyte-characters: t
	
	Major mode: Lisp Interaction
	
	Minor modes in effect:
	  tooltip-mode: t
	  mouse-wheel-mode: t
	  menu-bar-mode: t
	  file-name-shadow-mode: t
	  global-font-lock-mode: t
	  font-lock-mode: t
	  global-auto-composition-mode: t
	  auto-composition-mode: t
	  auto-encryption-mode: t
	  auto-compression-mode: t
	  line-number-mode: t
	  transient-mark-mode: t
	
	Recent input:
	<ns-new-frame> <menu-bar> <help-menu> <send-emacs-
	bug-report>

I get completely transparent background of the windows. Only the  
frame's decoration (scroll-bar, tabbar), mode-line and the fringe's  
decoration are opaque, text looks frayed out/worn out. When I launch  
it the regular way then most colours are incorrect. And when I then  
pick into the *temp* buffer, I activate the Aqua client behind  
Emacs.app. Otool -L reports:

	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit  
(compatibility version 45.0.0, current version 824.48.0)
	/sw/lib/fontconfig2/lib/libfontconfig.1.dylib (compatibility version  
3.0.0, current version 3.0.0)
	/sw/lib/libdbus-1.3.dylib (compatibility version 8.0.0, current  
version 8.0.0)
	/sw/lib/ncurses/libncurses.5.dylib (compatibility version 5.0.0,  
current version 5.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current  
version 88.1.12)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current  
version 1.0.0)

--
Greetings

   Pete


"Evolution"            o           __o                     _o _
           °\___o      /0~         -\<,              ^\___ /=\\_/-%
oo~_______ /\ /\______/ \_________O/ O_______________o===>-->O--o____



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

bug#1993: 23.0.60; Emacs.app has only transparent window background

[David Reitter]

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

Hi Peter,
regarding this bug: please try rebuilding with an updated CVS.  I have  
just checked in a few changes that may fix this (by not loading  
org.gnu.Emacs.plist any longer).

Thanks
- David



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

bug#1993: 23.0.60; Emacs.app has only transparent window background

[Peter Dyballa]

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


Am 16.03.2009 um 22:22 schrieb David Reitter:

> Hi Peter,
> regarding this bug: please try rebuilding with an updated CVS.  I  
> have just checked in a few changes that may fix this (by not  
> loading org.gnu.Emacs.plist any longer).

I managed to solve the issue by editing the PLIST file. I don't think  
I'll rebuild Emacs.app this week or this month – the X client needs  
some work and investigation. Maybe in April ...

--
Mit friedvollen Grüßen

   Pete

Musik hilft gegen Taliban, nicht Bomben.



[-- Attachment #2: Signierter Teil der Nachricht --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

bug#1993: 23.0.60; Emacs.app has only transparent window background

[Peter Dyballa]

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


Am 16.03.2009 um 22:22 schrieb David Reitter:

> Hi Peter,
> regarding this bug: please try rebuilding with an updated CVS.  I  
> have just checked in a few changes that may fix this (by not  
> loading org.gnu.Emacs.plist any longer).
>


The new interface is faulty: setting some value pops up a form  
without the usual Aqua interface of the three colourful dots. When I  
press Yes a crash seems to happen, which I did not want to report. So  
the CrashReporter interface went away, but the Yes/No interface  
stayed. And Emacs.app. Both don't go away.

--
Mit friedvollen Grüßen

   Pete

Know thyself. Need help, call GOOGLE.



[-- Attachment #2: Signierter Teil der Nachricht --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

bug#1993: 23.0.60; Emacs.app has only transparent window background

[Peter Dyballa]

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


Am 16.03.2009 um 22:22 schrieb David Reitter:

> Hi Peter,
> regarding this bug: please try rebuilding with an updated CVS.  I  
> have just checked in a few changes that may fix this (by not  
> loading org.gnu.Emacs.plist any longer).
>

The new interface is incomplete: there is none of the options of the  
previous preferences pane visible.

--
Mit friedvollen Grüßen

   Pete
                       ~  o
                        ~_\\_/\
                       ~  O   O



[-- Attachment #2: Signierter Teil der Nachricht --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

bug#1993: 23.0.60; Emacs.app has only transparent window background

[Peter Dyballa]

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


Am 16.03.2009 um 22:22 schrieb David Reitter:

> Hi Peter,
> regarding this bug: please try rebuilding with an updated CVS.  I  
> have just checked in a few changes that may fix this (by not  
> loading org.gnu.Emacs.plist any longer).
>

The key binding is incorrect. Pressing ⌘-, Emacs.app reports:  
Symbol's function definition is void: ns-popup-prefs-panel. The  
correct key binding would obviously be: ns-show-prefs.

--
Mit friedvollen Grüßen

   Pete

Ein Optimist ist in der Regel ein Zeitgenosse, der ungenügend  
informiert ist.
				– John B. Priestley


[-- Attachment #2: Signierter Teil der Nachricht --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

bug#1993: 23.0.60; Emacs.app has only transparent window background

[Peter Dyballa]

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


Am 16.03.2009 um 22:22 schrieb David Reitter:

> Hi Peter,
> regarding this bug: please try rebuilding with an updated CVS.  I  
> have just checked in a few changes that may fix this (by not  
> loading org.gnu.Emacs.plist any longer).
>


The previous setting of the Option key is not preserved. I can't type  
[, ], {, }, |, or \!

--
Mit friedvollen Grüßen

   Pete

Make it simple, as simple as possible but no simpler.
				– Albert Einstein




[-- Attachment #2: Signierter Teil der Nachricht --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

bug#1993: 23.0.60; Emacs.app has only transparent window background

[David Reitter]

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

On Mar 28, 2009, at 3:54 PM, Peter Dyballa wrote:

>
> Am 16.03.2009 um 22:22 schrieb David Reitter:
>
>> Hi Peter,
>> regarding this bug: please try rebuilding with an updated CVS.  I  
>> have just checked in a few changes that may fix this (by not  
>> loading org.gnu.Emacs.plist any longer).
>>
>
>
> The previous setting of the Option key is not preserved. I can't  
> type [, ], {, }, |, or \!

In the NS port, ns-option-modifier is `meta' by default, so this is  
logical.
I presume you had a customization.

Adrian, should we change this to match the Carbon Emacs default?
Your ns-compatibility-mode (forgot exact name) could change that, of  
course, but without it, we don't have too many Mac like keys bound.   
Traditional Emacs users tend to want a Meta key, while most users of  
non-English keyboard layouts will need Option very regularly to do  
tasks often done in Emacs {like C/Java/... programming}.

- D


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

bug#1993: 23.0.60; Emacs.app has only transparent window background

[David Reitter]

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

On Mar 28, 2009, at 3:07 PM, Peter Dyballa wrote:
>
> The new interface is incomplete: there is none of the options of the  
> previous preferences pane visible.

Some of the options are gone or have been merged with standard Emacs  
options, others are available via the normal customization interface  
(M-x customize-group RET ns RET), to which we are going to add  
remaining options that make sense only on NS/Cocoa (if you know any,  
let me or Adrian know).

I think we should add the Ns group to the top-level customization  
group.  Users are not going to find this stuff otherwise.

- D

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

bug#1993: 23.0.60; Emacs.app has only transparent window background

[David Reitter]

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

On Mar 28, 2009, at 3:11 PM, Peter Dyballa wrote:
> The key binding is incorrect. Pressing ⌘-, Emacs.app reports:  
> Symbol's function definition is void: ns-popup-prefs-panel. The  
> correct key binding would obviously be: ns-show-prefs.

Thank you, I just installed a fix.  The correct binding is customize.   
ns-show-prefs is the event.

- D

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

bug#1993: 23.0.60; Emacs.app has only transparent window background

[David Reitter]

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

On Mar 28, 2009, at 3:03 PM, Peter Dyballa wrote:
>
> The new interface is faulty: setting some value pops up a form  
> without the usual Aqua interface of the three colourful dots. When I  
> press Yes a crash seems to happen, which I did not want to report.  
> So the CrashReporter interface went away, but the Yes/No interface  
> stayed. And Emacs.app. Both don't go away.


Sounds bad, but I don't understand what's happening.  Do you mean the  
color panel?
Setting which value??
If you can reproduce, please file a proper bug report (separately).   
The trace would be helpful, of course.

- David



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

bug#1993: 23.0.60; Emacs.app has only transparent window background

[Peter Dyballa]

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


Am 29.03.2009 um 00:26 schrieb David Reitter:

> In the NS port, ns-option-modifier is `meta' by default, so this is  
> logical.
> I presume you had a customization.


This is bad default, possibly applicable for a simple US keyboard.  
When the system language default is non-US and the script is Latin  
based then Meta should be Command and Alt left as Alt.

--
Mit evolutionären Grüßen

   Pete


"Evolution"            o           __o                     _o _
           °\___o      /0~         -\<,              ^\___ /=\\_/-%
oo~_______ /\ /\______/ \_________O/ O_______________o===>-->O--o____



[-- Attachment #2: Signierter Teil der Nachricht --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

bug#1993: 23.0.60; Emacs.app has only transparent window background

[David Reitter]

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

On Mar 28, 2009, at 8:09 PM, Peter Dyballa wrote:
>
>> In the NS port, ns-option-modifier is `meta' by default, so this is  
>> logical.
>> I presume you had a customization.
>
>
> This is bad default, possibly applicable for a simple US keyboard.  
> When the system language default is non-US and the script is Latin  
> based then Meta should be Command and Alt left as Alt.

Could be done, but I think we should stick to one default for all  
layouts.

This may have to wait until Adrian is back from his travels.

- D

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

bug#1993: 23.0.60; Emacs.app has only transparent window background

[Peter Dyballa]

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


Am 29.03.2009 um 01:05 schrieb David Reitter:

> Sounds bad, but I don't understand what's happening.  Do you mean  
> the color panel?

No.

> Setting which value??

In *Customize Group: Holidays* the value to mark holidays initially  
in *Calendar* buffer. When I press the Toggle button and then press  
the "Set for current session" button I get asked whether all values  
should be set according to this buffer. This question is already non- 
sense – what do I care for Chinese or Islamic or Bahai holidays?! But  
OK, maybe this the new default behaviour when customising a group of  
settings ...

And the crash seems to happen after a time period, independent of  
whether I press Yes or No.

> If you can reproduce, please file a proper bug report  
> (separately).  The trace would be helpful, of course.


OK, can be done!

--
Mit friedvollen Grüßen

   Pete

There's no sense in being precise when you don't even know what  
you're talking about.
				– John von Neumann




[-- Attachment #2: Signierter Teil der Nachricht --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

bug#1993: 23.0.60; Emacs.app has only transparent window background

[Peter Dyballa]

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


Am 29.03.2009 um 01:14 schrieb David Reitter:

> Could be done, but I think we should stick to one default for all  
> layouts.

Then the system's one. No artificial changes.

--
Mit friedvollen Grüßen

   Pete                                           0
                                            %-/\_//
                                             (*)(*)



[-- Attachment #2: Signierter Teil der Nachricht --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

bug#1993: 23.0.60; Emacs.app has only transparent window background

[Adrian Robert]

On Mar 29, 2009, at 5:11 AM, David Reitter wrote:

> Adrian, should we change this to match the Carbon Emacs default?
> Your ns-compatibility-mode (forgot exact name) could change that,  
> of course, but without it, we don't have too many Mac like keys  
> bound.  Traditional Emacs users tend to want a Meta key, while most  
> users of non-English keyboard layouts will need Option very  
> regularly to do tasks often done in Emacs {like C/Java/...  
> programming}.

Hi,

I will just give my thoughts on this, but since this port is a  
community project it is not necessarily my decision what to do.

The reason to prefer command = command is that emacs can then use  
similar accelerator keybindings to other os x apps.  The reason to  
prefer command = meta is that emacs can use similar non-ascii latin  
character entry to other os x apps.  Which is preferred for a given  
user depends on two questions:

1) is the user in continental Europe?
2) is the user editing code or text?

Why (2)?  Now that I've been living on the continent myself for a  
while, I've noticed that programmers here often just use a US  
keyboard layout even if they have a physically non-US keyboard.  It's  
just too much of a hassle to get commonly-needed special characters  
otherwise.

So my feeling is that the command=meta option is preferred by text- 
writing Continentals, while command = command is likely preferred by  
everyone else.  I am not sure which group makes up a larger subset of  
OS X emacs users.

I do know that I received a few complaints over the years from folks  
disliking the Emacs.app command=command default.  My answer was  
always to rehash the above and note that it's easy to change it --  
just flip a combo box in the prefs panel.  Now that it's not so easy  
(I guess figuring out the existence of ns/mac-command-modifier  
variable and writing suitable elisp to .emacs is necessary), the  
default setting becomes more important.


>> Could be done, but I think we should stick to one default for all  
>> layouts.
>>
>
> Then the system's one. No artificial changes.


I agree with both of these.  So perhaps the best default would be  
command=command (super), alt=none, and the user can set a meta key  
(additional to esc+) if he/she desires.

-Adrian

bug#1993: 23.0.60; Emacs.app has only transparent window background

[David Reitter]

On 4 Apr 2009, at 02:26, Adrian Robert wrote:
>
> So my feeling is that the command=meta option is preferred by text- 
> writing Continentals, while command = command is likely preferred by  
> everyone else.  I am not sure which group makes up a larger subset  
> of OS X emacs users.

Well, a pretty stable 50% of all Aquamacs users are US based.

> I do know that I received a few complaints over the years from folks  
> disliking the Emacs.app command=command default.  My answer was  
> always to rehash the above and note that it's easy to change it --  
> just flip a combo box in the prefs panel.  Now that it's not so easy  
> (I guess figuring out the existence of ns/mac-command-modifier  
> variable and writing suitable elisp to .emacs is necessary), the  
> default setting becomes more important.

That's right.  Similarly, I have received plenty of complaints about  
Option=Meta, especially in the early days of Aquamacs.

>
>>> Could be done, but I think we should stick to one default for all  
>>> layouts.
>>>
>>
>> Then the system's one. No artificial changes.
>
>
> I agree with both of these.  So perhaps the best default would be  
> command=command (super), alt=none, and the user can set a meta key  
> (additional to esc+) if he/she desires.

Well, that would be another alternative - maybe a good one.  It's my  
second-preferred variant.

The reason why I support Command=Meta for Emacs 23 is experience from  
working with Aquamacs and Carbon Emacs users.  It seems to me that  
there is a division between Emacs traditionalists, who would like an  
Emacs with maximum compatibility across platforms.  These people don't  
need/want Mac keybindings.  On the other end, you find people with the  
need for cross-application integration.  Unsurprisingly, that's the  
typical Aquamacs user, while the traditionalists compile Emacs from  
scratch or use a distribution like Carbon Emacs Package.

Due to this polarization, I think that it is sensible to Emacs Emacs- 
compatible.  Because otherwise, I'm not sure who's going to fill the  
void.

(That said, Meta=Esc is a perfectly acceptable default setting, too.   
Just not my #1 choice.)

bug#1993: 23.0.60; Emacs.app has only transparent window background

[Adrian Robert]

On Apr 4, 2009, at 9:45 PM, David Reitter wrote:
>>
>> I agree with both of these.  So perhaps the best default would be  
>> command=command (super), alt=none, and the user can set a meta key  
>> (additional to esc+) if he/she desires.
>
> Well, that would be another alternative - maybe a good one.  It's  
> my second-preferred variant.
>
> The reason why I support Command=Meta for Emacs 23 is experience  
> from working with Aquamacs and Carbon Emacs users.  It seems to me  
> that there is a division between Emacs traditionalists, who would  
> like an Emacs with maximum compatibility across platforms.  These  
> people don't need/want Mac keybindings.  On the other end, you find  
> people with the need for cross-application integration.   
> Unsurprisingly, that's the typical Aquamacs user, while the  
> traditionalists compile Emacs from scratch or use a distribution  
> like Carbon Emacs Package.

Do W32 users face this same issue?  That is, does 'alt' play the same  
role on their non-US keyboards as it does on the Mac ones?  Can we  
follow Emacs on W32 in that case?

IMHO Command is too heavily used on the Mac to simply throw under the  
bus by default -- the very user who will like emacs or uses it on  
other platforms is exactly the one already using cmd-shortcuts in  
other apps on the Mac.  Further, "traditionalists" are most prepared  
to get their hands dirty and set up a command=meta mapping if they  
want it.  Whereas a less savvy, single-platform user coming to  
Emacs.app from Text Edit, XCode, etc. will be most at home with  
command=super and alt=alt.  As they learn emacs more, they can make  
their own decision about which key to give up for meta if they  
dislike esc+.

In any case the information about these key settings should be easily  
accessible to users and the method of changing them should be easy.   
This could be done with a customization buffer hyperlinked from  
either the splash screen or a help menu item.  This could be  
reconciled with the desire to keep the interface uniform across all  
platforms by allowing a sentence on splash or a single menu item  
under Help for platform-specific information.

-Adrian

bug#1993: 23.0.60; Emacs.app has only transparent window background

[Peter Dyballa]

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


Am 06.04.2009 um 06:25 schrieb Adrian Robert:

> IMHO Command is too heavily used on the Mac to simply throw under  
> the bus by default -- the very user who will like emacs or uses it  
> on other platforms is exactly the one already using cmd-shortcuts  
> in other apps on the Mac.  Further, "traditionalists" are most  
> prepared to get their hands dirty and set up a command=meta mapping  
> if they want it.  Whereas a less savvy, single-platform user coming  
> to Emacs.app from Text Edit, XCode, etc. will be most at home with  
> command=super and alt=alt.  As they learn emacs more, they can make  
> their own decision about which key to give up for meta if they  
> dislike esc+.


I wouldn't mind if command=super by default – provided some key  
bindings are reserved for Mac OS X (copy, paste, maximise/minimise,  
hide/unhide, maybe also new frame and preferences/customisation), a  
three button can be emulated, and the standard Meta key bindings of  
GNU Emacs are also available as super key bindings (for example M-g g/ 
M-g M-g, which collides with s-g, isearch-repeat-forward).

--
Greetings

   Pete

With Capitalism man exploits man. With communism it's the exact  
opposite.



[-- Attachment #2: Signierter Teil der Nachricht --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

bug#1993: 23.0.60; Emacs.app has only transparent window background

[David Reitter]

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

On Apr 6, 2009, at 12:25 AM, Adrian Robert wrote:

>
> On Apr 4, 2009, at 9:45 PM, David Reitter wrote:
>>>
>>> I agree with both of these.  So perhaps the best default would be  
>>> command=command (super), alt=none, and the user can set a meta key  
>>> (additional to esc+) if he/she desires.
>>
>> Well, that would be another alternative - maybe a good one.  It's  
>> my second-preferred variant.
>>
>> The reason why I support Command=Meta for Emacs 23 is experience  
>> from working with Aquamacs and Carbon Emacs users.  It seems to me  
>> that there is a division between Emacs traditionalists, who would  
>> like an Emacs with maximum compatibility across platforms.  These  
>> people don't need/want Mac keybindings.  On the other end, you find  
>> people with the need for cross-application integration.   
>> Unsurprisingly, that's the typical Aquamacs user, while the  
>> traditionalists compile Emacs from scratch or use a distribution  
>> like Carbon Emacs Package.
>
> Do W32 users face this same issue?  That is, does 'alt' play the  
> same role on their non-US keyboards as it does on the Mac ones?  Can  
> we follow Emacs on W32 in that case?

They have a Windows key...

Their issue is that standard key combos like C-x, C-c, C-v collide  
with Emacs bindings.  CUA solved the issue in some way.


> IMHO Command is too heavily used on the Mac to simply throw under  
> the bus by default -- the very user who will like emacs or uses it  
> on other platforms is exactly the one already using cmd-shortcuts in  
> other apps on the Mac.  Further, "traditionalists" are most prepared  
> to get their hands dirty and set up a command=meta mapping if they  
> want it.

I've had pretty nasty complaints from people who said that they hit  
"Command Q" (to fill) because that's what they're used to from Unix  
systems and their keyboards, and then the app quit on them.


>  Whereas a less savvy, single-platform user coming to Emacs.app from  
> Text Edit, XCode, etc. will be most at home with command=super and  
> alt=alt.  As they learn emacs more, they can make their own decision  
> about which key to give up for meta if they dislike esc+.

Well, like I said in my earlier e-mail, I don't think you can make  
everyone happy.  And there are SO many things to upset and derail the  
newbie user that I wouldn't try to go for a compromise.

> In any case the information about these key settings should be  
> easily accessible to users and the method of changing them should be  
> easy.  This could be done with a customization buffer hyperlinked  
> from either the splash screen or a help menu item.  This could be  
> reconciled with the desire to keep the interface uniform across all  
> platforms by allowing a sentence on splash or a single menu item  
> under Help for platform-specific information.

That's a good idea.  As per the other e-mail: the top-level  
customization group should contain "ns" (or "nextstep"), along with a  
note that these are the Mac specific settings, also (because NS isn't  
really Mac lingo).


--
http://aquamacs.org -- Aquamacs: Emacs on Mac OS X
http://aquamacs.org/donate -- Could we help you? Return the favor and  
support the Aquamacs Project!

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

bug#1993: 23.0.60; Emacs.app has only transparent window background

[Jason Rumney]

Adrian Robert wrote:
> Do W32 users face this same issue?  That is, does 'alt' play the same 
> role on their non-US keyboards as it does on the Mac ones?  Can we 
> follow Emacs on W32 in that case?

AltGr is distinct from Alt on Windows, so non-US users just lose one of 
the meta keys on their keyboard.  There are some users who prefer to use 
Alt to access the menus though, and use the windows keys for meta.  
Currently this requires a patched version of Emacs to work properly, we 
have papers from the author, we are just waiting for the author to clean 
up the patch so we can install it, for 23.2 now.

bug#1993: 23.0.60; Emacs.app has only transparent window background

[Tom Hageman]

In article <mailman.4741.1239059038.31690.bug-gnu-emacs@gnu.org>, Jason  
Rumney wrote:
> Adrian Robert wrote:
> > Do W32 users face this same issue?  That is, does 'alt' play the
> > same  role on their non-US keyboards as it does on the Mac ones?
> > Can we  follow Emacs on W32 in that case?
>
> AltGr is distinct from Alt on Windows, so non-US users just lose one
> of  the meta keys on their keyboard.  There are some users who prefer
> to use  Alt to access the menus though, and use the windows keys for
> meta.   Currently this requires a patched version of Emacs to work
> properly, we  have papers from the author, we are just waiting for
> the author to clean  up the patch so we can install it, for 23.2 now.

Naive suggestion mabe, but as most (all?) Macs also have left- and right-  
Alt keys, can't one be used as meta and the other kept as alt?

Regards,
Tom.