#530 unexpected copy/paste behaviour

release
closed-fixed
Program (402)
9
2006-10-17
2006-06-30
Joor Loohuis
No

I ran into some copy paste behaviour that IMHO is
unexpected to say the least.

1. select some text (ctrl-c)
2. expose/activate the incremental search bar (ctrl-i)
3. paste selected text (ctrl-v)
4. the text gets inserted in the text buffer, not in
the search bar, even though it has keyboard focus

NEdit release of Aug 20, 2004

Built on: Linux, 386, GNU C
Built at: Oct 6 2004, 11:39:53
With Motif: 2.2.3 [@(#)Motif Version 2.2.3]
Running Motif: 2.2 [unknown]
Server: The X.Org Foundation 60802000
Visual: 24-bit TrueColor (ID 0x21, Default)
Locale: nl_NL.UTF-8

Discussion

  • Thorsten Haude
    Thorsten Haude
    2006-08-11

    • assigned_to: nobody --> yooden
     
  • Scott Tringali
    Scott Tringali
    2006-08-11

    Logged In: YES
    user_id=11321

    Sadly, these are the Motif rules for menu accelerators, sadly.

    Ctrl+C is not a text-field translation; it's a menu accelerator.

    Motif doesn't have any support to override global
    accelerators with more focus-specific translations. It
    always prefers the global accelerators.

    This is the same reason that, when the text field has focus,
    if you click Edit>Paste it will go into the text widget, not
    your search bar.

    Example: if you use Shift-Insert to paste it works fine
    because it's a translation, not an accelerator.

    I think we could fix it by removing the ^C/^X/^V menu
    accelerators from the menu.

     
  • Scott Tringali
    Scott Tringali
    2006-08-11

    • labels: --> Program
    • milestone: --> release
     
  • Thorsten Haude
    Thorsten Haude
    2006-08-11

    Logged In: YES
    user_id=119143

    Can't we detect the focus and fork to i-search in
    pasteClipboardAP?

     
  • Scott Tringali
    Scott Tringali
    2006-08-11

    Logged In: YES
    user_id=11321

    Bad idea. You're basically specially coding the logic
    according to widget layout, so that if another widget comes
    into play it will certainly be wrong.

    By removing the global menu accelerator it will work
    according to the rules that you want automatically.

    Menu accelerators don't have hiearachy or react to focus,
    but translations do.

    (Yet another reason why Motif menu accelerators are just awful.)

     
  • Thorsten Haude
    Thorsten Haude
    2006-08-14

    Logged In: YES
    user_id=119143

    Ok, I think I understand what you say. I will look around to
    learn more.

     
  • Scott Tringali
    Scott Tringali
    2006-08-14

    Logged In: YES
    user_id=11321

    Try removing the accelerator resource for the cut/copy/paste
    menu items, and see what happens.

    The downside is then if there are any other stray
    translations that override cut/copy/paste then it's possible
    to have no accelerator at all. Yay user-customizable X
    resources.

     
  • Thorsten Haude
    Thorsten Haude
    2006-08-21

    Logged In: YES
    user_id=119143

    It seems that the tiny patch attached solves the problem:
    Handling of the clipboard in the main text widget is still
    done via translations in source/text.c and the iSearch
    XmText probably has its own translations.

    I'm not sure what you mean with "stray translations". Would
    that require a misconfiguration (not necessarily the user's)?

     
  • Logged In: NO

    By stray translation, I mean that any X resource can be
    overridden by the user... correctly or incorrectly.

    "iSearch XmText probably has its own translations": See
    nedit.c, NEDIT_TEXT_TRANSLATIONS which apply the modern
    ^X/^C/^V to Motif text widgets. This should apply for ALL
    text widgets, not just the isearch.

    You may want to check CapsLock, NumLock, etc - I'm not sure
    offhand if the translation code handles all that properly.
    I had thought they were wired in the accelerators.

     
  • Thorsten Haude
    Thorsten Haude
    2006-08-22

    Logged In: YES
    user_id=119143

    - That's also the case for the accelerators.
    - Thanks, haven't found these.
    - I can't get it to fail with the three *Locks I have.

     
  • Thorsten Haude
    Thorsten Haude
    2006-09-30

    • priority: 5 --> 9
    • status: open --> open-fixed
     
  • Thorsten Haude
    Thorsten Haude
    2006-09-30

    Logged In: YES
    user_id=119143

    So, does anyone see any disadvantages for the proposed solution?

     
  • Thorsten Haude
    Thorsten Haude
    2006-10-17

    • status: open-fixed --> closed-fixed