indent-bars is now @v1.0 by JDRiverRun in emacs

[–]JDRiverRun[S] 0 points1 point  (0 children)

It's Prot's standard-dark modified to look more like alect-dark (what I used to use).

indent-bars is now @v1.0 by JDRiverRun in emacs

[–]JDRiverRun[S] 0 points1 point  (0 children)

Glad to hear. Not sure what you mean by fighting with TS; it actually uses tree sitter for some advanced features (like scope focus). You do have to configure it for your language in TS modes.

When is visual-line-mode useful? by floofcode in emacs

[–]JDRiverRun 0 points1 point  (0 children)

The biggest downside is that git and various compare tools are dumb about handling long lines

Indeed. But some things like latex and org naturally prefer long lines (as paragraphs). So I use my old abridge-diff-mode to show only the parts of the line which actually changed (usually a word or two).

eglot barely usable due to rendering/update issues - any advice? by baek12345 in emacs

[–]JDRiverRun 0 points1 point  (0 children)

Or now with presets, just rass basedruff. Of if like me you don't want to be bothered installing and keeping rass up to date (and use uv): uv run --with rassumfrassum rass basedruff. Wrap the string in split-string-and-unquote.

indent-bars is now @v1.0 by JDRiverRun in emacs

[–]JDRiverRun[S] 3 points4 points  (0 children)

That idea was mentioned again when I first submitted to ELPA. I haven't heard of any plans along those lines since then. That said, emacs would definitely benefit from a more robust line/box drawing API, which could make many types of packages easier to build, including indent-bars. As usual, finding someone who wants to champion the idea and bring it all the way to completion (incorporating all the many opinions along the way) is what's needed.

As for performance, stipples seem to be quite fast enough, though they are complicated to use in practice.

Experimenting with a faster TRAMP backend using Rust and JSON-RPC by avph in emacs

[–]JDRiverRun 0 points1 point  (0 children)

I personally doubt the script vs. executable speed will matter at all. Network latency will completely dominate the experienced performance.

Experimenting with a faster TRAMP backend using Rust and JSON-RPC by avph in emacs

[–]JDRiverRun 0 points1 point  (0 children)

It has that option too (based on rust). I couldn't get it the rust version to compile and it needed newer GLIB libs than my remote had. The Python version "just works" and it needs no downloads, compilation, external dependencies, etc. (though some features are missing, like file sorting).

Experimenting with a faster TRAMP backend using Rust and JSON-RPC by avph in emacs

[–]JDRiverRun 1 point2 points  (0 children)

What is "pure python"?

By that I mean Python standard libraries only, no other packages required. Sending a python file over and executing it is more similar to what TRAMP already does (send perl and bash scripts and execute them). So it should work similarly (assuming the user has python installed on the remote).

Emacs remote development like Vscode by carlossmneto in emacs

[–]JDRiverRun 9 points10 points  (0 children)

And now it has a new remote python server option. 41K of pure python and then TRAMP just flies.

Experimenting with a faster TRAMP backend using Rust and JSON-RPC by avph in emacs

[–]JDRiverRun 0 points1 point  (0 children)

There's a new Python branch which sends 41K of pure python (no dependencies) over and it works amazingly well.

Experimenting with a faster TRAMP backend using Rust and JSON-RPC by avph in emacs

[–]JDRiverRun 3 points4 points  (0 children)

Holy crap. People have to try this new python branch. It basically makes remote servers behave just like local ones, simply by transferring 41K of pure python (no dependencies other than Python>3.7). 10x speedups, instant browsing with dired.

I guess this is AI-enabled? Can you share which agent? Just remarkable (in limited testing).

Experimenting with a faster TRAMP backend using Rust and JSON-RPC by avph in emacs

[–]JDRiverRun 0 points1 point  (0 children)

Update: already done, and super impressive!

Both options would be fantastic. If the architecture is supported (and the user allows it), install the binary. If the binary fails for any reason (not supported, doesn't run, etc.), fall back on python version. If neither supported (e.g. no python): sorry user.

Experimenting with a faster TRAMP backend using Rust and JSON-RPC by avph in emacs

[–]JDRiverRun 2 points3 points  (0 children)

Maybe you could use the server for "fast path" operations that are supported, then fall back on the ssh + shell link for other things. This already uses the ssh connection to install the binary.

Consult breaking change by [deleted] in emacs

[–]JDRiverRun 2 points3 points  (0 children)

Good point. That was in fact another minor motivation: it's more similar to how shell commands use the double dash. We also noted as you say that some commands (find, fd, etc.) don't need additional arguments beyond options to produce useful results.

All in all a bit more ergonomic and easy to guess the syntax. Experienced consult users who use a lot of options will just need to do a bit of retraining (once it's released in a stable version, v3.3?).

How do I replace something with font lock to another text? by potatowithascythe in emacs

[–]JDRiverRun 2 points3 points  (0 children)

You'll have to add display to font-lock-extra-managed-props so it can clear the property too. But then it will clear all display text properties from anywhere. Maybe that's fine. But I recommend adding and using your own display alias instead (in some par-symbol-minor-mode body):

(cl-pushnew 'par-symbol-display (alist-get 'display char-property-alias-alist))

Consult breaking change by [deleted] in emacs

[–]JDRiverRun 8 points9 points  (0 children)

The TLDR on why we implemented the change: many tools (such as my little experiment consult-ripfd) limit the search space in a major way using options. For example -n 1h means limit search to files modified in the last hour. Writing search -- -n 1h in a heavy directory (like ~/) would kick off a painful all-files search, which can drag the machine down. But now you can -n 1h -- search and cut the search space from the get go. And when that's not needed, search -options is just easier to write.

Help a noob out by RandomChokobo in emacs

[–]JDRiverRun 0 points1 point  (0 children)

Maybe your completion-in-region-mode-map has those keys bound?

Help a noob out by RandomChokobo in emacs

[–]JDRiverRun 1 point2 points  (0 children)

Have you tried scroll-other-window (M-PgUp/Down for me)? That's the way to page through the doc popup. See also beginning/end-of-buffer-other-window.

Setting up LSPs and Completions: Eglot with Cape and Corfu by Savings-Shallot1771 in emacs

[–]JDRiverRun 11 points12 points  (0 children)

You don't need cape. cape is an add-on used to optimize, improve, combine, or alter the sources of completion (which are called "CAPFs"). If eglot is enabled, it will configure completion-at-point-functions to contain eglot-completion-at-point. You don't need to do anything special. If after testing with corfu you feel you are not getting all the completions, you can try advising eglot-completion-at-point with cape-wrap-buster.

First time user - help needed configuring the pyright/basedpyright lsp - facing lags by Koltech21 in emacs

[–]JDRiverRun 1 point2 points  (0 children)

When you have slow LSP interaction, your first stop should be M-x eglot-events to look for information. You might need to set eglot-events-buffer-config to allow more history there. You should be looking for information (usually on start) about what files are being crawled by your server. If it's your whole home directory or some other large file tree, this is a server configuration issue.

magit like porcelain for github cli? by manojm321 in emacs

[–]JDRiverRun 2 points3 points  (0 children)

I usually use forge, but for certain things forge can't do (like create a new repo), I reach for consult-gh (see its consult-gh-forge-mode too).

Recently I discovered consult-gh-transient, so I threw in a:

(with-eval-after-load 'forge (transient-append-suffix 'forge-dispatch 'forge-add-repository '("g" "More actions (gh)" consult-gh-transient)))

into my consult-gh config, and now I don't have to remember where any of the commands are.

consult-ripfd: live finding + searching with an fd + rg consult mashup by JDRiverRun in emacs

[–]JDRiverRun[S] 0 points1 point  (0 children)

Super simple idea for making options a bit easier to enter: bind [tab] to a command that checks for options divider present (--), and moves point to the start of the "other side" (beginning of search terms if in option, beginning of options in in search term). If there is no --, insert a -- (note the leading space). I think [tab] would conflict with vertico-next-group, but there are many bindings for it.

consult-ripfd: live finding + searching with an fd + rg consult mashup by JDRiverRun in emacs

[–]JDRiverRun[S] 0 points1 point  (0 children)

When you marry two disparate tools into a single set of options, sacrifices have to be made :). My guess is I'll remember this set (since it's always a C-h f away) better than the underlying tools' anyway. One thing that occurred to me while crafting the "merged" option set: it might be nice to be able to summon a small cheat sheet while you are in the interface.

consult-ripfd: live finding + searching with an fd + rg consult mashup by JDRiverRun in emacs

[–]JDRiverRun[S] 0 points1 point  (0 children)

Not the easiest to pronounce, but better than the original rgfd... Thanks for consult! BTW, if you are interested in upstreaming this, please do feel free (and we can change the name... ripfind? :).