From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Newsgroups: gmane.emacs.bugs Subject: bug#44155: Print integers as characters Date: Sun, 1 Nov 2020 21:52:13 +0100 Message-ID: <608FF40B-D8F6-471E-8036-4779D892E987@acm.org> References: <871rhd3peq.fsf@mail.linkov.net> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) 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="16676"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 44155@debbugs.gnu.org, Andreas Schwab To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Nov 01 21:54:40 2020 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 1kZKN5-0004AV-W9 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 Nov 2020 21:54:40 +0100 Original-Received: from localhost ([::1]:38668 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZKN5-0002GJ-1h for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 Nov 2020 15:54:39 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59170) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZKLW-0001IZ-Qm for bug-gnu-emacs@gnu.org; Sun, 01 Nov 2020 15:53:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55414) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kZKLW-0004R5-Fv for bug-gnu-emacs@gnu.org; Sun, 01 Nov 2020 15:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kZKLW-0003ms-CV for bug-gnu-emacs@gnu.org; Sun, 01 Nov 2020 15:53:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 Nov 2020 20:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44155 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed patch Original-Received: via spool by 44155-submit@debbugs.gnu.org id=B44155.160426394114511 (code B ref 44155); Sun, 01 Nov 2020 20:53:02 +0000 Original-Received: (at 44155) by debbugs.gnu.org; 1 Nov 2020 20:52:21 +0000 Original-Received: from localhost ([127.0.0.1]:38727 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZKKr-0003lz-6v for submit@debbugs.gnu.org; Sun, 01 Nov 2020 15:52:21 -0500 Original-Received: from mail79c50.megamailservers.eu ([91.136.10.89]:57304 helo=mail70c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZKKo-0003ln-Cf for 44155@debbugs.gnu.org; Sun, 01 Nov 2020 15:52:19 -0500 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1604263936; bh=DoGNgfCylmswWlRFHhO6ISIJLBGSoVp7VdslascUVNI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=snazuK1Y8uZY50CLrAOCCCpQqa4jfa63tOzY87FAugIG1ueuPOVBCQtxdbj4rq8SF TJ9mLEq89Hg8xSXI0SS+kX1MfPOAzaZ0clKcIMxCKtYIOzR/hCaiRhneRa4Rm7FU/v AKrtaNxZwgmIUSQaV/r1/SF2pYUTSvobdEqIFd/g= Feedback-ID: mattiase@acm.or Original-Received: from [192.168.0.4] (c188-150-171-71.bredband.comhem.se [188.150.171.71]) (authenticated bits=0) by mail70c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 0A1KqDnk023427; Sun, 1 Nov 2020 20:52:15 +0000 In-Reply-To: <871rhd3peq.fsf@mail.linkov.net> X-Mailer: Apple Mail (2.3445.104.17) X-CTCH-RefID: str=0001.0A782F1C.5F9F2000.002E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=OKBZIhSB c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=IkcTkHD0fZMA:10 a=M51BFTxLslgA:10 a=ucMQw-l_AAAA:8 a=cQ7_6-hZ4EWDXOCf840A:9 a=QEXdDO2ut3YA:10 a=xkTruGkd22MpkFU079mG:22 X-Origin-Country: SE 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" Xref: news.gmane.io gmane.emacs.bugs:192467 Archived-At: 1 nov. 2020 kl. 19.35 skrev Juri Linkov : > Thanks for bringing a fresh perspective to this feature request. You are very graceful. The devil is in the details, as always! > (prin1-char 10) ?\C-j > (prin1-char 127) ?\C-? >=20 > Or should 10 be printed as '?\n'? Yes, I think ?\n is more useful. As a character, 10 is more commonly = thought of as newline than as control-j. >> What to use for the rest depends on the user's preference really -- >> for example, 31 might be printed as 31, ?\037, #o37 or #x1f. >=20 > Maybe more user choices should be supported by the variable? Maybe, but only if we can identify sensible such choices. Otherwise we = should just try to pick the best representation in each case. Giving = users too much choice isn't necessarily making them a favour! I'd suggest plain number syntax for control characters without named = escapes, for several reasons: * Such numbers are less likely to represent characters and more likely = to be, well, numbers. * It would allow a separate radix control to govern their output format. * Writing ?\x1f is no clearer than #x1f, and sometimes more confusing: = \xff is a raw byte in a string, but ?\xff is always 255. Thus we would have 10 -> ?\n, 13 -> ?\r, 127 -> ?\d, 65 -> ?A, 255 -> = ?=C3=BF, but 31 -> 31, 129 -> 129, 4194303 -> 4194303. >> Whether to print 32 as ?=E2=80=B9SPACE=E2=80=BA or ?\s is a matter of = taste. >=20 > ?\s is less error-prone. Yes, I agree. (I prefer ?\s or 32 as characters, but " " in strings.) >> For that matter, the variable name should perhaps start with 'print-' >> like other variables that control printing. Maybe we should separate >> the default radix and print integers as characters? Thus, we'd have: >=20 > The variable name was modeled after the similar variable = float-output-format. I see, interesting! One possibility would be to use a string in the same = way, thus "%x", "%c" etc, but it makes less sense for integers than = floating-point: no precision field, and many format alternatives such as = %#x do not produce valid Lisp read syntax. Better keep it simple. >> print-integer-radix -- 2, 8, 16, 10 or nil (which means 10) >>=20 >> print-integers-as-characters -- nil or t >=20 > What should be printed when both variables are bound to non-default = values, > e.g. print-integers-as-characters to t, and print-integer-radix to 16? > Maybe to print with character syntax and the given radix, e.g. = '?\x1f'. Well, it should clearly use character syntax for printable characters = and the given radix for non-characters. As you correctly point out, what = to use for non-printable characters (C0 and C1 controls, raw bytes) is = less obvious. I'd probably just use the given radix; I see no = readability advantage in printing ?\x1f to #x1f. Since your original motivation was to print characters in pretty-printed = nested Lisp expressions, perhaps we should just define = print-integers-as-characters as a Boolean and skip the radix for the = time being? We could add a print radix control later on if desired. = (That would save us the hassle to deal with bignums, for that matter.)