From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#35885: 25.2; Few mistakes in Emacs Manual (+ proposals) Date: Wed, 05 Jun 2019 19:52:57 +0300 Message-ID: <83muiwrn2u.fsf@gnu.org> References: <83k1e2tym6.fsf@gnu.org> <835zpltme6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="78781"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35885@debbugs.gnu.org To: Sebastian Urban Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jun 05 18:54:16 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hYZB2-000KMF-2E for geb-bug-gnu-emacs@m.gmane.org; Wed, 05 Jun 2019 18:54:16 +0200 Original-Received: from localhost ([127.0.0.1]:46454 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hYZB0-0002gB-Vo for geb-bug-gnu-emacs@m.gmane.org; Wed, 05 Jun 2019 12:54:15 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44936) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hYZAt-0002g4-On for bug-gnu-emacs@gnu.org; Wed, 05 Jun 2019 12:54:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hYZAp-0003kO-55 for bug-gnu-emacs@gnu.org; Wed, 05 Jun 2019 12:54:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34509) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hYZAo-0003iz-8I for bug-gnu-emacs@gnu.org; Wed, 05 Jun 2019 12:54:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hYZAo-000800-5S for bug-gnu-emacs@gnu.org; Wed, 05 Jun 2019 12:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 Jun 2019 16:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35885 X-GNU-PR-Package: emacs Original-Received: via spool by 35885-submit@debbugs.gnu.org id=B35885.155975360030699 (code B ref 35885); Wed, 05 Jun 2019 16:54:02 +0000 Original-Received: (at 35885) by debbugs.gnu.org; 5 Jun 2019 16:53:20 +0000 Original-Received: from localhost ([127.0.0.1]:48052 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hYZA7-0007z4-Jc for submit@debbugs.gnu.org; Wed, 05 Jun 2019 12:53:20 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58637) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hYZA6-0007ys-4z for 35885@debbugs.gnu.org; Wed, 05 Jun 2019 12:53:18 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hYZA0-0002gv-Ub; Wed, 05 Jun 2019 12:53:12 -0400 Original-Received: from [176.228.60.248] (port=4663 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hYZA0-0003k5-Da; Wed, 05 Jun 2019 12:53:12 -0400 In-reply-to: (message from Sebastian Urban on Wed, 5 Jun 2019 12:40:29 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:160161 Archived-At: > From: Sebastian Urban > Cc: 35885@debbugs.gnu.org > Date: Wed, 5 Jun 2019 12:40:29 +0200 > > > @t{} is the best trick we have for these characters, so if it doesn't > > work, someone will have to suggest a better way and verify it works in > > PDF. At the time we tried other methods, but AFAIR they were worse. > > Hmmm... if I use @t{“} (but without \rawbackslash \plainfrenchspacing) > or {\ttfamily “} or \texttt{“} in my 'test.tex' -> 'test.pdf' it > prints left double quotation mark correctly (i.e. in typewriter > shape), so... maybe there is something wrong with \rawbackslash or > \plainfrenchspacing or you used some older tex distribution with bug? > > Also '\tt' inside @t{} as stated in "LATEX2e: An unofficial reference > manual" (November 2018) is "older version of font switching", so maybe > try newer - '\ttfamily', unless this was intentional. Sorry, I don't understand what this means in practice. We don't use TeX/LaTeX in the manuals, we use Texinfo, so any raw TeX commands could only come from texinfo.tex. Is that where you saw \rawbackslash etc.? If not, where did you see them? > As I mentioned before @t{``} and t@{''} would do the job, but I think > putting specific characters, i.e. “ and ” is intended. Yes, we intend to put these specific characters. > > Does @kbd{`like this'} work? I don't want to use @t here, as this is > > keyboard input. > > ... > > Does @kbd{``like this''} work? > > Hmmm... I still don't know how to turn texi to pdf, so please don't > expect 100% answers, but I'm guessing it could work. I changed that to @kbd already, so I guess we should leave that for now, and wait for complaints. > Also you forgot about 4th occurrence there, but this is l/r double > quotation mark problem so... That's why I didn't do anything about it, yes. > >> In DISPLAY.TEXI - L1560: > >> # If the curved quotes @samp{‘}, @samp{’}, @samp{“}, and @samp{”} are > >> Well here we have @samp{...} instead of @t{...}, which also fails to > >> show “ and ”, displaying instead \ and " (just like @t{...}). But > >> it looks good in HTML. > > > > I changed them all to use @t{}. > > Please revert this change. I'm not sure what is the role of @samp{}, > but they are everywhere in the manual. @samp is used a lot, but there's no reason to use it in the above context. If nothing else, it looks badly in Info, because it produces an extra pair of quotes. I used @t{} because it produces the best results with quotes, AFAIR. > I think they exist to distinguish inserted (by something/someone in > Emacs) characters that are not part of the main text - they differ > form @t{}, because they add l/r single quotation marks in main > (normal) text shape around character. With them we have problem > only with l/r double quotation mark, with @t{} problem won't be > fixed and it'll cause additional problems with some of the rest of > quotes in this part of text. Once again, I think @t produces the best results with quotes. That was AFAIR our conclusion from when we worked on this issue during development of Emacs 26.1. If you can show that the PDF which is produced by that is incorrect, then we could try other methods, but they all require producing PDF and examining the results, there's no "correct" and "incorrect" method here by any other criteria. > Also I'm beginning to think, that our quotes should use @samp rather > than @t. For example in "Inserting text" chapter if something inserts > thing, this thing is using @samp: user inserts ordinary graphic > character ‘a’, ‘B’, ‘3’, ‘=’, "C-q DEL" inserts ‘DEL’, "C-q 1 0 1 B" > inserts ‘AB’. Maybe @t{} with "quotes" is mistake. That's not how I recollect this. I think we originally did use @samp, but moved to @t in the case of quotes because @samp gave sub-optimal or even incorrect results. > > In PDF 22.5 Quotation Marks: > > ... > > I don't understand why do we need to move away from @t{}. the comment > > clearly says that @t{} was found to do the job here. What am I > > missing? > > Text says "using straight apostrophes" and with @t{'like this'} we'll > get curved ones (attached "pic2"). So @kbd{'like this'} should be ok. I see nothing wrong with pic2, that's just how PDF renders "straight apostrophes". So I see no reason to move away from @t in this case. > > Why? `..' is converted by TeX to curve single quotes, and ``..'' to > > curve double quotes. What do you see in the PDF? > > Yes, but they are in main text shape, not typewriter (again "pic2"). I don't understand what problems you see in the shape, the text as typeset looks OK to me. > > In TEXT.TEXI - L448: > > ... > > In TEXT.TEXI - L469: > > You forgot about these, I cannot think of a solution for them. I didn't forget, I just didn't know what to do, so I did nothing. > As for Unicode, after reading your explanation and checking "The > Unicode Standard Version 12.0 – Core Specification" they seem to use > small caps for the name that is written in lowercase and main text > font for code with uppercase 'U' and letters if any in the code. > > I can agree for small caps for name (lowercase!), but for code we > should go with @code{} - reason for this is that there are other > Unicode codes in the manual and they have @code{} "face", also > with main text or small caps Unicode code looks uglier (depends on > font) - letters are wider than numbers (sometimes higher), while with > typewriter (@code{}) they are equal. > > So, my choice is: > @code{U+201D} @sc{right double quotation mark} > > But if you really want to go with how Unicode docs do it, then: > U+201D @sc{right double quotation mark} OK, done. > In INFO 15.10.4 (description of 'comma'): > ... You can also type ‘C-x u’ to undo the replacement; this exits the > ‘query-replace’,... > I just want to point out that other undo commands also work, > so maybe: > ... You can also type any undo command to undo the replacement;... > or maybe combine both: > ... You can also type any undo command (e.g. 'C-x u') to undo the... > Or is it nitpicking again? :) I rearranged the words there to indicate that there other bindings of 'undo'. Thanks.