[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii c
From: |
Eli Zaretskii |
Subject: |
bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename |
Date: |
Thu, 07 Feb 2019 17:50:30 +0200 |
Stefan, Dmitry, can I have your attention please?
I think there's a real mess regarding encoding and decoding stuff in
vc-find-revision and its backend implementations. For some reason,
several backend implementations bind both coding-system-for-read and
coding-system-for-write to no-conversion when they invoke the VCS to
produce a file at a certain revision. Here's an example from
vc-git.el:
(defun vc-git-find-revision (file rev buffer)
(let* (process-file-side-effects
(coding-system-for-read 'binary)
(coding-system-for-write 'binary)
(fullname
(let ((fn (vc-git--run-command-string
file "ls-files" "-z" "--full-name" "--")))
;; ls-files does not return anything when looking for a
;; revision of a file that has been renamed or removed.
(if (string= fn "")
(file-relative-name file (vc-git-root default-directory))
(substring fn 0 -1)))))
(vc-git-command
buffer 0
nil
"cat-file" "blob" (concat (if rev rev "HEAD") ":" fullname))))
Any idea why it insists on disabling code-conversions?
More generally, the find-revision method is documented as
Fetch revision REV of file FILE and put it into BUFFER.
There's nothing here that hints that the resulting buffer will not
look like any visited file, i.e. after decoding. Am I missing
something?
In addition to producing undecoded buffer, these bindings have the
adverse effect of forcing Emacs not to encode command-line arguments
we pass to the VCS, which is the immediate cause for the current bug.
It is my impression that one of the backends did these bindings for
some reason, and then others simply copy-pasted from it.
I'd like to fix this mess, if possible.
Thanks in advance for any insights.
- bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename, Vincent Belaïche, 2019/02/06
- bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename, Eli Zaretskii, 2019/02/07
- bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename,
Eli Zaretskii <=
- bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename, Stefan Monnier, 2019/02/08
- bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename, Eli Zaretskii, 2019/02/08
- bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename, Stefan Monnier, 2019/02/08
- bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename, Eli Zaretskii, 2019/02/08
- bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename, Stefan Monnier, 2019/02/08
- bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename, Eli Zaretskii, 2019/02/09
- bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename, Stefan Monnier, 2019/02/09
- bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename, Eli Zaretskii, 2019/02/09
- bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename, Stefan Monnier, 2019/02/09
- bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename, Vincent Belaïche, 2019/02/11