Planning any support for XML?

[luc0x61]

It was just an idea that sparked to mind seeing this tool.

[fioncat]

XML is not easy to handle because its tags may contain attributes, for example: <tag field1=value1>value2</tag>. When displaying it as a tree structure, how should field1=value1 be presented? At the moment, I don’t have a good idea.

[fioncat]

Hi, the XML is now available in v0.5.2.

[luc0x61]

I gave it a try with the attached XML, but... oh well, parsing is not exactly what I expected.
Yes, I know there's a lot of fuss with XML scheme/version at the beginning of it: maybe you'd like to try it yourself

cproject.xml

[fioncat]

This file can be parsed. Can I ask what your expectations are?

You can checkout the xml parse rule in the release note: https://github.com/fioncat/otree/releases/tag/v0.5.2

[luc0x61]

Oh well, then I have a different behavior here

Running version 0.6.1 on Win 11, in text console with cmdr/clink, but the behavior is the same running on a default cmd.exe terminal window.
I also tried forcing otree -t xml cproject.xml, but I have the same results 🤷‍♂️

[EDIT]

I suspected something strange in the user interface, and I discovered that pressing "Enter" showed for a while an inner selection...
Then I pressed Enter and without releasing, I tried navigating with arrows, but the most I got was this

After that, if I press up/down arrows to navigate, it jumps over some items (I see for a while an update on the right pane, then it moves down to the next).
I assume that parsing is fine, while key navigation has some compatibility issues on Windows.

[EDIT]

I confirm that from Windows Terminal (which I unfortunately use rarely), it works better, at least because the mouse interaction works everywhere, while the keyboard interface still skips items while navigating. And the default font settings render better graphics characters.

[fioncat]

Strange, I suspect it might be related to character encoding? Certain encodings might behave differently on Windows compared to Unix-like systems.

Unfortunately, I don't have access to a Windows environment at the moment, so I'm unable to debug this issue. Could you please confirm what character encoding the problematic terminal is using?