[climacs-devel] Encountering a bug after C-x C-f

[Sean Champ]

On Thursday 20 July 2006 05:52 am, Christophe Rhodes wrote:
>
> It seems likely to me that you are using inconsistent sources.  Have
> you checked out CVS HEAD of both ESA and Climacs?  If not, try that
> combination.

The build in which I'd encountered the issue had been made with most-recent 
checkouts from the HEAD for each of McCLIM, ESA, Climacs, and felxichain. 

I had built Climacs before updating my local copy of ESA. After checking-out 
the CVS head, then I restarted the image, and had ASDF build Climas with the 
new ESA  Though I had not watched the compilation process, but I am sure that 
ASDF would have ensured that Climacs was fully rebuilt, then, on top of the 
new ESA codebase.

Looking at climacs.asd, it looks like there should be nothing that wasn't 
rebuilt on the new ESA.

I'll have to clear-off my desktop, dig into a session of walking back along 
how it happend.

---

I suppose that this would belong in a different thread of mesages, but it is 
related, on that I will certainly be getting familiar with the McCLIM 
codebase, while trying to find out how that issue came to be. 

The matter, I mean: Upon noticing that CONS typed values are used in part to a 
represent of Climacs minibuffer commands, and while I am not bothered at 
that, whatsoever -- a specially formatted CONS works, as a data structure -- 
I hope to propose: The possibility that funcallable instances might be 
considered, as for how such might be applicable for the representation and 
execution of CLIM commands. 

(I know, it's an abject suggestion, there. After I'll be more familiar with 
the codebase, I might be able to determine, to more certainty, if and how it 
may be feasible.)

Like, maybe in something of an analogue to the Emacs #'interactive function: 
Given anything (e.g. a CLIM gadget? - and I am not yet much familiar with 
CLIM - or the minibuffer) any interface objects that would be used for 
'reading' input (i.e. parameter, argument) values to a  minibuffer command , 
some objects for the facilitation of such might be referenced from within an 
interactive-command object. (I'm not yet enough familiar with CLIM, either, 
as to make an example, there, but it seems that it could be posisble.)

(Maybe it could be actuated on command-function argument types, the means 
whereby an input value would be read for a CLIM command, or a means whereby a 
defaulted, input interface would be selected. e.g. if the parameter would 
have to be of type PATHNAME, then a file-selection dialogue could be 
presented. To implement this, it might involve some implementation-specific 
code, e.g. using the CMUCL/SBCL CTYPE mechanism)

Continuing with this proposal:

Once the input interface (?) would be referenced in an interactive-command 
object, then, There could be defined a mechanism in climacs, as for how the 
input interface would be activated on an interactive-command object, and how, 
parameters extracted from that interface, as upon the execution of the actual 
'command function'.

(I would like to reiterate, I'm not sure of how the proposal would be worked, 
in the code. I hope that I will have managed to have become more sure about 
it, as after I'll be more familiar with the McCLIM and Climacs codebases. I 
consider that it could be worth it, to have brought the matter to suggestion, 
firstly.)

I'd be glad to hear of any responses on the proposals, above.

Thank you,

--
Sean