From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: Documentation not clear for the Lisp function set-variable Date: Tue, 28 Jun 2005 10:32:43 +0200 Message-ID: References: <87slz6nr3h.fsf@jurta.org> <200506271609.j5RG9i020638@raven.dms.auburn.edu> <87vf3ztg62.fsf@jurta.org> Reply-To: Juanma Barranquero NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1119950092 26859 80.91.229.2 (28 Jun 2005 09:14:52 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 28 Jun 2005 09:14:52 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 28 11:14:51 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DnCAj-0003j8-Km for ged-emacs-devel@m.gmane.org; Tue, 28 Jun 2005 11:14:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DnCIY-0004E7-5N for ged-emacs-devel@m.gmane.org; Tue, 28 Jun 2005 05:22:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DnBaD-0003VL-RT for emacs-devel@gnu.org; Tue, 28 Jun 2005 04:36:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DnBaB-0003Ul-H5 for emacs-devel@gnu.org; Tue, 28 Jun 2005 04:36:40 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DnBYk-0003IY-Tn for emacs-devel@gnu.org; Tue, 28 Jun 2005 04:35:11 -0400 Original-Received: from [64.233.182.198] (helo=nproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DnBao-0005D8-2e for emacs-devel@gnu.org; Tue, 28 Jun 2005 04:37:18 -0400 Original-Received: by nproxy.gmail.com with SMTP id i2so203363nfe for ; Tue, 28 Jun 2005 01:32:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tWOYUHxSUi9lQVjQSHWqfZCf9uh4fiw7u6uZ0unaoqjzsG+pYK66iHVerPmB5GGpLVUz93Q7EOFhUpLKITIkju4znvOLE/noH2QOrDO9UanKdRjmoAFUQPogEiC8LESVMZ/N939qil6EeHeLrOMWrWOXclknnRlCasxH+ZPksO0= Original-Received: by 10.48.250.12 with SMTP id x12mr138108nfh; Tue, 28 Jun 2005 01:32:44 -0700 (PDT) Original-Received: by 10.48.250.5 with HTTP; Tue, 28 Jun 2005 01:32:43 -0700 (PDT) Original-To: Juri Linkov In-Reply-To: <87vf3ztg62.fsf@jurta.org> Content-Disposition: inline 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:39771 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:39771 On 6/28/05, Juri Linkov wrote: > Maybe set-variable should first try to complete non-obsolete aliases, > and filter out obsolete aliases (but still accept them). Completing to all non-obsolete variables and/or aliases should be easy, but... [see below] > The distinction > between obsolete variables and aliases is essential. Users should not > see obsolete variables by default, but should be able to use them ...I don't buy this argument. Users do not go randomly typing chars into `set-variable' just to see what variables they can set (at least, I don't think that's the most common use pattern). IMO, the user does M-x set-variable because he already knows the variable he wants to set (and it's even likely he read the doc and knows whether it is obsolete or not, though I'm willing to accept there are users who simply set a variable because they read about it in an old doc somewhere) and completion is just a help to do less typing. So in my view, `set-variable' should not filter out any user variable, whether it is an obsolete variable or an obsolete alias. I certainly would be very pissed if I wanted to set `messages-buffer-max-lines' and had to type it fully because `set-variable' had decided that `message-log-max' was the way to go. > (with possible notification about their obsoleteness). That's another matter entirely. I think is a good idea to warn about the variable being obsolete. But with the current `completing-read' mechanism, that can no be easily and elegantly done while the user is selecting the variable, only afterwards (unless I'm missing something). > Also it makes sense to introduce a new property byte-obsolete-face > to mark obsolete faces, so completion would work similarly for > customize-face. I support the idea about byte-obsolete-face, but not for face completion's sake, but because perhaps the byte-compiler could be coaxed into giving warnings about old faces' uses. Anyway, I'm not planning to delve into face completion (or customize), so that's a matter for whomever wants to implement it to ponder. --=20 /L/e/k/t/u