ENB: LeoJS and #3235: Leo's os.path wrappers

[Edward K. Ream]

This Engineering Notebook post discusses topics relating to transliterating Leo to Typescript on vs-code. These issues became apparent while working on #3235.

This ENB will be background for discussions between Félix and myself.

Background

Leo's g.os_path_* functions differ from the corresponding os.path.* functions in Python's standard library. Alas, removing these differences is likely to be difficult or impossible.

g.os_path_normslashes converts backslashes to forward slashes, but only on Windows. We might explain this behavior by saying that Leo's core uses only forward slashes. But I have my doubts.

g.os_path_join(*args, **kwargs) augments os.path.join with two hacks:
- '!!' prepends g.app.loadDir to the list of paths.
- '.'  prepends c.openDirectory to the list of paths, provided there is a 'c' kwarg.

Imo, only leoAtFile.py should support these conventions. They make no sense otherwise.

c.expand_path_expression evaluates so-called path expressions appearing in @file nodes. Such expressions are security risks because they can contain arbitrary Python code. Leo deserves a safer alternative that will work without Python support in vs-code.

Principles

Several conflicting principles apply:

1. Don't break existing code (or outlines) without compelling reasons.

2. Don't enshrine dubious code or design forever.

3. Re-evaluate little-used features that may be difficult to port vs-code.

4. Make minimal changes to Leo.

Summary

I will make no significant changes to Leo without consulting Leonistas first. This post only starts the conversation. Félix and I will certainly discuss these issues at length.

Changes to Leo g.os_path_* wrappers are dangerous. They could break existing scripts and plugins and change the meaning of .leo files. This post omits many tricky details.

Otoh, LeoJS may be obliged to change some of the routines mentioned here: vs-code can not use Python exactly as Leo does.

Your comments, please.

Edward