Open aireilly opened 1 year ago
I guess this is already here with the User/Asciidoctor.sublime-settings
file :/
What would be the expectation of this feature be for ST? to resolve include
directives in order to open files in the editor?
If that's the case, it should be doable since I've seen various plug-ins doing it, based on the native ST search results, which allows to open a file at a specific line by clicking on the underlined results.
As for images previewing, I think that would only work as a means to open the image in the editor, since ST now supports previewing some image formats on independent tabs — but I don't think it supports inline images, since unlike VSCode it doesn't rely on a true browser component but on a proprietary rendering engine with limited HTML support.
For images, we'd only need to establish the value of the :imagesdir:
attribute — i.e. assuming that's defined on the document header and not via the CLI. There could be a fallback mechanism, like suggested in the linked Issue, e.g. reading a project configuration file (either a native ST project file or a dedicate extension settings file).
Most likely, it's hard to find a solution that works with every workflow, since everyone has its own way to handle AsciiDoc projects. I mostly use Rake to handle my projects, but ST leverages Python, so it might be sub-optimal to expect an interaction between the two languages.
But I think the idea is good, but might need some thought on how to approach for ST specifically.
For my personal use case, I'd like to see:
Autocomplete attributes. Right now, I have a kind of hacky set up where I generate attribute snippets: https://github.com/aireilly/asciidoc_sublime_snippets/blob/master/scripts/generate-asciidoc-snippets.py.
Can you integrate it into this repository via a pull request?
Ideally, ST should pick up defined attributes in an AsciiDoc project.
Probably the hackish solution is good enough. I doubt it's possible to come up with a perfect solution, given the complexity that AsciiDoc project can reach (nested attributes, conditional attributes, CLI-defined attributes, etc.). Your proposed solution seems good enough for most projects, making developers' life easier when handling large projects that don' depend on advanced definitions.
In order to have a package that fully covers AsciiDoc features it would have to rely on an LSP server — which I believe would be very difficult to implement, since it would have to be real-time efficient (possibly, in a compiled language) and gracefully downgrade when incomplete or invalid constructs are found.
Sure! I think I have a bunch of stuff that would work in the repo actually. I will PR some things in.
It would be really nice to implement a feature similar to VSCode/Intellijel
.asciidoctorconfig
in ST4-AsciiDoctor.https://github.com/asciidoctor/asciidoctor-vscode/issues/380