Generalize counsel-outline to handle major modes and display styles - cont'd

[ericdanan]

Re #1681

[basil-conto]

Needs more filling! :)

[ericdanan]

Not sure what you mean. I agree the sentence is not very informative, but on the other hand I didn't want to duplicate the information of counsel-outline-settings's docstring.

So I just removed the sentence. This actually seems in line with many counsel commands that have short docstrings not mentioning the corresponding custom variables.

But of course if you have suggestions, @abo-abo will make the decision.

[basil-conto]

How about:

(or (bound-and-true-p LaTeX-section-list)
    (bound-and-true-p latex-section-alist)))

This removes the need for (defvar LaTeX-section-list) or (defvar latex-section-alist) and makes the function a tiny bit less mode/package-dependent (not that this is particularly important).

[ericdanan]

Thanks, done

[ericdanan]

In the last batch of 4 commits, the first and fourth follow @basil-conto 's comments.

The second one add :history and :caller to counsel-outline and make them customizable in counsel-outine-settings. This allows in particular to perfectly replicate counsel-org-goto for org-mode buffers, and can be useful more generally I think.

The third one transforms the counsel-org-goto-XXX custom variables into counsel-outline-XXX, makes them customizables in counsel-outline-settings, and makes aliases from the former to the latter. Also counsel-org-goto becomes an alias to counsel-outline, counsel-org-goto--get-headlines to counsel-outline-candidates, and counsel-org-goto--add-face to counsel-outline--add-face. This looks more consistent to me and I think it shouldn't alter anyone's setting, but you may of course think otherwise. Perhaps the alias is not needed for the latter two functions (in which case counsel-outline--add-face could be simplified slightly by making the two new optional args required).

I don't plan to push more commits for now, unless you suggest me to do so.

[abo-abo]

Thanks.

[basil-conto]

Not sure what you mean.

Sorry @ericdanan, I didn't see your reply to my comment. I was referring to what Emacs calls filling, by which all I meant was that the docstring line was too long and should be wrapped at ~65 columns, as is customary in Elisp.

[ericdanan]

I see, thanks for clarifying. Basil L. Contovounesios writes:

…

Not sure what you mean. Sorry @ericdanan, I didn't see your reply to my comment. I was referring to what Emacs calls filling, by which all I meant was that the docstring line was too long and should be wrapped at ~65 columns, as is customary in Elisp. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[basil-conto]

I know the wording wasn't touched by this PR, but since I'm working on improving these docs, I'd like to clarify: instead of "loaded", should this say "fontified" or similar instead? Because I don't understand how a buffer can be partially loaded.