edit+ - enhanced editor (non-qwerty-ready)

Minor v1.1.1: by popular request, a basic auto-indent system has been added to the release build.
Latest: v1.1 Adds advanced menu options, configurable menu hiding, keyboard/cursor-based block selection, and more; removes numerous bugs from 1.0

I've been frustrated with the offerings for enhanced in-game editors in CC for a long time. There have been many that look great, but none of them have been exactly the editor I want, so I've set out to create my own ideal editor!


first off, pictures: (pics are of current v1.1, menus are different in v1.2)


Features:

• all the features you've come to expect from the built-in editor, with two minor exceptions.¹
• easy and intuitive basic menus, with a toggleable efficient advanced alternative
• run program from the editor; if it errors, it takes you to the line number where the error was generated.
• basic or advanced computer support
• Complex block selection, with keyboard controls on any computer, or by simply dragging the mouse on advanced computers.
• increase/decrease selected block indentation
• "–update" shell argument to update to the latest version automatically
• special handling to prevent menus from interfering with typing alt-gr characters on non-english keyboards, unlike built-in edit
• works on tablets
• somewhat intelligent auto-indent features - "enter" after beginning a for, while, or repeat loop, or after an else or elseif clause, will be indented one step; lines with end, elseif, or until will be de-indented, if they have not already been.

Current beta version differences:

Spoiler

• gui-based file picker, for new saveAs and Load operations.

• Because of the addition of new APIs, if you have a version before v1.1, you will have to run "edit+ –update beta" twice for it to download the new file (the old version doesn't know about it). v1.1 (current release) and all later versions should no longer have this issue.

Current advanced menu shortcuts:

Spoiler

q - exit (x is cut)
s - save
r - run program
c - copy
x - cut
v - paste
b - begin/end block selection
tab/< - decrease indent (line or block)
> - increase indent (line or block)
h - toggle menu hiding
m - toggle menu mode (so, back to basic menus)
? - not implemented properly, will pop up this list in-game

Also, it defaults to basic menus and no menu hiding on first launch, but it remembers your settings if you change them, so you won't have to keep changing them to whatever mode you prefer.

More features are planned, just wanted to get this first stable release out there.
Planned features:

Spoiler

next version

• load, new, and save as menu commands, with simple visual file/path picker
• recent files list, for quick and easy switching between a group of files
• multi-file editing - have multiple files open at once, copy and paste code between them, etc
• revert command, reverts to last version
• undo/redo commands
• use a scratch file to provide crash/reboot-protection, for extra server-friendliness - no losing code if the server reboots and you hadn't saved, or if you find an "undocumented feature" that crashes the editor.

future versions

• context menus - right-click to bring up a context menu, with cut/copy/paste conveniently there. Also accessible with right-ctrl to open at cursor on any computer.Smart indenting (req by GeForce Fan)
• toggleable line numbers on left side (I don't know why people like this, but apparently they do, and alekso already asked for it)
• automatic indenting
• a variety of syntax highlighting configs, and the ability to customize them to your personal tastes.
• highlighting of standard lua and CC functions/apis
• Find, Find and Replace, with optional lua pattern support
• jump to named function definitions, line numbers

Installing:
Just type the following into any computer with http enabled:

pastebin run sR9t4iRZ

And it should download the last stable release from github!
To install the current beta release (which may have bugs, but also moar features!), just add "beta", like so…

pastebin run sR9t4iRZ beta

If you find any issues, however minor, please report them in the thread and I'll fix them ASAP, and tell me if they were in the stable or beta version. Suggestions for additional features are encouraged as well, though I make no promise to implement them unless I like them!

Oh, and I'm also open to suggestions for a better name than "edit+", not least because I'm fairly sure best practices discourage the "+" sign in file names.

Thanks already go to those who've reported bugs:
alekso56, Lyqyd, HPWebcamAble, nitrogenfingers, Kaikaku, Timia2109, wieselkatze

¹ there's not yet any auto-indenting functionality; this is planned for a future version. Also, there's no print feature. I have no plans to implement one, either, but if a lot of people really want it, I may change relent.

Looks pretty cool

A slightly better version of LuaIDE I suppose

A few things:
Tab doesn't work!
I know it just inserts 2 spaces, but I use it a TON

And it crashed when trying to cut text
(edit+:186: attempt to index nil)

You need a GoTo line and a Find function

Other than that its awesome

Side note how do you change the cursor color

I share your sentiments with editors and it's cool to see one with some new features. The multi-line comments do look good :)/>

Per your request I have bugs to report:
- Attempting to select text dragging down works very well but when I try to select going left or up from my cursor either nothing happens or it reprints the string from the point of the cursor.
- edit+ only works from the root, which may be by design but it'd be nice if it could be kept in a folder
- I'm not quite certain how pasting works. When I copy a multiline with different start and end points, it will paste whole lines, but sometimes miss one or two.
- After pasting when I select again parts of the document change, again not sure what's happening here.

This is really fantastic though, it's natural enough that I find myself shift-clicking and trying to use ctrl-cursor before realizing I can't in CC. It would be good to have some more features like advanced moving/copying/pasting of code, particularly between files and maybe stuff like regex or doc navigation (where is our CC vim?) Will follow for updates. Cheers!

HPWebcamAble, on 05 March 2015 - 01:51 AM said:

A few things:
Tab doesn't work!
I know it just inserts 2 spaces, but I use it a TON

:facepalm: total oversight, I almost never hit tab myself XD will fix shortly.

HPWebcamAble, on 05 March 2015 - 01:51 AM said:

And it crashed when trying to cut text
(edit+:186: attempt to index nil)

O_o can you give me more details of what you were doing? I've tested copy and cut as many ways as I can think of, and not gotten a crash on line 186. I'll look at that line and see what path from cut could lead to an error there in the mean time. managed to reproduce. Thank you for reporting!

HPWebcamAble, on 05 March 2015 - 01:51 AM said:

You need a GoTo line and a Find function

Agreed on both counts. Find and Replace, too. Gimme a few versions. :)/>

HPWebcamAble, on 05 March 2015 - 01:51 AM said:

Side note how do you change the cursor color

it's the color of whatever your last call to term.setTextColor was. I need to fix it in this, actually, and make it always white, right now it's.. kindof unpredictable what color it will be


@nitrogenfingers

nitrogenfingers, on 05 March 2015 - 01:53 AM said:

I share your sentiments with editors and it's cool to see one with some new features. The multi-line comments do look good :)/>

thanks. :D/>

nitrogenfingers, on 05 March 2015 - 01:53 AM said:

Per your request I have bugs to report:
- Attempting to select text dragging down works very well but when I try to select going left or up from my cursor either nothing happens or it reprints the string from the point of the cursor.

Took me a minute and some comments from Lyqyd on irc to reproduce the drag-selection backwards not drawing properly thing, but it also just straight-up doesn't act on selections made this way correctly even when they draw correctly. Will be addressing this asap.

nitrogenfingers, on 05 March 2015 - 01:53 AM said:

- edit+ only works from the root, which may be by design but it'd be nice if it could be kept in a folder

not.. sure what you mean, but will try running it from another folder and perhaps it will become clear. Can't imagine what I've done that would only work from root, though…

nitrogenfingers, on 05 March 2015 - 01:53 AM said:

- I'm not quite certain how pasting works. When I copy a multiline with different start and end points, it will paste whole lines, but sometimes miss one or two.
- After pasting when I select again parts of the document change, again not sure what's happening here.

hrm. I suspect these are related, and possibly related to the first issue as well. Will stress-test the copy/paste code, it had seemed to be working but, I realise now, I'd tested it mainly on one file (hilight) and almost entirely on the first page of the file. Clearly there's more work there. When it's working as intended, pasting should work exactly like you would expect, the complete copied/cut text, however many lines, inserted at the cursor position, splitting the current line in the process.

nitrogenfingers, on 05 March 2015 - 01:53 AM said:

This is really fantastic though, it's natural enough that I find myself shift-clicking and trying to use ctrl-cursor before realizing I can't in CC. It would be good to have some more features like advanced moving/copying/pasting of code, particularly between files and maybe stuff like regex or doc navigation (where is our CC vim?) Will follow for updates. Cheers!

I really wish I could cleanly implement ctrl+left and ctrl+right to move the cursor a token at a time… also, shift+arrows to block select… I might play with timer-based approaches to these at some point, but unless I can make it feel completely natural and free from jarring quirks, I won't be including them. Having them just plain not work is actually better than having them sortof-work and then suddenly not work because you paused a bit too long still holding shift before hitting an arrow again, y'know?

having multiple open files is something I'm considering, but I'm thinking for the immediate future I'll settle for a Load File command, along with a recent files list so you can switch between a few active-not-open files quickly and conveniently. When that's implemented, naturally the clipboard will not reset when you switch files. Not sure what you mean with "advanced" moving/copying/pasting, possibly because I've stuck with textpad instead of some of these fancy latest-gen code editors that have all sorts of magic installed under the hood, but regexp (well, lua patterns, actually) for find and also for replace are something I definitely have in mind for the future!

anyway, enough responding, going to go work on the issues you guys have reported. Thanks to all!

okie, new post for update. I think all reported issues have been fixed, just pushed a version that has the following fixes/additions

• multiple issues with copy/paste and block selection fixed, seems to work now in all the cases I could think to try
• tab key support added
• fixed issue with finding api when installed outside of root
• cursor should stay white now instead of changing colors in unpredictable ways

:edit: a feature addition… small but awesome

• tab and ctrl,tab can be used to increase or decrease the indentation level of a selected block of code.

Oh, this looks really useful and I like the copy and paste! :)/>

One wish for for users of a qwertz keyboard: The ~ is only availably for me by pressing Alt-Gr, this means I cannot get it in the in game editor :(/>
I would give you all my ÖÖÜÜÄÄß in exchange for a ~

Kaikaku, on 05 March 2015 - 09:15 PM said:

Oh, this looks really useful and I like the copy and paste! :)/>

One wish for for users of a qwertz keyboard: The ~ is only availably for me by pressing Alt-Gr, this means I cannot get it in the in game editor :(/>
I would give you all my ÖÖÜÜÄÄß in exchange for a ~

Yeah that would be cool if you edit it. Maybe move CTRL to an other button. Also { and } needs AltGr (CTRL+ALT).

Thank you!

New name : Edit++? :P/>
Not only a reference to NP++, but also to C++

You can likely type those characters the same way you do in the built-in edit program–by opening the menu first and then typing the key combination to produce the character you want.

A pretty neat editor, I can see myself using it! I can foresee a lot of naming suggestions for edit++, but I think that's a bit unoriginal and, like you said, you want to avoid +'s in the filename. How about something like xEdit, or edit with another prefix that stands for a synonym of 'enhanced'?

Ninja'd by Lyqyd on the work-around; I'll have to see if I can find something to emulate a non-qwerty keyboard, or see if I can find someone on irc later to help me test. Given that the whole pre-tap ctrl to open menu thing works, I assume the char events do normally come, so I might be able to to special-case those so they can pass through; a config option to change the menu key might be an option as well, assuming there even is a key on these fancy foreign keyboards that isn't used in a combination to type some common character…. don't have time to fiddle with it at the moment, only passing by my computer and wanted to go ahead and acknowledge.

Oh, and I have it on good authority that apparently key_up events are gonna be a thing in the next version of CC. That means it should finally be possible to consistently and properly detect and handle shift+key, ctrl+key, alt+key, and all other permutations thereof, whenever the next version comes out. So there's that to look forward to!

The next version will have some accommodation of this issue, if not tonight then some time tomorrow (GMT-5). Along with completely overhauled menus, which I've started on, that will have two modes, "basic" and "advanced", basic being more conventional grouped popup menus, advanced being more vim-like - not in the sense of using actual vim key mappings, but in the sense of not really having menus at all, so much as expecting you to just know all the shortcuts. Though I plan on making the shortcuts configurable later, so settings compatible with your favorite editor of choice aren't out of the question, though it won't happen in this next version.

@lemonlake xEdit is a fine suggestion, except that there's already an xEdit, a few threads down on the first page, that someone made last fall. I'm vaguely leaning towards "codex," despite the similarity to the very dissimilar xcode.

For the name for about Tide - edit Backwards.

wojbie, on 05 March 2015 - 10:49 PM said:

For the name for about Tide - edit Backwards.

Hmm. tide. I like that; it's going on the short list. :D/>

Just tried it, and I gotta say that I like this a lot! You've really done a good job on this one! :D/>
I've got some suggestions for you if you are interested

• Auto-saving - This would be changable in settings, it would be useful for servers that suddenly restarts
• Settings - This would be needed for the suggestion above, it's pretty self-explainatory :P/>
• Backup - If the program would crash for some unexpected reason, the program would save the work you've done, and create a backup of it.

TheOddByte, on 06 March 2015 - 06:19 PM said:

Just tried it, and I gotta say that I like this a lot! You've really done a good job on this one! :D/>
I've got some suggestions for you if you are interested

• Auto-saving - This would be changable in settings, it would be useful for servers that suddenly restarts
• Settings - This would be needed for the suggestion above, it's pretty self-explainatory :P/>
• Backup - If the program would crash for some unexpected reason, the program would save the work you've done, and create a backup of it.

Thanks, glad you're liking it. It's only gonna get better from here, especially whenever this version of CC that dan200 has just added key_up and mouse_up events to is released… :drool:

I'm thinking of keeping a temp scratch file updated between manual saves, so that it can recover the files if it crashes or reboots - which seems immensely preferable to me to a naive autosave implementation, since those can cause you to accidentally save stuff you don't want to safe. That should cover your desires for both autosaving and backup, I expect.

Settings, in the dev build I've alrady got them saving and loading (they are saved in /etc if such a dir exists, otherwise, in whatever dir the program is in). I didn't intend to make a config option specifically for the saving, since it's supposed to be pretty unobtrusive the way I plan on implementing it, but it wouldn't be too difficult to add one if there's still demand.

The first practical setting options will be related to the menu - next release will, by default, be showing a menu bar at the bottom, click to expand submenus for file, edit, etc. Will have options under view to switch to advanced mode (no actual menus, just shortcuts) and to enable hiding the menu when not open (so you'll have to hit ctrl to open, as now).

GopherAtl, on 06 March 2015 - 06:38 PM said:

…

Well that's a good solution, keeping the files as a temp file sounds like a good solution, but as you said it would be a problem if there was something you didn't want to save. And glad to hear settings are coming.

Now about the key_up and mouse_up events.. Where did you hear that? I just can't wait for them, it's going to be so awesome! :D/>

Edit: Just looked in general and found your source :P/>

TheOddByte, on 06 March 2015 - 06:46 PM said:

GopherAtl, on 06 March 2015 - 06:38 PM said:

…

Well that's a good solution, keeping the files as a temp file sounds like a good solution, but as you said it would be a problem if there was something you didn't want to save. And glad to hear settings are coming.

Now about the key_up and mouse_up events.. Where did you hear that? I just can't wait for them, it's going to be so awesome! :D/>

Dan200 replied in the mouse_drop suggestion thread yesterday that he was implementing it right then; he later tweeted he was adding mouse_up and key_up events. So, for non-qwerty keyboard users, menus shouldn't interfere with your typing once I've got my hands on those events and updated accordingly, and for everyone, things like shift-tab to de-indent blocks, shift-arrows to select text, etc. will all be possible. Which will let me take edit+ from "a fine option for editing on a server" to "a viable alternative to an external editor full stop"

Oh, those key_up eventy definitely sound nifty. Yeah, that xEdit thingy was actually mine :D/>
I gotta say - I have the feeling that since I brought up that idea with multiline editing and marking text many others do also like to implement that in their editors. May just be a feeling, hehe.

I'd have to implement multiline syntax highlighting in my editor as well - I haven't it implemented, because I thought checking all the comments when pasting multiline would take up a fair bit of computing time - e.g. in a 1300 line file. Probably nonsense, but I'd like to keep my programs as efficient as possible. I might already have got an idea on how to improve the rendering with my new GUI API…
Also I gotta clean that code up a bit - that advanced event thing is definitely pushing my motivation on improving the overall user interaction with the program.

GopherAtl, on 06 March 2015 - 06:49 PM said:

…

Ahh, thought you looked on twitter first, well I won't go any more offtopic now. I'm just going to sit here and wait for another update.

wieselkatze, on 06 March 2015 - 06:52 PM said:

I'd have to implement multiline syntax highlighting in my editor as well - I haven't it implemented, because I thought checking all the comments when pasting multiline would take up a fair bit of computing time - e.g. in a 1300 line file. Probably nonsense, but I'd like to keep my programs as efficient as possible.

I was prepared for it to be an issue as well, and had plans in place to propagate the syntax changes incrementally, but first I just had it update the whole file and it really doesn't seem to be an issue. I can always go back and add the incremental solution later if it proves necessary, but I've sat with a 1000+ line file with no existing block comments and just put "–[=[" on the first line, commenting the whole file, then deleting the [, uncommenting everything, and back and forth, [, backspace, [, backspace, and it doesn't seem to have any noticeable impact in the current, naive implementation. Your syntax hilighting code may be a different story, I couldn't say, haven't compared them.

I basically used the syntax highlighting of the standard editor and modified it to work with strings as "\\" and "\\\"" and so on. Also i needed to change the rendering for it to work with my highlighting for the selected area.
As I implemented dynamic color changing with &amp;0-f and $0-f in my new GUI API I could probably relatively easily implement all those things in a new rendering function.
Then the highlighting would just work with e.g. "if a == &amp;" .. getHex( stringColor ) .. "\"hey, this is a string\"&amp;" .. getHex( textColor ) .. " then" … You get the point.

Side note: In line 104 you use "^(0x[%da-fA-F]*)(%s*)(.-)" to get hex codes. Couldn't you just shorten [%da-fA-F] to %x? %x is for hex values and already works both with uppercase and lowercase letters.

wieselkatze, on 06 March 2015 - 07:09 PM said:

I basically used the syntax highlighting of the standard editor and modified it to work with strings as "\\" and "\\\"" and so on. Also i needed to change the rendering for it to work with my highlighting for the selected area.
As I implemented dynamic color changing with &amp;0-f and $0-f in my new GUI API I could probably relatively easily implement all those things in a new rendering function.
Then the highlighting would just work with e.g. "if a == &amp;" .. getHex( stringColor ) .. "\"hey, this is a string\"&amp;" .. getHex( textColor ) .. " then" … You get the point.

Side note: In line 104 you use "^(0x[%da-fA-F]*)(%s*)(.-)" to get hex codes. Couldn't you just shorten [%da-fA-F] to %x? %x is for hex values and already works both with uppercase and lowercase letters.

oh, glad you said that, just realized I handle \" but not \\" in my strings… I will have to fix that.

As for the hex string, yeah, yer right, and it'd probably be more efficient as well, I just forgot about the %x group. Will have to change that, too!

:edit: Oh, somehow I hadn't noticed until playing with it just now that xedit actually does have dragging to block select. Very nice! But… no pgup/pgdn? And scrolling down only works with the mouse, cursor past bottom doesn't trigger a redraw at all.

This is great, but the lack of auto-indenting makes this useless.

Geforce Fan, on 06 March 2015 - 09:51 PM said:

This is great, but the lack of auto-indenting makes this useless.

I'd say the lack of constructive criticism will not lead to the creator noticing this more than other posts.

GopherAtl, on 06 March 2015 - 07:37 PM said:

- snip -

:edit: Oh, somehow I hadn't noticed until playing with it just now that xedit actually does have dragging to block select. Very nice! But… no pgup/pgdn? And scrolling down only works with the mouse, cursor past bottom doesn't trigger a redraw at all.

Yeah, I probably forgot to implement PgUp/PgDown - that's relatively easy to do.
No redraw? Wow that's a shame - I must have implemented that bug in a later version when I fiddled around with redrawing only certain parts of the screen.
Funny that noone had noticed it yet. Apparently nobody really uses that editor ^^.
I'll fix that right now.

#EDIT:
Wow. It was missing brackets. Fixed now, thanks for that report

Geforce Fan, on 06 March 2015 - 09:51 PM said:

This is great, but the lack of auto-indenting makes this useless.

It's on my to-do list, but I'm debating how best to implement it. It's one of those features that, for me at least, seems easy to screw up in little ways and make it as likely to annoy as help.

wieselkatze, on 06 March 2015 - 10:01 PM said:

Yeah, I probably forgot to implement PgUp/PgDown - that's relatively easy to do.
No redraw? Wow that's a shame - I must have implemented that bug in a later version when I fiddled around with redrawing only certain parts of the screen.
Funny that noone had noticed it yet. Apparently nobody really uses that editor ^^.
I'll fix that right now.

#EDIT:
Wow. It was missing brackets. Fixed now, thanks for that report

Yeah, sorry I didn't report it myself, but yours was one of half a dozen editors I downloaded and tried all in one go shortly before I started this project, to see if there was an existing solution that I was satisfied with enough to not bother with my own. At the time your thread hadn't been bumped since October, and combined with immediately running into the two issues I just told you about, I just moved along to testing the next editor and didn't bump the old thread to report the issues. Had I reported all the issues I found in all the editors, we would've had nothing but editors on page 1 of programs this week, some much older threads than yours XD

Getting people to actually try out your programs and report issues can be very difficult; I would've let a couple of issues just as face-palming as your down-scrolling issue slip by me if I hadn't gotten someone in the irc channel (alekso56) to test it for me before I posted it; if yuo don't have a robust regression testing process and stick to it tightly, it's astonishingly easy to overlook even the most glaring of bugs!

I just downloaded your editor - probably the thing I disliked most was scrolling with the mouse wheel - I prefer the screen scrolling directly when using the wheel, but in this case it first moves the cursor up or down and then scrolls. Definitely a thing of preference, but I think scrolling directly is more handy, as when you are using the mouse to set the cursor ( with the scroll wheel ), you could just as well click on the position you want the cursor to be.

One thing I noticed, but considered as a bug, was that when you're marking text with mouse_drag and while still clicking scroll down or up, the area being marked is fixed with the screen itself.
So the maximum area you can actually mark is 19 lines ( term size ).

wieselkatze, on 06 March 2015 - 10:45 PM said:

I just downloaded your editor - probably the thing I disliked most was scrolling with the mouse wheel - I prefer the screen scrolling directly when using the wheel, but in this case it first moves the cursor up or down and then scrolls. Definitely a thing of preference, but I think scrolling directly is more handy, as when you are using the mouse to set the cursor ( with the scroll wheel ), you could just as well click on the position you want the cursor to be.

Haha, this was the first thing Lyqyd complained about, too. I plan on fixing it, but for the moment it seemed the natural way to avoid having to allow for the cursor leaving the screen, as it normally can when you scroll with a mouse in a typical editor, whether with the wheel or middle-click-dragging or using the scroll bar or whatever. I actually agree with both of you that it's not good behavior currently, it's just a low priority in my mind because I'm not much on taking my hands off the keyboard when coding, and using the mouse wheel to scroll just isn't something do normally in any sort of text editor. It'll be fixed at some point in the next few updates, as I plan on redoing the way the goto error function works as well, which may sound completely unrelated but it's actually connected, oddly enough.

wieselkatze, on 06 March 2015 - 10:45 PM said:

One thing I noticed, but considered as a bug, was that when you're marking text with mouse_drag and while still clicking scroll down or up, the area being marked is fixed with the screen itself.
So the maximum area you can actually mark is 19 lines ( term size ).

Having just tried it, I must say, using the mouse wheel while holding down left click to drag is not something I think I've ever done before. Felt downright unnatural to go for the mousewheel with my middle instead of index finger. Having said that, it's actually not a bad idea to allow, particularly while waiting for the mouse_up event so I implement nice edge-scrolling while drag-selecting, so I may well tweak the mouse wheel to support it.

Honestly, though, in general, even using the mouse to block-select isn't something I do while coding; holding shift, while doing a combination of arrow keys, home, end, and page up/down are my go-to, and the best approximation I can do of these is a higher priority for me in edit+ than anything involving the mouse. The mouse vs keyboard stuff will always be a personal style/preference thing, though, you're right! My goal isn't necessarily to make the Best Possible Editor in some absolute sense, just the editor I want. Some will love it. Some will not. Can't please everybody, if you could, somebody would have a monopoly on every kind of program on the market!

GopherAtl, on 06 March 2015 - 10:56 PM said:

Having just tried it, I must say, using the mouse wheel while holding down left click to drag is not something I think I've ever done before. Felt downright unnatural to go for the mousewheel with my middle instead of index finger. Having said that, it's actually not a bad idea to allow, particularly while waiting for the mouse_up event so I implement nice edge-scrolling while drag-selecting, so I may well tweak the mouse wheel to support it.

Yeah, I implemented that in xEdit, too. The problem with that is: You can't tell if the user is still pressing the mouse button to scroll.
Currently I'm just waiting for the user to exit the very upper or lower part of the screen to stop scrolling, but when he leaves the mouse in the lower or upper part and releases the mouse button, it just continues scrolling. Unfortunately no solution for that. Yet.

Regarding using dragging + mouse scrolling: Yes, scrolling by positioning the mouse at the top or bottom is indeed more natural, but the mouse wheel just works better for me - espeacially in regards of precision; actually hitting the line I wanted to select. For fast down scrolling when you know you have a long function to select that is indeed the way to go.

wieselkatze, on 06 March 2015 - 11:03 PM said:

Yeah, I implemented that in xEdit, too. The problem with that is: You can't tell if the user is still pressing the mouse button to scroll.
Currently I'm just waiting for the user to exit the very upper or lower part of the screen to stop scrolling, but when he leaves the mouse in the lower or upper part and releases the mouse button, it just continues scrolling. Unfortunately no solution for that. Yet.

yeah, you won't suddenly get a new drag event just because the screen moved under the cursor, so not ideal. But at least it's /a/ way around the selecting-more-than-one-screen limitation.

wieselkatze, on 06 March 2015 - 11:03 PM said:

Regarding using dragging + mouse scrolling: Yes, scrolling by positioning the mouse at the top or bottom is indeed more natural, but the mouse wheel just works better for me - espeacially in regards of precision; actually hitting the line I wanted to select. For fast down scrolling when you know you have a long function to select that is indeed the way to go.

See, this is just a style thing, for me I have to have a pretty good reason to take my right hand off the keyboard and reach for the mouse; navigating with keys just feels more efficient, to me.

Lyqyd, on 05 March 2015 - 10:22 PM said:

You can likely type those characters the same way you do in the built-in edit program–by opening the menu first and then typing the key combination to produce the character you want.

Well, I have the same problem with the built-in edit. The key combination (e.g. Alt+126 for ~) works for me for example in notpad++ but not in edit / edit+. Don't know, either some weird qwertz issue or maybe the problem sits in front of the computer…

Kaikaku, on 06 March 2015 - 11:28 PM said:

Lyqyd, on 05 March 2015 - 10:22 PM said:

You can likely type those characters the same way you do in the built-in edit program–by opening the menu first and then typing the key combination to produce the character you want.

Well, I have the same problem with the built-in edit. The key combination (e.g. Alt+126 for ~) works for me for example in notpad++ but not in edit / edit+. Don't know, either some weird qwertz issue or maybe the problem sits in front of the computer…

actually… y'know what…

Anyone using a non-qwerty keyboard, please grab this program from pastebin and run it. It will give you instructions, record some data, and then give you a pastebin code. Come back and post those pastebin codes here. This will give me some hard data on these problematic keys, so I can know exactly what's going on. Some, I know, are just Ctrl + <some key>, and those, you can work around the built-in edit's menu (and mine, which is the same) by opening the menu with a tap of ctrl, /then/ typing the key - including pressing ctrl a second time, which closes the menu. The same trick you can use to ctrl+v and paste from the OS clipboard in edit. But Some people are talking about are new to me, and the output files will hopefully tell me exactly what's happening and if/how I can facilitate this for people.

the test program:

pastebin run Q53kbyu0

GopherAtl, on 06 March 2015 - 11:53 PM said:

actually… y'know what…

Anyone using a non-qwerty keyboard, please grab this program from pastebin and run it. It will give you instructions, record some data, and then give you a pastebin code. Come back and post those pastebin codes here. This will give me some hard data on these problematic keys, so I can know exactly what's going on. Some, I know, are just Ctrl + <some key>, and those, you can work around the built-in edit's menu (and mine, which is the same) by opening the menu with a tap of ctrl, /then/ typing the key - including pressing ctrl a second time, which closes the menu. The same trick you can use to ctrl+v and paste from the OS clipboard in edit. But Some people are talking about are new to me, and the output files will hopefully tell me exactly what's happening and if/how I can facilitate this for people.

the test program:

pastebin run Q53kbyu0

Here my two pastbin codes: First run:5HKn6uzb, second run:cUWHVziQ

I reapeted it to check why there so many key:29 key:184
Think the first time I pressed and released AltGr and then pressed and hold it for typing the second char.
Seems to me that my AltGr sends two key strokes.

Many thanks for investigating this :)/>

Kaikaku, on 07 March 2015 - 07:53 AM said:

Here my two pastbin codes: First run:5HKn6uzb, second run:cUWHVziQ

I reapeted it to check why there so many key:29 key:184
Think the first time I pressed and released AltGr and then pressed and hold it for typing the second char.
Seems to me that my AltGr sends two key strokes.

Many thanks for investigating this :)/>

Okie, got something of a work-around implemented into a minor hotfix.

Didn't get to work as much as I hoped yesterday, too many RL obligations, so I've tucked the dev build for the moment to go ahead and get a patch out.

Changes in this minor update:

• right-alt (alt-gr) now closes the menu the same way ctrl does; for non-qwerty users, this should (?) let any keys typed with ctrl-altgr-<key> pass through instead of being captured by the editor.
• typing past the end of a line actually scrolls the view right - can' believe nobody had reported this, I just noticed it last night XD
• external paste events are handled - note the difference, ctrl+v external pastes as always, the in-game clipboard is ctrl,v.
• :edit: forgot one, [[]] multi-line strings weren't hilighting correctly if the [[ followed another operator character, ex, "print([[foo]])". This has been fixed, too.

The menu overhaul is coming along, and really ought to be ready to push out later today, but at this point I'm reluctant to make any promises, as distractions abound on all sides.

GopherAtl, on 07 March 2015 - 12:35 PM said:

Okie, got something of a work-around implemented into a minor hotfix.

Didn't get to work as much as I hoped yesterday, too many RL obligations, so I've tucked the dev build for the moment to go ahead and get a patch out.

Changes in this minor update:

• right-alt (alt-gr) now closes the menu the same way ctrl does; for non-qwerty users, this should (?) let any keys typed with ctrl-altgr-<key> pass through instead of being captured by the editor.
• typing past the end of a line actually scrolls the view right - can' believe nobody had reported this, I just noticed it last night XD
• external paste events are handled - note the difference, ctrl+v external pastes as always, the in-game clipboard is ctrl,v.

The menu overhaul is coming along, and really ought to be ready to push out later today, but at this point I'm reluctant to make any promises, as distractions abound on all sides.

Yay, it works! The qwertz users have now {[~]} available ingame :D/>
First right-alt(AltGr) opens the menu, then press and hold AltGr + the respective key.

ok, big update. I haven't got everything I want for the next release finished yet - notably, the help screen is still missing - but it's ready for people to at least start testing, and is in many respects much improved. But I'm pushing it to github in the dev branch, and I updated the installer to support a "beta" argument, which will download the version from /dev rather than the release from /master.

To try it out, just do

pastebin run sR9t4iRZ beta

New features in the beta:

• basic and advanced menu modes, with toggleable hiding of menus when not in use; basic have conventional expanding menu groups (file, edit, etc), while advanced just gives a prompt for a shortcut key (see list below, in-editor help not implemented yet)
• block selection using keyboard on any computer - edit->block select to toggle block selection (or ctrl,b in advanced menu mode), then use arrows, pgup/dn, and home/end to expand/shrink the selection.
• block indent shifting
• special-cased handling to prevent menus from interfering with typing certain characters (like ~) on non-qwerty keyboards
• improved mouse wheel behavior
• misc. bugs found and fixed - backspace working properly when scrolled right and newlines to long lines;
• built-in –update argument, to allow updating without going back to the installer
• your settings - currently, the menu modes - are saved and remembered between sessions.
• Menus now fit on a tablet screen! mostly. Some conflict with basic menus and line numbers at present.

Basic menus should be pretty self-explanatory, but without the help screen, I'll list out the current advanced menu shortcuts here

Spoiler

just hit ctrl to open the menu (in advanced mode, you'll just see a > followed by a list of characters, which are the shortcuts) and then type one of the following:

q - exit (x is cut)
s - save
r - run program
c - copy
x - cut
v - paste
b - begin/end block selection
tab/< - decrease indent (line or block)
> - increase indent (line or block)
h - toggle menu hiding
m - toggle menu mode (so, back to basic menus)
? - not implemented properly, will pop up this list in-game

:edit: Oh, two non-obvious things with the basic menus… you can still do just "ctrl, tab" to decrease the indentation the current line or a selected block, in addition to going to edit->decrease indent, and you can do just "ctrl, b" to toggle the keyboard block selection mode,

So I've spent this evening beta-testing edit+ by trying to make a full application in it. I ended up with a columns-inspired tetris clone coming in at about 200 lines. Alongside helping with the testing, the program took me about 3 1/2 hours to write, came across a few bugs that made it a bit hard to work through but there's something oddly satisfying about using an editor that's improving as you use it :P/>

You can check out the code here to see what it looks like: http://pastebin.com/9eXDFgAR (or even play it!)

I've put in a stack of bug reports, of which most if not all were resolved before I was finished so while there's still a lot to do on this one it's a stable editor that's very fast to use and I really can't recommend it enough. It's a solid increment on edit but particularly the menus and shortcuts are well streamlined, and the rest of the editor works a lot like notepad++ and most other windowed text editors, which is probably it's biggest virtue. I heard a few other features Gopher is planning and it's just… stuff that's just very nice to have (undo, file backups…)

So yeah, it's got a way to go yet but I tested it pretty thoroughly and give it a thumbs up :)/>

Thanks, nitro, your testing was invaluable!

Too many bug fixes to list, but finally did a push to release! New features are the same as the beta two posts back, plus the help option actually displays in-game help now. Keyboard-based block selection, easy to use basic menus, highly efficient advanced menus, and 95% less bugs. Nitro just wrote a whole game in it!

If you had the beta already, you can just run

edit+ --update

and it will grab the new release.

If you're still using the old version, you'll have to use the installer to update

pastebin run sR9t4iRZ

but hereafter, just "edit+ –update" will grab the latest version, or "edit+ –update beta" if you feel like trying the latest experimental build.


For the next version, I'll be focusing on file-related stuff. It'll start saving changes to a temp file, so you won't lose any code if the computer/server reboots, or if edit+ crashes. I'll also be adding undo/redo, "open" and "save as…" menu options with a gui file picker, and a confirmation dialog for of unsaved changes before closing a file.

Kaikaku, on 07 March 2015 - 12:58 PM said:

Yay, it works! The qwertz users have now {[~]} available ingame :D/>
First right-alt(AltGr) opens the menu, then press and hold AltGr + the respective key.

You shouldn't have had to open the menu first, but I just figured out how to test this on my own computer/keyboard by telling windows to pretend it's a german keyboard, and found that I only made the change on the advanced menus, not the basic ones. Grab the latest (as of this post) release and it should just work when you type altgr+<whatever> in the basic or advanced menus now.

GopherAtl, on 08 March 2015 - 07:23 PM said:

You shouldn't have had to open the menu first, but I just figured out how to test this on my own computer/keyboard by telling windows to pretend it's a german keyboard, and found that I only made the change on the advanced menus, not the basic ones. Grab the latest (as of this post) release and it should just work when you type altgr+<whatever> in the basic or advanced menus now.

Yes, in this version AltGr doesn't enter the menu and I can access the {[~]} normaly!

Tested the current version on all computer types: Command and advanced is fine. Regular computer and turtle raises: "(F)ileedit+:1064: attempt to get length of nil"

Kaikaku, on 09 March 2015 - 07:38 PM said:

Yes, in this version AltGr doesn't enter the menu and I can access the {[~]} normaly!

Excellent! Good to have further confirmation.

Kaikaku, on 09 March 2015 - 07:38 PM said:

Tested the current version on all computer types: Command and advanced is fine. Regular computer and turtle raises: "(F)ileedit+:1064: attempt to get length of nil"

Herp, need to remember to test on basic computers, or there's not much point in supporting them. Was an easy bug, just fixed it in the release repo, "edit+ –update" should download the fixed version.

Instead of an auto-indentation feature, maybe you could just keep the current level of tabs from the previous line? It could always just be an option; I find it essential to an editor to at least keep the level of indentation you're on. It's really annoying to have to hit tab 6 times every time I start a new line.

since you almost asked nicely this time, I went ahead and implemented it, in both beta and release. edit+ –update and you should have your wish granted! newlines indent to match the previous line, and even increase by one level if the previous line ended in "do", "then", "else", or "repeat." It will also, under the right conditions, de-indent end, until, else, or elseif - those conditions being that the line in question currently has the same indentation as the previous line. So if it's already de-indented, it won't de-indent it further.

It's super-convenient.

just "edit+ –update" to grab latest.

It's been a bit of a round-about process, but there's major changes in the current beta build. This next release is a big one. Note these new features are, for now, only in the beta version - see the first post of the thread for instructions on installing, or updating an existing installation! Though note that, as I mention in the OP, you may have to run –update twice before it will download the new files; I had to enhance the updater in v1.1, if you have v1.0 or earlier it won't know to download the new files the first time.

Features currently in the beta:
Save as and Load menu options; save as happens automatically if you try to save a read-only file, or to a read-only directory.
visual file picker, built within a new gui library called guiutils.

Here's a screenshot that shows the new file picker dialog:


It's not finished yet, got more usability features planned for the gui library in general, but it is most definitely usable already, and everything still works on basic/advanced computers. People willing to test out the beta and report any bugs they manage to find are always appreciated!

A side note about the gui library, when it has been properly tested, I may release it separately, as a stand-alone API. Anyone interested in it in that capacity is welcome to play with it, you can grab it directly from the github repo or by installing edit+. The functions messageBox and filePicker defined in the API itself are the best examples of using it to design custom guis, though edit+ only calls those functions at present, and it can be used purely on that level, as well.

(:edit: If you'd already downloaded before this edit, you probably got an instant crash with "couldn't find gui api." That's because I neglected to push the last commit, which added it to the filelist. Derp.)

How would I make the program search for it's apis in /usr/lib when it itself is in /usr/bin?

is it not doing so? It should be checking the root directory, the current shell directory, the directory the edit+ program is actually in, /usr/lib, /lib, and /apis. If it's not, confirm that for me and I'll look into a fix; the table of search paths is on line 49, in the loadAPI function, if you want to try to fix it yourself in the mean time.

yes I saw the different search paths. Hmm I installed the beta version and it worked instantly interesting. Thanks for the quick response!

the quick response was dumb luck, happened to be looking at the forum on my lunch break XD Glad it's working, I'll double-check later tonight that the dev and release aren't different in that respect, as they shouldn't be

I would however suggest you make it so that when it updates it actually puts the apis in the currently used library folder. For now I'll make the edit myself but I would suggest you changing that in you next release.

hmm. That's doable, and a good idea. Will add it to the to-do list for the next version.

Bug report:
Using the beta version. I have advanced menu enabled. When I press ctrl to open the menu and afterwards b to toggle block selection the program crashes.

document:848: attempt to call nil

ah, yeah, the dev version is *quite* unstable at the moment, as the new gui features required a pretty extensive overhaul. I took a break to work on some other projects (like getting my peripheral mod BioLocks updated to 1.7.10), and am a bit busy with other things at the moment. You might want to switch back to the latest release; I'll make time tonight to look into the path thing, make sure the release version is checking the right directories for APIs, and if I have time, possibly add the feature to correctly update apis in place, for those who're pulling the APIs to a separate api directory.

Thanks for your efforts!

Also, your installer only installs the two files from the current release. It doesn't download the apis needed for the beta. That is why I had my problem(which was fixed by running edit+ –update beta twice)

I would like to request a couple features:
undo/redo functions
and highlighting with the keyboard (as in press and hold shift and move the cursor with the arrows/home/end keys to highlight)
insert key(not sure how useful it would be)

With these features I would be more than happy to use this instead of an external text editor

edit: this may be a bit far off but how about a right click context menu (with only basic copy/cut/paste options)

Sorry, been out of town and busier than expected, but back home and plenty of free time tonight, so will finally address some of the issues that have been raised here.

superaxander, on 25 March 2015 - 05:56 PM said:

Also, your installer only installs the two files from the current release. It doesn't download the apis needed for the beta. That is why I had my problem(which was fixed by running edit+ –update beta twice)

Saw your pull request on this, and after initially completely misunderstanding what you were saying at first, I merged the PRs.

columna1, on 26 March 2015 - 01:16 PM said:

I would like to request a couple features:
undo/redo functions

working towards this already, will be in the next major release, though not sure how far off that is, exactly.

columna1, on 26 March 2015 - 01:16 PM said:

and highlighting with the keyboard (as in press and hold shift and move the cursor with the arrows/home/end keys to highlight)
insert key(not sure how useful it would be)

holding shift to do it is just not possible in CC as it stands currently; it will become possible in the next CC version, when key_up events are added, and rest assured, I'll support it then! For now, though it has the best I could do - hit ctrl,b (note, this is ctrl followed by B, not ctrl+b, ctrl-held-plus-B)/> to toggle block selection mode in either basic or advanced menu modes. It will begin a block selection at the current cursor position, and cursor movement keys will let you move the end of the block selection. ctrl,b again switches back to normal cursor mode, as does doing a cut, copy, or paste, or pressing any other keys or characters that replace the selection.

columna1, on 26 March 2015 - 01:16 PM said:

With these features I would be more than happy to use this instead of an external text editor

columna1, on 26 March 2015 - 01:16 PM said:

edit: this may be a bit far off but how about a right click context menu (with only basic copy/cut/paste options)

Not as far off as you might think, but not planned for the next release, which is focused on improved file handling - undo/redo history, a scratch copy to avoid losing unsaved changes, and the file picker dialogs (open, save as, etc). Context menus are planned for the version after that. In the mean time, I'd recommend the advanced menus. Just doing "ctrl,x", "ctrl,c", and "ctrl,v" for cut, copy, and paste are more efficient than context menus will ever be.

okie, update to the installer and the update function. The installer now accepts several arguments, in the form "-<arg>=<value>"

ver - either beta or release, default is release, specifies which version to install/update
bindir - directory to place binary files. Defaults to the directory the installer is run from
apidir - directory to place apis. Defaults to bindir, or the current directory if no bindir specified.

Some examples:

  //all defaults, will install the latest release to the current shell directory
  pastebin run sR9t4iRZ
  //install the latest beta, putting the APIs in /apis and the program in /programs
  pastebin run sR9t4iRZ -ver=beta -bindir=/programs -apidir=/apis

So, run without args and it works just like before, which will give a windows-style installation, with the program and it's apis together. But if you're using a unix-like file system setup, you can specify "-bindir=/usr/bin -apidir=/usr/lib", or whatever the directory structure on your computer or OS is. These directories are stored to the config file, and the –update command line option will use the config settings so that updated files will be put where you originally installed them. This seems more convenient than the original approach, the only downside being that if you manually rearrange the files, you'll have to edit the edit+ config file (called ".edit+" and stored in the same directory as the main program) to change the directories there, as well.

:edit: bump for status update, over the weekend done much testing and bug-fixing on the beta, it is far more usable than it was a few days ago. Also got indent-assist working on pasted multi-line blocks, and added back the use of /usr/etc or /etc, if present, for the config file, which was inadvertently removed by an update last week. This all means the code is finally at a point where I will start implementing undo. The feature itself won't be that much code, really, but testing all the cases and making sure it's solid enough for release might take some time. I'm regretting that I didn't take the time to test and polish a release with the gui refactor and the new file picker and other dialogs instead of pushing on towards undo/redo; I won't push any more changes to github, other than bug fixes, until I've got undo/redo implemented and reasonably stable, so if anyone wants to volunteer to try and break the current beta version and report any errors they find for me, I'd really appreciate it, and it would let me push out another release before the undo/redo and related features are implemented and go live for beta.

Very nice progress! I'm excited to see the undo/redo feature implemented!

This thing is great. Excited for Undo/Redo feature. I use this for a kids programming class, and used the document api to make a function/logic bank to insert loops and whatnot easily.

Minor visual bug with the version available through packman: If you scroll up such that the line the cursor is on is the last line of the console, the cursor will be drawn there despite the text not being drawn.