C-e for going to end-of-line problem?
smcho
has the following lines.
beginning-of-line = Ctrl-a
end-of-line = Ctrl-e
I expect C-e to go to end-of-line, but C-e works as the next line.
Alt-x and check end-of-line and I get the following result.
end-of-line all: <Ctrl+E>
What might be wrong?
Edward K. Ream
Works for me with the Qt gui on Windows 7.
In general, when reporting problems, it is a good idea to report the
environment printed in Leo's log pane when Leo starts up. At present,
I don't know what platform you are using, or what gui, or anything
else.
Edward
smcho
C-a move the cursor to the start of line, but C-e seems to move the
cursor the first of the next line, which is the end of last line + 1.
If the line is the final one, C-e moves the cursor to the end of line
as there's no next line.
And this is the environment info for my machine.
Leo 4.8 rc1, build 3715, November 15, 2010
Python 2.6.1, qt version 4.7.0
darwin
On Nov 16, 3:09 pm, smcho <csmgr...@gmail.com> wrote:
> I copy the log info from Leo.
>
> I use Mac OS X 10.6.5, newest Leo, and Python/Qt.
>
> Leo 4.8 rc1, build 3715, November 15, 2010
> Python 2.6.1, qt version 4.7.0
> darwin
>
> I remember I could use C-e, but it doesn't work anymore even after I
> reinstall the Leo.
>
> On Nov 16, 2:54 pm, "Edward K. Ream" <edream...@gmail.com> wrote:
Edward K. Ream
> I don't know if this is a bug or not, but this is what I found.
It's definitely a bug, and potentially a very hard bug to fix.
The following notes are for @bool swap_mac_keys = False, which is,
according to the notes, the recommended setting.
> C-a move the cursor to the start of line, but C-e seems to move the
> cursor the first of the next line, which is the end of last line + 1.
> If the line is the final one, C-e moves the cursor to the end of line
> as there's no next line.
Neither c-a nor c-e is being passed to eventFilter, which means that
as far as Leo concerned these keys have never been pressed!
The situation on the Mac is dire, as far as keystrokes go. For
example, Ctrl-h apparently minimizes the window without any chance of
intercepting the stroke. Moreover, the alt key on Mac-specific
keyboards generates a Alt character, but the alt key on Microsoft
keyboards generates the Meta character (!!). Apparently, Leo doesn't
handle the Meta character as it should, which makes it impossible to
type Alt-x.
It gets worse. There appears to be no way to activate the Leo menus
from the keyboard at present. I'm not sure whether MacOS is involved
in this problem or not.
I'm not sure there is anything Leo can do about MacOS intercepting
various keystrokes, but now is the time to do some investigating.
Ideally, it would be good to get rid of the eventFilter method (and
all its odious helpers), replacing them all with "harder" bindings set
at init time. Of course, these would have to be "late" bindings,
created after the various settings files have been created.
It's time for some experiments on a simple prototype...
Edward
Ville M. Vainio
> Ideally, it would be good to get rid of the eventFilter method (and
> all its odious helpers), replacing them all with "harder" bindings set
> at init time. Of course, these would have to be "late" bindings,
> created after the various settings files have been created.
Do you mean QKeySequence objects associated with QActions that define
a leo command, that would be pretty cool.
--
Ville M. Vainio @@ Forum Nokia
Edward K. Ream
That's a coding detail, and an interesting one.
I've been giving the general problem some thought lately. I'll write
up my first thoughts later today.
Edward