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#61072: How to change the length of the separation lines in eldoc, used by eglot? Date: Tue, 21 Feb 2023 17:19:02 +0000 Message-ID: References: <871qmyn51d.fsf@betli.tmit.bme.hu> <87pma3gcyw.fsf@betli.tmit.bme.hu> 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="28819"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 61072@debbugs.gnu.org, Wei-Ting Lin To: Felician Nemeth Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Feb 21 18:20:17 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 1pUWJN-0007Je-B0 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 21 Feb 2023 18:20:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pUWJD-0005rU-Lo; Tue, 21 Feb 2023 12:20:07 -0500 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 1pUWJ9-0005qx-Ff for bug-gnu-emacs@gnu.org; Tue, 21 Feb 2023 12:20:03 -0500 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 1pUWJ9-0007NK-7L for bug-gnu-emacs@gnu.org; Tue, 21 Feb 2023 12:20:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pUWJ8-0008KZ-GU for bug-gnu-emacs@gnu.org; Tue, 21 Feb 2023 12:20:02 -0500 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: Tue, 21 Feb 2023 17:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61072 X-GNU-PR-Package: emacs Original-Received: via spool by 61072-submit@debbugs.gnu.org id=B61072.167699996131971 (code B ref 61072); Tue, 21 Feb 2023 17:20:02 +0000 Original-Received: (at 61072) by debbugs.gnu.org; 21 Feb 2023 17:19:21 +0000 Original-Received: from localhost ([127.0.0.1]:57191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUWIT-0008Ja-B5 for submit@debbugs.gnu.org; Tue, 21 Feb 2023 12:19:21 -0500 Original-Received: from mail-oi1-f176.google.com ([209.85.167.176]:46963) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUWIR-0008JN-F0 for 61072@debbugs.gnu.org; Tue, 21 Feb 2023 12:19:19 -0500 Original-Received: by mail-oi1-f176.google.com with SMTP id w7so5089295oik.13 for <61072@debbugs.gnu.org>; Tue, 21 Feb 2023 09:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Vc4JMHMg/d/5aoiLbMpacaWs3T1qDcr50Ruc5C7nfJM=; b=StRmRJa/IQlcXVLhumCdgI73kLHfxS8mN5PR9ex1kwlOu/K3qOhhDH2phnepCpW7SM FlWSxIRQ3QkRH/ud2BySrhwi4sN/XiEKgag8vR98DfTvTO5JowLwev3QddXF3CXp+m+8 o0kBzYIf9Jvhtu4JaTCV+N7uyauPIW/QMuB8Lmk3Fjxdz0bgWd8plza6NgAovKhDPCDq kfE3sBjfxRoMMQkaufFNh+/Jp/Pa9cX91eHU4OKRFvK4jzBF2+ahY7tal+zVoYI8WNYp BzHadcBlpUccnAfdtdBeEdgvCQ11LpXZEwVYLlj5Kqz4pYaksyrGAj0peEaUmVWumI15 vMhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Vc4JMHMg/d/5aoiLbMpacaWs3T1qDcr50Ruc5C7nfJM=; b=zNCI9roEZKDNVobcdzbkqeibJybUOkG+Kn35iKydwZCZTKk9k2DKUxxwwDrIVXOwwF L+pAzP4O0y7yYxbl/jQdGFg7iE8QUz5Fm/4oSJ9aHY52l4U3p4Cf9HBfP1luEgFW/hEF I0GtOlMa4ofSsLuQ+9jWGrllz5DBtcXBklVo2/cqer12nu3g2PK+RNcj1U6KSUPvT+WU 6mB+Aq8JLW3iDOboYbheOaBu9nR/h+TQFfnKbSCW2u9FOR5yBpEWwQ7V19UL0Zx8npdL lsnyC1dPDUdtFPo0j0whNxVzYtGNfySZXolalpUP8xe2aahGV1/odPlCwP968HMmhiPy fVYw== X-Gm-Message-State: AO0yUKVHn+rpROPBqHxj+4lqfo2zIIdXaV9cxffk8mm0V0k8m7hITs/g 18qWcxmNsgmANzM5SyPjaBalU82RnjPbK80fC0U= X-Google-Smtp-Source: AK7set/W1u7LIrpU7rV6vSmtn9KJFA7peBNcfcj3STnWXb2hdRxaEmbaUHNR5VnxgqYU6RmdvcpU0BZuAz8sSaZjCwo= X-Received: by 2002:a05:6808:128b:b0:37b:9a3:136f with SMTP id a11-20020a056808128b00b0037b09a3136fmr737937oiw.6.1676999953657; Tue, 21 Feb 2023 09:19:13 -0800 (PST) In-Reply-To: <87pma3gcyw.fsf@betli.tmit.bme.hu> 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:256304 Archived-At: On Tue, Feb 21, 2023 at 5:11 PM Felician Nemeth wrote: > So the LSP server sends "---\n". gfm-view-mode turns these three dashes > into a long separation line, which is then displayed by eldoc-box. > Neither gfm-view-mode nor eldoc-box is a part of Emacs or available from > GNU ELPA. I'm therefore tempted to say that debbugs is not the right > place for this bug report. > > However, when Eglot calls gfm-view-mode in eglot--format-markup the > window-width probably equals to the width of the window containing the > user's source code and eldoc-box seems to display the documentation in a > narrower window. So maybe it would help if Eglot allowed the users to > run a custom function instead of calling gfm-view-mode in > eglot--format-markup. Yes, I see the problem. Thanks for describing Felici=C3=A1n. But I don't think your suggestion is the correct way to tackle it. Rather, Eglot should add a markdown-capable element to eldoc-display-functions and hint in the documentation item produced by Eglot's eldoc-documentation-functions that that item has a markdown version (it may also have a plaintext version alongside), taken directly from the LSP source. The new function would then render the item appropriately. Then users and other modes such as eldoc-box can also add things to eldoc-display functions, read the hints (if they support them) and do whatever they think is more suitable with the rich/poor documentation item. This is in principle already fully supported by the ElDoc infrastructure, but needs someone to experiment with it (and potentially find limitations in ElDoc, which I can help plug). Jo=C3=A3o