>>       ;; inherit global values
>> -     (set (make-local-variable 'hide-ifdef-env)
>> -          (default-value 'hide-ifdef-env))
>> +;;   (set (make-local-variable 'hide-ifdef-env)
>> +;;        (default-value 'hide-ifdef-env))
>> +     (set 'hide-ifdef-env (default-value 'hide-ifdef-env))
>
>I don't undertand this change.  "(set '<foo> ...)" is just a bad form of
>(setq <foo> ...) so use `setq' instead.

Umm, here I only comment out the "make-local-variable" for hide-ifdef-env.
Otherwise the defined tokens works only for that buffer. I would like it to
work for all currently openned buffers in a "project" based manner. The
"set"
form derived from the original code. And I think it follows the example help
page of 'make-variable-buffer-local'. Is that help page out-dated?

>Indeed, there's been no real development on it in recently.  See my
>comments below.  Overall, I think it looks good and could be included in
>hideif.el, but I'd appreciate if you could clean up a few things first
>and split the change into a few chunks (this is a bit large to review as
>one single chunk).  IIUC one chunk would focus on extend the current
>parser & evaluator to handle the full CPP syntax.
>The remaining cleanups

The remaining cleanups are done. The original code that I derived from
contains a lot of ';;;' comments, I fixed most of them but left some since
they looks like to be placed on purpose to become a separator there.

To split the patch into some topic chunks is quite difficult now since it's
originally derived from a lot of commits in my local branch.

Even the core of my modification is rewritten twice. The first time I tried
is to store the parsing tree for each defined symbol so that there is no
need to reparse every time. However later I found it mandatory to restart
from token level since the token expansion sometimes re-ordered the
parse tree due to operator precedence. For example

#define EXPR(a,b)  a * b
#define EXPR2      EXPR(c+d,e+f)

The final result of EXPR2 will become c+d*e+f where d*e must be
calculated first. If we keep the parsing tree it will become (c+d) * (e+f).
Although good programs should not have such kind of errors but if we're
implement hideif this way it will not help programmer to catch such kind of
hidden C programming bugs early. Especially when a lot of operators
mixed together with some parenthesis skipped.

Therefore it's extremely time consuming to cherry-pick among all those
changes and group them into several valid topic patches, sorry about that...

Attached is the cleanup patch add-on to my previously posted patch.
Thanks.

-- 
Best regards,
Luke Lee