Add _ as an alias for ans

[nch0w]

Here's an example:

>>> k_B N_A

 k_B × N_A

   = 8.31446 J/(K·mol)

>>> *298

  Parse error at position 1: Expected identifier

>>> ans*298

  ans × 298

   = 2477.71 J/(K·mol)

It is more natural (at least, for me) to type an operation after an expression as if the previous result is prepended to it. This is how normal calculators function. It's just an idea of something that could improve the efficiency of the calculator.

[sharkdp]

Interesting idea, thank you for the feedback.

I'm slightly afraid that this might cause confusion if somebody really made an error and forgot to put something to the left of an operator. I think I'd like every user input to be a valid mathematical expression.

I've been thinking about adding _ as a synonym for ans, which would at least allow us to save a few keystrokes:

>>> _*298

What do you think?

[nch0w]

Yeah, I think that would help. What about something like tab or shift+tab auto-filling "ans" when the console is empty?

[sharkdp]

Tab is already reserved for normal tab completion (Tab-Tab shows all possible commands, variables, etc. - for example).

By the way, often you can also use <up-arrow> to fetch the last input and append your * 298 part directly. Of course, this will fail if your previous input contains something like 3+4.

[sharkdp]

I have another idea. What about adding a shortcut (maybe Alt+. in analogy to the bash shortcut) that would paste the last expression into the current line (similar to <up-arrow>), but with parens around it. This would allow us to type 3 + 4, Enter, Alt+., * 298 in order to get

> (3 + 4) * 298

[nch0w]

I guess that would work. It wouldn't be the same type of efficiency I have in mind, though (I rarely find myself using alt + .) - the underscore method would probably work better.

Maybe some sort of setting that allows "experienced" users to implicitly add ans? That might help

[pigmonkey]

I have just begun to use insect, and was a bit disappointed to find that this implicit ans behavior was not supported. I then came here intending to ask if it was possible to define custom variables, so that I could map ans to _, as _ is what I am used to from using the Python interpreter as a calculator.

I understand the concern around the implicit behavior. My first preference would be some sort of flag that I could use to start insect in a way that would support the the implicit answer (-x for expert? -d for dangerous?), but if that is not attractive I would be perfectly happy with a _ alias for ans.

The Alt + . option is interesting. I often find myself using a calculator to chain together a long series of expressions. Seeing just the previous one isn't especially attractive, but seeing the whole chain may occasionally be useful. I would be doing something like 3 + 4, Enter, Alt+., * 298, Enter, Alt+., / 6. If that gave me just the last expression I don't think it would be useful:

> (ans * 298) / 6

But if it gave me the whole chain it might be neat:

> ((3 + 4) * 298) / 6

Obviously this is a contrived example, and in the real world the full chain would often be much longer, likely spanning multiple lines. I think I would still want a _ alias to avoid all the noise when all I care about is the next answer, not how I'm getting there.

[sharkdp]

I have just begun to use insect, and was a bit disappointed to find that this implicit ans behavior was not supported. I then came here intending to ask if it was possible to define custom variables, so that I could map ans to _, as _ is what I am used to from using the Python interpreter as a calculator.

I understand the concern around the implicit behavior. My first preference would be some sort of flag that I could use to start insect in a way that would support the the implicit answer (-x for expert? -d for dangerous?), but if that is not attractive I would be perfectly happy with a _ alias for ans.

I'd rather not add different modes. Let's add _ as an alias for ans.

[triallax]

I want to work on this, but I'm wondering about a couple things:

• Should _ be some kind of reserved syntax, i.e. creating a variable named _ is not allowed? I think that disallowing such a variable declaration is best.
  • If we reserve _ as special syntax, do we also disallow ans as a variable? Again, I think we should do that.
• Should _ be prettified to ans? Again, IMO, yes.

[sharkdp]

Should _ be some kind of reserved syntax, i.e. creating a variable named _ is not allowed? I think that disallowing such a variable declaration is best.

Yes, that sounds like a good idea.

• If we reserve _ as special syntax, do we also disallow ans as a variable? Again, I think we should do that.

👍

Should _ be prettified to ans? Again, IMO, yes.

Hm. I think it might confuse users if we do so?

[triallax]

Hm. I think it might confuse users if we do so?

Fair point.