If you want to move around in strings, you might want to use a ReadStream.

In some Smalltalk systems there is a method called #skipToAll:.

Here's how mine starts out:

�� �� skipToAll: aSequence
�� �� �� "If the remaining elements can be parsed as <a><aSequence><b>,
�� �� �� ��return true leaving the position where?�� Otherwise return false. �� �� ��
�� �� �� ��GNU Smalltalk, Dolphin, and VisualAge:
�� �� �� �� ��leave the position after <aSequence>, consistent with #upToAll:,
�� �� �� �� ��and implementable in this class. ��(GST uses the KMP algorithm.)
�� �� �� ��VisualWorks and ST/X:
�� �� �� �� ��leave the position before <aSequence>, inconsistent with #upToAll:,
�� �� �� �� ��and only implementable for positionable streams. �� �� ��
�� �� �� ��Squeak 5.2 and Pharo 6.0:
�� �� �� �� ��not provided.
�� �� �� ��I cannot be compatible with everything.�� The semantics of 
�� �� �� ��#skipToAll: should obviously match #upToAll:, so I'll fit
�� �� �� ��in with GNU, Dolphin, and VisualAge Smalltalk.
�� �� �� "

So

������ (myReadStream skipToAll: 'marker')

���������� ifTrue:�� [loc := myReadStream position]

���������� ifFalse: [alternative code].

HOWEVER, I have a bad feeling about this.�� The entire approach, as with much

concerning strings in a Unicode age, seems fraught with peril.�� Consider

input = 'the need for vigilance is never-ending'

marker = 'end'

Should the marker be found or not?

input = '.... Si<floating acute accent> ...'

marker = 'Si'

Should the marker be found or not?

My code is NOT sensitive to these issues.

I would like to say that it was because I was writing a compatibility

method, so my code was compatibly broken,

but to be honest, I was stupid and forgot to think it through.

I would think that there would need to be an '... asTokens: aBoolean'

variant that checks that a match

��- is not followed by floating diacriticals

��- is not preceded by an alphanumeric if the target begins with one

��- is not followed by an alphanumeric if the target ends with one.

My own preference is to write a lexical analyser for the mini-language

I'm using, and NOT try to hack at it using general-purpose string

methods.

Perhaps you can tell us more about the context?�� What is the application-

level task you are trying to solve?

On Sat, 1 Jun 2019 at 22:01, Tim Mackinnon <tim@testit.works> wrote:

Maybe this is a dumb question - and often I��m surprised when asking these, but why is there no way to ��find after�� a string.

I find it rather boring to try and parse a string, after a known marker - thus:
(loc := aString findString: ��marker��) > 0 ifTrue: [ loc := loc + ��marker�� size ].

Is there a better way? This whole pattern seems very old and clunky and not smalltalk like?

Couldn��t we have: findAfter: aString ifAbsent: aBlock ?

Or is there a whole better pattern for string searching that I��m missing ?

Tim