search

fruxo / turbobadger

Small footprint UI library for hardware accelerated games & applications
579 stars 85 forks source link

TBEditField: caret and tags considering #69

Open inner100p opened 8 years ago

inner100p commented 8 years ago

Styling not affect on moving of text cursor. When styling switched on, the caret move through text without consider the tags, and we can edit "invisible" text of tags.

tesch1 commented 8 years ago

Yup. It's non-intuitive for anyone except a developer who understands the underlying TBEditField. I'm trying to build an editor that has syntax highlighting, which seems to be impossible because the editing keeps editing the formatting which should be invisible.

Caret position and editing commands (delete/insert) are normally independent of the styling. Maybe there could be a way to switch back and forth between an edit-mode that displays the formatting WITH the tags (to allow editing the tags), and an editing mode that only displays/edits text (but also displays formatting).

Also useful would be functions to insert/remove format tags around selections.

Any thoughts on how to approach this?

Maybe two types of caret positions - one that's formatting-aware and one that's tag-blind?

fruxo commented 8 years ago

The # 1 usecase I've heared developers trying to use styling for is syntax highlighting. The usecase i had in mind when adding styling support was completely different: static prettified text (like changelogs, hints with injected icons and other static UI stuff). I think making editing style-aware is unnecessary complicated to solve the syntax highlighting case. In fact, it's probably pretty slow to first generate all the style and then have TBEditField parse it.

A better approach to syntax highlighting would be to just have another way to override painting of each text fragment on the fly. There may also be a need to affect where text is broken into fragments (in special cases). Some extra "user" field in TBBlock to store cached stuff for this purpose would be cheap too.

Maybe the "fragment traverser" refactorization i've mentioned in the code would be a natural first step (and then override the traverser that paint all fragments) but something could probably just be added on top of the current code instead.