emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Display of em dashes in our documentation


From: Eli Zaretskii
Subject: Re: Display of em dashes in our documentation
Date: Fri, 08 Oct 2021 19:12:02 +0300

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 8 Oct 2021 11:09:13 -0400
> Cc: rms@gnu.org, db48x@db48x.net, yuri.v.khan@gmail.com, emacs-devel@gnu.org, 
>       monnier@iro.umontreal.ca, juri@linkov.net
> 
> > So I'd prefer to deal with this differently: introduce a new
> > (buffer-local) minor mode, which will install a display-table, whereby
> > "problematic" Unicode characters will be displayed as their ASCII
> > equivalents or equivalent ASCII strings.  We already set that up
> > automatically on terminals that are incapable of displaying those
> > characters, but nothing precludes us from having such a feature on
> > demand for capable displays as well.  Then users who don't want the
> > effects of these characters on display could activate such a mode, and
> > solve their problems without affecting the actual contents of the Info
> > files.
> 
> That's an interesting idea.  So you propose that this minor mode could
> display many more problematic Unicode characters in a different way, and
> that it would not necessarily be limited to info?

Yes.

> I guess it doesn't take much coding, but the interesting question is
> which other Unicode characters it should cover.  I only know about em
> dash; are there others?

We could let users customize the list in some way.

> One drawback is that em dash is only confirmed to be problematic in some
> situations; that is when they are written "like—this" with no space in
> between, whereas in situations "like — this" I think it is much
> preferable to show the actual Unicode character.

That's splitting hair, IMO.  The latter should never happen in a
well-written manual.

> Actually, this gives me another way of how we could do it: in our info
> manuals, as the final step before displaying it, we do something like
> this (here quickly coded up as a hook):
> 
>     (defun sk/Info-fix-em-dashes ()
>       (save-excursion
>         (goto-char (point-min))
>         (let ((case-fold-search t)
>               (buffer-read-only nil))
>           (while (re-search-forward "\\([a-z”’']\\)—\\([a-z]“‘`'\\)" nil t)
>             (replace-match "\\1 — \\2" t)))))
> 
>     (add-hook 'Info-selection-hook #'sk/Info-fix-em-dashes)

What will that do to byte offsets in Info tag tables?  I'd rather
avoid modifying the buffer contents.

> In any monospace font, I certainly prefer this:
> 
>        When ‘recover-session’ is done, the files you’ve chosen to recover
>     are present in Emacs buffers.  You should then save them.  Only
>     this — saving them — updates the files themselves.
> 
> To this:
> 
>        When ‘recover-session’ is done, the files you’ve chosen to recover
>     are present in Emacs buffers.  You should then save them.  Only
>     this—saving them—updates the files themselves.

But that's against our style of writing documents, isn't it?  I
believe the usual US English style is not to leave whitespace around
em dash.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]