gui
gui copied to clipboard
racket
Weird interaction between selection by mouse and selection by keys
Select a text in DrRacket with mouse. It is then impossible to use keys (shift+arrow) to shrink the selection (although extending is possible).
See the attached GIF.
This issue should really be moved to racket/gui.
@rfindler I think the problem here is that in every text editor that I use, extendstartpos and extendendpos are always equal to each other. In Racket GUI however, it allows them to be different. Can we fix this somehow?
I think one difficulty is that, what should operation like set-position do? Should it set extendstartpos = extendendpos = starting position? Or should it set extendstartpos = extendendpos = ending position? Perhaps there should be a new argument to control this? I'm not familiar with invariants in the code enough to confidently modify it.
This isn't code that I wrote either and I've worked with it some but I wouldn't say I'm particularly confident.
I do see what you mean about always having extendstartpos and extendendpos always being equal to each other and how that matches other editors' behavior. I think that if you click once and then start with shift arrow keys, that you'll get the behavior you want, tho, right?
I do think the current behavior is intended, however, and doesn't seem buggy (not buggy in the sense it does what its original author intended). And, FWIW, the code's behavior probably predates 2009.
I guess I don't have strong opinions here. I did try Emacs, Sublime, TextEdit, and Campuswire's in-browser editor and they all behave as if extendstartpos and extendendpos were always equal.
I didn't try it out, but just looking at the code and playing with those four editors, it seems like the change you'd want would be to just get rid of extendstartpos and extendendpos and replace them with just extendpos, where set-position sets extendpos to the starting part of the region. I didn't seriously try this out, however.
This issue should really be moved to
racket/gui.
I agree, and I've done that.
@rfindler My apologies. GitHub says you touch this file the most, so I assumed you wrote that code. Git blame seems to indicate that part was actually written by @mflatt.
Yes, there is a workaround as you said, but the workaround is not always feasible. For instance, if I want to make a selection over hundred lines, it makes more sense to use dragging / click + shift + click rather than click + shift-arrow keys.
It is also possible to drag backward. E.g., start dragging at position 10 and end dragging at position 5. In this case, extendpos should be 10, not 5. I think set-position should be flexible enough to do this kind of operation too, so "set-position sets extendpos to the starting part of the region" won't really work.
Git blame seems to indicate that part was actually written by @mflatt.
The git history trail goes dead for me quickly, showing only one commit for the lines that you linked to above, but Matthew originally wrote the editor libraries in C/C++ a long time ago (it is one of the earliest parts of Racket) and what you see here is the port of that to Racket which also happened a long time ago.
It is also possible to drag backward. E.g., start dragging at position 10 and end dragging at position 5. In this case, extendpos should be 10, not 5. I think set-position should be flexible enough to do this kind of operation too, so "set-position sets extendpos to the starting part of the region" won't really work.
Ah, yes. I see what you mean about sometimes the end of the selection is what extendpos would have to be. The mouse handling code will have to use extend-position, then, I suppose. I'm not sure what it is currently doing. I think it is probably fine that set-position makes a specific choice and documents it, however.
I think, if I'm reading the C++ code correctly, that the current behavior was introduced by @mflatt here: https://github.com/racket/old-plt/commit/d906fb84d83358a1cae27880a6aa6fd2a8c364ae in early 1999.
