[OS3.2] Feature request : implementing shift/ctrl + del/backspace shortcuts

[torturedutopian]

Hi !


Please tell me if that's not the right place for this kind of request


I'm quite accustomed to the following shortcuts which are IMHO very handy under 3.x :


in any dialog box / text field (for instance, the "Execute" window) :

SHIFT + BACKSPACE : removes the chunk of text before the cursor
SHIFT + DEL : ... after the cursor


in MUI classes, in KingCon..., in addition to those above, you have :
CTRL + BACKSPACE : removes the WORD before the cursor
CTRL + DEL : ... after the cursor


That's super handy for quickly modifying a portion of text, some command line arguments etc.


Would love to see those in OS 3.3 ;-)
Cheers. Hoping I don't sound like a spoilt kid !

[Thomas Richter]

For string gadgets, there is StringSnip, part of ViNCEd, or also available stand-alone, which adds additional keyboard shortcuts identical to those of ViNCEd.

http://aminet.net/package/util/sys/StringSnip

This is not a patch, it just populates the default string editing hook of intuition, which is there for exactly this purpose.

For the console, the answer is that this wouldn't be easily possible. The problem is that the console.device, which sits underneath the CON: handler, uses ANSI sequences to report the keystrokes to its clients (e.g. CON and unfortunately ANSI does not define sequences for them.

ViNCEd can do that because it is a single-layer design, as opposed to CON: which sits (correctly so) on top of the console.device.

[torturedutopian]

Hi, thanks so much for the elaborate answer :-)
Have a nice day !

Edit : are there plans to provide further OS 3.x update with ViNCEd, P96 etc. built-in ? Or is there a focus on minimalism and leaving the choice to the user ?

[idrougge]

Originally Posted by torturedutopian

in any dialog box / text field (for instance, the "Execute" window) :

SHIFT + BACKSPACE : removes the chunk of text before the cursor
SHIFT + DEL : ... after the cursor

The »Execute« window on OS 3.2 supports this, does it not for you?

[idrougge]

Originally Posted by Thomas Richter

For the console, the answer is that this wouldn't be easily possible. The problem is that the console.device, which sits underneath the CON: handler, uses ANSI sequences to report the keystrokes to its clients (e.g. CON and unfortunately ANSI does not define sequences for them.

ViNCEd can do that because it is a single-layer design, as opposed to CON: which sits (correctly so) on top of the console.device.

KCON: supports shift-backspace, is that also not working with console.device?

Perhaps console.device needs an update if it is causing drawbacks such as these?

[Thomas Richter]

Did you read and understand my post? There is no ANSI sequence (yes, that is a standard, also available from ECMA) for this key combination, thus there is nothing particular the console.device could signal.

[idrougge]

I don’t understand this kind of reasoning. The ANSI standard, which is some kind of lowest common denominator made for devices pre-dating the Amiga, is apparently not sufficient to handle this.

The keys are there, regardless of what ANSI and ECMA say; they have no say on what is in the user interface style guide (not to mention users’ expectations), which is published by Commodore.

[Daedalus]

Originally Posted by torturedutopian

I'm quite accustomed to the following shortcuts which are IMHO very handy under 3.x :

[...]

That's super handy for quickly modifying a portion of text, some command line arguments etc.

These shortcuts (and the similar, related Shift+left arrow, Shift+right arrow etc.) were consistent from at least OS 2.0 times, through to 3.9 and 4.1. They have been changed for 3.2, apparently in order to bring them in line with other platforms. Where shift has always been to move to / delete to the start/end of the line, it has been changed to Ctrl, and Shift instead is used for selecting the text in the gadget. Alt is used for moving to / deleting the next/previous word, though that is consistent with OS 3.9.

While this behaviour is more in-line with other platforms, it's a change I've found jarring in AmigaOS. It also introduces inconsistencies as observed between MUI and the native toolkits, and there are also inconsistencies within the OS itself, e.g. ASL file requesters still move/delete to the beginning/end instead of highlighting when shift is held.

Bottom line, I wouldn't hold your breath for these shortcuts to be reverted to the previous behaviour in future versions.

[boemann]

Originally Posted by idrougge

I don’t understand this kind of reasoning. The ANSI standard, which is some kind of lowest common denominator made for devices pre-dating the Amiga, is apparently not sufficient to handle this.

The keys are there, regardless of what ANSI and ECMA say; they have no say on what is in the user interface style guide (not to mention users’ expectations), which is published by Commodore.

Well it is the console.device that reigsters keypresses. It can surely detect such a keypress. But console.device communicates with CON: handler via ANSI, so if there is no way to express such a thing using ANSI then CON: handler can't be told.

And it is CON: handler that has to implement the functionality.

I hear your request though, so let's see what can be done in 3.3 (although that is many years away if at all).

[boemann]

Originally Posted by Daedalus

These shortcuts (and the similar, related Shift+left arrow, Shift+right arrow etc.) were consistent from at least OS 2.0 times, through to 3.9 and 4.1. They have been changed for 3.2, apparently in order to bring them in line with other platforms. Where shift has always been to move to / delete to the start/end of the line, it has been changed to Ctrl, and Shift instead is used for selecting the text in the gadget. Alt is used for moving to / deleting the next/previous word, though that is consistent with OS 3.9.

While this behaviour is more in-line with other platforms, it's a change I've found jarring in AmigaOS. It also introduces inconsistencies as observed between MUI and the native toolkits, and there are also inconsistencies within the OS itself, e.g. ASL file requesters still move/delete to the beginning/end instead of highlighting when shift is held.

Bottom line, I wouldn't hold your breath for these shortcuts to be reverted to the previous behaviour in future versions.

The change you describe here is not relevant to the console issue the original poster asked about though