`git-commit` is no longer distributed with `magit` and no longer
declares its dependencies, causing "file missing: with-editor" and
similar errors for folks who don't have magit installed. Also, VC's
commit workflows don't utilize the mode, so there's no reason to keep it
in this module.
Ref: magit/magit@c170fcf399
Ref: #8003
The keybinding in 682f151 was being overwritten. I'll simply copy the
keymap into the module, until I can devise a more elegant solution.
Amend: 682f151176
Ref: #5954
Activates smerge-mode if the file contains merge conflict markers. Also
turns binds the localleader to `smerge-mode-map` when it's active.
Also removes an unused leader binding (which will never be set because
:ui hydra was removed in b08c2c7).
Amend: b08c2c745fClose: #5954
BREAKING CHANGE: This deprecates the IS-(MAC|WINDOWS|LINUX|BSD) family
of global constants in favor of a native `featurep` check:
IS-MAC -> (featurep :system 'macos)
IS-WINDOWS -> (featurep :system 'windows)
IS-LINUX -> (featurep :system 'linux)
IS-BSD -> (featurep :system 'bsd)
The constants will stick around until the v3 release so folks can still
use it -- and there are still some modules that use it, but I'll phase
those uses out gradually.
Fix: #7479
magit/magit@97a95f7007 -> magit/magit@4881835572
The pinned version of `magit` in `:tools magit` needs be the same
as that of `git-commit` in `:emacs vc`.
`straight.el` prepares the repo only once, and if `git-commit` is
processed first, its pinned version wins out and the more recent
pinning of `magit` is ignored.
As noted in #7363, processing order may be non-deterministic, so the
inconsistent pinning may not be apparent on every system.
Fix: #7363
Amend: #7277
Amend: 7c63b353d2
Previously, only gitlab.com and gitlab.gnome.org were recognized as
gitlab hosts. This tweaks browse-at-remote to recognize any subdomain
named gitlab.* as a gitlab host (as a fallback, if no other regexp
matches).
This is provided by `smerge-mode` in Emacs 27, and functions exactly
like `smerge-next`, except that if there are no more conflicts in the
current file, it will go to the next file with conflicts.
Arguably this could be a different key binding. However, I find that it
is almost strictly superior to `smerge-next`: I can't think of a case
where I *wouldn't* immediately want to go to the next file with
conflicts, and even if you do by accident you can just pop back to the
preceding buffer. So I think it warrants being the default.
Close: #5431
featurep! will be renamed modulep! in the future, so it's been
deprecated. They have identical interfaces, and can be replaced without
issue.
featurep! was never quite the right name for this macro. It implied that
it had some connection to featurep, which it doesn't (only that it was
similar in purpose; still, Doom modules are not features). To undo such
implications and be consistent with its namespace (and since we're
heading into a storm of breaking changes with the v3 release anyway),
now was the best opportunity to begin the transition.
To reduce redundancy, remove the maintenance hassle that version
constants would impose later on, and rely on built-in
facilities (featurep) more over global variables or doomisms, these
global constants have been deprecated in favor of Emacs "features":
- EMACS28+ -- replace with (> emacs-major-version 27)
- EMACS29+ -- replace with (> emacs-major-version 28)
- NATIVECOMP -- replace with (featurep 'native-compile)
- MODULES -- replace with (featurep 'dynamic-modules)
(These constants will be formally removed when v3 is released. The IS-*
constants are likely next, but I haven't decided on their substitutes
yet)
I also decided to follow native-compile's example and provide features
for Emacs' system features (since system-configuration-features' docs
outs itself as a poor method to detect features):
- dynamic-modules
- jansson
- native-compile -- this one already exists, but will instead be removed
if it's non-functional; i.e. (native-comp-available-p) returns nil.
These are now detectable using featurep, which is fast and built-in.
I've omitted docs/*.org from this merge, as there is still work left to
do there, but I am pushing the module docs early so folks can benefit
from the new docs sooner.
new hydra head:
"n" (progn (smerge-vc-next-conflict)
(recenter-top-bottom (/ (window-height) 8)))
Allow us to jump to the next merge conflict in current project without
leaving the hydra and/or opening magit.
Fewer links means less confusion.
- Merge doom-issue and doom-commit links into doom-ref (for auto-linking
Issue/PR/commit references).
- Merge doom-module-source and doom-docs-source links into doom-source.
- Rename doom-report-issue to doom-report.
- Use '!' as the icon for module issues link.
- Remove doom-repo (replaced with "doom:*" in :lang org module).
- Add doomdir and emacsdir links to :lang org module.
vc-ignore-dir-regexp is configured to ignore TRAMP buffers to speedup
projectile. browse-at-remote uses vc-git-root to find git root project
and it will fail to find project root for remote buffers. Temporary
return vc-ignore-dir-regexp to default value.
Fix: #5660
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