[PATCH 12 of 20] hgweb, paper: add shortlogajax template and use it

[Alexander Plavin]

15.08.2013, 11:45, "Martin Geisler" <martin at geisler.net>:
> Alexander Plavin <alexander at plav.in> writes:
>
>>  15.08.2013, 00:32, "Matt Mackall" <mpm at selenic.com>:
>>>  On Tue, 2013-08-13 at 23:24 -0500, Kevin Bullock wrote:
>>>>  On 13 Aug 2013, at 3:44 AM, Alexander Plavin wrote:
>>>>>  13.08.2013, 12:30, "Martin Geisler" <martin at geisler.net>:
>>>>>>  Another thought that occured to me when I read the discussion
>>>>>>  about writing an XML style: have you considered writing a JSON
>>>>>>  style instead? That might be even more useful for JavaScript code.
>>>>>  In this application (I mean infinite scrolling) json style doesn't
>>>>>  give any differences/benefits to xml one, as we would have to
>>>>>  render the templates in JS anyway. The only difference for future
>>>>>  uses in javascript is using xfr.responsexml vs
>>>>>  json.parse(xfr.responsetext). So, this variants are about
>>>>>  equivalent and one of them just has to be chosen.   However, I
>>>>>  don't know what will be best here, and would like to hear more
>>>>>  opinions on this.
>>>>  I'd lean towards JSON as well. There are solid, widely-available
>>>>  parsers for both, but JSON is generally more compact, and more
>>>>  widely used by newer client-side libraries.
>>>  Note that both JSON and XML have a serious problem that will need to
>>>  be addressed before we can use them: can't pass arbitrary character
>>>  sets.
>>  What exactly can't we pass there? According to the json rfc, "All
>>  Unicode characters may be placed within the quotation marks except for
>>  the characters that must be escaped: quotation mark, reverse solidus,
>>  and the control characters (U+0000 through +001F).". I found it at
>>  http://www.ietf.org/rfc/rfc4627.txt (2.5).
>
> We don't know the encoding of things like file names and file content.
> Hgweb will just dump the raw bytestrings to the output and unless the
> encoding matches HGENCODING, filenames will look funny in the browser.
>
> Try it by setting HGENCODING to something like ascii, latin-1, or utf-8
> and run hg serve on a repo with non-ASCII characters.
>
> It is only meta data like commit messages and usernames that we try to
> decode and store as UTF-8 internally. The encoding.fromlocal function
> does this. The encoding.tolocal convertes the other way, from internal
> UTF-8 to the local encoding.
>
> Give that encoding.fromlocal always return a UTF-8 string (or raises an
> exception), I believe we can safely use JSON for the strings that are in
> the "local" encoding.
>
> Looking in changelog.read shows that user and desc are converted to
> local encoding upon read. Looking in context.branch shows that the
> branch name is in local encoding too. Tags and bookmarks are also read
> with encoding.tolocal.
>
> So a tooltip which shows the username, commit message, bookmarks and
> branch names could be implemented. Showing the filenames for a commit is
> more problematic since you cannot be sure that they can be JSON encoded.

Why can't we encode the characters outside of the jsonable range, or just strip them off? Hgweb outputs them now in html pages as strings, and I don't see any reason why it's not possible to add filter jsonescape to process this correctly.

>
> --
> Martin Geisler