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

List:       kde-kant
Subject:    [Kde-kant] Thougths on KWrite
From:       Anders Lund <anders () alweb ! dk>
Date:       2001-03-05 12:21:54
[Download RAW message or body]

Hi all,
As some of you will know I attended the Danish LinuxForum 2001 this saturday. 
At that occation I had the chance to talk a bit to ao Matthias Ettrich and 
show him a recent screenshot. When I told him that we are using kwrite, he 
said oh, why don't you use qttext? Asked why he didn't like kwrite, he 
pointed to some of the facts with kwrite that I too feel needs to be changed 
before we can present a really good editor.

His first point was the thing with indent: kwrite dosen't currently allow to 
set indent char and width, it uses the tab width in combination with the 
"convert to chars" setting. This needs to be changed, and as the kwrite 
indent() accepts a number for how much to indent, this won't present too much 
of a problem.
When I said that I feel that editor profiles should possibly be managed in 
named profiles with a list of MIME types so that you could have different 
settings for indent, selection properties etc he agreed that that would be 
really nice. I think this would be a nice feature, my suggestion is that 
theese properties could be stored in xml files and managed by kwrite similar 
to how highlightning is managed, though here we could keep each profile in a 
file of its own.

We also discussed the bookmark issue, and my thoughts of extending the 
bookmark features of kwrite in such a way that bookmarks can be created by 
the client [possibly represented by a plugin] as well as by the user, and 
with better use of bookmark names was well recieved too. 
He mentioned that in an upcoming release of qt, regexps will support 
backreferences similar to perl regexps, which I find exiting, as it will 
allow me to implement some kind of "autobookmarking" feature, where a user 
can have a document indexed using a regex with a backreference to decide for 
the name.

Finally, he suggested that we would implement some support for emacs magic 
tags, which I too think would be nice, since it will help many people to 
easily migrate to kant, and surely many of us expects a good editor to react 
to theese.

-anders
-- 
Go for a visual ride of GUI history
http://www.pla-netx.com/linebackn/guis/guitimeline.html

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