unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: liuhui1610@gmail.com, 67161@debbugs.gnu.org, juri@linkov.net
Subject: bug#67161: 30.0.50; [PATCH] Add option `dired-filename-display-length'
Date: Sun, 26 Nov 2023 19:58:18 +0200	[thread overview]
Message-ID: <83sf4s9z2d.fsf@gnu.org> (raw)
In-Reply-To: <jwv1qccxx8j.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Sun, 26 Nov 2023 12:08:04 -0500)

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: liuhui1610@gmail.com,  juri@linkov.net,  67161@debbugs.gnu.org
> Date: Sun, 26 Nov 2023 12:08:04 -0500
> 
> >> If vectors of glyphs can express things we can't express in a
> >> string, then the question is what should `concat` do in that case,
> >> and if we can then ... why do we even have vectors of glyphs?
> > See above.  I don't know why display-tables store vectors and not
> > strings, but it was like that forever.
> 
> If everything we can do with vectors of glyphs can be done with strings
> (i.e. vectors of glyphs are basically accidents of history), then it
> seems it would make sense to auto-convert a vector of glyph to a string
> *and* to phase out the use of vectors of glyphs.

Yes, but who will have the energy and motivation to go over all the
places that use the display-tables (both in Lisp and in C), and
convert all of them to use strings with faces instead vectors of
glyphs?  To say nothing of the related documentation?  And then we
will probably discover that some subtle aspect of this is the real
reason why we use vectors of glyphs...





  reply	other threads:[~2023-11-26 17:58 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-14  9:52 bug#67161: 30.0.50; [PATCH] Add option `dired-filename-display-length' Liu Hui
2023-11-14 13:26 ` Eli Zaretskii
2023-11-15 10:04   ` Liu Hui
2023-11-15 12:32     ` Eli Zaretskii
2023-11-16 10:07       ` Liu Hui
2023-11-16 12:11         ` Eli Zaretskii
2023-11-18  9:23           ` Liu Hui
2023-11-18 10:55             ` Eli Zaretskii
2023-11-18 16:12               ` Drew Adams
2023-11-20  4:34               ` Liu Hui
2023-11-20 12:10                 ` Eli Zaretskii
2023-11-20 17:54                   ` Juri Linkov
2023-11-20 18:42                     ` Eli Zaretskii
2023-11-20 18:55                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-20 19:17                     ` Eli Zaretskii
2023-11-21  7:52                     ` Juri Linkov
2023-11-21 11:55                       ` Eli Zaretskii
2023-11-21 17:12                         ` Juri Linkov
2023-11-20 17:20                 ` Drew Adams
2023-11-22  5:41                 ` Liu Hui
2023-11-25 10:52                   ` Eli Zaretskii
2023-11-25 17:51                     ` Juri Linkov
2023-11-25 20:02                       ` Eli Zaretskii
2023-11-26  2:56                         ` Liu Hui
2023-11-26  5:59                           ` Eli Zaretskii
2023-11-26 10:49                             ` Eli Zaretskii
2023-11-26 14:03                             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-26 14:53                               ` Eli Zaretskii
2023-11-26 17:08                                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-26 17:58                                   ` Eli Zaretskii [this message]
2023-11-26 18:06                                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-27  7:19                           ` Juri Linkov
2023-11-27  8:32                             ` Liu Hui
2023-11-27 17:16                               ` Juri Linkov
2023-11-15 18:06     ` Drew Adams
2023-11-15 15:54 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-16  3:44   ` Liu Hui

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83sf4s9z2d.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=67161@debbugs.gnu.org \
    --cc=juri@linkov.net \
    --cc=liuhui1610@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).