Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: add project specific settings #107

Closed
Tieske opened this issue Mar 12, 2013 · 27 comments
Closed

Feature request: add project specific settings #107

Tieske opened this issue Mar 12, 2013 · 27 comments
Assignees
Milestone

Comments

@Tieske
Copy link
Contributor

Tieske commented Mar 12, 2013

I have two ways for coding Lua

  1. libraries in the general library path
  2. self contained applications (zip-it and ship-it); a directory containing everything, including binaries, to run an application

Especially for nr 2 I would like to have project specific settings. Things to be included for a project;

  • set the Lua engine to be used
  • set the PATH variables
  • set whitespace and line-end parameters used
  • working directory when starting debugging should be project directory, or be configurable
  • possibly provide commandline options to be passed
  • set a debug-entry file (now the debugger starts the file in the current tab)
  • set a test-entry file (and a toolbar button to run it?)

Adding those things in a .zerobrane file in the project root for example.

@ghost ghost assigned pkulchenko Mar 12, 2013
@pkulchenko
Copy link
Owner

I think there are two separate issues. One is that some of that functionality you are looking for is not implemented yet (for example, ability to pass command line options) or set the PATH. Second is that the behavior would need to be customized for that particular project. Also, if it is customized per project, it's likely needs to be restored when you switch the project, which means the previous state needs to be captured and preserved somewhere.

As some of these features still need need to be implemented, I'll keep this request in mind when these features are being worked on, but will revisit when most of them are available.

One question: is the primary goal of this project setup to simplify it for other people using the same project (in which case the configuration stored in an .ini file is not likely to work) or is this primarily for you to make switching between projects easier (in which case the exact mechanism used may not matter much)?

@marcelvanherk
Copy link

Hi,

I am struggling a bit with the same issue for first install of my conquest DICOM server. You want people to install the application, download ZBS, and then somehow merge ZBS with application specific interpreter and app files and then be up and running. Similar to the welcome page in ZBS but then tailored to a new application with its own interpreter.

Marcel

@pkulchenko
Copy link
Owner

Hi Marcel,

This is interesting; are the files you need to use from ZBS (like the interpreter) distributed together with your application? Or are they available as a separate package?

I see two ways to facilitate the process:

  1. You provide a welcome page that has a link to a small script that is executed in ZBS (similar to how theme switching works). The script would then either gets the files from some location and installs them or copies them from the application folder locally (and then restarts ZBS).
  2. You provide a configuration file that configures ZBS to use interpreter and project files from your application. In this case they don't even need to be copied to ZBS folders. There may need to be small changes to ZBS to make the configuration script simpler, but essentially, you'd provide the script and possibly a shortcut; the users would then start zbs with "zbstudio -cfg /path/to/script.lua" and this would create the configuration they need.

In either case you can also provide additional customization, like setting the default interpreter to be the value you need (after it's installed or configured).

The first option is probably more elegant, but if you need to keep making changes to the application and related scripts, the second one may be better.

Another option would be to have something like a plugin that users would install and which would provide whatever configuration you need on top of ZBS, but this becomes somewhat similar to option 1, but the users are still in control what they download and install.

Although this may all be different from what Thijs has in mind for his request...

@marcelvanherk
Copy link

Hi,

I would distribute the files with the application, as they are very small compared to the app. Both options are elegant but both need small changes to ZBS I think. Option 1 has my preference as it avoid typing command lines for the user.

Marcel


Van: Paul Kulchenko [notifications@github.com]
Verzonden: dinsdag 12 maart 2013 22:15
Aan: pkulchenko/ZeroBraneStudio
CC: Marcel van Herk
Onderwerp: Re: [ZeroBraneStudio] Feature request: add project specific settings (#107)

Hi Marcel,

This is interesting; are the files you need to use from ZBS (like the interpreter) distributed together with your application? Or are they available as a separate package?

I see two ways to facilitate the process:

  1. You provide a welcome page that has a link to a small script that is executed in ZBS (similar to how theme switching works). The script would then either gets the files from some location and installs them or copies them from the application folder locally (and then restarts ZBS).
  2. You provide a configuration file that configures ZBS to use interpreter and project files from your application. In this case they don't even need to be copied to ZBS folders. There may need to be small changes to ZBS to make the configuration script simpler, but essentially, you'd provide the script and possibly a shortcut; the users would then start zbs with "zbstudio -cfg /path/to/script.lua" and this would create the configuration they need.

In either case you can also provide additional customization, like setting the default interpreter to be the value you need (after it's installed or configured).

The first option is probably more elegant, but if you need to keep making changes to the application and related scripts, the second one may be better.

Another option would be to have something like a plugin that users would install and which would provide whatever configuration you need on top of ZBS, but this becomes somewhat similar to option 1, but the users are still in control what they download and install.

Although this may all be different from what Thijs has in mind for his request...


Reply to this email directly or view it on GitHubhttps://github.com//issues/107#issuecomment-14803863.

@pkulchenko
Copy link
Owner

You should be able to try option 1 right now; I don't expect any issues even with the current code, but can tweak it if needed. Basically:

  1. Run whatever code you need to copy files to the appropriate locations. For example, you can use ide.editorFilename to get the current executable name; you will need it later to restart the process, but you also can use it to calculate the locations of interpreters folder and such.
  2. After everything is copied, you start the second instance using os.execute and the full executable name you have; you will need to add a parameter to disable a check for single instance, but this is easy.
  3. You then close the current instance by calling os.exit(). it will save the files and correctly close the instance.

After you have the sequence, I'll help you wrap it into a command you can then expose it as a link in your instructions.

@marcelvanherk
Copy link

Thanks,

but not tonight (off to bed ;->>>)

Marcel


Van: Paul Kulchenko [notifications@github.com]
Verzonden: dinsdag 12 maart 2013 23:57
Aan: pkulchenko/ZeroBraneStudio
CC: Marcel van Herk
Onderwerp: Re: [ZeroBraneStudio] Feature request: add project specific settings (#107)

You should be able to try option 1 right now; I don't expect any issues even with the current code, but can tweak it if needed. Basically:

  1. Run whatever code you need to copy files to the appropriate locations. For example, you can use ide.editorFilename to get the current executable name; you will need it later to restart the process, but you also can use it to calculate the locations of interpreters folder and such.
  2. After everything is copied, you start the second instance using os.execute and the full executable name you have; you will need to add a parameter to disable a check for single instance, but this is easy.
  3. You then close the current instance by calling os.exit(). it will save the files and correctly close the instance.

After you have the sequence, I'll help you wrap it into a command you can then expose it as a link in your instructions.


Reply to this email directly or view it on GitHubhttps://github.com//issues/107#issuecomment-14811402.

@pkulchenko
Copy link
Owner

Sure ;); For 2 and 3 you can run the following command: SettingsSaveAll(); wx.wxExecute(ide.editorFilename .. ' -cfg singleinstance=false', wx.wxEXEC_ASYNC); os.exit()

@Tieske
Copy link
Contributor Author

Tieske commented Mar 13, 2013

I think there are two separate issues.

correct

One is that some of that functionality you are looking for is not implemented yet (for example, ability to pass command line options) or set the PATH.

priority 2 imo

Second is that the behavior would need to be customized for that particular project.

priotity1 imo, new options available from 1, can then added here as they become available

Also, if it (ED: second one) is customized per project, it's likely needs to be restored when you switch the project, which means the previous state needs to be captured and preserved somewhere.

it could be a one off configuration file, no need to store stuff when switching. It could simply be yet another file opened in the editor. Ideally (as with the other options/settings) a menu accessible GUI.

As some of these features still need need to be implemented, I'll keep this request in mind when these features are being worked on, but will revisit when most of them are available.

please put the second one somewhere top of the list, as several settings, like interpreter to use, are already available as global settings.

One question: is the primary goal of this project setup to simplify it for other people using the same project (in which case the configuration stored in an .ini file is not likely to work) or is this primarily for you to make switching between projects easier (in which case the exact mechanism used may not matter much)?

doesn't the approach cater for both? or am I missing something? My reason for bringing this up was the latter one; easier project switching.

@marcelvanherk
Copy link

Hi,

if you have different folders for the projects, project switching is easy in my experience. It is the initial setup of of an application and its project folder that I am trying to simplify as much as possible.

I.e.,

copy zbs mobdebug.lua to app/lua folder optionally copy zbs socket to app/lua folder copy interpreter file from app/zbs to zbs copy app file from app/zbs to zbs select the newly installed interpreter set project folder to app/lua close any pages on zbs open the new app's welcome page (app/lua/welcome.lua) in zbs optionally open the rest of the demo lua files in zbs bring app/lua/welcome.lua to foreground restart zbs such that you can now immediately run the app first demo.

It would be nice if is a menu option where you select an app folder which has e.g, a zerobrane.lua file, but manually loading it as lua script in zbs and then presssing twice would be a great start.

Marcel


Van: Thijs Schreijer [notifications@github.com]
Verzonden: woensdag 13 maart 2013 14:37
Aan: pkulchenko/ZeroBraneStudio
CC: Marcel van Herk
Onderwerp: Re: [ZeroBraneStudio] Feature request: add project specific settings (#107)

I think there are two separate issues.

correct

One is that some of that functionality you are looking for is not implemented yet (for example, ability to pass command line options) or set the PATH.

priority 2 imo

Second is that the behavior would need to be customized for that particular project.

priotity1 imo, new options available from 1, can then added here as they become available

Also, if it (ED: second one) is customized per project, it's likely needs to be restored when you switch the project, which means the previous state needs to be captured and preserved somewhere.

it could be a one off configuration file, no need to store stuff when switching. It could simply be yet another file opened in the editor. Ideally (as with the other options/settings) a menu accessible GUI.

As some of these features still need need to be implemented, I'll keep this request in mind when these features are being worked on, but will revisit when most of them are available.

please put the second one somewhere top of the list, as several settings, like interpreter to use, are already available as global settings.

One question: is the primary goal of this project setup to simplify it for other people using the same project (in which case the configuration stored in an .ini file is not likely to work) or is this primarily for you to make switching between projects easier (in which case the exact mechanism used may not matter much)?

doesn't the approach cater for both? or am I missing something? My reason for bringing this up was the latter one; easier project switching.


Reply to this email directly or view it on GitHubhttps://github.com//issues/107#issuecomment-14841252.

@marcelvanherk
Copy link

This is as far as I got, I do not know well how to manipulate the ide.

local zbs = ide.editorFilename
zbs = string.gsub(zbs, 'zbstudio.exe$', '')
local dcm = ''
for i,v in pairs(ide.openDocuments) do
if v.filePath then
if string.find(v.filePath, 'zbs\install.lua') then
dcm = string.gsub(v.filePath, 'zbs\install.lua', '')
end
end
end
wx.wxCopyFile(zbs .. 'lualibs\mobdebug\mobdebug.lua', dcm .. 'lua\mobdebug.lua')
wx.wxCopyFile(zbs .. 'lualibs\socket.lua', dcm .. 'lua\socket.lua')
wx.wxCopyFile(dcm .. 'zbs\conquest.lua', zbs .. 'api\lua\conquest.lua')
wx.wxCopyFile(dcm .. 'zbs\conquestdicomserver.lua', zbs .. 'interpreters\conquestdicomserver.lua')
wx.wxCopyFile(dcm .. 'zbs\conquestdicomutil.lua', zbs .. 'interpreters\conquestdicomutil.lua')
-- ide.ProjectFolder = dcm .. 'lua'
-- ide.Interpreter = 'Conquest Dicom server'
-- close all windows
-- ide.OpenFile(dcm .. 'lua\welcome.lua')
-- open more files
-- focus on first open file
SettingsSaveAll();
wx.wxExecute(ide.editorFilename .. ' -cfg singleinstance=false', wx.wxEXEC_ASYNC);
os.exit()

@marcelvanherk
Copy link

It just occurred to me that I can just modify zeroBraneStudio.ini just after SettingsSaveAll() in the above install code to achieve all the missing bits. Is there a nice way to find its path? And of course the above code is just a sketch, a real installer would need to do lots of checks, for instance when orverwriting existign files.

@marcelvanherk
Copy link

-- how to use this install code: open install.lua from the c:\dicomserver\zbs folder in zbs
-- select all and then right click - run in console

-- this code almost works; ide.settings = nil is necessary to stop zbs overwriting my just saved settings
-- but it crashes the IDE
-- please help, Marcel

local zbs = ide.editorFilename
zbs = string.gsub(zbs, 'zbstudio\.exe$', '')
local dcm = ''
for i,v in pairs(ide.openDocuments) do
  if v.filePath then
    if string.find(v.filePath, 'zbs\\install\.lua') then
      dcm = string.gsub(v.filePath, 'zbs\\install\.lua', '')
    end
  end
end
wx.wxCopyFile(zbs .. 'lualibs\\mobdebug\\mobdebug.lua', dcm .. 'lua\\mobdebug.lua')
wx.wxCopyFile(zbs .. 'lualibs\\socket.lua', dcm .. 'lua\\socket.lua')
wx.wxCopyFile(dcm .. 'zbs\\conquest.lua', zbs .. 'api\\lua\\conquest.lua')
wx.wxCopyFile(dcm .. 'zbs\\conquestdicomserver.lua', zbs .. 'interpreters\\conquestdicomserver.lua')
wx.wxCopyFile(dcm .. 'zbs\\conquestdicomutil.lua', zbs .. 'interpreters\\conquestdicomutil.lua')

SettingsSaveAll(); 

ide.settings:SetPath('/editor')
ide.settings:Write('interpreter', 'conquestdicomserver')

ide.settings:SetPath('/projectsession')
for i=1, 100 do
  local f, p = ide.settings:Read(tostring(i))
  if f==nil then 
    ide.settings:Write(tostring(i), dcm .. 'lua')
    break 
  end
  if p==dcm .. 'lua' then break end
end

ide.settings:DeleteGroup('/session')
ide.settings:SetPath('/session')
ide.settings:Write('1', dcm .. 'lua\\welcome.lua')
ide.settings:Write('2', dcm .. 'lua\\livecoding.lua')
ide.settings:Write('3', dcm .. 'lua\\install.lua')
ide.settings:Write('index', 0)
ide.settings:Flush()
ide.settings = nil
wx.wxExecute(ide.editorFilename .. ' -cfg singleinstance=false', wx.wxEXEC_ASYNC); 
os.exit()

@marcelvanherk
Copy link

You need to remove ide.settings = nil before and add wx.wxSleep(2) after the wx.wxExecute. Also if f==nil should be if f==false. Then it works. I mailed Paul a much nicer version making it a more generic install script controlled by these settings:

local config = {appname='Conquest Dicom Server', api={'conquest.lua'}, interpreter={'conquestdicomserver.lua', 'conquestdicomutil.lua'}, interpretername='conquestdicomserver',
tools={}, demos={'welcome.lua', 'livecoding.lua', 'install.lua'}, ds='', installdir='ZeroBraneStudio'}

@marcelvanherk
Copy link

-- Here is the complete script, it should be useable for any app
--[[ ---------------------------------------------------------------
This is a small installer script to enable editing and debugging [Lua](http://www.lua.org) 
scripts for [Conquest Dicom Server](http://ingenium.home.xs4all.nl/dicom.html) (`V 1.4.17alpha up`) in the fantastic
[ZeroBrane Studio](http://studio.zerobrane.com) (`V 0.35 up`) development environment. Use as follows: 

Open **ZeroBrane Studio** and look at the `Local console` tab
Load this **install.lua** file with   `File - Open`
Select all text using             `right-click - Select All`
Run it in the console using       `right-click - Evaluate in Console`

After this - ZeroBrane Studio will reopen ready to run demo scripts 
and develop for **Conquest Dicom Server**. As installed, Zerobrane Studio
communicates with a running Conquest Dicom Server and offers code 
completion and full debugging facilities. 
---------------------------------------------------------------- ]]--
local config = {appname='Conquest Dicom Server', 
        api={'conquest.lua'}, 
                interpreter={'conquestdicomserver.lua', 'conquestdicomutil.lua'},
            interpretername='conquestdicomserver', 
        tools={},
        demos={'welcome.lua', 'livecoding.lua', 'nifty.lua'},
        ds='\\', 
        installdir='ZeroBraneStudio'}
local z, ds = config.installdir, config.ds

-- Clear the local console tab for our messages
ide.frame.bottomnotebook.shellbox:ClearAll()

-- Detect ZeroBrane Studio Folder
local zbs = ide.editorFilename
zbs = string.gsub(zbs, 'zbstudio\.exe$', '')
print('Installing into ZeroBrane Studio at: ' .. zbs)

-- Detect app folder (assumes one app\zbs\install.lua is open in ide)
local app = ''; local installfile = z..ds..'install\.lua'
for i,v in pairs(ide.openDocuments) do
  if v.filePath then
    if string.find(v.filePath, installfile) then
      app = string.gsub(v.filePath, installfile, '')
    end
  end
end
print(config.appname .. ' is at: ' .. app)

-- Copy file from to but do not replace newer one
function safecopy(file, from, to)
  local ffr = GetFileModTime(from..file)
  local fto = GetFileModTime(to..file)
  if ffr==nil then
    error('Cannot install file: ' .. from..file)
  end
  if fto==nil then
    wx.wxCopyFile(from .. file, to .. file)
  elseif GetFileModTime(from..file):GetTicks()>=GetFileModTime(to..file):GetTicks() then
    wx.wxCopyFile(from .. file, to .. file)
    print('Updated file: ' .. to..file)
  else
    print("Didn't replace newer file: " .. to..file)
  end
end

-- install files from zbs to app
safecopy('mobdebug.lua', zbs..'lualibs'..ds..'mobdebug'..ds, app..'lua'..ds)
safecopy('socket.lua',   zbs..'lualibs'..ds,                 app..'lua'..ds)

-- install files from app to zbs
for k,v in ipairs(config.api) do
  safecopy(v, app..ds..z..ds, zbs..'api'..ds..'lua'..ds)
end
for k,v in ipairs(config.interpreter) do
  safecopy(v, app..z..ds,     zbs..'interpreters'..ds)
end
for k,v in ipairs(config.tools) do
  safecopy(v, app..z..ds,     zbs..'tools'..ds)
end

-- modify the main interpreter file to tell it where the conquest folder is
local f=io.open(zbs..'interpreters'..ds..config.interpreter[1], 'rt')
local s=f:read('*all'); s = string.format('local appdir = %q\n', app) .. s
f:close(); f=io.open(zbs..'interpreters'..ds..config.interpreter[1], 'wt')
f:write(s); f:close();

-- start setting the ZBS configuration
SettingsSaveAll(); 
ide.settings:SetPath('/editor')
ide.settings:Write('interpreter', config.interpretername)

-- add project folder
ide.settings:SetPath('/projectsession')
local f, org = ide.settings:Read(tostring(1))
  for i=1, 100 do
    local f, p = ide.settings:Read(tostring(i))
    if f==false then 
      ide.settings:Write(tostring(i), org)
      ide.settings:Write(tostring(1), app .. 'lua')
    break
  end
  if p==app .. 'lua' then break end
end

-- prepare to open a list of documents
ide.settings:DeleteGroup('/session')
ide.settings:SetPath('/session')
for k, v in ipairs(config.demos) do
  ide.settings:Write(tostring(k), app .. 'lua'..ds..v)
end
ide.settings:Write('index', 0)
ide.settings:Flush()

-- restart ZBS
print('Updated ZBS session; restarting ZBS in 2s'); wx.wxYield(); wx.wxSleep(2)
wx.wxExecute(ide.editorFilename .. ' -cfg singleinstance=false', wx.wxEXEC_ASYNC); 
wx.wxSleep(1)
os.exit()

@marcelvanherk
Copy link

If you replace

ide.settings:Write(tostring(k), app .. 'lua'..ds..v)

by

ide.settings:Write(tostring(2_k-1), app .. 'lua'..ds..v)
ide.settings:Write(tostring(2_k), app .. 'luasamples'..ds..v)

You can load samples both from the lua and the luasamples folder (using that invalid files are not loaded by zbs)
Marcel

@pkulchenko
Copy link
Owner

@Tieske, I've been reviewing the open tickets and would like to get some clarification on this one. As we discussed earlier, it can be split into two parts: (1) have a mechanism to apply some settings on a per-project basis, and (2) make some of the settings more configurable. I think I have a solution for (1). I'm proposing a plugin that will keep track of project changes and will load user.lua if it exists in that folder (the name can be configurable) and will "undo" the effect of the changes when the project is changed to something else.

As to (2), we can discuss which options are not (yet) modifiable from a config and how to enable that. Would this work?

@Tieske
Copy link
Contributor Author

Tieske commented Oct 10, 2013

Sounds like a plan. Just a thought that popped up while going through this issue again; instead of user.lua I would propose to have _project.zbs and _user.zbs. (the _ is a matter of taste, I like to separate the config files)

  1. settings in _user overrule settings in _project. This way I can store whitespace settings (every git repo used seems to have different settings) in the _project file and have that included in the git repo. While at the same time I can use the path to the interpreter to be used in _user as that is specific for my system, and I can exclude that file from the git repo.
  2. It allows me to create a shortcut for .zbs files, so I can double click a .zbs file and have that specific project opened.

@pkulchenko
Copy link
Owner

These are interesting ideas. To support (1) I'd need to allow multiple filenames to be provided and to process them in the order specified. Something like projectsettings.filename = {'_project.zbs', '_user.zbs'}.

To support (2), I'd need to "catch" load request for that file, change the project folder instead and suppress opening of that file. This should all be doable with a plugin. You are still limited to whatever settings are processed in user.lua, but we will handle anything you think may be missing separately.

@Tieske
Copy link
Contributor Author

Tieske commented Oct 10, 2013

thx. looking forward to it!

@andrewstarks
Copy link

I'd like to second this feature request!

One thing that this model provides is the ability to define multiple roots for the project tree. This is helpful in case 1 of @Tieske's original use case. I opened a case and then read this one more closely. Realising that it was duplicative, I closed it. I'll post my original thoughts:


When I work on writing libraries, I sometimes work from different directories. This is especially true when I'm using a tool kit and for some reason, in the middle of my project, I need to modify something in that tool kit.

In these cases, I wish that I could have the tool kit shown as a second root directory in my project view.

Along with this, I'd like a simple Lua file that represented a project to ZBS. In this file, there could be any amount of valid ZBS configuration data, but the primary thing it would contain is the folders that the project should include.

Some thoughts:

  • If configuration state is an issue, then reloading ZBS when a new project is opened is fine.
  • The hierarchy should be: project -> user -> system, with defaults going from left to right.
  • This is a gateway to nested projects. I'm just saying. : ^)

@Tieske
Copy link
Contributor Author

Tieske commented Oct 19, 2013

adding to @andrewstarks ;

The hierarchy should be: project -> user -> system, with defaults going from left to right.

I think it should be: user-project -> project -> user-system -> system. Or stated otherwise; have project and system settings, and for each a user variant that overrides the generic one.

@andrewstarks
Copy link

Yeah. You're right. The use case is:

The project settings are in source control and then the user can have their version that is list in .gitignore.

That is a great idea.

@pkulchenko
Copy link
Owner

Right, I was thinking about something as simple as having this as a default: projectsettings = {filename = {'.zbstudio/user.lua'}}, but allowing you to specify projectsettings = {filename = {'_project.zbs', '_user.zbs'}}.

The settings are applied in the order: system (cfg/user.lua), user (<HOME>/.zbstudio/user.lua), and then project (as above; in the order listed), which allows you to have project/user specific configs in the project directory.

The tricky part is to save/restore settings when you switch projects as those are flattened into one table. I do have several options, just need to find the best one.

@andrewstarks
Copy link

The "easy" thing would be perhaps just to shut it down and reload with the new project. Or launch a new ZBS Process then the use can close the existing one.

@pkulchenko
Copy link
Owner

Yes, this can be done, but I'm looking for something a bit less invasive ;). I'll try saving and restoring settings first and they we can see what settings may be not reset correctly (and deal with them on a case-by-case basis).

pkulchenko added a commit that referenced this issue Oct 22, 2013
This is needed to take project configuration into account before files are
loaded.
@pkulchenko
Copy link
Owner

pkulchenko commented Oct 22, 2013

You'll need to use the plugin below and the latest code from project-settings branch.

The default configuration file is .zbstudio/user.lua, but you can change this by setting projectsettings = {filename = {'_project.zbs', '_user.zbs'}} in the config. The filenames can include path (absolute/relative); the relative part is combined with the project path.

The configuration is applied and then fully restored when you switch projects. Technically, any settings should work, but due to implementation details, some may not. For example, setting language is likely not to work as it's applied when the IDE is loaded (and menus and all other elements are being built). Most of editor settings should work with one exception: font settings (size/face) are cached, so they are going to be reused (and editor.fontsize is going to be ignored). This is probably a bug and should be fixed (if there is a demand).

The plugin also adds one menu item Edit | Preferences | Settings: Project, which will open all configuration files (even if more than one) in the current project. All the changes will be in effect next time you switch to the project.

Plugin code.

@pkulchenko
Copy link
Owner

Closing as project settings support has been merged into master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants