bug#69562: 29.2.50; go-ts-mode does not handle comments with fill-paragraph

bug#69562: 29.2.50; go-ts-mode does not handle comments with fill-paragraph

[Ankit Gadiya via Bug reports for GNU Emacs, the Swiss army knife of text editors]

When fill-paragraph is invoked on the comment lines in the `go-ts-mode`
buffer, it does not add the comment delimiters on the new lines.

    // Sample is a sample function with a very long comment. Sample is
a sample function with a very long comment. Sample is a sample
function with a very long comment. Sample is a sample function with a
very long comment.
    func Sample() {

    }

Becomes this:

    // Sample is a sample function with a very long comment. Sample is a
    sample function with a very long comment. Sample is a sample function
    with a very long comment. Sample is a sample function with a very long
    comment.
    func Sample() {

    }


In GNU Emacs 29.2.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.16.0) of 2024-03-04 built on t14
Repository revision: ae80192d97b8d0e54a9429091cd84190bdbeb49e
Repository branch: emacs-29
System Description: Debian GNU/Linux 12 (bookworm)

Configured using:
 'configure --prefix=/usr/local/ --localstatedir=/var/local/
 --libdir=/usr/local/lib/ --sysconfdir=/usr/local/etc/
 --mandir=/usr/local/share/man/ --with-gameuser=:games --with-modules
 --without-libotf --without-m17n-flt --without-gconf --without-gsettings
 --with-native-compilation=aot --with-pgtk --without-xaw3d
 --without-cairo --without-xinput2 --with-sound=no --with-json
 --with-mailutils --with-tree-sitter --with-rsvg 'CFLAGS=-O2 -pipe
 -march=native -fomit-frame-pointer''

Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS HARFBUZZ JPEG JSON LIBSELINUX
LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP
SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  corfu-popupinfo-mode: t
  windmove-mode: t
  hyperbole-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  evil-commentary-mode: t
  global-evil-collection-unimpaired-mode: t
  evil-collection-unimpaired-mode: t
  evil-mode: t
  evil-local-mode: t
  winner-mode: t
  global-corfu-mode: t
  corfu-mode: t
  override-global-mode: t
  marginalia-mode: t
  vertico-mode: t
  shell-dirtrack-mode: t
  which-key-mode: t
  savehist-mode: t
  global-auto-revert-mode: t
  pixel-scroll-precision-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/ankit/.config/emacs/elpa/transient-20240226.2332/transient hides
/usr/local/share/emacs/29.2.50/lisp/transient
/home/ankit/.config/emacs/elpa/jsonrpc-1.0.24/jsonrpc hides
/usr/local/share/emacs/29.2.50/lisp/jsonrpc
/home/ankit/.config/emacs/elpa/eglot-1.17/eglot hides
/usr/local/share/emacs/29.2.50/lisp/progmodes/eglot
/home/ankit/.config/emacs/elpa/eldoc-1.15.0/eldoc hides
/usr/local/share/emacs/29.2.50/lisp/emacs-lisp/eldoc

Features:
(shadow hl-line mail-extr emacsbug mule-util corfu-popupinfo mastodon
mastodon-search mastodon-toot facemenu mastodon-iso persist
mastodon-http request org-alert org-agenda alert log4e notifications
gntp org-modern evil-collection-org-present org-present
evil-collection-custom cus-edit cus-load hyperbole hinit hui hui-mouse
hmouse-key hui-menu hyrolo-menu hui-jmenu hibtypes hib-doc-id hyrolo
sort klink hmouse-tag hib-kbd hui-mini hib-debbugs hsys-www
evil-collection-eww eww url-queue mm-url hib-social hypb-ert hactypes
hsys-org org-element org-persist xdg org-id org-refile avl-tree
evil-collection-org org ob ob-tangle ob-ref ob-lob ob-table ob-exp
org-macro org-src ob-comint org-pcomplete org-list org-footnote
org-faces org-entities ob-emacs-lisp ob-core ob-eval org-cycle org-table
ol org-fold org-fold-core org-keys oc org-loaddefs org-version
org-compat org-macs evil-collection-man man hargs hpath
evil-collection-outline noutline outline hmouse-sh hsettings hui-em-but
hbut hmouse-drv hui-window hycontrol windmove hui-select hbdata hgnus
gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig
gnus-sum shr pixel-fill kinsoku url-file svg dom gnus-group gnus-undo
gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7
nnoo gnus-spec gnus-int gnus-range gnus-win evil-collection-gnus gnus
nnheader range hsmail hmail htz cal-julian evil-collection-calendar
cal-menu calendar cal-loaddefs hbmap hmoccur hvar hypb locate hversion
hload-path magit-bookmark evil-collection-magit magit-submodule
magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull
magit-fetch magit-clone magit-remote magit-commit magit-sequence
magit-notes magit-worktree magit-tag magit-merge magit-branch
magit-reset magit-files magit-refs magit-status magit magit-repos
magit-apply magit-wip magit-log which-func magit-diff smerge-mode
git-commit evil-collection-log-edit log-edit message sendmail yank-media
puny evil-collection-dired dired dired-loaddefs rfc822 mml mml-sec
evil-collection-epa epa derived epg rfc6068 epg-config gnus-util
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader
pcvs-util add-log magit-core magit-autorevert magit-margin
magit-transient magit-process with-editor server magit-mode magit-git
magit-base evil-collection-magit-section magit-section cursor-sensor crm
dash geiser-guile info-look transient geiser-debug geiser-repl
geiser-image geiser-capf geiser-doc geiser-menu geiser-autodoc
geiser-edit etags fileloop generator geiser-completion geiser-eval
geiser-connection tq geiser-syntax evil-collection-scheme scheme
geiser-impl help-fns radix-tree geiser-log geiser-popup
evil-collection-view view geiser-custom geiser-base
evil-collection-geiser geiser dape evil-collection-eglot eglot
external-completion evil-collection-xref xref evil-collection-flymake
flymake-proc flymake diff evil-collection-diff-mode diff-mode
evil-collection-ert ert ewoc evil-collection-debug debug backtrace
find-func evil-collection-imenu imenu jsonrpc gdb-mi bindat gud project
evil-collection-compile compile repeat pulse color just-mode jq-mode
smie c++-ts-mode c-ts-mode c-ts-common treesit evil-commentary
evil-commentary-integration evil-collection-unimpaired
evil-collection-which-key evil-collection-vertico
evil-collection-tabulated-list evil-collection-tab-bar
evil-collection-simple evil-collection-replace
evil-collection-process-menu evil-collection-package-menu
evil-collection-info evil-collection-indent evil-collection-help
evil-collection-elisp-mode evil-collection-eldoc evil-collection-corfu
evil-collection-consult evil-collection-comint evil-collection-buff-menu
evil-collection-bookmark evil-collection annalist evil evil-integration
evil-maps evil-commands reveal evil-jumps evil-command-window evil-types
evil-search evil-ex evil-macros evil-repeat evil-states evil-core comp
comp-cstr warnings icons advice evil-common thingatpt rect evil-vars
winner orderless corfu edmacro kmacro use-package-bind-key bind-key
easy-mmode marginalia vertico consult bookmark text-property-search pp
tramp tramp-loaddefs trampver tramp-integration files-x tramp-compat rx
shell pcomplete comint ansi-osc parse-time iso8601 time-date format-spec
ansi-color which-key exec-path-from-shell recentf tree-widget wid-edit
no-littering compat use-package-ensure savehist autorevert filenotify
modus-vivendi-theme modus-themes cl-extra help-mode use-package-core
pixel-scroll cua-base ring consult-autoloads corfu-terminal-autoloads
corfu-autoloads dape-autoloads eglot-autoloads eldoc-autoloads
evil-collection-autoloads annalist-autoloads evil-commentary-autoloads
evil-autoloads exec-path-from-shell-autoloads fish-mode-autoloads
geiser-guile-autoloads geiser-autoloads general-autoloads
goto-chg-autoloads hyperbole-autoloads kotl-autoloads hact set hhist
jq-mode-autoloads jsonrpc-autoloads just-mode-autoloads magit-autoloads
pcase git-commit-autoloads magit-section-autoloads dash-autoloads
marginalia-autoloads markdown-mode-autoloads mastodon-autoloads
no-littering-autoloads orderless-autoloads org-alert-autoloads
alert-autoloads log4e-autoloads gntp-autoloads org-modern-autoloads
org-present-autoloads persist-autoloads popon-autoloads
request-autoloads restclient-autoloads transient-autoloads
vertico-autoloads which-key-autoloads with-editor-autoloads info
compat-autoloads yasnippet-autoloads zig-mode-autoloads
reformatter-autoloads package browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie generate-lisp-file
url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs password-cache json subr-x map byte-opt gv
bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip
cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/pgtk-win pgtk-win term/common-win pgtk-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting font-render-setting cairo gtk pgtk multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 642718 92991)
 (symbols 48 45307 7)
 (strings 32 153518 11805)
 (string-bytes 1 5519927)
 (vectors 16 88306)
 (vector-slots 8 1533184 95107)
 (floats 8 667 421)
 (intervals 56 794 0)
 (buffers 984 13))

bug#69562: 29.2.50; go-ts-mode does not handle comments with fill-paragraph

[Eli Zaretskii]

> Date: Tue, 5 Mar 2024 14:11:14 +0530
> From:  Ankit Gadiya via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> When fill-paragraph is invoked on the comment lines in the `go-ts-mode`
> buffer, it does not add the comment delimiters on the new lines.
> 
>     // Sample is a sample function with a very long comment. Sample is
> a sample function with a very long comment. Sample is a sample
> function with a very long comment. Sample is a sample function with a
> very long comment.
>     func Sample() {
> 
>     }
> 
> Becomes this:
> 
>     // Sample is a sample function with a very long comment. Sample is a
>     sample function with a very long comment. Sample is a sample function
>     with a very long comment. Sample is a sample function with a very long
>     comment.
>     func Sample() {
> 
>     }

Thanks.

Randy and Yuan, could you please look into this issue?

bug#69562: 29.2.50; go-ts-mode does not handle comments with fill-paragraph

[Dmitry Gutov]

On 05/03/2024 10:41, Ankit Gadiya via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> When fill-paragraph is invoked on the comment lines in the `go-ts-mode`
> buffer, it does not add the comment delimiters on the new lines.
> 
>      // Sample is a sample function with a very long comment. Sample is
> a sample function with a very long comment. Sample is a sample
> function with a very long comment. Sample is a sample function with a
> very long comment.
>      func Sample() {
> 
>      }

Does you example originally have one long commented line? Because when I 
try it that way, filling seems to work fine, comments are added on the 
new lines.

bug#69562: 29.2.50; go-ts-mode does not handle comments with fill-paragraph

[Dmitry Gutov]

Please keep the bug address in Cc. The bug tracker does not forward the 
messages to others or save them in history otherwise.

On 05/03/2024 16:22, Ankit Gadiya wrote:
>> Does you example originally have one long commented line? Because when I
>> try it that way, filling seems to work fine, comments are added on the
>> new lines.
> 
> Yes, I think the lines got wrapped in the mail but I had a long line. Admittedly
> that sample is specifically to showcase the issue but a more realistic scenario
> is when I already have multiline comments, I update it and want to re-fill
> it. Here also, it is clear that fill-paragraph does not respect the comment
> delimiter so it moves them just like regular characters.
> 
> (all comment lines start with // in case mail adds line breaks)
> 
>      // Sample is a sample function with a very long comment. Sample is a
>      // new details added to the comment sample function with a very
> long comment. Sample is a sample function
>      // with a very long comment. Sample is a sample function with a very long
>      // comment.
>      func Sample() {
> 
>      }
> 
> Becomes this
> 
>      // Sample is a sample function with a very long comment. Sample is a // new
>      details added to the comment sample function with a very long
> comment. Sample is
>      a sample function // with a very long comment. Sample is a sample
> function with
>      a very long // comment.
>      func Sample() {
> 
>      }

That's odd: here it becomes

   // Sample is a sample function with a very long comment. Sample is a
   // new details added to the comment sample function with a very long
   // comment. Sample is a sample function with a very long
   // comment. Sample is a sample function with a very long comment.
   func Sample() {
   	
   }

> I was able to reproduce it by running `emacs -Q` and manually enabling
> go-ts-mode in the go file. Please note that in the `go-mode` ELPA package it
> used to work as it defines its own fill-paragraph function. So possibly that
> function might be triggered for you if you have that configured?

I've also tried with 'emacs -Q', both the emacs-29 branch and master.

The version you included in the bug report (ae80192d97b8d0e54a94290) is 
very recent, so there can't be any commits that changed things since.

Are you testing in the same Emacs as the one you filed the bug report in?

> Today @stebalien@emacs.ch suggested to set adaptive-fill-regexp for go-ts-mode
> and that solved it for me (if this is useful).
> 
>      (setq-mode-local go-ts-mode adaptive-fill-regexp "[ \t]*//+[ \t]*")

TBH I'm not yet sure what the value of this variable should look like. 
But if I manage to reproduce the bug on my machine, this will be the 
next thing we can try, thanks.

bug#69562: 29.2.50; go-ts-mode does not handle comments with fill-paragraph

[Eli Zaretskii]

> Cc: 69562@debbugs.gnu.org
> Date: Tue, 5 Mar 2024 16:49:44 +0200
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 05/03/2024 16:22, Ankit Gadiya wrote:
> >> Does you example originally have one long commented line? Because when I
> >> try it that way, filling seems to work fine, comments are added on the
> >> new lines.
> > 
> > Yes, I think the lines got wrapped in the mail but I had a long line. Admittedly
> > that sample is specifically to showcase the issue but a more realistic scenario
> > is when I already have multiline comments, I update it and want to re-fill
> > it. Here also, it is clear that fill-paragraph does not respect the comment
> > delimiter so it moves them just like regular characters.
> > 
> > (all comment lines start with // in case mail adds line breaks)
> > 
> >      // Sample is a sample function with a very long comment. Sample is a
> >      // new details added to the comment sample function with a very
> > long comment. Sample is a sample function
> >      // with a very long comment. Sample is a sample function with a very long
> >      // comment.
> >      func Sample() {
> > 
> >      }
> > 
> > Becomes this
> > 
> >      // Sample is a sample function with a very long comment. Sample is a // new
> >      details added to the comment sample function with a very long
> > comment. Sample is
> >      a sample function // with a very long comment. Sample is a sample
> > function with
> >      a very long // comment.
> >      func Sample() {
> > 
> >      }
> 
> That's odd: here it becomes
> 
>    // Sample is a sample function with a very long comment. Sample is a
>    // new details added to the comment sample function with a very long
>    // comment. Sample is a sample function with a very long
>    // comment. Sample is a sample function with a very long comment.
>    func Sample() {

Could it be that you two use different versions of the grammar
library?

bug#69562: 29.2.50; go-ts-mode does not handle comments with fill-paragraph

[Dmitry Gutov]

On 05/03/2024 17:49, Eli Zaretskii wrote:
>> That's odd: here it becomes
>>
>>     // Sample is a sample function with a very long comment. Sample is a
>>     // new details added to the comment sample function with a very long
>>     // comment. Sample is a sample function with a very long
>>     // comment. Sample is a sample function with a very long comment.
>>     func Sample() {
> Could it be that you two use different versions of the grammar
> library?

I expect that it doesn't matter: we're not talking about a situation 
where some queries fail or some syntax errors.

go-ts-mode also doesn't set syntax-propertize-function (which is a 
mechanism of translating the grammar's syntax into something our generic 
code would look up. So it should only be affected by the settings we 
make in Lisp: the buffer syntax table and whatever other variables 
affect how filling happens.

Anyway, I've installed the latest version of the Go grammar now and 
don't see a change.

bug#69562: 29.2.50; go-ts-mode does not handle comments with fill-paragraph

[Ankit Gadiya via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Tue, 5 Mar 2024 at 20:19, Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> Please keep the bug address in Cc. The bug tracker does not forward the
> messages to others or save them in history otherwise.
>
Noted, thank you.

> On 05/03/2024 16:22, Ankit Gadiya wrote:
> >> Does you example originally have one long commented line? Because when I
> >> try it that way, filling seems to work fine, comments are added on the
> >> new lines.
> >
> > Yes, I think the lines got wrapped in the mail but I had a long line. Admittedly
> > that sample is specifically to showcase the issue but a more realistic scenario
> > is when I already have multiline comments, I update it and want to re-fill
> > it. Here also, it is clear that fill-paragraph does not respect the comment
> > delimiter so it moves them just like regular characters.
> >
> > (all comment lines start with // in case mail adds line breaks)
> >
> >      // Sample is a sample function with a very long comment. Sample is a
> >      // new details added to the comment sample function with a very
> > long comment. Sample is a sample function
> >      // with a very long comment. Sample is a sample function with a very long
> >      // comment.
> >      func Sample() {
> >
> >      }
> >
> > Becomes this
> >
> >      // Sample is a sample function with a very long comment. Sample is a // new
> >      details added to the comment sample function with a very long
> > comment. Sample is
> >      a sample function // with a very long comment. Sample is a sample
> > function with
> >      a very long // comment.
> >      func Sample() {
> >
> >      }
>
> That's odd: here it becomes
>
>    // Sample is a sample function with a very long comment. Sample is a
>    // new details added to the comment sample function with a very long
>    // comment. Sample is a sample function with a very long
>    // comment. Sample is a sample function with a very long comment.
>    func Sample() {
>
>    }
>
> > I was able to reproduce it by running `emacs -Q` and manually enabling
> > go-ts-mode in the go file. Please note that in the `go-mode` ELPA package it
> > used to work as it defines its own fill-paragraph function. So possibly that
> > function might be triggered for you if you have that configured?
>
> I've also tried with 'emacs -Q', both the emacs-29 branch and master.
>
> The version you included in the bug report (ae80192d97b8d0e54a94290) is
> very recent, so there can't be any commits that changed things since.
>
> Are you testing in the same Emacs as the one you filed the bug report in?
>

Yes, I only have one Emacs version installed on my system and I'm currently
tracking the emacs-29 branch (last compiled maybe a week ago). I tried enabling
`debug-on-entry` for the `fill-paragraph` function. Here is the
Backtrace if it's
useful. I think beyond this it goes into lower level buffer manipulation
functions.


  current-left-margin()
* move-to-left-margin()
* forward-paragraph(1)
* fill-forward-paragraph(1)
* fill-region(17 269 nil)
* #f(compiled-function (&optional justify region) "Fill paragraph at
or after point.\n\nIf JUSTIFY is non-nil (interactively, with prefix
argument), justify as well.\nIf `sentence-end-double-space' is
non-nil, then period followed by one\nspace does not end a sentence,
so don't break a line there.\nThe variable `fill-column' controls the
width for filling.\n\nIf `fill-paragraph-function' is non-nil, we call
it (passing our\nargument to it), and if it returns non-nil, we simply
return its value.\n\nIf `fill-paragraph-function' is nil, return the
`fill-prefix' used for filling.\n\nThe REGION argument is non-nil if
called interactively; in that\ncase, if Transient Mark mode is enabled
and the mark is active,\ncall `fill-region' to fill each of the
paragraphs in the active\nregion, instead of just filling the current
paragraph." (interactive #f(compiled-function () #<bytecode
0x11237b10c59aec8e>)) #<bytecode -0xb45f5d20aa35b1f>)(nil t)
* apply(#f(compiled-function (&optional justify region) "Fill
paragraph at or after point.\n\nIf JUSTIFY is non-nil (interactively,
with prefix argument), justify as well.\nIf
`sentence-end-double-space' is non-nil, then period followed by
one\nspace does not end a sentence, so don't break a line there.\nThe
variable `fill-column' controls the width for filling.\n\nIf
`fill-paragraph-function' is non-nil, we call it (passing
our\nargument to it), and if it returns non-nil, we simply return its
value.\n\nIf `fill-paragraph-function' is nil, return the
`fill-prefix' used for filling.\n\nThe REGION argument is non-nil if
called interactively; in that\ncase, if Transient Mark mode is enabled
and the mark is active,\ncall `fill-region' to fill each of the
paragraphs in the active\nregion, instead of just filling the current
paragraph." (interactive #f(compiled-function () #<bytecode
0x11237b10c59aec8e>)) #<bytecode -0xb45f5d20aa35b1f>) (nil t))
* fill-paragraph(nil t)
  funcall-interactively(fill-paragraph nil t)
  call-interactively(fill-paragraph record nil)
  command-execute(fill-paragraph record)
  execute-extended-command(nil "fill-paragraph" "fill-pa")
  funcall-interactively(execute-extended-command nil "fill-paragraph" "fill-pa")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

> > Today @stebalien@emacs.ch suggested to set adaptive-fill-regexp for go-ts-mode
> > and that solved it for me (if this is useful).
> >
> >      (setq-mode-local go-ts-mode adaptive-fill-regexp "[ \t]*//+[ \t]*")
>
> TBH I'm not yet sure what the value of this variable should look like.
> But if I manage to reproduce the bug on my machine, this will be the
> next thing we can try, thanks.

I also tried pulling the latest grammar for go and it's still
reproducing on my machine.

bug#69562: 29.2.50; go-ts-mode does not handle comments with fill-paragraph

[Dmitry Gutov]

On 06/03/2024 07:22, Ankit Gadiya wrote:

>> Are you testing in the same Emacs as the one you filed the bug report in?
>>
> 
> Yes, I only have one Emacs version installed on my system and I'm currently
> tracking the emacs-29 branch (last compiled maybe a week ago). I tried enabling
> `debug-on-entry` for the `fill-paragraph` function. Here is the
> Backtrace if it's
> useful. I think beyond this it goes into lower level buffer manipulation
> functions.
> 
> 
>    current-left-margin()
> * move-to-left-margin()
> * forward-paragraph(1)
> * fill-forward-paragraph(1)
> * fill-region(17 269 nil)

Sorry, I'm not noticing anything odd here.

>>> Today @stebalien@emacs.ch suggested to set adaptive-fill-regexp for go-ts-mode
>>> and that solved it for me (if this is useful).
>>>
>>>       (setq-mode-local go-ts-mode adaptive-fill-regexp "[ \t]*//+[ \t]*")
>>
>> TBH I'm not yet sure what the value of this variable should look like.
>> But if I manage to reproduce the bug on my machine, this will be the
>> next thing we can try, thanks.
> 
> I also tried pulling the latest grammar for go and it's still
> reproducing on my machine.

Could you confirm that your problem reproduces if you start Emacs as 
'emacs -Q'?

bug#69562: 29.2.50; go-ts-mode does not handle comments with fill-paragraph

[Ankit Gadiya via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Thu, 7 Mar 2024 at 07:27, Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> On 06/03/2024 07:22, Ankit Gadiya wrote:
>
> >> Are you testing in the same Emacs as the one you filed the bug report in?
> >>
> >
> > Yes, I only have one Emacs version installed on my system and I'm currently
> > tracking the emacs-29 branch (last compiled maybe a week ago). I tried enabling
> > `debug-on-entry` for the `fill-paragraph` function. Here is the
> > Backtrace if it's
> > useful. I think beyond this it goes into lower level buffer manipulation
> > functions.
> >
> >
> >    current-left-margin()
> > * move-to-left-margin()
> > * forward-paragraph(1)
> > * fill-forward-paragraph(1)
> > * fill-region(17 269 nil)
>
> Sorry, I'm not noticing anything odd here.
>
> >>> Today @stebalien@emacs.ch suggested to set adaptive-fill-regexp for go-ts-mode
> >>> and that solved it for me (if this is useful).
> >>>
> >>>       (setq-mode-local go-ts-mode adaptive-fill-regexp "[ \t]*//+[ \t]*")
> >>
> >> TBH I'm not yet sure what the value of this variable should look like.
> >> But if I manage to reproduce the bug on my machine, this will be the
> >> next thing we can try, thanks.
> >
> > I also tried pulling the latest grammar for go and it's still
> > reproducing on my machine.
>
> Could you confirm that your problem reproduces if you start Emacs as
> 'emacs -Q'?

I did notice some files from earlier versions of Emacs installation on my
machine. So just to rule it out, I cleared all the installations and re-compiled
and re-installed Emacs locally from the same commit again. Unfortunately, it is
still reproducing in the `emacs -Q` session.

This is the output of `emacs-version` inside `emacs -Q` session.

GNU Emacs 29.2.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
cairo version 1.16.0) of 2024-03-04

This is the partial output from the `report-emacs-bug` buffer in the same `emacs
-Q` session.

In GNU Emacs 29.2.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.16.0) of 2024-03-04 built on t14
Repository revision: ae80192d97b8d0e54a9429091cd84190bdbeb49e
Repository branch: emacs-29
System Description: Debian GNU/Linux 12 (bookworm)

I also tried fetching newer changes from the `emacs-29` branch and I'm
still able to reproduce it.

GNU Emacs 29.2.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
cairo version 1.16.0) of 2024-03-07

In GNU Emacs 29.2.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.16.0) of 2024-03-07 built on t14
Repository revision: 6e801077ae88e72dbad32015a083602062c4efe3
Repository branch: emacs-29
System Description: Debian GNU/Linux 12 (bookworm)

bug#69562: 29.2.50; go-ts-mode does not handle comments with fill-paragraph

[Eli Zaretskii]

> Date: Thu, 7 Mar 2024 14:28:52 +0530
> From:  Ankit Gadiya via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> On Thu, 7 Mar 2024 at 07:27, Dmitry Gutov <dmitry@gutov.dev> wrote:
> >
> > Could you confirm that your problem reproduces if you start Emacs as
> > 'emacs -Q'?
> 
> I did notice some files from earlier versions of Emacs installation on my
> machine. So just to rule it out, I cleared all the installations and re-compiled
> and re-installed Emacs locally from the same commit again. Unfortunately, it is
> still reproducing in the `emacs -Q` session.
> 
> This is the output of `emacs-version` inside `emacs -Q` session.
> 
> GNU Emacs 29.2.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
> cairo version 1.16.0) of 2024-03-04
> 
> This is the partial output from the `report-emacs-bug` buffer in the same `emacs
> -Q` session.
> 
> In GNU Emacs 29.2.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.38, cairo version 1.16.0) of 2024-03-04 built on t14
> Repository revision: ae80192d97b8d0e54a9429091cd84190bdbeb49e
> Repository branch: emacs-29
> System Description: Debian GNU/Linux 12 (bookworm)
> 
> I also tried fetching newer changes from the `emacs-29` branch and I'm
> still able to reproduce it.
> 
> GNU Emacs 29.2.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
> cairo version 1.16.0) of 2024-03-07
> 
> In GNU Emacs 29.2.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
>  3.24.38, cairo version 1.16.0) of 2024-03-07 built on t14
> Repository revision: 6e801077ae88e72dbad32015a083602062c4efe3
> Repository branch: emacs-29
> System Description: Debian GNU/Linux 12 (bookworm)

I note that this bug and its discussion lack the minimal reproducible
recipe, at least there's no complete recipe.  You start with showing
some incomplete snippet, and AFAICT never show anything more detailed.
So would you please post such a complete recipe, including:

  . a Go source file to visit
  . the sequence of Emacs command/keys to type in order to reproduce
    the problem, after visiting the above file
  . what you get in the buffer after these commands

You see, I fear that you and Dmitry are not doing the same in your
reproduction steps, and that is why Dmitry cannot reproduce the issue
you are complaining about.  Having a complete self-contained recipe
with all the details will go a long way towards eliminating the
differences between what you see.  (It will also allow me to try
reproducing this, as currently I have no idea what to type in the
buffer under go-ts-mode to begin with.)

Thanks.

bug#69562: 29.2.50; go-ts-mode does not handle comments with fill-paragraph

[Ankit Gadiya via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Thu, 7 Mar 2024 at 15:08, Eli Zaretskii <eliz@gnu.org> wrote:

> I note that this bug and its discussion lack the minimal reproducible
> recipe, at least there's no complete recipe.  You start with showing
> some incomplete snippet, and AFAICT never show anything more detailed.
> So would you please post such a complete recipe, including:
>
>   . a Go source file to visit
>   . the sequence of Emacs command/keys to type in order to reproduce
>     the problem, after visiting the above file
>   . what you get in the buffer after these commands
>
> You see, I fear that you and Dmitry are not doing the same in your
> reproduction steps, and that is why Dmitry cannot reproduce the issue
> you are complaining about.  Having a complete self-contained recipe
> with all the details will go a long way towards eliminating the
> differences between what you see.  (It will also allow me to try
> reproducing this, as currently I have no idea what to type in the
> buffer under go-ts-mode to begin with.)
>
> Thanks.

In retrospect that makes sense, thank you. In fact I was able to figure
out the issue with reproduction, as I followed the advice of recording exact
command sequence.


Following is the full Go file to reproduce the issue:

```
package main

// This is the docstring for the main function that extends beyond
fill-column value.
func main() {
}
```

Following is the exact steps to reproduce the issue:

* emacs -Q main.go
* M-x go-ts-mode
* Highlight the full docstring line with Mouse.
* M-x fill-paragraph

This is the result in the buffer after executing the above steps:

```
package main

// This is the docstring for the main function that extends beyond
fill-column value.
func main() {
}
```

I think the difference between Dmitry and me was that I was highlighting the
docstring and Dmitry was not. I tried the same steps but without highlighting
just with the cursor somewhere in the docstring line and it worked as expected.
I believe this is what Dmitry observed as well. This is the content of my buffer
without highlighting the step.

```
package main

// This is the docstring for the main function that extends beyond
// fill-column value.
func main() {
}
```

(Please don't mind the repeated email, I forgot to CC the Bugtracker.)

On Thu, 7 Mar 2024 at 15:08, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Date: Thu, 7 Mar 2024 14:28:52 +0530
> > From:  Ankit Gadiya via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> >
> > On Thu, 7 Mar 2024 at 07:27, Dmitry Gutov <dmitry@gutov.dev> wrote:
> > >
> > > Could you confirm that your problem reproduces if you start Emacs as
> > > 'emacs -Q'?
> >
> > I did notice some files from earlier versions of Emacs installation on my
> > machine. So just to rule it out, I cleared all the installations and re-compiled
> > and re-installed Emacs locally from the same commit again. Unfortunately, it is
> > still reproducing in the `emacs -Q` session.
> >
> > This is the output of `emacs-version` inside `emacs -Q` session.
> >
> > GNU Emacs 29.2.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
> > cairo version 1.16.0) of 2024-03-04
> >
> > This is the partial output from the `report-emacs-bug` buffer in the same `emacs
> > -Q` session.
> >
> > In GNU Emacs 29.2.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version
> > 3.24.38, cairo version 1.16.0) of 2024-03-04 built on t14
> > Repository revision: ae80192d97b8d0e54a9429091cd84190bdbeb49e
> > Repository branch: emacs-29
> > System Description: Debian GNU/Linux 12 (bookworm)
> >
> > I also tried fetching newer changes from the `emacs-29` branch and I'm
> > still able to reproduce it.
> >
> > GNU Emacs 29.2.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
> > cairo version 1.16.0) of 2024-03-07
> >
> > In GNU Emacs 29.2.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> >  3.24.38, cairo version 1.16.0) of 2024-03-07 built on t14
> > Repository revision: 6e801077ae88e72dbad32015a083602062c4efe3
> > Repository branch: emacs-29
> > System Description: Debian GNU/Linux 12 (bookworm)
>
> I note that this bug and its discussion lack the minimal reproducible
> recipe, at least there's no complete recipe.  You start with showing
> some incomplete snippet, and AFAICT never show anything more detailed.
> So would you please post such a complete recipe, including:
>
>   . a Go source file to visit
>   . the sequence of Emacs command/keys to type in order to reproduce
>     the problem, after visiting the above file
>   . what you get in the buffer after these commands
>
> You see, I fear that you and Dmitry are not doing the same in your
> reproduction steps, and that is why Dmitry cannot reproduce the issue
> you are complaining about.  Having a complete self-contained recipe
> with all the details will go a long way towards eliminating the
> differences between what you see.  (It will also allow me to try
> reproducing this, as currently I have no idea what to type in the
> buffer under go-ts-mode to begin with.)
>
> Thanks.

bug#69562: 29.2.50; go-ts-mode does not handle comments with fill-paragraph

[Eli Zaretskii]

> From: Ankit Gadiya <ankit@argp.in>
> Date: Thu, 7 Mar 2024 15:45:02 +0530
> 
> * emacs -Q main.go
> * M-x go-ts-mode
> * Highlight the full docstring line with Mouse.
> * M-x fill-paragraph

Thanks.  Now it's clear.

> I think the difference between Dmitry and me was that I was highlighting the
> docstring and Dmitry was not. I tried the same steps but without highlighting
> just with the cursor somewhere in the docstring line and it worked as expected.
> I believe this is what Dmitry observed as well. This is the content of my buffer
> without highlighting the step.

Well, fill-paragraph is documented to behave differently when the
region is active.  Did you have any special reason to highlight the
comment, instead of just typing M-q inside the comment?

bug#69562: 29.2.50; go-ts-mode does not handle comments with fill-paragraph

[Ankit Gadiya via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Thu, 7 Mar 2024 at 16:25, Eli Zaretskii <eliz@gnu.org> wrote:
>
> Well, fill-paragraph is documented to behave differently when the
> region is active.  Did you have any special reason to highlight the
> comment, instead of just typing M-q inside the comment?

No special reason. I guess it's an old vim muscle memory that stuck with me. But
M-q is much easier, no need to select first. It is also behaving correctly so
I'll use this from now on.

Thanks Eli and Dmitry for helping me resolve the issue.

bug#69562: 29.2.50; go-ts-mode does not handle comments with fill-paragraph

[Dmitry Gutov]

On 07/03/2024 13:13, Ankit Gadiya wrote:
> On Thu, 7 Mar 2024 at 16:25, Eli Zaretskii<eliz@gnu.org>  wrote:
>> Well, fill-paragraph is documented to behave differently when the
>> region is active.  Did you have any special reason to highlight the
>> comment, instead of just typing M-q inside the comment?
> No special reason. I guess it's an old vim muscle memory that stuck with me. But
> M-q is much easier, no need to select first. It is also behaving correctly so
> I'll use this from now on.
> 
> Thanks Eli and Dmitry for helping me resolve the issue.

No problem! Then I'm closing this report.