Notepad-plus-plus: Command Line Parameters: -1 vs. -2

[Yaron10]

STR:
Open a file.
Place the caret at line 3.

Run that file from the command-line with -n-1.
-- The caret remains at line 3.

Run that file from the command-line with -n-2.
-- The caret is at line 0.

Expected:
The same result in both cases.

---

Notepad++ v7.9.1 (32-bit)
Build time : Nov 2 2020 - 01:03:56
Path : C---notepad++.exe
Admin mode : ON
Local Conf mode : ON
OS Name : Windows 7 Enterprise (32-bit)
OS Build : 7601.23964
Current ANSI codepage : 1255
Plugins : ComparePlus.dll HTMLTag_unicode.dll MenuIcons.dll PythonScript.dll _CustomizeToolbar.dll

[sasumner]

I think -1 should put the caret on the _last_ line of the file.
-2 should put the caret on the line _before_ the last line of the file.
etc.
:-)

[Yaron10]

That's another option. :)
But I don't think it's necessary and not moving the caret would probably require less code, wouldn't it?

[sasumner]

Well one could argue that _nothing_ in this issue is _necessary_. :-)
(Just don't enter negative numbers for -n. )

[sasumner]

I think -1 should put the caret on the last line of the file.

There was a comment HERE regarding this:
_I was hoping -1 (negative one) would be like “last array element” and bring me to the last line, but it didn’t work._

[sasumner]

Not really related, but what is the opinion on how this should work:

• a 10-line file
• user invokes Notepad++ with -n20

Should Notepad++ ignore it, or should Notepad++ go as far as it can (line 10 in this case)?

[Yaron10]

Well one could argue that nothing in this issue is necessary.
(Just don't enter negative numbers for -n. )

This reminds me of a similar recent case: https://github.com/notepad-plus-plus/notepad-plus-plus/pull/9127#issuecomment-723652490. :)

These actions are either a mistake or "dumb".
But the application should take them into account and respond consistently.

a 10-line file, user invokes Notepad++ with -n20

I think the current behavior is OK.
But it's a good point: you can argue that both on -n-1 and -n-2 the caret should be moved to line 0.

There was a comment HERE regarding this.

I see. But is it the best way to implement "go to last line"?

[sasumner]

This reminds me of a similar recent case

But that drove an obscure bug (the searching one).
It isn't all that illogical to have two temporary tabs with the same name (in theory).
But when it gets in the way of some other feature working correctly, it is a problem -- that was dealt with.

This one is more of user saying "Oh, I entered a negative number. That's wrong. I won't do that again".
It really isn't important that it acts differently if different negative numbers are used, IMO, this kind of consistency isn't important.
I mean, we aren't talking about it causing a crash or something equally dire.
It's really a "who cares?" kind of thing (I know the answer). :-)

I'm glad you opened the issue, but let's turn it into something valuable, possibly revamping the feature, not just making consistent response to dumb input.

I think the current behavior is OK.

Since you answered in that fashion, now I have to go see what the current behavior is so that I have a real answer. :-)

you can argue that both on -n-1 and -n-2 the caret should be moved to line 0.

Meh. :-)

But is it the best way to implement "go to last line"?

It's actually not bad. Pythoners would also agree. :-)
It also fulfills the request of the user that says "How can I start N++ and open a file and jump to the line 10 lines before the last line of the file?"
All this assumes that the largest line number that is reasonable is 2147483647.

[sasumner]

Follow up:
7.9.1. behavior, a 10-line file, user invokes Notepad++ with -n20 : Notepad++ will put the caret on line 10.

[Yaron10]

I think the current behavior is OK.

Since you answered in that fashion, now I have to go see what the current behavior is so that I have a real answer.

That's a very good point. :)

"How can I start N++ and open a file and jump to the line 10 lines before the last line of the file?"

Is that a real question or you used it as an argument?
I love "feature-rich" apps, but sometimes there's a fine line between "customization" and "bloat" (and I do NOT mean your suggestion is the latter).
I see your point. As you understand.

[Yaron10]

This is relevant to -p as well. And -p might change to (f.e.) -char.
So, as you've mentioned before: wouldn't it better to settle the "Offset" question first?

[sasumner]

Is that a real question or you used it as an argument?

I don't recall it as a "real question", but I don't see why it isn't possible to be real.
It is nice to be already prepared when a user decides they need to do something.
Unlike before (user needed to jump to last line) where we weren't exactly prepared.

I love "feature-rich" apps, but ...

Don and I agree in general with this.
Usually it comes up for Don with touching the UI of the Find tab pages! :-)
For me, it bugs me to have so many preferences (of course you know this).

Something like my "bloat" :-) would be hidden from the general user, only to be brought out by reading the manual or someone asking.
I would not have suggested it except that at least one user has already wanted it.
And someone else even provided the solution, not particularly liking the kludgey -n2147483647 or otherwise large arbitrary number.

I'll see what I can do.
You will like it, because I will make the behavior logical and consistent. :-)

[Yaron10]

I'll see what I can do.
You will like it, because I will make the behavior logical and consistent. :-)

Great.
Thank you for all your hard work. :+1:

[sasumner]

This is relevant to -p as well.

From what I've seen in the code, it ( -n ) is NOT relevant to -p.

[Yaron10]

I meant that -x-No might be relevant to -p: "How can I start N++ and open a file and jump to Pos 10 from the end?".
I had -p in mind, but it's actually relevant to other parameters as well.
What would you do in -n-10 -c-15?

[ArkadiuszMichalski]

What would you do in -n-10 -c-15?

max line -10, max column - 15?

Another question, what if -val is bigger than max lines / columns, I assume we'll go to the beginning (which would be the opposite of going to the end for positive values)?

And I will also ask, will the Go to ... window also offer this?

In general, selecting from the end could be useful. It would be worth doing it consistent for the numerical arguments (if it will be implemented).

[sasumner]

I had -p in mind, but it's actually relevant to other parameters

-p still suffers from the "we're not sure what it is" syndrome, but once we figure that out, then Yes, they could all work consistently; switching to regex notation:

-n[+-]?\d+
-c[+-]?\d+
-p[+-]?\d+ (propose deferment of this until some time later...)

Another question, what if -val is bigger than max lines / columns, I assume we'll go to the beginning (which would be the opposite of going to the end for positive values)?

Yes, retaining how the positive case works currently, see https://github.com/notepad-plus-plus/notepad-plus-plus/issues/9146#issuecomment-727041046 above

And I will also ask, will the Go to ... window also offer this?

I don't see why it shouldn't, but we'll do it under a separate issue.
We don't know what DH thinks of the general idea yet, so...keep it small to start.

It would be worth doing it consistent for the numerical arguments

Consistency is "king". :-)

[Yaron10]

@ArkadiuszMichalski,

What would you do in -n-10 -c-15?

max line -10, max column - 15?

I thought @sasumner might reply that negative values would only be implemented in lines.
That's why I asked about the double parameters.

Another question, what if -val is bigger than max lines / columns, I assume we'll go to the beginning (which would be the opposite of going to the end for positive values)?

Do you mean the current behavior should be retained or changed if @sasumner's idea is implemented?

@sasumner,

What should happen in -n-50 in a 20-lines-file?

-p still suffers from the "we're not sure what it is" syndrome, but once we figure that out, then Yes, they could all work consistently; switching to regex notation

:+1:

[ArkadiuszMichalski]

Another question, what if -val is bigger than max lines / columns, I assume we'll go to the beginning (which would be the opposite of going to the end for positive values)?

Do you mean the current behavior should be retained or changed if @sasumner's idea is implemented?

Retainded and extended to the negative values (as reverse behavior to the positive values). First line contains the answer to your question: "What should happen in -n-50 in a 20-lines-file?" << go to the beginning, because n50 will go to the end. At least, that's how it should be for me.

And case with 0 as value for -n also need to be considered somehow, treated as 1? This https://github.com/notepad-plus-plus/notepad-plus-plus/issues/9146#issuecomment-727110308 basically explains everything.

Edit:

notepad++ -multiInst -n stylers.model.xml << this work, 1 line (0 column)
notepad++ -multiInst -n -c stylers.model.xml << this work, 1 line, 0 column

notepad++ -multiInst -n -c5 stylers.model.xml << half work, 1 line but 0 column (not 5)
notepad++ -multiInst -n0 -c5 stylers.model.xml << half work, 1 line but 0 column (not 5)

Maybe -n, -c, -p without value should use some default.

[Yaron10]

@ArkadiuszMichalski,

Yes, some points to consider. :)

[sasumner]

Let's attempt to change things, one feature at a time.

This has benefits:

• smaller changes at a time (easier for DH to review and like)
• not so much effort put in in case it is not liked :-)

We'll start with -n because:

• it is the most used
• it isn't -p :-)
• it was what this issue was originally opened against

I'll document things in such a form that it can be included directly in the user manual.

[donho]

If my memory is still working, all the integers of the argument should be positive and absolute (not relative).
So in the STR, 2 given negative values (-2 & -1) could make undefined behaviour, hence the cursor remains the current position.
It's not a bug to me.

[sasumner]

I don't really consider it a bug either.
It's a "don't do that" type of thing for the user.

But, my thinking was to use this issue to expand the feature a bit, and satisfy one other user's request to jump the caret to the last line of the file.
But, if you don't want it to be done, I won't do it, and we can close.

But, I pretty much already did it, so I'll PR it and even if it doesn't make it in, at least the code will be there for those that might want it as a patch. It isn't really much code, anyway.

[donho]

@sasumner So what's your mini-spec about this feature?

[sasumner]

@donho

Mini-spec:

-n with no following integer : same as -n0
-n0 : combined with -cN will keep caret on current line while moving to column _N_ (because currently -c does nothing without -n specified)
-nN (or even -n+N) : no change in existing behavior, move caret to start of line _N_ (assumes -c not used)
-n-N : move caret to start (again assumes no -c used) of line from _END_ of file

So, examples of -n-N are :

• -n-1 : move to last line of file
• -n-2 : move to line before the last line of file

This is similar to python logic for lists/arrays where my_list[-1] refers to the _last_ element of _my_list_.

Any argument that exceeds the bounds will peg at the boundary. In other words, in a file of 10 lines, -n13 will be considered a wish to move to line 10 (retains existing behavior). In the same file, -n-13 would move the caret to line 1.

It may seem to "complicate" things.
But negative line offsets could remain "hidden" to users that don't need it.
We wouldn't _try_ to hide it, but it wouldn't be the main usage.

Hmmm, I suppose I just wrote the documentation...for a feature that may not survive. :-)

[donho]

The following arguments are integer arguments.

• -n : Scroll to indicated line on filePath
• -c : Scroll to indicated column on filePath
• -p : Scroll to indicated position on filePath
• -x : Move Notepad++ to indicated left side position on the screen
• -y : Move Notepad++ to indicated top position on the screen

You interpret the negative numbers counting from the opposite extremity, why not? My concern is, once we open the door for -n, the other integer arguments should be applied to the same logic as well. -c-42 or -x-64 has no sense and non-utility, not mentioning to the possibility of implementation. So the simplest logic seems the best to me.

At least, I would say that negative integer arguments can be interpreted (instead undefined behaviour) as 0 (or 1, it depends on the argument), so no more undefined behaviour.

[ArkadiuszMichalski]

Other option, make at least that -n, -c and -p (arguments without value) move to the last line/column/char. Currently we have to enter some large value to get such behaviour.

[donho]

@ArkadiuszMichalski
"-nN" and "-cN" are made for locating the error of compiler of interpreter.
But why do users need "-c-38" or "-p-7" ?

[sasumner]

"-nN" and "-cN" are made for locating the error of compiler of interpreter.

Compiler output is a common usage, but users have invented others. Crazy users.

why do users need "-c-38" or "-p-7" ?

Probably because users think they need to do crazy things. :-)

[sasumner]

Currently we have to enter some large value to get such behaviour.

And that's a kludge; shouldn't have to resort to a kludge.

[ArkadiuszMichalski]

"-nN" and "-cN" are made for locating the error of compiler of interpreter.
But why do users need "-c-38" or "-p-7" ?

I remember seeing somewhere a question of selection from the end, so it could potentially be useful for someone. For me personally, it's enough to choose the last things more conveniently (https://github.com/notepad-plus-plus/notepad-plus-plus/issues/9146#issuecomment-727285505). All negative can be ignored and point to the last used (or used default).

[donho]

so it could potentially be useful for someone. For me personally

Potential need is not the real need.
Let's see if it's requested by (quite a lot of) people, then we can say it's real need (or not).

[ArkadiuszMichalski]

@donho But close this bug is not to fast? Actually -n-1 and -n-other_number works differently, first use last remembered line and second jump to first line, unless it's intentional.

[sasumner]

Closure is fine.

@ArkadiuszMichalski said:

Actually -n-1 and -n-other_number works differently

It doesn't matter.
Negative numbers are NOT allowed (per "usage guidelines") after -n, so it doesn't matter what it does.
As long as it doesn't crash/corrupt, and it doesn't, so it is OK.

Workaround to jump to last line is probably: -n2147483647 which might be a bit hard to remember. :-)
Jumping to line before the last line (or similar): Can't be done, sorry. :-)

[sasumner]

@donho said:

-x : Move Notepad++ to indicated left side position on the screen

-x-64 has no sense and non-utility

Wait, what??

On my multi-monitor setup, negative X and negative Y make perfect sense! :-)
I didn't know that -x could not do this!
I have to run now. I have to go open a new issue!

Later edit:
Actually, negative numbers for -x and -y DO work.
So...no new issue.
But...now there's an inconsistency where negative numbers work for some parameters but not others.

[sasumner]

As promised, here are the changes that do the proposed work for the -n option, for any future interest.
Just remembering them here, I didn't put them on a branch at all.
original.zip
changes.zip

[Yaron10]

Thank you all. Whatever you decide. :)

[donho]

Actually, negative numbers for -x and -y DO work.
So...no new issue.
But...now there's an inconsistency where negative numbers work for some parameters but not others.

OK.
@sasumner What's the specs for "-c" then?

[sasumner]

@donho

I think it is OK that -x and -y allow negative numbers and other parameters don't.
Because x and y have mathematical definitions that make sense here.
My proposal for the -n was only well-known to Pythonistas.

[donho]

@sasumner
Your (or Python's) "-n" logic is not so hard to understand, and it doesn't brother me neither.
The same logic can be applied to "-p", and be implemented easily, I guess.
If "-c" with negative value can be implemented easily, just go ahead.

But in this case the logic should be all the same for "-n", "-c" & "-p". Let's keep the consistency for these 3 arguments.

[sasumner]

just go ahead.
But in this case the logic should be all the same for "-n", "-c" & "-p". Let's keep the consistency for these 3 arguments.

I definitely agree with that 100%.

My thinking was to make the changes with one issue/PR for each, but I can do it all at once.

A "spec" for -c or -p is very similar to the one for -n.

[donho]

All at once is OK.
Thank you @sasumner

[donho]

I didn't consider the complicity of adding the positive & negative value factor, so after discussing with
@sasumner: https://github.com/notepad-plus-plus/notepad-plus-plus/pull/9210#issuecomment-738007943 , we decide to not integrate negative value in -p, -n and -c.

OTOH, the negative values of these 3 arguments won't be undefined anymore. They will be rejected - so negative values are just ignored.

[Yaron10]

@donho,

Great. :+1:
Thank you.

@sasumner,

Thanks again.