Insert constant's name instead of value

[Pol Welter]

Currently clicking a constant just pastes the value of said constant into the editor.

This workflow hinders usability (the user has to choose the constant from the list), and quickly renders the editor field very messy.

We do have a better way to handle this: just treat constants as any other builtin variable (such as pi). Clicking on 'Elementary charge' in the constants widget should not insert 1.60217653e-19, but elem_charge (or similar), which would then evaluate to 1.60217653e-19.

This gives us the power of the autocomplete feature, and saves the user's overview of what those funny numbers actually represent.

[Helder Correia]

Thought about it long time ago. The problem is that we'd have to create a built-in reserved variable for each constant that already exists and will exist. There's quite a lot of them, and the tendency is to increase very fast. Also, each user works typically with a small subset of constants (physics, astronomy, chemistry, etc). It's easy enough for each user to assign their own name to those frequent values. Again, not against the idea, but we need to think about the details above.

[Pol Welter]

Are you concerned about performance? We are using a QHash for storing variables, which is very fast. Also, I couldn't care less about the 1 meg of RAM i'd need to sacrifice. If anything, we might see a (barely noticeable) delay when starting up SpeedCrunch.

Or are you worried about cluttering the namespace? This might be solved by choosing fairly long and descriptive names, such as gas_constant instead of R. Or make them writeable.

Long names is also what I had in mind for unit names; call them meter, kilogram, etc. Let the user create shorter names like m, or kg.

Still, for me long names are infinitely better than simply a number.

[Helder Correia]

Not performance, not even namespace so much, but rather required manual work on me or some contributor :) Again, I'm in favor of this, but also think users can easily create their variables with their favorite localized names from their few frequent constants.

[Pol Welter]

Hmm, localization is actually a deal breaker. Hadn't thought about it earlier.

Even if we did manage to localize the constant names, the user's history would break as soon as they switch language, and inhibit them to share their saved session with their colleagues using a different language.

Same goes for unit names btw (and those we have to localize).

[Helder Correia]

Not a deal breaker. We don't localize function names either (and we shouldn't localize units). That's a development/maintenance nightmare that is only worth doing in Excel or similar. I just said that if we leave the name assigning task to the user, she can even "localize" it.

[Pol Welter]

I like this. Basically follow the same approach as programming languages; keywords such as if or begin aren't localized either, even if the IDE might be.

Good call.

Now that you mention it: I hate the translated function names in Excel :P

[Johannes Lange]

Hey! I also think this would be useful. But concerning namespace pollution I'd suggest using some escape character like many CAS or scripting languages do (e.g. $R or %R).