> On Jul 21, 2020, at 11:13 AM, Jonas Devlieghere <jo...@devlieghere.com> wrote: > > I don't mind adding the two-letter commands, but I also don't really see the > value in being able to say `bs` instead of `b s -y`. Until either becomes > muscle memory, both require a little cognitive overhead of thinking > "breakpoint set -y" or "breakpoint source". As a user there would be more > value in knowing that the latter is really `breakpoint set -y` which then > allows you to query the help.
Yes, I don’t really understand people’s objection to “br s -y” or whatever, and peering over people’s shoulders indicates it is not universal. But there are a significant number of folks who are happier with a single command to type and “b s -y” seems to be a hinderance. I was trying to help in this case, not trying to understand... > > If I understand correctly the problem with `b` is that the regex can't > distinguish easily between what it should parse and what it should forward to > `breakpoint set`. Additionally, because it's essentially a mini-language, you > can't be sure if something with a colon is a symbol or file separated by a > line/column number. More that that. If you type: (lldb) b f<TAB> then we have to complete f in all the collections “b” might access, symbol names and file names in this case. In a substantial project that’s a lot of symbols if I meant a file name and vice versa. And the more we glom into the break-specification mini language, the harder this will be. > > I think we should be able to solve the first issue by making `b` a proper > first-class command instead of a regex alias, taking the exact same options > as `breakpoint set`. I think our existing command object argument parser > should be able to parse this and return the remaining "free form" argument, > which we can then parse as a mini-language like we do today. Of course this > would remain suboptimal, but would be strictly better than what we have today > and address the original problem you're trying to solve. Furthermore, with a > first-class command we can do a better job on the help front which is really > underwhelming for _regexp_break command aliases. > > That leaves the second problem, which would be solved by the new two-letter > commands but not by changing `b`. From a purity perspective I'd lean towards > the new commands, but as a user I doubt I would use them. I set almost all my > breakpoints with `b` and I don't see a compelling reason to change to `bs`. > So that leaves me with using `b` most of the time, until I do need to pass > some extra option at which point I'll probably just use `breakpoint set` > directly. > > TL;DR: Given how widely used `b` is I'd rather improve that and turn it from > a 98% solution into a 99% solution instead of adding new commands. I was hoping that since “bs”, “ba”, and “bn” are easy to type and would show up in a top-level “help” new folks would shift to using those, and maybe extant users of “b” would too. Then we could slide past having the “break-specification mini-language” over time. I was also trying to make things a little better w/o signing up for making “_regex_break” work better which I don’t have any intention of doing personally... Jim > > > On Tue, Jul 21, 2020 at 10:22 AM Jim Ingham via lldb-dev > <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote: > When we were first devising commands for lldb, we tried to be really > parsimonious with the one & two letter unique command strings that lldb ships > with by default. I was trying to leave us as much flexibility as possible as > we evolved, and I also wanted to make sure we weren’t taking up all the > convenient short commands, leaving a cramped space for user aliases. > > The _regex_break command was added (and aliased by default to ‘b’) as a way > to allow quick access for various common breakpoint setting options. However > it suffers from the problem that you can only provide the options that are > recognized by the _regexp_break command aliases. For instance, you can’t add > the -h option to make a hardware breakpoint. Because the “_regex_break > command works by passing the command through a series of regex’s stopping at > the first match, trying to extend the regular expressions to also include > “anything else” while not causing one regex to claim a command that was > really meant for a regex further on in the series is really tricky. > > That makes it kind of a wall for people. As soon as you need to do anything > it doesn’t support you have to go to a command that is not known to you > (since “b” isn’t related to “break set” in any way that a normal user can > actually see.) > > However, lldb has been around for a while and we only have two unique > commands of the form “b[A-Za-z]” in the current lldb command set (br and bt). > So I think it would be okay for us to take up a few more second letter > commands to make setting breakpoints more convenient. I think adding: > > bs (break source) -> break set -y > ba (break address) -> break set -a > bn (break name) -> break set -n > > would provide a convenient way to set the most common classes of breakpoints > while not precluding access to all the other options available to “break > set”. We could still leave “b” by itself for the _regex_break command - > people who’ve figured out it’s intricacies shouldn’t lose their investment. > This would be purely additive. > > What do people think? > > Jim > > > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > <https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
