Community

XML is slower and fatter than a simple configuration file.

It's a configuration file for a specific application. I can't think of any reason another application should ever be interested in it.

I'd be willing to accept an xml file format for TP settings, as long as TP uses a very basic, non-dtd-validating, xml parser. A basic basic basic xml parser is easy to build, and won't add to much to TextPad's code footprint.

But, adding a dtd-validating, DOM Level 3 complaint xml parser to TP could easly add more than a megabyte to the application size. Totally not worth it.

But, adding a dtd-validating, DOM Level 3 complaint xml parser to TP could easly add more than a megabyte to the application size. Totally not worth it.

I don't agree that it wouldn't be worth it.

If there were a validating xml parser within textpad, it could be used to validate our own files as well...

But then, a dtd-validating parser wouldn't really fit my needs, I'd need a XSchema-validating parser...

MudGuard wrote:If there were a validating xml parser within textpad, it could be used to validate our own files as well...

But then, a dtd-validating parser wouldn't really fit my needs, I'd need a XSchema-validating parser...

Just run a script that does what you need from within Textpad. Simple.

Just because you want something doesn't mean the average user doesn't think it's bloat.

MudGuard wrote: But then, a dtd-validating parser wouldn't really fit my needs, I'd need a XSchema-validating parser...

Dito: I think it would be a nice addition to TextPad, because now I have to step-out of TextPad all the time. I have not found any XML validator that I could integrate with TextPad at this time...

Maybe this will be a functionality for an add-on?

Jan Paul

Get a room funboys! (errr... ok, another thread in any case!)

rkrite wrote:

gracefool wrote:XML is a waste of time and resources if the file isn't going to be used in other applications.

Wouldn't assuming that a data source (or file) won't be used for another application be more time wasting than initially giving the file flexability from the beginning, if by some chance the file does become a source of data?

How can you waste time you haven't spent yet? The INI format is easy enough to convert to naive XML if you ever need that functionality, and if you don't, you don't lose anything (presuming INI is more natural to how the settings are internally stored than XML, which is frankly often the case).

Remember, really parsing true XML is harder than you think.

maniac wrote:i moved everything to a folder - textpad system files in one, syn files, macros, dictionaries, clip, etc in another

then just update all the settings in textpad to reflect that and use those folders, then export the REG file into that folder, zip the folder, and bam

next time you install textpad or whatever, just recreate the folder, unpack, and double click the REG file

This is a fine one off solution. But TextPad has enterprise level customers. It needs an enterprise level solution.

VIM on *Nix boxes has a .vim folder in the user folder. If you tar it you can move it anywhere.

I have hundreds of boxes with VIM configured perfectly. I'm not saying VIM (or *Nix) is easy, but I can "scp bronosky.com/vimconf.tgz; tar -C ~ -zxf vimconf.tgz" in about 4 seconds.

It would be nice to export settings when new people come to work in a company (how often do you rebuild your computer and need to do this?).
However, as sb already pointed out, a simple registry exporting batch file together with zipping up some files does the trick very nicely. Why not just include that batch file in releases of textpad, with a link to it in the start menu?