Lars Schneider writes:
>> Of course it is possible, if you really wanted to. The code knows
>> if it gave the "we launched and waiting for you" notice, so it can
>> maintain not just one (i.e. "how I close the notice?") but another
>> one (i.e. "how I do so upon an error?") and use it in the err
On Wednesday 22 November 2017 10:25 PM, Lars Schneider wrote:
On 20 Nov 2017, at 01:11, Junio C Hamano wrote:
Kaartic Sivaraam writes:
It might be a good thing to keep the notice but I think it would be
better to have that error message in a "new line". I'm not sure if
it's possible or not.
On Wed, Nov 22, 2017 at 11:53 AM, Lars Schneider
wrote:
>> On 17 Nov 2017, at 20:41, Eric Sunshine wrote:
>> * emacsclient already prints its own message ("Waiting for Emacs...",
>> which runs together with Git's message). Perhaps treat emacsclient as
>> a special case and skip printing this mess
> On 20 Nov 2017, at 01:11, Junio C Hamano wrote:
>
> Kaartic Sivaraam writes:
>
However, it's not clear how much benefit you gain from stashing this
away in a static variable. Premature optimization?
>>>
>>> The variable being "static" could be (but it was done primarily
>>> becaus
> On 17 Nov 2017, at 20:41, Eric Sunshine wrote:
>
> On Fri, Nov 17, 2017 at 8:51 AM, wrote:
>
>> + char *term = getenv("TERM");
>> +
>> + if (term && strcmp(term, "dumb"))
>> + /*
>> +*
> On 17 Nov 2017, at 19:40, Junio C Hamano wrote:
>
> lars.schnei...@autodesk.com writes:
>
>> Junio posted the original version of this patch [1] as response to my RFC
>> [2].
>> I took Junio's patch and slightly changed the commit message as well as the
>> message printed to the user after G
Kaartic Sivaraam writes:
>>> However, it's not clear how much benefit you gain from stashing this
>>> away in a static variable. Premature optimization?
>>
>> The variable being "static" could be (but it was done primarily
>> because it allowed me not to worry about freeing),
The current code ha
On Saturday 18 November 2017 07:10 AM, Junio C Hamano wrote:
Eric Sunshine writes:
@@ -40,6 +40,32 @@ int launch_editor(const char *path, struct strbuf *buffer,
const char *const *en
+ static const char *close_notice = NULL;
+
+ if (isatty(2) && !close_notice) {
Eric Sunshine writes:
>> @@ -40,6 +40,32 @@ int launch_editor(const char *path, struct strbuf
>> *buffer, const char *const *en
>> + static const char *close_notice = NULL;
>> +
>> + if (isatty(2) && !close_notice) {
>
> If you reverse this condition to say (!close_no
On Fri, Nov 17, 2017 at 8:51 AM, wrote:
> When a graphical GIT_EDITOR is spawned by a Git command that opens
> and waits for user input (e.g. "git rebase -i"), then the editor window
> might be obscured by other windows. The user may be left staring at the
> original Git terminal window without e
lars.schnei...@autodesk.com writes:
> Junio posted the original version of this patch [1] as response to my RFC [2].
> I took Junio's patch and slightly changed the commit message as well as the
> message printed to the user after GIT_EDITOR is invoked [3].
>
> Thanks,
> Lars
Thanks.
> diff --gi
From: Junio C Hamano
When a graphical GIT_EDITOR is spawned by a Git command that opens
and waits for user input (e.g. "git rebase -i"), then the editor window
might be obscured by other windows. The user may be left staring at the
original Git terminal window without even realizing that s/he nee
12 matches
Mail list logo
