Yedit: EOL treatment + Mouse click bug #61
Comments
|
Thanks for all the great suggestions. There's a lot here and it might take a while to work through it all.
Are you referring to yedit.exe? It should be part of yori-typical.cab, both in stable and daily. Are you seeing something different?
Hmm, odd that I missed that. I have a fix for it ready, will push it soon.
This behavior is following MS-DOS Edit. I've been following version 1 (which is included with NT 4.) I don't know if version 2 did something different. But I agree this behavior is a little strange, and I'm open to changing it; I just wanted to start with the original and see what people want before deviating too much.
Can I ask what this one refers to? When I select a line with shift+down and hit del, the cursor seems to end in the right location. What are you using to delete the line, and where does the cursor go? This is one area where I changed behavior from Edit. In Edit, it's not possible to have a selection that spans lines without including the entire line - you can select lines, or select characters within a line, but not both. When deleting a selection that spans lines, it returns the cursor to the beginning of the line because that's the beginning of the selection.
Hmm, I never knew Edit did that...
Yedit followed edit by putting drives as part of the directory list. I know that's not what modern UIs do, but it was common for DOS programs.
I've been wanting to implement this too. It's a larger change and may take a while though.
Realistically, I doubt this will ever happen. Auto indent implies knowledge of the language that the text is written in. That just seems "a bridge too far" - there are lots of good editors that do this kind of thing, but they are necessarily larger and need ongoing maintenance to keep up with the languages they are parsing.
You probably already knew this, but it looks like MS-DOS Edit treats Ctrl+A as move one word left, Ctrl+S as move one char left, Ctrl+D as move one char right, and Ctrl+F as move one word right. I didn't know that before. I wonder what environment they were using it in where arrow keys were not available or supported.
Since I've been following Edit 1, there's no multi-document support. I'm not sure if this is worth doing or not - in a modern environment it's easy to launch multiple instances, and the clipboard is shared since it's using the Windows clipboard. The main reason I can see for this is when using SSH and launching multiple instances of things is hard.
You're not the first person to ask for this, although it's a ton of work, and Edit 1 didn't support it. (I had to build support for this in ymore.exe and am horrified about how it turned out but don't know how to do better.)
That's very funny. I have a fix and will push it soon. This was broken by trying to support mouse selection - it has created a selection with zero characters in it. Delete refuses to delete an empty selection, but leaves the selection there anyway, so the only way out is to use keys that clear selections. |
|
Hi, +Alternate installation
I appreciate yedit was built as part of yori, but am delighted that it only imports KERNEL32.DLL and +Behaviors You are entirely correct about the default cursor behaviors and I never knew about some of these original keyboard shortcuts:
I guess as I am running Autohotkey I could remap some of these, to use the arrow keys - or even "hjkl". This is your project and the difficult decisions about replicating/modernizing the handling of EOL boundaries is in your hands.
I was using "{Home}, Shift-{End}, {Del}" to remove a line and the cursor was staying at the old last col on an empty line which looked very odd. If you choose to hold the cursor to the left of the EOL this will then bring the cursor back to col 1. I have still not found how yedit allows one to change drive; when displaying my root directory there are no other drives listed. This could be a feature of my system. +Extensions I can imagine wrapping lines is difficult, but it does allow comfortable use of the editor for prose/letters/emails. Infinite Undo combined with Run is just so good for scripting: "edit, save(CTRL+S), execute(Shift+F5), undo(CTRL+Z)" is a very common cycle. I can live without multiple documents/splits etc. However, spawning a new instance in the current directory would be useful. Once again many thanks for bringing back edit to the command line. Kind Regards Gavin Holt Edited after reading you commit descriptions |
|
Hi, Kind regards Gavin |
Hi,
Many thanks for making the effort, especially as you appear to be a vim user!
As a non-compiling amateur the self contained windows binary is very welcome
(I note it's not in the nightly CAB build).
Feels great, very clean interface and only 78ms to startup!!
Not having to think about how to use the editor,
really concentrates the mind regarding adding features.
It was a long time ago that edit.com was my workhorse and
I can't run the original so it's difficult to remember specific behaviors.
As a 100% DOS/Windows user I do have deeply ingrained muscle memory
for cursor movements, cut copy paste undo, find replace goto, new open save(as) reload quit.
Perhaps yedit could mimicking edit.com as described on the web:
What is the "most valued feature" missing?
What is in the "first tier of desires"
Bugs?
Enhancements (Autohotkey)
See: https://www.autohotkey.com/docs/commands/_IfWinActive.htm
#IfWinActive Administrator: yedit.exe
{
^':: Send ''{Left}
^2:: Send ""{Left}
^9:: Send (){Left}
^0:: Send (){Left}
^[:: Send []{Left}
^]:: Send []{Left}
^b:: Send {Home}
^+b:: SendInput +{Home}
^e:: Send {End}
^+e:: SendInput +{End}
^k:: SendInput +{End}{Del}
+^k:: SendInput +{Home}{BS}
^y:: Send {End}+{Home}{Del}{BS}{Down}{Home}
^+s:: Send !fa
^w:: Send !fx
^h:: Send !sc
^Up:: Send {F3}
^Down:: Send {F3}
WheelUp:: Send {Home}{Up}{Up}
WheelDown:: Send {Home}{Down}{Down}
^RButton:: SendInput {RAW}%ClipBoard% ; Paste
}
The text was updated successfully, but these errors were encountered: