RE: Scratch buffer annoyance

[Drew Adams]

> >>> How about adding a link at the end: [Customize Startup Screen]?
> >>
> >>> That way, you get the splash screen with the links, by
> >>> default, and one of the links lets you set your startup
> >>> preference. No need to hunt for a way to customize the
> >>> startup screen.
> >>
> >> A good idea!
> >
> > We should use the startup screen group for that with the same
> > interface as Emacs/Options/Browse Customization groups.  In that
> > manner, people get kicked into using the customize browser right from
> > the start.
>
> To clarify: the link [Customize Startup Screen] should enter the
> customize browser in the right customization group.

Thanks for the clarification; I understood something different from your
first post.

Even so, I'm not too sure what you mean. I think you are saying, in essence,
that we should open the book to the part of the table of contents that shows
the title of the target section, rather than opening the book directly to
that target section. The section title in the TOC is a link to the target,
but this is still an indirection.

Here are possible Customize destinations for this:

1. Open to the *Customize Browser* buffer.  I think you're proposing this.

2. Open to the *Customize Group* buffer (say *Customize Group:
convenience*).

3. Open to the *Customize Option: visit-on-startup* buffer.

For either #1 or #2, it would be important to put the cursor on the target
option and highlight that option, or else users will be easily disoriented.
It would not be enough, for instance, to just put the cursor on the option.
The user is asking for a particular tree branch, not for the forest. For #1,
the highlighting says "This is the way"; for #2, it says "You are here".

I agree that it is good, in general, to introduce users to the customize
browser. But where do you draw the line with your suggestion? Whenever the
user asks to customize a single option, should we just open the browser to a
browser display that shows that option or its group somewhere on it (and
highlight the target)? That would help introduce users to the browser, but
it would be an unnecessary inconvenience that would quickly have users
asking for a direct route.

I think we should go all the way, and get the user to the final destination
immediately: the customize entry for the target option. That would mean #2
(with highlighting of the option) or #3. I prefer #3, as it is the simplest
and least confusing for users. However, it provides the least customize
context, admittedly.

If your concern is a general one that, when a user is in a customize buffer
for a single option, or even for its group, s?he is not made aware of the
existence of the customize browser, then that is a separate issue, one that
is not specific to the startup display or to its option, `visit-on-startup'.

That concern is best dealt with by improving the final customize buffer, so
that the browser is pointed out with a link. In *Customize Option* and
*Customize Group*, instead of having just a list of links to the parent
groups, we could add a link to the *Customize Browser* too. This link would
take you to the browser, with the cursor on the current option or group and
with that option or group highlighted, to aid orientation. The link should
be near the links to the parent groups.

I think that would be a better way to introduce users to the browser than to
kick them into it when they ask to customize a single option. I do agree
that the customize browser needs more visibility - currently, it is visible
only (1) in the doc and (2) on the Options menu.