ST bug which breaks code when replacing folded text

[BPL]

Today I’ve catched a quite nasty ST bug, it happens when you decide to replace ocurrences from folded code, it’s quite destructive behaviour in fact and it will make you waste tons of time wondering why your code has been broken strangely if you’re not totally aware of it.

Personal story, In the past after doing some heavy refactoring (long time refactoring without running any test) of large python folded code (using alt+f3 quick_find_all command quite intensively) I’d end up running auto-pep8 and finally running my tests, but… what was my surprise after all the heavy refactoring? The code was totally broken misteriously!!! I was shocked without understanding at all what had happened as I tend to refactor stuff quite methodically… So my first thought would be blaming that auto-pep8 couldn’t handle folded code properly… Since that moment I just stop running autopep8 with folded code as a golden rule. At that time I didn’t suspect ST3 wasn’t able to handle folded code properly (i considered reliable by definition), today I’ve realized code-folded replacements are potential destructive actions on ST3 build 3131, here’s a little MCVE which exposing the nasty behaviour:

class Bar():
    def f():
        a = Foo.foooooooooo_bar()
        pass

class Foo():
    def foooooooooo_bar():
        pass

And breaking the code is as easy as doing something like this.

Well… the good news are at least now I’m aware of the really destructive behaviour so it’ll be my responsability if I break the code by doing so but it’s a shame all the wasted time because of it.

In any case, it’s strange this destructive behaviour has been living in ST till version3… as ocurrence replacements should be rock-solid in a text editor by definition since the very beginning.

Thanks in advance.

[ThomSmith]

The following behaves exactly as I think you would expect:

1. Fold the class Bar.
2. Select foooooooooo_bar under Foo.
3. Press alt+f3.
4. Type in a new method name.

When you unfold Bar, you will see that the invocation of foooooooooo_bar has been replaced correctly by the new method name,

However, in your video, you do one more thing. You move the cursor, presumably using the arrow keys. This is what results in the unwanted behavior, because while it is possible for commands like alt+m to select text inside a folded region, the arrow keys skip over folded regions when moving the cursor. The problem — what you see as a bug — stems from trying to move the cursor within a folded region. I’m not sure that there is any behavior for that case that wouldn’t be surprising under the wrong conditions.

The behavior for ctrl-d when adding a selection inside a folded region is to unfold that region. Perhaps alt+m should do the same. If you like, you can implement this behavior in the general case with a ViewEventListener implementing on_selection_modified and calling View.unfold.

[BPL]

Thanks for the clarification, good to know what the logic is

Now, while I understand what your suggestion is about my point is other, is this a bug or not? Let me put it in a different manner (not subjective one). If you perform the same actions from my video with an unfolded view no matter whether you move the cursor or not, the end state of the buffer will be expected for the user, I mean, of course the user could also break the code if he wanted to but he’d know why he broke it. But if we stick to this bug, the user doesn’t know what the end state of the buffer will be… but in my opinnion, this is the same buffer we’re talking about, aren’t we?

You see my point? Same buffer, different behaviour, therefore it’s not about “what i see as a bug”… this is a bug… and a nasty one I should say.

i.e: Software should be deterministic, and no matter the view of the buffer, the output should be the same… the command is intended to replace text after all…

[kingkeith]

side note: why haven’t you upgraded to build 3143 or newer?

[BPL]

I like to update at my own pace tbh (packages/ST) … few months ago i had upgraded and the UI had been changed drastically … at first I got annoyed and I was trying desperately rolling back… But then I decided to give it a shot and now I’ve got used to it and the new UI feels normal again . That said, I don’t really like having unexpected updates and if this version works for me as it is, there is no strong reason to upgrade. If you told me the most recent version supported python3.6 or this bug would be fixed, well… I could think twice

Nah, seriously, ST has reached already a level of maturity so big that I prefer updating not very often unless they add major core changes (more performance… although the current one is fast as hell, ability to use the most recent python to code plugins… although 3.3 is more than good enough). “Problem” here is the product is already a really awesome one so it’s quite difficult to miss many features that allows you to get the job done fast&easily on any programming language for any type of project size… So…

[ThomSmith]

no matter the view of the buffer, the output should be the same

This seems intuitively appealing, but it rather defeats the purpose of code folding. If we take this literally, then when your cursor is at the beginning of a long folded region, and you press the right arrow, then the selection should now be inside the folded region. Press it again and the selection would have moved inside the folded region. The problem is that because the region is folded, you can’t see what the selection is — your commands are changing the state in a way that is invisible to you. This is why the arrow keys cause the selection to move over folded regions rather than through them.

I expect the same commands to have different results depending on whether code is folded. If I press the down arrow, I expect the cursor to move to the next visible line, even if there is a multi-line folded region in between. I think that it would be far more confusing in the common case if the cursor were to “vanish” while the selection moved somewhere inside the folded code.

Now, given that, what should be the behavior of alt+m? I think you would agree that it should select code within the folded region; it would be confusing if it were to omit selections within folded code. Then, if it does not automatically unfold the code, you can reach unintuitive results if you use the arrow keys, because your selection is inside a folded region. I think that this is a good argument that alt+m should expand folded regions containing matches. But I don’t think it’s a good argument for making deep changes to the way that code folding works.