Caution: rev 4952 fixes bug 87933 with major key reorg: please test

[Edward K. Ream]

Ref 4952 of the trunk fixes bug 87933:
"Redefining a key binding breaks menu items with same binding"

This was a difficult bug to fix--I rewrote significant parts of Leo's
code that deals with settings for key binding.

All unit tests pass, and I have been using this code happily for a few
days, but significant problems could be lurking. Please use caution
and please report any problems immediately, especially settings-
related problems.

Besides fixing the bug, Leo computes accelerators, in menu items
dynamically when the user activates a menu. The accelerator shows
*all* keys bound to the command associated with the menu item.

In the next few days I'll be simplifying the new code further, so if
you want more stable code please stay away from the trunk and the
nightly builds for the next several days.

Here is the checkin log:

A major reorganization of the configuration code that fixes bug 87933
Redefining a key binding breaks menu items with same binding

- Replaced g.bunches with ShortcutInfo objects, and bunchList name by
aList followed by
assert isinstance(si,ShortcutInfo),si

Using ShortcutInfo objects rather than g.bunch was a big win.

- Wrote and tested make_settings_dict and its helpers,
merge_settings_dicts, invert and uninvert.

- Leo computes menu texts dynamically in onAboutToShow.

- leo_update_shortcut now shows all shortcuts for a command.

- leoMenu.define_enable_dict encapsulates data used to enable/disable
commands regardless
of where those commands appear in Leo's menu. The old code assumed
that a fixed menu
location for all commands that could be enabled or disabled.

- Removed dynamic_menus "compile-time" constant.

- Created << define global key dicts >> in leoApp.py.

This is a duplicate of dicts in leoKeys.py: they will be merged
later today
in a location to be determined.

- Added unused ShortcutName and ShortcutsDict classes.

The ShortcutName class will go away: it's methods may become methods
of the ShortcutInfo class.
Alternatively, the methods might stay where they are.

The ShortcutsDict class *will* become functional: it's the only way
to eliminate the wretched
_hash hack used in the present raw key dictionaries. Furthermore,
the ShortcutsDict class
will probably encapsulate inverted dicts.

Edward

[Edward K. Ream]

On Jan 30, 7:29 am, "Edward K. Ream" <edream...@gmail.com> wrote:

> Ref 4952 of the trunk fixes bug 87933:
> "Redefining a key binding breaks menu items with same binding"
>
> This was a difficult bug to fix--I rewrote significant parts of Leo's
> code that deals with settings for key binding.

I am now in the midst of some long-overdue simplification that has
been made possible with the new code:

1. Leo now (provably) no longer uses the very complex g.app.config.get/
set code for shortcuts.

2. The new k.kill_one_shortcut allows k.registerCommand to properly
override settings. For example, File:New is no longer bound to Ctrl-N
when the following becomes active::

@button test @key=Ctrl-N

k.kill_one_shortcut uses the invert/uninvert trick used in
merge_settings_dict. Only this kind of elegant code has a chance of
working reliably.

3. As mentioned in another thread, k.tkbindingFromStroke is about to
make its exit.

4. I'll be making several other simplifications to the config code in
the next several days. It is important to do it now while all the
complexities are fresh in my mind.

When all this work is done, it will be time to consider releasing Leo
4.10 b1. After that goes out the door I'll fix several other high-
priority bugs before b2.

Edward

[Kent Tenney]

This is AWESOME!

- it makes all the simple key combinations available for custom defs
(I was jealous of Leo claiming so many ctl-<key> codes, too lazy to
learn ctl-alt-<key>)

- they take effect with only a save and revert, no need to close and open

A great day for Leo customization.

Thanks,
Kent

> --
> You received this message because you are subscribed to the Google Groups "leo-editor" group.
> To post to this group, send email to leo-e...@googlegroups.com.
> To unsubscribe from this group, send email to leo-editor+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
>

[Edward K. Ream]

On Mon, Jan 30, 2012 at 12:49 PM, Kent Tenney <kte...@gmail.com> wrote:
> This is AWESOME!

Glad you like it. BTW, later revs improve the printing of bindings in
the print-bindings, print-commands and during tab completion.

EKR

[Viktor Ransmayr]

Hello Edward,

On 30 Jan., 14:29, "Edward K. Ream" <edream...@gmail.com> wrote:
> Ref 4952 of the trunk fixes bug 87933:
> "Redefining a key binding breaks menu items with same binding"

> ...

As of revision 4959 'Alt + x' no longer selects/ enters 'command
mode'.

The outlook of 'Help -> Print Bindings' looks strange to me. - However
I can't provide a log, since select all + copy does not work in log
pane
either - and - I do not want to spend the time to type it in by
hand ...

At the moment I see not other chance than reverting back to a version
before revision 4952.

With kind regards,

Viktor

[Viktor Ransmayr]

On 31 Jan., 04:54, Viktor Ransmayr <viktor.ransm...@gmail.com> wrote:
> Hello Edward,
>
> On 30 Jan., 14:29, "Edward K. Ream" <edream...@gmail.com> wrote:
>
> > Ref 4952 of the trunk fixes bug 87933:
> > "Redefining a key binding breaks menu items with same binding"
> > ...
>
> As of revision 4959 'Alt + x' no longer selects/ enters 'command
> mode'.
>

> ...
> At the moment I see not other chance than reverting back to a version
> before revision 4952.
>

Just for the record. - Deleting the existing snapshot and executing
"bzr branch lp:leo-editor --revision=4950" resolved the reported
issue.

With kind regards,

Viktor

[Edward K. Ream]

On Mon, Jan 30, 2012 at 9:54 PM, Viktor Ransmayr
<viktor....@gmail.com> wrote:

> As of revision 4959 'Alt + x' no longer selects/ enters 'command
> mode'.

It works for me on Windows 7 with either Python 2.6 or Python 3.2.
What platform are you using?

> The outlook of 'Help -> Print Bindings' looks strange to me.

Recent revs have improved its appearance, but only when using
monospaced fonts in the log pane.

Edward

[redla]

Edward,
after the yesterday update (i.e. with the latest code) I am also
observing very strange behaviour of Leo.
I don't have an exact repro, but some things what I've seen follows:
- copy/paste body text by CTRL-C/CTRL-V is corrupted. It seems like
CTRL-C still does what
it should (at least I can select a block of text by a mouse, copy that
by CTRL-C and paste it properly
_to another application_ (like gvim), but CTRL-V simply does nothing
- I've found a "workaround" - if I do a right click on the body, a pop-
up menu appears containing copy/paste
etc. items (even with corresponding CTRL-C etc. shortcuts shown). And
if I selecte that "paste" from this
"context" menu, the text (even from external appl like gvim) is pasted
properly. BTW: The rendered context menu has no border shown and it
also uses the sabe background color like the body itself so it looks a
bit strange
- editing text in body panels is broken too. I can type a "plain"
text, but whenever I want to move cursor by pressing some arrow key,
the corresponding "Right", "Left" etc, string is included instead ;-
( And for delete a little triangle appear. Interestingly (and luckily)
Backspace still works properly (i.e. deletes a char before the
cursor). So for now I do "editing" by moving cursor by a mouse and
using only backspace - not a lot of fun...
- I've also seen similar problems with the tree panel, IMHO CTRL-I
doesn't work either. And delete put the same triangle like in body
I am using the lalest (BZR) leo sources with python3.2.2 on Arch Linux
(with a jwm window manager, but IMHO that shouldn't matter)

BTW: For some longer time (weeks/months) an "goto end line" handler is
broken too. Having long enough line in the body (so it is wrapped and
spans over multiple physical line), "Home" properly jumps at the start
of the (logical) line, but "End" jumps only to the end of physical
line, i.e. into middle of the line itself. Cut that bug (or at least
non-symmetry) be fixed too, please?

Kind regards,
Radim

[Viktor Ransmayr]

Hello Edwards,

On 31 Jan., 11:17, "Edward K. Ream" <edream...@gmail.com> wrote:
> On Mon, Jan 30, 2012 at 9:54 PM, Viktor Ransmayr
>

> <viktor.ransm...@gmail.com> wrote:
> > As of revision 4959 'Alt + x' no longer selects/ enters 'command
> > mode'.
>
> It works for me on Windows 7 with either Python 2.6 or Python 3.2.
> What platform are you using?

Windows 7 and Python 3.2 !

> > The outlook of 'Help -> Print Bindings' looks strange to me.
>
> Recent revs have improved its appearance, but only when using
> monospaced fonts in the log pane.

I should have phrased it more precisely. - The content of 'H -> P B'
is " empty/ null/ ..." in my environment.

However, as I stated in my second mail, reverting to rev. 4950 solved
the problem !

Viktor

[redla]

> after the yesterday update (i.e. with the latest code) I am also
> observing very strange behaviour of Leo.

As Viktor proposed, reverting to bzr version 4950 "fixes" all the
described problems (except the End going to only physical line and not
to the logical (wrapped) one)...