Re: CaSe-IndepeDent Menu SEARches?

[Michael Davidsaver via Core-talk <core-talk at aps.anl.gov>]

On 2/4/21 1:29 AM, Ralph Lange via Core-talk wrote:
> In the good old times,
> we used to have a static DB parser that was used to provide a "lint" tool for databases. (My mourning of the loss of that feature was largely ignored.)

https://github.com/epicsdeb/pypdb/blob/master/dbdlint.1.txt

However, there is currently no good way to wire this into
the make process.  In my mind, this should run as a "build"
step prior to installing .db files.  So that a typo will
be caught before any changed files are copied.

> In such a tool, I would support and encourage all kinds of intelligent hints for improving databases, showing similar options for typos being the simplest example.
> (What about "Engineers that used the calcout record also often use the seq and compress records.")
> 
> "Fixing" bugs on the fly? Rather not. Large blocks of explanations and suggestions on the IOC console? Rather not.

Fair enough.  The are certainly diminishing returns for longer error messages.


I find myself wondering how difficult it would be to customize autocomplete
for a text editor like Kate (my usual editor for .db files).


> Cheers,
> ~Ralph
> 
> 
> On Thu, 4 Feb 2021 at 08:38, Torsten Bögershausen via Core-talk <core-talk at aps.anl.gov <mailto:core-talk at aps.anl.gov>> wrote:
> 
> 
>     > On 4 feb. 2021, at 01:21, Johnson, Andrew N. via Core-talk <core-talk at aps.anl.gov <mailto:core-talk at aps.anl.gov>> wrote:
>     >
>     > A colleague just presented me with one of those frustrating little problems where his database wouldn’t load because he spelled a calcout.OOPT field value using “to” instead of “To” and he couldn’t find it.
>     >
> 
>     Thar is sad to hear - but who hasn’t been there ?
>     Doesn’t the database loader give a useful warning/error ?
>     What is the difference between “to”, “fo”, “io”, “tu” ?
>     They are all typos, spelling errors.
>     What is the “real name” ? “To” or “to” ?
>     My suggestion would be to use a (naming) convention here - the same problem hits me all the time.
>     “CamelCase" or “snake_case" or “UPPERCASE" or “lowercase”  ?
>     None of my compilers is intelligent to figure out how to fix this typos - and that is a good thing.
> 
>     And: Helping colegues to find this kind of bugs puts people together.
>     Exchange knowledge, chat about other stuff.
>     Best practise, new projects, problems, even the solved ones.
> 
>     > How about when putting to a menu field we do a second pass through the choice strings using epicsStrCaseCmp() so this kind of thing would be silently accepted? The first pass should still use strcmp() in case some IOC has choices (in mbbo strings) that only differ by case, but the second pass would accept the first to match even when the cases differ.
>     >
>     > We could make this configurable so sites could turn it off, or even have it display a warning, but I’m not sure who would really want that much strictness.
>     >
>     > I already wrote the code, although it could be posted as a Codeathon project instead (requiring tests and Release Notes as well).
>     >
> 
>     > - Andrew
>     >
>     > --
>     > Complexity comes for free, simplicity you have to work for.
>     >
>