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

Re: Newsreader: Best of the bunch?



Paul Smith wrote:
>From your various responses you seem to be advocating using a shallow
> set of functionality that is easily translatable across most
> applications, so you can switch to a new one without much effort
> rewiring muscle-memory, etc.  That's the way you like to work, and
> that's fine.

    Actually, no.  I am pointing out that others are saying that a monolithic
application which has replaced the operating system is better than several
smaller specialized applications because of a common set of keys and that the
better alternative is to get rid of the middle man.  Remember, I did point out
I switch editors *several times a day* so "muscle-memory" (bogus, it's true)
doesn't need to be rewired.

>   * beginning/end of file
>   * forward/backward by word
>   * forward/backward by sentence
>   * forward/backward by paragraph

    These don't have a common basis as in many instances one doesn't have a
need for them in all applications.

>   * search forward/backward
>   * search forward/backward again (using the same string)

    Common.

>   * query/replace
>   * query/replace again (using the same strings)

    Not common, not all applications need replacement.

>   * undo (multiple levels)/redo (multiple levels)

    Uncommon, see above.

>   * paste previous cut (that is, not the most recent but the one before
>     that, or the one before _that_, etc.--i.e. a selection list)

    Uncommon, see above.

    The problem is that you're looking at everything as "it can fit in a text
editor" so all text editor fuctions have to be available all the time.  That
simply is not the case.  Hell, email is that way.  Tell me, when do you need
"undo" when *reading* email.  You've changed the message you're reading?  How
and why, exactly?  That web page you're reading, why would you need undo?  How
and why did you change it and for what purpose?

> Emacs has a client/server capability so there's no reason that any
> reasonably configurable mail/news/whatever tool couldn't be set up to
> quickly and seamlessly invoke Emacs to compose messages.

    Why tell me this?  Did I say emacs couldn't be quickly envoked?

> Here's the thing though: I need all of those functions when I'm READING
> mail, too, not just writing it.  It's quite liberating to realize that
> the mail message you're reading is just another buffer, and you can go
> there, search through it, move around, select text, copy several
> selections, go somewhere else, paste them, etc. etc. using the exact
> same commands as you would for any other editing job.

    Yes.  It is quite liberating.  Been doing it for years without Emacs.
That is not unique and is exactly the set of functions I alluded should be
common. But, please, a *replaced* and *undo* while *reading*?!

> Your posts indicate you feel that reading and editing are quite
> unrelated tasks, and so should be handled by different tools and if
> their interfaces are different that's perfectly reasonable.

    No, I am, quite correctly, stating that not all functions are needed at
all times and only very few functions are needed by all.  Furthermore I did
not state reading vs. editing.  I stated different functions.  I am thinking
window control as well.  Remember one poster said that the option to change
windows is the same.  Yeah, anyone with a gui or screen gets that.  But now we
have the problem of what happens when the application has windows?  That has
nothing to do with reading or editing but simple placement of the work.

> And... so?  Are you trying to imply that Emacs users _can't_ do that?

    That's the impression they give whenever I'm faced with them.  They have a
very singular view of the unix world and one which is quite contrary to how
the rest of the unix world perports to operate.

-- 
         Steve C. Lamb         | I'm your priest, I'm your shrink, I'm your
       PGP Key: 8B6E99C5       | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: