Subject: Re: [PATCH 1/4] terminal: use flags for save_term()

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Mon, 07 Mar 2022 13:06:54 +0100

On Mon, Mar 07 2022, Phillip Wood wrote:

> On 05/03/2022 14:02, Ævar Arnfjörð Bjarmason wrote:
>> On Fri, Mar 04 2022, Phillip Wood wrote:
>> 
>>> From: Phillip Wood <[email-masked]>
>>>
>>> The next commit will add another flag in addition to the existing
>>> full_duplex so change the function signature to take an unsigned flags
>>> argument. Also alter the functions that call save_term() so that they
>>> can pass flags down to it.
>>>
>>> Signed-off-by: Phillip Wood <[email-masked]>
>>> ---
>>>   compat/terminal.c | 41 +++++++++++++++++++++--------------------
>>>   compat/terminal.h |  5 ++++-
>>>   2 files changed, 25 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/compat/terminal.c b/compat/terminal.c
>>> index d882dfa06e..bad8e04cd8 100644
>>> --- a/compat/terminal.c
>>> +++ b/compat/terminal.c
>>> @@ -34,7 +34,7 @@ void restore_term(void)
>>>   	sigchain_pop_common();
>>>   }
>>>   -int save_term(int full_duplex)
>>> +int save_term(unsigned flags)
>> Doing e.g.  ...
>> 
>>>   void restore_term(void)
>>> diff --git a/compat/terminal.h b/compat/terminal.h
>>> index 0fb9fa147c..f24b91390d 100644
>>> --- a/compat/terminal.h
>>> +++ b/compat/terminal.h
>>> @@ -1,14 +1,17 @@
>>>   #ifndef COMPAT_TERMINAL_H
>>>   #define COMPAT_TERMINAL_H
>>>   +/* Save input and output settings */
>>> +#define SAVE_TERM_DUPLEX (1u << 0)
>> 	
>> 	enum save_terminal_flags {
>> 		SAVE_TERMINAL_FLAGS = 1 << 0,
>> 	};
>> 	
>> Here would be better IMO. See 3f9ab7ccdea (parse-options.[ch]:
>> consistently use "enum parse_opt_flags", 2021-10-08) for how it makes
>> debugging better.
>
> I'd remembered Junio objecting to enums for bit flags in the
> discussion of that patch but looking at the whole thread it seems like
> the debugger support lead him to change his mind. I'll update.

Yeah, aside from that I think part of that was whether it was worth it
to refactor it for existing code, but since this is new code & we tend
to use that pattern liberally (which pre-dates any recent changes I did
by quite a bit...), ....