Bug in TSELOADIR handling since TSE 4.50.1

[Carlo Hogeveen]

Rest assured that I am not looking for bugs.
I am just programming my latest macro, doing my due diligence in anticipating and testing relevant situations, and seem to be on a
streak bumping into TSE bugs.
I this case I was creating a macro's own .ini file, which according to TSE rules also must by findable thru TSELOADDIR, and testing
went off-script again.

To reproduce the bug I followed a variation of the instructions for the 2nd "potentional need" in TSE's help topic "Augmenting the
Editor Load Directory", the one for a multi-user version in a network.
I installed TSE 4.50.5 as a user in "D:\Tse4.50.5", and selected all the default answers.
Then in a cmd prompt I gave these commands:
D:
cd \
mkdir D:\TSeClient
cd TseClient
set TSELOADIR=D:\TseClient
copy D:\Tse4.50.5\*.dat
copy D:\Tse4.50.5\synhi\*.syn
copy D:\Tse4.50.5\spell\*.lex
D:\Tse4.50.5\g32

The bug is that no macros are found.
At start-up cuamark is not found, and when trying to use the editor other helper macros like compile and iconfig are not found.

Doing these steps with TSE 4.50 and lower versions of TSE works fine.
Doing these steps with TSE 4.50.1 and higher versions of TSE reproduces the bug.

Carlo

[S.E. Mitchell]

Found it! Will be in the next version.
Wish I could come up with a test for it in sanity, but can't think of
an easy (or hard for that matter) way to check it.
Anyway, thanks for the report!
--
Sammy

> --
>
> ---
> 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/000501dbb63e%2475693ba0%24603bb2e0%24%40ecarlo.nl.

[Carlo Hogeveen]

> Wish I could come up with a test for it in sanity

https://ecarlo.nl/tse/DemosAndTests.html#sanity_tseloaddir
correctly finds the bug in Windows TSE v4.50.1 thru v4.50.5,
and correctly does not find the bug in Windows TSE v4.50 and lower.

It does not find the bug in Linux TSE v4.50.1.
I do not know what to think about that.

Carlo

[S.E. Mitchell]

I need a play-by-play - what does it do?
Thanks!
--
Sammy

> --
>
> ---
> 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/000001dbb6b9%24e18cd5f0%24a4a681d0%24%40ecarlo.nl.

[Carlo Hogeveen]

> I need a play-by-play - what does it do?

Maybe it makes the most sense if I drill down.

1.
The high-level explanation is, that it pauses with a warning if it finds the bug, and then finishes.
If it does not find the bug, then it displays a 2-second "OK" message and just finishes.

The macro will not work if you make it part of another macro, because then its references to CurrMacroFilename() will no longer work correctly.

2.
The mid-level explanation is, that it reproduces the steps as described in the second bullet-point of the TSE help topic "Augmenting the Editor Load Directory", but minus the 3 copy statements that are unnecessary for just a test, and plus a temporary rename of tseload.dat to avoid unnecessary error-messages from not-found autoload macros, and plus a Dos() call of TSE itself with a "new" macro, that reproduces the bug (or not) with a SearchPath() of the new macro itself.

Steps:
The macro sanity_tseloaddir is compiled and executed.
Because the macro sees that it is not started from the command line, it starts prepping the bug-reproducing environment.
It creates a new temporary directory tmp_dir based on the user's environment.
In directory tmp_dir it creates a sanity_tseloaddir.cmd file.
The contents of sanity_tseloaddir.cmd are also based on the user's environment, for example:
C:
cd <tmp_dir>
set TSE_LOADDIR=<tmp_dir>
<path to>\g32 -e<path to>\mac\sanity_tseloaddir.mac
(Calling TSE with a TSELOADDIR environment string, that points to an empty directory, would triggers the bug when TSE searches for macros, but we gave it a start-up macro with a hard path.)
Around calling sanity_tseloaddir.cmd, the file tseload.dat is temporarily renamed, so that the new TSE session will not try to search and load TSE's AutoLoad List macros, and thereby prematurely trigger the bug too many times.
Then we do it:
Macro sanity_tseloaddir.s in the 1st TSE session calls command file sanity_tseloaddir.cmd, which starts a 2nd TSE session with a prepped TSELOADDIR environment and the start-up macro <full path>\sanity_tseloaddir.mac.
This time around, because sanity_tseloaddir.s sees that it is started from the command-line, it simply tests the bug with a SearchPath() statement that simulates how TSE searches for macros.
If the SearchPath() fails, then it pauses with a warning, otherwise it only displays a 2-second "OK" message.
Then this 2nd instance of the macro abandons the 2nd instance of TSE (and thus itself).
This ends sanity_tseloaddir.cmd, returning control to sanity_tseloaddir.s in 1st TSE session.
The macro cleans up the temporary directory and exits.

This seems enough detail for now.
Let me know of any points that need further clarification.

Carlo