cygwin xemacs problems

[Eric S. Johansson]

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.