Future of the emacs library

Hello everyone! I know there are a few emacs users out there, and I wanted to get an idea of what you all think about the future of the scel emacs library. A few weeks ago I put up a discussion PR on the repo but so far it has failed to generate any discussion. Please have a look if you’re interested in improving the SC emacs experience!

In a nutshell, I think it would be beneficial to decouple the emacs library from the supercollider distribution. There are several good package management options for emacs which probably didn’t exist when this library was first created.

My main hesitation is that linux users might be affected because scel is currently built by cmake and installed in site-lisp directory (for linux only). I’m hoping to get feedback from you fine folks on how disruptive of a change this will be and how much appetite there is for having a separate distribution. If we did make this change, would it be sufficient to provide install guidance in the release notes?

2 Likes

My main question about scel is, what is the current state of autocompletion and method templates? These are indispensable. I recall from some years ago that scel’s method autocompletion and argument templates were rather weak. One user had independently forked it and improved those features, but there was not a clear way to merge them back in.

I personally wouldn’t object to decoupling.

hjh

1 Like

what is the current state of autocompletion and method templates?

Autocompletion is ok for class and method names, but I’d like to integrate eldoc for better argument expansion. By method templates do you mean snippets? If so, I don’t think scel ships with any built-in but I have defined a few for myself locally and they would be easy enough to contribute back to the library. The trick there is deciding which ones are universally useful and which ones are just applicable to my own workflow.

Before taking on any other enhancements I thought it would be best to try to tackle the distribution problem, given my own struggles to install the mode. Having a separately distributed package would make it much easier for people to keep up to date locally and could encourage more contribution.

I just found the dev meeting schedule topic yesterday. Do you think the meeting would be an appropriate place to discuss and try to achieve consensus on this?

BTW, this is my first post here, and I realized I never introduced myself. How rude :slight_smile:

I’m relatively new to SC, been tinkering and learning for the last 6-8 months. Having a lot of fun with it. I’m a professional software developer and (very) amateur musician, not an audio engineer. I thought a good way for me to contribute would be through the emacs mode.

3 Likes

Hi @jxa
I’ve been using SC on emacs for about 10 years and I’d welcome any change to make it easier to get them working on a new machine. I still play on my 10 year old machine with the same configuration and pretty afraid to touch anything and break the whole config :smiley: I’m now using doom emacs on my new machine, but haven’t got it working yet, hence I still rely on my archaic yet reliable but untouchable setup :slight_smile:

If I can help with anything, or testing a new installation or changes, let me know. I’ll be happy to get a newer version working on my new machine :slight_smile:

@rukano thank you so much for weighing in! Your reply doubles my confidence that this is indeed a major pain point for people.

The PR has instructions for installing in doom emacs. It will install from my un-merged branch which is still a work-in-progress, but I’m using it successfully. I’m also using doom config so I should be able to help you troubleshoot any issues.

What OS are you on? If it’s linux or windows maybe you could give some feedback about the location of the installed binary, help, and extensions directories so I can add them as defaults.

1 Like

Hi, I’ll try it out! I’m on macOS, so I guess I won’t have much input for these… I still have to manage to get my emacs and my doom emacs configs in order, so I can start super colliding again in there… but thanks a lot for this, and giving the scel some urgently needed love. :slight_smile:

I didn’t mean snippets (which I guess could just use yasnippets or such).

Argument expansion is really necessary for it to be anything other than a toy editor ('k, maybe that’s a bit harsh, but IMO a code editor isn’t full-featured without it). I’ve been using SC for, oh, 19 years now and, with the thousands of method implementations, I’ve no shame in saying I can’t remember the argument signatures for all of them.

I quite like emacs and it would support a minor-mode for my live coding dialect, which I’d love to (find time to) implement. But it’s hard for me to commit to an editor that doesn’t look up method arg lists for me.

hjh

it’s hard for me to commit to an editor that doesn’t look up method arg lists for me.

It is currently possible to look up a method’s arguments. The function is sclang-show-method-args, bound to C-c C-m by default. It isn’t perfect but it’s better than nothing at all.

It should be possible, maybe even straightforward, to integrate eldoc so the method args show up in the minibuffer whenever you’re inside an argument list. That might be the next thing I start to tackle.

I would love also if a keystroke (tab, probably) could expand the list of arguments into the code. This is maybe what you’re saying too. I’ll need to do some more research to find out the best way to accomplish that.

1 Like

Ah, I forgot that.

But, I just tried it again and remembered the weaknesses of the current scel autocompletion and method argument help:

  • Autocompletion takes a partially entered keyword and present a flat list of left-matching keywords. In most code editors, you can narrow the list down further by continuing to type – e.g., in IDE, type LFP and the class name completion menu will present the options LFPar and LFPulse. Type a u, and the list reduces to only LFPulse, at which point you can hit return to accept. In sc-el currently, you have to switch gears mentally away from typing and toward menu selection.

    • IDE: L F P u <return>
    • scel: L F P C-c C-n <down-arrow> <return>
      It’s “there” but it’s less user-friendly.
  • Suppose I create an a = Rect(0, 0, 100, 100);.

    • Now I type a.move and C-c C-n. I get every method name beginning with move. There is no way to narrow the list down by class. The IDE at least presents some information about who implements the method selector.
    • OK, so I’ve got a.moveTo( and I do C-c C-m. The result is… nothing. Argument lists are not accessible for any instance methods, only for class methods. This means it’s an incomplete feature, as the vast majority of methods are for instances – so the feature works in a minority of cases.

At one point, someone had forked version of sc-el where argument look up worked like this:

  • If it could identify a class e.g. Rect.new(), it would automatically present arguments for the class method.
  • Otherwise, it would present a list of classes that implement the method selector. After choosing, it would show the arguments for that method.

Unfortunately I a/ can’t find that fork anymore and b/ SC has diverged too far from it so there isn’t a clean way to merge back to SC today.

I would seriously consider going back to sc-el if you could look up arguments for instance methods. Without that, realistically, it’s not quite usable for me. I actually like Emacs as an editor better than the IDE, but I need fully functioning completion.

That would be a very excellent spot of gravy!

~~

Installation (Linux): I’ve been building sc-el and installing to the default location /usr/local/share/emacs/site-lisp/SuperCollider – I’m afraid this is not sufficient for (require 'sclang) alone to find the module. I did have to (add-to-list 'load-path ...) – then, no problem.

For the help system, the README should probably say that (require 'w3m) is not necessary in a Qt-enabled build. That is, the README currently says you must require w3m “for the HTML help system to fully function” but Help.gui does fully function (and is bound within sc-el code!), outside of Emacs, so w3m is needed only for no-GUI builds.

hjh

While on the subject of scel wishlist – you can do string_ and it does update the emacs buffer’s contents, but you can’t selectString (an empty method stub exists, but no functionality), and I didn’t see a way to query the cursor position.

hjh

Hi! Glad that emacs interface is getting developers attention. I’m using sc-el for years (tried sc-ide, but looks like emacs is way of life). I didnt face problems with sc-el installation, but getting latest sc-el via melpa would be a good option.

Hi @vividsnow. Thanks for the feedback!

I’m guessing you’re on a linux machine since you didn’t have trouble with the install. If it isn’t too much trouble, would you mind sending me the results of C-h v sclang-system-data-dir? It would help me to have the value of this variable for the defaults in my PR.

Nevermind, I finally got it through my thick skull to install a linux vm. I’ll need it anyways in order to update the build scripts for supercollider.

On debian it happens to be /usr/share/SuperCollider.

sclang-system-data-dir is a variable defined in ‘sclang-vars.el’.
Its value is "/usr/local/share/SuperCollider"
  This variable may be risky if used as a file-local variable.
Installation dependent data directory.

(sc build from source)

Thanks I changed it to prefer /usr/local/share over /usr/share if it exists.

+1 on this! IMHO, any improvement would be welcome. I have been using Emacs for SC (on Linux) for a few years now. Learned to live with its shortcomings because I never had enough courage/time (or skill) to tackle it under the hood. At a first glance, I think that decoupling Emacs library from SC distribution would be a good thing. I tinker a little with elisp (I did an [ob-sclang](GitHub - djiamnot/ob-sclang: Orgmode Library of Babel implementation of sclang support in code blocks for orgmode) so this may be a motivation to dig deeper. I’m willing to test at least.

I am currently using Doom Emacs with Supercollider. I never got to get scel working, I found another package named sclang and sclang-extensions that works great out of the box and have been using it for about a year, now. Not sure if its the same package as scel, I’m relatively new to Emacs, and was using Vim before. sclang has documentation access both in Emacs itself or through an independent browser, which is pretty nice. And works better than the Vim plugin I was using before. I have nice class and method autocompletion and never had major issues with it.

This is cool, didn’t now about it. It shouldn’t be a problem to integrate it I guess. But, as I said, I’m relatively new to Emacs and not sure what I’m talking about.

I’m not sure I got this right, but my Emacs behaves like you’re describing your IDE does.

I really like using Emacs, specially for livecoding which is my main practice with Supercollider. So I really appretiate any improvements, and will be glad to help with feedback or whatever I can.