Re: Contributing xc.el to ELPA

Stefan Monnier <[email protected]>
Newsgroups gmane.emacs.devel
Message-ID <[email protected]>
> ## shell usage
> I see you replaced `call-process-shell-command' with `call-process' in one
> place, which is fine, but you left `async-shell-command' in another
> place. Are you hoping I'll find a way to remove that usage of a shell?

I removed use of the shell where it seemed easy to do.  For the
`async-shell-command` case it seemed harder, so I left it as is.
If you can get rid of the use of a shell that's good, but it's not
super important.

> Many common tasks invoke `git' or `ssh' which may prompt interactively
> for input, so having a shell in those cases is handy.

The shell is not actually involved in that prompting (the use of a pty
rather than a pipe for the connection to the underlying process
(i.e. the `process-connection-type`) is probably more important, along
with the use of something like a `comint-mode` to read the user's
replies and send it to the process).

But as I said above, there's nothing evil about using a shell.

It's just an additional layer (thus extra resource usage) and comes with
security/correctness issues if you're not careful to quote your
arguments, but it's a minor concern.

> ## treemacs-treelib availability
> You noted that `(require 'treemacs-treelib)' will fail to compile if it's
> not installed. I use three functions and three macros from treemacs-treelib,
> and xc-treelib.el is only relevant or useful for users with treemacs
> installed. Would you recommend I should move that functionality out into
> another package entirely, or is there some pattern I can use to prevent it
> from being compiled on systems without treemacs available?

The ELPA system doesn't provide an easy way to mark some files as
dependent on some extra package.  You could move it to separate package
but given the size of those packages it doesn't seem worth the trouble.
What you can do is mark the file as `no-byte-compile: t`, or you can use

    (require 'treemacs-treelib nil t)

and then either avoid the use of macros somehow (not sure if
treemacs-treelib makes that easy), or otherwise wrap those macro calls
such that they're skipped when `treemacs-treelib` was not loaded.

E.g. you could do

    (defmacro xc--if-macro-fboundp (name then &rest else)
      "Execute THEN if macro NAME is bound and ELSE otherwise.
    Essentially,
    
      (xc--if-macro-fboundp name then else...)
    
    is equivalent to
    
      (if (fboundp \\='name) then else...)
    
    but takes care of byte-compilation issues where the byte-code for
    the latter could signal an error if it has been compiled with
    emacs 24.1 and is then later run by emacs 24.5."
      (declare (indent 2) (debug (symbolp form &rest form)))
      (if (fboundp name)             ;If macro exists at compile-time, just use it.
          then
        `(if (fboundp ',name)               ;Else, check if it exists at run-time.
             (eval ',then)                  ;If it does, then run the then code.
           ,@else)))


    (xc--if-macro-fboundp the-treemacs-macro
      (progn
        (the-treemacs-macro ...)
        (the-treemacs-macro ...)
        (the-treemacs-macro ...)))


=== Stefan
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.