Support sublime text build system variables in "save_location" about exporthtml HOT 3 OPEN

Ah, I think I understand now. I don't actually ever use the save feature. I honestly forgot I had already implemented a save until you mentioned I did. So yeah, we can probably incorporate variables.

@gir-bot remove S: triage
@gir-bot add T: feature, P: low

from exporthtml.

More specifically, can you elaborate on what feature you are requesting? And how you imagine it would work?

I get the impression you want to save the exported HTML to a file? If I did this, I'd probably just prompt the user with a save file dialog via the sublime.save_dialog API. Granted, this is a new API command in ST4 (in Beta and available on Sublime's Discord server), but that is probably the way I'd go. The starting directory could be configurable and such.

from exporthtml.

I specifically would like to use the $folder or $project variable to specify a directory which is relative to the opened file or project to store all the exported HTML files. For example, if I have a folder opened in ST like this:

Some Project  # $project_path, $folder
├── Some Project.sublime-project  # $project
├── src  # $file_path
│   ├── main.py  <- opened file
│   ├── test.py
│   └── ...
└── HTML
    ├── main.py.html
    ├── test.py.html
    └── ...

In this example, I would like to save exported HTML files to the HTML sub-directory of the project directory, if these variables are supported, this can be specified by either $project_path/HTML, or $folder/HTML.

The current implementation seems only supports saving files to the same directory as the opened file, or an absolute path if specified, and relative paths are also not supported.

It would be useful if I could manually pick the directory on save every time, but I think it would be more useful if I could just specify a relative path to either the opened file or the project directory, and just export them as usual. Also, using these variables is the standard way of implementing it (used by many other ST extensions for similar feature), so I suggest to implement the feature in this way instead of only supporting relative paths.

from exporthtml.