On Tue, Mar 15, 2016 at 5:48 PM, Linus Torvalds
<[email protected]> wrote:
> On Tue, Mar 15, 2016 at 5:45 PM, Junio C Hamano <[email protected]> wrote:
>>
>> Wouldn't it be nicer to do this kind of thing at the output side? A
>> stupid way would be to have an option to indent the log text with a
>> tab instead of 4-spaces, but a more sensible way would be to keep
>> the visual 4-space-indent and do the expand-tab for each line of
>> text.
>
> Yes, that would certainly work for me too. It's just the "ascii boxes
> don't line up" that is problematic..
Ok, that actually turns out to be pretty easy.
Here's a first try at it. It does tab expansion only for the cases
that indent the commit message, so for things like "pretty=email" it
makes no difference at all.
However, it hardcodes the hardtab size to 8, and makes this all
unconditional. That's how a vt100 terminal works, but fancer terminals
may allow you set actual tab-stops, and if you're in emacs you can
probably do just about anything)
Comments? This does make the kernel commit 0dc8c730c98a look fine, so
it would make me happy.
I can write a commit log etc if people think this is ok, but right now
this is just a silly raw patch in the attachement..
Linus
pretty.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/pretty.c b/pretty.c
index 92b2870a7eab..dcd6105d1eb2 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1652,8 +1652,26 @@ void pp_remainder(struct pretty_print_context *pp,
first = 0;
strbuf_grow(sb, linelen + indent + 20);
- if (indent)
+ if (indent) {
+ int i, last = 0, pos = 0;
+
strbuf_addchars(sb, ' ', indent);
+ for (i = 0; i < linelen; i++) {
+ int expand;
+ if (line[i] != '\t')
+ continue;
+ strbuf_add(sb, line+last, i-last);
+ pos += i-last;
+ expand = (pos + 8) & ~7;
+ strbuf_addchars(sb, ' ', expand - pos);
+ pos = expand;
+ last = i+1;
+ }
+
+ // Handle the tail non-tab content
+ line += last;
+ linelen -= last;
+ }
strbuf_add(sb, line, linelen);
strbuf_addch(sb, '\n');
}
