search

visit-dav / visit

VisIt - Visualization and Data Analysis for Mesh-based Scientific Data
https://visit.llnl.gov
BSD 3-Clause "New" or "Revised" License
438 stars 116 forks source link

Improve string interface in CLI by a) consistifying and b) using less strict matching logic #4620

Open markcmiller86 opened 4 years ago

markcmiller86 commented 4 years ago

Its difficult to code the string names of plots, operators, queries, expression function names, or other parts of the CLI interface where the user is expected to type in a literal string which names a feature in VisIt. Part of the reason for this is that for multi-word names, there is no consistency in use of captialization, spaces, underscores, hyphens, etc. So, even if you can remember the name of the thing, there is no uniform rule for how that string should be formatted and you wind up having to go look for yourself. So, we should fix the consistency there.

However, even with consistency in the formatting of those strings, it would help if the CLI wasn't using only absolute matching logic and instead did something like...

  1. try absolute match first,
  2. if the above fails, try lower-case only match
  3. if the above fails, try lower-case, removed spaces match
  4. if the above fails, try lower-case, removed spaces, hyphens and underscores match
  5. otherwise, the entered string is not recognized

Another option to consider is the use of constrained spell checking where the string is itself spell-checked and then common misspelling are factored out as well.

This would alleviate some tedium in coding CLI scripts.

The string-consistification policy effort alone would require consensus on formatting and then an extensive adjustment to the existing interface to correct all of the cases that don't follow the agreed upon policy. The above matching logic, however, I think would be sufficient to ensure old scripts with old strings would continue to work.

If there is no means for issuing a warning to the user about slight missepllings so they would know to eventually go fix it, it would also mean that over time, users could accumulate CLI code that is sligthly wrong and which we would need to support forever more. But, I think that possibility is worth the improved friendliness of the interface.

brugger1 commented 4 years ago

Another thought is to come up with a policy and then support that everywhere in addition to any existing cases are.