If you map search to caps-lock you should map some other key to search.

There's another issue on the rapid toggling of caps-lock, but I don't have the bug# handy.

"If you map search to caps-lock you should map some other key to search"

Then don't you have to give up a commonly used key in exchange? 

I can't imagine giving up any of these for Search: Ctrl, Alt, Backspace and Escape. Feels rather boxed in...

abodenha@chromium.org, I can't remap another key without losing even more shortcuts.  And I filed the other bug report. :)

To clarify:

- I can't remap Backspace because I have to be able to easily correct text.
- I can't remap Ctrl because I have to be able to copy and paste easily. (Anyone remember iOS 1.x when you couldn't copy/paste?)
- I can't remap Alt because it's needed for various shortcuts and by SSH/mosh.
- I can't remap Escape because I use it for SSH/mosh.

In theory, Alt and Escape are redundant when using SSH, but some programs keep track of the delay between keypresses to differentiate them.

It's really a shame that all these keys are necessary for development, but it's not something that can be changed overnight.  I'm in favor of eliminating the need for Caps Lock, but, for the time being, the need still exists in some professions.

One way to resolve this would be to map left and right modifiers separately, or to provide an option to map one of the function keys to search.  The latter could be a simple dropdown.  Heck, I wouldn't even mind if I had to use the shell.

Reactivating this bug since it's a potential adoption blocker for developers.

A bit of extra context.
https://productforums.google.com/forum/#!topic/chromebook-central/YvPRHT-9TrE

Another use case is Googlers using Cider on a Chromebook.

The Search key is required for certain system shortcuts. If you need CapsLock, it is recommended that you choose another key to map to Search.

How about taking a step back and reading the context? The bug talks about the physical key marked with the Search symbol, not the "Search" action. Clearly, since remapping is offered in the first place these are not the same.

Is there a technical reason why the physical key, which almost universally is used as CAPS LOCK, can't work as Fn keys modifier regardless of the action mapping? The suggestion to map another key to Search is not really helpful (if you disagree please try it first yourself, and report back if you can find usable permutation of keys)

Remapping a key effectively makes it a different key. For example if you remap search to ctrl, pressing the key will generate ctrl events not search. 

Understood, thanks for the explanation. But this is an implementation
detail that the end users likely don't care about (and they should not).

The problem here is that there's a painful conflict between two features:

1. The ability to remap some of the keys
2. The ability to emulate Fn keys

Mapping the physical key located where the traditional CAPS key is located
to CAPS is a supported feature (and sounds like a reasonable thing to do)
so it should not require or result in losing the ability to emulate Fn keys.

To emulate Fn keys, users need Search. If Search was mapped to something else, then they lost that key until they map something else to it. I don't think we can do anything here.

I understand that certain design decisions might make this an inconvenient
change, more complex that it may seem.  But that's different than to say
"we can't do anything here".

It make be worth taking a step since being too close to the implementation
likely skews the perspective: when I say this is an implementation details
what I mean is that there's nothing that precludes a different
implementation which satisfies all the requirements:

Let's call the physical key code Pkey and the software mapped key Skey and
ChromeOS allows custom mappings for some of the keys  (ex. Pkey{CAPS} ->
Skey{Search} by default)

1. Current implementation: Skey{Search} + Skey{N} -> Skey{FnN}
2. Alternative implementation: *Pkey{CAPS}* + Skey{N} -> Skey{FnN}

In the second implementation it's irrelevant what the soft mapping is.
Again, I can see some inconvenient details in changing the implementation
but as customer advocates we can't say "it can't be done".

At most we can *acknowledge that the current behavior is broken *and say
"sorry, it's too hard to make the change at this time" (and hopefully keep
the bug active as a reminder to revisit this)

afakhry@ to confirm what to do next

It might be of benefit to all involved if it were easier to remap just one of the shift/ctl/alt keys instead of always remapping both.

This would make an additional 3 keys available for assignment.

Just sayin...