Use zsh native syntax highlighter?

[rocky]

Currently in zshdb, pygments is used for zsh syntax highlighting. It is optional.

In addition, or instead, zshdb could use zsh's native syntax highlighting. See https://github.com/zsh-users/zsh-syntax-highlighting

However when this is in effect the set/show style would probably be disabled or perhaps using pygments would only kick in after setting a pygments style. Something similar goes for set/show highlight.

Any volunteers? @psprint ?

[psprint]

Currently I'm doing "one more subsystem for Zplugin" thinking, for a week now. I'm trying to make Zplugin additionally sophisticated. So I'm pretty tired after implementing previous updates and now during this strive for one more. Maybe you would have some idea for a feature for Zplugin, who knows?

After that and few days rest I could work for zshdb. I've used it with fast-syntax-highlighting to track the state machine there, it went well. There was one thing, I needed to convert FSH highlighter into a script, couldn't debug it as function. Not sure if this is solvable.

BTW, zshdb is a large project, and it looks like it can much benefit from zdharma/zshelldoc. I generated the documentation (single command in lib/: zsd *.sh) and commited it here:

https://github.com/zdharma/hacking-private/tree/master/zshdb

It somewhat reveals that some index.adoc or something could be a good idea for zshelldoc. Asciidoc looks even better when converted with asciidoctor, here is example: http://zdharma.org/Zsh-100-Commits-Club/Zsh-Native-Scripting-Handbook.html

[rocky]

I am not a big zsh user. (I don't use it as my default shell for example). So unfortunately I wouldn't know what is there and what might be added. In fact I just learned of and looked up Zplugin just now.

Perhaps you should open a zshdb issue concerning problem with FSH highlighter run as function. A priori I don't know if it is solvable or not. But probably if we can isolate the problem, it will be clear and possibly can be fixed.

As for the documentation, there is extensive command documentation which is also available inside the debugger's help system.

But I think you mean API documentation. For that, I have opened Issue #14 .

As for working on zshdb, there's no hurry. No one is working on it, although I am surprised that it is as popular as it is given that haven't worked on it in a long time and generally do that only in conjunction to passes in bashdb.

Since I don't really have a passionate desire to learn any more zsh than is needed to get the job done, I am sure there are lots of ways the code could be improved.

However, I'll mention one caveat: since the code base here is largely the same as bashdb and kshdb, I try to use common POSIX idioms. Of course there have to be differences to handle aspects not specified in POSIX, such as ways to access the call stack, or list keys of a hash.

What I have found over time and I think what you will see, is that often zsh has a more idiomatic way of getting stuff than the way that I have stumbled upon. Please feel free to fix that. Or review the code and make pull requests.

[psprint]

I'm slightly disappointed about the level of attention you described that zshdb gets. I could invest time in this project as I'm seeing scripts -> real-software switch happening, and want to boost it, like I described here in zsh-users post, and zshdb perfectly matches this. I will try anyway, maybe it will be cool to code this project, if I manage to hook up somewhere and start.

Yes it was about API docs. For contributors and interested people. If I ask someone I typically get answer that call-trees much help and the docs are OK.