Re: Newsreader: Best of the bunch?

From: Paul Smith (psmith_at_nortel.com)
Date: 10/20/05

  • Next message: Joseph H. Fry: "Re: new users" 
    To: debian-user@lists.debian.org
Date: 20 Oct 2005 10:02:16 -0400

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

    Myself, and other people who appreciate Emacs, would rather have a very
    deep, powerful set of functionality and learn to take full advantage of
    it. Yes, it would be harder for me to move to a new application for
    full-time work (although it is, after all, not rocket science to switch
    tools). However, for this precise reason I use a tool which is free
    software, not proprietary, and which has already been in use for 20+
    years and has been ported to more platforms than any of the tools you
    have mentioned on this thread so far. I'm quite confident in saying
    that as long as I want to use it, Emacs will be available to me.
    Therefore the ONLY reason to switch is if something better comes
    along... and if something better comes along it will be WORTH the effort
    of switching, and so I'll make the effort.

    %% Steve Lamb <grey@dmiyu.org> writes:

    > furufuru@ccsr.u-tokyo.ac.jp wrote:

    >> Of course! But, I'm talking about COMMON functions such as
    >> selecting regions of text, copying it to the clipboard, pasting it,

    >> when you search a text, jump to the top of the line, and copy
    >> the line in the mail summary window as when you search, jump,
    >> and copy a part of your source code in a text-editing window.

    > Yes, and handy keys those are. *points to end, home, pgup, pgdn,
    > etc*

    This definition of "common functions" is far too limited. I also
    consider all of the following to be very basic functionality:

      * beginning/end of file
      * forward/backward by word
      * forward/backward by sentence
      * forward/backward by paragraph
      * search forward/backward
      * search forward/backward again (using the same string)
      * query/replace
      * query/replace again (using the same strings)
      * undo (multiple levels)/redo (multiple levels)
      * 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)

    >> Exactly. And that small percentage is what you use most
    >> frequently in your daily life. At least this is true for me.

      sl> Which doesn't imply that one should program everything inside a
      sl> text editor. The proper way would be to provide that
      sl> functionality globally by a controlling program or, failing that,
      sl> community standards.

    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.

    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.

    Sure, it would be great if there were community standards that covered
    editing capabilities in-depth, but in fact the only standards we have
    are very basic: as you say, page up/down, home/end, arrow keys, maybe
    a few others.

    As for a controlling program, things like screen can only get you very
    limited integration. That's not good enough: I want the full power of
    the editor available in ALL areas where it might be useful.

    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. I don't
    agree with that: I think they have far more in common than they are
    different, and I prefer to use the same interface when performing common
    operations.

      sl> In fact when confronted with a lack of options I can make do with
      sl> what is available.

    And... so? Are you trying to imply that Emacs users _can't_ do that?
    There's nothing about using Emacs that makes you incapable of using
    other editors. I daresay most Emacs users do use other editors for some
    tasks (personally I use vi almost exclusively when I'm su'd to root, for
    example).

    However, arguing about what to do when you don't have any choices is a
    pointless conversation on its face. The only interesting conversation
    is what you use when you have options. 

    -- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@nortel.com>           HASMAT--HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
        These are my opinions--Nortel takes no responsibility for them.
-- 
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
  • Next message: Joseph H. Fry: "Re: new users"

    Relevant Pages

    • Re: forth in forth
      ... Since Emacs has everything, it also has bookmarks, which have that ... functionality (and you can use it when reading info with Emacs): ... fashion you have to press a long sequence of keys to achieve the ...
      (comp.lang.forth)
    • Re: Beginning Hobbyist Programmer Question
      ... one can do a great many things within Emacs. ... find KDevelop to be the best tool on Linux. ... What functionality would you really miss? ... Unfortunatly Windows has decided to put the help on ...
      (comp.emacs)
    • Re: IDE for C: KDevelop vs Emacs vs Other
      ... Maybe OE even does it by design, ... not a major motivator for people to move the Emacs. ... Functionality is excellent. ... It is important to remember that GUI and modern application ...
      (comp.os.linux.development.apps)
    • Re: Apple hiring $MS programmers?
      ... from command line (vi and emacs) are rather privitive. ... editing of .txt files as well as basic WYSIWIG editing ... neither does it match the functionality of Emacs for handling ... inappropriate for an application in which plain text editing ...
      (comp.sys.mac.system)
    • RE: Caching a sniffer
      ... most network connected devices they need to have functionality on other ... this is the core functionality of a switch. ... information which resides at the Network layer of the OSI ...
      (Security-Basics)