Extensionless File Manager options import/export

[mjdl]

1) Under v18 an options profile export zip file just containing "Extensionless File Manager" options has a file export.xml that has stanzas covering a whole lot more options than just the Extensionless File Manager options (see attached file). Is this a bug? I.e., will importing such an options zip file set more than just the Extensionless File Manager options?

2) Under v19 the export zip file's export.xml contains just one options stanza (for the Extensionless Files Manager, see attached file).

3) Attempting to import the v18 options zip into v19 bring up a dialog warning that the earlier file's format may not be compatible. But will such a v18 options zip file change options other than the intended Extensionless File Manager?

4) Importing/exporting the Extensionless File Manager option file is just a time saver for the user from having to retype all those lists of file types, names and/or Ant-style patterns. The only essential information about each name or pattern for the Manager is a) the language file type and b) a file name or an Ant-style file pattern (which could be converted internally to a Slickedit-style file pattern for the options file XML elements), all two elements of which could be imported/exported from a user-created file with a very simple non-xml text file (maybe with a Unicode BOM if so encoded) in comma-separated format. This would be a Slick version independent file that people could store with other files in a project if they ever need to change Extensionless file lists on a project basis, and could be rapidly edited without a lot of dialoging-about. (The usual export/import zip option would remain, of course.)

5) One small point: using the existing windows platform directory/file selection dialog boxes in the Extensionless File Manager does not update the "Recent Places" Windows Explorer MRU list. That list is extremely useful in shortening navigation to recent places in those standard Windows selection dialogs.

[Sandra]

1, 2.  Not a bug, in that no extra options will be imported.  It's just leftover stuff hanging out.  We did make a change this year to remove the unnecessary stuff, since it wasn't doing anything.

3.  We throw up that dialog mostly as a precaution, since export/import is not the ideal way to migrate a configuration from version to version.  There were no changes in the formatting of the export/import of the Extensionless File Manager between v18 and v19, so you should be fine, and as I said, there aren't actually extra options being imported.

4.  Would the Extensionless File Manager be useful to you on a per-project or per-workspace basis, rather than doing a import/export on an as-needed basis? 

5.  I'll check on this.

Thanks for all the feedback!

[mjdl]

Thanks for the quick response. My chief concerns were the extra stuff in the v18 options.xml file somehow making unwanted changes in v19 options, as well as finding a way around the endless UI clickery to rebuild the extensionless file/pattern list.

To your query on my point (4): for me, when using C++, the extensionless file names are really confined to the Standard Library and other library headers, so making them global rather than workspace/project based seems reasonable. But since the feature allows specifying how any file is lexed & analysed in the editor, maybe there is a case for also specifying that on an individual workspace/project basis--but I would not be a real user of such an extra option, so it seems a low priority to me.

[hs2]

I agree with mjdl and think it's not really neccessary to handle the filesets per workspace/project.
Even when using cross-compilers with different STL implementations and add. ext.less headers I think a global (super)set will do. Keep it simple
HS2

[Sandra]

The extensionless file settings currently are global, unless there is a bug.  Is that not what you are seeing?  I asked about per-workspace, since you requested a way to import them more easily, so I assumed you were changing them frequently.  Did the settings not migrate from v18?

[mjdl]

The extensionless file settings currently are global, unless there is a bug.  Is that not what you are seeing?  I asked about per-workspace, since you requested a way to import them more easily, so I assumed you were changing them frequently.  Did the settings not migrate from v18?

Since this was a first beta of v19, I decided to try it out with a fresh profile (i.e. I simply renamed the v18 profile so it did not get imported). I will try the regular importing process sometime over the next couple of days.

I think I was reacting a little too sharply to the monotonous clicking-about and typing necessary to get all the C++ extensionless header files by name into the manager using the general ant pattern "*/include/**/header". Eventually I just used the file selection dialog alone and multiple selected names.

As HS2 says above, keep it simple. I think there is no good case for not leaving it a global file list, but I'd like the additional option in the main manager panel of a plain multi-line text entry box where the user rapidly edits the file names/patterns and their file types one to a line and clicks OK/cancel at the end, no special file import/export necessary.

In fact the current UI of distinguishing all the different types of file/pattern selection is unnecessarily complex: a simple 2 column list box of absolute file names, full paths, or quoted Ant/Slickedit regex patterns and their file types will have enough distinguishing syntax for the underlying Slickedit machinery to generate the full internal XML format.

[Sandra]

Ah, okay.  Sorry about the confusion, I think I understand now.  We can certainly look into simplifying the UI.  I see what you mean - if you have to add a lot of entries, it can get tedious.

Thanks for the feedback!