Jakub Narebski <jnareb@xxxxxxxxx> writes:
> From: Junio C Hamano <gitster@xxxxxxxxx>
> 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) and how the
actual output looks like?
Regarding the latter, I have a slight suspicion that chopping
the tail of the middle part and showing very little context may
not produce a very useful output.
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?
That is, it any chopping ever needs to happen, I suspect a more
useful way to shorten the output would be to:
- divide the available space to give enough space to give
context for head and tail part.
- chop head from the left, if needed, with leading ellipsis;
- chop tail from the right, if needed, with trailing ellipsis;
- chop search string from both ends, if needed, with leading
and trailing ellipses.
Hmm?
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
