a look at the browser scene & emacs

a look at the browser scene & emacs

[Xah Lee]

News about the browser world
http://www.macworld.com/article/139022/2009/02/safari4firstlook.html?t=232

emacs really needs to keep up.

The IDE idea, from 1990s to 2000, basically reduced emacs market share
from perhaps more than 50% in the early 1990s to maybe 1% today among
professional programers.

emacs today has lots of problems. Many of the “emacs way”, are
technically inferior. But the nice elisp system holds it back still.

The way for emacs to advance, is to get more people to use emacs.
Emacs users today are already just the very small clique, half of
which are perhaps over 40. With these small circle of people, every
idea that's not “emacs way” gets stamped out.

Emacs 22 took a few major step, by having syntax highlighting on by
default, and CUA mode as a option. Emacs 23 took it further, by having
cursor move by visual line, and have highlight selection on by
default. I presume that in emacs 24 might have CUA mode on by
default... but these changes are happening quite late.

The emacs on the mac, in particular Aquamac emacs and Carbon emacs,
did significant job in saving emacs from oblivion. There are a lot
needs to be done, especially on the Windows platform because it is
used by most people.

• The Modernization of Emacs
  http://xahlee.org/emacs/modernization.html

  Xah
∑ http://xahlee.org/

☄

Re: a look at the browser scene & emacs

[David Kastrup]

Xah Lee <xahlee@gmail.com> writes:

> News about the browser world
> http://www.macworld.com/article/139022/2009/02/safari4firstlook.html?t=232
>
> emacs really needs to keep up.
>
> The IDE idea, from 1990s to 2000, basically reduced emacs market share
> from perhaps more than 50% in the early 1990s to maybe 1% today among
> professional programers.
>
> emacs today has lots of problems. Many of the “emacs way”, are
> technically inferior. But the nice elisp system holds it back still.
>
> The way for emacs to advance, is to get more people to use emacs.
> Emacs users today are already just the very small clique, half of
> which are perhaps over 40. With these small circle of people, every
> idea that's not “emacs way” gets stamped out.

Or gets adapted to the Emacs way.  The result is that people get one
consistent tool.

> Emacs 22 took a few major step, by having syntax highlighting on by
> default, and CUA mode as a option. Emacs 23 took it further,

Emacs 23 is not yet finished.

> by having cursor move by visual line, and have highlight selection on
> by default. I presume that in emacs 24 might have CUA mode on by
> default...

It quite certainly won't.

> but these changes are happening quite late.

> The emacs on the mac, in particular Aquamac emacs and Carbon emacs,
> did significant job in saving emacs from oblivion.

I disagree.  That's something only a Mac-centric person could say.  The
cross-platform upstream code foldback has been minimal.

> There are a lot needs to be done, especially on the Windows platform
> because it is used by most people.

Platform-specific additions are a dead end since they tend to be
single-person efforts that die out once the person can't be interested
anymore.

-- 
David Kastrup

Re: a look at the browser scene & emacs

[Xiao-Yong Jin]

David Kastrup <dak@gnu.org> writes:

> Xah Lee <xahlee@gmail.com> writes:
>
>> News about the browser world
>> http://www.macworld.com/article/139022/2009/02/safari4firstlook.html?t=232
>>
>> emacs really needs to keep up.
>>
>> The IDE idea, from 1990s to 2000, basically reduced emacs market share
>> from perhaps more than 50% in the early 1990s to maybe 1% today among
>> professional programers.
>>
>> emacs today has lots of problems. Many of the “emacs way”, are
>> technically inferior. But the nice elisp system holds it back still.
>>
>> The way for emacs to advance, is to get more people to use emacs.
>> Emacs users today are already just the very small clique, half of
>> which are perhaps over 40. With these small circle of people, every
>> idea that's not “emacs way” gets stamped out.
>
> Or gets adapted to the Emacs way.  The result is that people get one
> consistent tool.

As a under 40 user, I very much like the idea of being
consistent.  I don't like CUA mode and the new default
transient mark mode behavior.  But I do like the idea of
improving the display back-end of Emacs.  I love the
upcoming version 23 because of the anti-aliased font support
and much better handling of multibyte character encoding
system.

Nowadays, there are usually only three kinds of program on
my desktop.

    a. Emacs
    b. urxvt
    c. firefox

All sorts of shell modes in Emacs are slow compared to
urxvt.  And all web browsing modes are just lame.  I do most
of my work in Emacs, but external term and browser is
indispensable, as for now.  I would very much like to see
the ideal society where people only fire up Emacs and do all
sort of things in the good old Emacs way.  An efficient,
functional and versatile display back-end is what Emacs is
really lack of.  This might be what Emacs can learn from
webkit or XUL.


Xiao-Yong
-- 
    c/*    __o/*
    <\     * (__
    */\      <

Re: a look at the browser scene & emacs

[Samuel Wales]

On Wed, Feb 25, 2009 at 06:13, Xiao-Yong Jin <xj2106@columbia.edu> wrote:
> All sorts of shell modes in Emacs are slow compared to
> urxvt.  And all web browsing modes are just lame.  I do

Did you try cvs emacs-w3m?

-- 
Myalgic encephalomyelitis denialism is causing death (decades early;
Jason et al. 2006) and severe suffering, pain, and disability (worse
than nearly all other serious diseases studied; Schweitzer et al.
1995) and grossly corrupting science.  *Anybody* can get the disease.
No serious scientist doubts its reality and severity.
http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm

Re: a look at the browser scene & emacs

[Xiao-Yong Jin]

Samuel Wales <samologist@gmail.com> writes:

> On Wed, Feb 25, 2009 at 06:13, Xiao-Yong Jin <xj2106@columbia.edu> wrote:
>> All sorts of shell modes in Emacs are slow compared to
>> urxvt.  And all web browsing modes are just lame.  I do
>
> Did you try cvs emacs-w3m?

Indeed, I did.  And I do use it some times.  It is also the
only thing that can save me in such situations when people
send me crazy formatted emails.  But I guess I don't have
to say too much about it.  Without better display/rendering
engine in Emacs, it can never be compared with any of the
modern web browsers, even can't catch up with links[1] in
graphic mode.

[1] http://links.twibright.com/

Alright, I don't want to start a flame war.  I'm just a
normal user who doesn't have time and energy to contribute
to the Emacs community.  All I can do is writing down a few
sentences and hoping some nice devs who have time and energy
might take a look at it and say, `Geez, it's a good idea and
I can do it.'

That said, Emacs is still my favourite.
-- 
    c/*    __o/*
    <\     * (__
    */\      <

Re: a look at the browser scene & emacs

[Richard Riley]

Xiao-Yong Jin <xj2106@columbia.edu> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Xah Lee <xahlee@gmail.com> writes:
>>
>>> News about the browser world
>>> http://www.macworld.com/article/139022/2009/02/safari4firstlook.html?t=232
>>>
>>> emacs really needs to keep up.
>>>
>>> The IDE idea, from 1990s to 2000, basically reduced emacs market share
>>> from perhaps more than 50% in the early 1990s to maybe 1% today among
>>> professional programers.
>>>
>>> emacs today has lots of problems. Many of the “emacs way”, are
>>> technically inferior. But the nice elisp system holds it back still.
>>>
>>> The way for emacs to advance, is to get more people to use emacs.
>>> Emacs users today are already just the very small clique, half of
>>> which are perhaps over 40. With these small circle of people, every
>>> idea that's not “emacs way” gets stamped out.
>>
>> Or gets adapted to the Emacs way.  The result is that people get one
>> consistent tool.
>
> As a under 40 user, I very much like the idea of being
> consistent.  I don't like CUA mode and the new default
> transient mark mode behavior.  But I do like the idea of
> improving the display back-end of Emacs.  I love the
> upcoming version 23 because of the anti-aliased font support
> and much better handling of multibyte character encoding
> system.
>
> Nowadays, there are usually only three kinds of program on
> my desktop.
>
>     a. Emacs
>     b. urxvt
>     c. firefox
>
> All sorts of shell modes in Emacs are slow compared to
> urxvt.  And all web browsing modes are just lame.  I do most
> of my work in Emacs, but external term and browser is
> indispensable, as for now.  I would very much like to see
> the ideal society where people only fire up Emacs and do all
> sort of things in the good old Emacs way.  An efficient,

Yes, many people would. But the fact of the matter is more and more
"modern" users come to Emacs and shirk away because like it or not times
have changed since VTxxx. Let experts default it back to the stone age
and let new users see immediately that emacs does have transient marker
mode and CUA. (while on a CUA fan myself, I can not think of any time I
would want to NOT see the marked region as I create it).


> functional and versatile display back-end is what Emacs is
> really lack of.  This might be what Emacs can learn from
> webkit or XUL.
>
>
> Xiao-Yong

-- 
 important and urgent problems of the technology of today are no longer the satisfactions of the primary needs or of archetypal wishes, but the reparation of the evils and damages by the technology of yesterday.  ~Dennis Gabor, Innovations:  Scientific, Technological and Social, 1970

Re: a look at the browser scene & emacs

[Miles Bader]

Richard Riley <rileyrgdev@gmail.com> writes:
> Yes, many people would. But the fact of the matter is more and more
> "modern" users come to Emacs and shirk away because like it or not times
> have changed since VTxxx.

Surely emacs is moving in this direction -- but is also being careful to
keep in mind the large existing emacs user community.

There is ample room for people to discuss this evolution, but approaches
that start with "first, toss out the existing user interface" aren't gonna fly.
Emacs isn't going to turn into a fancy notepad clone, regardless of what
"modern" users may (think they) want...

-Miles

-- 
Joy, n. An emotion variously excited, but in its highest degree arising from
the contemplation of grief in another.

Re: a look at the browser scene & emacs

[Xah Lee]

On Feb 26, 12:57 am, Miles Bader <mi...@gnu.org> wrote:
> There is ample room for people to discuss this evolution, but approaches
> that start with "first, toss out the existing user interface" aren't gonna fly.

Who said to toss out existing user interface, you?

Are you saying that i start my suggestion with “throw out existing
UI”? If so, please point out where.

> Emacs isn't going to turn into a fancy notepad clone, regardless of what
> "modern" users may (think they) want...

In what way you imagine emacs is going to be a fancy Microsoft Notepad
clone?

I've wrote the following suggestions on emacs modernization in the
past 3 years:

• The Modernization of Emacs
  http://xahlee.org/emacs/modernization.html

• Suggestions on Emacs's Scratch Buffer
  http://xahlee.org/emacs/modernization_scratch_buffer.html

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

• Emacs's Menu Usability Problem
  http://xahlee.org/emacs/modernization_menu.html

• Emacs's Mode Line Modernization Suggestions
  http://xahlee.org/emacs/modernization_mode_line.html

• Usability Problems With Emacs's Letter-Case Commands
  http://xahlee.org/emacs/modernization_upcase-word.html

• Suggestions on Emacs's mark-word Command
  http://xahlee.org/emacs/modernization_mark-word.html

• Suggestions on Emacs's Line-Cutting Commands
  http://xahlee.org/emacs/modernization_fill-paragraph.html

• Emacs Should Adopt HTML To Replace Texinfo
  http://xahlee.org/emacs/modernization_html_vs_info.html

• Emacs Should Support HTML Mail
  http://xahlee.org/emacs/modernization_html_mail.html

• Emacs's HTML Mode Sucks
  http://xahlee.org/emacs/emacs_html_sucks.html

which item, in which article, do you think that emacs is going to turn
into Notepad clone?

is the suggestion of using modern standard shortcut set of X C V for
Cut, Copy, Paste, of which Linux uses, means it is turning emacs to a
fancy Notepad clone?

Is fixing emacs's confusing undo and no redo, that is periodically
bitched by programer in blogs, considered making emacs into a Notepad
clone?

Is the suggestion for a statistics based ergonomic keybinding design
that are more faster to execute, easier on the fingers, and easier to
remember, mean it is turning emacs to a fancy notepad clone?

is the suggestion of getting rid of *scratch* buffer, and introduce a
command “New” with shortcut Ctrl+n, that creates new buffer anytime
anywhere, which lets user create multiple scratch buffers defaulting
to any mode and compatible for the rest of Linux's shortcuts, means it
is a fancy Microsoft Notepad?

is the suggestion of changing notation from C- and M- to Ctrl+ and Alt
+, such that it reflects the lable on the keyboard, and Richard
Stallman agrees may be a good idea, means it's Notepad?

is the suggestion of supporting html mail, and interface to gmail out
of the box, means it's becoming Microsoft Notepad?

is it simply the fact that making things easier to use, means kissing
Microsoft's ass?

Is the open source Firefox, and Google's extremely advanced
technologies and easy to use applications such as gmail, google map,
google earth, google code, all becoming Microsoft Notepad clone?

  Xah
∑ http://xahlee.org/

☄

Re: a look at the browser scene & emacs

[Tassilo Horn]

Xah Lee <xahlee@gmail.com> writes:

Hi Xah,

> is the suggestion of using modern standard shortcut set of X C V for
> Cut, Copy, Paste, of which Linux uses, means it is turning emacs to a
> fancy Notepad clone?

The functionality stays the same, but IMO it would confuse most users.
Killing is not cutting, yanking is not pasting.  The whole concepts
(kill-ring vs. simple copy&paste) are much different.

> Is fixing emacs's confusing undo and no redo, that is periodically
> bitched by programer in blogs, considered making emacs into a Notepad
> clone?

It's much more advanced than the usual sequential undo, but I admit that
it can get confusing sometimes.  So instead of dropping it I'd prefer to
think about a better UI for it.

> Is the suggestion for a statistics based ergonomic keybinding design
> that are more faster to execute, easier on the fingers, and easier to
> remember, mean it is turning emacs to a fancy notepad clone?

Users use different commands and your bindings may be better for you on
your querty keyboard, but I'm sure they're not on my German Dvorak Type
II keyboard.

> is the suggestion of getting rid of *scratch* buffer, and introduce a
> command “New” with shortcut Ctrl+n, that creates new buffer anytime
> anywhere, which lets user create multiple scratch buffers defaulting
> to any mode and compatible for the rest of Linux's shortcuts, means it
> is a fancy Microsoft Notepad?

Such a easy key like C-n is much too valuable for such a rarely used
command.  C-x b foobar RET is ok, isn't it?

> is the suggestion of changing notation from C- and M- to Ctrl+ and Alt
> +, such that it reflects the lable on the keyboard, and Richard
> Stallman agrees may be a good idea, means it's Notepad?

Nope, but I'm not sure if it's possible for emacs to get the right key.
Here, M is Alt, but Ctrl is indeed on the CapsLock key...

And it makes key sequences much longer to write with little or no
benefit.

> is the suggestion of supporting html mail, and interface to gmail out
> of the box, means it's becoming Microsoft Notepad?

Definitively not.  AFAIK Gnus can handle gmail accounts quite well.
Reading HTML mail works nice, too (with emacs-w3m as helper).  A simple
editor would be nice for some people, too.  But I guess that most
current devs arent interested in writing one, cause in "the tech
geekers" world mail is in text/plain.

Bye,
Tassilo

Re: a look at the browser scene & emacs

[Tassilo Horn]

Klaus Straubinger <KSNetz@UseNet.ArcorNews.DE> writes:

Hi Klaus,

>> Reading HTML mail works nice, too (with emacs-w3m as helper).  A
>> simple editor would be nice for some people, too.  But I guess that
>> most current devs arent interested in writing one, cause in "the tech
>> geekers" world mail is in text/plain.
>
> In Emacs, there is Enriched Mode if you want formatted text. The info
> file says
>
> | "Enriched mode" is a minor mode for editing files that contain
> | formatted text in WYSIWYG fashion, as in a word processor.  Currently,
> | formatted text in Enriched mode can specify fonts, colors, underlining,
> | margins, and types of filling and justification.  In the future, we plan
> | to implement other formatting features as well.
> |
> | Enriched mode is a minor mode.  It is typically used in conjunction
> | with Text mode, but you can also use it with other major modes such
> | as Outline mode and Paragraph-Indent Text mode.
> |
> | Potentially, Emacs can store formatted text files in various file
> | formats.  Currently, only one format is implemented: "text/enriched"
> | format, which is defined by the MIME protocol.
>
> One could write a converter to HTML if another format is desired.

Yes, nice.  I guess that would be possible without too much effort.  So
Xah, why not do it yourself?

Bye,
Tassilo
-- 
Vendor lock-in is when vendors  lock themselves inside of a building out
of fear of Richard Stallman's wrath.

Re: a look at the browser scene & emacs

[Colin S. Miller]

Xah Lee wrote:

(unnecessary usenet groups removed)

> Is fixing emacs's confusing undo and no redo, that is periodically
> bitched by programer in blogs, considered making emacs into a Notepad
> clone?
> 

Xah,

(require 'redo)
(global-set-key '(control meta -) 'redo)

will make Emacs's redo behave like most other editors.

HTH,
Colin S. Miller

Re: a look at the browser scene & emacs

[Samuel Wales]

On Sat, Feb 28, 2009 at 08:48, Colin S. Miller
<no-spam-thank-you@csmiller.demon.co.uk> wrote:
> (require 'redo)
> (global-set-key '(control meta -) 'redo)
>
> will make Emacs's redo behave like most other editors.

The behavior of redo is indeed an improvement -- it provides the
needed functionality -- but that  package corrupts the buffer.

If that bug were fixed in both emacs and xemacs, I think that there
would be no complaints about undo at all.

(Oh, some people might suggest branching or viewing the history or a
different type of bunching or something, but the lack of a true redo
(as opposed to undoing the undo) is IMO among the biggest usability
issues in all of emacs-dom.)

-- 
Myalgic encephalomyelitis denialism is causing death (decades early;
Jason et al. 2006) and severe suffering, pain, and disability (worse
than nearly all other serious diseases studied; Schweitzer et al.
1995) and grossly corrupting science.  The denialism is worse than it
ever was with even AIDS or MS.
http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm

Re: a look at the browser scene & emacs

[Xah Lee]

On Feb 25, 5:13 am, Xiao-Yong Jin <xj2...@columbia.edu> wrote:
> the good old Emacs way

Let me give some examples of how many of the emacs's ways are
technically inferior. Some, to a degree that's outright stupid. The
reason, most emacs users, didn't see this, because over all emacs is
above all others, especially in the 1990s, and with that developed a
emacs cult. So, the perception becomes black & white, namely: emacs
way, or stupid way.

here's some example of emacs that are technically inferior.

-------------

• Why Emacs's Keyboard Shortcuts Are Painful
  http://xahlee.org/emacs/emacs_kb_shortcuts_pain.html

Excerpt:

See also, a newsgroup post on “comp.emacs”. “Re: effective
emacs” (2008-06-01) by Daniel Weinreb. http://groups.google.com/group/comp.emacs/msg/0342e0bc1aa05c0d.

    Xah wrote:
    «Emacs's default cursor moving shortcuts are “Ctrl+f”, “Ctrl+b”,
“Ctrl
    +n”, “Ctrl+p”. The keys f, b, n, p are scattered around the
keyboard
    and are not under the home row.»

    Daniel wrote:
    That's true.  At the time Guy Steele put together the Emacs
default
    key mappings, many people in the target user community (about 20
    people at MIT!) were already using these key bindings.  It would
    have been hard to get the new Emacs bindings accepted by the
    community if they differed for such basic commands.  As you point
    out, anyone using Emacs can very easily change this based on
    their own ergonomic preferences.

Daniel is supposed to be the oldest emacs user.

-------------------

• The Modernization of Emacs
  http://xahlee.org/emacs/modernization.html

Excerpt:

«
Emacs's ways are technically superior. It should not change.

Emac's user interface, when compared to modern software application's
user interface, is complex and unusual, however, there's no basis
whatsoever of it being actually a superior design with regards to any
sensible metrics. (in fact, much of emacs's user interface are due to
historical reasons. That is, how computers are in 1980s.)

For example, let's consider emacs's system of keyboard shortcuts. For
a keyboard shortcut system, we might judge its quality based on
several aspects. Here are some examples of consideration:

    * Is it easy to learn? (is it familiar to most people? Is it easy
to remember?)
    * Is it ergonomic? (Are most frequently used commands's keyboard
shortcuts easy to type? Are more frequently used commands have easier
to type shortcuts than less frequently used commands?)
    * Are most frequently used commands all have a keyboard shortcut?
    * Is the shortcut system somehow consistent and extensible?

Emacs's keyboard shortcuts system, is good only with respect to the
last item. Emacs keyboard shortcuts are perhaps one of the most
difficult to learn among software, and is also one of the most
difficult to remember. The worst aspect of emacs's keyboard shortcuts,
is that it is ergonomically painful. (Many emacs-using programer
celebrities have injured their hands with emacs. (e.g. Richard
Stallman, Jamie Zawinski, Ben Wing), and emacs's Ctrl and Meta
combinations are most cited as the major turn-off to potential users
among programers)

Computer keyboard is a hardware interface, and the mapping of commands
to the key press combinations can be considered from a Operation
Research (ergonomic) point of view. The keyboard hardware itself can
be designed with consideration of ergonomics (that's why we have split
and curved keyboards), but consideration of what functions to map to
what key presses is also non-trivial if the software has large number
of functions, or if the software is mission critical, or the software
is used for repetitive, long durations of human-machine interaction
(such as data-entry, programing, writing). Think of it this way:
consider a airplane cockpit, filled with knobs, dials, buttons, and
switches. Now, if your job is to map the airplane control functions to
these switches, what are the issues to consider?

If we take careful consideration on creating a keyboard shortcut
system for emacs, it is not difficult to create a system that is
superior in some pure technical sense than the emacs's shortcut
system.

For some detail, see: Why Emacs's Keyboard Shortcuts Are Painful.

Aside from keyboard shortcuts system, other user interface aspects of
emacs are also questionable. For example, one major aspect of emacs
operation is that it uses a single window for multiple purposes and
files. Emacs is this way not because of a design decision, but rather
due to historical reasons. Computer resources in the 1980s are very
limited. When emacs is around, graphical system of showing “windows”
is not practically available, and the emacs's method of using the
screen (the monochrome text-only monitor) for presenting multiple
tasks (“buffers”) is actually a very advanced user interface design
not available in software of that era. When graphical systems becomes
practical in the 1990s, drawing a window still takes a lot memory, and
opening multiple windows is slow and impractical.

Modern software interface (say, post 2000) usually uses one window per
file (or task), and or show tabs if multiple tasks are represented in
a single window. However, emacs's buffer system doesn't provide the
tabs visual clue. Compared to the modern standard of tabbed window,
emacs's buffer interface is inferior because it is less intuitive.
Arguably, emacs's operation methods may be more efficient for expert
users. 20 years ago, efficiency for expert users may out weight the
ease of use for majority of average users. But in today computing era,
computers are standard tools in every household, efficiency and ease
of use for general users is as important for professional users. Even
for professional users, it is openly questionable that emacs's ways of
operation induced by its default user interface allows more efficient
operation than a user interface based on modern software conventions.
(this can be tested by having 2 team of programmers roughly equally
experienced or skilled in using emacs. One team use Emacs with default
UI setup, the other use a emacs with modernized interface (such as
Mac's Aquamacs), then compare their efficiency in finishing a set of
coding tasks.)
»

----------------------------

the emacs cult induced black & white mentality is harmful. When in
online discussion, whenever some aspect of emacs is criticized that is
unique to emacs, the emacs users just see “Emacs Way” vs “Microsoft
way”, and therefore they think the only way is emacs way. It needn't
be that way. Certainly the emacs's system is great and made it last
over about 3 decades, but many aspects can adopt modern UI for the
better, while not taking away any advantage of emacs.

over the past 3 years i've spent a lot time on this and written a lot
detailed account. One latest one is about emacs's menus. See:

• Emacs's Menu Usability Problem
  http://xahlee.org/emacs/modernization_menu.html

This is about emacs's menu. You'll see that it is full of usability
problems. PS on this i sent to emacs bug report. So far no response.

  Xah
∑ http://xahlee.org/

☄