bug#60397: 29.0.60; c++-ts-mode could report better defun names

bug#60397: 29.0.60; c++-ts-mode could report better defun names

[Knut Anders Hatlen]

The defun names reported by c++-ts-mode could still need a couple of
improvements:

1) In a buffer with c++-ts-mode and which-function-mode enabled, and
this content:

struct S {
  int f1(int x) {
    return x + 1;
  }
  int g1(int x);
};

int S::g1(int x) {
  return x + 1;
}

Inside the inline f1 function definition, which-function-mode shows
"S.f1". But inside the out-of-line g1 function definition, it shows
"n/a" instead of "S.g1". (Not limited to structs. Classes have the same
problem.)

2) Namespaces are not handled. Given this content:

namespace n {
int f1(int x) {
  return x + 1;
}
}

namespace {
int f2(int x) {
  return x + 1;
}
}

Inside the f1 and f2 function bodies, which-function-mode shows "f1" and
"f2", respectively. It would be better if it showed "n.f1" for the
former, and perhaps something like "(anonymous).f2" for the latter.


In GNU Emacs 29.0.60 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.35, cairo version 1.16.0) of 2022-12-29 built on dell
Repository revision: 909091d7578b7225601b202fb9257dedae879e9a
Repository branch: emacs-29
System Description: Debian GNU/Linux bookworm/sid

Configured using:
 'configure --with-json --with-xml2 --with-modules
 --prefix=/usr/local/stow/emacs --with-pgtk --without-x
 --with-native-compilation --with-tree-sitter'

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

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

Major mode: C++

Minor modes in effect:
  shell-dirtrack-mode: t
  treesit-explore-mode: t
  flyspell-mode: t
  hl-line-mode: t
  electric-pair-mode: t
  display-line-numbers-mode: t
  elide-head-mode: t
  flymake-mode: t
  winner-mode: t
  windmove-mode: t
  server-mode: t
  which-function-mode: t
  savehist-mode: t
  save-place-mode: t
  repeat-mode: t
  recentf-mode: t
  minibuffer-depth-indicate-mode: t
  marginalia-mode: t
  global-so-long-mode: t
  global-auto-revert-mode: t
  dynamic-completion-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tab-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/kah/.emacs.d/elpa/29/transient-0.3.7/transient hides /usr/local/stow/emacs/share/emacs/29.0.60/lisp/transient

Features:
(shadow sort mail-extr emacsbug message yank-media puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils shell pcomplete cus-start pulse color noutline
outline jka-compr find-func orderless cl-print cc-langs cc-mode cc-fonts
cc-guess cc-menus cc-cmds help-fns radix-tree cc-styles cc-align
cc-engine cc-vars cc-defs mule-util etags fileloop generator xref
misearch multi-isearch vc-git diff-mode easy-mmode vc-dispatcher
c-ts-mode treesit add-log comp comp-cstr flyspell ispell hl-line
elec-pair display-line-numbers elide-head time-date checkdoc lisp-mnt
flymake-proc flymake project compile text-property-search comint
ansi-osc ansi-color warnings thingatpt cus-edit pp rx winner ring
windmove disp-table server icons cl-extra help-mode which-func imenu
savehist saveplace repeat recentf tree-widget wid-edit mb-depth
marginalia magit-autorevert magit-git magit-section magit-utils crm dash
so-long autorevert filenotify completion cus-load embark-autoloads
boxquote-autoloads slime-autoloads marginalia-autoloads
orderless-autoloads info 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 system-font-setting font-render-setting cairo
gtk pgtk lcms2 multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 349779 18327)
 (symbols 48 18948 0)
 (strings 32 98089 2630)
 (string-bytes 1 3434581)
 (vectors 16 60037)
 (vector-slots 8 864811 38865)
 (floats 8 312 302)
 (intervals 56 3318 0)
 (buffers 984 24))

-- 
Knut Anders

bug#60397: 29.0.60; c++-ts-mode could report better defun names

[Yuan Fu]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> The defun names reported by c++-ts-mode could still need a couple of
> improvements:
>
> 1) In a buffer with c++-ts-mode and which-function-mode enabled, and
> this content:
>
> struct S {
>   int f1(int x) {
>     return x + 1;
>   }
>   int g1(int x);
> };
>
> int S::g1(int x) {
>   return x + 1;
> }
>
> Inside the inline f1 function definition, which-function-mode shows
> "S.f1". But inside the out-of-line g1 function definition, it shows
> "n/a" instead of "S.g1". (Not limited to structs. Classes have the same
> problem.)
>
> 2) Namespaces are not handled. Given this content:
>
> namespace n {
> int f1(int x) {
>   return x + 1;
> }
> }
>
> namespace {
> int f2(int x) {
>   return x + 1;
> }
> }
>
> Inside the f1 and f2 function bodies, which-function-mode shows "f1" and
> "f2", respectively. It would be better if it showed "n.f1" for the
> former, and perhaps something like "(anonymous).f2" for the latter.

Thanks for the report. I’ll work on this :-)

Yuan

bug#60397: 29.0.60; c++-ts-mode could report better defun names

[Yuan Fu]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> The defun names reported by c++-ts-mode could still need a couple of
> improvements:
>
> 1) In a buffer with c++-ts-mode and which-function-mode enabled, and
> this content:
>
> struct S {
>   int f1(int x) {
>     return x + 1;
>   }
>   int g1(int x);
> };
>
> int S::g1(int x) {
>   return x + 1;
> }
>
> Inside the inline f1 function definition, which-function-mode shows
> "S.f1". But inside the out-of-line g1 function definition, it shows
> "n/a" instead of "S.g1". (Not limited to structs. Classes have the same
> problem.)

Now the second function is displayed as S::g1.

> 2) Namespaces are not handled. Given this content:
>
> namespace n {
> int f1(int x) {
>   return x + 1;
> }
> }
>
> namespace {
> int f2(int x) {
>   return x + 1;
> }
> }
>
> Inside the f1 and f2 function bodies, which-function-mode shows "f1" and
> "f2", respectively. It would be better if it showed "n.f1" for the
> former, and perhaps something like "(anonymous).f2" for the latter.

Now the first function is shown as n.f1, the second is shown as f2.
Making it (anonymous).f2 isn’t necessarily better than f2 IMO, and
requires some non-trivial change to the current code, so I didn’t do it.

Yuan

bug#60397: 29.0.60; c++-ts-mode could report better defun names

[Knut Anders Hatlen]

Yuan Fu <casouri@gmail.com> writes:

> Knut Anders Hatlen <kahatlen@gmail.com> writes:
>
>> The defun names reported by c++-ts-mode could still need a couple of
>> improvements:
>>
>> 1) In a buffer with c++-ts-mode and which-function-mode enabled, and
>> this content:
>>
>> struct S {
>>   int f1(int x) {
>>     return x + 1;
>>   }
>>   int g1(int x);
>> };
>>
>> int S::g1(int x) {
>>   return x + 1;
>> }
>>
>> Inside the inline f1 function definition, which-function-mode shows
>> "S.f1". But inside the out-of-line g1 function definition, it shows
>> "n/a" instead of "S.g1". (Not limited to structs. Classes have the same
>> problem.)
>
> Now the second function is displayed as S::g1.

Looks good now. Classes seem to be handled fine too.

>> 2) Namespaces are not handled. Given this content:
>>
>> namespace n {
>> int f1(int x) {
>>   return x + 1;
>> }
>> }
>>
>> namespace {
>> int f2(int x) {
>>   return x + 1;
>> }
>> }
>>
>> Inside the f1 and f2 function bodies, which-function-mode shows "f1" and
>> "f2", respectively. It would be better if it showed "n.f1" for the
>> former, and perhaps something like "(anonymous).f2" for the latter.
>
> Now the first function is shown as n.f1, the second is shown as f2.
> Making it (anonymous).f2 isn’t necessarily better than f2 IMO, and
> requires some non-trivial change to the current code, so I didn’t do it.

Fair enough. Thanks!

-- 
Knut Anders

bug#60397: 29.0.60; c++-ts-mode could report better defun names

[Yuan Fu]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> Yuan Fu <casouri@gmail.com> writes:
>
>> Knut Anders Hatlen <kahatlen@gmail.com> writes:
>>
>>> The defun names reported by c++-ts-mode could still need a couple of
>>> improvements:
>>>
>>> 1) In a buffer with c++-ts-mode and which-function-mode enabled, and
>>> this content:
>>>
>>> struct S {
>>>   int f1(int x) {
>>>     return x + 1;
>>>   }
>>>   int g1(int x);
>>> };
>>>
>>> int S::g1(int x) {
>>>   return x + 1;
>>> }
>>>
>>> Inside the inline f1 function definition, which-function-mode shows
>>> "S.f1". But inside the out-of-line g1 function definition, it shows
>>> "n/a" instead of "S.g1". (Not limited to structs. Classes have the same
>>> problem.)
>>
>> Now the second function is displayed as S::g1.
>
> Looks good now. Classes seem to be handled fine too.
>
>>> 2) Namespaces are not handled. Given this content:
>>>
>>> namespace n {
>>> int f1(int x) {
>>>   return x + 1;
>>> }
>>> }
>>>
>>> namespace {
>>> int f2(int x) {
>>>   return x + 1;
>>> }
>>> }
>>>
>>> Inside the f1 and f2 function bodies, which-function-mode shows "f1" and
>>> "f2", respectively. It would be better if it showed "n.f1" for the
>>> former, and perhaps something like "(anonymous).f2" for the latter.
>>
>> Now the first function is shown as n.f1, the second is shown as f2.
>> Making it (anonymous).f2 isn’t necessarily better than f2 IMO, and
>> requires some non-trivial change to the current code, so I didn’t do it.
>
> Fair enough. Thanks!

Closing this since I think the problem’s fixed :-)

Yuan