Re: [PATCH] gitweb: Better chopping in commit search results

[Jakub Narebski <jnareb@gmail.com>]

On Fri, 22 Feb 2008, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> From: Junio C Hamano <gitster@pobox.com>
>> Subject: [PATCH] gitweb: Better chopping in commit search results
>>
>> When searching commit messages (commit search), if matched string is
>> too long, the generated HTML was munged leading to an ill-formed XHTML
>> document.
>>
>> Now gitweb chop leading, trailing and matched parts, HTML escapes
>> those parts, then composes and marks up match info.  HTML output is
>> never chopped.  Limiting matched info to 80 columns (with slop) is now
>> done by dividing remaining characters after chopping match equally to
>> leading and trailing part, not by chopping composed and HTML marked
>> output.
> 
> Could somebody test this with very long search string, as that
> was how the issue initially came up, to see (1) if it really
> fixes the "mark-up chopped in the middle" issue, (2) [...]

The bug in question was cause by the chop _after_ doing HTML
markup. Now gitweb chops, then HTML escapes, and chops no more.
There is no way this bug can happen now.

BTW if commit messages follows "wrap at 76 column" convention
it is not easy to test this condition... :-) 


But you are right that output should be improved...
 
> For example, if you are looking for "very long ... and how"
> in the first paragraph of message (if it were all on a single
> line), wouldn't you want to see:
> 
>     ...st this with <<very long ... and how>> the actual out...
> 
> rather than:
> 
>     Could som... <<very long search stri...>> the actual out...
> 
> in the result?

...but I think it is better left for another patch.

P.S. When testing this commit I have noticed that currently, probably
due to some misquoting, or interaction between escapemeta and quoting,
searching for messages which contain "'" (apostrophe), e.g. "don't"
currently doesn't work. Will investigate...
-- 
Jakub Narebski
Poland