unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
@ 2016-05-21 13:02 Uwe Brauer
  2016-05-23 11:52 ` Dmitry Gutov
  2016-05-23 17:40 ` Paul Eggert
  0 siblings, 2 replies; 36+ messages in thread
From: Uwe Brauer @ 2016-05-21 13:02 UTC (permalink / raw)
  To: 23595

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


The LaTeX  file attached, which contains Chinese/Japanese chars in
UTF-8(16) coding, can be compiled successfully with LaTeX (texlive
2015).

The following fails:

emacs -Q

Register the file (either with GIT, HG, RCS) modify commit and then run
vc-diff

The resulting diff contains either rubbish or fails to run.
Files attached.





In GNU Emacs 25.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.20.1)
 of 2016-01-19 built on Gilgamesch
Repository revision: e2203fb3260d959661eba307db0e289143698c5e
Windowing system distributor 'The X.Org Foundation', version 11.0.10706000
System Description:	Ubuntu 10.04.4 LTS

Configured using:
 'configure --prefix=/opt/emacs25/'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS NOTIFY GNUTLS LIBXML2 FREETYPE
M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK2 X11

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

Major mode: Group

Minor modes in effect:
  gnus-topic-mode: t
  cursor-sensor-mode: t
  TeX-PDF-mode: t
  TeX-source-correlate-mode: t
  global-diff-hl-mode: t
  diff-auto-refine-mode: t
  display-time-mode: t
  global-orglink-mode: t
  async-bytecomp-package-mode: t
  better-registers: t
  recentf-mode: t
  gnus-undo-mode: t
  shell-dirtrack-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
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent messages:
nnimap read 175k from imap.gmail.com
nnimap read 180k from imap.gmail.com
nnimap read 193k from imap.gmail.com
nnimap read 202k from imap.gmail.com
nnimap read 206k from imap.gmail.com
nnimap read 225k from imap.gmail.com
Reading active file from archive via nnml...done
Reading active file via nndraft...done
Checking new news...done
Invalid face reference: font-lock-comment-warn-face [18 times]

Load-path shadows:
/home/oub/emacs/site-lisp/packages/vm-8.2.0b/lisp/vm-pcrisis hides /home/oub/emacs/site-lisp/versch/vm-pcrisis
/home/oub/emacs/site-lisp/packages/auctex-git/auctex/texmathp hides /home/oub/emacs/site-lisp/versch/texmathp
/home/oub/emacs/site-lisp/packages/personal-lisp/test hides /home/oub/emacs/site-lisp/versch/test
/home/oub/emacs/site-lisp/packages/remember-2.0/remember hides /home/oub/emacs/site-lisp/versch/remember
/home/oub/emacs/site-lisp/packages/personal-lisp/extra hides /home/oub/emacs/site-lisp/versch/extra
/home/oub/emacs/site-lisp/babel hides /home/oub/emacs/site-lisp/versch/babel
/home/oub/emacs/site-lisp/versch/org-addons hides /home/oub/emacs/init/org-addons
/home/oub/emacs/site-lisp/versch/bm hides /home/oub/.emacs.d/elpa/bm-20151222.1603/bm
/home/oub/emacs/site-lisp/versch/latex-pretty-symbols hides /home/oub/.emacs.d/elpa/latex-pretty-symbols-20151112.244/latex-pretty-symbols
/home/oub/emacs/site-lisp/versch/markdown-mode hides /home/oub/.emacs.d/elpa/markdown-mode-20160513.618/markdown-mode
/home/oub/.emacs.d/elpa/helm-20160520.1124/helm-multi-match hides /home/oub/.emacs.d/elpa/helm-core-20160519.2213/helm-multi-match
/home/oub/emacs/site-lisp/versch/matlab-publish hides /home/oub/.emacs.d/elpa/matlab-mode-20160416.34/matlab-publish
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-mac-link hides /home/oub/.emacs.d/elpa/org-mac-link-20160109.1443/org-mac-link
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox hides /home/oub/.emacs.d/elpa/org-20160516/ox
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-texinfo hides /home/oub/.emacs.d/elpa/org-20160516/ox-texinfo
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-publish hides /home/oub/.emacs.d/elpa/org-20160516/ox-publish
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-org hides /home/oub/.emacs.d/elpa/org-20160516/ox-org
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-odt hides /home/oub/.emacs.d/elpa/org-20160516/ox-odt
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-md hides /home/oub/.emacs.d/elpa/org-20160516/ox-md
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-man hides /home/oub/.emacs.d/elpa/org-20160516/ox-man
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-latex hides /home/oub/.emacs.d/elpa/org-20160516/ox-latex
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-icalendar hides /home/oub/.emacs.d/elpa/org-20160516/ox-icalendar
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-html hides /home/oub/.emacs.d/elpa/org-20160516/ox-html
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-beamer hides /home/oub/.emacs.d/elpa/org-20160516/ox-beamer
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-ascii hides /home/oub/.emacs.d/elpa/org-20160516/ox-ascii
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org hides /home/oub/.emacs.d/elpa/org-20160516/org
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-w3m hides /home/oub/.emacs.d/elpa/org-20160516/org-w3m
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-version hides /home/oub/.emacs.d/elpa/org-20160516/org-version
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-timer hides /home/oub/.emacs.d/elpa/org-20160516/org-timer
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-table hides /home/oub/.emacs.d/elpa/org-20160516/org-table
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-src hides /home/oub/.emacs.d/elpa/org-20160516/org-src
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-rmail hides /home/oub/.emacs.d/elpa/org-20160516/org-rmail
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-protocol hides /home/oub/.emacs.d/elpa/org-20160516/org-protocol
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-plot hides /home/oub/.emacs.d/elpa/org-20160516/org-plot
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-pcomplete hides /home/oub/.emacs.d/elpa/org-20160516/org-pcomplete
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-mouse hides /home/oub/.emacs.d/elpa/org-20160516/org-mouse
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-mobile hides /home/oub/.emacs.d/elpa/org-20160516/org-mobile
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-mhe hides /home/oub/.emacs.d/elpa/org-20160516/org-mhe
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-macs hides /home/oub/.emacs.d/elpa/org-20160516/org-macs
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-macro hides /home/oub/.emacs.d/elpa/org-20160516/org-macro
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-loaddefs hides /home/oub/.emacs.d/elpa/org-20160516/org-loaddefs
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-list hides /home/oub/.emacs.d/elpa/org-20160516/org-list
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-lint hides /home/oub/.emacs.d/elpa/org-20160516/org-lint
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-irc hides /home/oub/.emacs.d/elpa/org-20160516/org-irc
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-install hides /home/oub/.emacs.d/elpa/org-20160516/org-install
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-inlinetask hides /home/oub/.emacs.d/elpa/org-20160516/org-inlinetask
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-info hides /home/oub/.emacs.d/elpa/org-20160516/org-info
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-indent hides /home/oub/.emacs.d/elpa/org-20160516/org-indent
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-id hides /home/oub/.emacs.d/elpa/org-20160516/org-id
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-habit hides /home/oub/.emacs.d/elpa/org-20160516/org-habit
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-gnus hides /home/oub/.emacs.d/elpa/org-20160516/org-gnus
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-footnote hides /home/oub/.emacs.d/elpa/org-20160516/org-footnote
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-feed hides /home/oub/.emacs.d/elpa/org-20160516/org-feed
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-faces hides /home/oub/.emacs.d/elpa/org-20160516/org-faces
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-eshell hides /home/oub/.emacs.d/elpa/org-20160516/org-eshell
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-entities hides /home/oub/.emacs.d/elpa/org-20160516/org-entities
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-element hides /home/oub/.emacs.d/elpa/org-20160516/org-element
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-docview hides /home/oub/.emacs.d/elpa/org-20160516/org-docview
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-datetree hides /home/oub/.emacs.d/elpa/org-20160516/org-datetree
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-ctags hides /home/oub/.emacs.d/elpa/org-20160516/org-ctags
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-crypt hides /home/oub/.emacs.d/elpa/org-20160516/org-crypt
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-compat hides /home/oub/.emacs.d/elpa/org-20160516/org-compat
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-colview hides /home/oub/.emacs.d/elpa/org-20160516/org-colview
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-clock hides /home/oub/.emacs.d/elpa/org-20160516/org-clock
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-capture hides /home/oub/.emacs.d/elpa/org-20160516/org-capture
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-bibtex hides /home/oub/.emacs.d/elpa/org-20160516/org-bibtex
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-bbdb hides /home/oub/.emacs.d/elpa/org-20160516/org-bbdb
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-attach hides /home/oub/.emacs.d/elpa/org-20160516/org-attach
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-archive hides /home/oub/.emacs.d/elpa/org-20160516/org-archive
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-agenda hides /home/oub/.emacs.d/elpa/org-20160516/org-agenda
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob hides /home/oub/.emacs.d/elpa/org-20160516/ob
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-tangle hides /home/oub/.emacs.d/elpa/org-20160516/ob-tangle
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-table hides /home/oub/.emacs.d/elpa/org-20160516/ob-table
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-stan hides /home/oub/.emacs.d/elpa/org-20160516/ob-stan
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-sqlite hides /home/oub/.emacs.d/elpa/org-20160516/ob-sqlite
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-sql hides /home/oub/.emacs.d/elpa/org-20160516/ob-sql
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-shen hides /home/oub/.emacs.d/elpa/org-20160516/ob-shen
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-shell hides /home/oub/.emacs.d/elpa/org-20160516/ob-shell
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-sed hides /home/oub/.emacs.d/elpa/org-20160516/ob-sed
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-screen hides /home/oub/.emacs.d/elpa/org-20160516/ob-screen
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-scheme hides /home/oub/.emacs.d/elpa/org-20160516/ob-scheme
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-scala hides /home/oub/.emacs.d/elpa/org-20160516/ob-scala
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-sass hides /home/oub/.emacs.d/elpa/org-20160516/ob-sass
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-ruby hides /home/oub/.emacs.d/elpa/org-20160516/ob-ruby
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-ref hides /home/oub/.emacs.d/elpa/org-20160516/ob-ref
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-python hides /home/oub/.emacs.d/elpa/org-20160516/ob-python
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-processing hides /home/oub/.emacs.d/elpa/org-20160516/ob-processing
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-plantuml hides /home/oub/.emacs.d/elpa/org-20160516/ob-plantuml
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-picolisp hides /home/oub/.emacs.d/elpa/org-20160516/ob-picolisp
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-perl hides /home/oub/.emacs.d/elpa/org-20160516/ob-perl
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-org hides /home/oub/.emacs.d/elpa/org-20160516/ob-org
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-octave hides /home/oub/.emacs.d/elpa/org-20160516/ob-octave
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-ocaml hides /home/oub/.emacs.d/elpa/org-20160516/ob-ocaml
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-mscgen hides /home/oub/.emacs.d/elpa/org-20160516/ob-mscgen
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-maxima hides /home/oub/.emacs.d/elpa/org-20160516/ob-maxima
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-matlab hides /home/oub/.emacs.d/elpa/org-20160516/ob-matlab
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-makefile hides /home/oub/.emacs.d/elpa/org-20160516/ob-makefile
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-lob hides /home/oub/.emacs.d/elpa/org-20160516/ob-lob
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-lisp hides /home/oub/.emacs.d/elpa/org-20160516/ob-lisp
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-lilypond hides /home/oub/.emacs.d/elpa/org-20160516/ob-lilypond
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-ledger hides /home/oub/.emacs.d/elpa/org-20160516/ob-ledger
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-latex hides /home/oub/.emacs.d/elpa/org-20160516/ob-latex
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-keys hides /home/oub/.emacs.d/elpa/org-20160516/ob-keys
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-js hides /home/oub/.emacs.d/elpa/org-20160516/ob-js
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-java hides /home/oub/.emacs.d/elpa/org-20160516/ob-java
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-io hides /home/oub/.emacs.d/elpa/org-20160516/ob-io
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-haskell hides /home/oub/.emacs.d/elpa/org-20160516/ob-haskell
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-groovy hides /home/oub/.emacs.d/elpa/org-20160516/ob-groovy
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-gnuplot hides /home/oub/.emacs.d/elpa/org-20160516/ob-gnuplot
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-fortran hides /home/oub/.emacs.d/elpa/org-20160516/ob-fortran
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-forth hides /home/oub/.emacs.d/elpa/org-20160516/ob-forth
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-exp hides /home/oub/.emacs.d/elpa/org-20160516/ob-exp
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-eval hides /home/oub/.emacs.d/elpa/org-20160516/ob-eval
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-emacs-lisp hides /home/oub/.emacs.d/elpa/org-20160516/ob-emacs-lisp
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-ebnf hides /home/oub/.emacs.d/elpa/org-20160516/ob-ebnf
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-dot hides /home/oub/.emacs.d/elpa/org-20160516/ob-dot
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-ditaa hides /home/oub/.emacs.d/elpa/org-20160516/ob-ditaa
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-css hides /home/oub/.emacs.d/elpa/org-20160516/ob-css
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-core hides /home/oub/.emacs.d/elpa/org-20160516/ob-core
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-coq hides /home/oub/.emacs.d/elpa/org-20160516/ob-coq
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-comint hides /home/oub/.emacs.d/elpa/org-20160516/ob-comint
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-clojure hides /home/oub/.emacs.d/elpa/org-20160516/ob-clojure
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-calc hides /home/oub/.emacs.d/elpa/org-20160516/ob-calc
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-awk hides /home/oub/.emacs.d/elpa/org-20160516/ob-awk
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-asymptote hides /home/oub/.emacs.d/elpa/org-20160516/ob-asymptote
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-abc hides /home/oub/.emacs.d/elpa/org-20160516/ob-abc
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-R hides /home/oub/.emacs.d/elpa/org-20160516/ob-R
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-J hides /home/oub/.emacs.d/elpa/org-20160516/ob-J
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-C hides /home/oub/.emacs.d/elpa/org-20160516/ob-C
/home/oub/emacs/site-lisp/versch/json hides /opt/emacs25/share/emacs/25.1.50/lisp/json
/home/oub/emacs/site-lisp/versch/ffap hides /opt/emacs25/share/emacs/25.1.50/lisp/ffap
/home/oub/emacs/site-lisp/versch/abbrev hides /opt/emacs25/share/emacs/25.1.50/lisp/abbrev
/home/oub/ALLES/vc-emacs-neu/vc hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/vc
/home/oub/ALLES/vc-emacs-neu/vc-svn hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/vc-svn
/home/oub/ALLES/vc-emacs-neu/vc-src hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/vc-src
/home/oub/ALLES/vc-emacs-neu/vc-sccs hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/vc-sccs
/home/oub/ALLES/vc-emacs-neu/vc-rcs hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/vc-rcs
/home/oub/ALLES/vc-emacs-neu/vc-mtn hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/vc-mtn
/home/oub/ALLES/vc-emacs-neu/vc-hooks hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/vc-hooks
/home/oub/ALLES/vc-emacs-neu/vc-hg hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/vc-hg
/home/oub/ALLES/vc-emacs-neu/vc-git hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/vc-git
/home/oub/ALLES/vc-emacs-neu/vc-filewise hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/vc-filewise
/home/oub/ALLES/vc-emacs-neu/vc-dispatcher hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/vc-dispatcher
/home/oub/ALLES/vc-emacs-neu/vc-dir hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/vc-dir
/home/oub/ALLES/vc-emacs-neu/vc-dav hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/vc-dav
/home/oub/ALLES/vc-emacs-neu/vc-cvs hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/vc-cvs
/home/oub/ALLES/vc-emacs-neu/vc-bzr hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/vc-bzr
/home/oub/ALLES/vc-emacs-neu/vc-annotate hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/vc-annotate
/home/oub/ALLES/vc-emacs-neu/smerge-mode hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/smerge-mode
/home/oub/ALLES/vc-emacs-neu/pcvs hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/pcvs
/home/oub/ALLES/vc-emacs-neu/pcvs-util hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/pcvs-util
/home/oub/ALLES/vc-emacs-neu/pcvs-parse hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/pcvs-parse
/home/oub/ALLES/vc-emacs-neu/pcvs-info hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/pcvs-info
/home/oub/ALLES/vc-emacs-neu/pcvs-defs hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/pcvs-defs
/home/oub/ALLES/vc-emacs-neu/log-view hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/log-view
/home/oub/ALLES/vc-emacs-neu/log-edit hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/log-edit
/home/oub/ALLES/vc-emacs-neu/emerge hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/emerge
/home/oub/ALLES/vc-emacs-neu/ediff hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/ediff
/home/oub/ALLES/vc-emacs-neu/ediff-wind hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/ediff-wind
/home/oub/ALLES/vc-emacs-neu/ediff-vers hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/ediff-vers
/home/oub/ALLES/vc-emacs-neu/ediff-util hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/ediff-util
/home/oub/ALLES/vc-emacs-neu/ediff-ptch hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/ediff-ptch
/home/oub/ALLES/vc-emacs-neu/ediff-mult hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/ediff-mult
/home/oub/ALLES/vc-emacs-neu/ediff-merg hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/ediff-merg
/home/oub/ALLES/vc-emacs-neu/ediff-init hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/ediff-init
/home/oub/ALLES/vc-emacs-neu/ediff-hook hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/ediff-hook
/home/oub/ALLES/vc-emacs-neu/ediff-help hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/ediff-help
/home/oub/ALLES/vc-emacs-neu/ediff-diff hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/ediff-diff
/home/oub/ALLES/vc-emacs-neu/diff hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/diff
/home/oub/ALLES/vc-emacs-neu/diff-mode hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/diff-mode
/home/oub/ALLES/vc-emacs-neu/cvs-status hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/cvs-status
/home/oub/ALLES/vc-emacs-neu/compare-w hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/compare-w
/home/oub/ALLES/vc-emacs-neu/add-log hides /opt/emacs25/share/emacs/25.1.50/lisp/vc/add-log
/home/oub/emacs/site-lisp/packages/remember-2.0/remember hides /opt/emacs25/share/emacs/25.1.50/lisp/textmodes/remember
/home/oub/emacs/site-lisp/packages/personal-lisp/refill hides /opt/emacs25/share/emacs/25.1.50/lisp/textmodes/refill
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ox
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-texinfo hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ox-texinfo
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-publish hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ox-publish
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-org hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ox-org
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-odt hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ox-odt
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-md hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ox-md
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-man hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ox-man
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-latex hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ox-latex
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-icalendar hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ox-icalendar
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-html hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ox-html
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-beamer hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ox-beamer
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ox-ascii hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ox-ascii
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-w3m hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-w3m
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-version hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-version
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-timer hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-timer
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-table hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-table
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-src hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-src
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-rmail hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-rmail
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-protocol hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-protocol
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-plot hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-plot
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-pcomplete hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-pcomplete
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-mouse hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-mouse
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-mobile hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-mobile
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-mhe hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-mhe
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-macs hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-macs
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-macro hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-macro
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-loaddefs hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-loaddefs
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-list hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-list
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-irc hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-irc
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-install hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-install
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-inlinetask hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-inlinetask
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-info hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-info
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-indent hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-indent
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-id hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-id
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-habit hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-habit
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-gnus hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-gnus
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-footnote hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-footnote
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-feed hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-feed
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-faces hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-faces
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-eshell hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-eshell
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-entities hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-entities
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-element hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-element
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-docview hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-docview
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-datetree hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-datetree
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-ctags hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-ctags
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-crypt hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-crypt
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-compat hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-compat
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-colview hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-colview
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-clock hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-clock
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-capture hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-capture
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-bibtex hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-bibtex
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-bbdb hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-bbdb
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-attach hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-attach
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-archive hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-archive
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/org-agenda hides /opt/emacs25/share/emacs/25.1.50/lisp/org/org-agenda
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-tangle hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-tangle
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-table hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-table
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-sqlite hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-sqlite
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-sql hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-sql
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-shen hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-shen
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-screen hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-screen
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-scheme hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-scheme
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-scala hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-scala
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-sass hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-sass
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-ruby hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-ruby
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-ref hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-ref
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-python hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-python
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-plantuml hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-plantuml
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-picolisp hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-picolisp
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-perl hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-perl
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-org hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-org
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-octave hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-octave
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-ocaml hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-ocaml
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-mscgen hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-mscgen
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-maxima hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-maxima
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-matlab hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-matlab
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-makefile hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-makefile
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-lob hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-lob
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-lisp hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-lisp
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-lilypond hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-lilypond
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-ledger hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-ledger
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-latex hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-latex
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-keys hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-keys
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-js hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-js
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-java hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-java
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-io hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-io
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-haskell hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-haskell
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-gnuplot hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-gnuplot
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-fortran hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-fortran
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-exp hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-exp
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-eval hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-eval
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-emacs-lisp hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-emacs-lisp
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-dot hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-dot
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-ditaa hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-ditaa
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-css hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-css
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-core hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-core
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-comint hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-comint
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-clojure hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-clojure
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-calc hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-calc
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-awk hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-awk
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-asymptote hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-asymptote
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-R hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-R
/home/oub/.emacs.d/elpa/org-plus-contrib-20160516/ob-C hides /opt/emacs25/share/emacs/25.1.50/lisp/org/ob-C
/home/oub/.emacs.d/elpa/soap-client-3.1.1/soap-inspect hides /opt/emacs25/share/emacs/25.1.50/lisp/net/soap-inspect
/home/oub/.emacs.d/elpa/soap-client-3.1.1/soap-client hides /opt/emacs25/share/emacs/25.1.50/lisp/net/soap-client
/home/oub/emacs/site-lisp/versch/quickurl hides /opt/emacs25/share/emacs/25.1.50/lisp/net/quickurl
/home/oub/emacs/site-lisp/versch/smtpmail hides /opt/emacs25/share/emacs/25.1.50/lisp/mail/smtpmail
/home/oub/emacs/site-lisp/versch/hashcash hides /opt/emacs25/share/emacs/25.1.50/lisp/mail/hashcash
/home/oub/emacs/site-lisp/versch/feedmail hides /opt/emacs25/share/emacs/25.1.50/lisp/mail/feedmail
/home/oub/emacs/site-lisp/versch/hebrew hides /opt/emacs25/share/emacs/25.1.50/lisp/language/hebrew
/home/oub/emacs/site-lisp/packages/personal-lisp/lisp hides /opt/emacs25/share/emacs/25.1.50/lisp/emacs-lisp/lisp
/home/oub/emacs/site-lisp/versch/longlines hides /opt/emacs25/share/emacs/25.1.50/lisp/obsolete/longlines
/home/oub/emacs/site-lisp/packages/iso-pkg/iso-swed hides /opt/emacs25/share/emacs/25.1.50/lisp/obsolete/iso-swed
/home/oub/emacs/site-lisp/packages/iso-pkg/iso-insert hides /opt/emacs25/share/emacs/25.1.50/lisp/obsolete/iso-insert
/home/oub/emacs/site-lisp/packages/iso-pkg/iso-acc hides /opt/emacs25/share/emacs/25.1.50/lisp/obsolete/iso-acc

Features:
(shadow gnus-cite hashcash footnote emacsbug gnus-topic cursor-sensor
utf-7 nndraft nnmh bbdb-gnus bbdb-snarf mail-extr nnnil comment sort
org-eldoc preview prv-emacs tex-fold reftex-dcr reftex-auc flyspell
ispell cdlatex texmathp auto-capitalize tex-bar toolbar-x tex-buf
font-latex latex tex-style tex dbus crm latexenc ibuf-ext ibuffer
ibuffer-loaddefs map character-fold misearch multi-isearch dired-aux
vc-mtn vc-git vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs diff-hl-dired
vc-hg org-rmail org-mhe org-irc org-info org-gnus org-docview doc-view
jka-compr image-mode org-bbdb org-w3m ob-R ffap browse-kill-ring+
browse-kill-ring uimage url-ftp url-file url-dired image-file iimage
autobookmarks bookmark pp elpakit server shadchen
latex-unicode-math-mode robin code-library gist gh-gist gh-oauth gh-api
logito gh-cache pcache gh-auth gh-common gh-url gh-profile rx eieio-base
writegood-mode writeroom-mode visual-fill-column xemacs-compat dired-zip
calfw-ical calfw-cal calfw weekly-view cal-desk-calendar lunar solar
cal-dst holidays hol-loaddefs bm diff-hl vc-dir goto-chg ahg vc-annotate
grep ewoc log-edit pcvs-util add-log diff-mode align reftex-sel
bibretrieve time monky bindat iso-acc iso-cvt ref-master my-hg-commit
auto-insert-tkld date addl dired-tar all iso-cleanupmath hgignore-mode
vc-change-login backup-each-save vc-ensure-checkin my-vc-addons vc
vc-dispatcher latex-wcount dob-words latexdiff daily-journal gnus-dired
matlab-addons matlab-publish matlab_init cus-edit cus-start cus-load
company-matlab-shell matlab tempo company matlab-boxquote my-refill-msg
my-sc-addons gnus-encrypt org_init org-protocol ox-pandoc ox-md
ox-mediawiki ob-rec rec-mode org-tracktable orgtbl-join orglink
org-auctex-keys ox-odt rng-loc rng-uri rng-parse rng-match rng-dt
rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util
my-org-ref org-ref org-ref-helm-bibtex helm-bibtex bibtex-completion
helm-plugin helm-utils helm-net helm-help biblio biblio-dissemin
biblio-hal biblio-dblp biblio-crossref biblio-arxiv biblio-doi
biblio-core edebug-x edebug which-func imenu tar-mode let-alist
url-queue ido hl-line autoload lisp-mnt mm-archive network-stream nsm
starttls org-ref-helm helm helm-source eieio-compat helm-multi-match
helm-lib helm-config helm-easymenu edmacro kmacro async-bytecomp async
reftex-cite parsebib org-ref-glossary org-ref-utils org-ref-bibtex
org-ref-citeproc key-chord hydra lv doi-utils org-bibtex bibtex f s
ucs-normalize dash ob-octave ob-org org-mime org-readme http-post-simple
url-http url-auth url-gw puny seq yaoddmuse thingatpt skeleton sgml-mode
better-registers list-register query-replace-region ediff-addons
re-builder extview pandoc anti-niqqud sigadapt-simple sigadapt sendmail
bbdbadapt-sc texify-article TeX-escape-region supercite regi
bbdbciteadpt filladapt-pat filladapt next-longline recentf tree-widget
my-addons org-addons ox-latex ox-icalendar ox-html ox-ascii ox-publish
ox org-element avl-tree org-table org-install sp-eng-ger-fr-minor
folding-isearch folding gnus-init nnmairix nnml gnus-html url-cache url
url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf bbdbadapt-top-posting gnus-diary nndiary nnrss xml mm-url
gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art
mm-uu mml2015 mm-view mml-smime smime dig nntp gnus-cache nnir gnus-sum
gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source tls
gnutls utf7 netrc parse-time gnus-spec gnus-int gnus-range message dired
dired-loaddefs rfc822 mml mml-sec gmm-utils mailheader gnus-win gnus
gnus-ems wid-edit nnoo nnheader mail-utils pgp-mime-attach-key my-smiley
gnus-move-display-attachment epa-file epa derived epg boxquote rect
icalendar diary-lib diary-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailcap shr dom subr-x
browse-url bbdb-init bbdb-autoloads bbdbadapt-ispell bbdbadapt-gcc
bbdbadapt-encrypt my-bbdb-addons remember-bbdb bbdb-com warnings
mailabbrev bbdb timezone cl org-remember org-datetree
org-location-google-maps org-agenda google-maps google-maps-static
url-util google-maps-geocode google-maps-base json org org-macro
org-footnote org-pcomplete org-list org-faces org-entities noutline
outline easy-mmode org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-src ob-keys ob-comint ob-core ob-eval org-compat
org-macs org-loaddefs format-spec find-func cal-menu calendar
cal-loaddefs remember extra emacs_keys my-hebrew-init toggle my-mark
quail my-latex-env my-auctex-init reftex reftex-loaddefs reftex-vars
latex-keys my-fill-latex-sentence advice preview-latex tex-site
auto-loads flyspell-abbrev-multilang iv-sp-am-br-ger-fr-minor
my-change-prettify-list tex-mode compile shell pcomplete comint
ansi-color ring finder-inf info package epg-config url-handlers
url-parse auth-source cl-seq eieio byte-opt bytecomp byte-compile
cl-extra cconv eieio-core cl-macs gv eieio-loaddefs gnus-util mm-util
help-fns help-mode easymenu cl-loaddefs pcase cl-lib mail-prsvr
password-cache url-vars time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd 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 obarray 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 dbusbind inotify dynamic-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 8 986039 16894)
 (symbols 24 111306 0)
 (miscs 20 2301 397)
 (strings 16 278734 35195)
 (string-bytes 1 7537116)
 (vectors 8 105015)
 (vector-slots 4 2305029 103954)
 (floats 8 1491 557)
 (intervals 28 10492 0)
 (buffers 520 51)
 (heap 1024 56404 1925))

[-- Attachment #2: diff-rcs-result.txt --]
[-- Type: text/plain, Size: 218 bytes --]

䉩湡特⁦楬敳⁴敳琭捨楮⵪慰⹴數ल〱㘯〵⼲ㄠ〹㨳㠺㈵ऱ⸲⁡湤⁴敳琭捨楮⵪慰⹴數ल〱㘯〵⼲ㄠ〹㨴㘺〴⁤楦晥爊牣獤楦昺⁴敳琭捨楮⵪慰⹴數㨠摩晦⁦慩汥搊

[-- Attachment #3: rcs-bug.txt --]
[-- Type: text/plain, Size: 1082 bytes --]

Debugger entered--Lisp error: (error "Running rcsdiff -q   -U0 test-chin-jap.tex...FAILED (status 2)")
  signal(error ("Running rcsdiff -q   -U0 test-chin-jap.tex...FAILED (status 2)"))
  error("Running %s...FAILED (%s)" "rcsdiff -q   -U0 test-chin-jap.tex" "status 2")
  vc-do-command(" *diff-hl* " 1 "rcsdiff" ("/home/oub/ALLES/Chin-Jap/rc/test-chin-jap.tex") "-q" nil nil "-U0")
  apply(vc-do-command " *diff-hl* " 1 "rcsdiff" ("/home/oub/ALLES/Chin-Jap/rc/test-chin-jap.tex") ("-q" nil nil "-U0"))
  vc-rcs-diff(("/home/oub/ALLES/Chin-Jap/rc/test-chin-jap.tex") nil nil " *diff-hl* ")
  apply(vc-rcs-diff (("/home/oub/ALLES/Chin-Jap/rc/test-chin-jap.tex") nil nil " *diff-hl* "))
  vc-call-backend(RCS diff ("/home/oub/ALLES/Chin-Jap/rc/test-chin-jap.tex") nil nil " *diff-hl* ")
  diff-hl-changes-buffer("/home/oub/ALLES/Chin-Jap/rc/test-chin-jap.tex" RCS)
  diff-hl-changes()
  diff-hl-update()
  run-hooks(after-save-hook)
  basic-save-buffer(t)
  save-buffer(1)
  funcall-interactively(save-buffer 1)
  call-interactively(save-buffer nil nil)
  command-execute(save-buffer)

[-- Attachment #4: diff-result.txt --]
[-- Type: text/plain, Size: 145 bytes --]

diff --git a/test-chin-jap.tex b/test-chin-jap.tex
index 7f0cb2d..fa9824d 100644
Binary files a/test-chin-jap.tex and b/test-chin-jap.tex differ

[-- Attachment #5: diff-result-hg.txt --]
[-- Type: text/plain, Size: 122 bytes --]

摩晦‭爠㠵㤲挱っ〲㠱⁴敳琭捨楮⵪慰⹴數ੂ楮慲礠晩汥⁴敳琭捨楮⵪慰⹴數⁨慳⁣桡湧敤

[-- Attachment #6: test-chin-jap.tex --]
[-- Type: application/octet-stream, Size: 744 bytes --]


\documentclass{article}
\usepackage[boldfont,slantfont]{xeCJK}
\usepackage{xcolor}
\setCJKmainfont{AR PL SungtiL GB}

\begin{document}


This is an example of a latex document, which contains Chinese or
Japanase chars. It can be compiled with xelatex. However 
diff-hl-diff-goto-hunk fails.

\begin{tabular}{ll}
这是:& 975 kg\\
间:  &  13  隔\\
\end{tabular}

\end{document}

^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-21 13:02 bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS) Uwe Brauer
@ 2016-05-23 11:52 ` Dmitry Gutov
  2016-05-23 12:41   ` Uwe Brauer
  2016-05-23 16:48   ` Eli Zaretskii
  2016-05-23 17:40 ` Paul Eggert
  1 sibling, 2 replies; 36+ messages in thread
From: Dmitry Gutov @ 2016-05-23 11:52 UTC (permalink / raw)
  To: Uwe Brauer, 23595@debbugs.gnu.org

On 05/21/2016 04:02 PM, Uwe Brauer wrote:

> Register the file (either with GIT, HG, RCS) modify commit and then run
> vc-diff
> 
> The resulting diff contains either rubbish or fails to run.
> Files attached.

It seems, to an extent, be caused by our setting coding-system-for-read inside vc-diff-internal (to utf-16be-with-signature-unix, which is also the value of buffer-file-coding-system).

Without that, the result of vc-diff (at least with Git) is "Binary files a/test-chin-jap.tex and b/test-chin-jap.tex differ". Emacs 24.5 does the same.

Which is weird, considering both vc-diff-internal and vc-coding-system-for-diff have both been virtually untouched for the last couple of years.

But even if we figure out why happens, you (Uwe) probably want Git, Hg, etc, to treat this file as text, and not binary. Only then you'll be able to get meaningful diffs. I don't have a specific advice on that.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-23 11:52 ` Dmitry Gutov
@ 2016-05-23 12:41   ` Uwe Brauer
  2016-05-23 13:17     ` Dmitry Gutov
  2016-05-23 16:51     ` Eli Zaretskii
  2016-05-23 16:48   ` Eli Zaretskii
  1 sibling, 2 replies; 36+ messages in thread
From: Uwe Brauer @ 2016-05-23 12:41 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: Uwe Brauer, 23595@debbugs.gnu.org


   > On 05/21/2016 04:02 PM, Uwe Brauer wrote:


   > But even if we figure out why happens, you (Uwe) probably want Git,
   > Hg, etc, to treat this file as text, and not binary. Only then you'll
   > be able to get meaningful diffs. I don't have a specific advice on
   > that.

Right, but it is more dramatic. I don't care so much about the
difference for the (short) Asian text, but I do care about the fact that
now the file seems to be «doomed» in the sense that the diff of each and
every new commit ends up in Chinese, that is the file is considered as
binary from now on and that is really bad.

Strange that nobody noticed that before.
I am not sure what to do with this file.

Uwe 





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-23 12:41   ` Uwe Brauer
@ 2016-05-23 13:17     ` Dmitry Gutov
  2016-05-23 16:52       ` Eli Zaretskii
  2016-05-23 16:51     ` Eli Zaretskii
  1 sibling, 1 reply; 36+ messages in thread
From: Dmitry Gutov @ 2016-05-23 13:17 UTC (permalink / raw)
  To: Uwe Brauer; +Cc: 23595@debbugs.gnu.org

On 05/23/2016 03:41 PM, Uwe Brauer wrote:

> ...  that is the file is considered as
> binary from now on and that is really bad.

Yes, but it's Git that considers the file to be "binary". Emacs's VC 
probably can't do anything about that now.

Maybe the problem was created by Emacs when you were editing this file. 
Someone should investigate that, especially if you have a scenario how 
to produce a problematic file like that from scratch.

> Strange that nobody noticed that before.

This file might be unique.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-23 11:52 ` Dmitry Gutov
  2016-05-23 12:41   ` Uwe Brauer
@ 2016-05-23 16:48   ` Eli Zaretskii
  2016-05-23 17:00     ` Uwe Brauer
  2016-05-23 21:02     ` Dmitry Gutov
  1 sibling, 2 replies; 36+ messages in thread
From: Eli Zaretskii @ 2016-05-23 16:48 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: oub, 23595

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 23 May 2016 14:52:03 +0300
> 
> > The resulting diff contains either rubbish or fails to run.
> > Files attached.

I don't see any rubbish in the Git output.  With RCS, the command
signals an error, so more digging is needed to find out what's wrong
(although it could be that rcsdiff exits with non-zero status when it
sees what looks like binary files).

> It seems, to an extent, be caused by our setting coding-system-for-read inside vc-diff-internal (to utf-16be-with-signature-unix, which is also the value of buffer-file-coding-system).
> 
> Without that, the result of vc-diff (at least with Git) is "Binary files a/test-chin-jap.tex and b/test-chin-jap.tex differ". Emacs 24.5 does the same.

Setting coding-system-for-read is correct, because the important use
case is when the diffs are actually output.  The problem is that
UTF-16 is not ASCII-compatible, and so text output by Git itself will
be mishandled.  Another problem is that Git doesn't show the diffs at
all.

> Which is weird, considering both vc-diff-internal and vc-coding-system-for-diff have both been virtually untouched for the last couple of years.

Not sure what do you see as weird.

> But even if we figure out why happens, you (Uwe) probably want Git, Hg, etc, to treat this file as text, and not binary. Only then you'll be able to get meaningful diffs. I don't have a specific advice on that.

Why can't we invoke "git diff --text"?  That should fix the second
problem, I think.

As for the first problem, we should probably refrain from binding
coding-system-for-read to a CODING-SYSTEM for which

   (coding-system-get CODING-SYSTEM :ascii-compatible-p)

returns nil.  We should instead bind it to no-conversion and decode
the file data parts by hand, skipping the parts that Git itself
outputs (yes, this is messy).  Patches to that effect are welcome.

Bottom line: users who put UTF-16 encoded files into VCS are playing
with fire, and are best advised not to do that!





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-23 12:41   ` Uwe Brauer
  2016-05-23 13:17     ` Dmitry Gutov
@ 2016-05-23 16:51     ` Eli Zaretskii
  1 sibling, 0 replies; 36+ messages in thread
From: Eli Zaretskii @ 2016-05-23 16:51 UTC (permalink / raw)
  To: Uwe Brauer; +Cc: dgutov, 23595

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Mon, 23 May 2016 12:41:47 +0000
> Cc: Uwe Brauer <oub@mat.ucm.es>,
> 	"23595@debbugs.gnu.org" <23595@debbugs.gnu.org>
> 
> I don't care so much about the difference for the (short) Asian
> text, but I do care about the fact that now the file seems to be
> «doomed» in the sense that the diff of each and every new commit
> ends up in Chinese, that is the file is considered as binary from
> now on and that is really bad.

I'm guessing that Git uses the same strategy as GNU Diff for detecting
binary files, which AFAIR is by looking for binary nulls (Paul can
correct me if I'm wrong).  And UTF-16 encoded files have lots of
binary nulls.

However, using the --text switch to "git diff" ought to fix that.
Does it?





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-23 13:17     ` Dmitry Gutov
@ 2016-05-23 16:52       ` Eli Zaretskii
  0 siblings, 0 replies; 36+ messages in thread
From: Eli Zaretskii @ 2016-05-23 16:52 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: oub, 23595

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 23 May 2016 16:17:22 +0300
> Cc: "23595@debbugs.gnu.org" <23595@debbugs.gnu.org>
> 
> > Strange that nobody noticed that before.
> 
> This file might be unique.

Yes, working with UTF-16 and UCS-4 encoded text files is rather rare
and not recommended.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-23 16:48   ` Eli Zaretskii
@ 2016-05-23 17:00     ` Uwe Brauer
  2016-05-23 17:31       ` Eli Zaretskii
  2016-05-23 21:02     ` Dmitry Gutov
  1 sibling, 1 reply; 36+ messages in thread
From: Uwe Brauer @ 2016-05-23 17:00 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: oub, Dmitry Gutov, 23595

>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

   >> From: Dmitry Gutov <dgutov@yandex.ru>
   >> Date: Mon, 23 May 2016 14:52:03 +0300
   >> 
   >> > The resulting diff contains either rubbish or fails to run.
   >> > Files attached.

   > I don't see any rubbish in the Git output.  With RCS, the command
   > signals an error, so more digging is needed to find out what's wrong
   > (although it could be that rcsdiff exits with non-zero status when it
   > sees what looks like binary files).

   >> It seems, to an extent, be caused by our setting
   >> coding-system-for-read inside vc-diff-internal (to
   >> utf-16be-with-signature-unix, which is also the value of
   >> buffer-file-coding-system).
   >> 
   >> Without that, the result of vc-diff (at least with Git) is "Binary
   >> files a/test-chin-jap.tex and b/test-chin-jap.tex differ". Emacs
   >> 24.5 does the same.

   > Setting coding-system-for-read is correct, because the important use
   > case is when the diffs are actually output.  The problem is that
   > UTF-16 is not ASCII-compatible, and so text output by Git itself will
   > be mishandled.  Another problem is that Git doesn't show the diffs at
   > all.

   >> Which is weird, considering both vc-diff-internal and
   >> vc-coding-system-for-diff have both been virtually untouched for the
   >> last couple of years.

   > Not sure what do you see as weird.

   >> But even if we figure out why happens, you (Uwe) probably want Git,
   >> Hg, etc, to treat this file as text, and not binary. Only then
   >> you'll be able to get meaningful diffs. I don't have a specific
   >> advice on that.

   > Why can't we invoke "git diff --text"?  That should fix the second
   > problem, I think.

I thought the problem was caused by the fact that I did not entered that
chars, but rather copied it from some tex.stackexchange site, but I see
that was not the reason.


What is about mercurial?[1]


   > As for the first problem, we should probably refrain from binding
   > coding-system-for-read to a CODING-SYSTEM for which

   >    (coding-system-get CODING-SYSTEM :ascii-compatible-p)

   > returns nil.  We should instead bind it to no-conversion and decode
   > the file data parts by hand, skipping the parts that Git itself
   > outputs (yes, this is messy).  Patches to that effect are welcome.

   > Bottom line: users who put UTF-16 encoded files into VCS are playing
   > with fire, and are best advised not to do that!

Right, I see, that was just 2 chars in a document which contained
latin-1 or UTF8. So Chinese and Japanese programmers are in a
disadvantage, no?




Footnotes: 
[1]   I don't care so much about RCS in that context.






^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-23 17:00     ` Uwe Brauer
@ 2016-05-23 17:31       ` Eli Zaretskii
  2016-05-23 20:37         ` Uwe Brauer
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2016-05-23 17:31 UTC (permalink / raw)
  To: Uwe Brauer; +Cc: dgutov, 23595

> From: Uwe Brauer <oub@mat.ucm.es>
> Cc: Dmitry Gutov <dgutov@yandex.ru>, oub@mat.ucm.es,
> 	23595@debbugs.gnu.org
> Date: Mon, 23 May 2016 17:00:53 +0000
> 
> I thought the problem was caused by the fact that I did not entered that
> chars, but rather copied it from some tex.stackexchange site, but I see
> that was not the reason.
> 
> What is about mercurial?[1]

No clue, sorry.  I don't use it and don't know anything about it.
The man page says "hg diff --text" might do what you want.

>    > Bottom line: users who put UTF-16 encoded files into VCS are playing
>    > with fire, and are best advised not to do that!
> 
> Right, I see, that was just 2 chars in a document which contained
> latin-1 or UTF8. So Chinese and Japanese programmers are in a
> disadvantage, no?

Why?  UTF-8 supports Chinese just fine.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-21 13:02 bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS) Uwe Brauer
  2016-05-23 11:52 ` Dmitry Gutov
@ 2016-05-23 17:40 ` Paul Eggert
  2016-05-23 18:15   ` Eli Zaretskii
  1 sibling, 1 reply; 36+ messages in thread
From: Paul Eggert @ 2016-05-23 17:40 UTC (permalink / raw)
  To: 23595; +Cc: Uwe Brauer, Dmitry Gutov

On 05/23/2016 09:52 AM, Eli Zaretskii wrote:
 > Does "git diff --text" fix this?

I tried something like the following, which as I understand it is the 
procedure recommended for putting UTF-16 files under Git control on 
GNU/Linux hosts (the basic idea is that the repository contains UTF-8 
and the working files contain UTF-16):

* Add the line 'test-chin-jap.tex filter=utf16' to .gitattributes.

* git config filter.utf16.clean 'iconv -f utf-16 -t utf-8'

* git config filter.utf16.smudge 'iconv -f utf-8 -t utf-16'

* Commit the file all over again (as this stores the UTF-8 version in 
the repository, not the UTF-16 version).

* Make a trivial edit to the file in the non-ASCII region.

When I did all all this, Emacs 24.5 works and draft Emacs 25 shows 
mojibake, so we indeed have a regression. The shell command 'git diff' 
works fine, and outputs the difference in UTF-8, but I guess draft Emacs 
25 treats the git diff output as UTF-16.






^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-23 17:40 ` Paul Eggert
@ 2016-05-23 18:15   ` Eli Zaretskii
  0 siblings, 0 replies; 36+ messages in thread
From: Eli Zaretskii @ 2016-05-23 18:15 UTC (permalink / raw)
  To: Paul Eggert; +Cc: oub, 23595, dgutov

> Cc: Uwe Brauer <oub@mat.ucm.es>, Dmitry Gutov <dgutov@yandex.ru>,
>  Eli Zaretskii <eliz@gnu.org>
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 23 May 2016 10:40:40 -0700
> 
> I tried something like the following, which as I understand it is the 
> procedure recommended for putting UTF-16 files under Git control on 
> GNU/Linux hosts (the basic idea is that the repository contains UTF-8 
> and the working files contain UTF-16):
> 
> * Add the line 'test-chin-jap.tex filter=utf16' to .gitattributes.
> 
> * git config filter.utf16.clean 'iconv -f utf-16 -t utf-8'
> 
> * git config filter.utf16.smudge 'iconv -f utf-8 -t utf-16'
> 
> * Commit the file all over again (as this stores the UTF-8 version in 
> the repository, not the UTF-16 version).
> 
> * Make a trivial edit to the file in the non-ASCII region.
> 
> When I did all all this, Emacs 24.5 works and draft Emacs 25 shows 
> mojibake, so we indeed have a regression. The shell command 'git diff' 
> works fine, and outputs the difference in UTF-8, but I guess draft Emacs 
> 25 treats the git diff output as UTF-16.

If the above is the recommended procedure for putting such files under
Git, then vc-git should bind coding-system-for-read to utf-8 whenever

  (coding-system-get buffer-file-coding-system :ascii-compatible-p)

returns nil.  Otherwise, the current binding is TRT.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-23 17:31       ` Eli Zaretskii
@ 2016-05-23 20:37         ` Uwe Brauer
  2016-05-23 21:01           ` Lars Ingebrigtsen
  2016-05-24  2:33           ` Eli Zaretskii
  0 siblings, 2 replies; 36+ messages in thread
From: Uwe Brauer @ 2016-05-23 20:37 UTC (permalink / raw)
  To: 23595

>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
   >> Right, I see, that was just 2 chars in a document which contained
   >> latin-1 or UTF8. So Chinese and Japanese programmers are in a
   >> disadvantage, no?

   > Why?  UTF-8 supports Chinese just fine.

Now I am confused. In my poor understanding I thought UTF-16 is needed
for Chinese and Japanese. That seems not to be the case?!

So the problem I reported was caused by the fact that I used UTF-16
instead of UTF-8?









^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-23 20:37         ` Uwe Brauer
@ 2016-05-23 21:01           ` Lars Ingebrigtsen
  2016-05-24  2:33           ` Eli Zaretskii
  1 sibling, 0 replies; 36+ messages in thread
From: Lars Ingebrigtsen @ 2016-05-23 21:01 UTC (permalink / raw)
  To: 23595

Uwe Brauer <oub@mat.ucm.es> writes:

>    > Why?  UTF-8 supports Chinese just fine.
>
> Now I am confused. In my poor understanding I thought UTF-16 is needed
> for Chinese and Japanese. That seems not to be the case?!

No, UTF-8 and UTF-16 are just two different encodings of the same
charset, which is Unicode.  

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-23 16:48   ` Eli Zaretskii
  2016-05-23 17:00     ` Uwe Brauer
@ 2016-05-23 21:02     ` Dmitry Gutov
  2016-05-23 22:16       ` Paul Eggert
  2016-05-24  2:36       ` Eli Zaretskii
  1 sibling, 2 replies; 36+ messages in thread
From: Dmitry Gutov @ 2016-05-23 21:02 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: oub, Paul Eggert, 23595

On 05/23/2016 07:48 PM, Eli Zaretskii wrote:

>>> The resulting diff contains either rubbish or fails to run.
>>> Files attached.
>
> I don't see any rubbish in the Git output.

Might that have to do something with your OS? I see the mojibake like 
others.

> Setting coding-system-for-read is correct, because the important use
> case is when the diffs are actually output.  The problem is that
> UTF-16 is not ASCII-compatible, and so text output by Git itself will
> be mishandled.  Another problem is that Git doesn't show the diffs at
> all.

Apparently so.

>> Which is weird, considering both vc-diff-internal and vc-coding-system-for-diff have both been virtually untouched for the last couple of years.
>
> Not sure what do you see as weird.

That we have a regression while the relevant functions didn't change. 
Something probably changed on the lower level, and we might be wise to 
figure out what (unless somebody already knows, and just didn't point 
that out because it's not a bug).

>> But even if we figure out why happens, you (Uwe) probably want Git, Hg, etc, to treat this file as text, and not binary. Only then you'll be able to get meaningful diffs. I don't have a specific advice on that.
>
> Why can't we invoke "git diff --text"?  That should fix the second
> problem, I think.

It does not. It forces Git to diff the file as text, but neither the 
current code, nor the patch at the end make the displayed file contents 
to be correctly decoded.

I haven't tried Paul's solution for this myself, but it seems to be the 
way to go.

> As for the first problem, we should probably refrain from binding
> coding-system-for-read to a CODING-SYSTEM for which
>
>    (coding-system-get CODING-SYSTEM :ascii-compatible-p)
>
> returns nil.  We should instead bind it to no-conversion and decode
> the file data parts by hand, skipping the parts that Git itself
> outputs (yes, this is messy).  Patches to that effect are welcome.

Not sure what's the best place to do it, but the patch below gives me 
24.5's behavior (correctly decoding the short "Binary files ... differ" 
output). Could someone try it together with Paul's solution?

diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el
index 25b41e3..b62b68d 100644
--- a/lisp/vc/vc.el
+++ b/lisp/vc/vc.el
@@ -1696,6 +1696,8 @@ vc-diff-internal
  	(setq coding-system-for-read
  	      (coding-system-change-eol-conversion coding-system-for-read
  						   'dos)))
+    (unless (coding-system-get coding-system-for-read :ascii-compatible-p)
+      (setq coding-system-for-read nil))
      (vc-setup-buffer buffer)
      (message "%s" (car messages))
      ;; Many backends don't handle well the case of a file that has been






^ permalink raw reply related	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-23 21:02     ` Dmitry Gutov
@ 2016-05-23 22:16       ` Paul Eggert
  2016-05-23 22:28         ` Dmitry Gutov
  2016-05-24  2:40         ` Eli Zaretskii
  2016-05-24  2:36       ` Eli Zaretskii
  1 sibling, 2 replies; 36+ messages in thread
From: Paul Eggert @ 2016-05-23 22:16 UTC (permalink / raw)
  To: Dmitry Gutov, Eli Zaretskii; +Cc: oub, 23595

On 05/23/2016 02:02 PM, Dmitry Gutov wrote:
> Not sure what's the best place to do it, but the patch below gives me 
> 24.5's behavior (correctly decoding the short "Binary files ... 
> differ" output). Could someone try it together with Paul's solution?
>

It worked for me in the Bug#23595 test case, with Git configured with 
utf16<->utf8 filters as I described. However, it reintroduces a bug when 
the version-controlled uses ISO-2022-JP. If I make a trivial change to 
etc/HELLO, for example, the patch can cause vc-diff to display mojibake, 
as the output of "git diff" uses ISO0-2022-JP but vc-diff decodes it as 
UTF-8. Although this is the same mojibake that Emacs 24.5 generates so 
the behavior is not a regression from 24.5, it is a regression from 
current emacs-25.

We are on thin ice here no matter what. One idea to improve on the 
current emacs-25 behavior is to test whether a simple ASCII message like 
"Binary files differ" encodes as itself using the file's coding system, 
and to use the file's coding system if it does and locale-coding-system 
if it doesn't.

> diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el
> index 25b41e3..b62b68d 100644
> --- a/lisp/vc/vc.el
> +++ b/lisp/vc/vc.el
> @@ -1696,6 +1696,8 @@ vc-diff-internal
>      (setq coding-system-for-read
>            (coding-system-change-eol-conversion coding-system-for-read
>                             'dos)))
> +    (unless (coding-system-get coding-system-for-read 
> :ascii-compatible-p)
> +      (setq coding-system-for-read nil)) 







^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-23 22:16       ` Paul Eggert
@ 2016-05-23 22:28         ` Dmitry Gutov
  2016-05-24  0:07           ` Paul Eggert
  2016-05-24  2:40         ` Eli Zaretskii
  1 sibling, 1 reply; 36+ messages in thread
From: Dmitry Gutov @ 2016-05-23 22:28 UTC (permalink / raw)
  To: Paul Eggert, Eli Zaretskii; +Cc: oub, 23595

On 05/24/2016 01:16 AM, Paul Eggert wrote:

> It worked for me in the Bug#23595 test case, with Git configured with
> utf16<->utf8 filters as I described. However, it reintroduces a bug when
> the version-controlled uses ISO-2022-JP.

Does it have a bug report? Can we have a test case?

> If I make a trivial change to
> etc/HELLO, for example, the patch can cause vc-diff to display mojibake,
> as the output of "git diff" uses ISO0-2022-JP but vc-diff decodes it as
> UTF-8. Although this is the same mojibake that Emacs 24.5 generates so
> the behavior is not a regression from 24.5, it is a regression from
> current emacs-25.

That's too bad.

> We are on thin ice here no matter what. One idea to improve on the
> current emacs-25 behavior is to test whether a simple ASCII message like
> "Binary files differ" encodes as itself using the file's coding system,
> and to use the file's coding system if it does and locale-coding-system
> if it doesn't.

How would we do that? We're currently picking conding-system-for-read 
well before the first byte of the output is generated.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-23 22:28         ` Dmitry Gutov
@ 2016-05-24  0:07           ` Paul Eggert
  2016-05-24  9:47             ` Dmitry Gutov
  0 siblings, 1 reply; 36+ messages in thread
From: Paul Eggert @ 2016-05-24  0:07 UTC (permalink / raw)
  To: Dmitry Gutov, Eli Zaretskii; +Cc: oub, 23595

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

On 05/23/2016 03:28 PM, Dmitry Gutov wrote:
> Does it have a bug report? Can we have a test case?

Not as far as I know. I was hoping we wouldn't have to write a bug 
report now, as emacs-25 does not have that bug now. I suppose someone 
with more free time could write a test case....

>
>> One idea to improve on the
>> current emacs-25 behavior is to test whether a simple ASCII message like
>> "Binary files differ" encodes as itself using the file's coding system,
>> and to use the file's coding system if it does and locale-coding-system
>> if it doesn't.
>
> How would we do that? We're currently picking conding-system-for-read 
> well before the first byte of the output is generated.

Emacs can decide the coding system before git diff generates any output, 
by applying decode-coding-string to a canary string sample. The attached 
patch should work; please give it a try.


[-- Attachment #2: 0001-Fix-vc-diff-problems-with-UTF-16.patch --]
[-- Type: application/x-patch, Size: 2483 bytes --]

^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-23 20:37         ` Uwe Brauer
  2016-05-23 21:01           ` Lars Ingebrigtsen
@ 2016-05-24  2:33           ` Eli Zaretskii
  1 sibling, 0 replies; 36+ messages in thread
From: Eli Zaretskii @ 2016-05-24  2:33 UTC (permalink / raw)
  To: Uwe Brauer; +Cc: 23595

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Mon, 23 May 2016 20:37:29 +0000
> 
> >>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
>    >> Right, I see, that was just 2 chars in a document which contained
>    >> latin-1 or UTF8. So Chinese and Japanese programmers are in a
>    >> disadvantage, no?
> 
>    > Why?  UTF-8 supports Chinese just fine.
> 
> Now I am confused. In my poor understanding I thought UTF-16 is needed
> for Chinese and Japanese. That seems not to be the case?!

No, it's not the case.  UTF-8 and UTF-16 both support the same space
of Unicode codepoints.

> So the problem I reported was caused by the fact that I used UTF-16
> instead of UTF-8?

Yes!





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-23 21:02     ` Dmitry Gutov
  2016-05-23 22:16       ` Paul Eggert
@ 2016-05-24  2:36       ` Eli Zaretskii
  2016-05-24  9:35         ` Dmitry Gutov
  2016-05-25  6:19         ` Paul Eggert
  1 sibling, 2 replies; 36+ messages in thread
From: Eli Zaretskii @ 2016-05-24  2:36 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: oub, eggert, 23595

> Cc: oub@mat.ucm.es, 23595@debbugs.gnu.org, Paul Eggert <eggert@cs.ucla.edu>
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 24 May 2016 00:02:36 +0300
> 
> On 05/23/2016 07:48 PM, Eli Zaretskii wrote:
> 
> >>> The resulting diff contains either rubbish or fails to run.
> >>> Files attached.
> >
> > I don't see any rubbish in the Git output.
> 
> Might that have to do something with your OS? I see the mojibake like 
> others.

I was talking about the attachment Uwe provided, so this has nothing
to do with my OS.

> > As for the first problem, we should probably refrain from binding
> > coding-system-for-read to a CODING-SYSTEM for which
> >
> >    (coding-system-get CODING-SYSTEM :ascii-compatible-p)
> >
> > returns nil.  We should instead bind it to no-conversion and decode
> > the file data parts by hand, skipping the parts that Git itself
> > outputs (yes, this is messy).  Patches to that effect are welcome.
> 
> Not sure what's the best place to do it, but the patch below gives me 
> 24.5's behavior (correctly decoding the short "Binary files ... differ" 
> output). Could someone try it together with Paul's solution?

Paul's solution is outside of Emacs's realm.  What Emacs should do is
bind coding-system-for-read to utf-8 in this case (not leave it
unbound as in your patch), under the assumption that the user used the
procedure outlined by Paul.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-23 22:16       ` Paul Eggert
  2016-05-23 22:28         ` Dmitry Gutov
@ 2016-05-24  2:40         ` Eli Zaretskii
  2016-05-24 15:36           ` Eli Zaretskii
  1 sibling, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2016-05-24  2:40 UTC (permalink / raw)
  To: Paul Eggert; +Cc: oub, dgutov, 23595

> Cc: oub@mat.ucm.es, 23595@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 23 May 2016 15:16:56 -0700
> 
> On 05/23/2016 02:02 PM, Dmitry Gutov wrote:
> > Not sure what's the best place to do it, but the patch below gives me 
> > 24.5's behavior (correctly decoding the short "Binary files ... 
> > differ" output). Could someone try it together with Paul's solution?
> >
> 
> It worked for me in the Bug#23595 test case, with Git configured with 
> utf16<->utf8 filters as I described. However, it reintroduces a bug when 
> the version-controlled uses ISO-2022-JP. If I make a trivial change to 
> etc/HELLO, for example, the patch can cause vc-diff to display mojibake, 
> as the output of "git diff" uses ISO0-2022-JP but vc-diff decodes it as 
> UTF-8. Although this is the same mojibake that Emacs 24.5 generates so 
> the behavior is not a regression from 24.5, it is a regression from 
> current emacs-25.

For some reason I don't quite understand, iso-2022-jp fails the
ascii-compatible-p test.  We could make an exception for the iso-202
family in this case.  Then the bug would not creep back in.

> We are on thin ice here no matter what. One idea to improve on the 
> current emacs-25 behavior is to test whether a simple ASCII message like 
> "Binary files differ" encodes as itself using the file's coding system, 
> and to use the file's coding system if it does and locale-coding-system 
> if it doesn't.

Yes, but we know in advance which coding-systems will be unable to do
that, so testing this at run time sounds like waste of cycles.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-24  2:36       ` Eli Zaretskii
@ 2016-05-24  9:35         ` Dmitry Gutov
  2016-05-24 15:40           ` Eli Zaretskii
  2016-05-25  6:19           ` Paul Eggert
  2016-05-25  6:19         ` Paul Eggert
  1 sibling, 2 replies; 36+ messages in thread
From: Dmitry Gutov @ 2016-05-24  9:35 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: oub, eggert, 23595

On 05/24/2016 05:36 AM, Eli Zaretskii wrote:

>> Might that have to do something with your OS? I see the mojibake like
>> others.
>
> I was talking about the attachment Uwe provided, so this has nothing
> to do with my OS.

Hm, yes, that's odd. I do see the same problem with Git as Use reported 
with Hg and RCS, on my machine.

>What Emacs should do is
> bind coding-system-for-read to utf-8 in this case (not leave it
> unbound as in your patch), under the assumption that the user used the
> procedure outlined by Paul.

Should `utf-8' altogether replace `undecided' in 
vc-coding-system-for-diff? Then the use of buffer-file-coding-system 
could be predicated on its being compatible with ascii.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-24  0:07           ` Paul Eggert
@ 2016-05-24  9:47             ` Dmitry Gutov
  2016-05-25  6:51               ` Paul Eggert
  0 siblings, 1 reply; 36+ messages in thread
From: Dmitry Gutov @ 2016-05-24  9:47 UTC (permalink / raw)
  To: Paul Eggert, Eli Zaretskii; +Cc: oub, 23595

On 05/24/2016 03:07 AM, Paul Eggert wrote:

> Not as far as I know. I was hoping we wouldn't have to write a bug
> report now, as emacs-25 does not have that bug now. I suppose someone
> with more free time could write a test case....

OK, maybe it's not too important.

> Emacs can decide the coding system before git diff generates any output,
> by applying decode-coding-string to a canary string sample. The attached
> patch should work; please give it a try.

It works at least as well as my patch, or that's what I could test.

But:

- Shouldn't that change be in vc-coding-system-for-diff?
- It seems to try to fix a separate issue (whether all files use the 
same coding system).
- Like Eli pointed out, (coding-system-get coding-system-for-read 
:ascii-compatible-p) should work about as well. Why doesn't it?

As an aside, how did you manage to create a patch that's using tabs for 
indentation, with indent-tabs-mode bound to nil in .dir-locals.el? 
That's troubling.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-24  2:40         ` Eli Zaretskii
@ 2016-05-24 15:36           ` Eli Zaretskii
  0 siblings, 0 replies; 36+ messages in thread
From: Eli Zaretskii @ 2016-05-24 15:36 UTC (permalink / raw)
  To: eggert; +Cc: oub, dgutov, 23595

> Date: Tue, 24 May 2016 05:40:44 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: oub@mat.ucm.es, dgutov@yandex.ru, 23595@debbugs.gnu.org
> 
> > It worked for me in the Bug#23595 test case, with Git configured with 
> > utf16<->utf8 filters as I described. However, it reintroduces a bug when 
> > the version-controlled uses ISO-2022-JP. If I make a trivial change to 
> > etc/HELLO, for example, the patch can cause vc-diff to display mojibake, 
> > as the output of "git diff" uses ISO0-2022-JP but vc-diff decodes it as 
> > UTF-8. Although this is the same mojibake that Emacs 24.5 generates so 
> > the behavior is not a regression from 24.5, it is a regression from 
> > current emacs-25.
> 
> For some reason I don't quite understand, iso-2022-jp fails the
> ascii-compatible-p test.

OK, I understand that now.  ascii-compatible-p is not the right test,
the right one is mime-text-unsuitable-p; and the test should be
reversed, i.e. this:

  (coding-system-get CODING-SYSTEM :mime-text-unsuitable-p)

should return nil for CODING-SYSTEM to be usable.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-24  9:35         ` Dmitry Gutov
@ 2016-05-24 15:40           ` Eli Zaretskii
  2016-05-25  0:09             ` Dmitry Gutov
  2016-05-25  6:19           ` Paul Eggert
  1 sibling, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2016-05-24 15:40 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: oub, eggert, 23595

> Cc: oub@mat.ucm.es, eggert@cs.ucla.edu, 23595@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 24 May 2016 12:35:40 +0300
> 
> >What Emacs should do is
> > bind coding-system-for-read to utf-8 in this case (not leave it
> > unbound as in your patch), under the assumption that the user used the
> > procedure outlined by Paul.
> 
> Should `utf-8' altogether replace `undecided' in 
> vc-coding-system-for-diff? Then the use of buffer-file-coding-system 
> could be predicated on its being compatible with ascii.

Not sure it's a good idea: the solution we found is only known to work
with Git, whereas vc-coding-system-for-diff is for any VCS.  Mercurial
seems to have a similar encode/decode filter feature, but I'm not sure
using it means the diff results will be in UTF-8.

I think we should have a git-specific function that implements the
above idea, and then we should use it in vc-coding-system-for-diff.
(I prefer a separate function because my gut feeling is that we will
need something like that in other Git operations, when UTF-16 files
are involved.)

WDYT?





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-24 15:40           ` Eli Zaretskii
@ 2016-05-25  0:09             ` Dmitry Gutov
  2016-05-25 16:22               ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Dmitry Gutov @ 2016-05-25  0:09 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: oub, eggert, 23595

On 05/24/2016 06:40 PM, Eli Zaretskii wrote:

> Not sure it's a good idea: the solution we found is only known to work
> with Git, whereas vc-coding-system-for-diff is for any VCS.  Mercurial
> seems to have a similar encode/decode filter feature, but I'm not sure
> using it means the diff results will be in UTF-8.

Do we actually know that we'll need this behavior to be VCS-specific?

So far, we've seem some pretty similar results with vc-diff using Git, 
Hg and RCS.

> I think we should have a git-specific function that implements the
> above idea, and then we should use it in vc-coding-system-for-diff.

Git-specific or backend-specific?

I suppose we could add some new encoding-handling logic at the beginning 
of vc-git-diff instead.

> (I prefer a separate function because my gut feeling is that we will
> need something like that in other Git operations, when UTF-16 files
> are involved.)

We can always extract a new function when it's needed, though.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-24  2:36       ` Eli Zaretskii
  2016-05-24  9:35         ` Dmitry Gutov
@ 2016-05-25  6:19         ` Paul Eggert
  2016-05-25 16:26           ` Eli Zaretskii
  1 sibling, 1 reply; 36+ messages in thread
From: Paul Eggert @ 2016-05-25  6:19 UTC (permalink / raw)
  To: Eli Zaretskii, Dmitry Gutov; +Cc: oub, 23595

Eli Zaretskii wrote:
> What Emacs should do is
> bind coding-system-for-read to utf-8 in this case (not leave it
> unbound as in your patch), under the assumption that the user used the
> procedure outlined by Paul.

I don't see how this would work for files like etc/HELLO, which use iso-2022-jp. 
But perhaps the above comment is obsolete now.

> ascii-compatible-p is not the right test,
> the right one is mime-text-unsuitable-p; and the test should be
> reversed, i.e. this:
>
>   (coding-system-get CODING-SYSTEM :mime-text-unsuitable-p)
>
> should return nil for CODING-SYSTEM to be usable.

Better, but this wouldn't work for coding systems like ebcdic-us, which are so 
incompatible with ASCII that messages like "Binary files differ" would turn into 
gibberish.

> testing this at run time sounds like waste of cycles.

Not so many cycles that anyone will really care, I expect.

We could establish a new coding system property for "close enough to ASCII that 
most people won't mind". That would be a more-intrusive change, though. For 
emacs-25 I thought it'd be better to have something that is more self-contained.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-24  9:35         ` Dmitry Gutov
  2016-05-24 15:40           ` Eli Zaretskii
@ 2016-05-25  6:19           ` Paul Eggert
  2016-05-25 16:27             ` Eli Zaretskii
  1 sibling, 1 reply; 36+ messages in thread
From: Paul Eggert @ 2016-05-25  6:19 UTC (permalink / raw)
  To: Dmitry Gutov, Eli Zaretskii; +Cc: oub, 23595

Dmitry Gutov wrote:
> Should `utf-8' altogether replace `undecided' in vc-coding-system-for-diff? Then
> the use of buffer-file-coding-system could be predicated on its being compatible
> with ascii.

That might be going too far.

We want buffer-file-coding-system to be compatible-enough with ASCII for the 
case where diff output might contain ASCII metadata or non-ASCII file contents 
or both. In this case, if buffer-file-coding-system is greatly incompatible with 
ASCII, then ASCII will often be wrong (because the file data in the diff output 
will be mostly UTF-16, say), and buffer-file-coding-system will often be wrong 
too (because the non-file data will be mostly ASCII). So when 
buffer-file-coding-system is greatly incompatible with ASCII, we can't use 
either buffer-file-coding-system or UTF-8; they're both wrong too often.

The way it's *supposed* to work in a POSIX system, is that diff is supposed to 
be applied to a file that is valid text according to the current locale's 
encoding, and diff is supposed to generate both metadata and data that uses the 
current locale's encoding. I expect that we should fall back on this approach 
when buffer-file-coding-system is greatly incompatible with ASCII. This will 
better handle unusual cases such as a system operating in an EBCDIC locale 
(which can happen on IBM mainframes, though admittedly Emacs is not likely to 
work well on such platforms). And this argues for sticking with 'undecided' 
instead of 'utf-8' here.

(In theory it's possible for a GNU/Linux system to establish a locale with 
UTF-16 encoding, so that diff's metadata and data are consistently UTF-16 for 
this example. However, I've never heard of such a thing, and couldn't find any 
evidence of one just now when I searched for it. So I don't think we need to 
worry about this now.)






^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-24  9:47             ` Dmitry Gutov
@ 2016-05-25  6:51               ` Paul Eggert
  2016-05-25 12:44                 ` Dmitry Gutov
  0 siblings, 1 reply; 36+ messages in thread
From: Paul Eggert @ 2016-05-25  6:51 UTC (permalink / raw)
  To: Dmitry Gutov, Eli Zaretskii; +Cc: oub, 23595

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

Dmitry Gutov wrote:

> - Shouldn't that change be in vc-coding-system-for-diff?
> - It seems to try to fix a separate issue (whether all files use the same coding
> system).

Yes. For emacs-25 that's probably too much, as you suggest. So we can fix the 
problem in vc-coding-system-for-diff. Revised (more-conservative) patch attached.

> - Like Eli pointed out, (coding-system-get coding-system-for-read
> :ascii-compatible-p) should work about as well. Why doesn't it?

It doesn't work for EBCDIC.

> As an aside, how did you manage to create a patch that's using tabs for
> indentation, with indent-tabs-mode bound to nil in .dir-locals.el? That's
> troubling.

I override that setting, as I find it annoying in too many cases. It's just a 
minor annoyance, but there it is.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-vc-diff-problems-with-UTF-16.patch --]
[-- Type: text/x-diff; name="0001-Fix-vc-diff-problems-with-UTF-16.patch", Size: 2411 bytes --]

From 4b608d04b5c71a580a962b014c0399d0c917d9ab Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 24 May 2016 22:28:44 -0700
Subject: [PATCH] Fix vc-diff problems with UTF-16

Problem with UTF-16 reported by Uwe Brauer (Bug#23595).
There are similar problems with EBCDIC or with other coding
systems differing greatly from ASCII.
* lisp/vc/vc.el (vc-coding-system-for-diff): Require the file's coding
system to be compatible-enough with ASCII so that messages like "Binary
files differ" are not misdecoded.
---
 lisp/vc/vc.el | 25 +++++++++++++++++++------
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el
index af875e8..0dbdcb0 100644
--- a/lisp/vc/vc.el
+++ b/lisp/vc/vc.el
@@ -1601,18 +1601,31 @@ vc-coding-system-inherit-eol
 (defun vc-coding-system-for-diff (file)
   "Return the coding system for reading diff output for FILE."
   (or coding-system-for-read
-      ;; if we already have this file open,
-      ;; use the buffer's coding system
-      (let ((buf (find-buffer-visiting file)))
-        (when buf (with-current-buffer buf
+      (let ((coding
+	     (or
+	      ;; If we already have this file open,
+	      ;; try the buffer's coding system.
+	      (let ((buf (find-buffer-visiting file)))
+		(when buf
+		  (with-current-buffer buf
 		    (if vc-coding-system-inherit-eol
 			buffer-file-coding-system
 		      ;; Don't inherit the EOL part of the coding-system,
 		      ;; because some Diff tools may choose to use
 		      ;; a different one.  bug#4451.
 		      (coding-system-base buffer-file-coding-system)))))
-      ;; otherwise, try to find one based on the file name
-      (car (find-operation-coding-system 'insert-file-contents file))
+	      ;; Otherwise, try to find one based on the file name.
+	      (car (find-operation-coding-system 'insert-file-contents
+						 file)))))
+	;; Use the files' coding system only if it is compatible
+	;; enough with ASCII.  If the files' coding system is UTF-16,
+	;; diff likely outputs something like "Binary files differ" in
+	;; ASCII, which would be misdecoded by UTF-16.
+	(when (and coding
+		   (let ((samp "Binary files differ"))
+		     (string-equal samp (decode-coding-string
+					 samp coding t))))
+	  last-coding-system-used))
       ;; and a final fallback
       'undecided))
 
-- 
2.5.5


^ permalink raw reply related	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-25  6:51               ` Paul Eggert
@ 2016-05-25 12:44                 ` Dmitry Gutov
  0 siblings, 0 replies; 36+ messages in thread
From: Dmitry Gutov @ 2016-05-25 12:44 UTC (permalink / raw)
  To: Paul Eggert, Eli Zaretskii; +Cc: oub, 23595

On 05/25/2016 09:51 AM, Paul Eggert wrote:

> Yes. For emacs-25 that's probably too much, as you suggest. So we can
> fix the problem in vc-coding-system-for-diff. Revised
> (more-conservative) patch attached.

Looks good, thanks. We should also test it with different backends, to 
see if it helps with this problem in each of them (at least to some extent).

Like Eli said, it might also cause new problems in some of them.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-25  0:09             ` Dmitry Gutov
@ 2016-05-25 16:22               ` Eli Zaretskii
  2016-05-25 23:21                 ` Dmitry Gutov
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2016-05-25 16:22 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: oub, eggert, 23595

> Cc: oub@mat.ucm.es, eggert@cs.ucla.edu, 23595@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 25 May 2016 03:09:27 +0300
> 
>     Not sure it's a good idea: the solution we found is only known to work
>     with Git, whereas vc-coding-system-for-diff is for any VCS.  Mercurial
>     seems to have a similar encode/decode filter feature, but I'm not sure
>     using it means the diff results will be in UTF-8.
> 
> Do we actually know that we'll need this behavior to be VCS-specific?

I think we can make an educated guess, see below.  My conclusion is
that this does need to be VCS-specific.

> So far, we've seem some pretty similar results with vc-diff using Git, Hg and RCS.

Not quite.  They all fail, but in different ways.  More importantly,
the solutions are most probably going to be different.

>     I think we should have a git-specific function that implements the
>     above idea, and then we should use it in vc-coding-system-for-diff.
> 
> Git-specific or backend-specific?

Backend-specific, most probably.  Except that currently we only have a
good idea about the Git backend, for which it is explicitly documented
that the output will be in UTF-8 when content filters are used.

Mercurial and Bazaar both support similar filters, but I cannot find
any documentation on what encoding will be used for the output.  For
Bazaar, there's a general statement somewhere that it defaults to the
locale's encoding (there's a config variable to change that).

SVN doesn't seem to support filters at all, so with it, the user will
have to manually set the mime-type property of the UTF-16 files as
text, and install a replacement Diff command that can produce diffs
from UTF-16 files (I believe GNU Diff cannot currently do that).
Since no canonical way exists, I don't see how we can know for sure
the encoding of the Diff output; my best guess is that it will also be
in UTF-16.  (Similar problems exist in SVN with other operations on
such files.)

For RCS and CVS, I don't see any solution at all, since AFAIK these
don't support any such features or anything similar.  These will
always treat UTF-16 files as binary, so no meaningful diffs can be
produced for them.

> I suppose we could add some new encoding-handling logic at the beginning of vc-git-diff instead.
> 
>     (I prefer a separate function because my gut feeling is that we will
>     need something like that in other Git operations, when UTF-16 files
>     are involved.)
> 
> We can always extract a new function when it's needed, though.

True, but I think if we want to support UTF-16 files, the need is
already here.  vc-diff and its derivatives are just the tip of the
iceberg, we will need similar stuff for every command that includes
both text from the versioned file(s) and some text output by the VCS
program itself.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-25  6:19         ` Paul Eggert
@ 2016-05-25 16:26           ` Eli Zaretskii
  0 siblings, 0 replies; 36+ messages in thread
From: Eli Zaretskii @ 2016-05-25 16:26 UTC (permalink / raw)
  To: Paul Eggert; +Cc: oub, dgutov, 23595

> Cc: oub@mat.ucm.es, 23595@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 24 May 2016 23:19:01 -0700
> 
>     ascii-compatible-p is not the right test,
>     the right one is mime-text-unsuitable-p; and the test should be
>     reversed, i.e. this:
> 
>       (coding-system-get CODING-SYSTEM :mime-text-unsuitable-p)
> 
>     should return nil for CODING-SYSTEM to be usable.
> 
> Better, but this wouldn't work for coding systems like ebcdic-us, which are so incompatible with ASCII that messages like "Binary files differ" would turn into gibberish. 

It's easy enough to exempt EBCDIC (and any other similar encodings).
There are only 3 of them, AFAICS.

> We could establish a new coding system property for "close enough to ASCII that most people won't mind". That would be a more-intrusive change, though. For emacs-25 I thought it'd be better to have something that is more self-contained. 

A :mime-text-unsuitable-p test augmented by a list of additional
coding-systems we find unsuitable is simple, self-contained, and safe
for emacs-25, IMO.  For master, we could add a cleaner, but more
intrusive fix.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-25  6:19           ` Paul Eggert
@ 2016-05-25 16:27             ` Eli Zaretskii
  0 siblings, 0 replies; 36+ messages in thread
From: Eli Zaretskii @ 2016-05-25 16:27 UTC (permalink / raw)
  To: Paul Eggert; +Cc: oub, dgutov, 23595

> Cc: oub@mat.ucm.es, 23595@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 24 May 2016 23:19:05 -0700
> 
>     - Like Eli pointed out, (coding-system-get coding-system-for-read
>     :ascii-compatible-p) should work about as well. Why doesn't it?
> 
> It doesn't work for EBCDIC.

It's easy enough to exempt EBCDIC (and any other similar encodings).

>     - Shouldn't that change be in vc-coding-system-for-diff?
>     - It seems to try to fix a separate issue (whether all files use the same coding
>     system).
> 
> Yes. For emacs-25 that's probably too much, as you suggest. So we can fix the problem in vc-coding-system-for-diff. Revised (more-conservative) patch attached. 

That patch relies on subtleties of comparing unibyte and multibyte
strings, so I don't like it, even if we ignore the issue of computing
something whose result is known in advance.

I still think we can come up with a simple (and safe for emacs-25)
method of identifying the problematic encodings, and leave the general
issue of having a new attribute for master.  Can we have a patch along
those lines, please?





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-25 16:22               ` Eli Zaretskii
@ 2016-05-25 23:21                 ` Dmitry Gutov
  2016-05-26 10:44                   ` Uwe Brauer
  2016-05-26 15:35                   ` Eli Zaretskii
  0 siblings, 2 replies; 36+ messages in thread
From: Dmitry Gutov @ 2016-05-25 23:21 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: oub, eggert, 23595

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

On 05/25/2016 07:22 PM, Eli Zaretskii wrote:

> I think we can make an educated guess, see below.  My conclusion is
> that this does need to be VCS-specific.
>
>> So far, we've seem some pretty similar results with vc-diff using Git, Hg and RCS.
>
> Not quite.  They all fail, but in different ways.  More importantly,
> the solutions are most probably going to be different.

OK, that makes sense.

> Backend-specific, most probably.  Except that currently we only have a
> good idea about the Git backend, for which it is explicitly documented
> that the output will be in UTF-8 when content filters are used.
>
> ...

Taking a step back, I'm not sure it's really necessary to fix this. 
Because Uwe, the only person to complain about diffing UTF-16 files so 
far, can solve it much easier by switching the file to UTF-8.

And properly fixing it, across the board, is either impossible, or at 
least pretty hard.

>> We can always extract a new function when it's needed, though.
>
> True, but I think if we want to support UTF-16 files, the need is
> already here.  vc-diff and its derivatives are just the tip of the
> iceberg, we will need similar stuff for every command that includes
> both text from the versioned file(s) and some text output by the VCS
> program itself.

Here's a patch everybody is welcome to try.

[-- Attachment #2: git-asciify.diff --]
[-- Type: text/x-patch, Size: 1201 bytes --]

diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
index f35c84d..f7bd867 100644
--- a/lisp/vc/vc-git.el
+++ b/lisp/vc/vc-git.el
@@ -1083,12 +1083,19 @@ vc-git-region-history-mode
                     (cdr font-lock-defaults))))
 
 
+(defun git--asciify-coding-system ()
+  (unless (let ((samp "Binary files differ"))
+            (string-equal samp (decode-coding-string
+                                samp coding-system-for-read t)))
+    (setq coding-system-for-read 'undecided)))
+
 (autoload 'vc-switches "vc")
 
 (defun vc-git-diff (files &optional rev1 rev2 buffer _async)
   "Get a difference report using Git between two revisions of FILES."
   (let (process-file-side-effects
         (command "diff-tree"))
+    (git--asciify-coding-system)
     (if rev2
         ;; Diffing against the empty tree.
         (unless rev1 (setq rev1 "4b825dc642cb6eb9a060e54bf8d69288fbee4904"))
@@ -1127,6 +1134,7 @@ vc-git-revision-completion-table
     table))
 
 (defun vc-git-annotate-command (file buf &optional rev)
+  (git--asciify-coding-system)
   (let ((name (file-relative-name file)))
     (apply #'vc-git-command buf 'async nil "blame" "--date=short"
 	   (append (vc-switches 'git 'annotate)

^ permalink raw reply related	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-25 23:21                 ` Dmitry Gutov
@ 2016-05-26 10:44                   ` Uwe Brauer
  2016-05-26 15:35                   ` Eli Zaretskii
  1 sibling, 0 replies; 36+ messages in thread
From: Uwe Brauer @ 2016-05-26 10:44 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: oub, eggert, 23595


   > On 05/25/2016 07:22 PM, Eli Zaretskii wrote:

   > OK, that makes sense.


   > Taking a step back, I'm not sure it's really necessary to fix this.
   > Because Uwe, the only person to complain about diffing UTF-16 files so
   > far, can solve it much easier by switching the file to UTF-8.

Correct and I already did. :-D so for me the situation is fine.

I would however suggest to add some short information, maybe in the
docstring of vc-diff, to mention the problem with UTF-16.






^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-25 23:21                 ` Dmitry Gutov
  2016-05-26 10:44                   ` Uwe Brauer
@ 2016-05-26 15:35                   ` Eli Zaretskii
  2016-06-19 19:09                     ` Dmitry Gutov
  1 sibling, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2016-05-26 15:35 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: oub, eggert, 23595

> Cc: oub@mat.ucm.es, eggert@cs.ucla.edu, 23595@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 26 May 2016 02:21:40 +0300
> 
> > Backend-specific, most probably.  Except that currently we only have a
> > good idea about the Git backend, for which it is explicitly documented
> > that the output will be in UTF-8 when content filters are used.
> >
> 
> Taking a step back, I'm not sure it's really necessary to fix this. 
> Because Uwe, the only person to complain about diffing UTF-16 files so 
> far, can solve it much easier by switching the file to UTF-8.
> 
> And properly fixing it, across the board, is either impossible, or at 
> least pretty hard.

Well, it's not too hard for Git, so I think it would be good to fix
it, at least on master.

> >> We can always extract a new function when it's needed, though.
> >
> > True, but I think if we want to support UTF-16 files, the need is
> > already here.  vc-diff and its derivatives are just the tip of the
> > iceberg, we will need similar stuff for every command that includes
> > both text from the versioned file(s) and some text output by the VCS
> > program itself.
> 
> Here's a patch everybody is welcome to try.

Thanks.  Like I said, I don't like using string-equal to compare
unencoded and encoded strings, but that aspect could be fixed by a
follow-up change.

If no one objects in a week, I suggest to push to master.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS)
  2016-05-26 15:35                   ` Eli Zaretskii
@ 2016-06-19 19:09                     ` Dmitry Gutov
  0 siblings, 0 replies; 36+ messages in thread
From: Dmitry Gutov @ 2016-06-19 19:09 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: oub, eggert, 23595-done

On 05/26/2016 06:35 PM, Eli Zaretskii wrote:

>> Here's a patch everybody is welcome to try.
>
> Thanks.  Like I said, I don't like using string-equal to compare
> unencoded and encoded strings, but that aspect could be fixed by a
> follow-up change.
>
> If no one objects in a week, I suggest to push to master.

Pushed, and closing.





^ permalink raw reply	[flat|nested] 36+ messages in thread

end of thread, other threads:[~2016-06-19 19:09 UTC | newest]

Thread overview: 36+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-05-21 13:02 bug#23595: 25.1.50; file with chinese/japanse chars, vc-diff fails (HG, Git, RCS) Uwe Brauer
2016-05-23 11:52 ` Dmitry Gutov
2016-05-23 12:41   ` Uwe Brauer
2016-05-23 13:17     ` Dmitry Gutov
2016-05-23 16:52       ` Eli Zaretskii
2016-05-23 16:51     ` Eli Zaretskii
2016-05-23 16:48   ` Eli Zaretskii
2016-05-23 17:00     ` Uwe Brauer
2016-05-23 17:31       ` Eli Zaretskii
2016-05-23 20:37         ` Uwe Brauer
2016-05-23 21:01           ` Lars Ingebrigtsen
2016-05-24  2:33           ` Eli Zaretskii
2016-05-23 21:02     ` Dmitry Gutov
2016-05-23 22:16       ` Paul Eggert
2016-05-23 22:28         ` Dmitry Gutov
2016-05-24  0:07           ` Paul Eggert
2016-05-24  9:47             ` Dmitry Gutov
2016-05-25  6:51               ` Paul Eggert
2016-05-25 12:44                 ` Dmitry Gutov
2016-05-24  2:40         ` Eli Zaretskii
2016-05-24 15:36           ` Eli Zaretskii
2016-05-24  2:36       ` Eli Zaretskii
2016-05-24  9:35         ` Dmitry Gutov
2016-05-24 15:40           ` Eli Zaretskii
2016-05-25  0:09             ` Dmitry Gutov
2016-05-25 16:22               ` Eli Zaretskii
2016-05-25 23:21                 ` Dmitry Gutov
2016-05-26 10:44                   ` Uwe Brauer
2016-05-26 15:35                   ` Eli Zaretskii
2016-06-19 19:09                     ` Dmitry Gutov
2016-05-25  6:19           ` Paul Eggert
2016-05-25 16:27             ` Eli Zaretskii
2016-05-25  6:19         ` Paul Eggert
2016-05-25 16:26           ` Eli Zaretskii
2016-05-23 17:40 ` Paul Eggert
2016-05-23 18:15   ` Eli Zaretskii

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).