bug#24902: 25.1; C-x = for Unicode

bug#24902: 25.1; C-x = for Unicode

[Ulrich Windl]

When trying to insert a Unicode character using new C-X 8 RET, I
realized that C-x = does not print the unicode name of the character,
but just "Char: ‒ (8210, #o20022, #x2012) point=146 of 146 (99%)
column=0" (for example).

I think it would be a logical extension to display the Unicode character
name also for C-x =.



In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
 of 2016-09-17 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
 'configure --without-dbus --without-compress-install CFLAGS=-static'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: DEU
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  shell-dirtrack-mode: t
  show-paren-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
c is undefined
mouse-2, RET: find variable's definition
C-c C-, is undefined
C-c C-; is undefined
Making completion list...
Char: ‒ (8210, #o20022, #x2012) point=146 of 146 (99%) column=0
ad-Advice-delete-char: Text is read-only [2 times]
Making completion list... [2 times]
ad-Advice-delete-char: Text is read-only
Making completion list... [2 times]

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired rfc822 mml mml-sec epg
epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mail-utils
iso-transl apropos noutline outline view ido seq ess-toolbar ess-mouse
ess-dde mouseme thingatpt browse-url ess-menu ess-swv ess-noweb
ess-noweb-font-lock-mode ess-bugs-l essd-els ess-sas-d ess-sas-l
ess-sas-a ess-sta-d ess-sta-l cc-vars cc-defs make-regexp ess-sp6w-d
ess-sp3-d ess-julia julia-mode ert pp find-func ewoc debug rx derived
ess-r-d ess-r-syntax ess-r-completion ess-roxy essddr hideshow ess-help
info reporter ess-r-package ess-s-l speedbar sb-image ezimage dframe ess
ess-inf ess-tracebug easy-mmode compile ess-mode ess-noweb-mode edmacro
kmacro ess-utils tramp tramp-compat auth-source cl-seq eieio byte-opt
bytecomp byte-compile cl-extra cconv eieio-core gnus-util mm-util
help-fns help-mode mail-prsvr password-cache tramp-loaddefs cl-macs
trampver ucs-normalize shell pcomplete comint ansi-color ring
format-spec advice ess-generics cl gv cl-loaddefs pcase cl-lib
ess-custom executable easymenu ess-compat ess-site paren cus-start
cus-load time-date mule-util tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
w32notify w32 multi-tty make-network-process emacs)

Memory information:
((conses 16 436320 22595)
 (symbols 56 40634 0)
 (miscs 48 169 311)
 (strings 32 102604 15754)
 (string-bytes 1 2535070)
 (vectors 16 49188)
 (vector-slots 8 1666056 249236)
 (floats 8 313 446)
 (intervals 56 2161 22)
 (buffers 976 27)) 

bug#24902: 25.1; C-x = for Unicode

[Andreas Schwab]

On Nov 08 2016, "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> wrote:

> When trying to insert a Unicode character using new C-X 8 RET, I
> realized that C-x = does not print the unicode name of the character,

C-u C-x = does.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#24902: 25.1; C-x = for Unicode

[Phil Sainty]

On 09/11/16 01:02, Ulrich Windl wrote:
> I think it would be a logical extension to display the Unicode
> character name also for C-x =.

With a prefix argument -- C-u C-x = -- the unicode character name
is displayed amongst all the extended information (and the customize
interface allows many additional unicode properties to be added to
that display).

I'm not sure whether you are unaware of the prefix arg behaviour,
or just think this particular value should be added to the standard
output?

bug#24902: Antw: Re: bug#24902: 25.1; C-x = for Unicode

[Ulrich Windl]

>>> Andreas Schwab <schwab@suse.de> schrieb am 08.11.2016 um 13:23 in
Nachricht
<mvmbmxqdutq.fsf@hawking.suse.de>:
> On Nov 08 2016, "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> wrote:
> 
>> When trying to insert a Unicode character using new C-X 8 RET, I
>> realized that C-x = does not print the unicode name of the character,
> 
> C-u C-x = does.

Oops, right! But the result is not a status line, but a new window with _lots_
of information, like this (for a different character):
---
             position: 146 of 146 (99%), column: 0
            character:   (displayed as  ) (codepoint 8199, #o20007, #x2007)
    preferred charset: unicode (Unicode (ISO10646))
code point in charset: 0x2007
               script: symbol
               syntax:   	which means: whitespace
             category: .:Base
             to input: type "C-x 8 RET 2007" or "C-x 8 RET FIGURE SPACE"
          buffer code: #xE2 #x80 #x87
            file code: not encodable by coding system iso-latin-1-dos
              display: by this font (glyph code)
    uniscribe:-outline-Courier
New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x03)

Character code properties: customize what to show
  name: FIGURE SPACE
  general-category: Zs (Separator, Space)
  decomposition: (noBreak 32) (noBreak ' ')

There are text properties here:
  fontified            nil
---

What I'd like to see is something like this:
"Char:   (8199, #o20007, #x2007, "FIGURE SPACE") point=146 of 146 (99%)
column=0"

Ulrich

bug#24902: Antw: Re: bug#24902: 25.1; C-x = for Unicode

[Phil Sainty]

On 09/11/16 02:49, Ulrich Windl wrote:
> What I'd like to see is something like this:
> "Char:   (8199, #o20007, #x2007, "FIGURE SPACE") point=880 of 880 (99%)
> column=0"

For long unicode names that's more like:

"Char:   (11137, #o25601, #x2b81, "UPWARDS TRIANGLE-HEADED ARROW
LEFTWARDS OF DOWNWARDS TRIANGLE-HEADED ARROW", file ...) point=146 of
146 (99%) column=0"

Which is definitely wrapping in an 80 column terminal.

bug#24902: Antw: Re: bug#24902: 25.1; C-x = for Unicode

[Marcin Borkowski]

On 2016-11-08, at 20:53, Phil Sainty <psainty@orcon.net.nz> wrote:

> On 09/11/16 02:49, Ulrich Windl wrote:
>> What I'd like to see is something like this:
>> "Char:   (8199, #o20007, #x2007, "FIGURE SPACE") point=880 of 880 (99%)
>> column=0"
>
> For long unicode names that's more like:
>
> "Char:   (11137, #o25601, #x2b81, "UPWARDS TRIANGLE-HEADED ARROW
> LEFTWARDS OF DOWNWARDS TRIANGLE-HEADED ARROW", file ...) point=146 of
> 146 (99%) column=0"
>
> Which is definitely wrapping in an 80 column terminal.

Fair enough.  OTOH, I =was= aware of C-u C-x =, but I'd still want the
behavior Ulrich wrote about, possibly enabled through an option.
I could actually write a patch to do it, WDYT?

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

bug#24902: Antw: Re: bug#24902: 25.1; C-x = for Unicode

[Mark Oteiza]

Marcin Borkowski <mbork@amu.edu.pl> writes:
> On 2016-11-08, at 20:53, Phil Sainty <psainty@orcon.net.nz> wrote:
>
>> On 09/11/16 02:49, Ulrich Windl wrote:
>>> What I'd like to see is something like this:
>>> "Char:   (8199, #o20007, #x2007, "FIGURE SPACE") point=880 of 880 (99%)
>>> column=0"
>>
>> For long unicode names that's more like:
>>
>> "Char:   (11137, #o25601, #x2b81, "UPWARDS TRIANGLE-HEADED ARROW
>> LEFTWARDS OF DOWNWARDS TRIANGLE-HEADED ARROW", file ...) point=146 of
>> 146 (99%) column=0"
>>
>> Which is definitely wrapping in an 80 column terminal.
>
> Fair enough.  OTOH, I =was= aware of C-u C-x =, but I'd still want the
> behavior Ulrich wrote about, possibly enabled through an option.
> I could actually write a patch to do it, WDYT?

I think describe-char-eldoc is useful for this purpose

bug#24902: 25.1; C-x = for Unicode

[Lars Ingebrigtsen]

"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> writes:

> When trying to insert a Unicode character using new C-X 8 RET, I
> realized that C-x = does not print the unicode name of the character,
> but just "Char: ‒ (8210, #o20022, #x2012) point=146 of 146 (99%)
> column=0" (for example).
>
> I think it would be a logical extension to display the Unicode character
> name also for C-x =.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

As others noted, `C-u C-x =' does display this info, and the reason that
`C-x =' doesn't is because the names can be very long.  We could add a
user option to include it anyway, but in my opinion, it wouldn't be used
much, and users that want this could just add advice to the command to
do it instead.

So I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24902: 25.1; C-x = for Unicode

[Kévin Le Gouguec]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> writes:
>
>> When trying to insert a Unicode character using new C-X 8 RET, I
>> realized that C-x = does not print the unicode name of the character,
>> but just "Char: ‒ (8210, #o20022, #x2012) point=146 of 146 (99%)
>> column=0" (for example).
>>
>> I think it would be a logical extension to display the Unicode character
>> name also for C-x =.
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> As others noted, `C-u C-x =' does display this info, and the reason that
> `C-x =' doesn't is because the names can be very long.  We could add a
> user option to include it anyway, but in my opinion, it wouldn't be used
> much, and users that want this could just add advice to the command to
> do it instead.
>
> So I'm closing this bug report.

Note that Emacs 27 introduced what-cursor-show-names, which does exactly
what is requested in this report IIUC.

I'm a happy user of that option, FWIW.

bug#24902: 25.1; C-x = for Unicode

[Mattias Engdegård]

[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]

> As others noted, `C-u C-x =' does display this info, and the reason that `C-x =' doesn't is because the names can be very long. We could add a user option to include it anyway, but in my opinion, it wouldn't be used much, and users that want this could just add advice to the command to do it instead. 

If many users would be served by an improved format, perhaps a change would be warranted after all? My local version replaces the standard

 Char: α (945, #o1661, #x3b1, file ...) point=419 of 423 (99%) column=0

with

 U+03B1 GREEK SMALL LETTER ALPHA pt=419/423 col=0

To save space, remove noise, unnecessary and/or obsolete characters. U+HHHH is the standard notation for code values nowadays; I have little use for decimal and octal (octal!) numbers although I know how to get them if I want. Nor do I generally need to see the character itself; it's right under the cursor.

Now almost all Unicode character names fit very comfortably on a single line in the echo area, and for the rare ones that do not, this area expands.

I'm not going to reopen the bug but believe such a format (or something similar) would be much more helpful for the typical user. But don't take my word for it: try running something like the attached code yourself for a while and see if it doesn't make you happier.

I doubt much thought has gone into the present format; it's just an artefact of history.


[-- Attachment #2: my-what-cursor-position.el --]
[-- Type: application/octet-stream, Size: 1095 bytes --]

;;; -*- lexical-binding: t -*-

(defun my-what-cursor-position (&optional detail)
  "Like `what-cursor-position', but with important information only."
  (interactive "P")
  (if detail
      (what-cursor-position detail)
    (let* ((char (char-after))
           (char-info
            (cond
             ((null char) "")
             ((<= #x3fff80 char #x3fffff)
              (format "#x%02X (raw byte) " (logand char #xff)))
             (t
              (format "U+%04X %s "
                      char
                      (or (get-char-code-property char 'name)
                          (get-char-code-property char 'old-name)
                          "(undefined)")))))
           (beg (point-min))
           (end (point-max))
           (narrow (if (and (= beg 1) (= (1- end) (buffer-size)))
                       ""
                     (format " <%d-%d>" beg end))))
      (message "%spt=%d/%d%s col=%d"
               char-info
               (point) (buffer-size)
               narrow
               (current-column)))))

(global-set-key (kbd "C-x =") 'my-what-cursor-position)

bug#24902: 25.1; C-x = for Unicode

[Lars Ingebrigtsen]

Mattias Engdegård <mattiase@acm.org> writes:

> To save space, remove noise, unnecessary and/or obsolete
> characters. U+HHHH is the standard notation for code values nowadays;
> I have little use for decimal and octal (octal!) numbers although I
> know how to get them if I want. Nor do I generally need to see the
> character itself; it's right under the cursor.

Emacs defaults to showing some things in octal, so showing octal here
isn't that absurd...

> Now almost all Unicode character names fit very comfortably on a
> single line in the echo area, and for the rare ones that do not, this
> area expands.

`C-x 8 e d' says what the name of the character is.  Perhaps it should
also include the hex value...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24902: 25.1; C-x = for Unicode

[Mattias Engdegård]

24 jan. 2022 kl. 10.21 skrev Lars Ingebrigtsen <larsi@gnus.org>:

> Emacs defaults to showing some things in octal, so showing octal here
> isn't that absurd...

What things would that be? The only ones I can think of are raw bytes and some control characters.

The only reason why C-x = shows octal is inertia. If you wrote the command today, you would not include octal.

This is just another Immovable Ladder in Emacs. It must be preserved exactly as it is, for the sole reason that it has always been this way.

> `C-x 8 e d' says what the name of the character is.  Perhaps it should
> also include the hex value...

Or perhaps we could improve the more commonly used and accessible `C-x =` to show both?

I could write a patch to change it (with an option to keep the Good Old Times look for the traditionalist), but there's no point if it would be dismissed out of hand. Would it?

bug#24902: 25.1; C-x = for Unicode

[Lars Ingebrigtsen]

Mattias Engdegård <mattiase@acm.org> writes:

> What things would that be? The only ones I can think of are raw bytes
> and some control characters.

Yes, that's what I was thinking of.

> The only reason why C-x = shows octal is inertia. If you wrote the
> command today, you would not include octal.
>
> This is just another Immovable Ladder in Emacs. It must be preserved
> exactly as it is, for the sole reason that it has always been this
> way.

I never use octal myself and have configured Emacs to display raw bytes
as hex, so I agree with the first assertion.  But the latter isn't a
very friendly caricature.  The reason we don't remove all the octal
stuff from Emacs is that it'd annoy a significant number of people.

>> `C-x 8 e d' says what the name of the character is.  Perhaps it should
>> also include the hex value...
>
> Or perhaps we could improve the more commonly used and accessible `C-x
> =` to show both?
>
> I could write a patch to change it (with an option to keep the Good
> Old Times look for the traditionalist), but there's no point if it
> would be dismissed out of hand. Would it?

Making a format-spec thing for `C-x =' would be fine by me.

I don't understand the aggression here, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24902: 25.1; C-x = for Unicode

[Robert Pluim]

>>>>> On Mon, 24 Jan 2022 11:40:01 +0100, Mattias Engdegård <mattiase@acm.org> said:

    Mattias> 24 jan. 2022 kl. 10.21 skrev Lars Ingebrigtsen <larsi@gnus.org>:
    >> Emacs defaults to showing some things in octal, so showing octal here
    >> isn't that absurd...

    Mattias> What things would that be? The only ones I can think of are raw bytes and some control characters.

    Mattias> The only reason why C-x = shows octal is inertia. If you wrote the command today, you would not include octal.

    Mattias> This is just another Immovable Ladder in Emacs. It must be preserved
    Mattias> exactly as it is, for the sole reason that it has always been this
    Mattias> way.

    >> `C-x 8 e d' says what the name of the character is.  Perhaps it should
    >> also include the hex value...

    Mattias> Or perhaps we could improve the more commonly used and accessible `C-x =` to show both?

    Mattias> I could write a patch to change it (with an option to keep the Good
    Mattias> Old Times look for the traditionalist), but there's no point if it
    Mattias> would be dismissed out of hand. Would it?

I sense a discoverability issue related to 'what-cursor-show-names'
:-)

(FWIW I agree about the octal, but that is another discussion)

Robert
-- 

bug#24902: 25.1; C-x = for Unicode

[Robert Pluim]

>>>>> On Mon, 24 Jan 2022 12:00:31 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Making a format-spec thing for `C-x =' would be fine by me.

As long as that was for 'C-x =' only, and not 'C-u C-x =' I guess that
would be OK, although the only possible use I would have for it would
be to not show the octal. The octal is a very minor irritant, so Iʼm
not sure itʼs worth the effort.

Robert
-- 

bug#24902: 25.1; C-x = for Unicode

[Mattias Engdegård]

24 jan. 2022 kl. 12.00 skrev Lars Ingebrigtsen <larsi@gnus.org>:

>  The reason we don't remove all the octal
> stuff from Emacs is that it'd annoy a significant number of people.

Oh, that is perfectly understood, and please do believe that I'm not accusing you of stubborn conservatism! But being human, you and I both are capable of making sometimes less than perfect decisions for excellent reasons such as not wanting to annoy people. We then fail taking into account the people that are annoyed by these decisions.

There is no perfect solution to this problem but fearless discussion is a good start.

> Making a format-spec thing for `C-x =' would be fine by me.

That would of course also be possible, but I'm not sure the complexity (in implementing, maintaining and using it) would be warranted. What about just starting with two choices, old and new, while honouring the existing `what-cursor-show-names` variable in the former case? A more complex user-define format could be added as a later alternative.

> I don't understand the aggression here, though.

My sincerest apologies -- none were meant.

bug#24902: 25.1; C-x = for Unicode

[Mattias Engdegård]

[-- Attachment #1: Type: text/plain, Size: 233 bytes --]

Attached is a draft patch. It does not change the output of `describe-char`, which is invoked from `C-u C-x =`. The `traditional` format is unchanged; the new format is designed to be informative and reasonably free from clutter.


[-- Attachment #2: 0001-Cleaner-what-cursor-position-format.patch --]
[-- Type: application/octet-stream, Size: 6204 bytes --]

From 1893b401d5da2734e1588e98fbb45151af871088 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mattias=20Engdeg=C3=A5rd?= <mattiase@acm.org>
Date: Mon, 24 Jan 2022 16:49:08 +0100
Subject: [PATCH] Cleaner `what-cursor-position` format

Add a new `C-x =` output format, under the control of the new
`what-cursor-format` user option, that uses more modern formatting
and omits noise syntax and rarely used information.  It always
includes the character name.

* lisp/simple.el (what-cursor-format): New.
(what-cursor-show-names): Explain relation to `what-cursor-format`.
(what-cursor-position--default,
what-cursor-position--traditional): New functions.
(what-cursor-position): Reduce to calling the right back-end function.
* etc/NEWS: Announce.
---
 etc/NEWS       |  6 ++++
 lisp/simple.el | 78 ++++++++++++++++++++++++++++++++++++++------------
 2 files changed, 65 insertions(+), 19 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index 3f6b2d2a1f..a9b4151bd9 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -176,6 +176,12 @@ wheel reports.  Unlike 'pixel-scroll-mode', this mode scrolls the
 display pixel-by-pixel, as opposed to only animating line-by-line
 scrolls.
 
+** New user option 'what-cursor-format'
+It governs the output format of 'what-cursor-position', normally
+bound to 'C-x ='.  When 'traditional', the output is identical
+to that of Emacs 28; when 'default', a simpler, briefer format
+that always includes the character name is used.
+
 ** Terminal Emacs
 
 ---
diff --git a/lisp/simple.el b/lisp/simple.el
index 801a3c992c..c8eccd8ba8 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -1564,27 +1564,57 @@ count-lines
                  (1- (line-number-at-pos))
                (line-number-at-pos)))))))
 
+(defcustom what-cursor-format 'default
+  "What to show in the echo area in `what-cursor-position'.
+The `default' format gives the hex code and name of the character
+after point, the cursor position, buffer size, and column number.
+
+The `traditional' format also displays the code in decimal and octal,
+and only includes the name if `what-cursor-show-name' is non-nil.
+For a non-ASCII multibyte character, it also gives the encoding in the
+buffer's selected coding system if the coding system encodes the
+character safely.  If the character is encoded into one byte, that
+code is shown in hex.  If the character is encoded into more than one
+byte, just \"...\" is shown."
+  :type '(choice (const :tag "Default" default)
+                 (const :tag "Traditional" traditional))
+  :version "29.1"
+  :group 'editing-basics)
+
 (defcustom what-cursor-show-names nil
-  "Whether to show character names in `what-cursor-position'."
+  "Whether to show character names in `what-cursor-position'.
+It only applies when `what-cursor-format' is `traditional'."
   :type 'boolean
   :version "27.1"
   :group 'editing-basics)
 
-(defun what-cursor-position (&optional detail)
-  "Print info on cursor position (on screen and within buffer).
-Also describe the character after point, and give its character
-code in octal, decimal and hex.  If `what-cursor-show-names' is
-non-nil, additionally show the name of the character.
-
-For a non-ASCII multibyte character, also give its encoding in the
-buffer's selected coding system if the coding system encodes the
-character safely.  If the character is encoded into one byte, that
-code is shown in hex.  If the character is encoded into more than one
-byte, just \"...\" is shown.
-
-In addition, with prefix argument, show details about that character
-in *Help* buffer.  See also the command `describe-char'."
-  (interactive "P")
+(defun what-cursor-position--default ()
+  "Default echo area output of `what-cursor-position'."
+  (let* ((char (char-after))
+         (char-info
+          (cond
+           ((null char) "")
+           ((<= #x3fff80 char #x3fffff)
+            (format "#x%02X (raw byte) " (logand char #xff)))
+           (t
+            (format "U+%04X %s "
+                    char
+                    (or (get-char-code-property char 'name)
+                        (get-char-code-property char 'old-name)
+                        "(undefined)")))))
+         (beg (point-min))
+         (end (point-max))
+         (narrow (if (and (= beg 1) (= (1- end) (buffer-size)))
+                     ""
+                   (format " <%d-%d>" beg end))))
+    (message "%spt=%d/%d%s col=%d"
+             char-info
+             (point) (buffer-size)
+             narrow
+             (current-column))))
+
+(defun what-cursor-position--traditional ()
+  "Traditional echo area output of `what-cursor-position'."
   (let* ((char (following-char))
          (char-name (and what-cursor-show-names
                          (or (get-char-code-property char 'name)
@@ -1671,9 +1701,6 @@ what-cursor-position
 				  "..."
 				(encoded-string-description encoded coding)))
 		    (format "(%d, #o%o, #x%x%s)" char char char char-name-fmt)))))
-	(if detail
-	    ;; We show the detailed information about CHAR.
-	    (describe-char (point)))
 	(if (or (/= beg 1) (/= end (1+ total)))
 	    (message "Char: %s%s %s point=%d of %d (%d%%) <%d-%d> column=%d%s"
 		     (if (< char 256)
@@ -1688,6 +1715,19 @@ what-cursor-position
 			 (buffer-substring-no-properties (point) (1+ (point))))
 		     (single-key-description char))
 		   bidi-fixer encoding-msg pos total percent col hscroll))))))
+
+(defun what-cursor-position (&optional detail)
+  "Print info on cursor position (on screen and within buffer).
+Also describe the character after point according to `what-cursor-format'.
+
+In addition, with prefix argument, show details about that character
+in *Help* buffer.  See also the command `describe-char'."
+  (interactive "P")
+  (when detail
+    (describe-char (point)))
+  (cond
+   ((eq what-cursor-format 'default)     (what-cursor-position--default))
+   ((eq what-cursor-format 'traditional) (what-cursor-position--traditional))))
 \f
 ;; Initialize read-expression-map.  It is defined at C level.
 (defvar read-expression-map
-- 
2.32.0 (Apple Git-132)

bug#24902: [External] : bug#24902: 25.1; C-x = for Unicode

[Drew Adams]

If you're going to offer a user option to choose the format, why not allow that option value to also specify the format, instead of providing only two possible formats? IOW, have a defcustom `choice' that includes the two formats you're providing but also lets users specify a format (for the same data).

bug#24902: 25.1; C-x = for Unicode

[Lars Ingebrigtsen]

Mattias Engdegård <mattiase@acm.org> writes:

> Attached is a draft patch. It does not change the output of
> `describe-char`, which is invoked from `C-u C-x =`. The `traditional`
> format is unchanged; the new format is designed to be informative and
> reasonably free from clutter.

I think using `format-spec' would allow users to tweak this more
extensively, which they probably want to, if they care enough to change
it at all.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24902: 25.1; C-x = for Unicode

[Mattias Engdegård]

24 jan. 2022 kl. 17.35 skrev Lars Ingebrigtsen <larsi@gnus.org>:

> I think using `format-spec' would allow users to tweak this more
> extensively, which they probably want to, if they care enough to change
> it at all.

Thanks for taking a look! I had a go at format-spec, and don't think it's appropriate. Let me explain:

1. It doesn't fit the problem very well: neither the traditional nor the new format are easily expressed with format-spec since they are conditional in several ways (fields or strings that appear depending on the circumstances). In contrast, conditions are easily expressible in Lisp.

2. Even if we went through the contortions to make formats expressible in format-spec, it still wouldn't be very easy to do so, especially compared to choosing a ready-made format. For more advanced customisation, Lisp is probably preferable.

3. As any designer knows, customisability is a cop-out: it's an abdication of responsibility. The user can now conveniently be blamed for any perceived shortcoming. Conversely, being forced to think and make hard choices is much of what design is about, and users like when it's done for them in a competent way.

Customisability is a minefield: it is often motivated by vague hypotheticals like "what if someone wants to..." when the right question to ask is instead what a good design would be and what preferences, if any, could reasonably differ.

Let's look at it this way: what would you personally want the format to be, if you did not need to think about anyone else's wishes? Then see if our ideas might converge. Chances are that we could find something that most users think is pretty good, and many of the rest could very well live with.

bug#24902: 25.1; C-x = for Unicode

[Lars Ingebrigtsen]

Mattias Engdegård <mattiase@acm.org> writes:

> 1. It doesn't fit the problem very well: neither the traditional nor
> the new format are easily expressed with format-spec since they are
> conditional in several ways (fields or strings that appear depending
> on the circumstances). In contrast, conditions are easily expressible
> in Lisp.

The format we're settling on doesn't have to be identical to the one we
have today.  Defaulting to, say, the

Char: e (101, #o145, #x65) point=818 of 2005 (41%) column=60

might be OK.

> 2. Even if we went through the contortions to make formats expressible
> in format-spec, it still wouldn't be very easy to do so, especially
> compared to choosing a ready-made format. For more advanced
> customisation, Lisp is probably preferable.

Writing code is always better for programmers, but non-programmers can
put together format-spec things easier.

> 3. As any designer knows, customisability is a cop-out: it's an
> abdication of responsibility. The user can now conveniently be blamed
> for any perceived shortcoming. Conversely, being forced to think and
> make hard choices is much of what design is about, and users like when
> it's done for them in a competent way.

I know what you mean, but of course I want to have a good default.  I
just doubt that there's any point in adding more than one "standard
format" -- people that want to tweak stuff like this really wants to
tweak stuff like this.  Trying to figure out all formats a user might
want is futile (and ultimately user-hostile).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24902: 25.1; C-x = for Unicode

[Mattias Engdegård]

24 jan. 2022 kl. 18.39 skrev Lars Ingebrigtsen <larsi@gnus.org>:

> Writing code is always better for programmers, but non-programmers can
> put together format-spec things easier.

Maybe, but why don't we first try to make an effort so that they don't have to. There is a tower of convenience for the typical user:

1. accept the default
2. customise-variable, picking another ready-made format
3. download an ELPA package (or copy someone's init.el)
4. write Lisp

A format-spec elaboration would fit somewhere between 3 and 4 in that tower -- easier than Lisp, but less convenient than using something available. (Maybe you would place it above 3, but then I personally rank "Lisp" at around 1.001. We aren't typical users.)

Thus let's attack 1 and 2 first. If we fail, and it is clear that a significant number of users would legitimately be dissatisfied by options 1..4 above, then format-spec may be an option.

>> 3. As any designer knows, customisability is a cop-out: it's an
>> abdication of responsibility. The user can now conveniently be blamed
>> for any perceived shortcoming. Conversely, being forced to think and
>> make hard choices is much of what design is about, and users like when
>> it's done for them in a competent way.
> 
> I know what you mean, but of course I want to have a good default.

And I know that you do! What about the new format -- is it good enough for you, or can you help making it better?

>  I just doubt that there's any point in adding more than one "standard
> format" -- people that want to tweak stuff like this really wants to
> tweak stuff like this.

No they don't, unless we tell them that they may want to. (This is an often ignored back-side of customisation!)
I've only heard rather reasonable comments about specific shortcomings such as the lack of Unicode names. Let's fix that first.

>  Trying to figure out all formats a user might
> want is futile (and ultimately user-hostile).

Correct, but that was never the the idea. We only need to provide the minimum number of ones to make most users happy.

(I should add at this point that users typically don't know exactly what they want, but they occasionally do know what they don't. This actually makes the job of the designer easier.)

The ideal number of options is always one, but I went with two for a very specific reason: the 'traditional' option is a time-saver. Not for users, but for you and me, who can point to it if there is a complaint about the change. I'd rather not have it.

bug#24902: 25.1; C-x = for Unicode

[Robert Pluim]

>>>>> On Tue, 25 Jan 2022 16:38:22 +0100, Mattias Engdegård <mattiase@acm.org> said:

    Mattias> The ideal number of options is always one, but I went with two for a
    Mattias> very specific reason: the 'traditional' option is a time-saver. Not
    Mattias> for users, but for you and me, who can point to it if there is a
    Mattias> complaint about the change. I'd rather not have it.

I remember there was a very large amount of back-and-forth about the
exact output that would be enabled by `what-cursor-show-names', as
people were very sensitive to the exact information presented. Yet
here you've essentially flipped it to t for everybody, which will
inevitably result in complaints.

I think the new format can be improved, as to my eyes itʼs lacking in
visual separators between the fields, but in any case I donʼt think it
should be the default.

"Let the Good Old Times roll"

Robert
-- 

bug#24902: 25.1; C-x = for Unicode

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Tue, 25 Jan 2022 17:41:55 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,
>  Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, 24902@debbugs.gnu.org
> 
> I remember there was a very large amount of back-and-forth about the
> exact output that would be enabled by `what-cursor-show-names', as
> people were very sensitive to the exact information presented. Yet
> here you've essentially flipped it to t for everybody, which will
> inevitably result in complaints.
> 
> I think the new format can be improved, as to my eyes itʼs lacking in
> visual separators between the fields, but in any case I donʼt think it
> should be the default.

AFAIU, we didn't yet agree on changing the default.

bug#24902: 25.1; C-x = for Unicode

[Mattias Engdegård]

25 jan. 2022 kl. 17.41 skrev Robert Pluim <rpluim@gmail.com>:

> I remember there was a very large amount of back-and-forth about the
> exact output that would be enabled by `what-cursor-show-names', as
> people were very sensitive to the exact information presented. Yet
> here you've essentially flipped it to t for everybody, which will
> inevitably result in complaints.

It's a rather separate discussion. (Those most attached to the old appearance are long-time users who know very well how to customise it, and it's good if new users get the better design by default.) Let's focus on the new design right now.

> I think the new format can be improved, as to my eyes itʼs lacking in
> visual separators between the fields

I thought the all-caps Unicode character name did offset it rather well against what followed, but perhaps adding a comma immediately after the name, as in

U+003B SEMICOLON, pt=72/145 col=0

would help?

bug#24902: 25.1; C-x = for Unicode

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Tue, 25 Jan 2022 19:00:21 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,
>  Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, 24902@debbugs.gnu.org
> 
> U+003B SEMICOLON, pt=72/145 col=0

This is supposed to be for newcomers?  What is "pt"? what is "col"?
what does N/M mean?  The only thing that doesn't need explanation is
the "," part.

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Ulrich Windl]

>>> Mattias Engdegård <mattiase@acm.org> schrieb am 25.01.2022 um 19:00 in
Nachricht <5EA6B0F8-93CC-43DD-B4BE-8109FBA68722@acm.org>:

[...]
> U+003B SEMICOLON, pt=72/145 col=0

As Unicode names can have spaces in them (e.g.: "U+A758 LATIN CAPITAL LETTER Q
WITH DIAGONAL STROKE"), the comma is important (unless the name is quoted), I
think.

> 
> would help?

bug#24902: 25.1; C-x = for Unicode

[Lars Ingebrigtsen]

Mattias Engdegård <mattiase@acm.org> writes:

> And I know that you do! What about the new format -- is it good enough
> for you, or can you help making it better?

U+006F LATIN SMALL LETTER O pt=2938/2942 col=52

or

U+006F LATIN SMALL LETTER O pt=1913/3297 <1402-3298> col=42

I think that's more confusing than what we currently have -- pt and col
aren't very clear.  Compared to:

Char: o (111, #o157, #x6f) point=1913 of 3222 (59%) <1402-3223> column=42

And I have absolutely no idea what the stuff in <> is supposed to tell
me, but the current format has that in common with the proposed format.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24902: 25.1; C-x = for Unicode

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 26 Jan 2022 14:10:40 +0100
> Cc: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, 24902@debbugs.gnu.org
> 
> Char: o (111, #o157, #x6f) point=1913 of 3222 (59%) <1402-3223> column=42
> 
> And I have absolutely no idea what the stuff in <> is supposed to tell
> me

It shows the restriction, if any.

bug#24902: 25.1; C-x = for Unicode

[Mattias Engdegård]

26 jan. 2022 kl. 08.09 skrev Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>:

> As Unicode names can have spaces in them (e.g.: "U+A758 LATIN CAPITAL LETTER Q
> WITH DIAGONAL STROKE"), the comma is important (unless the name is quoted), I
> think.

All right, let's add a comma there then.

26 jan. 2022 kl. 14.10 skrev Lars Ingebrigtsen <larsi@gnus.org>:

> I think that's more confusing than what we currently have -- pt and col
> aren't very clear.

Maybe we can afford spending a few more characters then, "point" is a reasonable improvement. I think that "col" as shorthand for "column" is readily understood because it is so common even outside Emacs, but will happily change to "column" if required.

> And I have absolutely no idea what the stuff in <> is supposed to tell
> me, but the current format has that in common with the proposed format.

Yes. The problem is that since we display the point and buffer size, which is the basic job of the command after all, we pretty much need to indicate narrowing in some way. Since narrowing is slightly uncommon we could afford some verbosity; what about changing

 <1234-5678>

into

 (narrowed to 1234-5678)

then?

bug#24902: 25.1; C-x = for Unicode

[Robert Pluim]

>>>>> On Wed, 26 Jan 2022 14:10:40 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Mattias Engdegård <mattiase@acm.org> writes:
    >> And I know that you do! What about the new format -- is it good enough
    >> for you, or can you help making it better?

    Lars> U+006F LATIN SMALL LETTER O pt=2938/2942 col=52

    Lars> or

    Lars> U+006F LATIN SMALL LETTER O pt=1913/3297 <1402-3298> col=42

    Lars> I think that's more confusing than what we currently have -- pt and col
    Lars> aren't very clear.  Compared to:

    Lars> Char: o (111, #o157, #x6f) point=1913 of 3222 (59%) <1402-3223> column=42

    Lars> And I have absolutely no idea what the stuff in <> is supposed to tell
    Lars> me, but the current format has that in common with the proposed format.

You only see that when the buffer is narrowed, itʼs
<(point-min)-(point-max)>. Iʼm not sure how useful it is.

Since weʼre now painting this bike-shed, hereʼs my preferred colour:

U+006F 'LATIN SMALL LETTER O' point=2938 of 2942 col=52

I think I could be persuaded that the (59%) stuff should be in there
as well, but thatʼs not a strongly held opinion.

Robert
-- 

bug#24902: 25.1; C-x = for Unicode

[Lars Ingebrigtsen]

Mattias Engdegård <mattiase@acm.org> writes:

> Since narrowing is slightly
> uncommon we could afford some verbosity; what about changing
>
>  <1234-5678>
>
> into
>
>  (narrowed to 1234-5678)
>
> then?

Yes, that'd be an improvement.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Ulrich Windl]

>>> Robert Pluim <rpluim@gmail.com> schrieb am 26.01.2022 um 14:48 in Nachricht
<87a6fihaku.fsf@gmail.com>:

[...]
> U+006F 'LATIN SMALL LETTER O' point=2938 of 2942 col=52

I was wondering about three things:
1) When you display the column, shouldn't you display the line, too?
2) Should the percentage be included when point position is included?
3) As the output may become lengthy, will the minibuffer extend to multiple lines, or should we be smart detecting when line-number minor mode is active and omit line, column and percentage then?

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Mattias Engdegård]

26 jan. 2022 kl. 15.09 skrev Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>:

> 1) When you display the column, shouldn't you display the line, too?

It's probably because Emacs traditionally displays the line but not the column number in the mode line. The reason for that, in turn, is that updating the column number for each typed character makes Emacs less usable over a slow serial line (like 1200 bit/s).

These outdated assumptions should be clearly be reconsidered but meanwhile perhaps we'd better keep the column number in C-x =. What do you think?

> 2) Should the percentage be included when point position is included?

That percentage smelled "included because we could" from afar. It's not very useful; the current/maximum point positions give the user a good idea how far in the buffer he is.

> 3) As the output may become lengthy, will the minibuffer extend to multiple lines

Yes. The aim is to make this fairly rare with an 80-column frame width, not to prevent it outright.

bug#24902: 25.1; C-x = for Unicode

[Mattias Engdegård]

[-- Attachment #1: Type: text/plain, Size: 388 bytes --]

26 jan. 2022 kl. 14.48 skrev Robert Pluim <rpluim@gmail.com>:

> U+006F 'LATIN SMALL LETTER O' point=2938 of 2942 col=52

The single quotes are mostly noise; a comma after the name seems to work just as well and is less intrusive (and shorter). The syntax "U+1234 NAME IN CAPS" is Unicode standard and the user is likely to have encountered it before.

Here is an updated patch.


[-- Attachment #2: 0001-Cleaner-what-cursor-position-format.patch --]
[-- Type: application/octet-stream, Size: 6220 bytes --]

From a4d4eaf9fcb83b98277959083028aa2a20489a1c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mattias=20Engdeg=C3=A5rd?= <mattiase@acm.org>
Date: Mon, 24 Jan 2022 16:49:08 +0100
Subject: [PATCH] Cleaner `what-cursor-position` format

Add a new `C-x =` output format, under the control of the new
`what-cursor-format` user option, that uses more modern formatting
and omits noise syntax and rarely used information.  It always
includes the character name.

* lisp/simple.el (what-cursor-format): New.
(what-cursor-show-names): Explain relation to `what-cursor-format`.
(what-cursor-position--default,
what-cursor-position--traditional): New functions.
(what-cursor-position): Reduce to calling the right back-end function.
* etc/NEWS: Announce.
---
 etc/NEWS       |  6 ++++
 lisp/simple.el | 78 ++++++++++++++++++++++++++++++++++++++------------
 2 files changed, 65 insertions(+), 19 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index abef1019ac..68fb9110f1 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -183,6 +183,12 @@ wheel reports.  Unlike 'pixel-scroll-mode', this mode scrolls the
 display pixel-by-pixel, as opposed to only animating line-by-line
 scrolls.
 
+** New user option 'what-cursor-format'
+It governs the output format of 'what-cursor-position', normally
+bound to 'C-x ='.  When 'traditional', the output is identical
+to that of Emacs 28; when 'default', a simpler, briefer format
+that always includes the character name is used.
+
 ** Terminal Emacs
 
 ---
diff --git a/lisp/simple.el b/lisp/simple.el
index 801a3c992c..2cc90426e2 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -1564,27 +1564,57 @@ count-lines
                  (1- (line-number-at-pos))
                (line-number-at-pos)))))))
 
+(defcustom what-cursor-format 'default
+  "What to show in the echo area in `what-cursor-position'.
+The `default' format gives the hex code and name of the character
+after point, the cursor position, buffer size, and column number.
+
+The `traditional' format also displays the code in decimal and octal,
+and only includes the name if `what-cursor-show-name' is non-nil.
+For a non-ASCII multibyte character, it also gives the encoding in the
+buffer's selected coding system if the coding system encodes the
+character safely.  If the character is encoded into one byte, that
+code is shown in hex.  If the character is encoded into more than one
+byte, just \"...\" is shown."
+  :type '(choice (const :tag "Default" default)
+                 (const :tag "Traditional" traditional))
+  :version "29.1"
+  :group 'editing-basics)
+
 (defcustom what-cursor-show-names nil
-  "Whether to show character names in `what-cursor-position'."
+  "Whether to show character names in `what-cursor-position'.
+It only applies when `what-cursor-format' is `traditional'."
   :type 'boolean
   :version "27.1"
   :group 'editing-basics)
 
-(defun what-cursor-position (&optional detail)
-  "Print info on cursor position (on screen and within buffer).
-Also describe the character after point, and give its character
-code in octal, decimal and hex.  If `what-cursor-show-names' is
-non-nil, additionally show the name of the character.
-
-For a non-ASCII multibyte character, also give its encoding in the
-buffer's selected coding system if the coding system encodes the
-character safely.  If the character is encoded into one byte, that
-code is shown in hex.  If the character is encoded into more than one
-byte, just \"...\" is shown.
-
-In addition, with prefix argument, show details about that character
-in *Help* buffer.  See also the command `describe-char'."
-  (interactive "P")
+(defun what-cursor-position--default ()
+  "Default echo area output of `what-cursor-position'."
+  (let* ((char (char-after))
+         (char-info
+          (cond
+           ((null char) "")
+           ((<= #x3fff80 char #x3fffff)
+            (format "#x%02X (raw byte) " (logand char #xff)))
+           (t
+            (format "U+%04X %s, "
+                    char
+                    (or (get-char-code-property char 'name)
+                        (get-char-code-property char 'old-name)
+                        "(undefined)")))))
+         (beg (point-min))
+         (end (point-max))
+         (narrow (if (and (= beg 1) (= (1- end) (buffer-size)))
+                     ""
+                   (format " (narrowed to %d-%d)" beg end))))
+    (message "%spoint=%d/%d%s col=%d"
+             char-info
+             (point) (buffer-size)
+             narrow
+             (current-column))))
+
+(defun what-cursor-position--traditional ()
+  "Traditional echo area output of `what-cursor-position'."
   (let* ((char (following-char))
          (char-name (and what-cursor-show-names
                          (or (get-char-code-property char 'name)
@@ -1671,9 +1701,6 @@ what-cursor-position
 				  "..."
 				(encoded-string-description encoded coding)))
 		    (format "(%d, #o%o, #x%x%s)" char char char char-name-fmt)))))
-	(if detail
-	    ;; We show the detailed information about CHAR.
-	    (describe-char (point)))
 	(if (or (/= beg 1) (/= end (1+ total)))
 	    (message "Char: %s%s %s point=%d of %d (%d%%) <%d-%d> column=%d%s"
 		     (if (< char 256)
@@ -1688,6 +1715,19 @@ what-cursor-position
 			 (buffer-substring-no-properties (point) (1+ (point))))
 		     (single-key-description char))
 		   bidi-fixer encoding-msg pos total percent col hscroll))))))
+
+(defun what-cursor-position (&optional detail)
+  "Print info on cursor position (on screen and within buffer).
+Also describe the character after point according to `what-cursor-format'.
+
+In addition, with prefix argument, show details about that character
+in *Help* buffer.  See also the command `describe-char'."
+  (interactive "P")
+  (when detail
+    (describe-char (point)))
+  (cond
+   ((eq what-cursor-format 'default)     (what-cursor-position--default))
+   ((eq what-cursor-format 'traditional) (what-cursor-position--traditional))))
 \f
 ;; Initialize read-expression-map.  It is defined at C level.
 (defvar read-expression-map
-- 
2.32.0 (Apple Git-132)

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Wed, 26 Jan 2022 17:53:00 +0100
> Cc: Robert Pluim <rpluim@gmail.com>, larsi@gnus.org, 24902@debbugs.gnu.org
> 
> 26 jan. 2022 kl. 15.09 skrev Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>:
> 
> > 1) When you display the column, shouldn't you display the line, too?
> 
> It's probably because Emacs traditionally displays the line but not the column number in the mode line. The reason for that, in turn, is that updating the column number for each typed character makes Emacs less usable over a slow serial line (like 1200 bit/s).

It is also because displaying the column requires to redraw the mode
line on every move of the point, which is expensive and slows down
redisplay.

> These outdated assumptions should be clearly be reconsidered

They are not necessarily outdated.

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C‑x = for Unicode

[Ulrich Windl]

>>> Mattias Engdegård <mattiase@acm.org> schrieb am 26.01.2022 um 18:02 in
Nachricht <537072BC-F9DF-4B7B-BA88-02320A731013@acm.org>:
> 26 jan. 2022 kl. 14.48 skrev Robert Pluim <rpluim@gmail.com>:
> 
>> U+006F 'LATIN SMALL LETTER O' point=2938 of 2942 col=52
> 
> The single quotes are mostly noise; a comma after the name seems to work 
> just as well and is less intrusive (and shorter). The syntax "U+1234 NAME IN

> CAPS" is Unicode standard and the user is likely to have encountered it 
> before.

I don't know much about the Unicode standard, but in BabelPad (Windows
application) some character descriptions have an extra part separated with a
colon, like this:
"U+00B6 PILCROW SIGN : paragraph sign"

So maybe the quotes may be justified.

> 
> Here is an updated patch.

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C‑x = for Unicode

[Robert Pluim]

>>>>> On Thu, 27 Jan 2022 10:12:21 +0100, "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> said:

    >>>> Mattias Engdegård <mattiase@acm.org> schrieb am 26.01.2022 um 18:02 in
    Ulrich> Nachricht <537072BC-F9DF-4B7B-BA88-02320A731013@acm.org>:
    >> 26 jan. 2022 kl. 14.48 skrev Robert Pluim <rpluim@gmail.com>:
    >> 
    >>> U+006F 'LATIN SMALL LETTER O' point=2938 of 2942 col=52
    >> 
    >> The single quotes are mostly noise; a comma after the name seems to work 
    >> just as well and is less intrusive (and shorter). The syntax "U+1234 NAME IN

    >> CAPS" is Unicode standard and the user is likely to have encountered it 
    >> before.

    Ulrich> I don't know much about the Unicode standard, but in BabelPad (Windows
    Ulrich> application) some character descriptions have an extra part separated with a
    Ulrich> colon, like this:
    Ulrich> "U+00B6 PILCROW SIGN : paragraph sign"

    Ulrich> So maybe the quotes may be justified.

Those are codepoints which have both a 'name' and an 'old-name'.
'C-u C-x =' will show both by default, I donʼt think itʼs necessary
for 'C-x =', which will show 'name' if it exists, else 'old-name'.

Iʼm more interested in the visual separation between the U+ABCD and
the name.

Robert
-- 

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C‑x = for Unicode

[Eli Zaretskii]

> Date: Thu, 27 Jan 2022 10:12:21 +0100
> From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
> Cc: 24902@debbugs.gnu.org, larsi@gnus.org
> 
> I don't know much about the Unicode standard, but in BabelPad (Windows
> application) some character descriptions have an extra part separated with a
> colon, like this:
> "U+00B6 PILCROW SIGN : paragraph sign"

That "paragraph sign" part comes from the old-name field of the
character database:

  00B6;PILCROW SIGN;Po;0;ON;;;;;N;PARAGRAPH SIGN;;;;
                                  ^^^^^^^^^^^^^^

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C‑x= for Unicode

[Ulrich Windl]

>>> Robert Pluim <rpluim@gmail.com> schrieb am 27.01.2022 um 10:43 in
Nachricht
<87y231fr9l.fsf@gmail.com>:

[...]
> 
>     Ulrich> I don't know much about the Unicode standard, but in BabelPad 
> (Windows
>     Ulrich> application) some character descriptions have an extra part 
> separated with a
>     Ulrich> colon, like this:
>     Ulrich> "U+00B6 PILCROW SIGN : paragraph sign"
> 
>     Ulrich> So maybe the quotes may be justified.
> 
> Those are codepoints which have both a 'name' and an 'old-name'.
> 'C-u C-x =' will show both by default, I donʼt think itʼs necessary
> for 'C-x =', which will show 'name' if it exists, else 'old-name'.
> 
> Iʼm more interested in the visual separation between the U+ABCD and
> the name.

Well I think _one_ space after U+xxxx is fine; it's visual enough for me.
Personaly I'd prefer delimiting a name consisting of multiple words by
quotes.

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C‑x= for Unicode

[Robert Pluim]

>>>>> On Thu, 27 Jan 2022 11:11:14 +0100, "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> said:

    >>>> Robert Pluim <rpluim@gmail.com> schrieb am 27.01.2022 um 10:43 in
    >> Iʼm more interested in the visual separation between the U+ABCD and
    >> the name.

    Ulrich> Well I think _one_ space after U+xxxx is fine; it's visual enough for me.
    Ulrich> Personaly I'd prefer delimiting a name consisting of multiple words by
    Ulrich> quotes.

Yes, thatʼs what I meant by 'visual separation', although 'delimiting'
is a better expression of that. In the 'traditional +
what-cursor-show-names = t' mode, you get that, except that itʼs not
the same delimiter on either end of the name, itʼs ", " at the start,
and ")" at the end:

Char: t (116, #o164, #x74, LATIN SMALL LETTER T) point=1889 of 1948 (97%) <955-1949> column=0

Robert
-- 

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C‑x = for Unicode

[Mattias Engdegård]

27 jan. 2022 kl. 10.43 skrev Robert Pluim <rpluim@gmail.com>:

> Those are codepoints which have both a 'name' and an 'old-name'.
> 'C-u C-x =' will show both by default, I donʼt think itʼs necessary
> for 'C-x =', which will show 'name' if it exists, else 'old-name'.

Right, and it is probably the right call here -- only control characters have an old-name but no name (some have neither).
There is a single name/old-name collision, U+1F514 vs U+0007, but there's no serious risk of confusion.

> Iʼm more interested in the visual separation between the U+ABCD and
> the name.

Just a space seems to be the standard convention to the point that characters are nowadays often identified in that manner in prose, as in U+00A7 SECTION SIGN.
It also reinforces the connection between the code and the name, being separate from the rest of the information being displayed, which is about the cursor position. Is it good enough, you think?

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C‑x = for Unicode

[Ulrich Windl]

>>> Mattias Engdegård <mattiase@acm.org> schrieb am 27.01.2022 um 13:38 in
Nachricht <D42E8275-DF4E-4727-8958-A301A77FE703@acm.org>:
> 27 jan. 2022 kl. 10.43 skrev Robert Pluim <rpluim@gmail.com>:
> 
>> Those are codepoints which have both a 'name' and an 'old-name'.
>> 'C-u C-x =' will show both by default, I donʼt think itʼs necessary
>> for 'C-x =', which will show 'name' if it exists, else 'old-name'.
> 
> Right, and it is probably the right call here -- only control characters 
> have an old-name but no name (some have neither).
> There is a single name/old-name collision, U+1F514 vs U+0007, but there's no

> serious risk of confusion.

According to BabelPad the names are different:
U+0007 <control> : ALERT [BEL]
U+1F514 BELL

> 
>> Iʼm more interested in the visual separation between the U+ABCD and
>> the name.

U+ABCD MEETEI MAYEK LETTER HUK : ha

;-)

> 
> Just a space seems to be the standard convention to the point that 
> characters are nowadays often identified in that manner in prose, as in 
> U+00A7 SECTION SIGN.
> It also reinforces the connection between the code and the name, being 
> separate from the rest of the information being displayed, which is about
the 
> cursor position. Is it good enough, you think?

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Lars Ingebrigtsen]

Mattias Engdegård <mattiase@acm.org> writes:

>> 2) Should the percentage be included when point position is included?
>
> That percentage smelled "included because we could" from afar. It's
> not very useful; the current/maximum point positions give the user a
> good idea how far in the buffer he is.

Stepping back a bit, `C-x =' does two things now, and neither very well:
It says something about the character under point, and it says something
about where in the buffer you are.

I think it might make more sense to split this into two commands, where
one would more fully describe the character under point, and the other
command says where you are in the buffer.

For instance, it would be nice if it said what percentage the line you're
at is.  (Nice if you're going through a list of items and wonder what
percentage you're at.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Juri Linkov]

> Stepping back a bit, `C-x =' does two things now, and neither very well:
> It says something about the character under point, and it says something
> about where in the buffer you are.
>
> I think it might make more sense to split this into two commands, where
> one would more fully describe the character under point, and the other
> command says where you are in the buffer.
>
> For instance, it would be nice if it said what percentage the line you're
> at is.  (Nice if you're going through a list of items and wonder what
> percentage you're at.)

This looks more like `M-='.  When the region is not activated,
currently it does nothing and signals an error.

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Stepping back a bit, `C-x =' does two things now, and neither very well:
  > > It says something about the character under point, and it says something
  > > about where in the buffer you are.
  > >
  > > I think it might make more sense to split this into two commands, where
  > > one would more fully describe the character under point, and the other
  > > command says where you are in the buffer.

I put those things together in one command so as to economize on key
bindings.  That advantage still exists, so I don't think we should
split it.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> This looks more like `M-='.  When the region is not activated,
> currently it does nothing and signals an error.

Hm, yes, then we could use that for one or the other of the commands (if
we decide to split them up).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Mattias Engdegård]

27 jan. 2022 kl. 16.39 skrev Lars Ingebrigtsen <larsi@gnus.org>:

> Stepping back a bit, `C-x =' does two things now, and neither very well:
> It says something about the character under point, and it says something
> about where in the buffer you are.
> 
> I think it might make more sense to split this into two commands, where
> one would more fully describe the character under point, and the other
> command says where you are in the buffer.

That's an interesting aspect and it is true that the user is only interested in one of the parts: either the character or the position (etc). On the other hand, both currently fit in the echo area (with some care; it's partly what this bug is about), and it is not clear that the added room for information motivates the increased cognitive load that an extra binding implies.

In a modern editor it would perhaps make sense to to have the position-related data in a live view that can be shown or hidden at any time. This is clearly popular for line and column numbers; some writers like live word counts, and so on. Character info is less useful as live information and more likely something called up on command.

For that matter, many users employ the vertical scroll bar as a live approximate position/size indicator. I just wish its height were based on lines instead of characters.

Anyway, what about making the proposed minor reform to `C-x =` now and plan for a more extensive overhaul separately?

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 28 Jan 2022 08:09:48 -0500
> Cc: mattiase@acm.org, 24902@debbugs.gnu.org, rpluim@gmail.com, larsi@gnus.org,
>  Ulrich.Windl@rz.uni-regensburg.de
> 
>   > > Stepping back a bit, `C-x =' does two things now, and neither very well:
>   > > It says something about the character under point, and it says something
>   > > about where in the buffer you are.
>   > >
>   > > I think it might make more sense to split this into two commands, where
>   > > one would more fully describe the character under point, and the other
>   > > command says where you are in the buffer.
> 
> I put those things together in one command so as to economize on key
> bindings.  That advantage still exists, so I don't think we should
> split it.

I would also hate to use two commands where one does the job today.
"C-x =" is a command I use very frequently, and it is very useful.

bug#24902: [External] : bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Drew Adams]

> it is true that the user is only interested
> in one of the parts: either the character or
> the position (etc).

Not really.  _Some_ user might _sometime_
be interested in only one of the parts.

bug#24902: [External] : bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Drew Adams]

> > I put those things together in one command so as to economize on key
> > bindings.  That advantage still exists, so I don't think we should
> > split it.
> 
> I would also hate to use two commands where one does the job today.
> "C-x =" is a command I use very frequently, and it is very useful.

+1.

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Lars Ingebrigtsen]

Mattias Engdegård <mattiase@acm.org> writes:

> For that matter, many users employ the vertical scroll bar as a live
> approximate position/size indicator. I just wish its height were based
> on lines instead of characters.

Yes, that'd be much better.

> Anyway, what about making the proposed minor reform to `C-x =` now and
> plan for a more extensive overhaul separately?

No matter what we do, we're going to annoy some people, so why annoy
them twice?  😀

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I would also hate to use two commands where one does the job today.
> "C-x =" is a command I use very frequently, and it is very useful.

Do you use it to examine the character under point and its position at
the same time?  If so, when?

(I do both things, but I don't think I've ever felt the need for both
things at the same time, so I'm curious when you'd want both at the same
time.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: rms@gnu.org,  mattiase@acm.org,  rpluim@gmail.com,
>   Ulrich.Windl@rz.uni-regensburg.de,  juri@linkov.net,
>   24902@debbugs.gnu.org
> Date: Sat, 29 Jan 2022 15:34:25 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I would also hate to use two commands where one does the job today.
> > "C-x =" is a command I use very frequently, and it is very useful.
> 
> Do you use it to examine the character under point and its position at
> the same time?  If so, when?

For example, when there's some problem with cursor position, and I
want to know where point _really_ is.  Also, when there are many
similar characters in the buffer, and seeing both the character itself
and its position goes a long way towards disambiguating stuff.

The "part of display ..." and the EOB indication are also occasionally
very useful.

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Mattias Engdegård]

29 jan. 2022 kl. 15.32 skrev Lars Ingebrigtsen <larsi@gnus.org>:

>> For that matter, many users employ the vertical scroll bar as a live
>> approximate position/size indicator. I just wish its height were based
>> on lines instead of characters.
> 
> Yes, that'd be much better.

Presumably we could use heuristics similar to line-number-mode for when to use the line numbers and when to fall back to characters, but I'm sure there are technicalities to work out. At least the number of lines in the buffer changes less often.

> No matter what we do, we're going to annoy some people, so why annoy
> them twice?

Hmmm, aren't we unnecessarily censoring ourselves now? If someone is really annoyed by not getting the character at point in octal by default despite that the old way is just a defcustom away, then... I don't think we shouldn't let ourselves be ruled by that person, should we? (It's not that we are going to lose users from the change.)

I'd take it easier on the plan to split the functionality in two commands, unless you have a clever idea.

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> For example, when there's some problem with cursor position, and I
> want to know where point _really_ is.  Also, when there are many
> similar characters in the buffer, and seeing both the character itself
> and its position goes a long way towards disambiguating stuff.
>
> The "part of display ..." and the EOB indication are also occasionally
> very useful.

Thanks; I see.  This sounds very useful especially when debugging the
Emacs display, but perhaps isn't what most users would feel is vital?
(But I don't know one way or the other.)

What I see attractive about splitting this up into two commands is that
there's more information about positions and characters that would be
useful, I think.  For instance, when I'm wondering about a character
it's because it's odd to me somehow, so knowing the name and the
general-category of the character (in addition to the Unicode char
number) is what I'd like to know.

And for positions, I'd really like to know the percentage point of the
line.

If we split this up into two commands, but added a user option to get
the combined display back on `C-x =', would that be acceptable for you?
(I'm not saying that I actually want that, but just exploring what our
options are here; I don't have any strong feelings on the matter.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Lars Ingebrigtsen]

Mattias Engdegård <mattiase@acm.org> writes:

> I'd take it easier on the plan to split the functionality in two
> commands, unless you have a clever idea.

Just exploring options in this area; see my response to Eli.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: rms@gnu.org,  mattiase@acm.org,  rpluim@gmail.com,
>   Ulrich.Windl@rz.uni-regensburg.de,  juri@linkov.net,
>   24902@debbugs.gnu.org
> Date: Sun, 30 Jan 2022 16:47:49 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > For example, when there's some problem with cursor position, and I
> > want to know where point _really_ is.  Also, when there are many
> > similar characters in the buffer, and seeing both the character itself
> > and its position goes a long way towards disambiguating stuff.
> >
> > The "part of display ..." and the EOB indication are also occasionally
> > very useful.
> 
> Thanks; I see.  This sounds very useful especially when debugging the
> Emacs display, but perhaps isn't what most users would feel is vital?
> (But I don't know one way or the other.)

Those are my frequent use cases.

> If we split this up into two commands, but added a user option to get
> the combined display back on `C-x =', would that be acceptable for you?
> (I'm not saying that I actually want that, but just exploring what our
> options are here; I don't have any strong feelings on the matter.)

Why not put the 2 new commands on 2 other keys, and leave "C-x ="
alone?

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Robert Pluim]

>>>>> On Sun, 30 Jan 2022 18:46:55 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Lars Ingebrigtsen <larsi@gnus.org>
    >> Thanks; I see.  This sounds very useful especially when debugging the
    >> Emacs display, but perhaps isn't what most users would feel is vital?
    >> (But I don't know one way or the other.)

    Eli> Those are my frequent use cases.

And mine.

    >> If we split this up into two commands, but added a user option to get
    >> the combined display back on `C-x =', would that be acceptable for you?
    >> (I'm not saying that I actually want that, but just exploring what our
    >> options are here; I don't have any strong feelings on the matter.)

    Eli> Why not put the 2 new commands on 2 other keys, and leave "C-x ="
    Eli> alone?

+1 on this. Itʼs not like the current 'C-x =' output is some
horrendous UI mistake that needs fixing.

Robert
-- 

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> If we split this up into two commands, but added a user option to get
>> the combined display back on `C-x =', would that be acceptable for you?
>> (I'm not saying that I actually want that, but just exploring what our
>> options are here; I don't have any strong feelings on the matter.)
>
> Why not put the 2 new commands on 2 other keys, and leave "C-x ="
> alone?

It doesn't feel optimal to have a command that vaguely covers two other
commands.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: rms@gnu.org,  mattiase@acm.org,  rpluim@gmail.com,
>   Ulrich.Windl@rz.uni-regensburg.de,  juri@linkov.net,
>   24902@debbugs.gnu.org
> Date: Mon, 31 Jan 2022 16:27:00 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why not put the 2 new commands on 2 other keys, and leave "C-x ="
> > alone?
> 
> It doesn't feel optimal to have a command that vaguely covers two other
> commands.

<Shrug> They are different commands with evidently different goals, so
making them new commands sounds appropriate to me.  If the intent is
not to repurpose what-cursor-position, then what exactly is the intent?

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> <Shrug> They are different commands with evidently different goals, so
> making them new commands sounds appropriate to me.  If the intent is
> not to repurpose what-cursor-position, then what exactly is the intent?

The intent is to have something that's useful for a larger portion of
the users on `C-x ='?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Mattias Engdegård]

30 jan. 2022 kl. 16.47 skrev Lars Ingebrigtsen <larsi@gnus.org>:

> What I see attractive about splitting this up into two commands is that
> there's more information about positions and characters that would be
> useful, I think.  



> For instance, when I'm wondering about a character
> it's because it's odd to me somehow, so knowing the name and the
> general-category of the character (in addition to the Unicode char
> number) is what I'd like to know.

Being a two-letter code, the general category could certainly fit into the current (revised) format. While you and I would find it useful, we are ones who know our Zp from our Cf; the typical user may find those codes mysterious. But perhaps that is not automatically a usability problem?

Otherwise, for more exact inspection of the character at point we have describe-char, or `C-u C-x =`. (Most people seem to agree that its layout could be improved but that's a different matter.)

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Lars Ingebrigtsen]

Mattias Engdegård <mattiase@acm.org> writes:

> Being a two-letter code, the general category could certainly fit into
> the current (revised) format. While you and I would find it useful, we
> are ones who know our Zp from our Cf; the typical user may find those
> codes mysterious. But perhaps that is not automatically a usability
> problem?

The category is typicall "Letter, Uppercase" etc.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: rms@gnu.org,  mattiase@acm.org,  rpluim@gmail.com,
>   Ulrich.Windl@rz.uni-regensburg.de,  juri@linkov.net,
>   24902@debbugs.gnu.org
> Date: Mon, 31 Jan 2022 18:00:11 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > <Shrug> They are different commands with evidently different goals, so
> > making them new commands sounds appropriate to me.  If the intent is
> > not to repurpose what-cursor-position, then what exactly is the intent?
> 
> The intent is to have something that's useful for a larger portion of
> the users on `C-x ='?

To me, this means you want new and different commands.  But I won't
argue.

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Mattias Engdegård]

31 jan. 2022 kl. 18.45 skrev Lars Ingebrigtsen <larsi@gnus.org>:

> The category is typicall "Letter, Uppercase" etc.

If that is what you're after then it's probably too verbose for the echo area in a combined `C-x =`.
I'd be happy with

 U+0023 NUMBER SIGN [Po] point=22401/47662 col=0

but perhaps the abbreviations are overly technical, at least until we add them to the regexp engine.

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Lars Ingebrigtsen]

Mattias Engdegård <mattiase@acm.org> writes:

>> The category is typicall "Letter, Uppercase" etc.
>
> If that is what you're after then it's probably too verbose for the
> echo area in a combined `C-x =`.
> I'd be happy with
>
>  U+0023 NUMBER SIGN [Po] point=22401/47662 col=0
>
> but perhaps the abbreviations are overly technical, at least until we
> add them to the regexp engine.

I don't think it makes sense to add the category to the combined
command.  I was talking about if we separated them.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#24902: Antw: [EXT] Re: bug#24902: 25.1; C-x = for Unicode

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

If "splitting" C-x = means what I think it means, it implies using two
key sequences instead of one.  That would be a significant cost.

Would this change offer any practical benefit?

  > <Shrug> They are different commands with evidently different goals, so
  > making them new commands sounds appropriate to me.

That is an improvement in conceptual neatness, but I don't think it is worth
the practical price of two keys where one key now serves.

  > The intent is to have something that's useful for a larger portion of
  > the users on `C-x ='?

That could be an improvement, depending.  What, concretely, would that
command do?


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)