search

JamesDoingStuff / tree-sitter-topas

0 stars 0 forks source link

feature request #20

Open johnsoevans opened 1 week ago

johnsoevans commented 1 week ago

Hi James. Garry/Dean/Phil shared your github repo with me this morning for the TOPAS project.
There are a couple of INP file highlightings in jEdit that it would be useful to replicate eventually:

  1. For big files I normally have autofolds which are closed by default on opening. They look like: '{{{ a description of what's in next section ... '}}}
  2. In template INP files (see e.g. https://topas.awh.durham.ac.uk/doku.php?id=templates). I use the symbol below to mark somewhere user has to put in information and colour it purple: -> text to replace.
JamesDoingStuff commented 4 days ago

Hi John, thanks for getting in touch. Sorry for the delayed reply, I had some time off and have been working on the site keyword since. To address those features:

  1. Currently these would be highlighted as two individual line comments. I'm not sure how they appear in jEdit, but I could make the description text a different colour if that'd be useful? As for auto-folding, Tree-sitter can be used to provide folding (in Neovim at least), but it's not something I've had a chance to look into. I suspect it'd be rather tricky to implement with the autofold blocks, as it would mean treating everything inside them separately to the rest of the input file, which would likely cause problems if the block contains keywords that the parser is expecting to appear.

  2. These may be challenging to highlight, depending on how they work - are they treated like comments, with the user having to remove the arrow before running the file? Or does the arrow effectively just cause the line to change colour, but still requires it be valid TOPAS code?

johnsoevans commented 1 day ago

  1. Having the '{{{ highlighted as two comments is fine. This is how they appeared in jEdit. jEdit used just the {{{ as one of it's folding triggers so it was easy to switch between the two views in the image below. It may be easiest just to do this with a vs-code extension. image

  2. The arrow is just to change the colour of the following text to purple. The text doesn't have to be valid topas code. It's just there to flag to the user that they have to change that line of text.

JamesDoingStuff commented 1 day ago

Understood, thanks. In that case I think that, for now at least, I'll implement both features as comments. I'll add a query tag to allow users to highlight the arrow comments differently to other comments, but since highlight colours are controlled locally, I can't set them to be purple automatically, unfortunately. If I get a chance though, I'll upload a config file that matches the jEdit scheme.

keeble commented 1 day ago

Just a thought on the folding... is it imperative @johnsoevans that this {{{}}} syntax specifically is supported, or that folding itself is supported?

@JamesDoingStuff since the treesitter can understand the syntax, can we define grammatical concepts which can be folded such as macro definitions or str blocks etc? If possible, this solution would be nicer I think, because the folding would then follow standard patterns in the editor of choice; and would not introduce new syntax specifically to accommodate this.

johnsoevans commented 1 day ago

I agree that folding automatically on major things like xdd, str, etc would be great. The ‘{{{ would just be nice to have for legacy reasons as I have 100s of files that use it. It also lets a user put in their own arbitrary folds for thing treesitter wouldn’t be able to recognise. It’s not a big deal for treesitter as I think we can just do it in a vscode extension.

JamesDoingStuff commented 1 day ago

since the treesitter can understand the syntax, can we define grammatical concepts which can be folded such as macro definitions or str blocks etc?

Neovim certainly supports this type of folding, not sure for other editors. It works using the same query language as highlighting, so a folds.scm file containing a query 

(macro_body) @fold

would collapse all the contents of macro definitions. Most keywords are still lacking structure at this time, but eventually the same method could be used with them. As for the '{{{ method, this parser will mostly just ignore them as it stands. I don't think any folding capability can/should be added to those via Tree-sitter.