Bug 221989

Summary: [implementation] PatternRule does not unread all characters in endSequenceDetected
Product: [Eclipse Project] Platform Reporter: Boris von Loesch <vonloesch>
Component: TextAssignee: Platform-Text-Inbox <platform-text-inbox>
Status: ASSIGNED --- QA Contact:
Severity: minor    
Priority: P3 CC: daniel_megert
Version: 3.3.1   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Boris von Loesch CLA 2008-03-09 17:11:56 EDT
Build ID: M20070921-1145

Where:
org.eclipse.jface.text.rules.PatternRule#endSequenceDetection

More information:
If there are escaped characters the method uses scanner.read() (Line 246 & 252) but does not increase readCount (Line 242). In the case that the rule does not apply, some characters will then not unread. A simple readCount++ in Line 253 should solve this problem.
Comment 1 Dani Megert CLA 2008-03-11 14:17:07 EDT
Do you have a scenario or test case?
Comment 2 Boris von Loesch CLA 2008-03-11 16:30:29 EDT
(In reply to comment #1)
> Do you have a scenario or test case?

No, but as far as I understand the PredicateRule system it should unread all characters if the rule does not apply. This does not happen here, so it seems to be an error. If you want, I can try to construct a testcase.
Comment 3 Dani Megert CLA 2008-03-12 04:29:37 EDT
>If you want, I can try to construct a testcase.
Yes, please as we did not have a problem so far in any product that uses this rule. So not much reason to touch it ;-)
Comment 4 Eclipse Webmaster CLA 2019-09-06 16:05:28 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.