GNU bug report logs - #51262
[PATCH] Don't use color escape sequences in `vc-git-expanded-log-entry'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51262 in the body.
You can then email your comments to 51262 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jan Synáček <jan.synacek <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Don't use color escape sequences in
 `vc-git-expanded-log-entry'
Date: Mon, 18 Oct 2021 12:45:48 +0200

[Message part 1 (text/plain, inline)]

-- 
Jan Synáček

[0001-Don-t-use-color-escape-sequences-in-vc-git-expanded-.patch (text/x-patch, attachment)]

Message #8 received at 51262 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Jan Synáček <jan.synacek <at> gmail.com>
Cc: 51262 <at> debbugs.gnu.org
Subject: Re: bug#51262: [PATCH] Don't use color escape sequences in
 `vc-git-expanded-log-entry'
Date: Mon, 18 Oct 2021 22:16:11 -0700

Jan Synáček <jan.synacek <at> gmail.com> writes:

> From acbfec361709c5eebafb9a957e76f70500083cf0 Mon Sep 17 00:00:00 2001
> From: Jan Synacek <jan.synacek <at> gmail.com>
> Date: Mon, 18 Oct 2021 12:34:38 +0200
> Subject: [PATCH] Don't use color escape sequences in
>  `vc-git-expanded-log-entry'
>
> * lisp/vc/vc-git.el (vc-git-expanded-log-entry): Use --no-color in git
> invocation.
>
> Copyright-paperwork-exempt: yes
> ---
>  lisp/vc/vc-git.el | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
> index 35c0838dd6..3f89fad235 100644
> --- a/lisp/vc/vc-git.el
> +++ b/lisp/vc/vc-git.el
> @@ -1323,7 +1323,7 @@ vc-git-show-log-entry
>
>  (defun vc-git-expanded-log-entry (revision)
>    (with-temp-buffer
> -    (apply #'vc-git-command t nil nil (list "log" revision "-1" "--"))
> +    (apply #'vc-git-command t nil nil (list "log" revision "-1"  "--no-color" "--"))
>      (goto-char (point-min))
>      (unless (eobp)
>        ;; Indent the expanded log entry.

Thanks for the patch.

Could you add some details here, such as what problem it is supposed to
fix?  How can I reproduce the issue here, starting from emacs -Q?

Message #11 received at 51262 <at> debbugs.gnu.org (full text, mbox):

From: Jan Synáček <jan.synacek <at> gmail.com>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51262 <at> debbugs.gnu.org
Subject: Re: bug#51262: [PATCH] Don't use color escape sequences in
 `vc-git-expanded-log-entry'
Date: Tue, 19 Oct 2021 10:15:25 +0200

On Tue, Oct 19, 2021 at 7:16 AM Stefan Kangas <stefan <at> marxist.se> wrote:
> ...
>
> Could you add some details here, such as what problem it is supposed to
> fix?  How can I reproduce the issue here, starting from emacs -Q?

Sure. Sorry for not doing it earlier. For some reason, I assumed that this was
obvious.

Here's the reproducer (built from the latest commit on the emacs-28 branch):

  1) mkdir /tmp/test
  2) cd /tmp/test/
  3) git init
  4) echo data > file.txt
  5) git add file.txt
  6) git commit -m "first commit"
  7) emacs -Q
  8) <run shell and cd /tmp/test>
  9) <execute C-x v L>
  10) <hit RET on the first commit>

This is what I see on my system (I hope that gmail doesn't remove the escapes):

*  (HEAD -> master)520684e..: Jan Synacek 2021-10-19 first commit
 ^[[33mcommit 520684e773918234874a35738b094ca39b63a822^[ [m
Author: Jan Synacek <jan.synacek <at> gmail.com>
Date:   Tue Oct 19 10:04:02 2021 +0200

  first commit

It might be dependent on git configuration, but I think it's safe to assume that
there might be escape sequences and simply use --no-color. And that's what
my patch does.

Regards,
-- 
Jan Synáček

Message #14 received at 51262 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Jan Synáček <jan.synacek <at> gmail.com>
Cc: 51262 <at> debbugs.gnu.org
Subject: Re: bug#51262: [PATCH] Don't use color escape sequences in
 `vc-git-expanded-log-entry'
Date: Tue, 19 Oct 2021 01:33:56 -0700

Jan Synáček <jan.synacek <at> gmail.com> writes:

> Sure. Sorry for not doing it earlier. For some reason, I assumed that this was
> obvious.

Thanks.

> Here's the reproducer (built from the latest commit on the emacs-28 branch):

(I just used the emacs.git repository here.)

>   7) emacs -Q
>   8) <run shell and cd /tmp/test>
>   9) <execute C-x v L>
>   10) <hit RET on the first commit>
>
> This is what I see on my system (I hope that gmail doesn't remove the escapes):
>
> *  (HEAD -> master)520684e..: Jan Synacek 2021-10-19 first commit
>  ^[[33mcommit 520684e773918234874a35738b094ca39b63a822^[ [m
> Author: Jan Synacek <jan.synacek <at> gmail.com>
> Date:   Tue Oct 19 10:04:02 2021 +0200
>
>   first commit

Here, I actually see the colours, and no escape sequences.

The question is what is different in our setups.  Could you post the
output of M-x report-emacs-bug?  Is there anything in your ~/.gitconfig
that could be causing this?

> It might be dependent on git configuration, but I think it's safe to assume that
> there might be escape sequences and simply use --no-color. And that's what
> my patch does.

I agree that you shouldn't need to see those escape sequences, but it
would be better if we could narrow it down so we don't have to remove
colours for everyone.  The first step is to try to figure out what it is
that makes you see control sequences where I get colours.

Message #17 received at 51262 <at> debbugs.gnu.org (full text, mbox):

From: Jan Synáček <jan.synacek <at> gmail.com>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51262 <at> debbugs.gnu.org
Subject: Re: bug#51262: [PATCH] Don't use color escape sequences in
 `vc-git-expanded-log-entry'
Date: Tue, 19 Oct 2021 10:53:41 +0200

On Tue, Oct 19, 2021 at 10:33 AM Stefan Kangas <stefan <at> marxist.se> wrote:
>
> ...
> > This is what I see on my system (I hope that gmail doesn't remove the escapes):
> >
> > *  (HEAD -> master)520684e..: Jan Synacek 2021-10-19 first commit
> >  ^[[33mcommit 520684e773918234874a35738b094ca39b63a822^[ [m
> > Author: Jan Synacek <jan.synacek <at> gmail.com>
> > Date:   Tue Oct 19 10:04:02 2021 +0200
> >
> >   first commit
>
> Here, I actually see the colours, and no escape sequences.

Colors as in interpreted escape sequences?

> The question is what is different in our setups.  Could you post the
> output of M-x report-emacs-bug?  Is there anything in your ~/.gitconfig
> that could be causing this?
>
> > It might be dependent on git configuration, but I think it's safe to assume that
> > there might be escape sequences and simply use --no-color. And that's what
> > my patch does.
>
> I agree that you shouldn't need to see those escape sequences, but it
> would be better if we could narrow it down so we don't have to remove
> colours for everyone.  The first step is to try to figure out what it is
> that makes you see control sequences where I get colours.

It looks like the following part of my ~/.gitconfig triggers the issue:
...
[color]
    ui = always
...

Here's the outupt of report-emacs-bug:

In GNU Emacs 28.0.60 (build 5, x86_64-pc-linux-gnu, GTK+ Version
3.24.30, cairo version 1.17.4)
 of 2021-10-19 built on jsynacek-home
Repository revision: 66fbd5527335cb3136b65ed3644e5a8b151add32
Repository branch: emacs-28
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: Arch Linux

Configured using:
 'configure --with-native-compilation'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-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
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny rfc822 mml mml-sec epa
derived epg rfc6068 epg-config gnus-util rmail rmail-loaddefs
auth-source eieio eieio-core eieio-loaddefs password-cache json map
text-property-search time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail comp comp-cstr warnings
subr-x rx cl-seq cl-macs rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils add-log log-view pcvs-util cl-extra help-mode seq byte-opt gv
bytecomp byte-compile cconv vc-mtn vc-hg vc-git diff-mode easy-mmode
vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs vc vc-dispatcher dired-aux
cl-loaddefs cl-lib dired dired-loaddefs iso-transl tooltip eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer 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 composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice
button loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 109429 5832)
 (symbols 48 9402 1)
 (strings 32 28203 1960)
 (string-bytes 1 908834)
 (vectors 16 19670)
 (vector-slots 8 345815 11442)
 (floats 8 30 53)
 (intervals 56 354 0)
 (buffers 992 14))

Message #20 received at 51262 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Jan Synáček <jan.synacek <at> gmail.com>
Cc: 51262 <at> debbugs.gnu.org
Subject: Re: bug#51262: [PATCH] Don't use color escape sequences in
 `vc-git-expanded-log-entry'
Date: Tue, 19 Oct 2021 11:00:57 -0700

close 51262 28.1
thanks

Jan Synáček <jan.synacek <at> gmail.com> writes:

> It looks like the following part of my ~/.gitconfig triggers the issue:
> ...
> [color]
>     ui = always

Aha, so that's the culprit.  Presumably without that, git detects that
it's a "dumb" terminal and doesn't output any color escape sequences.

> Colors as in interpreted escape sequences?

That was my first assumption, but it's actually just font-locking.

It seems like your proposed patch does fix the reported issue, and I
could see no other adverse effects; the colors are there there even with
your patch.

I have therefore now pushed this to the emacs-28 branch (commit
5c1a575ef4) with some minor touch-ups to the commit message.  I'm
therefore closing this bug report.

Thanks again for the bug report and patch!

Previous Next

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