Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.soft-sys.andrew Subject: Re: Meta-X package Message-ID: <3756@auspex.auspex.com> Date: 26 Jul 90 01:39:59 GMT References: Organization: Auspex Systems, Santa Clara Lines: 69 > There is no provision for passing an argument to the function. > > There is no completion of the name while typing it in. > >I can't offer a solution to the second problem, though someone could >easily write a completion package that inspected that proctable. I looked at it sufficiently long to conclude that "easily" may not be the right word here; the whole completion stuff wasn't wonderfully-well documented and seemed a bit intricate. I'm sure it's doable; it just looked like more work than I was about to do. >To pass arguments you can utilize Ness. But can you pass arguments to a function in any EMACS by doing M-X? I tried it on both MicroEMACS and GNU EMACS (not the latest version) with functions that took arguments, and they prompted me for the argument, just as they would have had they been bound to keys. I assume they'd do the same with Bill's M-X package. >I do this by adding to my .atkinit the line > > addkey ness-dostmt \e\e view > >Then when I type ESC-ESC (or meta-ESC, I suppose) it prompts for Ness >statements. Any proctable function can be called and arguments passed. At least in Gosling EMACS, there is a "run a command" function, done with M-X, and an "evaluate Mlisp expression" function, done with something else. "ness-dostmt" seems more like the latter than the former. I don't see the inability to pass an argument to a function using M-X as a problem, for those reasons. It might be cleaner if proctable functions worked the way GNU EMACS functions worked; i.e., if the proctable entry included a spec for what arguments the function took, with M-X doing the prompting, rather than the code that implements the function doing so, and the arguments being passed to the function as, say, an array of unions or some such. This would centralize some of the user interaction, and shrink the code of some proctable functions; it would also, given code that could cope with the idea of a dialog box with more than one item, let Andrew prompt for a multi-argument function with a dialog box if the value of DialogPriority specified that the function in question should use a dialog box. Unfortunately, it could also require some rewriting of proctable function code. >For instance, to classify a message into a folder (am operation I don't >have in my messages menu) I can type ESC-ESC and give the command: > > messages_classify_by_name(currentinset, "foldername") > >Note that the dashes in the proctable names become underlines in Ness >and that the first argument should be currentinset because that is >expected by the proctable function. OK, I'll bite. Where's the code that prompts for a folder name if, say, you have "messages-classify-by-name" bound to a key or menu item, and you invoke it through a key sequence or menu item, rather than from Ness? The proctable function takes a "name" argument, but I didn't see any code in the function for "messages-classify-by-name" that does the prompting if there's a NULL argument, nor did I see anything in the proctable entry telling any common code to prompt for it. I must be missing something....