Re: master 1e3b0f2: Improve doc strings of project.el

[Theodor Thornhill]

>>
>> Or am I misunderstanding you?
>
> Maybe.  I don't think I understand what you are suggesting in enough
> detail to tell.

For a project of any kind (vc, major-mode-based, or any concept you can
think of) to decide what buffers are useful we need some set of
information about the project. If as you say, a text-mode based project
only should show buffers of say, org-mode, markdown etc, and exclude
buffers generated by org-babel or something, we need to place that
knowledge somewhere.

This knowledge is in part stored in 'project-ignores', where we can
ignore patterns such as "assets" "node_modules" etc. without it needing
to be put in a .gitignore [1]. However, then we lose the optimized search
functionalities offered by the "(head vc)" implementation in project.el.

If for instance the project-switch-to-buffer should have to know
everything about every imaginable combination of interesting derivates
of a project, then I believe that would be a quite a bit larger
function (or at least a huge curated map of sorts).

What I am thinking, surely without knowing all the intricacies here, is
that maybe the "switch-to-buffer" and "kill-buffers" also should be
defgenerics? Then the implementation of what to show can be put off for
later, and the "(head vc)" version can be decided now?

Otherwise, I guess the user has to specify a set of patterns, or at
least decide on major-modes to include, and that would seem like a
hassle to me.

I may be overthinking this, but it would be nice if "switch-to-buffer"
only would be a "brainless" buffer-picker with only useful choices.

Theo


[1]: If we choose to implement our own notion of a project.