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

[Xah <xahlee@gmail.com>]

On Jul 29, 4:52 am, Alan Mackenzie <a...@muc.de> wrote:
> Hi,Xah!
>
> On Mon, Jul 28, 2008 at 03:54:35PM -0700,XahLeewrote:
> > > Maybe the only reason some parts of Emacs haven't been updated is
> > > because of missing man power.  Who knows?  Maybe you can start on
> > > those 4 hours of query-replace, then.
> > Thanks for the encouragement. I just might down the road start my own
> > emacs cult... creating a emacs distro that's just my ideal of what
> > functional, BEST efficient, software should be like. I have actually
> > thought about this several times in the past year.
>
> 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 “M-‹key›” notation
to “Alt+‹key›” in emacs manual and menu.

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.

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

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'm not subscribed to their mailing
list. Further, i'm not a experienced elisp coder as most of them are.
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.

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.



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

The issue in this thread here, is whether “Alt+‹key›” notation is
better and should be adapted by emacs. I have given i hope detailed
analysis:

“Emacs's M-‹key› Notation vs Alt+‹key› Notation”
 http://xahlee.org/emacs/modernization_meta_key.html

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

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.

The reason i gave, about why “Alt+‹key›” 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?

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

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.

I mentioned, there's another thing is changing how the shortcut 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 “Alt+” or “Ctrl+” notation. Is this true?

Do you know about this?


> > 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 “Alt+‹key›” is
considered a dumb down? Is it because it's easy to understand?

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


> > When i run my own emacs distro, info doc will be considered
> > supplementary to html/xhtml. HTML will be the primary doc format, with
> > its 1000 times more user base and tools and perhaps 10 times more
> > technically powerful and flexible.
>
> ??? HTML is much less powerful than Info.  Viewing info within Emacs,
> you've got all the power of Emacs, and many useful viewing commands - on
> top of that, info is all text, so it displays instantly, in contrast to
> stuff in a web brower, which takes a noticeable time to render.
>
> In fact, info is so far ahead of html that if some researcher from a
> foreign planet were do descend on Earth and compare the two formats, he'd
> think that html arrived first, then info developed from it.  In fact, it
> was more the other way around.
>
> 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
notation issue please.



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

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


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

In this thread, i suggested making the shortcut notation changes. So,
it shouldn't effect people's exiting customization.


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


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

     =(^_^)=

  Xah
∑ http://xahlee.org/

☄