From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: chad Newsgroups: gmane.emacs.devel Subject: Re: Always-true predicate? Date: Sun, 21 Feb 2021 21:02:43 -0800 Message-ID: References: <875z2qoqc6.fsf@gnus.org> <87eehcsal4.fsf@gmail.com> <83zh002zjm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f298b805bbe5b602" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22020"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Robert Pluim , EMACS development team , Lars Ingebrigtsen , Richard Stallman To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Feb 22 06:03:49 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lE3Nt-0005dd-JP for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Feb 2021 06:03:49 +0100 Original-Received: from localhost ([::1]:43624 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lE3Ns-0001gF-Kh for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Feb 2021 00:03:48 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37644) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lE3N5-0001Fo-9x for emacs-devel@gnu.org; Mon, 22 Feb 2021 00:02:59 -0500 Original-Received: from mail-yb1-xb31.google.com ([2607:f8b0:4864:20::b31]:41558) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lE3N3-00038r-6s; Mon, 22 Feb 2021 00:02:59 -0500 Original-Received: by mail-yb1-xb31.google.com with SMTP id m9so11678861ybk.8; Sun, 21 Feb 2021 21:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wrRJmLXQnVoTOXvPSpbIahFPMDV6vIDcviD+xWW12Ec=; b=lNvmT00q6nuETldp3CXxfEspCX/IZVeDgbiuQn9owcm8aN9tbglVUYYObdSpQ4jH0V SikEX3Z8hrolrSJh8fyiTX1rOUOnzHh1uiuMiAbXvjWdfjVhnHPQsSEG+nBhf17ATh5i Sol1voNgUdDnfzZ64PGvNxC4BE/hFgE8vQ/wsXJDtBN8nTNlY1bYo1DuZOWvFf7iEEJJ +xh2T0sPn1vuCJaESVWzVVAJ0gY/IpoYAlQ83+tHBg4cWnfMWOoL/T5u8qoOWqHV9KNb xcx9ebC8kQbXln3vRL6EqhrF6SYHOHRPlNbsUQFNjEeLEKs9aMJ5sBmFVPYwwQ5uLjzw ZQPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wrRJmLXQnVoTOXvPSpbIahFPMDV6vIDcviD+xWW12Ec=; b=ZBFkcnHuPwGYTOhNIDzq4xb0tWoxXn2PH2qeAt+yOCMO8BOskhWtoB61OTpMV/q2GF 6L640JaKlfC6uKiG0NSrf83teOS+4HxIdelGqBGeJJx1lzej1qoLx8APSdW+Q9mWnsXm pcPXhRZHH1jdSwY7kRVllgWIQ0E4qHr/xGDAak9MisT98vSxySEbCyFRxdWBwSa5KaZR iX9BFNSlFp42oy4IFWbJCBQSBOnd/teJfO8jy2zMk/AHgnoxbKNN9lSuDITb9oMXTPdb PO65LLPs7IZcId6+zTGWLkuyKumdJ6GPGZKvmAvyElnY3F/1mWaFjGs5UBVkwtQcQH8L OrCA== X-Gm-Message-State: AOAM532U0EIstIkAy1LNfAh599Lz8mERDWXjq58roQw9Hq4qarrU4qsk 7j5PYJQ9UNMrQxqtQCRry9CEqyCRKeEtwZuHKTgrKcbZJLI= X-Google-Smtp-Source: ABdhPJwUaR0PbsYp1c7WaDpP8F9qO6qOJ+lt7FHbsxXDnbu/cZT5nqknmtOhGmLnA4CRqPJSquXcUnfwuArvA+LrOus= X-Received: by 2002:a25:a044:: with SMTP id x62mr29173852ybh.153.1613970174809; Sun, 21 Feb 2021 21:02:54 -0800 (PST) In-Reply-To: <83zh002zjm.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::b31; envelope-from=yandros@gmail.com; helo=mail-yb1-xb31.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:265459 Archived-At: --000000000000f298b805bbe5b602 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 19, 2021 at 1:10 AM Eli Zaretskii wrote: > I must diverge somewhat here, and express my uneasiness, to say the > least, with the recent-ish fashion of making too many user options > have function values. It makes "M-x set-variable" much less > convenient than it should be, and it makes customizing such options > harder for users who aren't proficient in Lisp. We should limit such > option values to the absolute minimum, IMO. I'd very much prefer to > have simple atomic values (symbols, numbers, or strings) that are then > interpreted by the relevant commands to run the necessary code or call > out to necessary subroutines to do the job. I feel that some of us > think that putting functions with the necessary code directly in the > option's value is somehow "cleaner" or "more elegant". I disagree. > I suspect that I ran into an instance of this recently, where the helpful package (an extension that offers expanded help functions, basically) had trouble in it's helpful-callable function with facemenu-face-menu. I tracked the problem down to a bad interaction in helpful with this code in facemenu.el: (defvar facemenu-face-menu > [...]) > (defalias 'facemenu-face-menu facemenu-face-menu) The problem that I get is: Debugger entered--Lisp error: (wrong-type-argument sequencep t) > mapconcat(identity (t) " ") > s-join(" " (t)) > helpful--signature(facemenu-face-menu) > helpful-update() > helpful-callable(facemenu-face-menu) > funcall-interactively(helpful-callable facemenu-face-menu) > call-interactively(helpful-callable nil nil) > command-execute(helpful-callable) I'm not familiar with the (defalias 'foo foo) idiom, so maybe it should be expected to work, and it's just a bug in helpful. (I reported it to the package maintainers already, with a note that I'd mention it here.) There are a few other instances of in emacs that I found with a quick search, and they also cause similar trouble for helpful. Is this an example of an accidental functional value, as I originally expected, or am I barking up the wrong tree and instead just looking at a parsing bug? (My lisp is largely self taught and started with Scheme, so these parts of elisp are murky to me.) Thanks, ~Chad --000000000000f298b805bbe5b602 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Feb 19, 2021 at 1:10 AM Eli Zaret= skii <eliz@gnu.org> wrote:
I must diverge somewha= t here, and express my uneasiness, to say the
least, with the recent-ish fashion of making too many user options
have function values.=C2=A0 It makes "M-x set-variable" much less=
convenient than it should be, and it makes customizing such options
harder for users who aren't proficient in Lisp.=C2=A0 We should limit s= uch
option values to the absolute minimum, IMO.=C2=A0 I'd very much prefer = to
have simple atomic values (symbols, numbers, or strings) that are then
interpreted by the relevant commands to run the necessary code or call
out to necessary subroutines to do the job.=C2=A0 I feel that some of us think that putting functions with the necessary code directly in the
option's value is somehow "cleaner" or "more elegant&quo= t;.=C2=A0 I disagree.

I suspect that I = ran into an instance of this recently, where the helpful package (an extens= ion that offers expanded help functions, basically) had trouble in it's= helpful-callable function with facemenu-face-menu. I tracked the problem d= own to a bad interaction in helpful with this code in facemenu.el:

(defvar facem= enu-face-menu
=C2=A0 [...])
(defalias 'facemenu-face-menu facemen= u-face-menu)

The problem that I get is:

Debugger= entered--Lisp error: (wrong-type-argument sequencep t)
=C2=A0 mapconcat= (identity (t) " ")
=C2=A0 s-join(" " (t))
=C2=A0 = helpful--signature(facemenu-face-menu)
=C2=A0 helpful-update()
=C2=A0= helpful-callable(facemenu-face-menu)
=C2=A0 funcall-interactively(helpf= ul-callable facemenu-face-menu)
=C2=A0 call-interactively(helpful-callab= le nil nil)
=C2=A0 command-execute(helpful-callable)
I'm not familiar with the= (defalias 'foo foo) idiom, so maybe it should be expected to work, and= it's just a bug in=C2=A0helpful. (I reported it to the package maintai= ners already, with a note that I'd mention it here.) There are a few ot= her instances of in emacs that I found with a quick search, and they also c= ause similar trouble for helpful.

Is this an examp= le of an accidental functional value, as I originally expected, or am I bar= king up the wrong tree and instead just looking at a parsing bug? (My lisp = is largely self taught and started with Scheme, so these parts of elisp are= murky to me.)

Thanks,
~Chad
--000000000000f298b805bbe5b602--