From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Scratch buffer annoyance Date: Sat, 21 Jul 2007 08:14:18 -0700 Message-ID: References: <857iou9jf2.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1185030890 16699 80.91.229.12 (21 Jul 2007 15:14:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 21 Jul 2007 15:14:50 +0000 (UTC) Cc: Peter Lee , rms@gnu.org, emacs-devel@gnu.org To: "David Kastrup" , "Mathias Dahl" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 21 17:14:48 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1ICGfP-0004Qd-MH for ged-emacs-devel@m.gmane.org; Sat, 21 Jul 2007 17:14:47 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ICGfP-00016N-1k for ged-emacs-devel@m.gmane.org; Sat, 21 Jul 2007 11:14:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ICGfL-00014r-KO for emacs-devel@gnu.org; Sat, 21 Jul 2007 11:14:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ICGfK-00014H-Vp for emacs-devel@gnu.org; Sat, 21 Jul 2007 11:14:43 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ICGfK-00013k-SO for emacs-devel@gnu.org; Sat, 21 Jul 2007 11:14:42 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1ICGfH-0006Ol-4y; Sat, 21 Jul 2007 11:14:39 -0400 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l6LFEZic023431; Sat, 21 Jul 2007 10:14:35 -0500 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l6LDSUp0010916; Sat, 21 Jul 2007 09:14:34 -0600 Original-Received: from dhcp-amer-csvpn-gw2-141-144-72-196.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 3058839151185030867; Sat, 21 Jul 2007 08:14:27 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <857iou9jf2.fsf@lola.goethe.zz> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:75234 Archived-At: > >>> 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.