Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add c-lang-defconst c-anchored-cpp-prefix #453

Merged
merged 2 commits into from
Apr 7, 2018
Merged

Add c-lang-defconst c-anchored-cpp-prefix #453

merged 2 commits into from
Apr 7, 2018

Conversation

zonuexe
Copy link
Member

@zonuexe zonuexe commented Apr 7, 2018

This is the cause of the error that occurred in Emacs snapshots (later 25) and 26 development versions. We must confess that we did not know how to debug Emacs Lisp and CC Mode.

PHP Mode inherits the properties of java-mode, but Java has no preprocessor, and PHP defined c-opt-cpp-prefix for PHP tags. Therefore, by properly defining c-anchored-cpp-prefix, errors are prevented from occurring.

This error was c-macro-is-genuine-p called from c-beginning-of-macro, but this problem is obscured by the huge condition-case of c-syntactic-re-search-forward.

This is the cause of the error that occurred in Emacs snapshots (later
25) and 26 development versions. We must confess that we did not know
how to debug Emacs Lisp and CC Mode.

PHP Mode inherits the properties of java-mode, but Java has no
preprocessor, and PHP defined `c-opt-cpp-prefix` for PHP tags.
Therefore, by properly defining `c-anchored-cpp-prefix`, errors are
prevented from occurring.

This error was c-macro-is-genuine-p called from c-beginning-of-macro,
but this problem is obscured by the huge `condition-case` of
`c-syntactic-re-search-forward`.
@zonuexe zonuexe merged commit 0b1553b into emacs-php:master Apr 7, 2018
@zonuexe
Copy link
Member Author

zonuexe commented Apr 7, 2018

resolve #380 #426

@zonuexe zonuexe mentioned this pull request Apr 7, 2018
@ejmr
Copy link
Collaborator

ejmr commented Apr 8, 2018

We must confess that we did not know how to debug Emacs Lisp and CC Mode.

This understatement made me literally laugh out loud, because for CC Mode in particular it is painfully true, heh.

I have started looking at the PHP Mode GitHub page about once every 1--2 weeks, usually on the weekend; on Saturday or Sunday I will glance over the recent bug reports and pull requests to see if there is anything really important I could contribute. I very rarely write any code anymore, so I have nothing to contribute in that way. But I try to keep an eye open for any situations where I could perhaps help explain why PHP Mode does this-or-that based on decisions made years ago by people like myself who are no longer actively involved.

Fortunately there is nothing I can offer regarding c-opt-cpp-prefix because Joris Steyn provided great information in the relevant commits from Augest--September of 2014:

  1. ec4c166
  2. dce73c5

What I can offer, however, is a small amount of advice regarding project maintenance.

It was easy for me to find those two commits via git log -S"c-opt-cpp-prefix", i.e. Git's so-called "pickaxe" functionality. In my experience though many developers, including those who are the maintainers or authors of various projects, rarely make use of the pickake; in fact, most often I have found that people are completely unaware the pickake even exists for Git commands like log and diff (and I think format-patch, but I have used that command less than five times in my life, heh).

On more than one occassion I have seen Linus Torvalds say that the best decision he made regarding Git was to hand over its maintenance and future design to Junio C. Hamano. I consider Hamano to be one of the best maintainers of any open-source project, and I have long studied what he does with Git so-as to improve my own abilities as a maintainer. One thing I learned from Hamano's work was the practice of using the pickaxe to improve the quality of commit messages.

More specifically, I learned from Hamano the habit of using Git's pickaxe to help me create references to older commits when those commits provide important context, especially for patches which fix bugs. Here is a recent example of that practice. Hamano uses the specific format of...

Abbreviated-SHA-1-Hash ("First Line of the Commit Message")

...when he makes reference to previous commits. It is not necessary to provide the entire SHA-1 hash so long as you provide enough characters for it to be unique; six-to-eight characters is sufficient, and I believe Hamano himself always uses eight. Personally I have never run into a situation where providing the first eight characters of a hash was insufficient for finding a specific Git commit, but I must also note that I have never maintained a project even remotely close to Git in terms of the amount of contributors and commits. With that in mind, it is important to note that Hamano provides the first line of the commit after its abbreviated hash; this provides a way to find the correct commit in the extremely rare chance that an eight-digit hash is ambiguous. More importantly, including the first line of the commit message provides informative context. I believe it can even have a ripple effect by which contributors might feel more inclined to ensure the subject lines of their commit messages are well-written, being both succinct and explanatory, when they know the maintainer(s) are apt to quote those lines in future commits.

This is all a long-winded way for me to offer the simple advice that you should consider following the same practice. There are various Git GUIs and web interfaces which will automatically convert such references, i.e. the abbreviated hash, into hyperlinks pointing directly to those commits. That behavior, combined with the parenthetical quoted subject line following the hash, makes it easy for future developers to understand the context of a given reference and to find more detailed information by following said links if they want to. There have been multiple times where I have been able to find and fix bugs more quickly thanks to such informative references to previous patches.

When you are implementing a feature or fixing a bug, I recommend that you use the pickaxe (or other Git features for searching the log) to find any related commits that already exist, and that you make reference to those older commits whenever you feel that they would improve the informative and explanatory quality of your own commits. Likewise, if you agree that this practice is useful, don't hesitate to ask contributors to do the same, particularly those who contribute on a regularly basis and are likely to understand enough about the code and development of PHP Mode that they can recognize what previous commits would offer the most useful context for whatever patch(es) they submit.

Finally, on the subject of the maintenance of Git itself, Junio C. Hamano has written about other practices, some of which you may find worthwhile for PHP Mode.


As an aside, just like Torvalds said of Hamano, my best decision regarding PHP Mode was to turn over maintenance to you. I have been nothing but happy and impressed with how effectively and quickly you made the transition from contributor to lead/sole maintainer. The fact that I have had very little to say since stepping down is a testament to how well you are running PHP Mode. Thank you again for all your efforts and everything you continue to do for PHP developers who use GNU Emacs.

--ejmr

@zonuexe zonuexe deleted the php-mode-indentation-error branch April 9, 2018 05:33
@zonuexe zonuexe mentioned this pull request May 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants