#530 unexpected copy/paste behaviour

Program (402)

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


  • Thorsten Haude

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

    Scott Tringali - 2006-08-11

    Logged In: YES

    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

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

  • Scott Tringali

    Scott Tringali - 2006-08-11

    Logged In: YES

    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

    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

    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

  • Thorsten Haude

    Thorsten Haude - 2006-08-21

    Logged In: YES

    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)?

  • Nobody/Anonymous

    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

    - 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

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

  • Thorsten Haude

    Thorsten Haude - 2006-10-17
    • status: open-fixed --> closed-fixed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks