Bug #260

Mark preceding tag red

Added by Cambell Prince over 2 years ago. Updated over 1 year ago.

Status:New Start:06/09/2009
Priority:Low Due date:
Assigned to:- % Done:

0%

Category:- Spent time: -
Target version:V1.1.x
Resolution:

Description

Mark both the offending tag AND the preceding tag red, since very often the cause of the problem is really the preceding tag. E.g. if \bw is stuck in the middle of a sense just before \de, \de is the one marked in red. I think both should be marked red, though I don't mind that \de will be listed as the culprit in the bottom-left pane.

History

Updated by Cambell Prince over 2 years ago

I agree that it is somewhat confusing that the marker highlighted is not the 'culprit'. However, it is the marker that could not be placed in the structure - for whatever reason. I don't think Solid is smart enough to figure out what the cause of the error is - it simply states what it couldn't do.

Updated by Cambell Prince over 2 years ago

Jon: I agree that SOLID shouldn't try to be that smart, but that's why I suggested simply making both markers red. This reminds the user to think about both of them, rather than only about the second one, since the first is often the culprit. If you don't like making the first one red, you could make it orange or pink or something. The orange/pink font would mean "SOLID doesn't have a problem with this field, but it may be causing the following field to be invalid."

Updated by Beth Bryson over 1 year ago

Well, I guess it depends somewhat on who the audience is. I have gotten accustomed in other domains to looking higher up for an error that is flagged lower down. I think this is something SOLID users can be taught. Often it's not the immediately preceding tag that is the problem; it could be something even earlier. I think coloring the preceding one could be misleading sometimes, and could better be handled just by education. Maybe a movie could even be developed to demonstrate how this works, and some of the principles to use for tracking down bugs like this. (Someday, or by a user who thinks it would be a good idea...)

Updated by Cambell Prince over 1 year ago

  • Target version set to V1.1.x

One thing I think we can do here is to unwind the preceding marker - pretend it wasn't there - and then try and place the current marker. If this is good, we can then mark the preceding marker as being poorly placed, and carry on the check as though it wasn't there.

Also available in: Atom PDF