mickeyp

So your complaint is about the non-default behavior? The level 3 was chosen as default explicitly to avoid the abundance of color where it's not really needed.

That's not what I wrote.

I don't see that "everything is the same shade", even with level 4. There are problems - like the variable matcher in particular (which is not useful IMO, but should at least use a different face).

The variable matcher, indeed, is the one I was talking about...

Here's a patch fixing the one problem I found

I'm glad we're on the same page.

That's a misinterpretation of my argument. I said monochromacity: that at the highest level, many disparate node types are font locked with the same face. Try it in Python. Everything is the same shade of whatever your variable name face is.

The problem is monochromacity. The font lock rules in a lot of the TS modes are... not always thought through. Ramp up python-ts-mode's font lock level to the maximum and most of everything is dyed the same colour. It's frustrating and I have had to muck around with treesit-font-lock-feature-list to selectively unpick the chaff from the grist. And it's not exactly easy changing it either: if you're new to elisp, or not fluent in the extremely awkward interface for changing this stuff, you'll have to look up how someone else has done it.

It's not even customizable, so you can't just click around and change it either.

Use a keyboard macro. No need for elisp:

https://www.masteringemacs.org/article/keyboard-macros-are-misunderstood

It does not have indentation at all. It should, but for reasons, it does not. Furthermore, for reasons that strain credulity, it will highlight ERROR nodes with a font lock face, causing endless graphical flashing as you leave your tree-sitter tree in a brief error-state as you type.

I recommend you ditch it unless you have a good reason for using it. The third-party yaml-mode.el is excellent.

You can drag files into many different places and have the drop action do different things. The compose email interface will automatically attach the dragged files as attachments.

Another minor point: if you use VMWare workstation as I do, you can drag files from the host straight into an Emacs buffer. I'm sure this also works for other hypervisors like Virtualbox.

Does it work with TRAMP? That'd be the ace in the hole.

No it isn't. DAP can definitely do this. It can even attach to a PID.

This is what I complained about it in my post: I could not get dape to work with this.

Did you use the debugpy adapter with the following configuration from the readme?

Of course.

DAP has some issues as well, extremely loose specification, the overwhelming majority is tested with vscode and a lot of cruff is hidden inside in the plugins for vscode. I was close to putting it in the bin at several points.

Yes, indeed.

I saw this on the mailing list, and it looks very promising. It's always nice to have more choice in this space. I did also play around with it quite a bit and I do have some feedback to the author (and anybody who would want to play around with it):

Expect to debug the dape debugger. I wanted to check it out with a bespoke software project I'm building for a client and I figured this would be a fine way to test it. I've never played around with DAP and friends before (ipdb is fine for me, thanks) so it was a bit of a learning curve as the documentation is sparse, even moreso the magic flags and parameters you need to paw off to dape and -- down the road -- the actual DAP client/server. This... this is bad and needs a lot more handholding. I struggled, and I've done Python and Emacs for two decades. And I simply could not, no matter what I did, get the microsoft adapter and dape.el to play nice with the client-server attachment facility in the dape protocol, and dape.el didn't help me much here in terms of why

nor, for that matter, did the Microsoft-provided DAP debug adapter you use. Error handling in the DAP client/server seems poor or not designed, surprise surprise, for anything but VSCode or whatever.

I could, after a fair bit of wrangling, get it to work by starting the process for me and then have it hook into whatever it needs to do to work. That does seem to work. I never did get attachment to work, rendering it useless in a webapp or even for my usual workflow of throwing down a breakpoint() and having ipdb (or whatever) pick up from there.

Other problems I've encountered is a weird way that it stores configuration options once you've told dape to connect to stuff. The UX around that needs work before it's plug-and-play.

The other criticism is that it does not, and this might be a DAP thing and not a dape thing, work with the default GDB-like shorthands (c for continue, etc.). Maybe that's just how it is; but it's little things like that.

Being able to see all the relevant variables, a la the GDB multi-window support in Emacs, is also nice. Which makes me wonder why we can't just reuse that, as there's surely man-years of work to make that stable and effective.

Still, an impressive effort, and I'm surprised how little code dape actually is. I'm sure it'll improve quickly once people start giving feedback.

Welcome back! Here's another fun way of doing it:

https://www.masteringemacs.org/article/inserting-emoji-input-methods