There was recently a great tidy-up commit in the Emacs master
branch (commit 1f29ee2d21b57e81a28550a1b31bc8a39406d17b), which removed
a lot legacy stuff. Dired's dired-pop-to-buffer function was among them.
However dired+ plus seems to heavily depend on it, so for now, I've
simply copied the source of the function from the legacy cleanup commit.
It sometimes causes a long lock-up of Emacs. I believe this is due to a
known issue where the mode can cause excessive garbage collection while
scrolling, combined with my use of gcmh which prevents GC while actively
using Emacs.
Hence my theory is that pixel scrolling is causing tons of memory to be
consumed, but gcmh prevents the GC from running, until it hits a tipping
point where it GCs hundreds of megabytes of memory.
Or, that's my theory at least :P
The field_identifier type was recently removed from tree-sitter-go here:
https://github.com/tree-sitter/tree-sitter-go/pull/71
This means that struct keys are no longer syntax highlighted as
properties, which I dislike. Hence this new query targets the first
element of a key/value pair, and marks the first element as a @property
if it contains an identifier.
I'm not sure if this undoes the goal of removing the field_identifier,
but for now, it resolves my personal annoyance of struct keys not be
highlighted as properties when creating a new instance of the struct.
In languages that uses "{" for blocks, accepting a Copilot completion
that ends with "{", causing a structural imbalance, which
structural-based packages like smartparens does not like and causes
headaches.
With the custom accept function, trailing "{" chars along with any
whitespace before it, are ignored from Copilot completion. An exception
is made for if the removal of trailing "{" and whitespace yields an
empty completion, in which case the completion is accepted as is.
This is a more generic and robust fix for flx-rs not behaving correctly
when given consults extra metadata bytes as part of the input candidate.
This should now work with any candidate provided by consult, not just
those that come from the consult-buffer command.
On macOS when running Emacs in a terminal, the ns-system-appearance
variable is defined, but set to nil. We now cater for that, and simply
default to loading the dark theme.
Emacs will now change theme automatically on macOS when system
appearance is changed between light/dark. And also sets the appropriate
theme on startup too.
Caddy can now format Caddyfiles with the "caddy fmt" command, so we use
reformatter to create a format-on-save mode for Caddyfiles.
Also there's no need for the weird whitespace-mode workaround, as we now
use tab indentation in Caddyfiles, since that's what "caddy fmt"
produces.
When lsp-mode is active, it tries to ensure it's own
lsp-completion-at-point function is listed before any other functions in
completion-at-point-functions.
This however prevents completions for yasnippet snippets and
files/folders from working, as completion never moved on beyond
lsp-completion-at-point. Previously I had managed to fix this by using
the DEPTH option of add-hook to get siren-yasnippet-capf and cape-file
to run before lsp-completion-at-point.
But it seems lsp-mode has changed from using add-hook to a more custom
method of always ensuring lsp-completion-at-point is always first on the
list. Hence we need to the same using the new siren-prepend macro I
recently added.
Remove nearly all custom behavior with consult.
The separate groups for project and non-project buffers within
consult-buffer weren't as useful after switching away from orderless to
fussy for completion scoring, as non-project buffers were often sorted
higher than project buffers.
And there's no need for the custom siren-consult-projectile-buffer
function, as consult-project-buffer does the same thing when configured
to use projectile's root path function.
It seems the string candidates produced by consult-buffer have some
extra non-printable bytes appended at the end. These bytes makes flx-rs
not match against the candidate properly.
Consult does add a text property to the candidate string called 'buffer,
which contains the original buffer name.
So for now, we advice the flx-rs-score function and attempt to the
extract the buffer text property from the input candidate and use that
instead. If the candidate has no such text property, we use it as is.
It seems the fzf-native scoring method can get slow and laggy over
time. It seems the flx-rs method does not, and is overall a bit faster.
However, flx-rs doesn't give exact matches as high of a score as
fzf-native, so scoring might be a bit different than I'm used to. Time
will tell if I'll find it annoying enough to switch back to fzf-native.
Also switch from orderless to fussy's all-completions backed filtering
method. This yields a noticeable improvement in speed, but it does not
support multiple search terms separated by space like orderless does.
Another potential habit I will need to adjust.
