Evennia Docstringer for Windows

[Tristano Ajmone]

Hi everyone,

I'm glad to announce the first release of Evennia Docstringer (Alpha 1):

https://github.com/tajmone/Evennia-Docstringer

It's Windows standalone tool for generating Python docstrings capturable by Evennia autohelp.

You work in 3 panes: (1) raw input (where you type and don't worry about line-wrapping); (2) docstring preview (where you see the wrapped final docstring), and (3) a color previewer.

Why is it useful? Well, for a start you don't have to worry anymore about rewrapping the text to 80 when you add or remove words to the docstring.

It offers live preview of ANSI tags in actions: full color, and emulates almost 100% Evennia's behaviour. So, it can make life easier when handling lots of color tags and other ansi sequences, or Xterm.

It's smart, so when it line-wraps it does all calculations based on what will be the in-Mud screen output, not counting valid ANSI tags.

At present it only allow clipboard exportation of raw and output docstrings. In future editions it will allow saving and loading files. 

My idea is to finally create a tool to centralize all docstrings (autohelp, custom help entries, and any MUD-text) in single files, each file containing multiple docstring "raw sources" which are each associated to a specific Python class in an external file, allowing for formatted docstrings to be injected in the files directly. This would allow to work concentrating only on the actual text, without having to open and modify all the Python modules.

So, for now, it's a tool limited to cut-and-paste operations, but still ... it's quite handy in practical terms.

I'd appreciate feedback and suggestions on how to evolve it.

Tristano

[Austin Holliman]

This is wonderful! Thanks for this.

I'll be trying it out later tonight, this will help a ton when it comes to building as well!

[Griatch Art]

Very cool Tristano! I toyed with it on a Windows VM, looks good. :)
.
Griatch

[Tristano Ajmone]

Dear Austin and Griatch,

I'm glad you like it! Right now I am stuck because I can't figure how to build the interface. My aim is to have the App handle in a single file multiple "docstrings"; the user could jump from one docstring to the other using a drop-down menu. So far no problems.

But then, each docstring could belong to one of the following types:

1. Plain -- ie: just a plain ANSI text that the user copies to clipboard and pastes somewere else.
   
2. Python docstring -- ie: the docstring is associated to a given Class in a given external module. This means that when the user "outputs to docstrings", all docstrings of this type will be injected in the corresponding Class as docstrings. This is useful for updating Cmds docstrings. For this type of docstring, the user will have to associate a module and a class in that module.
3. Batch command docstrings -- ie: the docstring will output to an Evennia batchcommand file that will contain all the docstrings of this type in an Evennia list of "@help/append" commands (which, by the way, need trailing whitespaces converted to {_ in order not to be trimmed). For this type, the user has to associate an output batchcommand file and the custom help category and entry.

These are the main types I want to implement (to start with). What I am not yet sure about is how to handle it in the interface.

I'd definitely want to have the choice to "import" a python Cmds module, so that the user can extract all the Cmd classes into a working document, and then change them. Also, it should allow to import single Classes on existing docstring documents.

The thing is that I have to work out where and how to insert the different working field for each type--type 2 will need to offer a menu of choices based on existing Cmd classes, so they can't be arbitrary names. Type 3 need to offer two fields: help category and entry. So I guess it's better to create a separate popup window for those options, I just wanted to make something not to complicate to use.

Also, I think that "output" would mean injecting all Cmd docstrings into their modules, as well as recreating the custom help entries batchcommand.

When the app will allow to centralize control of all Cmds autohelp docstrings, as well as custom help entries, it will be very useful to handle all in-Mud documentation in an easy manner -- no matter how many modules are involved. Anything extra would be a bonus, but these two are the main purpose of the whole App.

Then I could start working on extra-formatting tags, hypenation for word-wrapping, ecc.

It's just driving me crazy that I can't visualize how the settings menu should look like... I don't want setting to be scattered in many different windows, neither I want an interface with redundant stuff. I guess I just need to sit and wait for some inspiration...

Any ideas?