[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: Merging Syntax + File-Types
From:       Christoph Cullmann <cullmann () babylon2k ! de>
Date:       2007-05-21 17:08:17
Message-ID: 200705211908.17142.cullmann () babylon2k ! de
[Download RAW message or body]

On Monday 21 May 2007 17:23:49 Matthew Woehlke wrote:
> Dominik Haumann wrote:
> > On Monday 21 May 2007, Matthew Woehlke wrote:
> >> Christoph Cullmann wrote:
> >>> Now the question is: should I merge the hl + filetype menu to one
> >>> "mode" menu? The user still can switch to the hls by using their modes,
> >>> he can switch to it's own modes, would we loose something?
> >>
> >> Yes. Right now I often use KATE file type Sources/C(2) (one I made) with
> >> any of several highlighters (e.g. Java, C++, C, C-Custom1, C-Custom2,
> >> C#, etc). This lets indentation profiles be stored in one KATE file type
> >> that can be used with multiple highlighters (i.e. 'actual' file types).
> >> Otherwise if I have two projects with different indentation styles,
> >> instead of M+N modes, I now have M*N modes, where M is indentation
> >> profiles I use, and N is highlighters I use.
> >
> > If I understood you correctly you still want to be able to create your
> > own filetypes (which have a higher priority).
>
> I may be misunderstanding Dominick. Right now we have highlighting and
> file type, which are independent; one of each is always active. That is,
> selecting a highlighter does not change the file type (indeed, does not
> change any settings except the highlighter) and selecting a file type
> only changes the highlighter if the file type specifies a highlighter.
> It sounds like after this there would be two problems:
> 1. can't tell, independently, what highlighter and what file type (i.e.
> indentation profile) are selected.
> 2. selecting a "highlighter" might nuke indentation settings.
>
> It would also be /really, really nice/ if highlighters that don't
> specify other settings would not get a file type auto-created, so as to
> minimize clutter to things that actually do something.
I think the katedirconfig files are the solution for your problem, they are 
best used to tweak settings project based. Yes, I agree that there is that 
one drawback, that there is no independend detection of filetype and 
highlighting, but on the other side, this is just more straight forward. Kate 
now ships with a set of predefined modes, the stuff we have as highlighters. 
Atm no indenters are specified in the highlightings, but that is the way to 
go, that highlighters can reference matching javascript indenters.

I really think, the current way is generic enough, you have this three levels 
atm:

1. autodetection of mode, by mimetype/wildcard/priority
2. searching for the .kateconfig files
3. searching for variables in the file itself

With this three level hierachy, still every need should be fullfilled. You can 
have global modes, which define a well-chosen set of default for a 
language/documenttype, you can define project wide settings with .kateconfig 
files and you can overwrite everything with variables in the file itself.

What this changed removed, was a fourth level, which was messed not that 
correct either before or after phase 1.. I don't really think this will be a 
that big problem. Other good thing is, that providing the KTextEditor with a 
API to chose the mode, apps embedding the part will not only be able to 
switch to a specific hl but even allow to switch to the real mode, the user 
is able to customize (for example adding addtional variables for the 
Sources/C++)

cu
Christoph

-- 
Christoph Cullmann
KDE Developer, Kate Maintainer
http://babylon2k.de, cullmann@kde.org
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]