I was testing host menu support today and as part of the testing noticed something odd, but in fact it's been there a long time. You see if you select nothing in a text field (aka a ParagraphEditor) it makes the entire line disappear. WHAT?
mmm a bug on my part, no.
You see ParagraphEditor>>cut reads...
cut "Cut out the current selection and redisplay the paragraph if necessary. Undoer & Redoer: undoCutCopy:"
self lineSelectAndEmptyCheck: [^ self].
self replaceSelectionWith: self nullText. self undoer: #undoCutCopy: with: self clipboardText. self clipboardTextPut: UndoSelection
Part of the logic in lineSelectAndEmptyCheck: selects the entire line if the selection point is nil and there is a run of something to select, otherwise it flashes the text area. So it on purpose selects the line, then does the cut.
In checking VisualWorks 5.x I see it doesn't have this behavior, and usually I've selected some text when I do a cut. So the question is should we change things? I just found this behavior a bit odd.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Hi, John,
Well it's certainly an intentional feature.
Though it's not a feature of VisualWorks, nor perhaps of any other Smalltalk for that matter, for many years it has been a trademark feature of Squeak that any text-editing command that requires a non-empty selection, if issued when the selection is an insertion point (i.e. is empty,) will first select the current line before executing the command.
This convention is followed for all the twenty-some-odd commands that can be invoked from within the text-editor which require a non-empty selection.
For many users (including me) this convention is a huge time saver and wrist-preserver.
For example, on a blank line anywhere that text can be typed, you can type: Morph <cmd-b> and without needing to click the mouse or fish into a menu, you will have a browser open on class Morph.
Similarly, you can type lineSelec <cmd-q> <cmd-n> and you'll immediately be presented with all senders of #lineSelectAndEmptyCheck: -- which, incidentally, will reveal all the commands to which the convention applies.
Or, similarly, type cut <cmd-shift-W> to discover all selectors that contain the keyword "cut".
I suppose that if there are others like you who find this feature unsettling, we could make it be governed by a Preference.
Or perhaps you're only objecting to having the feature apply to "cut," but would be happy to see it continue to work for all the other two dozen commands which can be invoked within the text-editor and which require a non-null selection?
Cheers,
-- Scott
At 8:22 PM -0700 9/22/04, John M McIntosh wrote:
I was testing host menu support today and as part of the testing noticed something odd, but in fact it's been there a long time. You see if you select nothing in a text field (aka a ParagraphEditor) it makes the entire line disappear. WHAT?
mmm a bug on my part, no.
You see ParagraphEditor>>cut reads...
cut "Cut out the current selection and redisplay the paragraph if necessary. Undoer & Redoer: undoCutCopy:"
self lineSelectAndEmptyCheck: [^ self].
self replaceSelectionWith: self nullText. self undoer: #undoCutCopy: with: self clipboardText. self clipboardTextPut: UndoSelection
Part of the logic in lineSelectAndEmptyCheck: selects the entire line if the selection point is nil and there is a run of something to select, otherwise it flashes the text area. So it on purpose selects the line, then does the cut.
In checking VisualWorks 5.x I see it doesn't have this behavior, and usually I've selected some text when I do a cut. So the question is should we change things? I just found this behavior a bit odd.
--
John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Am 23.09.2004 um 06:29 schrieb Scott Wallace:
For many users (including me) this convention is a huge time saver and wrist-preserver.
Yep, me too. I wouldn't say huge (but then again, I'm German - err, never mind), but it's often convenient. Many people do not even notice it, because it seldomly, if at all, does get into the way. So for me it's fine as it is, even for cuts. *IF* we're going to touch this it would be much more important to find those odd circumstances in which Undo won't undo correctly ... or, even better, have multiple undo steps like in Tweak.
- Bert -
squeak-dev@lists.squeakfoundation.org