Hi everyone, is it possible to make the editor auto-complete the text, sort of similar to the way modern word processors do? BTW. I don't mean "dynamic completion", I'm aware of that one. Try it with a non US keyboard and you'll find it most inconvenient. In case the "auto completion" isn't already setable, I should think some of you clever guys out there have already come up with some code, care to share with the rest of us? Cheers Guenther
Unable to parse email body. Email id is 1449
Hello lispworkers, One can invoke the completion function for a text input pane by clicking the "?" button. Does any standard keyboard combination to do so exist on Windows? Is it possible to assign this gesture? -- Sincerely, Dmitri Ivanov www.ystok.ru
Unable to parse email body. Email id is 1461
Hello David, | ...snip...| | Possibly the Windows-compliant way to do it would be to use a menu | item with an accelerator. Then, the user can figure out what | non-standard key to use, because it appears on the menu. | ...snip...| | We will document callback-type :focus, though you could implement this | idea without it. Nice way, thanks. Unfortunately, does not work for text-inpute-choice, the subclass text-input-pane. -- Sincerely, Dmitri Ivanov www.ystok.ru
Unable to parse email body. Email id is 1474
Hello lispworkers,
I have the following piece of code in the file cc.lisp:
----------------
(defun %make-closure (x &aux y)
(lambda ()
(unless y (setq y (* x 1000))) ; long run
(1+ y)))
(defmacro cc (x)
`(funcall ,(%make-closure x)))
(defun test ()
(+ (cc 2) (cc 3)))
;(cc 3)
;(test)
----------------
When compiling this file with LWW 4.3, I have got the following:
**++++ Error in TEST:
Object #<interpreted closure (LAMBDA NIL (UNLESS Y (SETQ Y (* X 1000)))
(1+ Y))> is of type TYPE::INTERPRETED-FUNCTION which is not externalizable
to #<STREAM::LATIN-1-FILE-STREAM E:\Lisp\Projects\t_cc.fsl>.
; (TOP-LEVEL-FORM 2)
; *** 1 error detected, no fasl file produced.
;;; Compilation finished with 0 warnings, 1 error.
Is this a LW-specific problem or general CL issue?
The workaround could be not to compile the TEST function at all, but put
into a separate file and load from the .lisp source instead of .fasl.
However, leaving the function interpreted means macroexpansion occurring
every time it gets called, which is undermines the usefulness of the
closure.
Any takers?
BTW, is it possible to declare some function interpreted within the body of
the file being compiled?
--
Sincerely,
Dmitri Ivanov
www.ystok.ru
The problem is a general CL issue - function literals can't be dumped to
file.
The way your code is set up, the %make-closure function returns a
function literal which, ultimately, is embedded in the function test.
The following revision to %make-closure works since the macro returns
the function-creating form rather than the function itself.
(defun %make-closure (x)
`(let (y)
(lambda ()
(unless y (setq y (* ,x 1000))) ; long run
(1+ y))))
Hope this helps.
Regards
Guy.
In message <000001c39df3$3552d2e0$425702c3@digo>, Dmitri Ivanov
<divanov@aha.ru> writes
>Hello lispworkers,
>
>I have the following piece of code in the file cc.lisp:
>----------------
>(defun %make-closure (x &aux y)
> (lambda ()
> (unless y (setq y (* x 1000))) ; long run
> (1+ y)))
>
>(defmacro cc (x)
> `(funcall ,(%make-closure x)))
>
>(defun test ()
> (+ (cc 2) (cc 3)))
>
>(cc 3)
>(test)
>----------------
>When compiling this file with LWW 4.3, I have got the following:
>
>**++++ Error in TEST:
> Object #<interpreted closure (LAMBDA NIL (UNLESS Y (SETQ Y (* X 1000)))
>(1+ Y))> is of type TYPE::INTERPRETED-FUNCTION which is not externalizable
>to #<STREAM::LATIN-1-FILE-STREAM E:\Lisp\Projects\t_cc.fsl>.
> (TOP-LEVEL-FORM 2)
> *** 1 error detected, no fasl file produced.
>;; Compilation finished with 0 warnings, 1 error.
>
>Is this a LW-specific problem or general CL issue?
>
>The workaround could be not to compile the TEST function at all, but put
>into a separate file and load from the .lisp source instead of .fasl.
>However, leaving the function interpreted means macroexpansion occurring
>every time it gets called, which is undermines the usefulness of the
>closure.
>Any takers?
>
>BTW, is it possible to declare some function interpreted within the body of
>the file being compiled?
>--
>Sincerely,
>Dmitri Ivanov
>www.ystok.ru
>
--
* Dmitri Ivanov wrote: > By experimenting, I have found out that leaving the test function > interpreted will do because it macroexpands cc only twice while evaluating > the defun (though rather unbelievable). I think you need to describe what you're trying to do more carefully. A solution which only works when bits of the code are left interpreted or only works by calling the compiler at runtime is usually an answer to the wrong problem. --tim