"Start File" ignored under some conditions.

[xopxe]

When the edited file is Lua and there is a "Start File" set, then the Start File is correctly run when hitting F6/F5 . If the current tab is not a .lua file but another extension added to luaspec.exts, then will try to execute it ignoring the Stat File.

In my case, these are conf files I added to my user setting with:

luaspec.exts[#luaspec.exts+1] = "conf"

[pkulchenko]

@xopxe, I can't reproduce this issue; I always get the debugging started on the correct file. Is there anything else of interest? Can you remove all the plugins and see if the issue still happens?

[xopxe]

Yes, removed all the plugins and it sill happens for me. But there are some observations:

• It only happens with the default "Lua" selected as the interpreter in the menu. If I switch to another interpreter (Lua5.3 in my case) everything works correctly.
• When I right click on the file in the side bar and select "Set as Start File", only has effect when the file is also the current tab (this might be related to the other strange menu behavior).

Edit: my user.lua:

editor.fontname = "Ubuntu Mono"
editor.fontsize = 12

styles.indicator.fncall.st = wxstc.wxSTC_INDIC_PLAIN

styles.indicator.varglobal = {fg = {255,0,0}, u=true}

--xop https://github.com/pkulchenko/ZeroBraneStudio/issues/323#issuecomment-47281548
local G = ... -- this now points to the global environment in the script
local luaspec = G.ide.specs.lua
luaspec.exts[#luaspec.exts+1] = "conf"

editor.autoactivate = true

singleinstance=false

[pkulchenko]

When I right click on the file in the side bar and select "Set as Start File", only has effect when the file is also the current tab (this might be related to the other strange menu behavior).

I suspect it is related to the same issue as discussed in #1062, as all these menu items are using GetFocusedItem call, which doesn't seem to be working correctly when the local menu is opened.

[xopxe]

Yes, I guess it's unrelated to what I see here.

I just confirmed that when add an extension to luaspec.exts, these files when active will ignore a Start File and try to execute.

[pkulchenko]

Bug #1070 is fixed for new projects too, but seems to still affect existing projects. Perhaps I should remove some state file?

After the fix in #1062 is applied, you may need to delete the session config file, as it tracks the start file information per project: https://studio.zerobrane.com/doc-general-preferences#session-configuration.

[xopxe]

This is weird, I delete the session file (~/.ZeroBraneStudio), and I know it works because all sessions dissappear. It seems if I create a new .conf file it is correctly ignored and the Start File is respected. This works with files created from the menu or directly in the filesystem. But if I open a .conf file that already existed before I patched, it will run and ignore the Start File. Does that make sense?

[pkulchenko]

Just make sure I understand:

1. You deleted the session file
2. You set the Start File on some file
3. You opened a "new" .conf file (that was created after the patch was applied) and when you run/debug, the correct (start) file is selected
4. You opened an "old" .conf file (without changing the Start file), but when you run it, it's executed instead of the Start file.

If I listed the conditions correctly, can you run a "new" file again to see if it works?

I don't have an explanation, as I'd expect all those .conf files to work. What does ide:GetProjectTree():GetStartFile() report in both cases (when "old" and "new" file is selected)?

[xopxe]

I think I found what it is, and it's unrelated old/new, and actually unrelated to Start File.

Happened that the "old" files had invalid Lua syntax in them, and the failure whas from trying to compile it, not run. If I create a new file and put invalid Lua code inside I get the same error. For example:

Compilation error on line 3:
/home/xopxe/workspace/epibus/eeee.conf:3: '=' expected near '<eof>'

I dont't know what is the correct thing to do. On one hand, I did say it was Lua code. On the other hand, I did not ask for it to be compiled, it's just a file I have opened.

[pkulchenko]

@xopxe, thank you for tracking it down. So, you are suggesting that if the Start File is set, then the compilation check should be skipped on the currently selected file? It probably makes sense to me on the first glance.

Something like this?

diff --git a/src/editor/menu_project.lua b/src/editor/menu_project.lua
index c0785e46..16d54d4f 100644
--- a/src/editor/menu_project.lua
+++ b/src/editor/menu_project.lua
@@ -190,6 +190,7 @@ local function getNameToRun(skipcheck)
     editor.spec.apitype == "lua" and
     (not skipcheck) and
     (not ide.interpreter.skipcompile) and
+    (not ide:GetProjectStartFile()) and
     (not CompileProgram(editor, { reportstats = false })) then
     return
   end

[xopxe]

Hm , that's a though call.

I guess the more common scenario is that you are editing a Lua file which is part of the project (eg a module), and have the Start File set to the "main". In this case you might want the current file to be compiled, or it will fail a runtime.

But only auto-compiling the file you are to run, and having the option to manually compile any file (F7) also sound reasonable. (Perhaps add a "Compile all" command to compile all open Lua tabs?)

Both options sound justifiable to me.

[pkulchenko]

I'm leaning to the first option. The check is nice, but it's only done for Lua 5.1 and 5.2 interpreter anyway. Let me mull it over a bit more...

[xopxe]

Yeah, my case was rather weird, I agree.