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

[Alan Mackenzie]

Hallo, once again!

On Tue, Jul 29, 2008 at 05:44:10AM -0700, Xah wrote:
> On Jul 29, 4:52 am, Alan Mackenzie <a...@muc.de> wrote:

> > Please do that!  For one thing, you'll then find out just how time
> > consuming your changes will be to implement.

> there are difference between creating a fork vs the emacs team making
> the changes.

> For example, take this thread's issue of changing ... notation to ...
> in emacs manual and menu.

What, this thread whose Subject: line is "What does 'run' do in
cperl-mode?"?  ;-)

> The emacs team already have a infrastructure. So, there's mailing list,
> source code depository, bug apps, ways to report bug, ways to
> incorporate change, bug fixing cycle, feature adding cycle, release
> cycle, established feature adding process or convention, etc.

> On the other hand, to create a fork, you have to basically create the
> whole infrastructure, social and technical.

Yes, you do.

> Can you see there's a huge difference in manpower needed comparing the
> two?

Yes.  However, even if the infrastructure were already present for what
you want to do, it would still be a massive undertaking.

> So, for example, i claim that the shortcut notation change is just few
> hours work. Then somebody claims, if it is just few hours, why don't
> you do it and perhaps send in the diff? Well, i'm not in any sense a
> officially in gnu emacs dev team.

I am, though.  I'm not in a position to speak for the rest of the Emacs
team, but I can all but guarantee that if you created a patch to replace
"meta" by "alt", it would not be accpeted.  There would be a mass of
support work needed, it would cause all sorts of incompatibilities (one
already mentioned - you'll need to think up a new name for the current
"alt" modifier, and forever more field the confusion between old-alt and
new-alt), and generally foul things up for years to come, for very
questionable benefit.  I think that anybody who's capable of benefitting
from Emacs is intellectually able to understand what key "M-" refers to.

> I'm not subscribed to their mailing list.

You can read the archives at
<http://lists.gnu.org/archive/html/emacs-devel/2008-07/threads.html> etc.
If you do, you'll see just how much the developers care about what seem
trivial little issues in the user interface.

> Further, i'm not an experienced elisp coder as most of them are.

I would recommend you to get experienced.  Like Emacs, elisp is supremely
easy to use, but unlike Emacs, it's also very easy to learn (compared
with monstrosities like C++ or Java).

> I can still say make the changes in say 1 day. Then, i have to
> subscribe to the mailing list, write explanation all over again on why
> i did this.  Learn ways to put the code into their depository.
> Basically learn all the structures they are using, etc. On the other
> hand, if, say, one of the developer saw that the shortcut notation
> change is a good idea, he can then spend 4 hours and commit.

:-)  There's more to it than one developer "seeing" that it's a good
idea.  There's persuading the other 15 or 20 of that goodness, in
particular the two bosses Stefan Monnier and Chong Yidong.  The thread on
the mailing list would explode into a 200 post mamoth thread, at the end
of which the change would be rejected.  It would cause far too much work
for far too little, if any, gain.

> The above is somewhat simplified scenario of course. Please, no need to
> nit pick. But i hope you see that there's a difference, in the manpower
> needed between GNU Emacs adopting a change, vs someone outside making
> the exact same change into GNU Emacs.

Somebody has to do the heavy manual work.  It's rare indeed that anybody
on the Emacs team will see an idea and think "hey, that's great!  I'll go
off and do it!".  Normally the response would be "hey, that's great!
Would you code it up and submit it, please.  If you need any help, drop
us an email."

> > > For one thing, it's very difficult to change GNU Emacs on issues
> > > such as these.

> > It is.  The difficulties are primarily technical, not political
> > (though they're political too).

> > > The most effective way to make such change, is just have a capable
> > > coder and fork it, like Xemacs and Aquamacs did. Then, it'll wipe
> > > out emacs marketshare almost overnight. Then, the GNU Emacs people
> > > will, without any asking, seriously do all the changes, as it
> > > happened with Xemacs. (in my opinion, Xemacs is largely responsible
> > > for propelling user oriennted features we see in emacs today, took
> > > emacs about a decade to catch up.)

> > I don't think that'll happen at all.  But try it - it can't do any
> > harm.

> I do thank you for the encouragement. But, i find the naysaying too
> much. Of course, it's part of discussion. But too much negative
> attitude screw progress.

There's experience behind the "negative attitude".  However, if you think
I and others are wrong, you can prove us wrong by hacking your idea into
reality.  The emacs-devel mailing list responds MUCH more positively to
"here's a great idea I've just implemented.  Would you try it out,
please" than to "here's a great idea, would you implement it for me,
please".

> The issue in this thread here, is whether ... notation is better and
> should be adapted by emacs. I have given i hope detailed analysis:

> ... Notation vs ...
> http://xahlee.org/emacs/modernization_meta_key.html

With all due respect, that article is a bit superficial.  It ignores the
work which would be needed to change, and it fails to argue that the
change is important enough to be worth even a small amount of work.  It
seems more to be arguing that if we were starting from scratch, the term
"alt" would be the better one.  I agree with that.

> and answered all replies. However, many of this replies simply are not
> about facts of the subject but just naysays.

:-)  You mean, a reply which supports your idea is "factual", and one
which opposes it is not.  ;-)

> Somebody says this is not the proper place, will never work, AOL IM was
> ICQ, suggesting how i should do it, advices on how fork should be done,
> that i'm off from reality, etc.

> In general, lots of pure naysays.

Including from me.  There's a lot of experience and good judgement behind
these negative posts.

> The reason i gave, about why ... is better, is summarized like this:

> Universally understood
> Notation Same as Key Label
> Meta is Alt in practice
> Keyboards don't have Meta key today

> Can you point out, if any of these points are wrong, or other reasons
> this change is just bad?

Yes, and I already have done in this thread and probably before.  Let me
repeat myself: it would be far too much work to be worthwhile, and it
wouldn't solve a problem, because nobody gets confused more than
momentarily by the term "meta" anyway.

> You say it takes too much time to implement. How so?

I think I've explained this several times alreay.  Let me try again.
This change, even if it could be achieved in a few hours' hacking would
cause incompatibilities in existing code, and confusion between the
existing "alt" modifier (used by a tiny number of people) and the renamed
"meta".  Immediately after the change there would be weeks of code not
working, because hackers would continue to write "\M-", "\C-\M-", etc.,
which would now be incorrect.

> emacs manual is in info format, which is generated by texinfo. The
> source code is one or more plain files. As such, it can be done with
> the various find/replace commands in emacs, interactively or with
> regex.

You would have to write a new section detailing your (not yet specified)
backward compatibility features.  Hackers _hate_ that sort of thing.
They dissipate effort for no reason.

> I mentioned, there's another thing is changing how the shortcut ....

Correction: "key sequence".

> ... is displayed in the menu. I'm not a elisp expert (in comparison to
> emacs developers), and i haven't looked at how this can be done. I'm
> thinking there's just one place we can change and all mode's menu will
> show shortcuts using the ... or ... notation. Is this true?

No, there would be lots of places to change.  All the places which handle
key sequences have pretty much hard-coded values: For example, each
modifier is represented by a bit in a key-code: "M-" is b27, "C-" is b26,
"S-" (shift) is b25, "H-" (hyper) is b24, "s-" (super) is b23, "A-" (alt)
is b22.  Have a look at the function `event-apply-modifier' in simple.el
in the Emacs source to get an idea.

> > > So, either i try to spend tons of time to be the salesman for emacs
> > > modernization, or i actually take things into my hands and start my
> > > own emacs distro. The actually coding part for the latter will prob
> > > be dwarfed by all the associated tasks of running a website with
> > > public annoucement and communities etc.

> > The problem is that what you think of as "modernisation", others see
> > as "dumbing down".

> Well, yeah, i know about that and mentioned it a few times in this
> thread. But why is it dumb down? In what way it dumbed down? Let's
> focus on facts and specifics. Why is the notation ... is considered a
> dumb down? Is it because it's easy to understand?

The notation "alt-", of itself, is fine.  The notation "meta-" is
marginally less fine.  Your desire to change from "meta-" to "alt-"
posits dumb users for whom dumbing down is necessary or, at best, very
helpful.

> Is it your opinion, that emacs should remain difficult to use for the
> sake of difficult to use?

My opinion is that emacs is supremely easy to use and should remain so;
that emacs acheives this ease of use partly at the cost of being
difficult to learn, and that this is a good tradeoff; that changing from
"meta" to "alt" would achieve a vanishingly small increase in ease of
learning, no increase in ease of use, and a massive amount of pain for
those forced to switch usage.

[ .... ]

> > Html is ghastly for reading manuals.

> Great courage in start trolling. :)

> If you would, start a new thread, then i'll discuss my reasons about
> HTML vs info. Lets try to keep this thread on just the shortcut ....

Correction: "key sequence"

> .... notation issue please.

What, the thread called "What does 'run' do in cperl-mode?"?  ;-)

> > > But likely the html will still be generated by texinfo. Doc in info
> > > format will still be used i think, since it's a beautiful plain text
> > > hyperlink doc system. (ok, i'm allowed to have some wild future vision
> > > here...)
> > > PS one element that came to me i missed in the discussion of the labor
> > > of using the â~@~\Alt+â~@¹keyâ~@ºâ~@~] notation ....

> > Yes,Xah, that garbage is what your squiggles look like on a terminal
> > which isn't equipped with squiggle filters.  "Feel free" to stop dumping
> > such garbage on English language fora, please.

> Hum? You don't have the right font installed or something? My post
> should be in unicode with utf8 encoding.

It might well be.  And I'm not wasting my time with stupid international
character codes any more than I'm going to waste my time with MS-Word for
reading files.doc.  UTF has its place, but it's suboptimal in the extreme
for representing monolingual English.  If you want to piss off as many
people as possible, just carry on putting stupid multibyte characters
into your posts.  Nobody would have any objection to your UTF8 if you
restricted yourself to those characters also in ASCII.

> You can read them correctly using google group, e.g.
> http://groups.google.com/group/gnu.emacs.help/topics

This is a mailing list/newsgroup.  It would be far better if you wrote
your articles courteously.

> > > .... in emacs is that the notation should also show in menus, of
> > > course. (as opposed to just changing the info doc) I haven't looked
> > > at coding menus in elisp...  would it be just change one source
> > > code location for keybinding display and all menus of every mode
> > > will display using the ???Alt+???key??????  notation?

> > There are people who already use alt-key combinations in Emacs - the
> > alt key is not the same as the meta key.  You're going to screw them.
> > There are people, not a few, who bind meta-key key sequences in their
> > elisp files.  Are you going to insist on them making incompatible
> > changes, so that what used to be

> So you are talking about customization people made to emacs?

Of course.  Customisations and extensions.

> In this thread, i suggested making the shortcut ....

Correction: "key sequence".

> .... notation changes. So, it shouldn't effect people's exiting
> customization.

Do you mean customisation on the way out, or do you mean "exciting"
customisation, such as is done by me?  ;-)

> >     (global-set-key '[M-insertchar] 'show-debug-string)

> > will have to be changed to

> >     (global-set-key '[A-insertchar] 'show-debug-string)

> > ?  No, you won't.  What you'll actually do, once you become aware of the
> > problem, is to allow the 'M' modifier to remain "for the time being", as
> > a backward compatibility cludge.  10 years later, if Leeemacs is still
> > around by then, that "temporary" cludge will still be there.

> See above.

If you want to implement your idea, you'll have to decide how to solve
the problem of what to do about existing key sequences which use the
(existing) alt modifier.  Writing "see above" doesn't cut it, any more
than writing "PTO"[*] on both sides of a piece of paper would retain your
interest for very long.

[*] "PTO" = "please turn over".

> > And the same will hold for countless other little details you haven't
> > thought through yet.

> > On the other hand, if you were willing to get to grips with real
> > problems in Emacs, you'd be most welcome to contribute.

> Please refrain from wild generalizations and extraneous advice. I
> don't think it is welcome.

OK.  But I will give you this advice: get thoroughly proficient in elisp
before embarking on your "meta" to "alt" project.  It will save you a lot
of pain.

> For example, you are very welcome to contribute to me by donating money
> thru paypal. Use my xah @@@ xahlee.org email. It'll help my spirit in
> spreading more facts among tech geekers.

Hey, that's good.  :-)

>   Xah

-- 
Alan Mackenzie (Nuremberg, Germany).