Description of problem:
The automatic syntax highlighting in kate is not reliable. Kate should rely on the content of a file rather than it's extension.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. $ kate comps-f11.xml.in (taken from http://cvs.fedoraproject.org/viewvc/comps/comps-f11.xml.in?revision=1.306)
No syntax highlighting, I have to select the markup type manually to get it.
xml should be choosen by default based on the header of the file of it's mime type.
After renaming the file to comps-f11.xml the highlighting is fine.
$ xdg-mime query filetype comps-f11.xml.in
So the mimetype is recognized properly, kate should indeed use that.
$ xdg-mime query filetype comps-f11.xml.in
Did you checkup the file or download it? I checked it out.
$ cp comps-f11.xml.in comps-f11.xml
$ xdg-mime query filetype comps-f11.xml
So obviously kate uses the extension rather than the mime type. Other programs, such as geany or gedit correctly select the markup.
$ wget -q http://cvs.fedoraproject.org/viewvc/comps/comps-f11.xml.in?revision=1.306
$ xdg-mime query filetype comps-f11.xml.in\?revision\=1.306
Ah, recent fixes to xdg-utils in rawhide may be helping here.
inside a kde session.
If you want to test stuff directly, try
$ kmimetypefinder comps-f11.xml.in
$ file comps-f11.xml.in
comps-f11.xml.in: XML document text
Kate just relies on shared-mime-info to detect the mimetype. So whatever xdg-mime returns is also what Kate will detect. But xdg-mime is also just a frontend, shared-mime-info contains the actual data.
I'll let the shared-mime-info maintainers decide whether to accept this as a bug or close it as NOTABUG. Relying on the extension rather than the contents wherever possible is an intentional feature, it's much faster to detect the file type from the extension than to open the file and look at what's inside. So content matching is only used where extensions don't work reliably.
The "file" tool is mainly content-based, but it's obsolescent, shared-mime-info is what most current software uses. And the decision to rely on extensions more than on content matching is a deliberate design decision.
That said, looking at your differing results, it looks like this is already fixed in F12's shared-mime-info, isn't it?
kmimetypefinder is working ok to identify mimetype (see comment #5) so it's probably not shared-mime-info.
Sho_ in #fedora-kde earlier commented that kate has some internal mime handling bits, and is probably simply doing the wrong thing here.
If kate opens the file, it should definitely be looking at the mime-type associated with the data, rather than just the filename if it returns text/plain.
I tested shared-mime-info, and it returns application/xml for the comps.xml.in file as expected for both file data, and using the actual file. Filename fails as expected.
Reassigning to kdesdk, I don't know in which package kate is.
Steven, unless you suddenly became shared-mime-info maintainer, don't set the bug status to assigned...
Kate resides in kdesdk, so that's OK. (The actual fault may be in the KatePart in kdelibs, but that's our problem to sort out anyway. :-) )
Steven M. Parrish is a triager (the KDE triager), he was just following the bizarre Fedora convention of using ASSIGNED as "confirmed". (We're shoehorning our workflow into the states in this Bugzilla which are designed for RHEL.)
(In reply to comment #9)
> I tested shared-mime-info, and it returns application/xml for the comps.xml.in
> file as expected for both file data, and using the actual file.
For me xdg-mime returns text/plain but not text/xml. Please note that this bug was filed against F11 and not rawhide.
xdg-mime is a pile of crap and will use different ways of determining the mime-type depending on the desktop environment.
It will use gnome-vfs under GNOME, kfile under KDE, and "file -i" under others.
I tested using the mime test suite in shared-mime-info, using the latest xdgmime git master. I don't believe we changed anything related to XML mime-types in the last few releases.
Well, if gnome-vfs and kfile return different things, that's a bug in either of them, as they both use shared-mime-info.
Except that gnome-vfs (and gvfs) use the upstream xdgmime reference implementation, and kfile uses a KDE specific implementation, even though they use the same data.
kmimetypefinder (comment #5) is fine. kfile is from kde3.
Work to improve/fix kde4 integration in xdg-utils is ongoing (current versions do indeed use kmimetypefinder on kde4 correctly). So, for < F-12 on kde4, xdg-mime isn't working, granted.
Now, Sorry I didn't help properly triage this on my previous comments.
From the looks of it, addressing this may be non-trivial (comment #8), so I think the best way forward is to report this bug to kde upstream, bugs.kde.org.
Thank you for taking the time to report this issue.
This is an issue that needs to be addressed by the upstream developers. Please report this at http://bugs.kde.org and then add the upstream report information to this report. We will monitor the upstream report for a resolution to this issue, and will review any bug fixes that become available for consideration in future updates.
Setting status to NEEDINFO, and awaiting upstream bug report URL for tracking.
Thanks in advance.
Steven M. Parrish - KDE Triage Master
- PackageKit Triager
Fedora Bugzappers volunteer triage team
Removing NEEDINFO as Steven was kind enough to report the bug upstream.
Thanks, let's continue tracking this upstream then.
(Feel free to re-open if anyone in fedora land has the time/mojo to work to help fix this ourselves).