But I'm wondering if we really want to add every possible file extension that can contain XML data... At some point we got into real trouble with that approach. I think the better approach is to read first line of the file and if there is
<?xml version="1.0" encoding="Windows-1252"?>
line only then recognize it as XML file.
And add only file extensions we know can have XML formatted data but for some reason don't have that first line as filename extensions to editor code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why not.. XML files are becoming such a standard format we can have some special handling for them. And in file compare the extra file open/read/close should not have any negative effect to the speed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've done some changes to highlight xml files even if they don't have xml extention. I hope you'll find them useful. I posted the patch as a unified diff this time.
Regards,
bulklodd
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This looks like clever way to do it - better than I thought initially.
One minor thing:
- can you set the type with call SetTextType(CCrystalTextView::SRC_XML) - using filename extension is somewhat ugly and fragile. As we end up matching that extension against types anyway..
Another of reservations I have is:
- regular expressions are by definition "slow". Perhaps simple find/match would be better. BUT when loading file there are lots of much slower things - this should not really matter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> regular expressions are by definition "slow".
> you're right, but i'm not used to considering them as slow :) anyway i'll
> try to find another way to do that.
This is not a blocker for this patch - rather lower priority optimization we can do later. Problematic cases probably are MSXML produced XML files which don't have EOL characters so the "get first line" actually returns whole XML data from the file. :(
If you fix the first point in my earlier comment I can commit this patch.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey there,
I fixed your first point with using filename extension, but I left the regular expression. If you insist, I can replace it by 2 separate searches but they look less reliable than the RE.
Anyway if something's wrong with my code, don't hesitate to point it out.
Regards,
bulklodd
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You mean app.config (and web.config etc) files?
Adding .config as filename extension to XML syntax highlight implements this.
By the way, should add VS project files (*.vcproj; *.vbproj) too?
Hmmm.. Yes, they are XML files too.
But I'm wondering if we really want to add every possible file extension that can contain XML data... At some point we got into real trouble with that approach. I think the better approach is to read first line of the file and if there is
<?xml version="1.0" encoding="Windows-1252"?>
line only then recognize it as XML file.
And add only file extensions we know can have XML formatted data but for some reason don't have that first line as filename extensions to editor code.
Reading the first line to recognize XML files sounds pretty good. Shall we code it then?
Why not.. XML files are becoming such a standard format we can have some special handling for them. And in file compare the extra file open/read/close should not have any negative effect to the speed.
Hey there,
I've done some changes to highlight xml files even if they don't have xml extention. I hope you'll find them useful. I posted the patch as a unified diff this time.
Regards,
bulklodd
Thanks!
This looks like clever way to do it - better than I thought initially.
One minor thing:
- can you set the type with call SetTextType(CCrystalTextView::SRC_XML) - using filename extension is somewhat ugly and fragile. As we end up matching that extension against types anyway..
Another of reservations I have is:
- regular expressions are by definition "slow". Perhaps simple find/match would be better. BUT when loading file there are lots of much slower things - this should not really matter.
Oh, and I also moved this to patches list.
>> can you set the type with call SetTextType(CCrystalTextView::SRC_XML)
>> using filename extension is somewhat ugly and fragile
Ok, I agree, I'll do that
>> regular expressions are by definition "slow".
you're right, but i'm not used to considering them as slow :) anyway i'll try to find another way to do that.
>> regular expressions are by definition "slow".
> you're right, but i'm not used to considering them as slow :) anyway i'll
> try to find another way to do that.
This is not a blocker for this patch - rather lower priority optimization we can do later. Problematic cases probably are MSXML produced XML files which don't have EOL characters so the "get first line" actually returns whole XML data from the file. :(
If you fix the first point in my earlier comment I can commit this patch.
Hey there,
I fixed your first point with using filename extension, but I left the regular expression. If you insist, I can replace it by 2 separate searches but they look less reliable than the RE.
Anyway if something's wrong with my code, don't hesitate to point it out.
Regards,
bulklodd
I committed this with few style fixes:
- editlib code uses GNU style indenting with spaces
- we use space after commas
I don't insist on replacing RE with searches - like I wrote above it is lower priority optimization we can consider later on.
I also tested this with couple of files and seems to work as promised. So committed to SVN trunk:
Completed: At revision: 6654
Closing as the patch is committed to SVN.
Committed to 2.14 branch:
Completed: At revision: 7318