[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33567: Syntactic fontification of diff hunks
From: |
Juri Linkov |
Subject: |
bug#33567: Syntactic fontification of diff hunks |
Date: |
Wed, 05 Dec 2018 01:16:48 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) |
>> > vc-find-revision disables encoding/decoding because it wants to
>> > create an identical copy of the checked-out file, and doesn't want to
>> > be tripped by encoding/decoding issues. But in your case you don't
>> > write the buffer to a file, so why do you need to bind
>> > coding-system-for-read at all? I say leave it unbound, and let Emacs
>> > do its job decoding the text as usual. Does that not work?
>>
>> I tried to remove coding-system-for-read binding from
>> vc-find-revision-no-save, but it still fails to get the buffer
>> in the right encoding.
>
> What is "the right encoding",
By the right encoding I meant the same encoding that is detected
when write-region saves the file, e.g. when using the macro
with-temp-file in vc-find-revision-save. I don't know how
write-region detects the encoding for the saved file, but we need
the same encoding for the buffer that is not saved to the file
in vc-find-revision-no-save.
> and what did Emacs think the encoding was, when you didn't bind
> coding-system-for-read? These details are necessary to understand
> what exactly happens there and how to solve it.
vc-git-find-revision binds coding-system-for-read to `binary'.
>> Then I discovered that vc-git-find-revision and also some other VC
>> backend API implementations of find-revision bind
>> coding-system-for-read too. It seems that removing
>> coding-system-for-read from vc-git-find-revision will cause a lot of
>> breakage.
>
> How do you know vc-git-find-revision doesn't have a subtle bug as
> well, e.g. when file names in the repository are encoded in some
> non-trivial, non-UTF-8 encoding?
This is why vc-git-find-revision does nothing with its output
when it binds coding-system-for-read to `binary',
and doesn't try to encode/decode the git output.
> And anyway, we are not talking about changing vc-git-find-revision or
> affecting it, we are talking about your vc-find-revision-no-save,
> which does a different job. For the latter, I'd prefer not to decode
> by hand, as that might have subtle issues and will require much more
> testing in all kinds of environments and OSes.
vc-git-find-revision returns the output undecoded. I don't know
other way to decode it to the default coding other than recode-region.
> I prefer to rely on the usual decoding machinery, which we know
> works well.
Maybe I missed a separate function that can use the decoding machinery
like is used in write-region, but without writing a buffer to the file?
- bug#33567: Syntactic fontification of diff hunks, Juri Linkov, 2018/12/01
- bug#33567: Syntactic fontification of diff hunks, Eli Zaretskii, 2018/12/02
- bug#33567: Syntactic fontification of diff hunks, Juri Linkov, 2018/12/02
- bug#33567: Syntactic fontification of diff hunks, Eli Zaretskii, 2018/12/03
- bug#33567: Syntactic fontification of diff hunks, Juri Linkov, 2018/12/03
- bug#33567: Syntactic fontification of diff hunks, Eli Zaretskii, 2018/12/04
- bug#33567: Syntactic fontification of diff hunks,
Juri Linkov <=
- bug#33567: Syntactic fontification of diff hunks, Eli Zaretskii, 2018/12/05
- bug#33567: Syntactic fontification of diff hunks, Juri Linkov, 2018/12/05
- bug#33567: Syntactic fontification of diff hunks, Eli Zaretskii, 2018/12/06
- bug#33567: Syntactic fontification of diff hunks, Juri Linkov, 2018/12/10
- bug#33567: Syntactic fontification of diff hunks, Eli Zaretskii, 2018/12/11
- bug#33567: Syntactic fontification of diff hunks, Juri Linkov, 2018/12/11
- bug#33567: Syntactic fontification of diff hunks, Eli Zaretskii, 2018/12/12
- bug#33567: Syntactic fontification of diff hunks, Juri Linkov, 2018/12/03
- bug#33567: Syntactic fontification of diff hunks, Eli Zaretskii, 2018/12/04
- bug#33567: Syntactic fontification of diff hunks, Juri Linkov, 2018/12/04