GNU bug report logs - #15925
24.3.50; error when customizing whitespace-display-mappings

Previous Next

Package: emacs;

Reported by: Claudio Bley <claudio.bley <at> googlemail.com>

Date: Tue, 19 Nov 2013 07:39:02 UTC

Severity: normal

Tags: fixed, patch

Merged with 21771, 28183, 31869

Found in versions 24.3.50, 25.0.50, 27.0.50

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rgm <at> gnu.org, 15925 <at> debbugs.gnu.org, maurooaranda <at> gmail.com, claudio.bley <at> googlemail.com
Subject: bug#15925: 24.3.50; error when customizing whitespace-display-mappings
Date: Fri, 25 Sep 2020 14:06:24 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Fri, 25 Sep 2020 12:00:07 +0200
> Cc: Glenn Morris <rgm <at> gnu.org>, 15925 <at> debbugs.gnu.org,
>  claudio.bley <at> googlemail.com
> 
> > - What do we do with the other escape sequences, like ?\r and ?\f?
> >
> > Right now, we display those as ^M and ^L respectively.  If we keep this
> > representation, maybe somebody will feel there is some inconsistency,
> > because some characters we display as ^M, while others as \n.  Perhaps
> > is not a big deal, though.
> 
> We should definitely strive for consistency here...  \r and \f for ^M
> and ^L is fine by me (although I guess more people are familiar with ^L
> than \f).

I very much hope we leave the ^M and ^L display alone.  This is what
we did since day one (and yes, \n is a special case), and I'd rather
we didn't change that just in the name of consistency.




This bug report was last modified 4 years and 237 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.