Re: Contributing xc.el to ELPA

On Friday, July 17th, 2026 at 7:21 PM, Stefan Monnier <[email protected]> wrote:

> 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).

Okay, I removed all the uses of shells and shell quoting and now give each task a `term-mode' buffer which runs the process directly. (For my own use I would prefer `eat-mode' but as it's in NonGNU ELPA, I decided to go with `term-mode' for now. I could give eat a similar treatment to Treemacs and provide `xc-eat.el` for the eat enjoyers, if you think that's an appropriate pattern to continue.)

> 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.

I added forward declarations for the treemacs functions I use, and used your suggested macro to wrap the treemacs macros. I ran `emacs -Q' and was able to load and byte-compile xc.el and xc-treemacs.el without errors, so I am hopeful that this concern is addressed.


I've pushed a new minor version update to Codeberg responsive to feedback and incorporating your patches. I appreciate your time and attention!

Cheers,
Ryan