From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: Display of em dashes in our documentation Date: Fri, 8 Oct 2021 13:17:07 -0400 Message-ID: References: <4209edd83cfee7c84b2d75ebfcd38784fa21b23c.camel@crossproduct.net> <87v92ft9z6.fsf@db48x.net> <87o885tyle.fsf@db48x.net> <83k0it6lu5.fsf@gnu.org> <87k0isu7hz.fsf_-_@db48x.net> <87a6jotszy.fsf@db48x.net> <877der8smr.fsf@mail.linkov.net> <83y2772y0s.fsf@gnu.org> <83sfxd1g05.fsf@gnu.org> <83tuhtyn46.fsf@gnu.org> <83o880zuxs.fsf@gnu.org> <838rz4ypkt.fsf@gnu.org> <83o87zxzql.fsf@gnu.org> 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="14620"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, yuri.v.khan@gmail.com, juri@linkov.net, db48x@db48x.net, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 08 19:18:37 2021 Return-path: Envelope-to: ged-emacs-devel@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 1mYtW1-0003c2-95 for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Oct 2021 19:18:37 +0200 Original-Received: from localhost ([::1]:56450 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYtW0-0007f9-4v for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Oct 2021 13:18:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58750) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYtUe-0005eS-2W for emacs-devel@gnu.org; Fri, 08 Oct 2021 13:17:12 -0400 Original-Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]:36831) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mYtUc-0007Dg-B1; Fri, 08 Oct 2021 13:17:11 -0400 Original-Received: by mail-pf1-x430.google.com with SMTP id m26so8795162pff.3; Fri, 08 Oct 2021 10:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=i7qQMvNbDXI652B4nPoOX0EgvE9iUVWwXMETCO9m31U=; b=BHvQsfLIWTPrt4Bp3mR9Oep+6YfVzPkBnSOadhw4LEP2qjzzZ9BpPtEU45Z+/J7qmF bb/QlriwVODnJFhNP9EXXq2vJ0jSRzaKax8ol76+PgNkmcnrVziaVK6jjfjRh/VAas/s sTfpGve4fhd+pg7gwhGUiDUGhd75P/tEzr8UVWPt7w/DvVUj0IoKm4+AQHBPQ3yhqKgZ Oa/L5q0skdoFuQnLXiZWKKfs8XKB9j+oB+CsgiKSxaP6L7axfXK52e9hsMkinlf+ykLX hQyKJqL4O/3rS+DOWvXyMXw22aiA3F9P8/95gO/M0gxHE4ehafnfK0/SJxfi3wVIBCt5 2AeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=i7qQMvNbDXI652B4nPoOX0EgvE9iUVWwXMETCO9m31U=; b=f1kXYC/qoKrUqER6TkLmM/wupEEVX9wKndp1qx1IpLgefOcPYP9Hji0SprqA4Zf5cP Ulm9HPi4yxH2v6UcEPFrt7prp2jMSDjMnapmdisV47fLgzgpHzHAgFVWUVWIsHwQXky/ lA8P4EIjQTW1Glf39j5owV1JSyrlSa2A7gvdnpKpperkyHzRdo4Kw682pPbu2UzatIq6 cMb+8FAbPiCwahE6MzMg9ftwvxEPa0rTJRUJWAn/7znddhHl0IRdR2RvLH+M2Hxoi/y9 uv+BinaUSG/V00To1psunmT9ijzWRLxWBk8yhSmYtlGQz69t3RFHePakGL62ZS1KiZm8 MHYQ== X-Gm-Message-State: AOAM530ClnrxNTXWv5Vs48x9B1GuX34LThE6q64PWOBtvb/5yhvMYrSN qjs4dUrgJ2Vqmm1cQyiPpxhkhlkWeSas5Zf2yxq3b65x X-Google-Smtp-Source: ABdhPJyLHgyDQE7dCPalBtWsRABHVU0qzPeQMyLA5LOdrqvzStqLgguOQKkxwAvDgdog6rY/7Q1VZ6jZaVfXMTJmkXQ= X-Received: by 2002:a63:4717:: with SMTP id u23mr5627523pga.359.1633713428071; Fri, 08 Oct 2021 10:17:08 -0700 (PDT) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 8 Oct 2021 13:17:07 -0400 In-Reply-To: <83o87zxzql.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::430; envelope-from=stefankangas@gmail.com; helo=mail-pf1-x430.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:276570 Archived-At: Eli Zaretskii writes: >> One drawback is that em dash is only confirmed to be problematic in some >> situations; that is when they are written "like=E2=80=94this" with no sp= ace in >> between, whereas in situations "like =E2=80=94 this" I think it is much >> preferable to show the actual Unicode character. > > That's splitting hair, IMO. The latter should never happen in a > well-written manual. Even if your second claim is true, your proposal, IIUC, is that this mode could be used even outside of Info-mode. If we introduce a mode that fixes this in some cases, there is a risk that it will lead to suboptimal results in others. I do not think that pointing this out is unimportant or "splitting hairs". > What will that do to byte offsets in Info tag tables? I'd rather > avoid modifying the buffer contents. What do you mean by "byte-offsets in Info tag tables"? Do you mean that this approach risks leaving a table misaligned? If so, I think that is correct, and clearly a drawback. I don't see an easy way around it with this approach (but I also don't see a scenario when you would properly use an em dash in a table). I agree that it would be better not to modify the buffer contents, but IIUC that would require changes in Texinfo to support this use-case. >> In any monospace font, I certainly prefer this: >> >> When =E2=80=98recover-session=E2=80=99 is done, the files you=E2= =80=99ve chosen to recover >> are present in Emacs buffers. You should then save them. Only >> this =E2=80=94 saving them =E2=80=94 updates the files themselves. [...] > > But that's against our style of writing documents, isn't it? I > believe the usual US English style is not to leave whitespace around > em dash. We have discussed this up-thread, and the situation is clear: the most common style in printed books is to not use whitespace, whereas in papers and magazines the most common style is to use whitespace. Both approaches are valid and commonly used in properly written English. AFAIK, there is no consensus about how this should be handled when you render text in a monospace font for display on a screen. No one has presented any evidence that such a consensus exists. I don't know, but I assume that the reason that Texinfo doesn't leave space around em dash is because this is considered undesirable in printed manuals. But I believe treating the printed manual as exactly analogous to the screen is a mistake here; the practical considerations that made Texinfo render em dash as "--" in the past still apply when using UTF-8, as long as the result is intended for display in a mono-space font. The better solution in that case is to render it as " =E2=80=94 " or "--", even when the rest of the text is UTF-8. But with all this, I am actually beginning to wonder if this shouldn't properly be fixed in Texinfo itself.