all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: Learning "my emacs" from the start (was: Generating a listing of all	symbols)
Date: Sun, 20 Apr 2014 11:06:23 +0300	[thread overview]
Message-ID: <83lhv0fmrk.fsf@gnu.org> (raw)
In-Reply-To: <3defe928-5d2e-4d3b-bc26-f595f275f840@googlegroups.com>

> Date: Sat, 19 Apr 2014 13:10:22 -0700 (PDT)
> From: Hans BKK <hansbkk@gmail.com>
> 
> > There's no one right way to learn Emacs.  But, I think the way you're
> > choosing is a lot of work.
> >
> > You can start off using it for everyday editing, that's what I did and
> > what lots of people do.  I expect you've done the tutorial and learned
> > the keybindings, that's very useful.  Then read a bit of the manual
> > and the internet resources occasionally and learn more.
> >
> > You only really need to looks for customizations, enable non-default
> > packages, etc. when you run into a problem or you feel something is
> > inefficient.  Why change the standard behaviour if it's not a problem?
> <snip>
> 
> I am learning customization before ordinary usage in editing very intentionally; emacs' value as a portable lifetime meta-OS dev/org/comms platform is far more important to me than its comparatively trivial role as an editor.

Almost no one uses Emacs as merely an editor.  I think most, if not
all, of those who write in this forum are like you: they use Emacs for
much more than just editing text.  Therefore, the suggestions you get
here is not limited to editing.  You are well advised to take those
suggestions under consideration, even if you don't agree with them
eventually.  Don't dismiss them too quickly: they have a very large
number of combined man-years of experience behind them.

> The whole point to me of bothering with the learning curve [1] of a complex platform like emacs is to create my own highly-customized version, and the keybindings seems (again, to me) to be a logical place to start, ideally before getting sucked into the vanilla-emacs shift-Alt-Ctrl-Super-Meta-Cmd (IMO sorry-but-insane ancient-legacy) default keybindings for routine navigation and editing usage.

There are emulation packages (like cua-mode) that do that for you.  No
need to roll out your own bindings (which might not work well, because
some CUA shortcuts conflict with very important Emacs keybindings,
which you don't want to break).

In any case, the above is exactly in line with what you were advised:
start Emacs in its default configuration, then identify your special
needs that aren't satisfied by that (Emacs by default already supports
several CUA standard keys), then try looking for an optional bundled
package which already does what you want, and only of all of the above
fails, proceed to rolling your own.

> I will of course leave many hundreds of commands alone, especially for the more obscure and complex, less frequently used modes and packages not worth taking the time to customize.

Alas, there's no practical way of discovering which is which.  If you
intended to go over all of the commands provided by Emacs, then that's
impractical, as there are too many of them, even if you restrict
yourself to the default configuration.  IOW, the way you intend to
take is much longer and less efficient than what was suggested to you.

> Ideally my emacs will be keystroke-compatible with the de-facto standard bindings for the most-used editing-basic functions, as followed by most other mainstream editors released in recent decades, so my 5-y.o. kid and grandmother could juat sit down and use it.

Again, if you turn on cua-mode, you will have most, if not all, of
what your kid and grandmother need.  No need to take this philosophy
farther than it needs to go.  As soon as you start talking about
features that are not text editing, there are no de-facto standards
for most keybindings, so you either adopt what Emacs provides, or come
up with yet another incompatible set of bindings.

One significant advantage of using the standard Emacs bindings is that
your muscle memory will still be applicable when you need to work on
someone else's machine, or even explain to someone else how to solve a
problem in their Emacs.  This isn't something to dismiss easily in the
long run.

Happy hacking!



  parent reply	other threads:[~2014-04-20  8:06 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-19 20:10 Learning "my emacs" from the start (was: Generating a listing of all symbols) Hans BKK
2014-04-19 20:57 ` Emanuel Berg
2014-04-20  8:06 ` Eli Zaretskii [this message]
2014-04-20 10:39   ` Learning "my emacs" from the start Thien-Thi Nguyen
2014-04-20 11:04     ` Eli Zaretskii
2014-04-20 14:12       ` Thien-Thi Nguyen
2014-04-20 14:13         ` Eli Zaretskii
2014-04-22  8:47           ` Nicolas Richard
2014-04-22 16:40             ` Eli Zaretskii
2014-04-20 13:00     ` Florian v. Savigny
2014-04-20 13:29       ` Florian v. Savigny
2014-04-20 14:50       ` Thien-Thi Nguyen
2014-04-21  8:26         ` Florian v. Savigny
     [not found]         ` <mailman.19974.1398068777.10748.help-gnu-emacs@gnu.org>
2014-04-21 13:12           ` Hans BKK
     [not found] ` <mailman.19908.1397981214.10748.help-gnu-emacs@gnu.org>
2014-04-20 13:23   ` Learning "my emacs" from the start (was: Generating a listing of all symbols) Rusi
2014-04-20 17:13     ` Bob Proulx
2014-04-20 18:51       ` Eli Zaretskii
     [not found]       ` <mailman.19947.1398019903.10748.help-gnu-emacs@gnu.org>
2014-04-21 14:37         ` Rusi
2014-04-21 19:01           ` Bob Proulx
2014-04-21 20:16             ` Robert Thorpe
2014-04-21 20:22             ` Robert Thorpe
2014-04-21 21:00             ` Eli Zaretskii
     [not found]           ` <mailman.20014.1398106904.10748.help-gnu-emacs@gnu.org>
2014-04-22  1:37             ` Rusi
2014-04-20 17:12 ` Hans BKK
2014-04-20 20:36   ` Robert Thorpe
2014-04-20 20:41   ` Emanuel Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83lhv0fmrk.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.