helm and org-mode tags

[Makmiller Pedroso]

Hi all,

I typically use more than one tag for the same headline in org-mode
(e.g., ":email::urgent:"). But with helm I only get completion for my
first tag. If I want to insert a second tag for the same headline I
have to type the whole tag name myself (helm doesn't show any
candidates for inserting a 2nd tag). Is that the expected behavior?

Thanks,
mak

[Thierry Volpiatto]

Hi,

Makmiller Pedroso <makm...@gmail.com> writes:

> Hi all,
>
> I typically use more than one tag for the same headline in org-mode
> (e.g., ":email::urgent:"). But with helm I only get completion for my
> first tag.

Sorry, but what helm command are you using ?



--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[Samuel Schaumburg]

Hi,

would like to bring this up again, since I am having the same issue, trying to provide some more information here.

All I do with helm is set it up like that in my init file.

(require 'helm-config)
(helm-mode)

In org-mode buffers, assigning tags, either in a headline with C-c C-c or with C-c C-q leads to helm taking over the normal org commands (only if helm-mode is running, otherwise not)

The helm buffer is named: helm-mode-org-set-tags.

Assigning just one tag is fine as said in the OP above. Helm also provides all the default tabs, that have been defined during org mode setup. So far so good.

All further tags indeed have to be typed manually and no completion is available.

Would it be possible to look into this and make it work more conveniently? The default org tag completion works okayish, but leaves some things to be desired. Would really love to use helm here.

Thx
Samuel

[Makmiller Pedroso]

Hi,

Samuel Schaumburg <schaum...@gmail.com> writes:

> Hi,
>
> would like to bring this up again, since I am having the same issue, trying
> to provide some more information here.

At least in my case, my problem was that org-tag-alist was nil in my org
buffer. I had a setq in my org-tag-alist in emacs config but, because of
a typo somewhere, the value of org-tag-alist wasn't getting assigned.

Cheers,
mak

>
> All I do with helm is set it up like that in my init file.
>
> (require 'helm-config)
> (helm-mode)
>
> In org-mode buffers, assigning tags, either in a headline with C-c C-c or
> with C-c C-q leads to helm taking over the normal org commands (only if
> helm-mode is running, otherwise not)
>
> The helm buffer is named: helm-mode-org-set-tags.
>
> Assigning just one tag is fine as said in the OP above. Helm also provides
> all the default tabs, that have been defined during org mode setup. So far
> so good.
>
> All further tags indeed have to be typed manually and no completion is
> available.
>
> Would it be possible to look into this and make it work more conveniently?
> The default org tag completion works okayish, but leaves some things to be
> desired. Would really love to use helm here.
>
>>
>>

>> Hi,

[Samuel Schaumburg]

Unfortunately, this does not seem to be my issue. I have set up with the dummy example from the manual, to make extra sure and also tested with my own configuration.

org-tag-alist is non nil in any case, as it is supposed to be.

Thank you anyhow

2014-01-28 Makmiller Pedroso <makm...@gmail.com>

[Thierry Volpiatto]

Samuel Schaumburg <schaum...@gmail.com> writes:

> Unfortunately, this does not seem to be my issue. I have set up with the
> dummy example from the manual, to make extra sure and also tested with my
> own configuration.
>
> org-tag-alist is non nil in any case, as it is supposed to be.
> Thank you anyhow

Here how it behave here:
If I set org-tag-alist like this:

(setq org-tag-alist '(("@entrainement" . ?E)
("@climbing" . ?c)
("Equipement" . ?e)
("@github" . ?d)
("Helm" . ?h)
("crypt" . ?C)
("@travel" . ?t)))

I am prompted to the fast org interface (no helm) and I can enter a
second tag.

If I set it like this:
(setq org-tag-alist '(("@entrainement")
("@climbing")
("Equipement")
("@github")
("Helm")
("crypt")
("@travel")))

I have helm completion, if I try to enter a second tag, the current one
is inserted in minibuffer and I have to C-k to see all tags in helm
completion tag list.
The current tag is replaced (BUG: It is not what I want).
If I turn off helm-mode the same bug happen with regular completion.


So I guess there is an org bug here:
org should behave the same with regular completion and its fast
interface.
There is no helm bug here IMO.

[Anders Johansson]

Thierry Volpiatto <thierry.volpiatto@...> writes:

>
> Samuel Schaumburg <schaumburg777@...> writes:
>
> > Unfortunately, this does not seem to be my issue. I have set up with the
> > dummy example from the manual, to make extra sure and also tested with my
> > own configuration.
> >
> > org-tag-alist is non nil in any case, as it is supposed to be.
> > Thank you anyhow
>
> Here how it behave here:
> If I set org-tag-alist like this:
>

> (setq org-tag-alist '((" <at> entrainement" . ?E)
> (" <at> climbing" . ?c)
> ("Equipement" . ?e)
> (" <at> github" . ?d)

> ("Helm" . ?h)
> ("crypt" . ?C)

> (" <at> travel" . ?t)))

>
> I am prompted to the fast org interface (no helm) and I can enter a
> second tag.
>
> If I set it like this:

> (setq org-tag-alist '((" <at> entrainement")
> (" <at> climbing")
> ("Equipement")
> (" <at> github")

> ("Helm")
> ("crypt")

> (" <at> travel")))

>
> I have helm completion, if I try to enter a second tag, the current one
> is inserted in minibuffer and I have to C-k to see all tags in helm
> completion tag list.
> The current tag is replaced (BUG: It is not what I want).
> If I turn off helm-mode the same bug happen with regular completion.
>
> So I guess there is an org bug here:
> org should behave the same with regular completion and its fast
> interface.
> There is no helm bug here IMO.
>

Hi,
FYI:
This is possibly related to the similar issue using ido I discussed here:
http://thread.gmane.org/gmane.emacs.orgmode/78236/ (be sure to look at the
whole thread).

The thing is that org's tag-insertion mechanism enables us to insert
multiple tags in sequence, and ido (and perhaps not helm either?) doesn't
support this behaviour? (i.e. passing a function for completion to
completing-read).

Cheers,
Anders Johansson

[Thierry Volpiatto]

Passing a function as collection is not supported by vanilla
`completing-read' either.

The bug here is on the org side as said above.

[jenia.ivlev]

I'm glad to have found you. I'm having the same bug too.

[Anders Johansson]

Hi,
Passing a function as a collection is supported by completing-read, at least in 24.4. From docstring of completing-read:
"COLLECTION can be a list of strings, an alist, an obarray or a hash table.
COLLECTION can also be a function to do the completion itself."

This is what org does. 'org-set-tags' passes 'org-tags-completion-function' to org-icompleting-read' which checks whether 'collection' (second argument) is a list and in this case (where it is a function) calls 'completing-read' (instead of ido or iswitchb) with the custom function.

I don't know what helm does when overriding completing-read, but it obviously interferes with this.
A way to disable helm-completion in this case could be adding (org-set-tags) to 'helm-completing-read-handlers-alist'. i.e.:

(add-to-list 'helm-completing-read-handlers-alist '(org-set-tags))

(not tested)

Ideally, a custom function working with helm that supports multiple selection of tags could be created and added:

(add-to-list 'helm-completing-read-handlers-alist '(org-set-tags . GREAT-FUNCTION))

Cheers,
Anders

[Shreyas Ragavan]

Anybody happen to find a solution to this yet ? 

[Anders Johansson]

Hi,
I'm using the config below now.
Not ideal, but it works.

(add-to-list 'helm-completing-read-handlers-alist '(org-set-tags . aj/org-completing-read-tags))

(defun aj/org-completing-read-tags (prompt coll pred req initial hist def inh)
  ;;(fn prompt coll &optional pred reqm initial hist def)
  (let* ((initial (and initial (stringp initial) (not (string= initial "")) initial))
         (curr (when initial (org-split-string initial ":")))
         (table (org-uniquify
                 (mapcar 'car org-last-tags-completion-table)))
         ;; remove current tags from list
         (table (if curr (cl-delete-if (lambda (x) (member x curr)) table) table))
         (prompt (if initial (concat "Tags " initial ": ") prompt)))
    (concat initial
            (mapconcat
             'identity (nreverse
                        (aj/helm-completing-read-multiple
                         prompt table pred nil nil hist def
                         t "Org tags" "*Helm org tags*" ":"))
             ":"))))

(defun aj/helm-completing-read-multiple (prompt choices &optional predicate require-match initial-input hist def inherit-input-method name buffer sentinel)
  "Read multiple items with `helm-completing-read-default-1'. Reading stops
when the user enters SENTINEL. By default, SENTINEL is
\"*done*\". SENTINEL is disambiguated with clashing completions
by appending _ to SENTINEL until it becomes unique. So if there
are multiple values that look like SENTINEL, the one with the
most _ at the end is the actual sentinel value. See
documentation for `ido-completing-read' for details on the
other parameters."
  (let ((sentinel (if sentinel sentinel "*done*"))
        this-choice res done-reading)
    ;; uniquify the SENTINEL value
    (while (cl-find sentinel choices)
      (setq sentinel (concat sentinel "_")))
    (setq choices (cons sentinel choices))
    ;; read some choices
    (while (not done-reading)
      (setq this-choice
            (helm-completing-read-default-1
             prompt choices predicate require-match initial-input hist def inherit-input-method
             name buffer nil t))
      (if (equal this-choice sentinel)
          (setq done-reading t)
        (setq res (cons this-choice res))))
    ;; return the result
    res))



Cheers,
Anders

[Adam Porter]

Hi Anders,

Thank you so much for sharing that code!  I've been wanting to fix this for years, and your code works great!

I've tidied it up a bit and fixed a small issue with the prompt, and I posted it in a gist here:

https://gist.github.com/alphapapa/a3433c54a631b693ba9d

I also submitted a pull request to the Helm repo, with credit to you:

https://github.com/emacs-helm/helm/pull/1439

There's currently a very strange bug (unrelated to your code) on that PR.  Something weird causing a function to fail if its name begins with "helm"; it works fine if it's named anything else.  Feel free to check it out if you have any ideas.  :)

Thanks,

Adam

[Anders Johansson]

That’s nice!
And I see Thierry fixed the problems and merged it too.
One thing that you can do with the original org-completion for
tags but not with this solution is to remove tags from the
heading. Now you have to do that »manually« by directly editing
the document. This is not a big problem for me though. I usually
move to the tags and use mark-sexp (C-M-SPC) to mark one tag at a
time and kill them.

Cheers,
Anders

--
Anders Johansson

[Adam Porter]

On Tuesday, March 22, 2016 at 7:18:32 AM UTC-5, Anders Johansson wrote:

That’s nice!
And I see Thierry fixed the problems and merged it too.
One thing that you can do with the original org-completion for
tags but not with this solution is to remove tags from the
heading. Now you have to do that »manually« by directly editing
the document. This is not a big problem for me though. I usually
move to the tags and use mark-sexp (C-M-SPC) to mark one tag at a
time and kill them.

Yeah, that's the only issue.  I think it's an improvement overall, because I usually add tags more than I remove them.  I have an idea for a way to fix it, though.  I'll see if I can get it working.

[Thierry Volpiatto]

Anders Johansson <mejlaa...@gmail.com> writes:

> That’s nice!
> And I see Thierry fixed the problems and merged it too.
> One thing that you can do with the original org-completion for
> tags but not with this solution is to remove tags from the
> heading. Now you have to do that »manually« by directly editing
> the document. This is not a big problem for me though. I usually
> move to the tags and use mark-sexp (C-M-SPC) to mark one tag at a
> time and kill them.

Also, with the current version of helm-org-completing-read-multiple
you can't change the tag once entered if you change your mind, what
about this version (Use TAB for completion and separate tags with ","):

(defun helm-org-completing-read-multiple (prompt choices

&optional
predicate require-match
initial-input hist def

name buffer)

"Read multiple items with `helm-completing-read-default-1'.

Reading stops when the user enters empty string."
(completing-read-multiple
prompt choices
predicate require-match initial-input hist def))

Of course the tags reversed due to the nreverse of previous version
will be fixed if we use this.

--
Thierry

[Thierry Volpiatto]

Anders Johansson <mejlaa...@gmail.com> writes:

> That’s nice!
> And I see Thierry fixed the problems and merged it too.
> One thing that you can do with the original org-completion for
> tags but not with this solution is to remove tags from the
> heading.

Now you can do it.

So now to complete tags:

1) Call org-set-tags-command
2) Hit TAB after removing if necessary current tag from prompt.
3) Press RET to enter new tag.
4) Enter ":" or "," and hit TAB again to enter next tag and so on.
5) Hit RET when finished.


BTW In which case there is no "Tags: " prompt and it is needed to call
org-icompleting-read ?

Thanks.

--
Thierry

[Adam Porter]

On Friday, March 25, 2016 at 2:42:29 AM UTC-5, thierry v wrote:

BTW In which case there is no "Tags: " prompt and it is needed to call
org-icompleting-read ?

That happens when, e.g. entering a heading in an org-capture prompt.  There are probably some other org prompts that would activate it as well--I guess anytime org-icompleting-read is called by anything in org. 

[Anders Johansson]

Thierry Volpiatto <thierry....@gmail.com> writes:

> Now you can do it.
>
> So now to complete tags:
>
> 1) Call org-set-tags-command 2) Hit TAB after removing if
> necessary current tag from prompt. 3) Press RET to enter new
> tag. 4) Enter ":" or "," and hit TAB again to enter next tag
> and so on. 5) Hit RET when finished.

This means that both an extra TAB and an extra ":" has to be
entered for completing each tag.
What I liked about my old solution was being directly thrown into
helm and being able to add many existing tags quickly.

But I guess the current behaviour is a more reasonable and
expected.

> BTW In which case there is no "Tags: " prompt and it is needed
> to call org-icompleting-read ?

As Adam said, we only want this special behaviour for tags-calls
to org-icompleting-read. Checking the prompt is not that nice but
it works.

Cheers,
Anders

[Thierry Volpiatto]

Anders Johansson <mejlaa...@gmail.com> writes:

> This means that both an extra TAB and an extra ":" has to be
> entered for completing each tag.
> What I liked about my old solution was being directly thrown into
> helm and being able to add many existing tags quickly.

Yes, was nice, but once your choice were made, you couldn't remove the selected
tag, you had to C-g and start again.
This new behavior allow also to replace existing tags by new ones.
So all in one, I guess the new behavior is better, even if we have to
enter a separator (now you can use a space) and TAB for next tag.

> But I guess the current behaviour is a more reasonable and
> expected.

Yes.

>> BTW In which case there is no "Tags: " prompt and it is needed
>> to call org-icompleting-read ?
>
> As Adam said, we only want this special behaviour for tags-calls
> to org-icompleting-read. Checking the prompt is not that nice but
> it works.

Thanks for explaining, my org usage is very basic, though I couldn't find a
situation where I enter org-icompleting-read with our actual code...

Thanks.

--
Thierry

[Thierry Volpiatto]

Adam Porter <alphade...@gmail.com> writes:

> That happens when, e.g. entering a heading in an org-capture prompt.

How do you enter such a prompt ?

--
Thierry