bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#60805: [PATCH] Extend go-ts-mode with command to add docstring to fu


From: Eshel Yaron
Subject: bug#60805: [PATCH] Extend go-ts-mode with command to add docstring to function
Date: Sat, 21 Jan 2023 23:26:23 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Evgeni Kolev <evgenysw@gmail.com> writes:

> While I agree users should be able to customize, this particular
> example is too much of a corner case.
>
> For example, which Go functions/types need a docstring - all exported
> ones, and possibly some unexported; on the other hand, adding linter
> directives is so rare, you need to have a very good reason to add such
> exceptions. Team-accepted exceptions are stored as accompanying config
> files; example https://staticcheck.io/docs/configuration/#configuration-files
>
> We can add a variable holding a function which will take a defun
> treesit node as input, and return text. It's simple from
> implementation point of view.
>
> However, I don't see how this will make Emacs more useful - let's say
> the user wants to enter a linter comment, will they:
> 1. modify the customization variable to another function, then C-c
> C-d, then revert the customization variable; or
> 2. they can just enter the linter comment
>
> As long as entering linter comments is rare, I believe the user will just do 
> 2.

You don't need to modify the customization variable and restore it, you
just need to define a specialized command that let-binds it and calls
go-ts-mode-docstring.  So I could have a custom command for directives
or other formats that's as simple as:

(defun my/go-insert-custom-docstring ()
  (interactive)
  (let ((go-ts-mode-docstring-function #'my/go-custom-docstring))
    (go-ts-mode-docstring)))

With the current implementation, writing such a command would basically
require duplicating the code of go-ts-mode-docstring expect for the part
that inserts the Go function's name, right?  That's not that such a big
problem of course, but not ideal either IMO.


Eshel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]