Text Fields and Editor about chrysalisp HOT 30 CLOSED

Hi sorry I’ve been away on business for a few days! I’m back tomorrow and will assist on this and look over the new wallpaper stuff.

But I would start by looking at the gui/label/class files. A editable text field widget would probably inherit from label override the draw method to look a little different and provide overrides for the mouse and key event methods, like button, to make the label ‘text property editable. Plus when the enter key is pressed fire the action event in a similar manner to the button class does on a click event.

Funny I was having a conversation today with somebody and I said that ChrysaLisp don’t have a text field widget yet ;) so your timing is excellent:) lol

from chrysalisp.

Just pushed a couple of extra things to help out, scrolling and min/max doing something useful. But I will stop now as I've got to get on with some other stuff and leave this as your playground ;) And maybe others will join in with you too :)

I will add a textfield widget at some point as your likely to need that eventually to allow people to type in filenames etc. But plenty can be done now on this app.

Best Regards

Chris

from chrysalisp.

Now a text area widget would be more involved ! Some important questions need asking for a multi-line text widget.

Is it ment to allow any size of text file to be loaded into it ? Or just a paragraph of text maximum, reflowing a large text area with kerning and so forth can actually be quite slow ! Or demands a much more sophisticated data structure than a typical widget provides to keep the performance up.

I think we do need a text area widget that copes with a paragraph or so of plain text, but this is not what I would base a text editor on !

My gut tells me that a more sophisticated version of the VDU class with support for coloured characters (think syntax highlighting ability) and a text editor would use this as the display output for its own data structures for handling large amounts of text. Maybe that structure could be as simple as a vector of 'lines' of characters, fast access to each line of text etc.

I know there are text editors out there that use a structure for each paragraph where the cursor represents the 'hole in the middle of the data at the insert point...' but I've not ever looked into these things myself.

Time to do so ! ;) The obvious question to me would be 'what does Emacs do...'

from chrysalisp.

I am going to do you the extension to VDU class to support the 'vector of strings' editor structure, just today things got a bit busy with HackerNews article again....

You have me on a promise to get this to you ASAP ! ;) Chris

from chrysalisp.

I'd been attempting to bastardize something from a combination of terminal and docs to create some kind of basic editor. Most of my experimentation was done in docs, because it's setup for file display already, but I do think vdu is likely a better tool for text display.

I was working on something like this for inline character/string replacement:

(defun edit_string (string index change)
  (defq new_string (cat (slice 0 index string) change (slice (inc index) -1 string))))

I still need to add a conditional to lengthen the string in case the change is longer than the string from index. But it's a start.

My thoughts were to load the file-stream info file-buffer and index by y * w + x keeping current x and y and checking dirty. I'm not sure if that's practical though. Cursor movement would be fairly trivial this way since you did most of the work on that for terminal.

from chrysalisp.

Smaller more basic text fields should be easier to implement. But it seems as if you keep those widgets at a fairly low level, so I'm not sure whether it's best to requests widgets or attempt to build them.

from chrysalisp.

There is already (insert) (erase) (join) for sequences defined in the class/lisp/boot.inc file ;) They will work with strings as well as lists.

from chrysalisp.

(insert) will still work fine even if you do so at the end of the line. I’m assuming your cursor x pos will not float beyond the length of the line here, but either way you can just check that easily. I will try to get you a very basic framework going shortly.

from chrysalisp.

I should have known there was a function for this. Still a whole lot to learn.

from chrysalisp.

Just pushed a very crude Edit app to get you somthing to play with. I’ll do a better VDU refresh method soon for you.

from chrysalisp.

Thank you for the boot.inc tips and for providing a framework for this.

I've not been particularly focused, and I don't have the experience or comprehension to implement a lot of my ideas. Going forward, I'm going to focus more on comprehension and implentation for this specific application.

I'm going to pack up the wallpaper and then I'll start work on a specific aspect of implementation. Scrolling the buffer might be a good starting point, which could also be helpful/applicable to the terminal as well.

from chrysalisp.

This is great, thank you.

from chrysalisp.

@nuclearfall did you see the bug report I added to the end of the pull request ?

It will (erase) out of range when backspace at the very last line and when off the right edge of text.

from chrysalisp.

Yeah, I noticed that last night. I'll put in a patch.

from chrysalisp.

The new pull request modifies directional behavior to fairly standard text editor behavior which happens to resolve the issue with backspace.

from chrysalisp.

Fair enough !

from chrysalisp.

@nuclearfall But you broke the ordinary char insert.... ;)

Insert no seams to be doing an insert before the cursor ....

I've had a wild hack weekend doing a native font rendering system ! So I was using the editor to test my font drawing code and noticed this !

from chrysalisp.

@nuclearfall Implemented a simple textfield !

from chrysalisp.

This is an old account from nuclearfall. I am still working on this. I should've said something, but I had to send in my MacBook. Unfortunately I was stupid enough to believe they had actually fixed th keyboard on the 2018 model. It's been less than two years I've had it.

In any case, I am still working on this. I've been working on some basic scroll capabilities, saving and opening text buffers. I'm trying to implement everything in vdu without window functions for now. That way it can be used from the terminal as well.

from chrysalisp.

As soon as I restore my passwords, I should have a less.inc (or maybe just read.inc) to push for the terminal, which is just a read only version of the command mode in edit.

As far as the editor, I've done some work on that tonight. I've implemented a command mode with basic pgdown, pgup, and rudimentary save functionality (only allows writing to a file in the Guest user directory, not to actual system files. I don't want someone—read, me—to edit edit and break it quite yet. :)

I plan to implement edit as a terminal friendly application, and use the app to add a window with a scrollbar and toolbar—which will allow changing fonts and not having to use a command mode to issue commands like save.

from chrysalisp.

I have just removed much of the functionality of VDU apart from (vdu-load) !

I really believe that the editor should not push things into the VDU class, that is a very simple GUI char grid component, optimised to do that job and that job only.

Trying to make it terminal friendly is probably not the best approach ! I've gone the opposite direction with my thinking on the VDU class, mainly from thinking about your Editor requirement. I've removed all ideas about VT52/VT100 char codes and gone back to a much simpler idea of the VDU class being a char grid UI component that is driven by the application loading a (list str str str) edit buffer into it.

The editor should, I believe, concentrate on a set of edit functions that manipulate a list of text_buf structures. It does not care how that text_buf structure is displayed to the user. One such option is loading a VDU widget from it, there may be others in the future.

So the editor is more a, scriptable (with key bindings to drive it from the Edit app), library of Lisp functions for manipulating a set of text buffers. No thought to terminals or VDU widgets or any other ways to display a text_buf.

Chris

from chrysalisp.

In order to support your less.lisp cmd app, if you need to implement any control codes for clear screen or clear line, then you should change the (vdu-print) function the terminal now defines. All the terminal output gets sent via that function and then loaded into the VDU widget. So feel free to add terminal style command codes to that.

from chrysalisp.

I'm sorry, I think i've scared you without cause. :)

text_bufs being place in structures will be high priority.

The behavior is agnostic of the command mode. It all acts on the current buffer, the x, y and position offsets of the cursor and what you what you want to do.The keystrokes, key chords or mouse you use to implement that functionality is entirely independent. Pg up and down using space and backspace in command mode were just the easiest way for me to illustrate functionality for now.

Selection of text is currently set to engages with an opening square bracket, but the functionality isn't dependent on having a command mode or square bracket. It would be just as easily engaged via mouse event.

from chrysalisp.

@nuclearfall

Merged over your recent changes, but have several issue with Edit.

Whenever you resize or min/max button.

Error: (eval form [env]) symbol_not_bound ! < vdu-resize > File: apps/edit/app.lisp

White for background and black text means you can't see the character under the cursor ! ;)

I've temporally taken the Edit app out of the Guest launcher list, just till you stabilise things and are happy it's in good shape.

Regards

Chris

from chrysalisp.

@nuclearfall @Ohessex

I just noticed on the last set of commits from you that there is some conflict markers in the files that are not resolved ! I didn't see any conflicts at my end on the merge to master, so I suspect they may have arisen when you merged from master back to your fork !

So currently several of the edit folder files are in a conflicted state and you will need to decide what the correct merged result should be.

Regards

Chris

from chrysalisp.

This should be fixed in the latest pull request.

I'll be adding some basic buffer storing and switching next.

from chrysalisp.

@nuclearfall

Quick comment on something you will find useful.

In your latest merge, your close-buffer function renumbers the buffers with an each loop.

You use a variable, i, that you set to 0 and increment inside the each.

Well the loop index is directly available for you without need for use of i at all ! During each! and some! loops the _ symbol is bound to the loop index already. So if you use say ‘ts’ for the lambda you can then do (elem-set text_index ts _) and remove use of i all together.

Btw your source is getting better all the time ! :) seams your getting into it !

You might want to look at turning your save/load buttons etc into an icon toolbar using the Entypo font. Lots of interesting symbols in there that are great for toolbars. I use an online font editor to look through the symbols for my toolbars and the MacOS Unicode key entry keyboard to type them into my editor.

Chris

from chrysalisp.

Another minor point but worth knowing is when using constant values like text_index you can wrap them in a (const xxx) macro. All that macro does is evaluate the form at read time so that during run time your not looking up the symbol, which wastes time for constant values.

It’s certainly worth it for named indexes of tupple elements.

Also worth explaining now that this is similar to what (defun-bind) is doing for function calls. That macro resolves all the function call symbols that this function uses at read time in order to avoid having to lookup the function symbols at runtime. For tight loops these sorts of of pre binding macros can save a lot.

Chris

from chrysalisp.

Couple of observations for you on trying the latest version.

Click close eventually crashes when no buffers remain.

Scroll bar dosnt update correctly as text grows larger than screen, I only ever see a full height scroll bar.

In resize action I see a gap appear to the right of the text field?

Chris

from chrysalisp.

@nuclearfall @Ohessex

I've added a little app 'Entypo' to show the symbols available to use on toolbars etc.

from chrysalisp.