Re: Fwd: Update earlier posted hideif.el enhancements

[Luke Lee]

>>       ;; 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

hideif-cleanup.patch
Description: Binary data