unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Demonstration mode...
Date: Mon, 27 Jun 2005 16:04:14 +0200	[thread overview]
Message-ID: <85u0jjvqu9.fsf@lola.goethe.zz> (raw)
In-Reply-To: <E1DmmJT-0004H0-OI@fencepost.gnu.org> (Richard M. Stallman's message of "Mon, 27 Jun 2005 01:37:43 -0400")

"Richard M. Stallman" <rms@gnu.org> writes:

>     > Is it that you use menus to invoke the commands?  How inconvenient.
>
>     Definitely.  That's why I want to use the keyboard, but have it look
>     like I would be using the mouse.  Which also shows the keyboard
>     shortcuts in the menus.
>
> But most Emacs keyboard commands don't have any equivalent menu
> items.  So this could only work for a narrow subset of possible
> input.

Yes, but the stuff I am demonstrating pretty much falls into the
categories that would be also in menus and on a printed help sheet.

Of course I would not want to have this sort of thing work on things
like plain cursor movement commands: that's why I said that it would
be vital to specify the keymaps that should be watched for
corresponding menu entries: the normal editing keymaps I would not
usually want to be demonstrated that way.

> What if you use M-x to enter commands that are worth showing people?
> They will see the "M-x COMMANDNAME" in the minibuffer, and that will
> tell them what you're doing as well as a menu item would.

Problem is that it does not look like something every rank beginner
could do himself easily without any preparation.

The sort of talks I do usually want to point out to people that we are
no longer in the dark ages where a menuless terminal application
started throwing strange help screens at hapless users the first time
they made the mistake of hitting "Backspace".

I know that the menu approach is about the most inefficient way of
accessing Emacs that is available.  But it also is the least scary
one, and it is a tolerable starting point.

Basically, it is a teaching and documentation aid.  Stuff like that
acts like a multiplier.

Another thing in the multiplier area that I'd like is something that
took a menu, and cranked out a Texinfo page with the menu structure as
items, and the function help strings as corresponding explanation.

Of course, the thing should be flexible enough to produce other
markup, like HTML that showed the menus, popped up the help strings on
mouse-over, and did some appropriate action when clicking on the menus
itself (like changing an underlying screenshot of the main Emacs
"frame" to simulate the actual actions a real Emacs would do).

Stuff like that: possibilities of extracting information automatically
about the manner of working with Emacs.

If every Tom, Dick and Jane could easily create standard screen shots
or pseudo screen shots and HTML demo pages and LaTeX chapters and
online "movie" demonstrations about his favorite modes, I think this
would help a lot with proselytizing.

Anyway, I was just brainstorming a bit, and wanted to mention some of
this stuff before I forget about it again.  I am doing quite a few
talks about Emacs/AUCTeX these days, and am planning to write some
dead-tree kind of documentation in future (and have some web pages to
maintain), and those are the sort of things that I repeatedly thought
"would be nice to have, and not technically infeasible".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

  reply	other threads:[~2005-06-27 14:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-23 19:05 Demonstration mode David Kastrup
2005-06-26 15:04 ` Richard M. Stallman
2005-06-26 18:57   ` David Kastrup
2005-06-27  5:37     ` Richard M. Stallman
2005-06-27 14:04       ` David Kastrup [this message]
2005-06-28  4:17         ` Richard M. Stallman
2005-06-28  6:59           ` David Kastrup
2005-06-28 21:29             ` Richard M. Stallman
2005-06-27 15:57       ` Drew Adams
2005-06-27 16:58         ` David Kastrup

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=85u0jjvqu9.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --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).