Proposal committed to frq-3555324 branch. It makes use of the
virtual-event changes from bug-3555644. I'm not saying we
should grant this (See Tcl bug 3554051), but I we do, this
is how.
<<SelectAll>> is anyway more readable than <Control-slash>,
whether we bind it to <Control-a> or not.
Jeff, your opinion about this please. I don't think that many
people know that <Control-slash> selects everything,
<Control-a> seems much more common.
Or, should a TIP be filed on this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For Windows the situation is rather clear: Many
other applications use Ctrl-A for this, besides, the
current function of Ctrl-A is <Home>, while all
Windows keyboards simply have a <Home> key
which does the same.. So, committed that
part to trunk.
For Unix, the situation is less clear. Do all
keyboards in use there have the <Home>
key? Besides, there is an alternative:
Ctrl-slash, and Ctrl-A conflicts with other
Emacs-like bindings.
So, for now, keeping it as-is on UNIX.
Other opinions? What to do with this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jan -- before you merge this to trunk, better run it by tcl-core first. I get the impression that there are a lot of Tcl users (even on Windows) who would be very unhappy to lose their Emacs bindings.
Overall I think the move towards more virtual events is a good direction. (Just wary of incurring the wrath of Emacs people :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>(Just wary of incurring the wrath of Emacs people :-)
Yes, I'm aware of that. After Tk8.6b3 is out, I plan to
send a poll on Tcl Core, but a little more general
than that. For example, on Mac, the emacs-like
bindings changed from using "Control" to using
the "Command" key. That's useful, because
then there is no conflict any more between
<SelectAll> (Control-a) and <Home>
(Command-a), and it's following the Apple
documentation. But it could be made
switchable as well.
For Windows/Mac I'm not that afraid: It's the
Microsoft/Apple documentation against
the legacy implementation ;-) And, now
that we have virtual events, it's easy
to get the emacs bindings back. On Windows, just:
event delete <<SelectAll>> <Control-Key-a> <Control-Lock-Key-A>
event add <<LineStart>> <Control-Key-a> <Control-Lock-Key-A>
We even could introduce a variable ::tk_strictWin32,
set to 1 by default, which arranges that, similar
to the current ::tk_strictMotif on UNIX. But let's
wait for 8.6b3 and then the poll.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Proposal committed to frq-3555324 branch. It makes use of the
virtual-event changes from bug-3555644. I'm not saying we
should grant this (See Tcl bug 3554051), but I we do, this
is how.
<<SelectAll>> is anyway more readable than <Control-slash>,
whether we bind it to <Control-a> or not.
Jeff, your opinion about this please. I don't think that many
people know that <Control-slash> selects everything,
<Control-a> seems much more common.
Or, should a TIP be filed on this?
For Windows the situation is rather clear: Many
other applications use Ctrl-A for this, besides, the
current function of Ctrl-A is <Home>, while all
Windows keyboards simply have a <Home> key
which does the same.. So, committed that
part to trunk.
For Unix, the situation is less clear. Do all
keyboards in use there have the <Home>
key? Besides, there is an alternative:
Ctrl-slash, and Ctrl-A conflicts with other
Emacs-like bindings.
So, for now, keeping it as-is on UNIX.
Other opinions? What to do with this?
Jan -- before you merge this to trunk, better run it by tcl-core first. I get the impression that there are a lot of Tcl users (even on Windows) who would be very unhappy to lose their Emacs bindings.
Overall I think the move towards more virtual events is a good direction. (Just wary of incurring the wrath of Emacs people :-)
>(Just wary of incurring the wrath of Emacs people :-)
Yes, I'm aware of that. After Tk8.6b3 is out, I plan to
send a poll on Tcl Core, but a little more general
than that. For example, on Mac, the emacs-like
bindings changed from using "Control" to using
the "Command" key. That's useful, because
then there is no conflict any more between
<SelectAll> (Control-a) and <Home>
(Command-a), and it's following the Apple
documentation. But it could be made
switchable as well.
For Windows/Mac I'm not that afraid: It's the
Microsoft/Apple documentation against
the legacy implementation ;-) And, now
that we have virtual events, it's easy
to get the emacs bindings back. On Windows, just:
event delete <<SelectAll>> <Control-Key-a> <Control-Lock-Key-A>
event add <<LineStart>> <Control-Key-a> <Control-Lock-Key-A>
We even could introduce a variable ::tk_strictWin32,
set to 1 by default, which arranges that, similar
to the current ::tk_strictMotif on UNIX. But let's
wait for 8.6b3 and then the poll.