From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.bugs Subject: bug#62029: 29.0.60; Allow users to customize eldoc buffer separator Date: Thu, 30 Mar 2023 01:25:31 -0700 Message-ID: References: <0C40D168-54D5-47E9-8BD8-77CFCD70B895@gmail.com> <87355vdufe.fsf@gmail.com> <87h6uacadx.fsf@gmail.com> <87h6u2y7uj.fsf@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) 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="16068"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62029@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 30 10:26:28 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 1phnc3-00041V-Tb for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 30 Mar 2023 10:26:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1phnbm-00046b-AK; Thu, 30 Mar 2023 04:26:10 -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 1phnbg-00045i-10 for bug-gnu-emacs@gnu.org; Thu, 30 Mar 2023 04:26:04 -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 1phnbe-00051l-KI for bug-gnu-emacs@gnu.org; Thu, 30 Mar 2023 04:26:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1phnbe-00084T-95 for bug-gnu-emacs@gnu.org; Thu, 30 Mar 2023 04:26:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 30 Mar 2023 08:26: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.168016475131004 (code B ref 62029); Thu, 30 Mar 2023 08:26:02 +0000 Original-Received: (at 62029) by debbugs.gnu.org; 30 Mar 2023 08:25:51 +0000 Original-Received: from localhost ([127.0.0.1]:55712 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1phnbS-000840-OM for submit@debbugs.gnu.org; Thu, 30 Mar 2023 04:25:51 -0400 Original-Received: from mail-pj1-f45.google.com ([209.85.216.45]:39886) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1phnbQ-00083d-MI for 62029@debbugs.gnu.org; Thu, 30 Mar 2023 04:25:49 -0400 Original-Received: by mail-pj1-f45.google.com with SMTP id mp3-20020a17090b190300b0023fcc8ce113so21196802pjb.4 for <62029@debbugs.gnu.org>; Thu, 30 Mar 2023 01:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680164742; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PkbPhE2ZpH0Ge9nSEhUiZPH92OY8LvURsovuLSNkUeI=; b=MGAJXV6RuH9yyhj4ejJE2GPwwTrScrXRiR5vFtadi77qTvpTJMDkBy8HHf1FDfPH/G 7fLUlDMPYHduw6QQqwzDdNcX35khnun/EbdinX06Yjapj6MZuIe8GIGzdROTy38uYl9e B5+H9rFUIQm5kndYjXjXgAdgFsXavx+GEegcubYXcJi6lQ4ianwpTG6oJWTJ9V5gacVN mncnGtQ5/X6QMBibId4XUGdxBzC0+fTevY6QIT+IL9MQjF/PEvnx0sdQBg/oVKMeNZpW WlLOa9kqz1+jcVAPMp7KGW6NGHyaawo8G9LJBbsA4c694Dpyw9lW1IsExG0ZzQAAdkbk 9XEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680164742; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PkbPhE2ZpH0Ge9nSEhUiZPH92OY8LvURsovuLSNkUeI=; b=LBJsDzx5FQj8FcLSW0c4E9Tk5Zj+vRvauj495uP7XeUlqRyXUqGPVpDQi1bxvWxmFd bAtwtAyhhiPJfHtPn4Yi75tspMQIW+4//rlSrurYnc/ztYeuALdB+ixmuzoGVkkodYbW 8sxTK+hFe0BRF+Q8c+rQDDrjg/cQ0HD+JYo/msteBo5cKi+AxrksMdYMRuHJJAdd5fa6 t7p4Ww4GQ92mlEeA/e7/NWc9jDTNZm8yJ/6sd2a7/runkyn2zLaZ9uFM1L//itYmRNFJ VyL9LmrZTAn6rhQ5UwB1Pf3CSaFfIx3qy1RuOGTYO2M1yicA0s07gpV79ADqBULFrZ+7 NGtg== X-Gm-Message-State: AAQBX9f9Og1UQKJ5bFNZJAnphpjFMJbs2IwISO9sqCh8EluOlX0x5PLj Sj72vnx0OXDQaAR1MhnO4uY= X-Google-Smtp-Source: AKy350YGkmm7IweM2z4U8l5djGlOlPR1jIQLTBGe+aXH9ZBKqfe5JSf0VRU22jH9DhZImlqY59uSfQ== X-Received: by 2002:a17:902:d4c6:b0:1a1:c6a7:44f5 with SMTP id o6-20020a170902d4c600b001a1c6a744f5mr28691501plg.52.1680164742495; Thu, 30 Mar 2023 01:25:42 -0700 (PDT) Original-Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id n3-20020a654883000000b0051322a5aa64sm10965629pgs.3.2023.03.30.01.25.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2023 01:25:42 -0700 (PDT) In-Reply-To: <87h6u2y7uj.fsf@gmail.com> X-Mailer: Apple Mail (2.3731.400.51.1.1) 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:258905 Archived-At: > On Mar 30, 2023, at 1:13 AM, Jo=C3=A3o T=C3=A1vora = wrote: >=20 > Yuan Fu writes: >=20 >>>>=20 >>>> Looks good to me (except for the =E2=80=9Cdocumentatiok=E2=80=9D = ;-) eldoc-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 and >>>> 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. >>=20 >> Cool! The whole help system would benefit from some renovation, but I = don=E2=80=99t think anyone is excited to do it ;-) >>=20 >>>=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. >>=20 >> Yeah, I think it=E2=80=99ll be good to mentioned them in the = documentatiok. >>=20 >>>=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). >>=20 >> Huh, I wonder why I can see both flymake + eglot in the eldoc doc >> buffer when my eldoc-documentation-strategy is the default value? >=20 > Because Eglot changes eldoc-documentation-strategy automatically. It > shouldn't but the default value is really bad. Ah, I see. > 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. >=20 > 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. >=20 > 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 like it. I tried setting e-e-a-use-multiline to a larger value (like = 2), but set it back to one after a while, because I don=E2=80=99t like = all the skipping. I just need to see the signatures in the echo area, if = I want to know more, I can always bringup eldoc doc buffer (or in my = case an eldoc-box childframe) to see the full doc. >=20 > 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. That happens all too often :-) Well, at least the current situation = isn=E2=80=99t too bad. Yuan=