treewide: replace (eq/equal foo nil) with (null foo)

[Hi-Angel]

Just a trivial refactoring

[tomdl89]

Thanks for the PR @Hi-Angel. In the interests of being technically correct (which is the point of this PR anyway!) I think most (all?) of these should use not rather than null. As the info page Predicates on Lists says about null:

This function is identical to not, but as a matter of clarity we use null when object is considered a list and not when it is considered a truth value…

and I think these are truth values rather than empty lists..?

[Hi-Angel]

Sure, good point. Done!

[axelf4]

This function is identical to not, but as a matter of clarity we use null when object is considered a list and not when it is considered a truth value…

and I think these are truth values rather than empty lists..?

That is not true, in most of these cases nil is used as a stand-in for any other symbol, and not to indicate falseness.

[Hi-Angel]

Well, the variables look like are truth values, i.e. not action, not repeat-type, not flag. The function calls may be not so much…

I'm okay with whatever. It's a purely stylistic matter, null is an alias to not. not is one character shorter. On the other hand, my Python habit makes me prefer null over not (in Python not is error-prone in places), but then again ELisp isn't Python 😊 So, yeah, at the end I'm okay with either choice.

[axelf4]

Well, the variables look like are truth values, i.e. not action, not repeat-type, not flag.

action is one of nil for try-completion, t for all-completions, lambda for test-completion, metadata, (boundaries . ,suffix) for the type of completion action to perform, c.f. minibuffer.el which also uses (null action).

repeat-type is the repeat type and one of ignore, motion, abort, nil, ...

Neither is a boolean value.

((null action) is of course a truth value, but that does not mean not should have been used.)

[tomdl89]

@axelf4 my focus was more on the first half of the sentence:

we use null when object is considered a list

which these are not. I interpreted the second half of the sentence to be non-exhaustive:

not when it is considered a truth value

i.e. not when it is considered a truth value, but also not when it is a stand-in for any other symbol, etc?

So do you think this PR is more correct with nulls than nots? I'm happy to defer to you on this, as I get the impression you're more of a proper lisper than me.

[tomdl89]

Having read a bit more on this, I think @axelf4 is right, and the documentation is confusing. Sorry for the confusion @Hi-Angel

[Hi-Angel]

It's okay, I made a backup branch for the case we decided to revert everything to the older version 😊

I'll take a closer look to see if anything looks potentially like a boolean value to have there not instead of null.

At the end of the day, (null foo) is stylistically equivalent to (eq/equal foo nil), because both cases explicitly compare to nil, so even replacing everything with null would imply no stylistic regression.

[tomdl89]

The lack of clarity in the manual is reported here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70392
and fixed here: https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-29

[axelf4]

The lack of clarity in the manual is reported here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70392
and fixed here: https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-29

Nice! I agree that the documentation was ambiguous - good to get that cleared up.

What matters IMO is just that the completion functions stay consistent with those in minibuffer.el (which use either (eq _ nil) or (null _)).

[Hi-Angel]

Okay, so, I looked through changed locations, and neither is a boolean value, i.e. they all take some symbolic values as well besides nil. So in the end I just reverted to the older version that replaces the pattern to (null …).