[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What does 'run' do in cperl-mode?

From: Lennart Borgman (gmail)
Subject: Re: What does 'run' do in cperl-mode?
Date: Tue, 29 Jul 2008 00:44:21 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071031 Thunderbird/ Mnenhy/

Xah Lee wrote:
well, actually i'm surprised that you disagree with some of my points.

That is good. Then you have noticed I disagree ;-)

Ok, more specifically, in our topic here, you want the Alt key to
behave like other Windows apps. Namely, it invokes menu when pressed
by itself, and invoke command when pressed together with another key.
In other words, conforming to Window's UI guidelines.

Yes. I believe that on Windows it should do that. Otherwise a lot of users will be scared away.

As you know, on Apple's OSX, it follows a slightly different GUI
guideline. In particular, in OSX there's no such key like Window's Alt
that invokes a menu by itself... (traditinoally, Windows UI is
designed such that users can operate the computer by keyboard alone
without a mouse; but traditionlly Apple doesn't do this unless you
count turning keypad into a pointing device... but since about ~2004
in OSX Apple started to have a bunch of keys (usually Ctrl+Fn) to
navigate GUI elements... In short, how user uses keyboard to operate
the computer follows quite a different model than on Windows)

Thanks. I did not know about this. I guess what happened is that the accessibility requirements forced Apple to do allow keyboard navigation. I think that is good.

I fear however that it is a bit unfortunate they invented their own way. This can perhaps make things worse for people with disabilities. (And it makes me wonder about Apple's priorities.)

if i think correctly, you always stands by the Windows way. So, in
your opinion, my suggestion for using the notation “Alt+‹key›” for
emacs's “M-‹key›” is not good because that's incompatible with the
Window's way of pressing Alt by itself to invoke graphical menu.

Yes i can see that'd be a problem. But your Windows way is a nutcase,
and is not compatible with emacs tradition anyway. LOLz! I hope emacs
developers here will flame you to death first.

They already have. This is my second incarnation. Or is it the third? You kind of loose your memory.

Of course, we are getting onto a philosophical issue of whether to
have one's own interface or follow one of the major OS. The Java
platform tried to force its own interface (e.g. widgets looks and
feel), but basically failed. When a java program runs on Windows,
people want it to look and feel like Windows. When it runs on Mac,
people want it to look and feel like Mac. Basically, the crucial
factor is just market share. People are habituated with whatever they
are. They dont want to change. Java tried to squeeze its UI look and
feel starting with 0% market share into the meaty Windows UI or Mac
UI; sure it fails.

I think the lesson from Java is obvious: do what people expect on different platform. They expect Alt to activate the menus on Windows.

But of course in Emacs make it an option. Never force it on the users.

The current policy is that a standard Emacs (ie "emacs -Q") should behave the same on all platform. It is not a bad choice (but does not work since Emacs to be useful in many cases requires helper programs).

There is however nothing that prevents you and other to write different schemes corresponding to different platform for users to easily choose from. I have written some tools for it. And very good tools like cua-mode and Viper are included in Emacs.

However, with emacs, i think emacs has a chance to stand on its own.
Because, as you know, emacs precedes Windows or Mac.

That does not matter. Users (except those who already use Emacs) does not care about that.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]