* Johann Oskarsson <Johann> writes:
> I think I'll take the time to write a bit on usability, becouse the
> term "user friendly" is highly misunderstood. I think we can safely
> blame Microsoft for that.
I think we can safely blame M$ for a lot of things.
> The term "user friendly" is supposed to mean "an interface on a
> device, for use by humans, that makes it's usage easy" and that's
> the definition I use.
Me too, except that I tack on a "and/or intuitive for those few humans
that possess common sense".
> For emacs, it means "text editing expert friendly".
I don't totally agree with that, but in the light of not being able to
come up with something better right now, I'll go along with it (for
the time being).
> Yes, the learnign curve for emacs is steep, but once there, it's
> quite intuitive.
Agree.
> I've been able to guess behaviour many people on #emacs are (or
> were) quite unaware of. (I'm talking about C-u M-x unload-feature
> vs. M-x unload-feature -- yes, I correctly *guessed* the meaning
> of C-u before I even read the docs)
Thats terrific! Except for one thing... I've looked at the doc string
for `unload-feature' and I've looked at the code for `unload-feature'
(I was curious because I've never heard of using C-u on it)... and it
_doesn't_ use a prefix arg anywhere. So doing C-u M-x unload-feature
would be no different from M-x unload-feature.
But!
I consider that a bug. There is no way to invoke unload-feature
interactively (via M-x) and use the FORCE argument. (think I'll send
the XE folks a patch)
> But there are still many "usability issues" to fix. And I think
> most of them fall under "can (sx)emacs do X without writing lisp?"
Without the _user_ needing to write lisp, correct? In other words,
we'd just write it for them. We might want to keep an eye on bloat
here.
> Not all users know or care to learn lisp -- I didn't until I
> needed my window number mode. Until I made it, more experienced
> lispers didn't think it could be done.
Or didn't think it was all that useful, or didn't think you were going
about it the right way.[1]
> M-x customize helps, but it goes only so far.
The custom interface is a big fat hairy ugly hack. It works for most
things most of the time, but as you say, it only goes _so_ far. IMO
we should come up with something better.
> There are lots of issues that makes emacs slow and sometimes
> bloaty, we need to find these defects, order them (imo) according
> to "usability severity" and fix them in that order.
Good. I like it.
> One such issue is the lack of features to enable gnus (or any
> other mail reader) to create efficient mbox handler. There is no
> need to keep the entire mbox in memory,
And this is one of the reasons we have the nnml backend.
> the lack of low-level file handling in elisp.
Yes, this would be good to address.
> There's more I wanted to say, but I'll leave it to later. I mean
> this as a draft for an article to appear on the website soon next
> year.
Good stuff!
> There was some stuff I want to respond to Steve's comments but I'll
> leave that to later too. So *snip* ;)
aww, I feel all dejected now. :-(
:-P
Footnotes:
[1] Some of me still doesn't. :-P
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| In space, |
| No one can hear you rip a stinky |
|------------------------------------<steve@xxxxxxxxxxx>---|
pgpNdiKqj8YbI.pgp
Description: PGP signature
|