From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value Date: Thu, 2 Nov 2023 22:24:41 +0000 Message-ID: References: <83il6k8yyd.fsf@gnu.org> <837cn08o13.fsf@gnu.org> <831qd88dt5.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14991"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acorallo@gnu.org, 66750@debbugs.gnu.org, acm@muc.de To: Stefan Kangas , monnier@iro.umontreal.ca, Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 02 23:25:54 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1qyg8Q-0003bz-9x for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Nov 2023 23:25:54 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qyg82-0001dZ-Jh; Thu, 02 Nov 2023 18:25:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qyg7z-0001dH-FU for bug-gnu-emacs@gnu.org; Thu, 02 Nov 2023 18:25:27 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qyg7z-0004I6-3c for bug-gnu-emacs@gnu.org; Thu, 02 Nov 2023 18:25:27 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qyg8Y-00048V-8A for bug-gnu-emacs@gnu.org; Thu, 02 Nov 2023 18:26:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Nov 2023 22:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66750 X-GNU-PR-Package: emacs Original-Received: via spool by 66750-submit@debbugs.gnu.org id=B66750.169896394115867 (code B ref 66750); Thu, 02 Nov 2023 22:26:02 +0000 Original-Received: (at 66750) by debbugs.gnu.org; 2 Nov 2023 22:25:41 +0000 Original-Received: from localhost ([127.0.0.1]:56344 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyg89-00047o-6D for submit@debbugs.gnu.org; Thu, 02 Nov 2023 18:25:41 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:54265) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyg7v-00047I-Nq for 66750@debbugs.gnu.org; Thu, 02 Nov 2023 18:25:36 -0400 Original-Received: (qmail 30135 invoked by uid 3782); 2 Nov 2023 23:24:42 +0100 Original-Received: from acm.muc.de (p4fe158b7.dip0.t-ipconnect.de [79.225.88.183]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 02 Nov 2023 23:24:42 +0100 Original-Received: (qmail 12124 invoked by uid 1000); 2 Nov 2023 22:24:42 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:273685 Archived-At: Hello, Stefan, Stefan and Eli. On Thu, Nov 02, 2023 at 14:44:28 -0700, Stefan Kangas wrote: > Alan Mackenzie writes: > > On Thu, Nov 02, 2023 at 15:50:14 +0200, Eli Zaretskii wrote: > >> How about if you propose a compromise with which you could live? > > That is difficult. > Thanks for persevering despite the difficulties. :-) > I have just now reviewed this thread in full, and I reread also the > beginning of the discussion. The contention here is not around the > general idea, which everyone seems to find more or less useful, but some > of the design decisions in the proposed implementation. Or, more precisely, the design decisions in the actual implementation. > > I could see myself replacing the defining symbol with FILE:POSITION > > information, but I doubt that would make the two of you happy enough. > > Or, maybe put this defining symbol or F:P information into the doc > > string somehow (including in the interpreted format) like Stefan was > > suggesting recently. > If I understand you correctly here, you are willing to consider using > FILE+LINE+COL instead of defining symbol, .... or possibly as well as it. Or possibly a character offset in the file. > .... and storing the information in the docstring instead of the > lambda form. In the doc string _inside_ the lambda form. Its first line could be, for example, a space separated structured line containing a characteristic introduction (like we have in .elc files), the source file, line number, column number, maybe the buffer it came from (optional), maybe a defining symbol (optional). This line needn't be displayed by the help system, and could be as long as needed. > And if I understand Stefan Monnier's argument correctly, it seems like > he wouldn't object to that. I hope not. It is more than a small compromise for me, since the info will not be stored in RAM as I wanted, and also I'll have to start work on it again from scratch (but with the benefit of experience from doing it the first time). It is a compromise for Stefan M and Eli, since it would enable the mechanism to work for interpreted functions, too. How do you feel about this, Stefan (M.)? > So why not proceed along those lines? I'm willing to do this. I hope you (Eli) will find it OK, too. -- Alan Mackenzie (Nuremberg, Germany).