#953: Extend macro list

[vzhukovs]

This PR extends existed list of macros, by adding new ones.

Related issue: #953

Created new macros to provide various information from basic part.

It includes:

${editor.current.file.name} -- Currently selected file in editor with context
${editor.current.file.path}  -- Absolute path to the selected file in editor with context
${editor.current.file.relpath} -- Path relative to the /projects folder in editor with context
${editor.current.project.name} -- Project name of the file currently selected in editor with context
${editor.current.project.type} -- Project type of the file currently selected in editor with context
${explorer.current.file.name} -- Currently selected file in project tree
${explorer.current.file.path}  -- Absolute path to the selected file in project tree
${explorer.current.file.relpath} -- Path relative to the /projects folder in project tree
${explorer.current.project.name} -- Project name of the file currently selected in explorer
${explorer.current.project.type} -- Project type of the file currently selected in explorer
${server.<name>} -- Returns protocol, hostname and port of an internal server
${server.<name>.protocol} -- Returns protocol of a server registered by name
${server.<name>.hostname} -- Returns hostname of a server registered by name
${server.<name>.port} -- Returns port of a server registered by name
${workspace.name} -- Returns the name of the workspace

@vparfonov @ashumilova @azatsarynnyy review it, please.

[benoitf]

IMHO
${server.*} and ${workspace.*} should be handled server side

[vzhukovs]

We can resolve this information on the client and also this is the only one way to do this at the moment.

[vzhukovs]

Later, when we'll have mechanism to resolve it on server side, we'll move it. Maybe.

[benoitf]

I don't see why it is the only one way as you're bringing new code to handle it, this code could be added on server instead of client

[ashumilova]

+1
@benoitf for the server side command macros - will discuss how better to implement it and will create an issue.

[vparfonov]

I think we have separate issue on your idea @benoitf #2151

[benoitf]

@vparfonov yes but on this issue it's more how to bring custom resolver by prompting the user
my concern is that a command definition inside a workspace is shared by all clients and then some properties that are only related at the server side (like mapping of ports, workspace info, etc) could be resolved for all clients by the server (and not having each client solving the properties on its own as at the end it may have different result)

[codenvy-ci]

Build success. https://ci.codenvycorp.com/job/che-pullrequests-build/213/

[tolusha]

@vparfonov @vzhukovskii
Is there any way to show the whole list of macros for user ?

[azatsarynnyy]

javadoc with author is needed here

[vzhukovs]

Fixed

[vzhukovs]

@tolusha at this moment - no. But we can do the same as for key binding has done. Dedicate window with table of registered bindings. For example.

[azatsarynnyy]

javadoc with author is needed here

[vzhukovs]

Fixed

[azatsarynnyy]

+1 but can't understand what does it mean - macro provider

[vzhukovs]

Provider for macros

[tolusha]

@vzhukovskii Could you pls create the issue, otherwise we will forget it ^)

[codenvy-ci]

Build success. https://ci.codenvycorp.com/job/che-pullrequests-build/215/

[vparfonov]

not sure we are rely need this abstraction

[vzhukovs]

Removed

[vparfonov]

not sure about Abstract*Provider's but other ok,

need ok from @benoitf

[codenvy-ci]

Build success. https://ci.codenvycorp.com/job/che-pullrequests-build/218/

[TylerJewell]

@vparfonov @vzhukovskii - question for you. Is there any way we could add one more macro. It would be ${property.<name>} where <name> is the name of a property from che.properties file? This would allow for scenarios where a user could look up the value of a property that is in the standard list OR they could provide a custom property in che.properties.

For example:

# che.properties
my.custom.property=hamburgers

# In the macro:
${property.my.custom.property}

If this is something that requires server-side behavior, then I understand - let's add it into the issue tracking the movement of macros into the server.

[vzhukovs]

@TylerJewell it requires server side modification. I think, it would be better to do this with the issue tracking the movement of macros into the server.

[JamesDrummond]

@TylerJewell Custom properties will help bring in useful information about the host. Helpful for docker commands run in the host if it is possible.

[m1L31s]

Are those macros working?

${server..protocol} -- Returns protocol of a server registered by name
${server..hostname} -- Returns hostname of a server registered by name
${server..port} -- Returns port of a server registered by name

[vzhukovs]

Hi @m1L31s! At this moment only ${server.<servername>} only work. Those three macros have already unsupported.