This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
LoganDark2's profile picture

ShEdit - An editor with proper syntax highlighting!

Started by LoganDark2, 18 January 2018 - 06:55 PM
LoganDark2 #1
Posted 18 January 2018 - 07:55 PM


It isn't an IDE, but it's simple, gets the job (uh, most jobs) done, and works well. I actually use this editor more than I use external editors!

It's a modification of the stock edit program, with tons of more features!

Extra features supported by ShEdit:
  • Selection! Click and drag, or use shift+the arrow keys (or Home or End or PageUp or PageDown or whatever cursor movement keys, or even shift+left click)
  • Deleting a selection (press delete or backspace)
  • Replacing a selection (just start typing with a selection)
  • Row/col in the bottom right (order: cursor pos and then mark pos) instead of just the line
  • Actual tabs (and partial support for characters wider than one cell, but for now, just tabs). No, really, the tab key actually inserts tabs. It's amazing. A total breakthrough in my opinion.
  • Converting two spaces/indentation level to one tab/indentation level (and back)
  • Copy and paste!
  • Find text
  • Jump to line
A list of Lua features supported by the syntax highlighter:
  • Comments and multiline comments
  • Keywords
  • Operators (comparison, arithmetic)
  • Numbers (regular, hex, scientific)
  • String (regular, multiline, escapes, numeric escapes, hex escapes)
  • Special values (true, false, nil)
  • And more, all the token types are listed in the post for Lex.
Future features:
  • Faster screen drawing
  • Replace tool
  • Options menu
  • Configurable tab width (in the options menu)
This program requires a library of mine called Lex. The file must be called lex. If it is not found, the program will download it automatically, so there is no reason to install it manually. If it complains about the lexer just delete the file 'lex' and re-run ShEdit. Alternatively, you can download Lex (instructions are in the post) manually.

pastebin get guNvJcZ9 shedit
Edited on 24 January 2018 - 06:03 PM
LoganDark2 #2
Posted 20 January 2018 - 02:44 PM
A new version of ShEdit has been released, supporting the tools menu.

Edit: Somehow, I forgot that the Escape key exited the computer. That might be because I'm using an emulator, and not an in-game computer to test this. So, instead of Escape, left control exits the tools menu.
Edited on 21 January 2018 - 11:41 PM
LoganDark2 #3
Posted 23 January 2018 - 03:04 PM
Yet another new version has been released, supporting:
  • Find text
  • Jump to line
  • Improved the read-only protection on features I added myself, so you can't edit the buffer on a read only file (you can no longer paste to edit a read-only file, and you can no longer use the tools menu in a read-only file)
  • The fact that was even possible in the past is entirely my fault, because I neglected to support read-only files with all the features I've been adding. :P/>
SquidDev #4
Posted 24 January 2018 - 12:55 PM
Just had a play with this, and it's jolly neat. The tab/space conversion feature seems especially useful.

I did have an issue with some editing functions being rather laggy. One possible solution would be to only lex elements of the code which have changed. So if you have local foo = bar and insert a after foo, you only have to lex between the start of fooa until you match up with the previous token list (in this case you'll only have to consume fooa, but when editing multi-line comments you may have to lex for longer).

Some operations (such as selecting) seem to induce a lot of flicker, even with multishell disabled. I haven't had a look at your drawing function, so don't know if it's possible to optimise at all.

One feature which would be especially neat would be auto-indenting if pressing return after a then, else or do token. It might be possible to remove indentation after an end token, but that is more susceptible to breakage, say, if an if statement is on one line.
LoganDark2 #5
Posted 24 January 2018 - 06:02 PM
Just had a play with this, and it's jolly neat. The tab/space conversion feature seems especially useful.

Thanks!

I did have an issue with some editing functions being rather laggy. One possible solution would be to only lex elements of the code which have changed. So if you have local foo = bar and insert a after foo, you only have to lex between the start of fooa until you match up with the previous token list (in this case you'll only have to consume fooa, but when editing multi-line comments you may have to lex for longer).

'only lex elements of the code which have changed.' is more complicated than one might think. There's so many edge cases, and so many things that would require re-lexing the code anyway.

Some operations (such as selecting) seem to induce a lot of flicker, even with multishell disabled. I haven't had a look at your drawing function, so don't know if it's possible to optimise at all.

Oh yes. That is an issue with the honestly horrible highlighting method I am using (go over every character of every token, check if it is marked with a little function that runs for every single character onscreen, if it is marked, highlight it, else, don't).

I should have onUpdate generate a list of term.blits for me. Then draw will just term.blit it to the screen. Honestly, that's even better than iterating over every token anyway! While I'm at it, I might even make it only draw what's visible on screen (because the normal edit program just sets the cursor pos to a negative value based on scroll for drawing)

I had that issue once with my lexer. It took over 10 seconds to parse code once because I had a horrible function that looped over 8000 times for every token. That function was intended to get the row/col of the token. Now, I just return a counter value, which increments after every token with the length of that token. It's much faster.

One feature which would be especially neat would be auto-indenting if pressing return after a then, else or do token. It might be possible to remove indentation after an end token, but that is more susceptible to breakage, say, if an if statement is on one line.

Yeah, I might do that at some point. The way the tokens are formatted though might make that a little expensive. I'll look into it.
LDDestroier #6
Posted 24 January 2018 - 06:30 PM
Well butter my bollocks, this is actually a very good editor. Although it seems to be a modification of the existing rom/programs/edit, the functionality is boosted a lot. Nice.

Suggestions:
  • add a "replace all instances of X with Y" tool.
  • change tool "change 2 spaces into tab" and vice versa tool to allow an inputted amount of spaces to be converted instead of just 2 (pressing TAB is the equivalent of four spaces in the editor)
  • Color "true" green and "false" red. I think it'd look nice.
LoganDark2 #7
Posted 24 January 2018 - 06:58 PM
Well butter my bollocks, this is actually a very good editor.

Thanks! :P/>

Although it seems to be a modification of the existing rom/programs/edit, the functionality is boosted a lot. Nice.

Oh crap, I thought I specified that it was a modification in the post. Will edit.

Suggestions:
  • add a "replace all instances of X with Y" tool.

What would that be used for? Just curious. I'll consider adding it.

  • change tool "change 2 spaces into tab" and vice versa tool to allow an inputted amount of spaces to be converted instead of just 2 (pressing TAB is the equivalent of four spaces in the editor)

Maybe even a configurable tab width?

  • Color "true" green and "false" red. I think it'd look nice.

I think that feature would be better suited as an option in a settings menu. :P/>
Bomb Bloke #8
Posted 25 January 2018 - 12:57 AM
The "easy" way to kill flicker is to set your window to invisible before you start rendering to it, then reveal the thing when you've completed the "frame". On launch, check to see if your current terminal is a window or not (it will be if you're using multishell), and redirect to one if need be.
LoganDark2 #9
Posted 25 January 2018 - 04:07 PM
The "easy" way to kill flicker is to set your window to invisible before you start rendering to it, then reveal the thing when you've completed the "frame". On launch, check to see if your current terminal is a window or not (it will be if you're using multishell), and redirect to one if need be.

Drawing is still slow, which slows down everything else since the rest of the event loop needs to wait for it. I'll try to make it faster.

An update has been pushed to the pastebin that makes rendering faster. There's no flickering on the emulator anymore, I can't speak for in-game machines though.

Edit: Okay, nevermind the new version on Pastebin - it seems to work but not quite. I'll try to make it faster. :P/>
Edited on 10 March 2018 - 05:58 PM
Snablesnot #10
Posted 17 May 2019 - 01:02 AM
I really like this a lot.

However a couple downfalls for me is that the menu does not fit in turtle screen but that is minor because they all can still be accessed. Also while editing programs and attempting to use copy without a selection it crashes.
Edited on 19 May 2019 - 12:15 AM
LoganDark2 #11
Posted 12 November 2019 - 01:05 PM
Fixed a bug where the autocomplete would go off screen if you scrolled.