On 2/8/2011 4:06 AM, Stephen J. Turnbull wrote:
Eric S. Johansson writes:
> Control means there is a task specific interface in place. For example,
> something like trace route would need some way of incrementally building the
> commands, memorizing it with a specific name and then an argument which
> translates a name to a hostname.
I assume you can access menus?
One thing that's been on the agenda for a while is a menu editor. A
Lisp menu is just a sequence of sequences, something like
(defconst default-menubar
;; This is backquoted; a lambda with a preceding , will be byte-compiled.
`(("%_File"
["%_Open..." find-file]
("Open with Specified %_Encoding"
:filter
,#'(lambda (menu)
(coding-system-menu-filter
(lambda (entry)
(let ((coding-system-for-read entry))
(call-interactively 'find-file)))
(lambda (entry) t)
t)))
"-----"
["%_Save" save-buffer
:active (buffer-modified-p)
:suffix (if put-buffer-names-in-file-menu (buffer-name) "")]
("%_Edit"
["%_Undo" undo
:active (and (not (eq buffer-undo-list t))
(or buffer-undo-list pending-undo-list))
:suffix (if (eq last-command 'undo) "More" "")]
"----"
["Cu%_t" kill-primary-selection
:active (selection-owner-p)]
["%_Paste" yank-clipboard-selection
:active (selection-exists-p 'CLIPBOARD)]
["%_Delete" delete-primary-selection
:active (selection-owner-p)]
)))
This is very complicated, it's a selection from the main menubar code.
It doesn't get more complicated than that. :-) But Lisp is very good
at editing structures like this, and we should be able to create a
menu editor that navigates the menus just like selecting a command.
It would be substantially easier if it didn't need to handle features
like:active and :suffix.
the trick is coming up with a simpler notation the way I did with akasha (speech
recognition friendly web framework). Personally, I like a spatial specification
of menu hierarchy
view
Shrink window to fit --- C-x -
( Function argument argument argument)
narrow
Narrow to region --- C-x n n
( Function argument argument argument)
Narrow to page --- C-x n p
( Function argument argument argument)
go to line -- M-g
( Function argument argument argument)
Is something off the top of my head. This notation allows you to control the
menu hierarchy and associate a function with each argument. It may be too
simple. But it certainly is something one could speak and edit within xemacs
given Select-and-Say functionality.
XEmacs also has a "keyboard macro" facility, but it could
use some
improvement for your purposes.
True but it's okay. I really don't mind keeping all of the speech control
outside of XEmacs and minimizing the control interface to the essentials.
I'm not sure how that would work. XEmacs does have TTY and
stream-oriented consoles (it's painful, but you can actually work with
XEmacs using only stdin and stdout ... it's actually not unreasonable
for playing "doctor" or "dunnet"). Maybe the stream-oriented
console
could attach to the voice recognition.
Some form of RPC using Emacs as a server? Maybe a hack on the the client
interface? Yes, I am going to push heavily on "interesting solutions". Please
don't kill me. I have some stories I want to write. :-)
Here's how I think the action should go:
I say "new method name"
The system should gather all of the method names associated with the object from
which you've created the instance. That list of method names and the given
method name should be handed to an external program (how? Really fine magic).
The external program operates on the data and passes back the new method name.
The editing environment replaces the old method name with the new method name.
We are done
In the Windows environment, and I suspect most GUI editors, moving the data from
one application context of the other happens using the paste buffer. It also
counts on another side effect which is the act of pasting text replaces the
selected region. In our environment, we will need to do a kill region and then
inject the new name. This raises the question of maybe after we do it kill
region, we should inject the new name into the kill ring and then yank it back
into the buffer.
In our context, we obviously need to be a little more sophisticated like a
message passing mechanism or a return before done RPC mechanism. I haven't
figured out if a simple call and return will work or if it's necessary for the
application to query Emacs for additional things about the program state. I
think we can do most of what we need one way if the language mode is smart about
names and their relationships.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta