Edit[This]File() for unsupported file protocols

[Carlo Hogeveen]

Sammy and others,

I have this suspiciously shiny idea, that needs a critical look, and then perhaps your consideration.
TSE itself cannot open files with names that start with "https:", "sftp:", etc., and perhaps made-up file protocols.
TSE also cannot handle all existing file system capabilities, like Unicode filenames and ADS filenames.
This is not a new topic, but one I have a new idea about.

Would it make sense if:
1.
EditFile() and EditThisFile() would invoke a new _ON_EDITFILE_ hook after their possible prompt but before processing their
parameters.
2.
Two new functions were added to the macro language
GetEditFile([var?] string fn, integer flag)
SetEditFile([var?] string fn, integer flag)
that would get and set EditFile()'s and EditThisFile()'s two parameters.

The simplest case would be, that If the new hook recognizes in fn a file protocol it supports, then it can use the protocol to copy
the referenced file into a temporary file, and replace Edit[This]File()'s fn with the temporary file.
If the new hook wants to handle an error itself, then it can overrule Edit[This]Files()'s flag with _DONT_PROMPT_.
If and after Edit[This]File() opens the temporary file, an existing hook could rename it back to its protocol name.
If a user saves such a file and the protocol supports saving, then the existing _ON_FILE_SAVE_ and _AFTER_FILE_SAVE_ hooks can
already handle this.

A more elaborate case would be to first browse a referenced directory before handing a browsed-to protocol file back to
Edit[This]File() as a temporary file.

On the one hand this is not a theoretical idea: I came to it working on a macro that could be changed to use one such so-far shiny
looking possibility.
On the other hand my time is not such, that an immediate stream or even trickle of TSE extensions would follow.

The benefit of these cases would be, that to the user TSE's existing interface could edit extra file protocols and/or extended
existing file protocols.

Carlo

[Carlo Hogeveen]

After a good night's sleep the idea still looks shiny, which is promising.
That said, details came up.

1.
It can only be implemented in a user-friendly way, and therefore at all, if TSE's _EDIT_HISTORY_ can remain the user's input and not be fed by the hooks replacement input.

2.
Besides for EditFile() and EditThisFile(), logically the same hook should also be implemented for InsertFile(), SaveBlock() and SaveAs().

3.
Alternatively I worked out how to implement my own versions of these statements as a macro.
Its disadvantages would be a clunkier programming interface, and no automatic implementation in existing user interfaces and macros.
Its advantages would be a better separation of concern between native TSE and extensions using the macro, and even more freedom for me to extending these statements.

Hmm,
Carlo

[S.E. Mitchell]

This sounds like a great idea.
I'll work on implementing it.
What should the hook be called?
--

> --
>
> ---
> 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/000e01dc263c%24b00800c0%2410180240%24%40ecarlo.nl.

[Carlo Hogeveen]

Firstly, I must retract the part of my proposal to also implement the new hook for the SaveBlock() and SaveAs() statements.
Their file redirection can already be handled by the _ON_FILE_SAVE_ and _AFTER_FILE_SAVE_ hooks.
So the statement scope becomes EditFile(), EditThisFile() and InsertFile().

My best new hook name remains _ON_EDITFILE_.

Let's reiterate and focus on the requirements.
An assumption and requirement is, that the statements already handle their existing steps in the given order.

Statement steps for EditFile(), EditThisFile() and InsertFile():
The user provides a file parameter string to the statement directly or through a prompt.
The statement adds the file parameter string "as is" to _EDIT_HISTORY_.
New: The statement calls all procedures that implement the _ON_EDITFILE_ hook following existing hook processing rules, and enables that the file parameter string and the flag parameter integer can be changed outside the statement.
The statement processes the file parameter string and the flag parameter integer.

The macro language provides two new statements, the names of which match the hook name,
GetEditFile( var string fn, var integer flag)
SetEditFile([var?] string fn, [var?] integer flag)
that get and set EditFile()'s, EditThisFile()'s and InsertFile()'s two parameters.

Carlo

[S.E. Mitchell]

Thanks for the additional details.

Here is my first pass - something like this - lots of details to be worked out.

char *g_cmdline;
int g_flags;

// when called the cmdline has already been added to history
// called by EditFile() and EditThisFile()
int sys_editfile(char *cmdline, int flags) {

...

g_cmdline = cmdline;
g_flags = flags;

ExecHook(EVENT_ON_EDITFILE);

cmdline = g_cmdline;
flags = g_flags;

//continue processing

...

// just before exiting:

g_cmdline = NULL;
g_flags = 0;
}

//similar code for InsertFile()

void GetEditFile(char *fn, int flags) {
fn = g_cmdline;
flags = g_flags;
}

void SetEditFile(char *fn, int flags) {
g_cmdline = fn;
g_flags = flags;

> --
>
> ---
> 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/000601dc26e4%24b3a05360%241ae0fa20%24%40ecarlo.nl.

[Carlo Hogeveen]

Looks consistent and promising!

Carlo