The Modernization of Emacs

E

Ed

On 19 Juni, 07:14, Harry George
I've used emacs since the 1980's. ....

I've asked this question on an emacs forum and got no response, so I
presume the answer is no, but I see, Harry, that you're a veteran, so
maybe you've seen things few others have.

Have you ever seen an, "Extract method," function for emacs? Whereby
you highlight some lines of code, press a key, and the code is whisked
into its own method, with the appropriate method invocation left in
its place. If you could post a link, that'd be just champion.

..ed
 
L

Lew

Ed said:
On 19 Juni, 07:14, Harry George

I've asked this question on an emacs forum and got no response, so I
presume the answer is no, but I see, Harry, that you're a veteran, so
maybe you've seen things few others have.

Have you ever seen an, "Extract method," function for emacs? Whereby
you highlight some lines of code, press a key, and the code is whisked
into its own method, with the appropriate method invocation left in
its place. If you could post a link, that'd be just champion.

I googled about a bit and came up with
<http://bicyclerepair.sourceforge.net/>
linked from
<http://en.wikipedia.org/wiki/Refactoring>

I also looked at emacs's own "Info" pages and found this tidbit:
`M-x c-beginning-of-defun'
`M-x c-end-of-defun'
Move point to the beginning or end of the current function or
top-level definition. These are found by searching for the least
enclosing braces. (By contrast, `beginning-of-defun' and
`end-of-defun' search for braces in column zero.) If you are
editing code where the opening brace of a function isn't placed in
column zero, you may wish to bind `C-M-a' and `C-M-e' to these
commands. *Note Moving by Defuns::.

`M-a'
Move point to the beginning of the innermost C statement
(`c-beginning-of-statement'). If point is already at the beginning
of a statement, move to the beginning of the preceding statement.
With prefix argument N, move back N - 1 statements.

In comments or in strings which span more than one line, this
command moves by sentences instead of statements.

`M-e'
Move point to the end of the innermost C statement or sentence;
like `M-a' except that it moves in the other direction
(`c-end-of-statement').

You could, and I believe others have, create a macro to encapsulate these
actions with setting the mark and copying the region.

Here is a very promising-looking one that I found for C(**) and Java:
<http://xref-tech.com/speller/main.html>

GWMF.
 
B

Bent C Dalager

Have you ever seen an, "Extract method," function for emacs? Whereby
you highlight some lines of code, press a key, and the code is whisked
into its own method, with the appropriate method invocation left in
its place. If you could post a link, that'd be just champion.

XRefactory has refactorization support for Java that plugs into Emacs,
but unfortunately only up to Java 1.4.

http://www.xref-tech.com/xrefactory-java/main.html

Cheers
Bent D
 
G

Giorgos Keramidas

My favorite killing offence is /* vi:set ts=4: */.

Apparently, we share at least part of that. My own favorite killing
offense is '/* vi:set ts=anything: */' :)
 
G

Giorgos Keramidas

Here are some Frequently Asked Questions about The Modernization of
Emacs.

They are slightly lengthy, so i've separated each item per post. The
whole article can be found at

http://xahlee.org/emacs/modernization.html
------------

Q: The Terminology “buffer†and “keybinding†is good as they are.

A: The terminology “buffer†or “keybindingâ€, are technical terms
having to do with software programing. The term “keybinding†refers to
the association of a keystroke with a command in a technical, software
application programing context. That is to say, a programer “bind†a
keystroke to a command in a software application. The term “bufferâ€
refers to a abstract, temporary area for storing data, in the context
of programing or computer science.

These terms are irrelevant to the users of a software application.

As a user of a text editor, he works with files. The terms “opened
file†or “untitled file†are more appropriate than “bufferâ€.

No they are not. See you may have a real *file* on a disk somewhere,
which is called 'opened file' or even 'untitled file'. Now isn't it
confusing to think in terms of made-up descriptiors, just because the
term 'buffer' seems alien?

Educating the user to avoid confusion in this and other cases of made
up, 'user-friendly' descriptions is not a good enough answer. If you
can educate the user about this sort of fine distinction between files
stored on a disk somewhere and files which are figments of the
imagination of Emacs, then I can educate them about 'buffer' too and be
done with it all.

The main difference is that I get to do it today, without the need for
multi-thousand-line changes in the source and documentation of Emacs and
its thousands of plugins.
 
G

Guest

Have you ever seen an, "Extractmethod," function for emacs? Whereby
you highlight some lines of code, press a key, and the code is whisked
into its ownmethod, with the appropriatemethodinvocation left in
its place. If you could post a link, that'd be just champion.

xrefactory does this. I tried it once. It's a bit pricey , though.
 
B

Bjorn Borud

[Xah Lee <[email protected]>]
|
| ----------------------------------------
| SIMPLE CHANGES

if I were to suggest improvements to Emacs, the things you mention are
probably among the last things I'd even consider. the problem with
Emacs is not really the nomenclature or the keybindings. the problem
is that it needs to do what it already does better.

My frustration with Emacs has mostly been that Emacs-Lisp is a bit too
limiting. It is too slow and the codebase is a bit messy. or at
least it was the last time I tried to do something in Emacs-Lisp a
couple of years ago. it would also be beneficial if there was a more
proper and well-organized standard library for Emacs to make
developing Emacs applications easier.

for programmers, Emacs is a pretty good editor already, but there is a
bit of a threshold for extending Emacs.

-Bjørn
 
B

Bjorn Borud

[Xah Lee <[email protected]>]

to be quite honest, your proposal seems to largely be based on
ignorance.

| A: The terminology ÒbufferÓ or ÒkeybindingÓ, are technical terms
| having to do with software programing. The term ÒkeybindingÓ refers to
| the association of a keystroke with a command in a technical, software
| application programing context. That is to say, a programer ÒbindÓ a
| keystroke to a command in a software application. The term ÒbufferÓ
| refers to a abstract, temporary area for storing data, in the context
| of programing or computer science.

the term "buffer" is used extensively outside the computer science
domain, so it is not a CS only term. in an editor it is actually a
quite sensible name since it abstracts things a bit. for instance a
buffer need not be associated with a file. nor does it make any
assumptions about the way it is displayed (as opposed to "window" or
"tab").

| These terms are irrelevant to the users of a software application.

they are very relevant to me, and I am very much a user of Emacs. and
again, they provide good abstractions.

| As a user of a text editor, he works with files.

learn Emacs before you criticize it. your assumption is wrong. in
emacs you work on _buffers_. buffers often do not have files
associated with them.

| The terms Òopened fileÓ or Òuntitled fileÓ are more appropriate than
| ÒbufferÓ. Since emacs is also used for many things beside reading
| files or writing to files, for example, file management, ftp/sftp,
| shell, email, irc etc., the proper term can be ÒpanelÓ, ÒwindowÓ, or
| Òwork areaÓ.

"panel" and "window" refer to UI-elements. the buffer concept does
not map 1:1 to any of these. substituting "work area" for "buffer"
doesn't seem like a better abstraction. especially not if you see it
in the context of how Emacs relates to buffer contents.

| And, the term Òkeyboard shortcutÓ refers to typing of a key-
| combination to activate a command. It is also more appropriate than
| ÒbindingÓ or ÒkeybindingÓ.

why? if anything the term "shortcut" seems to imply that there is a
primary route to executing the function in question -- which more
often than not isn't the case. "keybinding" is a more precise term.

| Although concepts like ÒbufferÓ and ÒkeybindingÓ are seemingly
| interchangeable with ÒpanelÓ or Òkeyboard shortcutÓ, but their
| contexts set them apart.

they are interchangeable only if you have no idea what you are talking
about. you obviously have not bothered to have a proper look at Emacs
and think these things through properly.

| This is why in all modern software application's user
| documentations, terms like ÒbufferÓ or ÒkeybindingÓ are not to be
| seen but Òwindows, panes, and keyboard shortcutsÓ.

most "modern" editors are built on different premises than Emacs and
many have a far simpler view of the world. extremely few of them even
come close to Emacs in defining what is in practice an operating
environment for applications. it makes sense to refer to "windows"
when in fact you are referring to windows. it doesn't make sense to
call buffers "windows" in Emacs; because they are not.

| The reason emacs uses the technical terminologies throughout is
| because when emacs started in the 1970s, there really isn't any other
| text editors or even software applications.

the abstractions you mention are sensible ones independently of when
they were concieved. just because other people came along later and
used different abstractions, doesn't mean that the ones used in Emacs
are wrong, inferior or inappropriate. if you had bothered to
understand Emacs properly, you would have found that some of the
abstractions used make a lot of sense in an editor.

| Changes in society are always resisted by old timers, but it is also a
| main element behind progress.

I've been in the computer industry long enough to have seen quite a
few cycles of re-invention. each cycle you learn something about
which inventions were good and which were bad. a common thread if you
look at the survival rate of products and ideas is that it isn't
always the best product or idea that wins.

often something new comes along to replace something old. sometimes
it is better than what you had before, but often it is not really
better, just different.

a good example is the web and the applications we implement in terms
of the web. take forums for instance. in a strict technical sense,
web-based forums are inferior to NNTP-based forums. (I am sure you can
make the comparison yourself). yet NNTP-based discussion is not
growing at the same rate as web forums. the net has chosen its
preferred technology, and it wasn't because the web-based discussion
forums were so much more technically refined that the majority chose
them.

for my uses, web forums are a huge step back from NNTP.

| This terminology issue may seem trivial, but its importance lies in
| making emacs palpable to the vast number of people who ever need to
| use a computer to write.

why? Emacs is a tool. if you don't like it: use something else. it
is that simple.

-Bj¿rn
 
B

Bjorn Borud

[Giorgos Keramidas <[email protected]>]
|
| Educating the user to avoid confusion in this and other cases of made
| up, 'user-friendly' descriptions is not a good enough answer.

there are two types of "user friendly". there's "user friendly" and
then there is "beginner friendly" which is often mislabeled. the
latter is more important for applications which are to be used
casually. like utilities you only use once or twice per year -- those
need to be "beginner friendly".

for applications you are likely to use for prolonged periods of time
(like programming, video editing, music production etc), it does not
make sense to optimize for "beginner friendly". at least not at the
cost of making the application less "user friendly".

applications you spend a lot of time using are worth an investment in
learning how to use them. what creates friction in an application you
know reasonably well is when common tasks are fiddly. for instance,
while menus are often good for casual use and lower the initial
threshold for absolute beginners, depending heavily on menu navigation
becomes too fiddly if you are performing a certain task 2-3 times per
minute. it is not _user_ friendly.


Emacs is rather "user friendly", but not very "beginner friendly".
when I was first confronted with it, the sort of text editors I was
used to were Wordstar and derivatives of it. I was rather annoyed
that it didn't do what I expected, so I just used a different editor.

a few years later I bemoaned the fact that Emacs was so hard to use
during a conversation with a friend. he asked me if I had actually
made an effort to learn Emacs, which of course I hadn't. so I figured
I might as well give it a shot.

following the tutorial that comes with Emacs (and which is referred to
in the startup message) I spent a couple of hours one afternoon
learning the basics. already the next day I started using Emacs for
programming. the week after I had progressed to using it as my
newsreader (which I still do to this day) and eventually I started
reading my email in Emacs. perhaps two months after I had sat down to
learn Emacs I wrote my first Emacs extensions in Emacs Lisp. mostly
simple stuff to make common programming tasks easier.

I found Emacs to be user friendly, but in a different sense than the,
IMHO faulty definition, "beginner friendly". Emacs let me, as a user,
do more with less effort and provides a lot less friction than many
other developer tools I've used. at work I use it extensively, and we
have lots of neat extensions that really save a lot of time.

-Bjørn
 
B

Bjorn Borud

[Xah Lee <[email protected]>]
|
| Q: Why should emacs want to be popular and why should emacs change to
| conform the majority?

the majority of whom?

| We don't want emacs to be popular. We want people to adopt emacs,
| not emacs adopting people.

Emacs is a tool. if it doesn't fit you, choose a different tool. if
you need a screwdriver: don't buy a hammer and complain that it is
too heavy and blunt for your uses.

| A: This attitude has plagued unix and computer geekers for decades. In
| the early 1990s (DOS and unix), tech geekers would sneer at graphical
| menus and mouse, with hordes of reasons how pure text interface, the
| command line, and or keyboard operations are sufficient and superior
| than graphical user interface or using a mouse. This seems ridiculous
| today, but such online forum messages are common.

funny. all my UNIX workstations have had graphical user interfaces.
most of them a lot more flexible than the UI you get on Windows. some
of them with graphics hardware that would have been considered
supercomputers not that long ago (like the high-end graphics
subsystems of SGI systems). I even have a UNIX system at home which
was designed in the 80s and served as the main inspiration for both
current Windows versions as well as being the precursor for the
current MacOS interfaces.

your prejudices get the better of you and make you look like an
ignorant hillbilly.

| In software design, occasionally we are tied down with a design
| decision, such that it has a popular vs elegant aspect. For example,
| suppose we are designing a set of keyboard shortcuts for emacs and we
| are faced the question of whether to keep the copy/paste/undo/open etc
| with the conventional C/V/Z/O etc keystrokes. Or, we can choose to
| sacrifice user's familiarity of conventions but obtain a keyboard
| shortcut set that is in some way more consistent, extensible, or
| otherwise technically better.

you do make an excellent job of shooting yourself in the foot.

-Bjørn
 
K

Kaldrenon

Just so everyone's clear:

Nothing he has said makes much sense, if any.

He's talking about advocacy of something unique and powerful by -
making it less unique and powerful-. Not merely catering to the lowest
common denominator, but promoting something as better -by making it
worse-. Who does that?

Imagine that a man invents a vehicle that's far safer and more
maneuverable than any existing vehicle. Imagine that the increased
safety comes from the fact that it has five wheels. How incredibly
stupid would it be for that inventor to then say, "I'm going to
convince people to buy my new vehicle, which is safer thanks to this
fifth wheel. But in order to market it, I'll take the fifth wheel off,
so it's more familiar and comfortable for them."

I'm very, very new to emacs. I used it a little this past year in
college, but I didn't try at all to delve into its features. I'm
starting that process now, and frankly, the thought of it changing -
already- upsets me. I don't feel like the program ought to change in
order to accommodate me. I'm excited about the prospect of mastering
something new and different. The fewer resemblances to the common-
denominator, extra-friendly stuff I've worked with in the past, the
better.

Emacs' uniqueness may hurt its adoption rate, but it still has plenty
of users, who are all perfectly happy with how things are done.

-Andrew
 
D

David Kastrup

Kaldrenon said:
I'm very, very new to emacs. I used it a little this past year in
college, but I didn't try at all to delve into its features. I'm
starting that process now, and frankly, the thought of it changing -
already- upsets me. I don't feel like the program ought to change in
order to accommodate me.

Actually, the "E" in "Emacs" stands for "extensible". Part of the
appeal of Emacs is that you can change it to accommodate you.
I'm excited about the prospect of mastering something new and
different. The fewer resemblances to the common- denominator,
extra-friendly stuff I've worked with in the past, the better.

Emacs' uniqueness may hurt its adoption rate, but it still has
plenty of users, who are all perfectly happy with how things are
done.

Oh, but Emacs is not TeX: it _is_ being developed further. And some
changes are done in order to synchronize Emacs with the "other world"
where the latter has been oversleeping. For example, Emacs 23 will
internally use utf-8/Unicode as its encoding when it has used
emacs-mule up to now, a multibyte code of its own.

In spirit, this will not change Emacs much, yet it will remove
other-world friction and make Emacs more obviously the incarnation of
editing descended into this world.
 
K

Kaldrenon

Actually, the "E" in "Emacs" stands for "extensible". Part of the
appeal of Emacs is that you can change it to accommodate you.

Well put. Perhaps I should have said that I don't feel like the
program ought to change to "accommodate" -everybody-.

I know that Emacs is still being worked on, is still growing and
changing, and also that, because of its extensibility, anyone can
change it as they wish. In fact, if the OP wants Emacs to behave the
way he describes, I'm sure it's doable. But my statement was that the
changes he suggests are things that should not be enforced
universally, because not only is there nothing wrong with the things
he suggests changing, but the idea of enforcing uniform changes is not
entirely in the spirit of Emacs.
 
B

Bjorn Borud

[Kaldrenon <[email protected]>]
| Just so everyone's clear:
|
| Nothing he has said makes much sense, if any.

(it'd be good if you explicitly specify who "he" is since pronouns by
nature are extremely context sensitive, and in this context an
unattentive reader might think you are referring to me. thanks :).

| Emacs' uniqueness may hurt its adoption rate, but it still has plenty
| of users, who are all perfectly happy with how things are done.

I don't see popularity as a goal in itself. I am selfish. I only
care what the software can do for me and I think that this is the only
way to write good software: make something you'd want to use
yourself.

-Bjørn
 
J

Joel J. Adamson

Kaldrenon said:
Well put. Perhaps I should have said that I don't feel like the
program ought to change to "accommodate" -everybody-.

The point is that the responsibility to customize is on the user. All
the developers need to do is continue providing the most customizable
piece of software around. If we place the responsiblity to customize
on the developer, then he develops a piece of software customized for
himself; that wouldn't be Emacs.

Which brings me to another point: as someone already said, you could
fork the code and make all these changes, but then it would be
something else, it would stop being Emacs.

And it would stop being cool.

Joel

--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109

A webpage of interest:
http://www.gnu.org/philosophy/sylvester-response.html
 
T

Twisted

xrefactory does this. I tried it once. It's a bit pricey , though.

Someone is charging money for an emacs addon? Are they nuts? A lot of
people won't touch emacs with a ten foot pole, and emacs is free. How
many would actually pay for something that's useless without emacs?
Especially given the near-certainty that the price is almost pure
profit margin...
 
T

Twisted

The point is that the responsibility to customize is on the user.

Given that in its out-of-the-box configuration it's well-nigh unusable
without a printed-out "cheat sheet" of some kind, of the sort that
were supposed to have died out in the 80s, getting it customized poses
something of a catch-22 for anyone trying to get started using it.
 
T

Twisted

I found Emacs to be user friendly, but in a different sense than the,
IMHO faulty definition, "beginner friendly". Emacs let me, as a user,
do more with less effort and provides a lot less friction than many
other developer tools I've used. at work I use it extensively, and we
have lots of neat extensions that really save a lot of time.

Being beginner-friendly doesn't have to be at the expense of power or
expert-user usability.

On the other hand, being actively beginner-hostile leads to nobody
adopting the tool. Then again, if you don't mind being the last
generation that'll ever use it, then I guess you're okay with that. If
it suits its existing users, the rest of us will just continue to use
something else.

I continue to suspect that there's an ulterior motive for making and
keeping certain software actively beginner-hostile; a certain macho
elitism also seen with light aircraft pilots and commented on at
www.asktog.com (exact URL escapes me; sorry).
 
T

Twisted

Imagine that a man invents a vehicle that's far safer and more
maneuverable than any existing vehicle. Imagine that the increased
safety comes from the fact that it has five wheels. How incredibly
stupid would it be for that inventor to then say, "I'm going to
convince people to buy my new vehicle, which is safer thanks to this
fifth wheel. But in order to market it, I'll take the fifth wheel off,
so it's more familiar and comfortable for them."

Imagine that a man invents a vehicle that's far safer and more
maneuverable than any existing vehicle. Imagine that the increased
safety comes from the fact that it has five wheels. Gratuitously, he
also has his own peculiar ideas regarding how one should control this
vehicle, and instead of giving it a normal car steering wheel, brake,
and gas pedal, he gives it two stick-like left and right throttle
controls, which can be pulled back to brake and even reverse the car,
pushed forwards to accelerate it, and positioned differently to cause
the vehicle to rotate -- even to rotate in place, obviating the need
for three-point turns and simplifying parallel parking somewhat.

Unfortunately, nobody used to a normal car is remotely comfortable
with these controls. They have a very steep learning curve and
numerous accidents result. It turns out there's even a conversion kit
available for replacing them with a normal steering wheel, brake, and
gas pedal, but getting the conversion kit without crashing on the way
to where you get it proves problematic because of the same unusual
controls you're trying to replace. All of the driving schools, of
course, teach the usual wheel-and-pedals method of controlling a motor
vehicle...

This seems to be a closer analogy with emacs versus normal Windows
text editors. Arguably even the weird controls are superior in some
way -- but only if you got used to them, which will never happen
because you'll abandon it for inability to be productive with it long
before that can happen, and also because the same clunky controls
hobble your access to the online help that would otherwise smooth the
path for you. The same problem plagues attempts to reconfigure the
controls to something more normal. And the computer-driving schools --
computer classes in ordinary school -- teach standard Windows UI
conventions (or their Macintosh equivalents, which correspond closely
to one another). If there is any formal training in emacs use, it's
effectively unobtainable due to obscurity and hard-to-findness,
geographical distance, expense, or even more than one of those
factors.

The above applies equally to vi and its derivatives, if not more so --
vi is like taking that same already-wacky car with the two separate
throttles and adding, in a fit of quaint nostalgia, the need to
actually crank-start its engine. ;)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top