Auto-Indent - Basic not always works as expected

Codereamp

Hi,

In npp 8.7.8 when editing javascript files with Auto-Indent set to Basic I sometimes notice that in some instances after pressing Enter the caret first goes to the start of the new line. If I return to the line where the Enter was pressed initially then usually the next time npp correctly indents to the right indentation.

The examples of lines that show this (I’m not sure whether this is relevant) : } (closing bracket), else keyword.

Thanks

Codereamp

It seems like I have at least one easily reproducable test, language-agnostic

Notepad++ v8.7.8, 64 bit, portable

Auto-indent is set to Basic
File-new
type several spaces, type ‘foo’, press enter. The caret now is correctly placed below foo
press left arrow several times untill the caret reaches the first symbol of the second (current) line
type several spaces, type ‘bar’, press enter. Now the caret jumps to the start of the third line (unexpected)
press left arrow to return to the end of the second line (after bar), press enter, now caret is below bar (expected)
probably is has nothing to do with the fact that we are on the last line because in this text one can repeat similar actions in the middle of the text and get the same result.

PeterJones

@Codereamp said in Auto-Indent - Basic not always works as expected:

The culprit on that is the spaces after the bar – so there are spaces to the right of your cursor when you hit ENTER. Notepad++ uses those for part of the indentation for the next line.

Look at these screenshots with visible-spaces on:

Here, the caret is between bar and the six spaces:

Now I hit ENTER, and the caret moves to the begninning of the line, but the number of spaces after the caret changes to only 4, so that the end of the spaces align with the start of the bar on the previous line:

This is a known issue #15845, and was previously talked about in “Odd caret placement with auto-indent”

Codereamp

@PeterJones said in Auto-Indent - Basic not always works as expected:

This is a known issue #15845 , and was previously talked about in “Odd caret placement with auto-indent”

Thanks, I understand what it is, also I should have searched better before posting. Maybe after understanding the reasons behind I will adjust my habits at least to avoid creating white space after the caret before creating new lines.

mpheath

@Codereamp

LuaScript can be installed by Plugin Admin. This Lua code can be added to startup.lua by clicking on the menu Plugins -> LuaScript -> Edit Startup Script

 function TrimAfterNewline(character)
    -- Trim spaces and tabs for good indentation.
    
    if character == '\n' then
        local pos = editor.CurrentPos
        local posNext = pos - 1
                
        -- Find spaces or tabs.
        repeat
            posNext = posNext + 1
            local ch = editor.CharAt[posNext]
        until not (ch == 0x09 or ch == 0x20)
        
        -- Remove spaces or tabs.
        if posNext > pos then
            editor:DeleteRange(pos, posNext - pos)
        end
    end
end

npp.AddEventHandler('OnChar', TrimAfterNewline)

Coises

@Codereamp said in Auto-Indent - Basic not always works as expected:

Maybe after understanding the reasons behind I will adjust my habits at least to avoid creating white space after the caret before creating new lines.

I wrote something about the reasons here — the short version is that it’s implemented using the indentation logic of the underlying Scintilla control (the bit of software that controls the areas where you actually see and type into documents; it’s a separate project from Notepad++). If you think like Scintilla, what it’s doing makes sense; if you think like a human looking at the end result, not so much.

The specific issue for the Auto-indent: Basic case is #15843.

I still feel uncertain about the ideal resolution of that issue and the related Issue #15845.

When Auto-indent: Basic in effect, there are tabs or spaces following the caret, and you press Enter, what do you expect to happen?

Does the indentation of the previous line get duplicated, with the caret placed after it and the spaces or tabs following the copied indentation?

Or do the spaces or tabs following the caret get “absorbed” into the new indentation?

Do the characters used to indent the new line duplicate the indentation of the line that was split (spaces, tabs or any combination thereof), or does indentation follow the Indentation | Indent using: setting?

If white space following the caret is retained, does that apply even when there are no visible characters following the white space? Is the caret on the new line placed following all the white space, or just the part of the white space that was copied from the previous line? Does that vary depending on whether there is visible text following the white space?

If we copy existing indentation rather than re-creating it according to the Indent using setting, should that also apply to Auto-indent: Advanced when the language in effect doesn’t support “Advanced” indentation? (Advanced is available for C-like languages and for Python.)

What about Auto-indent: Advanced when the language does support advanced indentation, but indentation is neither increased nor decreased in a particular case?

Codereamp

@Coises, after @PeterJones mentioned your posts and your issues, I read discussions and your explanations. First I’m impressed with how many details you have in mind and this and other questions are very important. Also I noticed that while many agree with your observations, there are not so many who are frustrated by this as much as you are. Maybe I’m in your camp here, at least partially :)

My two cents are related to the fact that my previous activities were heavily influenced by Borland-originated editors (for example, in Delphi) where Virtual Space (now in npp too) was always on by default (I’m not even sure whether it is possible to switch it off). Lazarus IDE editor is very similar since Lazarus/FreePascal was inspired by Delphi/Turbo Pascal). Amongst other things this mode basically treats trailing space as virtual space. I just made a test when I forced multiple spaces after some last non-space character and tested End (SCI_LINEENDWRAP) operation. In Delphi/Lazarus the caret goes after the last non-space symbol so if there are no added spaces at all. The selection with keys also mostly ignores these new spaces, I could not select it with any ctrl/shift arrows operation. In npp End (SCI_LINEENDWRAP) jumps to the end of the new space so it is obviously kept intact. With selection in npp it’s mixed. Shift-arrows act like virtual space is everywhere, but Ctrl-Shift-arrows (SCI_WORDRIGHTENDEXTEND) “feels” this new space. Anyway, I’d suggest that when Enable Virtual Space is on, trailing spaces might be treated with some relaxed rules, but I’m not sure npp is ready to implicitly get rid of spaces without the user asking for it.

As for non-Virtual Spaces mode that is I suppose used mostly by npp users, maybe the difference in perception is what the Auto-Indent is doing. Actually I’m curious if anyone cares about trailing spaces at all (except when thinking about avoiding unnecessary bytes saved or implicit aesthetic reasons). The mere existence of “Trim trailing spaces and save” command probably partly answers this for many existing users, but I’m not sure about all.

Also interesting difference between Delphi editor and npp when the caret has some space after it and also meaningful text after the space. In the former after I press Enter the editor keeps the spaces and the text, but places the caret right below the character on the previous line so I have this space at the caret. In npp the caret goes to the start of the line and the meaningful text aligns to the line above.

The images below illustrates this

This is the state before I press enter in Delphi

… this is after

This is before I press enter in npp

This is after

I don’t know what kind is better, I’m more used to how Delphi handles it.