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

Re: [PATCH] pretty-print: de-tabify indented logs to make things line up properly

From
Linus Torvalds <torvalds@linux-foundation.org>
Date
Mar 16, 2016, 18:21 UTC
Message-ID
<CA+55aFxV5PWdSn9Gj=zV464TtJo=QvciZrhc5Pwe+Qfyqt8sXw@mail.gmail.com>
In-Reply-To
<xmqq7fh25mkc.fsf@gitster.mtv.corp.google.com>
On Wed, Mar 16, 2016 at 11:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
>  (1) if turning your "preparation; do { ... } while()" into
>      "while () { }" would make the result a bit easier to read;

So it's probably partly taste, but I will also disagree with your "easier to read", because of the way the code is logically structured.

In particular, the "no TAB" case is actually *fundamentally* different from the "no TAB at the end" case. The return value is different, and the caller does very different things - the code tries to make it very clear that that "no TAB" situation is very different from "we found a TAB".

So it's not "preparation + do-while".

It's "preparation + handle the no-TAB case differently", and then the "do-while" is very natural because by the time we get to the "ok, we are now going to need to do something about the line" stage, we already know we have a tab.

But the code *could* be made to just always do the whole "strbuf_add()", and not return a return value at all, and the no-tab case wouldn't be explicitly written to be different.

Let me know if you'd prefer that variant, and I'll send a new version.
>  (2) if we can somehow eliminate duplication of "tab + 1" (spelled
>      differently on the previous line as "1+tab"), the end result
>      may get easier to follow.

Yeah, I considered that. Either by just doing "tab++" before (so the +1" would come from that in both cases), or by introducing a new variable like

    ptrdiff_t bytes_used;
    ...
    bytes_used = 1 + tab - line;
and then just doing
    line += bytes_used;
    linelen -= bytes_used;

and the code I wrote just didn't do any of those temporary updates, and instead just did the "+1" by hand in both cases.

Again, I can redo the patch, just tell me which model you prefer.
                 Linus
Previous: Junio C HamanoNext: Junio C Hamano
Message 4 of 57 in “pretty-print: de-tabify indented logs to make things line up properly”
  1. pretty-print: de-tabify indented logs to make things line up properlyLinus Torvalds, Mar 16, 2016
  2. Linus TorvaldsMar 16, 2016
  3. Junio C HamanoMar 16, 2016
  4. Linus TorvaldsMar 16, 2016
  5. Junio C HamanoMar 16, 2016
  6. Junio C HamanoMar 16, 2016
  7. Linus TorvaldsMar 16, 2016
  8. Junio C HamanoMar 16, 2016
  9. Linus TorvaldsMar 16, 2016
  10. 1/4 pretty-print: de-tabify indented logs to make things line up properlyJunio C Hamano, Mar 17, 2016
  11. 2/4 pretty-print: simplify the interaction between pp_handle_indent() and its callerJunio C Hamano, Mar 17, 2016
  12. 3/4 pretty-print: further abstract out pp_handle_indent()Junio C Hamano, Mar 17, 2016
  13. 4/4 pretty-print: add --pretty=noexpandJunio C Hamano, Mar 17, 2016
  14. Linus TorvaldsMar 17, 2016
  15. Junio C HamanoMar 17, 2016
  16. Jeff KingMar 18, 2016
  17. Linus TorvaldsMar 18, 2016
  18. Jeff KingMar 18, 2016
  19. Junio C HamanoMar 18, 2016
  20. 0/5 Expanding tabs in "git log" outputJunio C Hamano, Mar 23, 2016
  21. 1/5 pretty-print: de-tabify indented logs to make things line up properlyJunio C Hamano, Mar 23, 2016
  22. 2/5 pretty-print: simplify the interaction between pp_handle_indent() and its callerJunio C Hamano, Mar 23, 2016
  23. 3/5 pretty-print: further abstract out pp_handle_indent()Junio C Hamano, Mar 23, 2016
  24. 4/5 pretty-print: limit expand-tabs to selected --pretty formatsJunio C Hamano, Mar 23, 2016
  25. 5/5 pretty-print: teach "--no-expand-tabs" option to "git log"Junio C Hamano, Mar 23, 2016
  26. Linus TorvaldsMar 23, 2016
  27. Jeff KingMar 24, 2016
  28. Junio C HamanoMar 24, 2016
  29. Torsten BögershausenMar 24, 2016
  30. Junio C HamanoMar 24, 2016
  31. Junio C HamanoMar 24, 2016
  32. Torsten BögershausenMar 25, 2016
  33. Torsten BögershausenMar 25, 2016
  34. Junio C HamanoMar 25, 2016
  35. Junio C HamanoMar 25, 2016
  36. 0/3 Expanding tabs in "git log" outputJunio C Hamano, Mar 29, 2016
  37. 1/3 pretty: expand tabs in indented logs to make things line up properlyJunio C Hamano, Mar 29, 2016
  38. Eric SunshineMar 30, 2016
  39. Junio C HamanoMar 30, 2016
  40. 2/3 pretty: enable --expand-tabs by default for selected pretty formatsJunio C Hamano, Mar 29, 2016
  41. Jeff KingMar 30, 2016
  42. Junio C HamanoMar 30, 2016
  43. 3/3 pretty: allow tweaking tabwidth in --expand-tabsJunio C Hamano, Mar 29, 2016
  44. 0/4 Expanding tabs in "git log" outputJunio C Hamano, Apr 5, 2016
  45. 1/4 pretty: expand tabs in indented logs to make things line up properlyJunio C Hamano, Apr 5, 2016
  46. 2/4 pretty: enable --expand-tabs by default for selected pretty formatsJunio C Hamano, Apr 5, 2016
  47. 3/4 pretty: allow tweaking tabwidth in --expand-tabsJunio C Hamano, Apr 5, 2016
  48. 4/4 pretty: test --expand-tabsJunio C Hamano, Apr 5, 2016
  49. Eric SunshineApr 5, 2016
  50. Jeff KingApr 5, 2016
  51. Junio C HamanoApr 5, 2016
  52. Jeff KingApr 5, 2016
  53. Junio C HamanoApr 5, 2016
  54. Perry HutchisonApr 5, 2016
  55. Jeff KingApr 5, 2016
  56. Linus TorvaldsMar 16, 2016
  57. Junio C HamanoMar 16, 2016

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.