Closed Minoru closed 8 years ago
Since the whole point of s/// command is to facilitate fixing typos,
No it is not. The documentation clearly says:
Replaces first argument with the second argument, taking the last sender phrase as the base.
What the typo fixing are you talking about?
And personally I would not change the current behaviour of s/// at all. It seems for me being just right. So I vote against this ticket, sorry.
It is generally intended for - but not limited to - fixing the typos in the last entered phrase.
I am not sure if we want to invent some manual "regular" expression parser. Also, @Minoru, your usage of $
does not seem intuitive to me at all. You've entered s/$/xxx/
, and my intuition is not sure what this would mean. Replace the end of the line with something, so the line won't end anymore?
That semantic is a bit vague for me (but I understand that it may work the same in Perl or sed
or whatever).
The idea of writing a custom "regex" parser doesn't appeal much to me either, especially since we'll need to take care not just of these two characters but also of escaping them, and also escaping the escape character. But this functionality will really make my life easier by making s/// closer to real regex replacement.
As for intuition, well, I don't see why this can be used as an argument. The usage is the same across implementations (just checked sed, Vim and Perl), so it's more feasible to fix your intuition rather than all the implementations. In fact, it's precisely because of me having this intuition that I suffer so much without this feature: when I need to fix the ending of my previous message, it immediately occurs to me that I should use $
; alternatives like typing the last word of the sentence don't spring to my mind at all.
Anyway, how do we proceed with this? Do we wait for votes from other Horta developers?
I'd say that first of all you need to provide a spec with a list of a regex features absence of which will confuse you most of all. Then we may discuss it. I have no strict objections against implementing this feature, but we need to settle on what exactly we're discussing.
You know, I was in two minds already after reading your responses and seeing #378. Now I started writing a spec and realized that we can have multi-line messages, which complicate things immensely: we now have to specify how the message is fed to the regex (line-by-line or as one single whole). That tipped my opinion: I'm no longer in favour of this feature, because the complications outweigh the gains.
Thanks for the discussion.
(I know that s/// deliberately doesn't support regular expressions out of security consideration, but if I understand it correctly, the ban applies only to more advanced things like repetition, lookahead and so on.)
Since the whole point of s/// command is to facilitate fixing typos, we should provide convenient methods of specifying what exactly needs to be fixed. The ban leaves us with little choice: beginning of line, end of line, and markers for word boundaries. Given the latter have different syntax across different regex standards, we end up with just two things to support.
So, any thoughts on adding
^
and$
tos///
?