Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Short circuit ambiguous REPL commands #90

Closed
weaversa opened this issue Sep 5, 2014 · 6 comments
Closed

Short circuit ambiguous REPL commands #90

weaversa opened this issue Sep 5, 2014 · 6 comments
Labels
feature request Asking for new or improved functionality
Milestone

Comments

@weaversa
Copy link
Collaborator

weaversa commented Sep 5, 2014

Cryptol> :s
:s is ambiguous, it could mean one of:
    :sat, :set

The previous version of Cryptol would select the 'most used' command (which is subjective, but still), rather that asking the user to try again. Here, the most used command is :set for :s. It would be nice to have this back again.

@kiniry kiniry added the feature request Asking for new or improved functionality label Sep 8, 2014
@kiniry kiniry added this to the Cryptol 2.1 milestone Sep 8, 2014
@TomMD
Copy link
Contributor

TomMD commented Sep 8, 2014

Whatever the preferred default might I suggest we have the defaults configurable by the user? An interface such as:

Cryptol> :s   // This is 'set'
Cryptol> :setdefault ("s","sat")  // Set prefix string 's' to expand to 'sat'
Cryptol> :s  // This is 'sat'

Should be just a simple lookup/insert in a map of defaults, which would be part of the REPL state. I expect these sorts of settings to become part of a .cryptolrc in the users home directory.

@weaversa
Copy link
Collaborator Author

weaversa commented Sep 8, 2014

I really like this idea. Also, I'm really looking forward to a .cryptolrc file.

acfoltzer added a commit that referenced this issue Sep 14, 2014
Reopens #94; the book talks about using :e to edit files, and having :exhaust in the command trie breaks this. We need to figure out a better way to disambiguate (#90)
@LeventErkok
Copy link
Contributor

Argh.. I really don't like this idea :-(

It's akin to weird aliases people put in their .shellrc files, whatever that .shell happens to be. They so get used to it, if they're using somebody else's session they're completely lost! (Happens to me all the time.)

This also means that you can't just ship someone a command file, since the "commands" they have might be aliased to something else.

Of course, this is a pet peeve. Sometimes too much configurability is not a good thing. (Compare the "linux" UI experience to the "Mac" one: Former is infinitely customizable, latter is a hell of a lot better.)

I actually prefer just starting to type, like ":s" and then hit tab until it disambiguates sufficiently. Is that too much to ask?

@weaversa
Copy link
Collaborator Author

"I actually prefer just starting to type, like ":s" and then hit tab until it disambiguates sufficiently. Is that too much to ask?"
So, that currently works just fine.

@kiniry
Copy link
Member

kiniry commented Sep 15, 2014

I, too, am not too terribly keen on an out-of-band .cryptorc . I'd rather everything be crystal-clear in the prelude and in modules. No bash- or LaTeX-like dependency hell for me, TYVM.

@kiniry kiniry modified the milestones: Cryptol 2.1, Cryptol 2.2 Sep 23, 2014
@acfoltzer
Copy link
Contributor

We now have the ability to specify multiple aliases for the same command, so for example we have [ ":s", ":set" ] to change settings, and [ ":sat" ] to run a SAT solver. You can see all the variants by doing running :help (or, now, :?).

Note that even though we added multiple concrete aliases, if you enter an unambiguous prefix you'll still get the full command, so :sa works for SAT.

These are compiled in, rather than being user-modifiable, which we decided was too much complexity for too little benefit. We are of course open to suggestions for what the various forms should be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Asking for new or improved functionality
Projects
None yet
Development

No branches or pull requests

5 participants