This doesn't fix a particular issue, but makes designing keybinds for
org-mode more predictable and less vulnerable to unpredictable changes
imposed by evil-collection.
Its default value is acceptable in 28+ and handles clipboard integration
in PGTK Emacs, so we don't have to.
Thanks to @sei40kr for revealing this fix to me (in #5219).
Fix#5219
rmuslimov/browse-at-remote@e02ad2189c -> rmuslimov/browse-at-remote@cef26f2c06
BREAKING CHANGE: browse-at-remote-remote-type-domains is replaced by
browse-at-remote-remote-type-regexps. If you have a custom domain
configured replace:
(add-to-list 'browse-at-remote-remote-type-domains
("git.example.com" . "github")
with
(add-to-list 'browse-at-remote-remote-type-regexps
("^git\\.example\\.com$" . "github")
Added support for Gittiles.
Shortlog:
Jack Rosenthal (3):
Add support for Gitiles
Fix broken tests
More permissive regex in browse-at-remote--gerrit-url-cleanup
Rustem Muslimov (2):
Fix broken merge
Fix savannah gnu message
rmuslimov (3):
Merge pull request #78 from jackrosenthal/gitiles
Merge pull request #80 from jackrosenthal/broke_tests
Merge pull request #81 from jackrosenthal/regex
Here's the problem:
1. Org's link system unconditionally calls *all* link :store handlers
when you call `org-store-link`, and all :export handlers when you
export an Org file.
2. The org-pdftools package works by defining a custom pdf: link with
custom :store and :export handlers.
3. Those handlers do not perform error handling before using pdftool's
API.
4. pdf-tools fails loudly and ungracefully with a
"pdf-info-epdfinfo-program is not executable" error when its API is
used and epdfinfo isn't installed.
TL;DR org-pdftools effectively breaks storing/exporting in org-mode
until pdf-tools-install is executed to install epdfinfo. This is awful
UX, so let's suppress the error.
Too many people not modifying the title and now my inbox is full of
"Briefly summarize your issue" issues. At least when it's blank by
default, Github won't let you submit it until you fill it out.
Half-reverts c2c6a64, which tried to get doom/reload to regenerate the
envvar file from within Emacs, but running an environment scraper in a
bare environment is really hard to get right. Ideally, your shell config
should set up your environment, but there are too many edge cases or
poor configs in the wild to depend on this.
I've brought back doom/reload-env, but only to reload the envvar file
-- *not* regenerate it. I've given up on trying to do that from within
Emacs.
Fix#5344
Ref c2c6a64118
Some logic derps from 0b5243c. Also restores
projectile-git-submodule-command in remote buffers (to fix a
wrong-type-argument error waiting to happen).
Ref 0b5243c12c
Ref #5360
Reduce how much projectile hits the server in TRAMP buffers by:
- Not looking for fd/fdfind (just use the VCS-specific commands
projectile provides and assume they're present on the remote).
- Not walking up the directory tree to display the project name in the
mode line.
- Reducing TRAMP file-cache misses.
- Reducing how chatty tramp is about its connections.
Fix#5360
The user's doom/info is essential information for debuggin issues.
Please don't modify or omit parts of it. Of course, feel free to remove
sensitive information, but do so selectively. The more you omit, the
less I have to work with.
ce31880 did not fix doom-system-cpus on msys2 builds because the
function didn't handle integer return values from any of its code
paths (which formerly returned strings or lists).
Ref ce31880cccFix#5347
a2a128d3 changed prefix-help-command to use embark. This commit fixes
prefix-help-command getting reset to describe-prefix-bindings due to
help.el setting it at top-level because it is eventually loaded twice
due to defer-feature!, which removes a symbol from emacs' list of loaded
features.
Ref a2a128d3a5
This is a source of slowdowns in markdown-mode buffers, even
ones without code blocks, which drastically affects typing and motion
latency. This appears to be an upstream issue.
