[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

editor issues



    Date: 16 July 1987, 10:12:53 EDT
    From: Timothy Daly <DALY at ibm.com>
    Re:   pathnames, portability, ed, eval-when, compile-file, fasl files

    Is there any *portable* way to get the pathname of the file
    that is currently being compiled or loaded?
No.

    I would like to be able to edit the file when an error occurs
    (similar to turbo pascal).

    That is, if someone types:

    (compile-file ">daly>foo.lisp")

    and my parser detects an error, I'd like to

    (ed ">daly>foo.lisp")

I think you are trying to do too much that is properly part of the
"programming environment", and inherently not portable (at least with
the current Common Lisp design goals).

A more portable alternative would be to have a SYNTAX-ERROR condition
and an EDIT proceed function, or something like that.  This would
provide a portable interface to "editing errors", if that capability
exists.

    [...] but there doesn't appear to be a get-current-pathname function
    defined anywhere.  Does common lisp plan to add such a function
    when the 'debugging facilities' get expanded?

Well, this was mentioned before, but I believe it was by you.  Unless
someone comes  up with a formal proposal that convincingly argues that
this is well-defined and useful, then it won't be adopted.  Although
you may think the semantics are obvious, it may be difficult to
clearly define.  Consider that code may be consed up and compiled
without ever having been in a file, and that code can be read from
places other than files.

    Actually, I'd like to be able to incant

    (progn (ed ">daly>foo.lisp") (ed-search arbitrary-text-string))

I think that anything of this sort is doomed in the absence of a
standard editor/environment.  As a practical matter this isn't very
important either.  Given that the editor exists and provides the
functionality you want (which Common Lisp doesn't guarantee), you can
have a trivial (but non-portable) code file that implements what you
expect in terms of what is available.

    And, dreaming on, I'd like a definition of

    (ed-command arbitrary-but-implementation-dependent-editor-command)

    that is, I'd like the interface syntax to the editor command
    handler to be defined in a portable manner.  [...] I could create
    editor scripts and assign them to implementation dependent
    variables.

This is just silly.  Your code isn't any more portable just because
the first symbol in each form is the same.  Since Lisp supports
arbitrary functional values, you can stick "editor scripts" in
variables just as easily as arbitrary code.

  Rob