Tab should only be changed for evil users in insert mode, since they
have fold cycling functionality available in normal mode and vanilla
users do not.
(And enboldens them in both forms)
I didn't think anyone would use this form to ask for how-to/config help,
but the internet proved me wrong.
Oh god. Does the bump request form need one too?
Reverts 86fd6c621 which increased gcmh-high-cons-threshold from Doom's
16mb default to its upstream default (of 1gb). This was an experiment.
In theory, the user should idle enough that it would GC enough to stave
off freezes/stuttering/paging, but in practice, either users did not
idle enough or the GC didn't clean up enough when given the opportunity.
The result: terrible stuttering and freezing after long periods of use.
Back to 16mb gang.
`cargo doc --open` (the previous binding of `SPC m b d`) always opens a
new browser tab. For "doc-driven development" this isn't so nice, since
we'd like to stay in the same tab and just refresh its contents after
editing. That's what `cargo doc` (without `--open`) does, which is
called by `#'rustic-carg-build-doc`.
This commit introduces a binding for the latter behaviour, but asigns it
to the old `SPC m b d`, with the "open" variant as `SPC m b D`. This
matches Spacemacs and follows the usual pattern of "the capital letter
variant is the one you use less often".
The :editor format module uses either the formatter available through an
LSP server or a formatter that the format-all package supports. With
:editor (format +onsave), this formatter is triggered when a file is
saved. However, if no format-all formatter is available, this on-save
behavior is disabled, even if an LSP formatter is available. This fixes
that.
+ Use rjsx-mode for all javascript files. It degrades gracefully and is
less maintenance.
+ Rethink flycheck + JS integration. You should get eslint and tslint
support in web-mode, typescript-mode, and typescript-tsx-mode now (as
well as rjsx-mode, of course).
`lispyville-end-of-defun' doesn't go to the next defun when point is
already at the end of a defun, whereas `lispyville-beginning-of-defun'
does. This commit fixes this inconsistency by matching
`lispyville-end-of-defun''s behaviour with `lispyville-beginning-of-defun'.
`line-end-position' isn't enough because it never returns `t' in normal
mode (in normal mode the point can't reach the true end of a line).
Trying to do this automatically is buggy to the point of insanity. It's
not reliable enough to use as a :post-build target for the pdf-tools
package.
Better to fail gracefully, let the user know what they must do, and let
them do it at their own discretion.
