Bug 253981 - [EditorMgmt] [GlobalActions] Emacs key bindings: add window-related Ctrl-x 2, Ctrl-x b, Ctrl-x o, amd related
Summary: [EditorMgmt] [GlobalActions] Emacs key bindings: add window-related Ctrl-x 2,...
Status: ASSIGNED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: IDE (show other bugs)
Version: 3.4.1   Edit
Hardware: All All
: P5 enhancement with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2008-11-05 14:57 EST by Daniel B. CLA
Modified: 2019-09-06 16:17 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel B. CLA 2008-11-05 14:57:23 EST
Build ID: M20080911-1700

Steps To Reproduce:
N/A (enhancement request)

More information:
It would be helpful if Eclipse's Emacs key binding mode 
supported standard Emacs key bindings for command commands
to switch between windows and buffers.  Key ones are:

- "Ctrl-x 2" (split window), presumably creating a new editor
  stack and opening a new editor (on the some file in whose 
  editor the command was issued)

  (This would directly support editing/seeing different
  parts of the same file at the same time in Emacs' keep-
  your-fingers-on-the-main-keyboard-mode.)

- "Ctrl-x b" (switch-to-buffer), presumably first presenting
  a list of the files currently open in editors in any editor
  stack and then editing the selected file in the current
  stack (possibly opening a new editor if there's not 
  already an editor for that file in the current stack).

  (This would support seeing/editing two different files.)


- "Ctrl-o" (other-window), switching focus to current (top-most)
  editor in the next stack (being no-op if there is only one
  stack).

  (This would support jumping back and forth between editing 
  two simultaneously-displayed files.)


- "Ctrl-x 0" (that's a zero) (delete-window), presumably 
  deleting the current editor stack after moving its editors 
  to the other (or next) editor stack (being no-op when there's 
  only one editor stack).

- "Ctrl-x 1" (delete-other-windows), presumbly deleting editor 
  stacks other than the current one, after moving all their 
  editors to the current stack  (being a no-op when there's 
  only one editor stack).

Note that Eclipse's Emacs mode already supports kill-buffer on 
the current buffer, "Ctrl-x k" and then "Return" in Emacs, 
although Eclipse doesn't quite implement it consistently with Emacs.
Comment 1 Mark Feber CLA 2009-06-16 18:54:13 EDT
Most of this behavior is now available in the current release of the Emacs+ plugin. [Ctrl-X 0 will be added soon).
See:
http://www.eclipseplugincentral.com/modules.php?op=modload&name=Web_Links&file=index&req=viewlink&cid=1442

The relevant portion from the doc reads:

Split window behavior - Adapt the Emacs notion of window splitting to the
eclipse editor stack

    * Split Horizontally (Ctrl-X 2): Split the editor stack horizontally and
      put the current editor below the others
          o When the split editor preference is checked (default), the current
              editor is split and placed below itself
    * Split Vertically (Ctrl-X 3): Split the editor stack vertically and put
      the current editor beside the others
          o When the split editor preference is checked (default), the current
              editor is split and placed beside itself
    * Join Window (Ctrl-X 1): Join a previously split editor window to the 
      (upper left) editor stack
          o When the split editor preference is checked (default), duplicate
              instances of the editor are closed

Window navigation - 

    * Other Window (Ctrl-X O): Navigate to the previous editor window
    * Backwards Other Window (Ctrl+U Ctrl-X O): Navigate to the oldest 
      previous editor window
    
BTW, this bug is a close relative of: https://bugs.eclipse.org/bugs/show_bug.cgi?id=8009    
Comment 2 Boris Bokowski CLA 2009-11-17 13:02:13 EST
Remy is now responsible for watching the [EditorMgmt] component area.
Comment 3 Eclipse Webmaster CLA 2019-09-06 16:17:56 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.