[Info-vax] in-memory editing with EDT or EVE

[Arne Vajhøj]

On 11/23/2024 9:54 PM, Craig A. Berry wrote:
> On 11/23/24 6:53 PM, Arne Vajhøj wrote:
>> On 11/23/2024 3:16 PM, Craig A. Berry wrote:
>>> There is no "client."  In a DVCS like git, when you commit a change,
>>> everything is written locally.  Pushing to a server is an optional
>>> separate operation and what you push is the version history that has
>>> been written locally first.  There is never a point where the commit
>>> message is sent over the network to another machine before being stored
>>> as one component of a commit.
>>
>> OK. I am still thinking SVNish. Sorry.
>>
>> But does it matter?
>>
>> edit disk file--read disk file--write to local repo
>> vs
>> edit in memory--write to local repo
>>
>> still seem like a difference to me.
>>
>> Or is git external editor actual editing the final file
>> inside the repo?
> 
> As I tried to explain before, a git commit consists of the metadata
> (author, timestamp, etc.), the commit message, the branch, and the
> actual diff content of the changeset.  All of the other pieces are
> stored on-disk, so it's hard to see a reason to keep the commit message
> in memory when it needs to be combined with the other pieces in order to
> produce the commit.

I am thinking differently.

Let us say hypothetical that you were doing a code review of some
code and you noticed that function A was passing a string to
function B by having A write it to a temporary file and B reading
it from the temporary file. Both A and B are doing lots of other
IO so the overall performance impact is insignificant. Would you
approve the code? I assume not.

In that case it is obvious funky because passing a string
between functions is very basic.

Doing in memory editing is not quite as basic. But it is possible.
With EDT and TPU on VMS.

So I was thinking that maybe it is still funky to do it
that way.

> It should also be mentioned that the editor used for editing commit
> messages is configurable, so git's process for producing a commit needs
> to work with any and every editor.

I know. That was the topic in one of the VSI forum threads.

I am not expecting GIT to change.

Very few editors will be callable and allow for a custom fileio
function.

And:

if ((OS = "VMS") and ((editor = "EDT") or (editor = "TPU))) then
     use callable editor on in memory data
else
     use external editor on temp file
end if

is not pretty.

> What problem are you trying to solve by keeping a kilobyte or three in
> memory instead of persisting it to disk where any and every utility in
> the toolbox can operate on it?

I am not really trying to solve a GIT problem. GIT works. And
VMS is not an important platform for GIT.

More like using the GIT editor case to point out that the
standard VMS editors has some nice capabilities, that could
be useful for somebody.

If somebody have a program that need to allow user to
edit data and the program is VMS specific and the target
editors are EDT and TPU, then maybe doing the edit in
memory makes sense.

You can still argue that both subprocess with external editor
and temp file or simple callable editor editor with temp file is
simpler code wise using just the VMS provided API's and
not some wrapper found on the internet.

But I like multiple options.

Arne