Better LUA DOC

[JimB40]

Hello guys,

It's about having better EdgeTX LUA API documentation.

API functions were added but while coding is fancy, writing proper doc seems not to be.
luadoc inherited after OpenTX suffers from anything that non-managed for years thing can suffer from.
To name few:

• Misleading naming scheme
• Non meaningful descriptions
• Lack of information which radio supports API FI
• Lack of usage examples
  etc, etc.

LUA API documentation going to be better :)
This EdgeTX sub-project lasts for some time.
Since last year I slowly fix luadoc 2.10 branch to make it real handy tool for LUA devs.

Already:

1. Structured information better
   https://luadoc.jimb40.com/
2. Introduced proper naming for variables, constants and described internal indexes etc
   https://luadoc.jimb40.com/v/2.10/overview/internal-indexes/source-list
3. Added better information and description of various scripts types interface
   https://luadoc.jimb40.com/v/2.10/overview/script-types
4. Started to add information about Radios

• we develop for physical devices so information about them are important.
  https://luadoc.jimb40.com/v/2.10/overview/radios/radiomaster/tx16s

5. Grouped CONSTANTS and started to add descriptions
   https://luadoc.jimb40.com/v/2.10/lua-api-reference/constants
6. Structured API functions based on what they do.
   https://luadoc.jimb40.com/v/2.10/lua-api-reference
7. Made quasi template for API function that includes:

• description
• parameters
• return value
• notes
• information if function is available on particular radio
• examples!!!
• related topics
  https://luadoc.jimb40.com/v/2.10/lua-api-reference/display-lcd/rgb
  https://luadoc.jimb40.com/v/2.10/lua-api-reference/display-lcd/clear
  https://luadoc.jimb40.com/v/2.10/lua-api-reference/display-lcd/drawbitmap

8. Last but not least got rid of this irritating "greater-than-..." in documentation links

First of all I'd like feedback about what was already done

Secondly ... well, hell of work ahead but step by step it will get better.
... and @pfeerick promised not pass any further LUA API PRs without proper changes to API doc from dev. :)

So contribution from whoever code in LUA for EdgeTX will be very appreciated
So far we will work on my luadoc fork not to mess with original repo, so give me dm to include you as gitbook author.

Eddie the Edgehog needs you :)

Cheers
Robert

[TodWulff]

Sir Robert,

As info, I am getting an error dialog ( https://i.imgur.com/wz1wtl8.png ) when attempting to open the cited URLs above. I'm using Win11x64 w/ current Chrome. Just so you know.

-t

[pfeerick]

Same here, Linux and Brave. So not just you ;) It's possible the links need updating as development has moved onto main luadoc repo.

[JimB40]

Yep once we moved environment to edgetx.org I've deleted my fork.
Just forgot to update this discussion thread.

BTW @pfeerick maybe we can publish what we have done already in "Next" branch.
Somwhere/somehow :)
So there will be visible teaser what will come and I will be able to update above links.

[pfeerick]

I've told you already that if I do that (github sync or any form for publishing), you lose live edit functionality, and will have to start doing change requests and reviewing in gitbook. 😛 It's one of the reasons I said I wanted you to merge the changes into 2.10, and carry on for 2.11... so that the current changes could be live... it is a living document, after all ;) I'm afraid you can't have it both ways.

Check this out if you want to see more... I don't think I sent that to you before... https://docs.gitbook.com/content-editor/editor/live-edits

[JimB40]

Roger that. But aren't you the one who makes impossible possible? :)
Then probably we will wait to merge it to 2.11 as 'work in progress' can introduce lots of questions from users regarding unfinshed work

[pfeerick]

I wish... can only work within the limitations of the tools we are currently using though. The only other thing I can think of is maybe duplicating the current next space and then publishing that as a snapshot (call it preview if you want) of what it currently looks like... and maybe doing that monthly or something?

[JimB40]

I wish... can only work within the limitations of the tools we are currently using though. The only other thing I can think of is maybe duplicating the current next space and then publishing that as a snapshot (call it preview if you want) of what it currently looks like... and maybe doing that monthly or something?

If not complicatg too much, That would be cool. And this preview as you said we can update once a month.