iceman_k
4th November 2005 14:55 UTC

NSIS naming conventions
I have noticed that there are no real naming conventions in NSIS.
e.g.,

!define "" "xyz"

is a valid command- the compiler accepts it.
However, there is no way to use this defined "symbol".
e.g.,

MessageBox MB_OK "${}"

displays "${}", not "xyz".

A couple of exceptions I have found are:

• A label cannot start with !,0-9,$,-, or +. (However, after the first character in the label name, anything is fair game.)
• A GoTo target cannot start with 0-9, $, or !. (ditto)

The absence of any real naming convention should normally not be an issue since I doubt that many people are creating weird names for functions, sections, labels, variables or symbols, but it still doesn't seem right.

Why do I bring this up? Well, I am developing an IDE for NSIS in Eclipse (see link in my signature), and it is really difficult to create a syntax highlighter/checker when the scripting language is so freeform.
Hence, I was wondering what were others' thoughts on this issue.

So... should there be a naming convention for NSIS?

kichik
11th November 2005 21:20 UTC

No one has any opinion on this?

iceman_k
11th November 2005 21:25 UTC

Apparently not. :D

Animaether
12th November 2005 00:45 UTC

My short answer: absolutely!
My long answer: however, I think most languages have notable exceptions like that, and a syntax highlighting engine would simply have to deal with those.

Personally I'd just exclude the use of quotes in a define, period.
E.g.
!define "foo bar" "hello world"
is perfectly legal - but it's pretty zany coding :)

----------

I've found other things to be far more concerning, really :)
(though they don't affect syntax highlighting, I think)

For example...

Why does RMDir, by default, not remove non-empty directories...
But DeleteRegKey, by default, does remove non-empty keys?
I.e. in the first instance you have to specify /r if you want it to delete the dir, even if it's not empty - and in the latter you need to specify /ifempty to make sure it's not deleting keys that aren't empty.
Might be semantics..

In terms of programming, however...
Why is it
StrCpy <output> <input>
and
SectionGetText <ID> <output>

I.e. why is the output sometimes the first argument, and sometimes the last ? (perhaps even things inbetween, haven't encountered that yet though)

I'm mostly used to scripting languages going :
<output> = <something>
e.g.
<output> = <input>
and
<output> = SectionGetText <id>
I understand NSIS uses a language more akin to C, but these (to me) inconsistent bits had my brain hurting in the beginning.

deguix
12th November 2005 05:27 UTC

No one has any opinion on this?

My opinion is the default - fix it! :D

Well, it's like in a DLL function call: you can't put spaces, but the compiler shows in the list of DLL calls plug-ins with spaces in their names... I could just use "CallInstDLL" to be able to call plug-ins with spaces, but there is no plug-in existant that has any spaces in their names, so it's not really that useful.

iceman_k
12th November 2005 05:44 UTC

The only issue would be backward compatability.
However, I don't think you would find many people doing something like this:

!define "${foo}" bar

This is a perfectly valid command- compiler accepts it. :D

pengyou
12th November 2005 11:51 UTC

Most of my installers use code like this:

!define "${foo}"
!define "${foo}" "${bar}"
!define "abc_${foo}_xyz" "${bar}"

because they use the MUI.

Animaether
12th November 2005 13:40 UTC

Does ${foo} in those instances contain spaces ?
If not, the quotation marks aren't needed ?

--

Overall the define stuff doesn't matter so much to me, if the only purpose of a fix would be to remove the non-issue (imho) of being able to define an empty var but not being able to refer to it :)

iceman_k
12th November 2005 14:08 UTC

Originally posted by pengyou
Most of my installers use code like this:

!define "${foo}"
!define "${foo}" "${bar}"
!define "abc_${foo}_xyz" "${bar}"

because they use the MUI.

Do you really define symbols like "${foo}"?
Or do you mean:

!define "foo"

Because if you really mean:

!define "${foo}"

then you should refer to it in code with "${${foo}}". Unwieldy at best.

What I mean when I said the compiler accepts:

!define "$foo}" bar

is that it accepts it even if "foo" has not been defined.
Essentially it allows you to define a symbol whose literal name is ${foo}.