Bug 528499 - Automatic syntax highlighting in kate not reliable
Summary: Automatic syntax highlighting in kate not reliable
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: kdesdk
Version: 11
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Than Ngo
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-10-12 14:23 UTC by Christoph Wickert
Modified: 2009-12-02 13:48 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-12-02 13:48:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
KDE Software Compilation 211025 0 None None None Never

Description Christoph Wickert 2009-10-12 14:23:17 UTC
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):
kdesdk-4.3.1-1.fc11.x86_64

How reproducible:
always

Steps to Reproduce:
1. $ kate comps-f11.xml.in (taken from http://cvs.fedoraproject.org/viewvc/comps/comps-f11.xml.in?revision=1.306)
  
Actual results:
No syntax highlighting, I have to select the markup type manually to get it.

Expected results:
xml should be choosen by default based on the header of the file of it's mime type.

Additional info:
After renaming the file to comps-f11.xml the highlighting is fine.

Comment 1 Rex Dieter 2009-10-12 14:36:33 UTC
Interesting,

$ xdg-mime query filetype comps-f11.xml.in
application/xml

So the mimetype is recognized properly, kate should indeed use that.

Comment 2 Christoph Wickert 2009-10-12 14:51:32 UTC
Strange:

$ xdg-mime query filetype comps-f11.xml.in
text/plain

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
text/xml

So obviously kate uses the extension rather than the mime type. Other programs, such as geany or gedit correctly select the markup.

Comment 3 Christoph Wickert 2009-10-12 14:53:42 UTC
Hmmm...

$ 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
text/plain

Comment 4 Rex Dieter 2009-10-12 14:58:42 UTC
Ah, recent fixes to xdg-utils in rawhide may be helping here.

I'm using 
xdg-utils-1.0.2-13.20090928cvs.fc12.noarch
inside a kde session.


If you want to test stuff directly, try
kmimetypefinder comps-f11.xml.in

Comment 5 Christoph Wickert 2009-10-12 15:10:18 UTC
$ kmimetypefinder comps-f11.xml.in 
application/xml
(accuracy 40)
$ file comps-f11.xml.in 
comps-f11.xml.in: XML  document text

Comment 6 Kevin Kofler 2009-10-12 19:55:25 UTC
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.

Comment 7 Kevin Kofler 2009-10-12 19:57:07 UTC
That said, looking at your differing results, it looks like this is already fixed in F12's shared-mime-info, isn't it?

Comment 8 Rex Dieter 2009-10-12 20:00:28 UTC
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.

Comment 9 Bastien Nocera 2009-10-13 01:18:59 UTC
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...

Comment 10 Kevin Kofler 2009-10-13 02:37:21 UTC
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.)

Comment 11 Christoph Wickert 2009-10-13 08:52:19 UTC
(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.

Comment 12 Bastien Nocera 2009-10-13 11:54:14 UTC
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.

Comment 13 Kevin Kofler 2009-10-13 12:55:38 UTC
Well, if gnome-vfs and kfile return different things, that's a bug in either of them, as they both use shared-mime-info.

Comment 14 Bastien Nocera 2009-10-13 13:17:14 UTC
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.

Comment 15 Rex Dieter 2009-10-13 13:22:29 UTC
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.

Comment 16 Steven M. Parrish 2009-10-18 20:17:27 UTC
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
https://fedoraproject.org/wiki/BugZappers

Comment 17 Christoph Wickert 2009-10-18 21:40:56 UTC
Removing NEEDINFO as Steven was kind enough to report the bug upstream.

Comment 18 Rex Dieter 2009-12-02 13:48:10 UTC
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).


Note You need to log in before you can comment on or make changes to this bug.