RE: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Drew Adams <drew.adams@oracle.com>]

> > 2. There are individual commands to insert each of>    the various
> fields, so you can easily include
> >    any that you don't choose to include by default.
> >    Most are bound to keys with prefix `C-o'.
> 
> That seems like more typing (and remembering) than I'd prefer.  If we
> want to do something like this, my ideal would be closer to how magit
> handles chunks: 'n' to go to next, 'k' to kill it.

#1, which you didn't quote, was the main thing.

The idea is that a user will typically want the
same fields to be included/excluded for her bug
reports.

In that case there's rarely any need to do anything
(hit a key to include, or kill text to exclude it).

The keys to include specific sections are available
for the rare case when you might want to include
something you generally exclude (via the option).

And `C-h m' tells you about the keys - there's
really nothing to remember.  Using such a key would
be relatively rare, in which case `C-h m' is your
friend.

> To elaborate, let's say I move point outside the "body text" part of
> the bug report, on top of the auto generated data.  Here, the current
> "block" (as detailed above: features, load-path-shadows, major-mode,
> etc.) gets highlighted, and the keys no longer does
> self-insert-comand, but instead the commands:
> 
>  'n' move to next block
>  'p' move to previous block
>  'e' edit current block (make "block" into regular text, disabling
> commands)
>  'k' kill current block
> 
> Even better if you see a help text in the minibuffer when point is on
> these blocks.
> 
> Just an idea.  Not sure if it's worth implementing, but I think it
> would be useful.

Good.  All ideas are helpful.

I think it's generally better to let users
define the typical, general behavior they want.

That's better than always including everything
(a hard-coding the behavior) and then giving
users ways to navigate and kill included text.
Why make users do that?

IOW, instead of making users kill the same kind
of text over and over, each time they file a
bug, let them choose their own preferred
(default) reporting behavior.

The default value of the option I provided does
include everything (all fields) - we ask for it
for a reason.  But a user can provide her own
default behavior by customizing the option.

For example, a user might change the default
behavior, to include only the Emacs _version_.

Because there's a command (and key) for each
section, she can easily override her default
behavior whenever including something more
makes sense to her.

Because I split the included text into separate
pieces (categories/fields), the code is a bit
cleaner, and users have better control over the
behavior.  Likewise, any code that wants to
tweak or make use of the basic code.