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

List:       kwrite-devel
Subject:    Re: Template Interfaces
From:       Sven Brauch <svenbrauch () googlemail ! com>
Date:       2014-04-17 16:39:26
Message-ID: 1568281.zRAxFvQ7Bh () localhost ! localdomain
[Download RAW message or body]

Hi!

On Monday 17 March 2014 22:42:17 Christoph Cullmann wrote:
> Otherwise I would like to hide these interfaces for KF 5.0 and add the in KF
> 5.1 if they got cleaned up.
I looked at it a bit. I think we should reduce the interface to one single 
function:

bool insertTemplateText ( const Cursor& insertPosition,
                          const QString& templateString,
                          const QHash<QString,QString>& initialValues=...,
                          const QString& templateScript=QString() );

which would insert a template string at the given position, with the given 
default values and the script.

The whole script registrar stuff I would drop from the interfaces. It should 
be handled internally. Since there is no longer different implementations of 
KTextEditor (^^) all the "insertTemplateTextImplementation" and 
"KTE_INTERNAL_setupIntialValues" stuff would just become an implementation 
detail, too (right?). That only leaves the above function.

In addition, I'm not sure how to deal with the macros. Since it has the power 
of running arbitrary JS chunks anyways, it seems a bit weird to have a 
separate implementation of some things in C++. For example if you want to 
insert the current year, you can just put a script which inserts the current 
year -- no? There's no need for C++ code doing specifically this (at least for 
most things). Things not available to JS (hostname?) could possibly be given 
to the JS interpreter as global variables, would that work?

If syntactic sugar is needed, fine, but then it should be done explicitly as 
syntactic sugar I think.

Strictly speaking I see the same problem with the regex and mirror mode. Those 
could be implemented with the Script mode very easily, without separate C++ 
code. For example, the old regex-replace syntax could simply be syntactic 
sugar for calling a predefined JS function to do the regex replace.

If you agree, I'll try my luck with this and come up with a patch.

Greetings!
_______________________________________________
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]