Applied, as commit 6b508ea7c
I cleaned up the commit message a bit. Commit message standards
are codified in the "GNU coding standards"
https://www.gnu.org/prep/standards/ which I should probably
re-read at some point. My memory of it is fuzzy and I sort of
just format commit messages based on vibes at this point.
In my opinion the two most important bits (again based on vibes
and fuzzy memory) are:
1: A clear and concise first line that is no more then 68
characters (length is for some weird Emacs reason. I forget why).
2: Everything touched is mentioned by its exact name so I can run
"git log --grep=VAR-NAME" to figure out why something broke.
Paul Bryan <[email protected]> writes:
Morgan Smith <[email protected]> writes:
Paul Bryan <[email protected]> writes:
If you've modified it enough to want your own name on it you
can always add "Co-authored-by:".
I don't care if my name is attached or not.
I agree that in this case we shouldn't add that tag but it is
useful to know about if you keep diving into older patches.
Adding this meta-data helps us avoid attributing something to
someone that they didn't do and might not agree with.
I briefly looked at the git documentation which shows other
meta-data keys which might be useful. Like 'Reviewed-by' and
'Signed-off-by'. Maybe I should add you to one of those but I'm
not going to read the documentation to figure out when to use them
because I am lazy.
Regarding giving credit, would the etiquette be to check with
the original author first before attaching their name? I guess
they did submit the patch to the list so credit would be
appropriate - it just took a few years to be applied! It's only
a small patch so maybe it doesn't make much difference either
way.
This is a tricky concept that I haven't seen any discussion around
personally.
I believe submitting a patch to the mailing list is consent
enough. In this specific case, the author went out of their way
to attribute their copyright to the FSF so we have extra consent.
Ihor Radchenko <[email protected]> writes:
I think we can make separator a variable (not a custom
option). This way, if someone absolutely wants to change
it, they could.
+(defconst org-tag-crm-separator "[ \t]*[:,][ \t]*"
+ "Regexp used to determine `crm-separator' when reading
multiple tags.")
+
A modifiable variable would mean defvar, not defconst.
I went with defconst since the various existing org-tag regexes
are of this form and most other defvars in org.el are not
initialised. Seemed to be the convention to follow here. As I
understand it, the idea is for users to modify it only if they
really, really want to. Mostly it should be left as a
constant. Happy to defer to others judgement on that though.
I totally agree with you. I was just trying to respect Ihor's
wishes. If Ihor cares to, they can change it themselves later.
Subject: [PATCH] org.el, org-capture.el: Introduce variable
for completing
read separator reg when reading tags.
"separator reg"?
oops. regex :)
I was wondering what that meant :)
* lisp/org.el org-tag-crm-separator: Introduce variable for
regex determining completing read separator when reading tags.
Put the variable in parenthesis like "(org-tag-crm-separator)".
Okay, I'll do that. Seem a bit confusing given a sexp like that
would mean something like a function or macro. I guess the
syntax here is not lisp though!
The "GNU coding standards" seems to have been written primarily
with C in mind.
Although it is very lisp like to enclose a list in parenthesis :P
Thanks for helping us with this older report! Do let me know
if you ever need any help with anything at all :)
Awesome. I had intended to be more active, but haven't quite
managed it yet. It's great that this is such a helpful and
supportive community though. I may take you up on the offer some
time!
Glad to hear it!
And with that this thread is done! Again thank you so much for
dealing with this!
