From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Troy Brown Newsgroups: gmane.emacs.bugs Subject: bug#74807: 30.0.90; Eglot: Non-Markdown strings rendered as Markdown Date: Mon, 6 Jan 2025 18:56:39 -0500 Message-ID: References: <86y100t6i7.fsf@gnu.org> <87bjwkkvfq.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="31578"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 74807@debbugs.gnu.org, felician.nemeth@gmail.com 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 Tue Jan 07 00:57:13 2025 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 1tUwy9-00082s-A8 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 Jan 2025 00:57:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUwxz-0005DC-S4; Mon, 06 Jan 2025 18:57:03 -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 1tUwxy-0005Cx-BF for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 18:57:02 -0500 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 1tUwxy-0001MY-2G for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 18:57:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:From:In-Reply-To:References:MIME-Version:To:Subject; bh=TqLFrmkXPo6XVhFiFOOiDhnq6HEfDGxPS74aFA0HD0g=; b=LT4CNlyo6qf7ydJzoyKmM5qfV12DJrH5U+YLdvrVfivsza4JcvWZNNiafyiMuCECi3kvRkPUH8kpV2s9VGTzn1inxi5KRQFNdsz8eNVgN7SxitUntbLWVLuyDKn6lIHeZDEcRg6O62v85MskYGl1RxuaxN7gwvWemLDTCS7Eo7StWxFepUBHwxGBH9MwkmndsU26q7euxGCbnj6EtuOk0xZDnp+fKFtYWKIYtHdg7r5Fi2Gpc8hzOOOBUOcpp6lWFWlyrVSyIBnqQLtK2/KXRi8K/OMLYtwYNf90oEO1AUmrCTSRdDK1LcrRtqg5dfopPm0J01fihb+JOJ8lzQQnog==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUwxx-0002ej-SS for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 18:57:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Troy Brown Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jan 2025 23:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74807 X-GNU-PR-Package: emacs Original-Received: via spool by 74807-submit@debbugs.gnu.org id=B74807.173620781910200 (code B ref 74807); Mon, 06 Jan 2025 23:57:01 +0000 Original-Received: (at 74807) by debbugs.gnu.org; 6 Jan 2025 23:56:59 +0000 Original-Received: from localhost ([127.0.0.1]:40999 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUwxv-0002eR-1i for submit@debbugs.gnu.org; Mon, 06 Jan 2025 18:56:59 -0500 Original-Received: from mail-ed1-f49.google.com ([209.85.208.49]:61743) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tUwxt-0002eE-DU for 74807@debbugs.gnu.org; Mon, 06 Jan 2025 18:56:58 -0500 Original-Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-5d3d0205bd5so22818124a12.3 for <74807@debbugs.gnu.org>; Mon, 06 Jan 2025 15:56:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736207811; x=1736812611; 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=TqLFrmkXPo6XVhFiFOOiDhnq6HEfDGxPS74aFA0HD0g=; b=rBtltVWImO8W8s0BJAye0gmDDb9C6LH0VWMpVuoS6K9GzNZVh03mZzkWwB4RCCeYJK oaCvg+I0L3bcdKNOdGsFbaLq76G4U6hM57t48Hx5assMDgc6K6DC7FxyxVpnNtaOmV4J QeOopIZhDLiZZHtDF0PFHOdvkcvlaPglecFP1G88gJdvRLaqrjiwZ7Zyie5IVtjD3/3Z vvr+79KTq8BBXfIcnUALoCwk+sYJT4TNkdal0SHI2QJ96NW7wu8JJBrFXpsKINi1DKif NTIWsKHZOcJMYJVGBIJSNjrcZOpU/3yagibiLlIoJR0dJ1HEy65HIaBCrLz04/hcv/d5 dBUw== X-Forwarded-Encrypted: i=1; AJvYcCUqHKsDDP07sy+D215Mj9V6tAWL7HG79lmuoelmBufu4/hdQSbDDqg2ZG9H+7DJtWrFG5Xd1A==@debbugs.gnu.org X-Gm-Message-State: AOJu0Ywd2ZY7b/qXJ2m/DW/gHfLTt6N2Zz7TvFeId1Y/mDb97xKjBzIU RocStEtktPP0dcmzSz/lHp5T6h1tAB/J+QdaKwnIVAifAaRNxxr/zp4S48X9ad4= X-Gm-Gg: ASbGnct/E+Tyu5FHhTBobtU+bOEZ38772lEP2JSv/+RyDcUJVlEMMeOsz1MtzrfjrZw v2quzwfKDSef26a6UF7Nm4AGdSLcmBQJm2FzoLyxCxY3Exf8rlYR7Axlfn0cTuw5rLJT7ZYWX7H 7x1EwVuEL/NcWJLNpWgVwm0pB9YbrNrNDDkrrX40bf/wfGBSI91TkjAtCm2zZngwRmdpuqav839 NcbuarGUtL4jCes1c2+u3or+50Hbq3uIwkwgJvZ4XZjD910zNVNvNtLq3/hgNzol+V4LN4POqCK JIBe9f9R527HK81+1lpF X-Google-Smtp-Source: AGHT+IEqrC88PmtSaS5SZ5njdqeEWg2xdXOdyJ1X6iW9W4znB+a1prhpBYEoGxJMHlJDGm0Zz7bhsg== X-Received: by 2002:a05:6402:5207:b0:5d0:bcdd:ff8f with SMTP id 4fb4d7f45d1cf-5d81dd5ed91mr53630204a12.4.1736207811065; Mon, 06 Jan 2025 15:56:51 -0800 (PST) Original-Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com. [209.85.218.48]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d8f51faaf8sm8206938a12.2.2025.01.06.15.56.50 for <74807@debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jan 2025 15:56:50 -0800 (PST) Original-Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-aa67ac42819so2152755066b.0 for <74807@debbugs.gnu.org>; Mon, 06 Jan 2025 15:56:50 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCXYzo2CuwlJwheR3LYxzBq1150oOhsVDkRvh9O+JinbT9ZoL6GZ3sfDbFN0nO47nMLcK6v3pA==@debbugs.gnu.org X-Received: by 2002:a17:906:730f:b0:aa6:80ed:e9a3 with SMTP id a640c23a62f3a-aac2d47a722mr5930290466b.35.1736207810411; Mon, 06 Jan 2025 15:56:50 -0800 (PST) In-Reply-To: <87bjwkkvfq.fsf@gmail.com> X-Gmail-Original-Message-ID: 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:298705 Archived-At: On Mon, Jan 6, 2025 at 6:56=E2=80=AFAM Jo=C3=A3o T=C3=A1vora wrote: > > Hello Troy, I've finally had time to look at your bug report. Thanks, I appreciate it. > > > I've run across a situation where Eglot receives a documentation > > string as part of a "completionItem/resolve". The documentation is > > being provided as a regular "string", not MarkupContent, yet it is > > being rendered as markup. Since the string contains characters which > > are being interpreted as markdown (e.g., ":"), it causes the > > documentation to be rendered incorrectly. > > After perusing the spec, I'm not sure the simple strings cannot be > rendered as Markdown by the client. The spec doesn't seem to > disambiguate this. All it says about the documentation field of a > Completion structure, besides its polymorphic type, is that it is a > > /** > * A human-readable string that represents a doc-comment. > */ > documentation?: string | MarkupContent; > > > Anyway I think if the server wants to ensure something is _not_ rendered > as Markdown it should use the more advanced MarkupContent structure and > explicitly specify 'plaintext' in its MarkupKind field. > > I understand this sounds counter-intuitive, but I have to be very > careful to do these kinds of changes. As you know, Eglot works with a > large body of servers, and I wouldn't be at all surprised that some of > those servers (or, more importantly, regulat users of those servers) do > actually expect plain strings to be rendered as Markdown when such a > renderer is available. > I'm fairly confident that plain text is heavily implied by the type being "string". If the spec wanted to indicate that the string could be markup, it would have been specified as "MarkedString" instead of "string", like this: documentation?: MarkedString | MarkupContent; The fact that it is specified as "string" strongly suggests that this was intentional in order to indicate that it does not contain markup. I understand, and appreciate your careful consideration of these kinds of changes, however even the VSCode implementation does not treat this as markdown, as can be seen at the following link where when the CompletionItem.documentation is a "string", the markdown renderer is not applied to the documentation: https://github.com/microsoft/vscode/blob/aaa576acca01852119f6a6b0260cf5a= a74a30c58/src/vs/editor/contrib/suggest/browser/suggestWidgetDetails.ts#L16= 8-L185 Furthermore, I would think that if, as you suggest, there were servers which expected plain strings to be rendered as Markdown here, the VSCode implementation would not avoid rendering plain strings as markdown. > Lastly, and adding to my reluctance to address this in code, I don't > understand what ':' is tripping the renderer here. Last I checked, ':' > doesn't have any special meaning in Markdown, especially in the middle > of the sequence. Emacs's `markdown-view-mode` from the markdown.el > package does give the left and right parts of: > > Indentation kind: spaces | tabs > > a different face (I don't know why, the online renderers I've tried do > not do that). But I wouldn't say it is being rendered "incorrectly". > While you might argue that the example I've shown is a fringe example, I'm sure you could envision other documentation content which uses characters which are interpreted as markup, and shouldn't be. I stand by my wording of "rendered incorrectly" when based on the content of the documentation, you might see it displayed differently, possibly more severely based on the documentation content. > Anyway, I lean strongly towards not touching this. I hope you reconsider, given the additional information I've provided. Thanks, Troy.