remote-inspect causes an Inspector tool on the IDE side to inspect a client side object. The actual object in the Inspector is a remote object handle to the client side object. The Inspector tool itself is an ordinary Inspector tool, and there is nothing that makes it a "remote" tool in any way.
If connection is
nil (the default) or is not a valid connection,
remote-inspect first checks if there is a default connection that is enabled (by default, if there is a default connection then it is enabled, see set-remote-debugging-connection) and uses that, the same as the Debugger and Listener do. However, if there is no default connection enabled,
remote-inspect behaves differently from the Debugger and Listener, because there is no obvious time-point to close temporary connections.
remote-inspectalready opened a connection, then
remote-inspectuses it anyway (even though it is not enabled).
remote-inspecttries to open a connection using that spec. If this works, it uses the new connection, and unless it is configured as the default (setup-default non-nil in configure-remote-debugging-spec) it also records it for future calls of
With the default setting, the connection opening function (start-client-remote-debugging-server or configure-remote-debugging-spec) both configures and enables the default connection, so
remote-inspect will just use that connection (maybe opening it the first time).
An ordinary inspector can inspect a remote object because the generic function get-inspector-values has a method that specializes on remote object handles to invoke get-inspector-values on the client side and return the results. Thus
remote-inspect can work only if get-inspector-values works on the client side. which is not guaranteed when delivering an application at higher values of the level argument to deliver.
LispWorks User Guide and Reference Manual - 20 Sep 2017