Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#965 Explicit control over SciteUserHome and SciteDefaultHome

open
Neil Hodgson
SciTE (231)
3
2013-04-03
2012-12-07
Zarathushtra
No

Punchline:

$(SciteUserHome) and $(SciteDefaultHome) should be independently and explicitly settable via environment variables.

Rationale:

Currently (on Windows), we can tell SciTE to read session and user properties files from a location () that is either the user profile directory (%USERPROFILE%), or from the same directory as the global properties file (via %SciTE_Home%).

Having the session and user properties files located in a different folder than the global properties () enables both easy backups and easy updates of SciTE itself.

Having them in a folder that is DIFFERENT from the user profile directory would enable the use of SciTE from a thumb drive.

Alas, the only documented way to achieve the latter is by giving up the former: If we set %SciTE_Home%, it will become the location of both user and global properties, preventing easy backups and updates. It's a "win-loose" situation.

Making it possible to set both locations independently would enable both aspects - a win-win situation.

Thanks in advance for consideration.

Implementation suggestion:

SciTE already maintains two variables to keep track of the two locations: $(SciteUserHome) and $(SciteDefaultHome).

My suggestion is to make it possible to set them via enviromnet variables

There is also the ability to access enviroment variables in properties files directly (i.e. $(FOO) expands to the value of %FOO%).

It seems natural to name the enviroment variables the same as the SciTE variables (i.e. %SciteUserHome% and %SciteDefaultHome%).

Discussion

  • Zarathushtra
    Zarathushtra
    2012-12-07

    Uhm, please ignore the line "My suggestion is to make it possible to set them via enviromnet variables" in my submission above.

     
  • Zarathushtra
    Zarathushtra
    2012-12-07

    • priority: 5 --> 3
     
  • Neil Hodgson
    Neil Hodgson
    2012-12-30

    The thumb drive scenario is still confusing: are you trying to have SciTE and its global properties on the thumb drive or on the fixed drive? Or is it the opposite? When making a portable thumb drive installation, I'd expect you'd want all the files, both constant and modifiable on the thumb drive so they travel with you. If you want just the recently-used file list and associated positions and folds etc. to stay with the machine then the suggested division is wrong as the modifiable set also includes user preferences.

    If you are just interested in a simple replacement of the read-only files with a new release then just xcopy the distribution onto the thumb drive hierarchy leaving the modified files intact.

     
  • Neil Hodgson
    Neil Hodgson
    2012-12-30

    • assigned_to: nobody --> nyamatongwe
     
  • Zarathushtra
    Zarathushtra
    2013-04-01

    Sorry for the late response, after an update at one of my email providers all my email forwarders were deleted, so I never got any notifications about this thread. :-/

    Anyhow, what I had in mind was to be able to do both:

    A thumb drive scenario calls for easy syncing, and having everything in one place seems to serve this well, b/c just copying everything over is what one usually does.

    Except...

    ... in some scenarios, ex. when suspecting a virus infection, I only want to grab my own stuff. That would be much easier if my stuff was in a entirely separate folder.

    ... when I want to integrate SciTE with my PortableApps suite, where it is standard to have user settings in a "Data" directory (and that's the only place the suite will do a "config backup" from.)

    ... when I want to update to a newer SciTE app code w/o possibly keeping obsolete files by just dumping the new files over my old ones, but by 1st purging the SciTE directory (w/o having to look at every single file to check if that's one of mine and exclude if from purging.)

    ... when I want to put my own .properties, .api, .lua, .whatnot files under version control w/o having to .hgignore or .svnignore the individual SciTE core files.

    If user and global properties could reside in separate user-selectable folders, for ex. by reading their location from environment variables and/or specifying them on the SciTE command line, that would resolve all issues re above use cases.

    I hope this clarifies what I had in mind.

     
  • Neil Hodgson
    Neil Hodgson
    2013-04-02

    Can't you set USERPROFILE for running SciTE to where you want to have user settings?

     
  • Zarathushtra
    Zarathushtra
    2013-04-02

    Ha, I tried that! In fact, that was the 1st thing I went for. But Windows expects to find a bunch of other folders beneath USERPOFILE, for example "Desktop". So when I tweak USERPROFILE, I get a warning message (accompanied by that terrible "bong" sound) whenever the file open or file save dialogs are opened, and the dialog's initial directory is wrong. That's pretty annoying.

    Besides, running other programs from within SciTE (which I do as I like to use SciTE as an IDE) with USERPOFILE tweaked affects those programs as well, since they inherit the environment.

    Worse yet, the expected folders are different on different Windows versions. Win7 expects stuff like Contacts and AppData (among others), XP expects things like "My Files" or so (and then they differ depending on the user's language, too).

    You see, USERPROFIE is not really a "portable" concept.

     
  • Neil Hodgson
    Neil Hodgson
    2013-04-03

    My worries with this is that it increases the possible settings affecting behaviour and thus adds to support costs.

    If anyone is interested in implementing this, I'll accept a well-written patch that preserves current behaviour unless a user consciously opts in by setting a new environment variable. The patch should minimise changes and include documentation.