[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] [PATCH] Some improvements to the c syntax

From: Liu Hao
Subject: Re: [Nano-devel] [PATCH] Some improvements to the c syntax
Date: Mon, 11 Dec 2017 09:58:32 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

On 2017/12/10 22:38, Benno Schulenberg wrote:
> Op 10-12-17 om 14:50 schreef Liu Hao:
>> On 2017/12/10 21:11, Benno Schulenberg wrote:
>>> I think #define should not color what comes after it.
>> This does not seem practically possible. I tried moving the rule for
>> after this rule but it turned out that every occurrence got colored -
>> not only
>> those following `#define` immediately, but those inside the macro body.
> I don't understand what you mean.  Do you mean #define inside a macro
> body gets colored and you don't want it to be?

As an example, I had code:

#define THROW_LENGTH_ERROR_(message_, field_)   \
    DEBUG_THROW(::Poseidon::Cbpp::Exception,    \
        ::Poseidon::Cbpp::ST_LENGTH_ERROR, ::Poseidon::sslit(   \
            "Length error in message " TOKEN_TO_STR(message_) " \
            while parsing " TOKEN_TO_STR(field_)    \

, then all occurrences of THROW_LENGTH_ERROR_, DEBUG_THROW,
ST_LENGTH_ERROR and TOKEN_TO_STR got colored as red, accompanied with
everything else in cyan.

> Anyway, to test the patch, I look at these two locations:
>    nano +52 src/nano.h
>    nano +797 src/global.c
> For the first one, the stuff after the #define is valid C, so it
> should be colored as C.  And thus it should be this way for all
> #defines.  For the second case, both lines of the #if should be
> colored.  The symbols used in the #ifs, #ifdefs and #ifndefs are
> not really part of the program, they are configuration, so I like
> it when they are not colored as if they were program symbols.

Well it depends on how #define is used. Macros are token replacements
that are not always C code. They do not go into object files in any
forms, unless expanded to real C code somehow. When unrolling loops by
hand, interjected macros could be helpful, but it is also necessary to
distinguish macros from plain C code. That is why I think macros should
be colored integrally.

>>> Together with #else and #endif it should be in a single-line color
>>> command.
>>> Maybe also #include should be in the single-line one?
>> This will require two rules, one of which is for the single-line and
>> the other
>> is multiple-line. I have attached an alternative patch for this.
> Yes.  I propose instead the upcoming patch.
> Benno
> _______________________________________________
> Nano-devel mailing list
> address@hidden

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]