From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.help Subject: Re: M-x custom: *PLEASE*, someone, have it build an INDEX (as in *info*) Date: Sat, 30 Jan 2010 14:05:59 +1100 Organization: Rapt Technologies Message-ID: <87vdekuwa0.fsf@lion.rapttech.com.au> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1264824271 8568 80.91.229.12 (30 Jan 2010 04:04:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 Jan 2010 04:04:31 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Jan 30 05:04:28 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Nb4ZO-0001Bh-0r for geh-help-gnu-emacs@m.gmane.org; Sat, 30 Jan 2010 05:04:26 +0100 Original-Received: from localhost ([127.0.0.1]:44135 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nb4Cd-0000DX-Py for geh-help-gnu-emacs@m.gmane.org; Fri, 29 Jan 2010 22:40:55 -0500 Original-Path: news.stanford.edu!usenet.stanford.edu!news.glorb.com!news2.glorb.com!news.glorb.com!news.astraweb.com!border5.newsrouter.astraweb.com!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux) Cancel-Lock: sha1:d0FBVf2MGFkW05aJLPQU/eUu6Mo= Original-Lines: 112 Original-NNTP-Posting-Host: b4c2a322.news.astraweb.com Original-X-Trace: DXC==MgBSM>XGEFOObP71A_HVDL?0kYOcDh@JnmNjE4M:dlF3BG::AR[VBKNb@h3aXWUVGLCB2Jo>e\]@ Original-Xref: news.stanford.edu gnu.emacs.help:176507 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:71577 Archived-At: dkcombs@panix.com (David Combs) writes: > In article , > Kevin Rodgers wrote: >>David Combs wrote: >>> Unlike most everyone else, I find "custom" basically UNUSABLE. >>> >>> (Actually, I'd much prefer a super-LONG edit-options -- at least >>> I could run M-x occur on it, see where things were. >>> >>> This custom thing -- I have no idea where things are, how far >>> down I have to go. >>> >>> Maybe if someone could code it to draw one HUGE tree (lying on its >>> side, of course), but the current scheme doesn't work for me. >>> >>> So, an INDEX would help -- each one being a LINK to the thing >>> it's about. Custom would make the index each time it started up. >> >>Why not `M-x apropos-variable' to generate the *Apropos* buffer as a >>virtual index? Then click on one of the links to display the *Help* >>buffer for any variable, which has a link to customize the variable. >> >>-- >>Kevin Rodgers >>Denver, Colorado, USA >> >> >> > > You mean with a regexp like "."? To get EVERYTHING? > > (everything that emacs knows about, anyway, at that time > I guess that custom works the same way -- if a .el file > hasn't yet been read in, emacs won't know any of its > variables? > > Or is that just plain wrong. Isn't there something that > is predefined, and if referenced, it's then read in? > Or is that just for defuns? Or not even emacs-lisp?) > Unfortunately, it seems to depend on how the author wrote their mode. Many well written modes do auto load their mode custom stuff, so it is there even if you have not used the mode. However, other modes don't and their custom definitions will only show up if the mode has been loaded. I doubt a full listing of all custom settings will be at all usable. There are already single modes where it takes considerable time to load all the custom definitions and some of them use sub-modes, so all of them are not being created at once. The issue is really formatting of the custom buffers, which can be a bit slow if there are lots of elements to render. I would not be surprised if building the custom buffer with all custom options in it would take in the order of minutes to render, making it almost unusable. While I can understand everyone likes to work in their own way, this request still feels like an approach that is looking at custom settings from the wrong angle. I suspect this could be due to bad documentation. In reality, you usually don't go browsing through customize buffers looking for things to change. Rather, you use the docs and manual to learn about the mode and pick up how it can be customized from there. Then you either do a customize group or customize variable to change what you need to change. browsing the custom settings without a good understanding or any background can often lead to really unexpected results. You get tempted to change some value because, based on its current setting and name, you *believe* its not correct. However, often what you think the name means and what you think the different settings do are not quite in line with reality. What tends to happen is you then modify things and later find out something isn't working correctly or isn't working how it use to or some other weird unexpected thngs happen and now you have to try and work out what it was you changed that is the cause. the other problem with this approach is that often the user will change the mode settings to work the way they think the mode should work before they have gotten to understand and possibly appreciate the way the author intended the mode to work. This then results in either the user getting frustrated with the mode and giving up or worse still, writing another mode that is 80% equivalent rather than adding to the existing mode and making it better. The customize interface is certainly on the clunky side and possibly not the best looking customization interface, but given that it works under X and on text consoles or inside an xterm, I think it does a pretty good job. It is also evolving and becoming better over time. Now we have a GTK based interface, maybe the X/GUI version will become even better. What would probably help is for developers to know more about why there is a desire to have the ability to list all options in one huge buffer. Rather than asking for a particular solution, maybe it would be better to provide more explination regarding why the existing solution is lacking and see if anyone can come up with a better solution. In the meantime, I'd use M-x customize-browse, which gives you the full tree of currently available custom option settings that you can traverse to see what is available and if desired, make changes. As it uses the tree widgets, it doesn't have the rendering overhead of a buffer with all custom settings. HTH Tim > > -- tcross (at) rapttech dot com dot au