Tags 2: The return of the tags #342
Conversation
You can now embed tags within the task description without them highlighting the entire row
| tag = match.group(0) if match else '' | ||
| tag = '' | ||
| if 'tag.todo' in self.view.scope_name(point): | ||
| reg = self.view.extract_scope(point) |
There was a problem hiding this comment.
This is not reliable enough, e.g. there is option to show date preview for due tag within paranthesis "due_preview_offset": 1, as I mentioned in prev pr phantom will change result of extract_scope.
We also should always expect that view may be affected by other plugins so even if user has default "due_preview_offset": 0, still there might be other phantoms.
I think we could try to use view.find method, i.e. check if cursor is on tag then search @ which is related to this tag (it will be either somewhere on left side of cursor or it might be exactly on right side of cursor), then the point of @ is a starting position for view.find which allow to use the regex from syntax, i.e. with atomic group etc. Right?
There was a problem hiding this comment.
The whole thing is a workaround to get it working with the re module.
Phantoms only appear after @Due tags, right? That can be worked around with a one time hack if thats so.
Using view.find will work as long as no phantoms throw off the regex. The key feature missing is the regex recursion that makes it all super easy. Probably a much better solution
A more permanent solution is to remove all phantoms at the beginng of the function and put them back at the end which I think is what the other function does? Means the issue should never resurge. Having a single function to reapply the phantoms or just store them and redraw.
Having "due_preview_offset": 1 means that date is inside the brackets while also next to your current text. This works great for @due(+2) but less good for any with short dates as you end up with both dates in the bracket, 
Does the setting need to effect every date? Does look strange with two dates in the brackets but that's why it's a setting.
There was a problem hiding this comment.
How about this @\w+((\((?=([^()]*))\3|[()]*\))*) — it works with re module and seems suitable?
It behaves as your alternative version, which seems alright to me since the last pair of parenthesis is not separated from the tag, there is no whitespace so we can consider it is a part of tag.
What your thoughts are?
Phantoms only appear after
@duetags, right?
No, phantoms may appear anywhere, because any plugin can add any phantoms to any views; and it is not possible to fully access existing phantoms.
Using view.find will work as long as no phantoms throw off the regex
Phantoms do not affect search in any way, afaik, only scopes boundaries.
less good for any with short dates as you end up with both dates in the bracket,
The preview is supposed to be displayed only if the existing text will be replaced after pressing tab. I would imagine it has problems due to date format and improper use of dateutil.
There was a problem hiding this comment.
I'll be taking a break for the exam period but I'll finish up a few improvements when I get time. I've got a in-dev copy that works for just the settings I want but I'll need to polish it so it works for the master release
Tags fixed up, no regex dependancy. Includes #341 #340
Currently only highlighting the first set of brackets after @tag.
alternative version which matches
@tag(a(b))()entirelyThere are other bits too but I'm pushing this before tomorrow. Seems like everything is working perfectly though.
A side effect of this is that the tags are much tigher and include no trailing whitespace (for regular tags)