Impossible to search for 4 spaces

[alexandernst]

Whenever I try to search for 4 spaces (spacebar hit, spacebar hit, spacebar hit, spacebar hit) the input field's value get's converted to... something... not really sure what, and Atom just can't match 4 spaces.

[alexandernst]

Actually, I beg a pardon. I am able to search for 4 spaces, but the field's value gets converted to something else, so once I type 4 spaces, I can't delete one of them. I'm forced to remove everything.

[benogle]

I think it's chunking them into groups of two. I'm going to close this as a dupe of https://github.com/atom/atom/issues/3174 as it seems like the same issue.

[alexandernst]

@benogle I can hardly agree with what you said in https://github.com/atom/atom/issues/3174 , quoting: I wouldnt consider this a bug. I think it should be a wontfix.

This is a bug in the find&replace package, also in Atom itself. Focusing on this issue, I genuinely can't remove a single space form what I'm trying to find and the idea of a design that makes Atom work that way is quite disturbing.

So, if you keep thinking https://github.com/atom/atom/issues/3174 is a wontfix, then reopen this, as this is a genuine bug.

[alexandernst]

@benogle ping?

[benogle]

This is a dupe of the issue linked, and we have not come to a conclusion on the linked issue.

[alexandernst]

@benogle I insist. This is, by no means, any similar to the issue you linked. The issue you linked is about Atom not letting you place the cursor at certain positions before the first non-space character of the line. This issue is about the find and replace input converting spaces to things.

While I do see why you're still looking for a solution to the issue you're linking, this issue is as clear as is gets. The input field shouldn't convert anything at all. It should be as stupid as possible, aka, it should just show the raw input if the user. It shouldn't care about your folding config, about any indent characters, nor about anything else. It should just let me write stuff and not care about that stuff at all.

[thomasjo]

The input field shouldn't convert anything at all.

But that's just the thing, it's not just an "input field". It's a TextEditor (well really a TextEditorView), so the issue is in fact a dupe.

[alexandernst]

@thomasjo Why do you use a TextEditor (or whatever that is)? Is there some reasoning that I'm missing here that makes you use a complete texteditor component instead of a simple text input field?

[thomasjo]

I don't know why unfortunately. Maybe @benogle can comment on that.

[thedaniel]

I'm not sure this is a duplicate either - if we fix atom/atom#3174 by allowing a texteditor's behavior in this way to be configured, we can fix the behavior in fnr easily, but as @alexandernst points out, if we leave it wontfix, this behavior in fnr is still a bug and should be addressed in some other way. Considering the alternative fixes though, it seems to make sense to provide a way to disable jumping across indents with an attribute in the tag or something rather than coming up with a whole new texteditor-like input element for fnr.

[thedaniel]

@alexandernst We use TextEditors in places like this so that input supports the same movement / manipulation commands (whether default or user-defined) that can be used while editing text in a normal editor.

[alexandernst]

@thedaniel That would make sense if the fnr input was designed to hold considerable amounts of text. I'm not sure that is the case here. fnr input will hold a single word, maybe 2, almost always. I can't think about a use case where an user would write that much text so he'd actually need to use his user-defined movement / manipulation commands.

[alexandernst]

@thedaniel Also, I'm not sure how much overheat the usage of this type of component adds to the fnr extension itself. Maybe using a simple input field would bring more benefits than keep using the current one?

[alexandernst]

Can we get this reopened while discussing it? I don't want it to be barred and lost.

[thomasjo]

Agreed.

[goffreder]

+1 on the "non-duplicate" side, to me this is a completely different bug in the fnr as you may keep the quick jump in the editor (thus "solving" it) and you'd still have this bug. Plus, to me this is quit a big one, since now I am forced to use a beautifier package if I want to refactor my code.

[da-n]

I believe this issue is also causes problems for me. For example if I want to search and replace something that spans multiple lines, that usually will include indentation. If I try to paste the target search query as such:

    $var1 = "foo";
    $var4 = "bar";

And replace them with:

    $var2 = "foo";
    $var3 = "bar";

I am out of luck, since the spaces are stripped. This works flawlessly on other text editors I use, so wonder why this choice was made. Thanks.

[proteo]

As pointed by da-n, the current behaviour prevents you from searching for multiple lines with leading spaces. I don't see how that is related to the other issue.

[maackle]

Possibly related: When I attempt a global Find & Replace, where my query begins with a space, in the preview of replacements, no matter what I choose as my replacement string, it always shows up as no change.

Without leading space:

With leading space: