Morgan Smith <[email protected]> writes: > Ihor Radchenko <[email protected]> writes: > >> I am not sure if it is a good idea. What you are essentially doing is >> trying to provide some kind of fix working around the fact that >> `org-tags-completion-function' is called inappropriately by >> `org-make-tags-matcher'. But I do not think that doing it in >> `org-tags-completion-function' itself is the right approach: > ... > I'm about to head to bed so I'm not going to dig any deeper then that but > reading the commit message from 622f9fa76c8ee0766b15945c013b0950d703b955 it > says: > >>> Note that there is still one use for `org-tags-completion-function', >>> which is for completing tag matches. Completing tag matches is >>> different from completing lists of tags since the separators (+, -, >>> etc) have semantic meaning. This commit does not address that use >>> case.
Hmm. You are right. I somehow thought that `org-tags-completion-function' is used in multiple places. However, it is _only_ used by `org-make-tags-matcher'. Therefore, its sole purpose is completing matcher string, not just tags. The function name is confusing. Maybe we should rename it and update the docstring to reflect the real intended purpose. > Oh and if your objection is about how clunky a job a did with the quote > counting code (which is a fair criticism), you could check if emacs 28 > has seq-count so we could just do: > > (seq-count (lambda (char) (eq char ?\")) string) Considering the above, I do not have so strong objection. Although, it still feels like temporary workaround. A proper completion should replicate how parsing MATCH string works in `org-make-tags-matcher' and ideally offer completion for property names, todo keywords, etc. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
