[PD] Keyboard shortcuts for "nudge", "done editing"

[Marvin Humphrey]

On Thu, Sep 29, 2011 at 10:37:45AM -0700, Jonathan Wilkes wrote:
> Something I was thinking about for the future is a way to model keyboard
> input after the efficiency of 'vi' input.  When in "Edit mode" without yet
> editing the text of an object, one could use "h", "j", "k", and "l" to move
> the bounding box selection around in the patch.  Then bind "/" to duplicate
> ctrl-f, and you have a quick way to get around the entire patch without
> leaving home position.  (Maybe also bind "i" to enter text-editing mode, and
> "a" to enter text editing mode at the end of the object's text.) Then when
> in text editing mode or "Run mode", turn off these bindings.
> 
> The tricky part is figuring out the most efficient way to make/edit
> connections.  There is already "auto-connect" behavior for leftmost xlets--
> there needs to be a way to make a new connection, remove a connection, move
> a connection, and possibly make many-to-many connections like [select 0 1 2
> 3 4] with each outlet going to a new message box.
> 
> DesireData has a way to edit connections with the keyboard but I found it
> takes too many keystrokes.

Perhaps some of those features could be accommodated by having configurable
key bindings for the actions in question.  You don't have to provide default
bindings for all options, either -- just provide hooks, and let the user
create key bindings for the actions they care about.

Ever used Logic Audio?  I was quite fond of its key binding preferences
system when I used it a decade ago.

> > What's left is the basically irrelevant issue of how to insert a newline
> > that's going to be turned into a space later anyway.  My inclination is to
> > supply a patch which simply does not support the insertion of newlines.  If
> > that results in user confusion and support inquiries, a binding for
> > <modifier><return> can be added later.
> 
> That will result in user confusion, because when a message box with 
> semicolons gets instantiated it doesn't automatically get newlines added 
> until you save the patch and reopen it, while object boxes add the newlines 
> after instantiation.  Currently the discrepancy can be hidden by always 
> adding the newlines yourself with enter.

Ah, I see.

Source text:

    'eep; op; ork; ah-ah;'

Object after instantiation:

    eep;
    op;
    ork;
    ah-ah;

Message after instantiation:

    eep; op; ork; ah-ah;

Message after close and reopen:

    eep;
    op;
    ork;
    ah-ah;

So people who know this and don't want to close-and-reopen require some way to
enter newlines while editing text.

That seems like a bug worth fixing, but I don't feel strongly about
<shift><enter> one way or another, and if it solves a problem people care
about, fine by me.

Marvin Humphrey