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#61072: How to change the length of the separation lines in eldoc, used by eglot? Date: Wed, 29 Mar 2023 16:59:58 -0700 Message-ID: References: <871qmyn51d.fsf@betli.tmit.bme.hu> <87pma3gcyw.fsf@betli.tmit.bme.hu> <87r0tq8bgp.fsf@betli.tmit.bme.hu> <87wn37ceo6.fsf@gmail.com> <87o7oc6h5b.fsf@betli.tmit.bme.hu> <87jzz0se9c.fsf@gmail.com> <87fs9n5tz9.fsf@betli.tmit.bme.hu> 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="39408"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 61072@debbugs.gnu.org, Wei-Ting Lin , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= To: Felician Nemeth Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 30 02:01:24 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 1phfjI-000A5R-8W for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 30 Mar 2023 02:01:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1phfiy-0001si-Sm; Wed, 29 Mar 2023 20:01: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 1phfiw-0001sU-UD for bug-gnu-emacs@gnu.org; Wed, 29 Mar 2023 20:01: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 1phfiw-0006bm-Et for bug-gnu-emacs@gnu.org; Wed, 29 Mar 2023 20:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1phfiw-0002zw-49 for bug-gnu-emacs@gnu.org; Wed, 29 Mar 2023 20:01: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 00:01: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.168013442111470 (code B ref 61072); Thu, 30 Mar 2023 00:01:02 +0000 Original-Received: (at 61072) by debbugs.gnu.org; 30 Mar 2023 00:00:21 +0000 Original-Received: from localhost ([127.0.0.1]:55246 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1phfiG-0002yv-V9 for submit@debbugs.gnu.org; Wed, 29 Mar 2023 20:00:21 -0400 Original-Received: from mail-pj1-f46.google.com ([209.85.216.46]:47020) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1phfiD-0002yc-Ke for 61072@debbugs.gnu.org; Wed, 29 Mar 2023 20:00:19 -0400 Original-Received: by mail-pj1-f46.google.com with SMTP id f6-20020a17090ac28600b0023b9bf9eb63so17901471pjt.5 for <61072@debbugs.gnu.org>; Wed, 29 Mar 2023 17:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680134411; 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=VW+URfw5Zm8xB0d3ONnQmjTwvNZxmMDQ+Xkm9tqyjas=; b=D/mZboWR8wR72DZZcIamgqomG2SPCICgrk0ZwL+zNcZcwpDsHxtjQwtIf1awnyX1Dn 1eVIFrbxeuYYklRd4rJtN98WzCdNWchQj8L1mh6eCXxTgnSVjiBTb5IbrLxRNWe/LJWL kc2Wry9j8brGjEFMRY+HJBZlcBbE+7vZ4RlWZ/Rf2W9jMwqewNzadbsvHnxMwOtLL1Ia vsdo+I8BVidoK5gxYnPZTvBtETlGfK2qeVla9/iuHYnjtAgn3dXOGSQp5mUmeDJ0Ta+S Gu/BeW/Q82cuDX0Lhw8ZC6HYWNB8xDENB2QnPA+ROD8aCNDHFTMn5OxWvWNBSgMCqLjj qQOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680134411; 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=VW+URfw5Zm8xB0d3ONnQmjTwvNZxmMDQ+Xkm9tqyjas=; b=LSnEPTLHyt8m675SKtdQ6HTSoiG10ToC3bneVaVpv7VWWrCX+pUmMhoR/GAYA4hrh/ INqvPucZGE0r7sDWFlofo8Aodmi5DXlHgwd3Vx8vd7pf7UpubUm9nfuoVPcfFgSijsXP Z3WENEjq4kXbyrXu3JcBzpQdOwVATF684DOJpNX1IG7q0uSY96xdLpMkQ+iHQ5HPCBvb 0eIlR4gHutr8iRT9BT48UYDDqg5LdR5FyeT9je6etSROVSztOPA+olhRt9kes8e3LguO rikc4iP1SH3xzbGeh3GvEHnMqbAjM2SRilAsaHQ3uNCQ66J8vU7Fusg6UCXhqyfkUmv1 Qh/w== X-Gm-Message-State: AAQBX9fjXdlF6il2wOMa7C0jgdndljp5jdmwYJVaIDlrQzWNyhBEnA88 Fh4mECmkGXIqcYWPVHD+mtY= X-Google-Smtp-Source: AKy350YpC+MFW4bOsyBkXVmO7yQFpqoESwghGTmY+RfIxL7AuU6gYEn+J0iepjCIXqOdVDpX1HaYMg== X-Received: by 2002:a17:902:e842:b0:19a:6acc:1de2 with SMTP id t2-20020a170902e84200b0019a6acc1de2mr26407802plg.35.1680134411394; Wed, 29 Mar 2023 17:00:11 -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 bf6-20020a170902b90600b001a1bf30cef1sm20586076plb.46.2023.03.29.17.00.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2023 17:00:11 -0700 (PDT) In-Reply-To: <87fs9n5tz9.fsf@betli.tmit.bme.hu> 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:258877 Archived-At: > On Mar 29, 2023, at 10:48 AM, Felician Nemeth = wrote: >=20 > Jo=C3=A3o T=C3=A1vora writes: >=20 >>> Sure, but can a better markdown.el solve the original issue? Is = there a >>> way to render a separation line independently of the current >>> window-width? >>=20 >> Yes, there is, with just the same code we use in eldoc now to = separate >> documentation from different backends. >>=20 >> (concat "\n" (propertize "\n" 'face '(:inherit separator-line = :extend >> t)) "\n") >=20 > Surprisingly, this does not work in the *scratch* buffer. It does = work > in a non elisp-mode buffer. I wonder why. If font-lock-mode is on, it overwrites the =E2=80=98face property. I = always apply both =E2=80=98face and =E2=80=98font-lock-face to be safe. >=20 > make-separator-line is a bit more complicated than the code above. > Would it make sense to use that when it's available? (I.e., Emacs 29 = and > above.) >=20 >> I've mailed Jason Blevins, markdown.el maintainer but he hasn't >> responded. Maybe make a bug report in the Github repo. >=20 > Yuan Fu (CC'd) has already made one: > https://github.com/jrblevin/markdown-mode/issues/753 The contributor thinks their fix for another problem also solves the = issue I raised, but I don=E2=80=99t have the energy to argue with them. Yuan