[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: package.el encoding problem

From: Eli Zaretskii
Subject: Re: package.el encoding problem
Date: Sat, 25 May 2019 16:47:06 +0300

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Sat, 25 May 2019 08:15:52 -0400
> >> > Can you enable "Options => Enter Debugger on Quit", then reproduce the
> >> > problem then hit C-g when you get the prompt?
> >> > [ Or do `M-: (debug)` when you get the prompt.  ]
> >> Don't bother I managed to reproduce it after all.  It should fixed, thanks,
> > Thanks, but I don't think I understand the fix.
> As you can see in the fix's assertion, the data we receive is
> a unibyte string and we need to save it into a file.

Yes, which is why I said I didn't understand the fix.  Multibyte
buffers can handle raw bytes without any problem.  Or at least I
thought they did.

> We used to put it into a multibyte buffer, which then causes the save
> the be all confused because the bytes 128-255 it contains aren't part of
> any coding-system.

I don't see how that matters.  Raw bytes should be converted back to
their original unibyte form when saving, no matter what coding-system
is used.

Could you perhaps show a recipe for the problem?  I'd like to look
into what happens there.

> It is definitely *possible* to use multibyte buffers even in cases where
> we only manipulate bytes, but it is undesirable.

I'm probably missing something, because I don't see would that be
undesirable.  Hopefully, a reproducible recipe will show me the light.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]