[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: over-engineered (and under-standardized) inferior interfaces
From: |
Jorgen Schaefer |
Subject: |
Re: over-engineered (and under-standardized) inferior interfaces |
Date: |
Thu, 21 Aug 2014 23:21:58 +0200 |
On Thu, 21 Aug 2014 16:29:35 -0400
Stefan Monnier <address@hidden> wrote:
> prog-proc-mode
First of all, this is an excellent initiative. Thank you.
> (define-key map [?\C-c ?\C-l] 'prog-proc-load-file)
> (define-key map [?\C-c ?\C-c] 'prog-proc-compile)
> (define-key map [?\C-c ?\C-z] 'prog-proc-switch-to)
> (define-key map [?\C-c ?\C-r] 'prog-proc-send-region)
> (define-key map [?\C-c ?\C-b] 'prog-proc-send-buffer)
> ;; FIXME: Add
> ;; (define-key map [?\M-C-x] 'prog-proc-send-defun)
> ;; (define-key map [?\C-x ?\C-e] 'prog-proc-send-last-sexp)
Just some comments on the default bindings. I understand these are the
historically-available ones, but I do feel that if we create a new mode
like this, it might be worthwhile to rethink them.
With the availability of an "active region", I think it would be nice
to consolidate send-buffer and send-region to a single binding. If
there is an active region, send the region; if not, send the buffer.
Using a nice binding like C-c C-c for a somewhat less-common command
like "compile the current file in the REPL" (as opposed to using M-x
(re)compile) seems like a waste.
So I'd suggest using C-c C-c for a new prog-proc-send-region-or-buffer.
I'm also unsure about using up too many C-c C-X bindings in this minor
mode; the major mode that activates it won't be able to easily override
those bindings locally, so it might be a good idea to be a bit more
conservative with the default bindings, providing the commands but not
the bindings for the less common use cases (load, compile, region,
buffer).
That would leave us with a default set of C-c C-c
(send-region-or-buffer) and C-c C-z (switch to repl, starting it if
necessary) (*) which seems like a nice default set to me that modes can
extend with options that make sense for them.
(*) And C-M-x, which I think is a nice addition for most modes and also
does not conflict with other mode bindings and uses.
Regards,
Jorgen
Re: over-engineered (and under-standardized) inferior interfaces, Sam Steingold, 2014/08/22
Re: over-engineered (and under-standardized) inferior interfaces, Elias Mårtenson, 2014/08/31
Re: over-engineered (and under-standardized) inferior interfaces, Andreas Schwab, 2014/08/21