[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: newbie .emacs proposal
From: |
sen_ml |
Subject: |
Re: newbie .emacs proposal |
Date: |
Sun, 07 Jan 2001 22:12:55 +0900 (JST) |
From: Eli Zaretskii <address@hidden>
Subject: Re: newbie .emacs proposal (was Re: RTFM Was: M-x goto-line binding)
Date: Sun, 7 Jan 2001 09:47:47 +0200 (IST)
> [I redirected this to emacs-devel, since gnu.emacs-bug is not a good
> place for prolonged discussions, which will probably follow.]
ok. it's probably obvious, but i'm not subscribed ;-)
> On Sun, 7 Jan 2001 address@hidden wrote:
>
> > why not provide a "newbie" (for lack of a better term) .emacs file
> > for inexperienced users containing particular settings (w/ good
> > comments)?
>
> Emacs traditionally refrained from distributing eny .emacs files, to
> make a point that customization is a fundamentally personal issue of
> each user.
i agree that customization is a personal issue -- i think this is
particularly true for very detailed settings.
one benefit to providing some .emacs files to choose from is that a
new user can see what kinds of customizations are possible. i'm sure
a fair number of Emacs users have had the "oh, i didn't know you could
do that!" kind of experience a number of times.
i think customize is meant to address this issue a bit, but frankly
speaking, there are so many items to choose from, i think it is likely
to be quite confusing and overwhelming to tell inexperienced users to
use customize to begin w/. [ i have also found the categorizations to
be a bit confusing -- i often end up reading the source ;-) ]
once a user gains experience w/ customizing on their own, it's much
easier to delve into the documentation, read the source, etc.
however, when inexperienced, i think examples and samples can be
helpful in providing users w/ an idea of what is possible and if used
as a starting point over time, users can gain experience customizing.
[ for those who didn't see my original post, i also mentioned the idea
of providing several .emacs files to choose from. ]
imo, an important point is to make certain settings stand out from the
rest. one way to do this is to provide a set of
not-overly-complicated .emacs files -- another way to do this might be
to display portions of customize so that certain settings stand out
compared to the rest. there may be other ways too, but i it seems to
me that good simple .emacs files (w/ comments) could be a good
approach.
> If you don't install such an .emacs anyway, it will be of little use,
> because users will need to find out about it before they could use it.
i'm not sure i understand what you mean here (probably me being dense).
i think it's fair to expect users to go through the tutorial -- if
there is some explanation in the tutorial concerning creating .emacs
files and some samples there (or locations of samples), that would be
helpful for getting new folks started. [ afaict, interacting w/
.emacs files is not currently touched on in the tutorial. ]
> It might be a better idea to have a special command which turns on a
> ``newbie mode'', if there's a place for such a mode.
hmmm, may be.
my gut feeling is to steer users toward getting used to working w/
.emacs files as early as possible. i feel that providing a newbie
mode may not give folks who use it a good way to transition from there
to creating or modifying their own .emacs files.
> > below are some things to consider for a newbie .emacs file.
> >
> > -global-font-lock-mode turned on by default
> >
> > -column-number-mode turned on by default
> >
> > -text-mode turned on by default (in *scratch*?)
> >
> > -a setting to tell Emacs to ask for confirmation when quitting
>
> Why do you think these settings are not good for non-newbies?
i don't. but they are not defaults, right?
i wouldn't want to force that on people who are used to the existing
behavior. but i think they might be good defaults for inexperienced
users.
what is the chance that inexperienced users will find out about them
shortly after they start using Emacs? by placing them in a sample
file, users know that they can turn them off by commenting them out
and they know that the features exist.
another idea is that all of the sample files could actually be
completely commented out (so the sample files have no effect) and new
users could choose to turn things on by uncommenting relevant
portions.
(oops, sorry if i repeated myself a bit)