Qualified imports of pkg/ui outnumber unqualified (82 to 1). Improve
consistency, and clarity, by changing the dot (unqualified) imports of
that package symbols to qualified.
Qualified imports of pkg/tt outnumber unqualified (27 to 24). Improve
consistency, and clarity, by changing the dot (unqualified) imports of
that package symbols to qualified.
cmp.Diff panics when comparing a struct that has unexported fields and no String
or Equal method, so change some structs to either export all their fields or
have an Equal method.
This fixes#1136.
This change addresses issues reported by the `staticcheck` tool and a
couple reported by the `golint` tool. It also adds missing issue links
to a couple of entries in the release notes. This change deliberately
does not address these warnings since it is unclear whether the project
owner would prefer to suppress or address them:
pkg/store/cmd.go:8:2: should not use dot imports (ST1001)
pkg/store/db_store.go:10:2: should not use dot imports (ST1001)
pkg/store/dir.go:8:2: should not use dot imports (ST1001)
This fixes the *Segment.Concat and RConcat methods to handle the new
number types. It also adds more tests of concatenation with the "Text"
and "Segment" types with number types.
Related #1340
Including the float64 data type in the prompt value stream causes an error.
This causes those values to be implicitly converted to a string as happens
everywhere else in Elvish.
I initially intended to modify the code to do the implicit string coercion
for any type not otherwise explicitly handled by the pkg/ui `Concat`
methods. I decided against that approach because doing so doesn't make
sense for some types that might appear in the value stream; e.g., Elvish
exceptions.
Fixes#1186
As with commit #eb2a792 I acknowledge that `golint` recommendations are
controversial and should not automatically be acted on. Nonetheless,
this change fixes legitimate lint issues such as copy/paste cleanups,
style problems I introduced (`i += 1` versus `i++`) or method/var comments
that are not in the preferred form.
It should be possible to bind a key to a literal control character. For
example, it should be possible to write:
edit:insert:binding["\e"] = $edit:command:start~
as a logically equivalent alternative to the preferred form:
edit:insert:binding[Ctrl-'['] = $edit:command:start~
Resolves#1185
Document the format key of names and modifiers; albeit with a TODO
regarding the `Shift` modifier.
Make function key modifier matching case sensitive (`Alt` not `alt`)
to match key name matching (`Enter` not `enter`).
Implement `Ctrl-?` as the logical counterpart to `"\c?"`.
Resolves#1163
I stumbled across a comment that began with "XXX". It was clearly meant as
a "TODO" comment. This changes all such occurrences. However, a few "XXX"
comments are ambiguous and a better prefix might be "WARNING". The "TODO"
prefix at least ensures someone, eventually, looks into the situation
and either rewords the comment or fixes the problem. This change means
everyone can assume searching for "// TODO" will find all such comments
rather than requiring they also know to search for "// XXX".
