Re: Emacs Mini Manual (PART 3) - CUSTOMIZING AND EXTENDING EMACS

[Emanuel Berg <embe8573@student.uu.se>]

solidius4747@gmail.com writes:

> The recent GNU Emacs Manual is more than 600 pages
> long:
> http://www.gnu.org/software/emacs/manual/pdf/emacs.pdf
>
> It includes packages like Semantic, EDE, Calc,
> GUD... (I am using these packages myself). That's a
> lot of features. Certainly, users won't need to learn
> of those to be productive.

It depends what packages and what users, and what they
do.

> It's likely that users usually read cover from cover

I think that is very unlikely for the majority of Emacs
users. But it is not a bad idea to do - on the
contrary...

> so they will be distracted by unnecessary stuffs not
> needed at the moment. The exported PDF of part 1 is
> only 43 pages long and part 3 is 83 pages
> long. Certainly mini compared to the actual manual.

I think "mini" is 1-3 pages. But you wrote it, you name
it. of course.

> I also added screencasts to demonstrate what Emacs is
> capable of.

Screencast = screenshot or dump? If so, that's
great. Those are very informative for the trained eye
and there is no coincidence that computer magazines are
always littered with those. In the accursed computer
science world, they don't do that a lot (at all) but
there is actually no one stopping you, so just do it
where it helps. One thing with the computer magazines
though, they tend to include very small screenshots,
often you cannot see. I think screenshots should be
half a page or at least one fourth a page to be truly
telling. Often it doesn't help to litter them with
arrows and boxes. It is better to add this in the
description beneath the image, with "down left" (etc.)
instead of arrows and the like.

> I want to ensure the new users that learning Emacs
> worth their time. I also explicitly stated that the
> official Emacs manual is the next place they should
> look for if they want to get the most of Emacs. My
> manual only provides a starting point.

Yeah, I suppose it isn't wrong to think up some logical
order but in reality I don't think it works that way
most of the time. I don't think people start reading
one thing, completes it, then the next thing at a
somewhat higher level, until they master it. They read
some, experiment some, use the help some, Google some,
...

> MELPA is really useful. It helped me to discover many
> useful packages and ease package management. Before
> that, I added packages as submodules in my .emacs.d
> git repo. I think once users know MELPA, even if they
> do not know what they want, they will explore the
> packages, install and play with it - like I did - and
> discover features not available in other editors; for
> example, Helm, Magit, undo-tree...

If they know how to do that... And you have a good
opportunity to teach them what you know.

> As for searching and filtering packages using the
> package manager, I will add it.

Yeah? :) Cool.

-- 
underground experts united