Add narrowing to consult-outline

[astoff]

Here's a sketch for the narrowing by outline level in consult-outline.

Some comments:

• I don't like the consult--ouline-level function too much. It would be easy enough to compute the level when building the candidate list, but then I would have to change consult--location-candidate to allow including this extra datum in each candidate.
• For now, I'm requiring outline in the body of consult--ouline-level. If we reimplemented code from outline to avoid requiring it, it wouldn't add that many lines of code. Still, I don't quite see why not (require 'outline) in the body of consult-outline itself. Then consult--outline-candidates could also be slightly simplified.
• There's nothing forcing outline levels to be contiguous numbers (for instance, the smallest level in consult.el is 4). I think it's best not to be overly fancy when handling this. So I'm just shifting outline numbers so that Level ≤ 1 narrows to the smallest level, but otherwise leave any holes as they are. This also means it's impossible to reach the level of (defun in consult.el, because those have outline-level=16 a.k.a. Level ≤ 13.

[minad]

For now, I'm requiring outline in the body of consult--ouline-level. If we reimplemented code from outline to avoid requiring it, it wouldn't add that many lines of code. Still, I don't quite see why not (require 'outline) in the body of consult-outline itself. Then consult--outline-candidates could also be slightly simplified.

The local require style is a no-go. We can either require it globally, code the needed functions ourselves or create a separate consult-outline.el in case on wants to preserve lazy loading. Which code is simplified exactly if you require outline? As far as I understand both outline-level and outline-regexp may be present if outline is not loaded. Is that right?

I don't like the consult--ouline-level function too much. It would be easy enough to compute the level when building the candidate list, but then I would have to change consult--location-candidate to allow including this extra datum in each candidate.

Yes, it should be done when generating the candidate list for performance. You can use add-text-properties in consult-location-candidate and add an optional argument.

[astoff]

If outline-regexp is bound and nil (which shouldn't happen), there will be an error in the ensuing re-search-forward. So I changed to (or (bound-and-true-p ...`

[astoff]

Just for the record, this is a tricky line, because it depends on the match data from the previous re-search-forward.

[astoff]

You can use add-text-properties in consult-location-candidate and add an optional argument.

Oops, I misread this. If you think it's a one off thing, we can keep as in the current version of the PR, otherwise I'll do as you suggest and add a &rest argument to consult--location-candidate.

[minad]

@astoff Yes, I meant add a rest argument to consult--location-candidate and use add-text-properties in consult--location-candidate instead.

[astoff]

Should be good now ;-)

[minad]

Thanks!