timesheet.txt icon indicating copy to clipboard operation
timesheet.txt copied to clipboard

Syntax for continuing by substring

Open scy opened this issue 5 years ago • 4 comments

I'm splitting #3 in three separate issues, this is one of them. Example file:

1234  implement CLI parser
1245  customer called, discussed some open questions
1320.  # bathroom break

Now it's 13:25 and I want to continue work on "implement CLI parser". In #3, I've suggested ^? as a syntax to back-reference previous lines by substring match. This means that I could write a line like 1325^?CLI or 1325^?parser or even 1325^?im to refer to the 1234 entry.

I've selected the question mark as a prefix for a reason here. First, it's easy to memorize, because less, vi etc. use ? as the command to search backwards. Second, not using any prefix at all (like 1325^parser) would prevent us from adding more possible ways to search in the future.

I had two open questions, but already opinions on them, and these opinions have not changed. To reiterate:

  • Should ^? be able to match anything in the description text, even hashtags and billable flags? I think yes, simply match the text as it is in the file, not any parsed content. This also makes it easier for editor plugins etc. to know which line you're referring to.
  • Should ^? match case-insensitively? I I'd say no. It complicates the matching (for non-ASCII characters at least), and you'll be most likely able to see the line you're referring to anyway.
    • @rohieb argued that case-insensitive matching would save some keystrokes, but I consider holding shift not really a keystroke. Also, and this is what really scares me about case-insensitive matching: The Python implementation would use Python's case-folding code, while a Vim plugin for example would use Vim's case-folding. If these two don't match exactly for some reason in some edge case, the plugin and the command-line tool might disagree on which line you're referring to. This can't happen with case-sensitive matching. I think it's not worth the risk.

One new open question came up:

  • Should ?^ foo (with a space in between) be looking for foo (whitespace stripped) or foo (the word foo with a space before it)? Stripping the whitespace would prevent us from using expressions that start or end with whitespace, but I think that's alright. We'll probably not be able to end with whitespace anyway, because the lower-level line parsing will eat it away, and also it would lead to ambiguity in a line like 1325^?nt # a comment: Does the space between t and # belong to the expression or already to the comment?

scy avatar Jun 18 '19 14:06 scy

One more thing regarding the "whitespace" question at the end: I'm thinking of implementing a regex-like search in the future that would allow you to match whitespace as well, if there's really a need. But this would definitely be post-1.0.

scy avatar Jun 18 '19 15:06 scy

Maybe think more like git, refer to the time as the identifier: ^1234, that's even how you just referred to it in the issue. Obviously theres a resolution tradeoff which should be considered. Also, maybe just something like ^~2 meaning two lines up.

gauteh avatar Jul 09 '19 11:07 gauteh

Looks like you got that covered by the two previous issues already ;)

gauteh avatar Jul 09 '19 11:07 gauteh

Yep, you're late to the party 😉 Referring to a timestamp is being discussed in #14, referring by position (like your ^~2) is in #13.

scy avatar Jul 09 '19 12:07 scy