* Using an External Editor

[ChrisRead]

Does anyone use an external editor when writing a plugin?

I ask, because the FH plugin editor seems so meh. I have been a long time user of Notepad++ and as I discovered in doing my plugin, it supports the LUA language to provides nice coloured syntax and more sophisticated editing capabilities like code folding etc.

For debugging, I know I have to run in the FH editor, and the only option seems to be to edit the .fu_lua file directly in the FH plugins folder and save it prior to then edit it in FH to run it in debug. A bit of a faff, but workable, and sometimes I just stay in the FH editor anyway if I only need to fix a minor thing.

Just curious if anyone else does anything similar.

[Mark1834]

I use Notepad++ extensively for proofreading - usually annotating a Notepad++ derived pdf on the iPad with my feet up on the sofa . Visual Studio Code and ZeroBrane sometimes feature with pro/ex-pro developers, but I’m happy with what I use for my basic plugins.

[ColeValleyGirl]

I use Visual Studio Code with some relevant extensions. It integrates with Github, so I keep my master outside the FH plugins folder, and only transfer files there for debugging.

One particular strength of this is that, if you set up the VS Code 'workspace' appropriately, it can recognise functions in all the standard libraries, so you don't need to keep looking at documentation.

My workspace definitions looks like:

Code: Select all

{
  "folders": [
    {
      "path": "D:/OneDrive/Lua Code Repositories/FH7",
      "name": "FH7"
    },
    {
      "path": "C:/Program Files (x86)/Family Historian/Program/Lua",
      "name": "Program Files Lua"
    },
    {
      "path": "C:/Program Files (x86)/Family Historian/Reports/Lua",
      "name": "Reports Lua"
    },
    {
      "path": "D:/OneDrive/Lua Code Repositories/FH API",
      "name": "FH API"
    }
  ],
  "settings": {
    "Lua.diagnostics.disable": [
      "lowercase-global"
    ]
  }
}

I have a file in the FH API directory that has definitions for all the FH API functions in it (hat tip: Jane T). it needs updating but is invaluable.

I can share it as a text file if you wish -- will need renaming to .lua before use.

[ChrisRead]

I hadn't got around to checking is VS Code supported LUA, but will as I have it installed already, and see how that goes.

I also use GitHub with GitExtensions, and manually copy the FH copy to my Development/FH Plugins/... folder when I reach a good point to stash it before breaking it again.

I can share it as a text file if you wish -- will need renaming to .lua before use.

That would be nice, thank-you, and if I make any updates as you say, I'll share it back again.

Also, having just looked at VSC LUA modules, there are many, many of them. Can you give me any recommendations for what you are using. It will save time and I'll at least know I'm doing what a veteran of the plugin game does.

[ColeValleyGirl]

I hadn't got around to checking is VS Code supported LUA, but will as I have it installed already, and see how that goes.

Recommended extensions: Lua by Sumneko. I believe that now also does code formatting but I've got used to Stylua.

I can share it as a text file if you wish -- will need renaming to .lua before use.

That would be nice, thank-you, and if I make any updates as you say, I'll share it back again.
[/quote]

See attached. (It isn't executable -- all the functions are empty).

[ColeValleyGirl]

I hadn't got around to checking is VS Code supported LUA, but will as I have it installed already, and see how that goes.

Recommended extensions: Lua by Sumneko. I believe that now also does code formatting but I've got used to Stylua.

I can share it as a text file if you wish -- will need renaming to .lua before use.

That would be nice, thank-you, and if I make any updates as you say, I'll share it back again.
[/quote]

See attached. (It isn't executable -- all the functions are empty).

[ChrisRead]

Thanks, immediately after posting I did a search on a hunch and found an old post of yours and grabbed the two you mentioned (here and there). Thanks anyway,also for the FH API file.

[ChrisRead]

Okaaaaaay, so to save me a bit of time and hunting (not used VSC much or for some time), where should I put the API file (now a .lua) and make VSC lua know to use it to find the API definitions.

[ColeValleyGirl]

I posted a workspace definition up thread.

[ChrisRead]

My bad, I forgot there was something posted earlier.

[ChrisRead]

Just got back to it, but I must be missing something else. I have a workspace setup using the settings you provided (all the files in the defined paths show in the workspace), but it still flags the fh functions I've used as Undefined Global while also giving the spec, and allowing Go to Definition to take me to the correct function in the API file.

Is this how it's supposed to be, or am I missing some aspect I haven't done. Not sure if it's a LUA thing or a VSC thing.

[ColeValleyGirl]

Did you include this bit in the workspace definition:

Code: Select all

  "settings": {
    "Lua.diagnostics.disable": [
      "lowercase-global"
    ]
  }

[ChrisRead]

Yup, checked and that's there.

I get the wavy underlines for the fh.... functions and hovering gives a popup like below
e.g.
Undefined global 'fhGetAppVersion', Lua Diagnostics.(undefined-global)
(global) fhGetAppVersion: unknown
View Problem (Alt+F8) Quick Fix...(Ctrl+)

Pretty sure yesterday at some point I could do a right-click and go to Definition, but that's not working today either.

Then suddenly it's working again, and the popup changed a bit and I can Go to Definition again.
e.g.
Undefined global 'fhGetAppVersion', Lua Diagnostics.(undefined-global)
function fhGetAppVersion()
View Problem (Alt+F8) Quick Fix...(Ctrl+)

So I'm rather confused as to what's going on. If I should expect to still see the wavy lines, then no problem as hovering over the function is showing the parameters expected from the API file.

settings.json is

Code: Select all

{
    "Lua.diagnostics.disable": [
        "lowercase-global"
    ],
    "Lua.diagnostics.globals": [
        "iup"
    ]
}

and the workspace settings are

Code: Select all

{
	"folders": [
		{
			"path": "C:/Program Files (x86)/Family Historian/Program/Lua",
			"name": "Program Files Lua"
		},
		{
			"path": "C:/Program Files (x86)/Family Historian/Reports/Lua",
			"name": "Reports Lua"
		},
	  	{
			"path": "D:/Chris's Files/Development/FH Plugins/GRO Source Reference",
			"name": "GRO Source Reference"
		},
		{
			"path": "D:/Chris's Files/Development/FH Plugins/FH API",
			"name": "Family Historian API"
		}

	],
	"settings": {
		"Lua.diagnostics.disable": [
		"lowercase-global"
		]
	}
}

[ColeValleyGirl]

Not sure what's going on there... maybe Jane will have an idea.

[Jane]

I see wavy lines for : functions as when I set up the definitions file I could not quite work out how to avoid the error on the fields defined using NewItemPtr. The definition is probably not quite right.

e.g

image.png (18.15 KiB) Viewed 308 times

My Workspace is simply

Code: Select all

{
	"folders": [
		{
			"path": "."
		}
	],
	"settings": {}
}

as the functions file and the workspace live in the plugins folder.

[Jane]

Changing the Object section of the definitions to

Code: Select all

-- Create Objects

function fhNewAge() 
---@cast item -nil
end
function fhNewDate(iYear, iMonth, iDay, strSubtype) 
---@cast item -nil
end
function fhNewDatePt(iYear, iMonth, iDay, bYearDD, bBC, strCalendar) 
---@cast item -nil
end
function fhNewItemPtr() 
---@cast item -nil
end
function fhNewRichText(strText, bRich) 
---@cast item -nil
end
function fhNewSection() 
---@cast item -nil
end

Reduces some of the underlines.

[ChrisRead]

It seems that although the brown wiggly lines do not go away, it switches from not knowing the API functions to knowing them if you open the API file.

I noticed that the API file shows red in the workspace as having problems, and when opened there are red wiggly underlines that go away after a few seconds. I think this is the point at which they are suddenly known and the definitions are then available by hovering over them in the main code file.

I can't tell what it thinks the problem was, as it goes too quickly to find out. But at least it explains the change in behaviour I wrote about earlier.