Bug 144353 - incorrectly recognized filetype -- Makefile.h/.cpp
Summary: incorrectly recognized filetype -- Makefile.h/.cpp
Status: RESOLVED FIXED
Alias: None
Product: kate
Classification: Applications
Component: part (show other bugs)
Version: 2.5
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-17 19:43 UTC by Maciej Pilichowski
Modified: 2008-08-13 16:20 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Pilichowski 2007-04-17 19:43:09 UTC
Version:            (using KDE KDE 3.5.6)
Installed from:    SuSE RPMs

I am writting a class for handling makefiles (C++) so I created two files for the start, Makefile.h and Makefile.cpp -- but kate recognizes them as... makefiles :-)
Comment 1 Maciej Pilichowski 2007-04-17 20:32:38 UTC
PS. _Makefile.h , Makefile_.h, MMakefile.h are all recognized as makefiles. Finally MakefileClass.h is for Kate C++ file.
Comment 2 Matthew Woehlke 2007-04-17 23:35:08 UTC
WORKAROUND: Create a file type (configure editor->file types) to override the Other/Makefiles for *.cpp and *.h (make sure it has higher priority).
Comment 3 Sebastian Pipping 2007-09-13 04:07:08 UTC
The wildcard for Other/Makefile current is set to "*makefile*;*Makefile*".
Why a star in front? "makefile*;Makefile*" and a slightly lower prio than
C++ would fix it.
Comment 4 Matthew Woehlke 2007-09-13 04:27:33 UTC
> Why a star in front?

"GNUmakefile" :-). I'll still say that making the detection lower-priority is the way to go. I don't think there is any need to remove the *'s.
Comment 5 Sebastian Pipping 2007-09-13 05:00:16 UTC
I think we should look at it the other way around: We should only keep stars if they can eat an _infinite set of strings_ like with "*.cpp". If its just "GNUmakefile" that we need it for, then it should be much faster to add that sring as a constant: "GNUmakefile;makefile*;Makefile*". All that wildcard matching takes way to long anyway.
Comment 6 Andreas Pakulat 2007-10-22 23:36:23 UTC
Somebody changed the default filetype pattern for Makefiles in Kate to include *makefile*, which not only fits GNUmakefile, but also things such as qmakefile.cpp, qmakefile.h, somedir/makefile.cpp, somedir/makefile.h

IMHO such a generic pattern is of no real use, it matches far too many false positives. I think the list should read:

GNUmakefile;makefile.*;Makefile;Makefile.*

Or are there common makefiles named MakefileFoo? 

Also as filetypes haver higher precedence than .kateconfig files, this will confuse people that have a xxxmakefileyy in a dir, because only for that file the settings from the .kateconfig won't apply.
Comment 7 Andreas Pakulat 2007-10-22 23:39:03 UTC
PS: And yes, changing the priority to -1 or -2 is also a good idea. *.cpp that actually contain Makefile code.
Comment 8 Sebastian Pipping 2007-10-23 00:28:58 UTC
I agree moving away from "*Makefile*" is the right track. However why "GNUmakefile;makefile.*;Makefile;Makefile.*" as the solution? What's the second wildcard good for?
Comment 9 Matthew Woehlke 2007-10-23 01:54:26 UTC
> What's the second wildcard good for?

makefile.win, Makefile.cvs, etc.
Comment 10 Andreas Pakulat 2007-10-23 01:56:40 UTC
Of course the second wildcard only makes sense if kate uses case-sensitive matching, which I assumed it does given that the current setting is

*Makefile*;*makefile*

If kate does the matching without case-sensitivity then the 2nd wildcard can go. Else you need it to match for example Makefile.cvs.
Comment 11 Sebastian Pipping 2007-10-23 03:54:23 UTC
I'm really no sure what the final decision should look like. Maybe listing all cases and make it a finite set? Of what I have seen here and elsewhere the list would be:

* Makefile
* Makefile.in
* Makefile.am
* GNUmakefile
* Makefile.gnu
* Makefile.bsd
* Makefile.bcc
* Makefile.cvs
* makefile.win

For the wildcard matcher ordering by likelyhood is also important.
What do you think? Any additions or tunings? Bad idea in general?
Comment 12 Sebastian Pipping 2007-10-23 03:58:55 UTC
SVN commit 728342 by sping:

First stage for fixing "*Makefile*" wildcard
CCBUG: 144353


 M  +1 -1      makefile.xml  


WebSVN link: http://websvn.kde.org/?view=rev&revision=728342
Comment 13 Matthew Woehlke 2007-10-23 04:21:53 UTC
> Maybe listing all cases and make it a finite set?

I think it's a bad idea. I have some stuff lying around like Makefile.linux, Makefiele.solaris, etc. 'Makefile.<foo>' is a modestly common naming paradigm, but users are likely to invent things to replace '<foo>' with, that won't be known in advance.
Comment 14 Andreas Pakulat 2007-10-23 10:30:10 UTC
I agree with Matthew. Also Makefile.Debug, Makefile.Release are pretty common (just look at Qt projects, sure you won't change those but you might look at them in kate).

I think forcing a dot into the name and having special cases when a makefile has a "prefix" (i.e. GNU) should be ok.
Comment 15 Christoph Cullmann 2008-08-13 16:19:07 UTC
SVN commit 846458 by cullmann:

CCBUG: 144353

 M  +2 -1      makefile.xml  


WebSVN link: http://websvn.kde.org/?view=rev&revision=846458
Comment 16 Christoph Cullmann 2008-08-13 16:20:21 UTC
Done now, allowing makefile,Makefile and GNUMakefile + .* suffixes, better than nothing.