Remove unnecessary (require 'inline) call

[1. text/plain]
Fix issue with symbols in collections again

This issue was accidentally added back in the previous commit, due to
a simplistic `cond' expression.
Use 'all-completions' in 'typo-edits'

Thanks to the input from Stefan Monnier[0] for suggesting this
approach, simplifying the handling of edge-cases which were previously
required to handle the various different collection types.

This also (properly) inlines the function 'typo--test', and further
optimises it by calculating (length key) only once for each invocation
of 'typo-edits'.

[0] https://lists.gnu.org/archive/html/emacs-devel/2023-07/msg00694.html
Merge handling of lists and alists

The principal issue here is that a alist may contain non-cons-cells,
while a "regular" list shouldn't contain any.  Given a cons-cell, it
would only be possible to decide this by traversing the list, before
processing it (or perhaps while processing it), until a cons-cell is
found (or not).

The approach taken here is to be flexible and interpret the a
cons-cell based collection as a sort of mix of both a alist and
regular list, matching both cons-cell entries and non-cons-cell string
or symbols.  This is strictly speaking not correct (at least going by
functions like 'assoc'), but consistent with other completion styles:

(all-completions "f" '("foobar" "foobaz"))       ;=> ("foobar" "foobaz")
(all-completions "f" '(("foobar" . 3) "foobaz")) ;=> ("foobar" "foobaz")
(all-completions "f" '("foobaz" ("foobar" . 3))) ;=> ("foobaz" "foobar")

Also note that this patch addresses the bug pointed out by Visuwesh in
[0], in that typo completion would raise an error when completing a
list containing symbols.

[0] https://lists.sr.ht/~pkal/public-inbox/%3C87pm4ywqus.fsf%40gmail.com%3E#%3C87pm4ywqus.fsf@gmail.com%3E
Handle hash-tables with symbols as keys

According to the Info node `(elisp) Basic Completion', both are legal
keys and have to be considered:

	If COLLECTION is a hash table, then the keys that are strings
	or symbols are the possible completions.  Other keys are

Thanks to Visuwesh for pointing out the issue in [0], and suggesting a fix.

[0] https://lists.sr.ht/~pkal/public-inbox/%3C87pm4ywqus.fsf%40gmail.com%3E#%3C87pm4ywqus.fsf@gmail.com%3E
Elaborate typo-{shrink,expand} docstrings
da00074a — Visuwesh 4 months ago
* typo.el (typo--test): Fix check for typo-shrink and typo-expand

(typo--test "-ener" "-n") would return t even though it has three
deletions and should be rejected as per the default value of typo-shrink.

See the discussion https://lists.sr.ht/~pkal/public-inbox/%3C87v8gg8z2j.fsf%40gmail.com%3E.
Fix typo in README
Bump version to 1.0.1 for GNU ELPA
Assign copyright to the FSF
Add more links to the introductory README paragraph
Add a .gitignore
Add a .dir-locals.el
Add licensing information
Add a basic README file

Based on my file from setup.el.
Add "Maintainer" header
Add user option 'typo-support-all-completions'
Update headers for Sourcehut
c0283a40 — Philip Kaludercic 7 months ago
Summary: Set 'typo-level' to 'sqrt' by default
a1c54f44 — Philip Kaludercic 7 months ago
Summary: Allow for 'typo-level' to be a function