[darcs-users] Re: Can I disable \xx quoting in record --interactive?

[David Roundy]

On Tue, Mar 22, 2005 at 07:10:31PM +0100, Tommy Pettersson wrote:
> On Mon, Mar 21, 2005 at 01:16:01PM -0800, Junio C Hamano wrote:
> > >>>>> "TP" == Tommy Pettersson <ptp at lysator.liu.se> writes:
> > TP> But still, it would be good if we could escape some control
> > TP> characters even in raw mode, such as back space and especially
> > TP> escape.
> > 
> > Not really.  ISO 2022 based encodings use \033 sequence for
> > switching character sets which you should not munge if you want
> > to keep them human readable.
> 
> Encodings which use \033 sequences will always be vulnerable to spoofs,
> unless darcs knows to separate some \033 sequence from others.  Encodings
> which switch between character sets will also be problematic for darcs
> unless it knows how to track what character set is active when it outputs
> single lines from a larger block of text.  The latter can not be fixed by
> just turning of escaping.
> 
> That's why I (in the long run) want to move the encoding part out of
> darcs.  There was a discussion about how to handle different line endings
> in darcs, and one suggestion (that I think got fairly accepted) was to
> (optionally) convert to and from a given type of EOL whenever darcs reads
> and writes the working files.  If darcs was made UTF8 aware the same
> method could be used to convert (with an external tool like iconv) from a
> local encoding to UTF8, used internally in darcs, and back to local
> encoding again when writing.  The conversions would need to affect all
> input and output, both to files and to the terminal.  If it was
> implemented as a general filter it could probably do other interesting
> things as well.

Yes, this does seem like a solution.  On the other hand, it's also a pretty
ugly hack, and will cost in terms of performance, since we'd have to
perform the conversion every time we run whatsnew, record, or whatever.

But on the whole, a local conversion for the working directory seems like
the only way to go for this sort of issue, and using the same trick for
dealing with encodings does sound like a good idea.  With care, one might
also be able to use the same trick to deal with filename encodings.  There
was a Russian a while back who wanted to be able to deal with filenames
that had different encodings on different computers.

> It however requires that all files in a repo have the same encoding (and
> type of EOL).  Supporting different encodings in different files requires
> more work.

Indeed, I don't think we want to go there.

> > I am inclined to say that darcs should not be reinventing $PAGER
> > anyway.  The simplest would be to just pipe the patch in the raw form
> > to $PAGER and have $PAGER worry about it.  Or at least make such an
> > option (keeping the current \xx quoting, with your recent "\r\n" fix,
> > as the default).  How does that sound?

Sending stuff to $PAGER isn't a complete solution--we may not want to send
two lines of text to the pager--some pagers let their contents disappear
when they exit, so the user would have to hit 'q' to exit the pager, and
then remember what it showed them when deciding what to tell darcs...

On the other hand, it is *definitely* a good idea to add $PAGER support,
and if we did so (and added a 'p' option to view a patch within the pager)
it might at least alleviate the problem.

> Something *is* definitely needed so people can use darcs with their local
> encodings.  I have proposed a way to gradually decrease the amount of
> escaping, all the way to no escaping at all.  The problem with this
> proposal, as I see it, is that it requires too much knowledge from the
> users.  It is easy to see that things starts working when you turn off
> escaping, but that doesn't make random user aware of the risks.

Have you sent this patch? I'm still catching up on my email from last
week... I agree that extending the DARCS_TRUST_ISPRINT scheme sounds like a
good idea for now.
-- 
David Roundy
http://www.darcs.net