-
Notifications
You must be signed in to change notification settings - Fork 4
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
How to add properly parameter description? #3
Comments
Hello, thank you for having given this package a chance. The docstring format provided by the package follows the official Google style guidelines: https://google.github.io/styleguide/pyguide.html#383-functions-and-methods The docstring doesn't contain the type in parentheses. The exception is for Python code that misses type annotations. Unfortunately, the package of this project doesn't support it. |
It's a pity, as this is a convention used by many of my projects. Kind Regards Carlo D. |
I know. I originally wrote this package because I needed it at work and I always dealt with type annotated code. Nowadays I actually use this package way less often. I will see if I find some free time to extend it. Meanwhile, feel free to contribute yourself if you have the motivation. I'd be happy to get in contact and explain how the code works in case. |
Hello, thanks for the reply. I've managed to make these modifications:
(maybe would be better)
but I don't know very well the implication data order. But now I can't get the way to output two lines one for the argument name and type in the form of:
and the subsequent indentend line for the description. I've managed to get this code:
But it is not working, I can't return (my fault I'm a beginner in elisp) the two lines. It print only "argument description" Obviously something is lacking. However I have forked your repo, just in case, but I think, that there will be flag to manage the two ways, or two different functions for the two ways, maybe. Kind Regards Carlo D. |
Hi. What you propose makes sense. You can create a new top level function that can be associated with a different key-binding. You can add it next to the existing one here: insert-docstring/python-insert-docstring.el Line 113 in cd6419b
Extending the argument data as you proposed makes sense. You then have to populate the new field with a function similar to this one: insert-docstring/python-insert-docstring.el Line 182 in cd6419b
I think that the new field must always be specified by the user, because the new docstring format is applicable only to code that misses type annotations. The insert-docstring/python-insert-docstring.el Line 289 in cd6419b
You don't have to add a line break between the argument name and its description, because it's optional according to the Google Style Guide. If you want to add the line break, it's a bit more complicated, because the docstring is stored in memory as a list of lines, before being dumped to the buffer. This way it's easier to split the content of the docstring from its final formatting (this package takes care of breaking the lines that are too long). Something that I recommend you to do is to add a unit test here: I personally find it quicker to iterate on the code that I develop by running the unit test rather than always manually calling the function on some file. The last step is extending the Feel free to open a pull request when you are ready and I'll review it. Thank you very much for your effort! |
Many thanks, I will see your remarks after Christmas. Probably I will need some help again, I will get in touch here, prior to making the PR. Merry Christmas! Kind Regards Carlo D. |
No problem. Merry Christmas! |
Hello, I find you package useful, but I have to edit them everytime I use it.
usually the format I use and is advised as example here:
https://www.sphinx-doc.org/en/master/usage/extensions/example_google.html#example-google
is:
There is some way to achieve this?
Kind Regards
Carlo D.
The text was updated successfully, but these errors were encountered: