delete a subtask with selection on the arrow leaves the arrow

Since my bug report was a duplicate of this one, I'll try and describe my observations here instead. First off, this bug is quite irritating for someone like myself who apparently cannot type :). However, I'm having a hard time figuring out where the problem is.

From what I can tell, the subtask is converted back into normal text, arrow and the rest of the text, when the first character of the Subtask's text is deleted. The same behavior is exhibited when you move your cursor after the character and press backspace, or if you move before the character and press delete, or if you highlight the character and press any of backspace, delete, or ctrl-x.

Its almost like something is happening to the tags when this character is being deleted. Is it possible that the indent tag ending is being removed and the subtask tag beginning is being removed too?

The code in _delete_range() looks to be the reason why the task is being deleted from the list...since it had been deleted, the modified function does not properly tag it again later.

There is an if statement that is checking for is_subtask tags, and if the iterator is at the beginning of the tag. Is so, then the subtask is deleted. There probably needs to be another check if there any further text of the line after the iterator.

Revision 712 of trunk has another side effect when deleting the first character of the subtask within the task editor..

I get a new task that shows up in the task tree but it only has the first letter of the task. The task seems to be deleted, since double clicking on this item shows the task i decided to replace it with. Of course, I get the real task in the task viewer also, with all the correct information displaying.

I also get the following error:

*** Node 189@1 not in vr and no path for parent
*** please report a bug against FilteredTree

Restarting gtg seems to clean things up, or changing the filter set, if you're viewing via tag selection.

Out of curiosity, what if the behavior of the editor changed such that hitting enter on a line with a subtask does not automatically create another subtask. Instead just go to the next line and require a dash to be entered to create another subtask.

I think personally, I'd like that to be the behavior, mainly due to the fact that typing in a subtask line seems to be much more processor intensive than typing a normal line that ends up being converted to a subtask later.

I had added a solution, but not was the ideal solution. The problem is that _delete_range is executed after the delete_selection then the subtask is deleted after the selection and the selection can't be totally deleted.