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

[Liu Hao]

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
>> MACROs
>> 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
> https://lists.gnu.org/mailman/listinfo/nano-devel


-- 
Best regards,
LH_Mouse