Feature request: textarea
Hi,
I have just found your package. It is very interessting and I am trying to write an application with it. I would like to know if there is any plan to create a texarea in the near future ?
Thanks. NT
Hi, glad you like it. I don't have concrete plans for a text area yet. I have been thinking about extending the TextView class to make it editable. However, adding that would get me very close to implementing a full text editor:
- Adding/removing characters
- Navigating the text (not trivial with automatic line breaks etc.)
- Selecting areas, cutting/pasting (optional at first maybe)
- Deal with
TextView's color/region tags somehow - Rewriting the
Formclass so editableTextViewobjects can also be included (e.g. this could break the horizontal layout)
So it's not a minor thing to add. I could add an "on roadmap" label to this issue if this is something you definitely need. This would mean I will eventually add it. But it could then still be some time before that happens and I don't know how urgent your need is here. (See #23 for an example of an "on roadmap" feature.)
Do you have a specific use case where an InputField is not enough?
I have intention to use tview to write several console applications. And in some of them, I need to modify a value under JSON format for example. I understand that it is not easy to but I think it is necessary when we edit some complexe data such as json, html etc. I have been thinking about making TextView to be editable. But I have not really entered in the code yet.
For your own project, you could probably come up with something simple by using TextView, intercepting key events with SetInputCapture(), and using regions and highlights to simulate a cursor.
TextView is already very complex. You can try to extend it but with so many things to consider -- and given that I have to maintain it in the long term -- I'm not sure I will merge any pull requests in that direction.
So I'm adding the "on roadmap" label. This means I will implement this but I don't know yet when. I will have to dedicate quite some time to it.
Yes, I think that I can manage in my projects so dont worry about when you will implement it. Anyway, thanks to add "on roadmap" for this request because it will be really nice to have it as a base element.
Thanh NGUYEN
On 5 March 2018 at 14:50, rivo [email protected] wrote:
For your own project, you could probably come up with something simple by using TextView, intercepting key events with SetInputCapture() https://godoc.org/github.com/rivo/tview#Box.SetInputCapture, and using regions and highlights https://godoc.org/github.com/rivo/tview#TextView to simulate a cursor.
TextView is already very complex. You can try to extend it but with so many things to consider -- and given that I have to maintain it in the long term -- I'm not sure I will merge any pull requests in that direction.
So I'm adding the "on roadmap" label. This means I will implement this but I don't know yet when. I will have to dedicate quite some time to it.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rivo/tview/issues/64#issuecomment-370424717, or mute the thread https://github.com/notifications/unsubscribe-auth/AWQwr4LCdrEFSWgjQoG8QlUnxGCcvJoFks5tbUKfgaJpZM4Sb2jx .
@uthng Just fyi, there is also a full blown editor atop of tcell, https://github.com/zyedidia/micro, which is MIT licensed and of course is quite tuned to editing text. With mouse support, copy-paste clipboard, macros, plugin system, highlighting, etc.
a full blown editor atop of tcell, https://github.com/zyedidia/micro
In addition to micro/if you prefer emacs keybindings, I have ported godit to Garrett's tcell, calling the result gemacs: https://github.com/glycerine/gemacs. It is an emacs written in pure Go. As it uses tcell, it should (at least, theoretically) be tview compatible.
Hi everyone, are there any news about textarea? I would like to use tview on my current project, but I need to be able to edit few lines of text. We already have controls working in inputbox, so maybe we are closer to have multiline inputbox? I really want to avoid using gocui. ;-)
Apologies for taking so long but this is really a more complicated issue for which I currently don't seem to have the time. I will definitely add it but cannot give you a time frame for this.
Out of interest, in your application, would you need support for region and colour tags while editing? Or are you looking for a simple text-only editor here?
@rivo no need for apology, it is open source, we all are working on it when we have time or/and we want!
I personally think, that simple text-only editor would be needed most of times. And in my app this is also the case, regions and color tags would not be used.
I made something using regions and highlights, maybe this is useful to someone. The code is quite error prone and unperformant and it still has some bugs, but overall it works! I would not recommend something like this for editing big chunks of text. I might replace it with an actual tview component at some point though. And if I do, I'll create a PR.

The code can be found here: https://github.com/Bios-Marcel/cordless/blob/master/internal/ui/editor.go
@ernierasta https://github.com/glycerine/gemacs doesn't ship with rivo/tview, but that matters little. It uses tcell too and it would take a few trivial lines of code to use it as your textarea editor.
@glycerine any chance you have a demo on hand with embedding either editor as a tview form field?
@matheusd not off hand.
@glycerine @Bios-Marcel thank you both for valuable input! I will probably use one of given options. And I am joining to @matheusd question, example would be very welcome.
Thank you guys again!
I tested @Bios-Marcel Editor impl, and while it does have issues, it seems reasonable for a first try.
The only thing I felt missing from it was being able to move up/down lines.
Rather than implement editor functionality in tview, would it make more sense to simply punt to using $EDITOR? That way whatever workflow/bindings the user is already accustomed to works seamlessly.
@lhanson that is not what this ticket is about. You can probably do what You describe right now. We are talking about textarea here. It is similar to box You put Your comment in, it has multiple lines and at least some basic editing capabilities. You need to have it forms in app, not as separate thing. But thank You for stopping by. :-)
I've just posted femto, a tview-compatible editor component derived from the micro editor. The API is a work-in-progress, but I think the basics should work.
Great work @pgavlin! Thank you for letting us know!
Thanks for letting us know, I'll keep and eye on it and might use it :D
I've just posted femto
Hey @pgavlin thanks for that! I've used femto with ssh paste.run
I'll probably be forking and making some pull requests.
@rivo thank you for creating a wonderful library for tui. I am using your library with my project here.
https://github.com/7onetella/minidoc
for one liner I use TextInput, for multiple lines, I exec to VIM, and back.
I am happy with using VIM for multiline edit but not everyone is comfortable with VIM.
it would be nice to have textarea for sure but I understand that you have a normal busy life like the rest of us. thank you anyway.
Add minimal PR #447 with multi-line text editor or TextArea
Is anyone aware of another widget (in any repo) that implements this functionality, even in a very basic way? I fully understand the difficulties in doing an implementation "the right way", and I excitedly await a more official "textarea" from @rivo, but I have found myself 99% of the way through an application and blocked by the the need for a simple, multiline input, and I cannot make it work. Femto is too heavy, #447 requires forking (i.e. I can't isolate it as an internal import because it depends too heavily on internal changes and dependencies), and shelling out to $editor is completely broken, at least for me. I don't need much, and can hack quite easily around anything more than "a box that I can shuffle text around in", but I also don't want to dive into a rabbit hole making a new widget when I have been able to get so far without diving into internals at all. I am at the point where I am considering vendoring the entire library with a diff of #447 overlaid on top of it just to get this one piece of functionality, so I am asking here as a last resort.
@flowchartsman see my comment above. https://github.com/glycerine/gemacs
@glycerine, I did (by the way, love your libraries), but, like you mentioned above in 2018, there's no quick example of embedding it as a widget and when I looked at the repo I was a little daunted by the complexity, and you appear to vendor tcell as well, so I honestly didn't consider it an option and looked elsewhere. Perhaps I should take another look, though some more guidance would be helpful.
Sorry, its been too long. You'll have to dive in, I'm afraid. The rabbit hole is likely very shallow though with gemacs an micro examples.
Please check out #594
This issue should be closed now that the TextArea widget has been implemented.
See #594