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

List:       kwrite-devel
Subject:    [Bug 58340] Tokens to unicode symbols. Encoding and Decoding.
From:       Jorge Adriano <jadrian () mat ! uc ! pt>
Date:       2003-07-22 21:36:31
[Download RAW message or body]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
     
http://bugs.kde.org/show_bug.cgi?id=58340     




------- Additional Comments From jadrian@mat.uc.pt  2003-07-22 23:36 -------
Ok, I've wrote to much in the report, let me try and make things more clear. 
My wish report: 
1. encode symbols (in the buffer) into tokens. 
2. parse input and decode tokens into symbols. 
 
With (1) you can do things like use Unicode symbols in your text, and save it as ASCII. 
This is quite usefull in some programming/markup languages, for details see above. 
Wish (2) is meant as an inverse of (1). When opening your text, it should be parsed and 
tokens decoded and displayed as symbols.  
The parser should also work "as you type", that is decoding the symbols into tokens as you 
type them. This way it keeps the display consistent and it provides a mean to insert the 
symbols. 
For applications see the original report above. 
 
Now in the original report, for completude, I refered to another feature that would be useful. 
3. Some way to insert Unicode symbols. It should work like:  
- press special key (cursor look changes) 
- type symbol name/press return (symbol is displayed) 
It would be quite useful in lots of situations, and great combined with wish (1), this way you 
wouldn't have to know the every different syntax you use for the tokens, you would have a 
standard way to insert them. 
 
(1) seems like Kate stuff to me, no problem about that IMO. 
(2) might need deeper input support like Christoph puts it (The "parse as you type" feature. 
Parsing when opening a text document or by pressing some key should offer no problem). 
If that is the case where should I report it? 
 
(3) like Aaron says, might belong in the X11 level (at least part of the implementation, as I 
think it would always need some KDE specific code), but so do transparencies, drop shadows, 
etc., and we have all kinds of hacks for faking that stuff becouse waiting for real support in X 
would take forever! Why not also do it for something that actually seems *useful*, and most 
probably would require much less effort. 
Again, maybe deeper input support might be needed but I have no idea where to report it.
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]