bug#64830: 30.0.50 C++ treesitter mode no coloration

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Mon, Aug 26, 2024 at 20:51:00 +0300, Eli Zaretskii wrote:
> > Date: Mon, 26 Aug 2024 17:25:34 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>, 64830@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > Ah, that's it!  I didn't know the grammar library in use was the one in
> > ~/.emacs/tree-sitter.  There, I've got 

> >     -rwxr-xr-x 1 acm acm 2319888 Jan 19  2023 libtree-sitter-cpp.so

> > , which is very old.  In my /usr/lib64, I've got

> >     lrwxrwxrwx 1 root root      26 Aug  4 18:13 /usr/lib64/libtree-sitter-cpp.so.0 -> libtree-sitter-cpp.so.0.14
> >     lrwxrwxrwx 1 root root      23 Aug  4 18:13 /usr/lib64/libtree-sitter-cpp.so -> libtree-sitter-cpp.so.0
> >     -rwxr-xr-x 1 root root 3175712 Aug  4 18:13 /usr/lib64/libtree-sitter-cpp.so.0.14

> > Why do we have this extra complication with ~/.emacs.d/tree-sitter as a
> > location for libraries?  In GNU/Linux distributions (well, in Gentoo at
> > any rate), newly downloaded libraries are put into /usr/lib64, so that
> > anybody naively updating a grammar library is going to have it masked out
> > by the old one still in ~/.emacs.d/tree-sitter.  Maybe I don't understand
> > the library mechanism as well as I ought to.

> We support grammar libraries in ~/.emacs.d/tree-sitter so that users
> could easily install versions of grammar libraries different from what
> their sysadmins decide to install.

Ah, OK.  Seems like a good reason.

How about outputting a message looking something like this:

    Loading /home/acm/.emacs.d/tree-sitter/libtree-sitter.so ....Done

..  This wouldn't get in the way, yet might well prevent some of the
problems I've been having over the last few days.

-- 
Alan Mackenzie (Nuremberg, Germany).