lFind difference between a regexp error and not finding anything

[Carlo Hogeveen]

I have a macro programming problem that does have a laborious solution, but I am hoping/looking for a better one.

Context:
The eList macro shows the current buffer as a list, and shrinks the list each time the user types another character.
The typed characters are treated as a regular expression to search and shrink the list.
Some regular expressions justly find nothing, and eList should show an empty list.
But a half-typed regular expression can be illegal and therefore find nothing:
eList should not shrink the list but do nothing until the user finishes typing the regular expression.

Problem:
In the macro language there seems to be no way to distinguish between the lFind command getting an illegal regular expression and
justly finding nothing.
Both return 0, which is correct, and must remain so for backwards compatibility.

Laborious solution:
I could write a procedure that checks whether the search-string is a valid regular expression.
A further disadvantage would be, that this would make eList larger, and eList is also intended to be includable in other macros.

I have not been able to come up with a way around this.
For example, TSE does not have a queryable errorlevel or ErrorState that I am aware of.

That said, it cannot hurt to ask, so, is there a better solution?

Carlo

[Eckhard Hillmann]

Hi Carlo,

could it be an option to do it like isrch.s does,
what I mean is make the search options switchable?

Just the first thought that crossed my mind...

--
Best regards
Eckhard mailto:or...@ewetel.net


Ihre Nachricht vom Samstag, 25. Januar 2025 11:21:


CH> I have a macro programming problem that does have a laborious solution, but I am hoping/looking for a better one.

CH> Context:
CH> The eList macro shows the current buffer as a list, and shrinks the list each time the user types another character.
CH> The typed characters are treated as a regular expression to search and shrink the list.
CH> Some regular expressions justly find nothing, and eList should show an empty list.
CH> But a half-typed regular expression can be illegal and therefore find nothing:
CH> eList should not shrink the list but do nothing until the user finishes typing the regular expression.

CH> Problem:
CH> In the macro language there seems to be no way to distinguish between the lFind command getting an illegal regular expression and
CH> justly finding nothing.
CH> Both return 0, which is correct, and must remain so for backwards compatibility.

CH> Laborious solution:
CH> I could write a procedure that checks whether the search-string is a valid regular expression.
CH> A further disadvantage would be, that this would make eList larger, and eList is also intended to be includable in other macros.

CH> I have not been able to come up with a way around this.
CH> For example, TSE does not have a queryable errorlevel or ErrorState that I am aware of.

CH> That said, it cannot hurt to ask, so, is there a better solution?

CH> Carlo

[Carlo Hogeveen]

Thanks for the input!
That would solve a different problem, namely giving the user the option to not search for a regular expression.
If the user does want to search for a regular expression, the problem remains.
For example, while typing "{cat}|{dog}", the list goes empty twice.
That would be flashy and not pretty but perhaps acceptable.
An underlying problem comes from the requirement to remain as near as possible to each previous current line.
For that it would help to know if the lFind failed on an illegal regular expression like "{" or on not finding cats or dogs.

Carlo

--

---
You received this message because you are subscribed to the Google Groups "SemWare TSE Pro text editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to semware+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/semware/879451821.20250125114937%40ewetel.net.

[S.E. Mitchell]

> In the macro language there seems to be no way to distinguish between the lFind command getting an illegal regular expression and
> justly finding nothing.
> Both return 0, which is correct, and must remain so for backwards compatibility.

> For example, TSE does not have a queryable errorlevel or ErrorState that I am aware of.

I have updated TSE's internal error processing to set an error level
upon encountering an invalid regular expression.
To query it, check the DosIOResult() function. You would want to
check it immediately after calling any of the find/replace functions,
as the error level is also set by other functions.

This will be available in the next version.
--
Sammy Mitchell

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "SemWare TSE Pro text editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to semware+u...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/semware/000c01db6f12%24d4851eb0%247d8f5c10%24%40ecarlo.nl.

[Carlo Hogeveen]

Awesome!
Thanks,

Carlo



-----Original Message-----
From: sem...@googlegroups.com <sem...@googlegroups.com> On Behalf Of S.E. Mitchell
Sent: Saturday, January 25, 2025 1:19 PM
To: sem...@googlegroups.com
Subject: Re: [TSE] lFind difference between a regexp error and not finding anything

[Eckhard Hillmann]

CH> If the user does want to search for a regular expression, the problem remains.
CH> For example, while typing "{cat}|{dog}", the list goes empty twice.

If the user has the option activated while typing it surely could flash.
If the user has it turned off while entering the expression possibly nothing might be found,
only when he turns it on the regex takes place and may find something.
But then when the option is turned on and he starts to backspace trying to correct the input
we are back at the beginning. Even if we could move the cursor to correct the input it wouldn't
help.

Right now I think I can't find a (better) solution.

It's like you said before, life would be much easier to have a way to query if the expression
is/was valid. Sadly, at this point I don't know of any way to get this information out of SAL.

--
Eckhard mailto:or...@ewetel.net


Ihre Nachricht vom Samstag, 25. Januar 2025 13:05:


CH> Thanks for the input!
CH> That would solve a different problem, namely giving the user the option to not search for a regular expression.
CH> If the user does want to search for a regular expression, the problem remains.
CH> For example, while typing "{cat}|{dog}", the list goes empty twice.
CH> That would be flashy and not pretty but perhaps acceptable.
CH> An underlying problem comes from the requirement to remain as near as possible to each previous current line.
CH> For that it would help to know if the lFind failed on an illegal regular expression like "{" or on not finding cats or dogs.

CH> Carlo


CH> -----Original Message-----
CH> From: sem...@googlegroups.com <sem...@googlegroups.com> On Behalf Of Eckhard Hillmann
CH> Sent: Saturday, January 25, 2025 11:50 AM
CH> To: Carlo Hogeveen <sem...@googlegroups.com>
CH> Subject: Re: [TSE] lFind difference between a regexp error and not finding anything

CH> Hi Carlo,

CH> could it be an option to do it like isrch.s does,
CH> what I mean is make the search options switchable?

CH> Just the first thought that crossed my mind...

CH> --
CH> Best regards
CH> Eckhard mailto:or...@ewetel.net


CH> Ihre Nachricht vom Samstag, 25. Januar 2025 11:21:

CH>> I have a macro programming problem that does have a laborious solution, but I am hoping/looking for a better one.

CH>> Context:
CH>> The eList macro shows the current buffer as a list, and shrinks the list each time the user types another character.
CH>> The typed characters are treated as a regular expression to search and shrink the list.
CH>> Some regular expressions justly find nothing, and eList should show an empty list.
CH>> But a half-typed regular expression can be illegal and therefore find nothing:
CH>> eList should not shrink the list but do nothing until the user finishes typing the regular expression.

CH>> Problem:
CH>> In the macro language there seems to be no way to distinguish between the lFind command getting an illegal regular expression and
CH>> justly finding nothing.
CH>> Both return 0, which is correct, and must remain so for backwards compatibility.

CH>> Laborious solution:
CH>> I could write a procedure that checks whether the search-string is a valid regular expression.
CH>> A further disadvantage would be, that this would make eList larger, and eList is also intended to be includable in other macros.

CH>> I have not been able to come up with a way around this.
CH>> For example, TSE does not have a queryable errorlevel or ErrorState that I am aware of.

CH>> That said, it cannot hurt to ask, so, is there a better solution?

CH>> Carlo

CH> --

CH> ---
CH> You received this message because you are subscribed to the Google Groups "SemWare TSE Pro text editor" group.
CH> To unsubscribe from this group and stop receiving emails from it, send an email to semware+u...@googlegroups.com.
CH> To view this discussion visit https://groups.google.com/d/msgid/semware/879451821.20250125114937%40ewetel.net.

[knud van eeden]

Solutions / workaround

1. The user must explicitly type an 'end' of regular expression character, e.g.

 !

to indicate that user has finished typing. Because the TSE program can not know if the user has finished

typing or not.

otherwise

2. The user must continue typing even not seeing any output in the list,

and this user typing will continue until the user has finished that regular expression completely.

As soon as the regular expression is then valid again in between the user will see output in the list.

This is probably the best solution / workaround.

otherwise

3. Do not use regular expressions in the list, like it was before. That works good enough (for me at least).

4. Note: 

Changing the output of TSE LFind() from 0 to something else like -1 will as usual thus break backwards existing

TSE macros, where many depend on checking if the output is 0 and will then give a TRUE

if e.g. LFind() returns e.g. -1. 

Changing the behavior of existing native TSE keywords as has happened a few times in the past is as indicated a no-no thus, this gives very probably again very many (difficult to track) side-effects and should be avoided.

As a feature request is honored then better to create a new TSE keyword which checks in combination with e.g. LFind if the regular

expression is valid or not and use that.

with friendly greetings

Knud van Eeden

--

---

You received this message because you are subscribed to the Google Groups "SemWare TSE Pro text editor" group.

To unsubscribe from this group and stop receiving emails from it, send an email to semware+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/semware/000c01db6f12%24d4851eb0%247d8f5c10%24%40ecarlo.nl.