unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "David House" <dmhouse@gmail.com>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: emacs-devel@gnu.org
Subject: Re: guided tour suggestions
Date: Sun, 3 Jun 2007 16:32:15 +0100	[thread overview]
Message-ID: <ebe43d680706030832h33cee756h5632d5e671c723ea@mail.gmail.com> (raw)
In-Reply-To: <EIENLHALHGIMHGDOLMIMCEAEDCAA.drew.adams@oracle.com>

On 02/06/07, Drew Adams <drew.adams@oracle.com> wrote:
> * There could be a *grep* or *compilation* screenshot, perhaps showing
> another window with found source code.

We could do the traditional IDE screenshot with grep, compilation,
speedbar and so on buffers open.

> * There could be a screenshot showing incremental search. It should be
> repeated in the search section.

I agree. Incremental search is both one of Emacs's most useful and
most GUI-heavy features, I'd love to see screenshots for both
incremental search and query-replace.

> * I would lose the tetris screenshot. If the point is to show that Emacs has
> play activities too, I'd skip this shot. Compared to play things available
> elsewhere, this is not very convincing. Better to show a good conversation
> with the shrink. I'd skip this stuff altogether, personally.

Keeping a screenshot for something like tetris, blackbox or doctor
would be nice in terms of keeping a more lightweight feel to the
article. They also give the impression that Emacs really does have
everything. I vote for keeping them.

> * Put the hexl screenshot last, if at all.

Agreed. Who uses hexl more than, say, dired?

> I agree. In fact, I vote for turning on delete-selection-mode by default.

Yes, me too.

> I'm not sure what I think about the presentation of Undo. It is generally
> clear, but it looks a bit intimidating because of the diagrams. If we keep
> the diagrams, perhaps add a diagram showing Emacs undo that corresponds to
> the first two diagrams. We don't see Emacs undo until the discussion of
> accessing the past after performing a non-undo/redo action. That is, we only
> see an Emacs undo chain that corresponds to the 3rd diagram.

I really found these diagrams helpful. Emacs does have a rather funky
undo policy with respect to the rest of the editors on this planet,
and it's worth explaining to avoid confusion. It's also a nice example
of how Emacs does things differently to be more powerful.

> What feature is not useful? "Useful features" even includes
> phases-of-the-moon, which is hardly an example of "Integration with common
> tools". No need to mention such stuff, IMO; users will appreciate it more
> when they find it, as an "extra" (a la easter egg).

Again, I'd like to keep this in, for the sake of humour and to give
the impression that Emacs has everything you'd ever want, and then
some.

> We might mention more about Emacs's features for editing code. Things such
> as indentation that we take for granted, for instance.

Agreed. Emacs should be pushed primarily as a coding platform.

-- 
-David House, dmhouse@gmail.com

  parent reply	other threads:[~2007-06-03 15:32 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-03 18:03 guided tour suggestions Karl Berry
2007-05-03 20:34 ` Phil Sung
2007-06-02 20:52   ` Chong Yidong
2007-06-02 21:04     ` David Kastrup
2007-06-02 22:08     ` Drew Adams
2007-06-03  8:23       ` Mathias Dahl
2007-06-03 15:32       ` David House [this message]
2007-06-11 20:01     ` Phil Sung
2007-06-11 20:19       ` Drew Adams
2007-06-27  1:16         ` Phil Sung
2007-06-27  4:28           ` Drew Adams
2007-06-27  5:45           ` David Kastrup
2007-06-27  6:04             ` Nick Roberts
2007-06-27  7:37               ` David Kastrup
2007-06-28  7:02             ` Phil Sung
2007-06-28  7:20               ` David Kastrup
2007-06-28  9:54                 ` David House
2007-06-28 10:25                   ` David Kastrup
2007-08-09  7:15                 ` Phil Sung
2007-08-09  7:36                   ` David Kastrup
2007-08-13  8:09                     ` Phil Sung
2007-06-28  8:20               ` Nick Roberts
2007-06-28  8:36                 ` David Kastrup
2007-06-29 16:41               ` Juri Linkov
2007-06-30  1:16               ` Nick Roberts
2007-06-30 10:03                 ` David House
2007-07-22 10:59                   ` Dieter Wilhelm
2007-05-03 22:30 ` David Koppelman
2007-05-03 22:41   ` Daniel Brockman
2007-05-04  5:09 ` Dieter Wilhelm
2007-05-04  7:32   ` Eli Zaretskii
2007-05-05 14:39 ` Randal L. Schwartz

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=ebe43d680706030832h33cee756h5632d5e671c723ea@mail.gmail.com \
    --to=dmhouse@gmail.com \
    --cc=drew.adams@oracle.com \
    --cc=emacs-devel@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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).