From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#62029: 29.0.60; Allow users to customize eldoc buffer separator Date: Thu, 30 Mar 2023 09:13:56 +0100 Message-ID: <87h6u2y7uj.fsf@gmail.com> References: <0C40D168-54D5-47E9-8BD8-77CFCD70B895@gmail.com> <87355vdufe.fsf@gmail.com> <87h6uacadx.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22405"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 62029@debbugs.gnu.org To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 30 10:13:14 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 1phnPG-0005i4-0p for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 30 Mar 2023 10:13:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1phnP6-0001O4-Js; Thu, 30 Mar 2023 04:13:04 -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 1phnP5-0001Ng-0G for bug-gnu-emacs@gnu.org; Thu, 30 Mar 2023 04:13:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1phnP4-0002Ql-Im for bug-gnu-emacs@gnu.org; Thu, 30 Mar 2023 04:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1phnP4-0007k4-4f for bug-gnu-emacs@gnu.org; Thu, 30 Mar 2023 04:13:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 30 Mar 2023 08:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62029 X-GNU-PR-Package: emacs Original-Received: via spool by 62029-submit@debbugs.gnu.org id=B62029.168016392429674 (code B ref 62029); Thu, 30 Mar 2023 08:13:02 +0000 Original-Received: (at 62029) by debbugs.gnu.org; 30 Mar 2023 08:12:04 +0000 Original-Received: from localhost ([127.0.0.1]:55687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1phnO8-0007iY-63 for submit@debbugs.gnu.org; Thu, 30 Mar 2023 04:12:04 -0400 Original-Received: from mail-wm1-f53.google.com ([209.85.128.53]:46056) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1phnO6-0007i2-GQ for 62029@debbugs.gnu.org; Thu, 30 Mar 2023 04:12:02 -0400 Original-Received: by mail-wm1-f53.google.com with SMTP id v6-20020a05600c470600b003f034269c96so937927wmo.4 for <62029@debbugs.gnu.org>; Thu, 30 Mar 2023 01:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680163916; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ugp+LTBp6Km3+hqq4a+8/2iLG/IYupEXPhIQOS/+Eeo=; b=ps/BJZZIAtxFDX8mJ7nfYmu0zKTn3wQLQNiIFqEvR30T1SVLbsMg7I9VW9bVLOjGST 1WJn1G6PnSNU93g/I4Q9kWVtER4jBO5xwTlo78szicBgKLWhg1wok80HQlHM+uAU6WTf lAFq5KgpHDadzNR3nc4UtDZX27aT+HRiM8xVHNWnEpLK4+fiPj7OoMu8fxZj4ql9EjWq V7VJei5TtZC7IlfT1TY4H0vY95J52Cq8Wfg2eTtst2INApRL5jrIdilNdkY/AEWCivXP ilZOivYHF7We/HvCQr+8CB01vBsQ6B9k5dyDECm24foPeEa5m6IxmfTXF2M4+f9G1d/l 0/eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680163916; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=ugp+LTBp6Km3+hqq4a+8/2iLG/IYupEXPhIQOS/+Eeo=; b=K19VHjnQZoSIb9dDxzSTLqx35AyKagbBGG9GwCDIdx6xXI82qAesoZdcBKEXd+/vWY 8J/RU6GhIXuLlAKaUa6QmMfDr4m7xRnaqG0xsHCTnr32+zyZLpCeljaor0uI/3/QqKKz 5g+k7g1SojPjbkj0k993w2AsHSY0MnaeXsRb+kTxolxV1HG9nJERogoQtiumwt08f8tu km2lEwIoRfKL6naaKQVeOniPWhg09+nip0BmJcjxkU5hMroCC7jBkun6laUxAi3DOrv3 fbpl3fSNd41DXX/tDMRpd6ah5uh/FJQIVUTzmkdpr/ryagKATRqYRI3RJzY5Mdw+lw7J h9qw== X-Gm-Message-State: AAQBX9cxA+Yw6970ux+nQR5lMVsmpH/2ivY7vG3aHGM6KLiSHJMpsna2 iO930qauxsxlj1afOM9eGC1dmzgGpJ4= X-Google-Smtp-Source: AKy350bZwAp1L4BeVihvzxaTMoQ6XlQo0foev4WS1c/mvanm2qRrp0mkNiueBPLiOy4+CsoHOHfD5A== X-Received: by 2002:a05:600c:4591:b0:3f0:3070:f4ea with SMTP id r17-20020a05600c459100b003f03070f4eamr2890098wmo.11.1680163916316; Thu, 30 Mar 2023 01:11:56 -0700 (PDT) Original-Received: from krug (87-196-72-128.net.novis.pt. [87.196.72.128]) by smtp.gmail.com with ESMTPSA id bd6-20020a05600c1f0600b003ef36ef3833sm5063554wmb.8.2023.03.30.01.11.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Mar 2023 01:11:55 -0700 (PDT) In-Reply-To: (Yuan Fu's message of "Wed, 29 Mar 2023 22:22:23 -0700") 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:258901 Archived-At: Yuan Fu writes: >>>=20 >>> Looks good to me (except for the =E2=80=9Cdocumentatiok=E2=80=9D ;-) el= doc-box can >>> also benefit from this (right now if you use it in emacs-lisp-mode, >>> it just shows a thin strip of text, not very exciting). >>>=20 >>> I=E2=80=99ll experiment with the title thing in eldoc-box. Does eglot a= nd >>> flymake already pass a :source cookie? Those two displaying stuff >>> together is the most possible case I can think of. >>=20 >>=20 >>> it just shows a thin strip of text, not very exciting). >>=20 >> Indeed. I'll present my patch soon in emacs-devel. >> There's one thing I don't like about it which is that >> is re-does a lot of complicated parsing for both *Help* >> and *eldoc* forms. Could be slow, or could be meaningless. >> Another aspect is that function documentation looks great >> because there is this nifty describe-function-1 helper, but >> variable documentation looks poor because there is >> no such thing. > > Cool! The whole help system would benefit from some renovation, but I don= =E2=80=99t think anyone is excited to do it ;-) > >>=20 >>> Does eglot and flymake already pass a :source cookie? >>=20 >> You mean ':origin', not ':source'. Though the latter name is >> acceptable and there's plently of time to change to it if you >> think it's better or more consistent with other parts of Emacs. >>=20 >> Yes they do. This cookie is automatic. Maybe I should state that >> in the documentatiok. > > Yeah, I think it=E2=80=99ll be good to mentioned them in the documentatio= k. > >>=20 >>> Those two displaying stuff together is the most possible case >>> I can think of. >>=20 >> In Eglot it's very usual to have three sources, and in Emacs >> Lisp you can also have three (function, variable and flymake). >>=20 >> You do need to set eldoc-documentation-strategy to >> eldoc-documentation-compose though (this should really >> be the default). > > Huh, I wonder why I can see both flymake + eglot in the eldoc doc > buffer when my eldoc-documentation-strategy is the default value? Because Eglot changes eldoc-documentation-strategy automatically. It shouldn't but the default value is really bad. The reason the default value is historic. Previously, there was a single producer of ElDoc, and only in Emacs Lisp. It would decide whether to show variable _or_ function doc, even if a given symbol had more than one meaning. So what's the problem with setting eldoc-documentation-strategy something like e-d-compose, you ask. Well, because of the default value of eldoc-echo-area-use-multiline-p, people would be seeing "bouncing" in the echo area while editing Elisp, which is something they are not used to. I think a very good solution is to set e-d-strategy to e-d-compose globally and e-e-a-use-multiline-p to 1 in emacs-lisp-mode. I once proposed this in this bug tracker, but the message was garbled by some side discussion, and I gave up. And ElDoc wasn't so powerful then. Jo=C3=A3o