Closed milouse closed 3 years ago
All right, modulo these comments, it looks good.
Can you confirm that you have the FSF copyright assignment or else haven't exceeded the 15 line contribution limit to Emacs? IN the latter case, please add the line Copyright-paperwork-exempt: yes
to the commit message.
Thanks!
Can you confirm that you have the FSF copyright assignment or else haven't exceeded the 15 line contribution limit to Emacs? IN the latter case, please add the line
Copyright-paperwork-exempt: yes
to the commit message.
I’m a bit afraid of these lines as I’m not a lawer… I’m not very sure about what I should do. From the following blog post I found a link to that template but I’m not sure about its content. Particularly the thing about my employer or the part about my changes, the files on which I work. I mean: do I have to write it every time I make a new PR? Because I’m don’t know right now on which file I’ll be working in the future, or not :/
Maybe you can give me some direction about that? Or does it helps if I explicitely give you my patch in public domain?
If you intend to make further contributions to Emacs and/or GNU ELPA packages, then you would need to complete that paperwork.
But if this is just a one-off contribution, then you don't need do to anything. In this case, I just ask one favor: please edit the commit message and append the phrase Copyright-paperwork-exempt: yes
at the end, so whoever is in charge of keeping track of things at the FSF knows what the situation was.
I apologize for the annoyance, but I wasn't the one who came up with this :-).
Or does it helps if I explicitely give you my patch in public domain?
I don't know if this is a thing — I'm not a lawyer either. But then again, you have a different reason to be exempt from the copyright paperwork if you have contributed 15 lines of code or less to Emacs or GNU ELPA packages.
Ok, thanks for your kind words. I think 6 lines do not needs paperwork for now ;)
However I’ll try to send the template I found and see what happen anyway. Maybe for later it can help.
Thanks!
devdocs-mode
is derived fromspecial-mode
, meaning some keybinding are present by default likeh
to display the mode help,q
to close the window, andg
to revert it. However, contrary to the 2 firsts, this one by default try to reopen some file, what leads to a crash when the buffer is not associated with any file. Thus currently, thedevdocs-mode
expose therevert-buffer
behavior in its documentation, but using it leads to a crash.This MR adds the necessary local variable, mapped to a simple wrapper function for
devdocs--render
to make that keybinding work as expected.This feature is really needed anyway, for exemple to quickly and easily reflow shr content when changing the frame geometry.