On 14 Jul 2016, at 21:33, Jacob Carlborg wrote:

1. Make a separate call to the dialog command. This is not documented, at least not in the documentation for the popup Ruby method.

Making a 1:1 copy of the DIALOG API in ruby has never been my desire, in fact, I personally prefer to use DIALOG directly, even from ruby, as DIALOG itself provides a stable and straightforward API.

The ruby wrappers was born back when the first version of the Dialog plug-in was written, which had a more complex API, so back then, there was justification, but not really with v2 of the Dialog plug-in.

Unfortunately once things have been added to the support library, it is extremely difficult to remove, because it is effectively public API.

2. Setup the mapping of a symbolic name to a path

Don’t you need some sort of mapping? Or does your completion code deal in absolute paths to images when it classifies the candidates for the completion menu?

3. There also seems to be a risk of having conflicting names between different bundles and possible the application itself

This was intended, similar to how we provide Warning, Note, Error, etc. for the gutter, it would not be unlikely to provide constant, variable, method, classMethod, etc. as standard images for the pop-up.

When it comes to efficiency the register command already caches the NSImage objects […]

Yes, the register command adds the image to the cache using their symbolic names, and the pop-up menu definition uses the symbolic names to reference the images.

But this indirection is what you are arguing for removing, so I don’t get this part.

It would also make the dialog command simpler because the register command could be removed.

The register command was also intended to be usable before loading nibs (with images).

(sorry for the rant).

As I said: the command could be updated to automatically “register” any image provided as a full path (possibly with its hash value to facilitate re-use of images) so while you felt it necessary to rant is beyond me.