git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 22, 2008, 17:14 UTC
Message-ID
<7voda8ap6r.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<20080222163035.5942.93410.stgit@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
Show 13 quoted lines
> 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) 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?
Previous: Jakub NarebskiNext: Jakub Narebski
Message 5 of 16 in “Do not chop HTML tags in commit search result”
  1. Do not chop HTML tags in commit search resultJean-Baptiste Quenot, Feb 13, 2008
  2. Jakub NarebskiFeb 13, 2008
  3. Junio C HamanoFeb 13, 2008
  4. gitweb: Better chopping in commit search resultsJakub Narebski, Feb 22, 2008
  5. Junio C HamanoFeb 22, 2008
  6. Jakub NarebskiFeb 22, 2008
  7. Jakub NarebskiFeb 22, 2008
  8. gitweb: Option to chop at beginning and in the middle in chop_strJakub Narebski, Feb 23, 2008
  9. Junio C HamanoFeb 23, 2008
  10. Jakub NarebskiFeb 23, 2008
  11. gitweb: Option to chop at beginning and in the middle in chop_strJakub Narebski, Feb 24, 2008
  12. Junio C HamanoFeb 25, 2008
  13. gitweb: Better cutting matched string and its contextJakub Narebski, Feb 25, 2008
  14. Junio C HamanoFeb 25, 2008
  15. Karl HasselströmFeb 23, 2008
  16. Jakub NarebskiFeb 23, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.