Odd (?) caret placement with auto-indent
-
@mkupper said in Odd (?) caret placement with auto-indent:
I feel the Note part should make it clearer that the behavior only happens when there were spaces/tabs immediately following the caret at the time enter was pressed.
How can I make it more clear? I already say, “For either Basic or Advanced mode, if you hit <kbd>Enter</kbd> in the middle of an indented line, before one or more space or tab characters (like before the space in
two words)…”. I suppose I could explicitly call out the caret, saying “For either Basic or Advanced mode, if you hit <kbd>Enter</kbd> when the caret is in the middle of an indented line, before one or more space or tab characters (like before the space intwo words)” … but I thought it was already pretty explicit even without the word “caret” being included.Do you have an alternate suggestion?
-
Sorry, I’ve been AFK since originally posting, but nice to see thoughtful replies on my topic.
It’s enough to make one want to script their own auto-indent. :-)
(But not post that here, because my script wouldn’t take tab characters into account, as I don’t use them) -
@PeterJones said in Odd (?) caret placement with auto-indent:
before one or more space or tab characters
The anal part of me :-) keeps getting stuck on “before one or more space or tab characters.” I had used “immediately before” rather than the more vague “before” which leaves open that there may be one or more characters between the caret and the spaces/tabs.
Overall, are we trying to document “defined” or “expected” behavior. Should the space/tab replacement thing be considered a “feature”, a “bug”, “glitch”, or an “anomaly?” If the manual is intend is to document defined/expected behavior then it may be better to remain silent on the space/tab replacement detail.
Likewise, the part about leaving the caret at column 1 seems to me to be a npp bug. Should that be included in the manual?
-
“immediately before”
I wouldn’t’ve thought it would be needed, but I also don’t object to that phrasing.
Overall, are we trying to document “defined” or “expected” behavior.
Yes. ;-)
If the manual is intend is to document defined/expected behavior then it may be better to remain silent on the space/tab replacement detail.
It’s hard to say: if it’s a bug that will be immediately fixed, then I can understand not documenting it. But if it’s going to be a bug that gets ignored by the developer for the next 5+ years, I think it should be documented.
Recently, a lot of the improvements to the manual have been about things that were assumed to be common knowledge, or clarifying behavior that was not obviously intuitive to the new user.
But if you think that the space clarification and the cursor-to-start-of-line would be more of a distraction than a help in the UM, I could just take out the new Note, and just leave the corrected phrasing of the individual modes.
-
@PeterJones said in Odd (?) caret placement with auto-indent:
But if it’s going to be a bug that gets ignored by the developer for the next 5+ years, I think it should be documented.
I second this idea.
-
@Alan-Kilborn, @mkupper, @PeterJones:
Would it make sense to anyone besides me to request changing the implementation of Auto-indent: Basic so that instead of relying on Scintilla’s indentation rules, it simply checked the line in which the Enter key was pressed for leading tabs and spaces, and, if it found any, inserted a copy of those before the caret in the new line, without regard to whether tabs or blanks are set as the indentation mode and without changing anything following the caret?
Since Basic never needs to create, expand or reduce indentation (like Advanced can) — it’s always duplicating the existing indentation, except for the case where spaces or tabs follow the caret — it shouldn’t be a problem to make it just do that: duplicate the existing indentation and not be reliant on having the tabs/spaces setting right for the specific file. And if you had tabs or spaces after the caret, they’d still be there following the caret in the new line, as a normal human being would expect.
I can request this and prepare an appropriate PR to implement it, but first I wanted to ask if others would find it logical. The major argument against it that I can see would be that it should really work this way for Advanced, too — but that’s more complex to implement, with more “OK, so what do we do if…” cases, and might thus be less likely to be deemed acceptable.
-
I said in Odd (?) caret placement with auto-indent:
Would it make sense to anyone besides me to request changing the implementation of Auto-indent: Basic so that instead of relying on Scintilla’s indentation rules, it simply checked the line in which the Enter key was pressed for leading tabs and spaces, and, if it found any, inserted a copy of those before the caret in the new line, without regard to whether tabs or blanks are set as the indentation mode and without changing anything following the caret?
I have submitted this as Issue #15843. Please comment if you think it does, or does not, make sense.
-
I also added Issue #15845, which directly notes the problem described in the original post. (Hopefully @Alan-Kilborn doesn’t mind that I did that.)
I suggested a solution, but not a specific commit, as the Auto-indent: Advanced code addresses many special cases, and without further examination I am not sure exactly where the fix is correctly applied.
-
@Coises said in Odd (?) caret placement with auto-indent:
Hopefully @Alan-Kilborn doesn’t mind that I did that.
Of course not.
-
You’ve proposed changing “basic” and “advanced” auto-indent in two separate github issues. I understand why you did this (in case one is accepted and the other is not accepted).
An offshoot from this is, if the basic one is accepted and the advanced one is not, it does me no good. Why? Well, because auto-indent is a global feature, not a file-type specific feature.
In theory I would turn basic auto-indent on for “normal” text files, to get the benefits of a “fix” for such files. However, for Python and C++ files, I want/need advanced auto-indent. But, I can’t do this (again, it’s global: basic OR advanced).
I lobbied the N++ developer that basic/advanced should be a per-filetype setting recently, but I lost (I was told “let’s see if other users need this”).
-
@Alan-Kilborn said in Odd (?) caret placement with auto-indent:
In theory I would turn basic auto-indent on for “normal” text files, to get the benefits of a “fix” for such files. However, for Python and C++ files, I want/need advanced auto-indent. But, I can’t do this (again, it’s global: basic OR advanced).
The code for Auto-indent: Advanced splits into three cases: C-like languages, Python and everything else; everything else uses the same code as Basic. The same change I proposed for Basic could be made there.
The reason I separated the two cases is that what I propose doing to Basic is simple and straightforward. I want to ignore the configured indent settings and just duplicate the indentation of the previous line. I was able, with reasonable confidence, to devise a commit which I believe implements that without causing side-effects.
The code for Advanced (except when it falls back to Basic) is far more complex, and of course it can’t ignore the indentation settings. The reason I didn’t suggest applying my change for Basic to Advanced when it falls back to Basic is that Advanced doesn’t just copy the existing indentation, it recomputes it, whether it is changing or not, according to the indentation settings (tabs or spaces). I thought it might be bizarre to have Auto-indent: Advanced sometimes change the indentation style to match the configuration and sometimes not.
I suggested something as to how Auto-indent: Advanced could be changed to fix the specific problem you mentioned, but I did not give an example commit, because I have not yet been successful at creating one. So far, for each attempt I’ve made I’ve quickly found some unwanted side-effect.
Part of the difficulty, also, is that after some experimentation with the unmodified version, there are some corner cases for which I do not follow the logic of the current behavior (or if some of that might be unintended). Example:
void func() { return; }
Start with that in language C++. The results of placing the caret after{and pressing Enter, then placing the caret after;and pressing Enter are not the same as the results of placing the caret after;and pressing Enter, then placing the caret after{and pressing Enter. In the latter order, the blank in “; }” is not absorbed; however, if you start with the line indented one level and do the same thing, the blank is absorbed. Either way, the caret winds up at the beginning of the line, as per your initial complaint.
