Old P::wrap_<type>() functions will be removed, and the wrap_<type>() callbacks
will be replaced with L::Property: WrapTempalteProperty<C> trait bounds. We
could instead use the std From trait, but my feeling is that we would be better
off using less-generic abstraction. It's unlikely that external callers would
have to use this trait.
This will help define List<T> template methods as table of fn(..)s. I think the
parsing/building API will look slightly nicer.
I'm going to add generic wrap(BoxedTemplateProperty<T>) trait, which means a
conversion from T should be uniquely defined. Even though we won't add the ()
template type, it's better to not reserve () for tests.
The former wording of "With the `-r` option, which is the default" is
confusing, and made redundant by the clarifications within the
option-level documentation.
The former wording of "[w]ith the `-r` option, which is the default..." is
a bit confusing. This change brings `jj diff`'s documentation more in
line with the other commands with similar semantics, such as `jj rebase`.
I was wondering whether this is presentation issue or not, and I think it is a
matter of DiffLineIterator. For matching hunks, DiffLineIterator flushes the
current_line buffer and bumps the line numbers for the next line. This should
guarantee that there are no blank DiffLine to be queued. However, for different
hunks, only the left line number can be bumped in the first loop, so there may
be an empty-looking hunk having the same right line number.
Closes#6471
The command has displayed all parents and the diff summary from the
merged parents since 48c44344bfb3 (2022-12-04) but it still says that
it only cares about the first commit. This patch finally fixes that.
We haven't had any reports of problems from people who opted in. Since
it's early in the release cycle now, let's now test it on everyone who
builds from head, so we get almost a month of testing from those
people before it's enabled by default in a released version.
This impacts lots of test cases because the change-id header is added
to the Git commit. Most are uninteresting. `test_git_fetch` now sees
some divergent changes where it used to see only divergent bookmarks,
which makes sense.
to set the message on the first commit, where the selected
changes are going. The commit with the remaining changes
keeps the original description.
With this option it becomes possible to use split in a fully
non-interactive way, in combination with the filset feature.
It also makes jj split more consistent with other commands
like squash, commit or new.
This patch replaces single-char L type aliases with P, and renames the L aliases
where that makes sense. Many of the P aliases will be removed later by
introducing generic wrap<T>() trait.
I think this was remainder of the old design where wrap_*() functions took
&TemplateLanguage as self argument. Since the wrapper type implements accessor
functions like .try_into_boolean(), it makes sense that the same type implements
::wrap_boolean(), etc.
These .wrap_<T>() functions will become generic over T.
It seems like a small usability improvement if users don't need to
enter the "$schema" link manually when they create a new config file.
This doesn't help existing users.
This change, from an enum to a struct, is a more accurate representation
of the actual way that a ConfigPath works; additionally, it lets us add
different information without modifying every single enumeration field.
I'm trying to refactor property wrapping functions, and noticed that it's odd
that .wrap_<property>() does boxing internally whereas .wrap_template() doesn't.
Also, it sometimes makes sense to turn property into trait object earlier. For
example, we can deduplicate L::wrap_boolean() in build_binary_operation().
This also adds a test case for the completion of arguments following
multi-argument aliases, to cover the bug reported in issue #5377.
The default command is like a special kind of alias, one which is
expanded from zero tokens. Consequently, it also triggers the bug
#5377 on bash/zsh, even if the `default-command` is just a single token.
The fix is along the lines sketched out by the "TODO" comment. Bash and
Zsh don't behave identical, so the padding ([""]) still needs to be
applied (and removed) conditionally in a disciplined manner.
The completion mechanism works differently in different shells:
For example, when the command line `jj aaa bb ccc` is completed at the
end of the `bb` token, bash and zsh pass the completer the whole line
`-- jj aaa bb ccc` and an index of 2 which refers to the `bb` token;
they are then expected to complete `bb`. Meanwhile, fish and Powershell
only pass the command up to the completion point, so `-- jj aaa bb`;
the completer is always expected to complete the last token. In all
cases, the shell ultimately decides what to do with the completions,
e.g. to complete up to a common prefix (bash), to show an interactive
picker (zsh, fish), or to insert the completion if it is the only one
(all shells). Remaining tokens (`ccc`) are also always appended by the
shell and not part of the completion.
While this is mostly handled by the clap_complete crate, we do expand
aliases and present clap_complete with a fake view of the real command
line, thereby reaching into its internals by wrapping the interface
between the completion shell script that is provided by clap_complete
and its Rust code in `CommandEnv::try_complete()`. If we get this wrong,
completion might yield unexpected results, so it is worth testing
completion for both flavors of shells whenever aliases are potentially
in the mix.
To avoid redundancy, the shell-specific invocation of `jj` is factored
into a `complete_at()` function of the test fixture. The `test-case`
crate is then used to instantiate each test case for different values of
clap_complete's `Shell` enum.
filter
bash/zsh specific behavior
move impl
