Re: [PATCH 1/4] terminal: use flags for save_term()
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Mar 7, 2022, 12:06 UTC
- Message-ID
- <220307.86ee3e0xv6.gmgdl@evledraar.gmail.com>
- In-Reply-To
- <1351bb93-673e-817f-6911-d321217032ce@gmail.com>
On Mon, Mar 07 2022, Phillip Wood wrote:
Show 49 quoted lines
> On 05/03/2022 14:02, Ævar Arnfjörð Bjarmason wrote:
>> On Fri, Mar 04 2022, Phillip Wood wrote:
>>
>>> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>>>
>>> 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 <phillip.wood@dunelm.org.uk>
>>> ---
>>> 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...), ....