[Top][All Lists]

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

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

From: Xah
Subject: Re: What does 'run' do in cperl-mode?
Date: Tue, 29 Jul 2008 15:50:53 -0700 (PDT)
User-agent: G2/1.0

On Jul 29, 11:27 am, Alan Mackenzie <address@hidden> wrote:

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

Let's get clear on exactly what is the proposed change.

(1) change all notations of M-key and C-key in emacs manual to Alt+key
and Ctrl+key notation. Just to be more precise, the source of emacs
manual is the texinfo source code, which are plain file. It generates
the info files.

(2) change somewhere in elisp source code, so that menu show shortcuts
with the Alt+ and Ctrl+ notation.

Note that elisp keymacro isn't in the proposed change, nor that elisp
function such as “kbd”.

> > I'm not subscribed to their mailing list.
> You can read the archives at
> <> etc.
> If you do, you'll see just how much the developers care about what seem
> trivial little issues in the user interface.

FYI, i'm aware, and have read it sometimes now and then this year.

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

Alan, don't start, ok? :)

(I'm no newbie and you knew. I started computer programing in ~1993,
started paid programing job in 1995...)

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

in dedicated mailing list, people would be more careful. Arguably on
emacs's dev list it'll still have a lot arguments... but i think it's
a good thing, in fact part of the list's goal, of exchange opinions,
even if at the end it is rejected. Some idea needs to start somewhere.
I'm sure there are initially rejected ideas that later become part of

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

Thank you.

As of now, i'm not sure i want to initiate the processing of actually
sending in code to GNU org for many social reasons. I don't mean to be
superficially mysterious... but for one thing, some (or perhaps
several) people don't necessarily like me due to my newsgroup posts.
Also, i'm not sure i want to be part of FSF or GNU. Sure i support
their ideas in general, but the OpenSource or FreeSoftware fervor
sometimes i cannot take as good to society.

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

Good point.

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

well as mentioned before... i'm just thinking about the change in the
manual, and the change in shortcut notation that shows up in menus. No
change proposed for macros or any elisp function. I think that's more
of what you are thinking.

I do think the change is important, because it makes emacs easier to
use. The difficulty to start using emacs is one of the most cited
criticism of emacs.

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

You are exagerrating i think. Ok maybe you are not.

The thing is, as i learned more in responding to people in this
thread, that some issue you just have to talk it out in detail. There
are a lot misunderstanding.

In the very beginning, i would simply think those who disagree with me
on this are just some patent idiots or who just want to play with me.
I'm sure many think the very fact i suggest the use of the Alt+
notation makes me a “troll”. But i think there's large room to

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

In last post, you mentioned some side effect of breaking customization
lisp codes. But i hope to clarify here, that no lisp code change is
proposed other than getting menus to display the new notation.

I think that's your main point, but i couldn't think of other major
points you are arguing against?

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

I think it's rather major confusion.

we have to look at in a social way. Sure, tech geeker may say that any
who can't understand a name alias is a idiot and not fit to use emacs.
That's rather a bad attitude and most of the time not seriously said.

software needs to be easy to use. Those not easy to use just become
less and less popular and eventually obsolete. Emacs has dwindling
user base.

> > You say it takes too much time to implement. How so?
> I think I've explained this several times alreay.

I honestly haven't seen you explained it in any tech way, other than
once in your last post.

>  Let me try again.
> This change, even if it could be achieved in a few hours' hacking would
> cause incompatibilities in existing code,

Note that no change in elisp code is involved, other than the one to
make the menu show the new notation.

All existing elisp code should behave as is.

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

Again, Alan, you kept reading more into it. There is no suggestion to
change elisp's macro syntax. Sorry if i wasn't clear or seems to imply

No, no change on lisp's key macro syntax. Ok, so the manual and menu
would show Alt+, but the keyboard macro and lisp code would show M-.
One may say this further causes confusion... yes but i think it is
better still than the current situation. Also, emacs already has huge
number of terminologies incompatible with today's...

the bottom line is, for anyone who actually gets down to reading or
wrtiing lisp , as the tech geeker would say: If you can't tell that M-
is just a syntax notation for the Alt key, then you perhaps shouldn't
code lisp.

Ideally, we would like to change the macro... but due to existing code
it's rather too much work. (that's what you are thinking) Also, the
issue gets complex since emacs already has the alt key idea from the
lisp machine keyboard's Alt Mode key... represented in kbd macro as
"A-", but isn't used today...

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

again, see above. There's no proposal to change keyboard macro syntax.

> > I mentioned, there's another thing is changing how the shortcut ....
> Correction: "key sequence".

note i'm aware that "key sequence" is preferred emacs term for
keyboard combination or sequential pressing of keys to invoke a

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

Again, i'm not suggesting change to kbd macro syntax. Somehow you have
this thought in mind firmly. Nowhere i implied such kbd macro syntax
Alan. Come on.

It remains the question: what source code one needs to change so that
all menu shows the Alt+ and Ctrl+ notation?

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

That's a bad way to look at things. Software needs to be easy to use.
As a metric to judge this quality, the more dumber people who can use
it, the better is the ease of use quality of the software.

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

Alright, i guess we disagree.

You might know already, that i also think emacs is the best text
editor and much more, despite some usabilitie issues on outset. If i
didn't think emacs is so great, i wouldn't have spent so much energy
arguing here. Also, i wrote a emacs and elisp tutorial from a
practical user's point of view. Many people liked my tutorial. For
exmaple, it is linked in blogs, e.g.
. Just to be sure, i also think emacs has great consistency, most
clear and comprehensive doc, far more so than most any software

one example related i like to cite, is the usability of linux. In your
stance, perhaps you think KDE/Gnome or Lindows is dumbing down? The
very notion and phrase of dumbing down is bad Alan.

> [ .... ]
> > > 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 address@hidden@address@hidden@~] 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.

I don't think you are being reasonable. today, even hardcore tech
geekers prefers unicode. Even in plain English, ascii is not as good
since it doesn't have curly quotes and other symbols such as lambda.

> > You can read them correctly using google group, e.g.
> >
> This is a mailing list/newsgroup.  It would be far better if you wrote
> your articles courteously.

In at least, i don't think i have flamed much. In
particular in this thread, i tried to be more normal and courteous.

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

Yes. Please keep in mind the change is for the manual and menu. Not
lisp kbd macro syntax.

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

(^_^) ... not sure i got the joke.

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

Again, i'm thinking just change in the manual and menu's notation for

The need to change kbd macro syntax so that it become consistent with
the suggestion, is good. But that gets hairy, as you explained. So the
issue now, is wheher this change creates inconsistecy. In my opinion,
no, because to be strict, emacs is already inconsistant by keep using
a key name on lisp machine's keyboards that practically didn't exist

One interesting point is that, on lisp machine's keyboard, it also has
a Alt key, labeled ALT MODE. In emacs's keyboard macro syntax, this is
written as "A-". So, when lisp keyboard went out and PC keyboard in,
emacs possibly might have made a better fix by changing using this Alt
key instead of Meta, instead of just mapping Meta to PC kbd's Alt. But
what exactly happened in this, why the decision back then... is
another interesting detail. My thought is that it's just part of
laziness, and other reason is that i think ALT MODE on lisp machine is
more like a mode toggle...

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

Well... thank you for this advice anyway.

> > For example, you are very welcome to contribute to me by donating money
> > thru paypal. Use my xah @@@ email. It'll help my spirit in
> > spreading more facts among tech geekers.
> Hey, that's good.  :-)
> >   Xah
> --
> Alan Mackenzie (Nuremberg, Germany).


reply via email to

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