Re: [PATCH v2 00/13] bash prompt speedup

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH v2 00/13] bash prompt speedup

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:57:48

SZEDER Gábor [off-list ref] writes:
This patch series eliminates many command substitutions and commands
in __git_ps1() from top to bottom by replacing them with bash builtins
or consolidating them.  A few timing results are shown in the log
message of patch 10.
Nice.  I think I saw Peff's comment and discussion between you two
already resuted in a fixup, so perhaps I'll see a reroll sometime
later when the dust settles?

Also, could you help review the other topic by Eduardo R. D'Avila
about colored prompt (Sion Oosthoek, who did the color support,
CC'ed)?

    http://thread.gmane.org/gmane.comp.version-control.git/228017

The impression I got when the PROMPT_COMMAND series was discussed
last October was that you need to use \[...\] pairs to get the
cursor position right for the purpose of command line editing, and
D'Avila's series seemed to only do so in PROMPT_COMMAND mode.

Re: [PATCH v2 00/13] bash prompt speedup

From: Simon Oosthoek <hidden>
Date: 2016-06-15 22:57:49

* Junio C Hamano [off-list ref] [2013-06-18 09:48:28 -0700]:
SZEDER Gábor [off-list ref] writes:
quoted
This patch series eliminates many command substitutions and commands
in __git_ps1() from top to bottom by replacing them with bash builtins
or consolidating them.  A few timing results are shown in the log
message of patch 10.
Nice.  I think I saw Peff's comment and discussion between you two
already resuted in a fixup, so perhaps I'll see a reroll sometime
later when the dust settles?

Also, could you help review the other topic by Eduardo R. D'Avila
about colored prompt (Sion Oosthoek, who did the color support,
CC'ed)?

    http://thread.gmane.org/gmane.comp.version-control.git/228017

The impression I got when the PROMPT_COMMAND series was discussed
last October was that you need to use \[...\] pairs to get the
cursor position right for the purpose of command line editing, and
D'Avila's series seemed to only do so in PROMPT_COMMAND mode.
Hi Junio e.a.

Unfortunately I'm very busy with lots of stuff, so hardly time to look at this. (I didn't read the full patch or resulting file)

The PROMPT_COMMAND business was not something I was glad to use, I was unable to get command substitution mode to work with colours and keep bash happy about the prompt string length. The thing to test is not whether or not colours appear when using substitution in PS1, but to see whether bash will not mess up the commandline when browsing through the history. This is especially inconvenient with very long commandlines (as you can imagine).

An optimisation which I've not yet had time to work on would be to do a lot of the processing in separate functions and use the result in separate functions for pcmode and subst. mode. The idea being that the maintainability of the logic for generating the prompt goes up (no duplicate code, clear separation, etc.) and the size of the called functions to gerenate the prompt goes down. And perhaps most important that it would be very easy to build a customised version of __git_ps1() using those functions from the standard code. 

I know this is pretty vague, I wish it wasn't so...

If it's somehow possible to eliminate the PROMPT_COMMAND mode, I'm all for it. But I doubt it can be done while keeping commandline browsing working ok... (please go ahead and prove me wrong!)

Cheers

Simon
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help