| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Emacs 31.1 adds variable `lisp-indent-local-overrides'.
|
|
|
|
|
|
|
|
|
|
|
|
Stick to doing so using `magit--propertize-face' for now.
Stick to not doing it for strings inserted into minibuffers or
into transient menu buffers, or used in messages. (Except where we
already do.)
This needs more work (including design decisions). This commit just
fixes some broken cases.
|
|
If there is a single BODY form in the final clause, we can just
use that as the CONDITION instead (because the value of that is
returned if the BODY is empty).
I've been gravitating towards that style for a long time, but
because I realize that this is not without issue and that there
are certainly those that would find this practice questionable,
I refrained from updating existing code until now.
The main problem with dropping the `t' is that it is not always
immediately obvious if one is looking at
(cond
...
((foo bar)))
or
(cond
...
((foo) (bar)))
That's why I still use `t' when the single BODY form is too long
and/or complex, despite fitting on one line. In this case from
`magit-log-move-to-revision', for example, I was on the fence:
(cond
...
((apply #'magit-log-all-branches (magit-log-arguments))))
(It's worth noting that the same issue also occurs when reading
non-final-catch-all clauses.)
On the other hand, the single BODY form can also be complex
*enough* to allow using it as the CONDITION, without that being hard
to parse. E.g., when it spans multiple lines, and indentation keeps
increasing, and/or when BODY is a `let' from or similar.
Used like this, `cond' becomes more similar to `or' in certain
situations, but even then they still behave differently, consider:
(or (and CONDITION maybe-nil)
...)
vs
(cond (CONDITION maybe-nil)
...)
|
|
Anaphoric macros get a bad rep and while my own infatuation was somewhat
short lived, there are cases where I still find them useful, such as in
the case of
(and$ (function-with-a-name-that-makes-if-obvious-what-is-returned)
(function-with-a-name-that-makes-if-obvious-what-is-expected $))
Many of the cases where this commits starts using `and$', fall squarely
into that category. There are a few where I an on the fence. That's
because I've just invented this macro and need some practice to fully
develop my sense of when it is, and is not, appropriate to use this
macro.
|
|
Using the "other elements of VARLIST have access to SYMBOLs from
earlier elements" variant is IMHO _wrong_ when there are in fact
no other elements.
|
|
Cond-Let's `if-let', `if-let*', `when-let', `when-let*' and `and-let*'
implementations behave differently from the built-in implementations,
but because I have been careful not to depend on the idiosyncrasies,
switching over should be mostly safe.
Also add shorthands for the other `cond-let--...' macros. We will
start using those (and `cond-let' and `cond-let*') in later commits.
|
|
This was not done until now because doing so resulted in a warning
because the macro expansion did not actually leave any variables
unused. This was fixed in Emacs 30.1 and I've added a backport to
Transient, which this package can also take advantage of.
Without consistently using `_' one would always have to count parens
to be sure whether a member of the varlist does or does not bind a
variable. It is very easy to make mistake when writing or reading
such forms, if `_' is not consistently used in the non-binding cases.
|
|
Almost always would it be better to use `match-string-no-properties'
instead of `match-string', but because the name of the former is
excruciatingly long for a function that one often wants to use in
tight spaces and because it usually "does not really matter", I
usually went for the latter.
The problem is, it does matter. For example, even strings that are
usually only used by code may end up obfuscating debug statements.
So let's start doing the right thing, even though there surely will
be people frowning at the use of a shorthand.
The fake ("match-string" "match-string") shorthand is necessary to
protect literal `match-string' and `match-string-no-properties' from
being corrupted by interpreted as shorthand for the non-existent
`match-stringing' and `match-string-no-propertiesing'.
Unfortunately the shorthands have to be specified in each library
individually. Using "dir-locals.el" only works if the libraries
are compiled. At least this additional noise is neatly tucked away
at the end of the files.
It might turn out that out of the more than two hundred instances
where this replaces `match-string' with `match-string-no-properties'
we should have stuck with the former in an instance or two. That's
the price of progress and can be fixed once such regressions are
reported.
|
|
|
|
|
|
Inform the user that the process buffer contains the full error
(and other output), regardless of whether `message' or `signal'
is used to show a short error message in the echo area.
Closes #5396.
|
|
|
|
|
|
|
|
The `process' slot is added by this class and used in
`magit-start-process'.
|
|
By popular demand, add this option, but warn against customizing it.
Closes #5348.
|
|
|
|
|
|
|
|
In two cases use lambda, not ##.
|
|
|
|
In one case use lambda and in another pcase-lambda, not ##.
|
|
|
|
When we stopped matching text that might identify the key
in [1: a43c1d8d7a], the intention was only to avoid false-negatives
by being to restrictive. However, since `magit-process-match-prompt'
only returns the matched text (i.e., it doesn't extend to the end of
the line), we do have to match the full line. Allow anything after
"passphrase" and only insist on the trailing colon.
See #5291.
1: 2025-01-25 a43c1d8d7a99dd2b9f865285bed442dddb0e5ce8
magit-process-password-prompt-regexps: Increase flexibility
|
|
- Account for different levels of politeness and verbosity, but
insist on reasonable capitalization.
- Since we don't try to determine a key's identifier anyway, when
asked for a passphrase, essentially only look for a reasonably
anchored string "passphrase".
- Make the trailing space after the colon optional in one more case,
for consistency. Now it is optional in all cases. We cannot know
for sure from strings posted into the issue tracker, whether the
colon was or was not followed by a space.
|
|
|
|
OpenSSH may use prompts like "(user@host) Password for user@host: ".
Let's treat that separately to avoid obfuscating the regexp used for
less repetitive host prompts.
|
|
|
|
|
|
|
|
The one right before matches too, and sets host match group.
|
|
|
|
|
|
|
|
|
|
For `magit-pre-refresh-hook' that is already being done.
|
|
|
|
This is a refinement of the functionality, which was previously
enabled using the variable `magit-process-extreme-logging' (which
we remove).
|
|
Add another entry that always prompts, because the modified entry may
stop matching some prompts (containing an unusual quote). Also tweak
another entry.
Fixes #5257.
|
|
These setup instructions are no longer needed because this function
is used by default.
|
|
We still show the run command in the echo area and log the command and
its output to the process buffer. Additionally logging the run command
to the *Messages* buffer is redundant.
|
|
Refreshing the process buffer is not useful.
|
