Should $(CURRENT_LINE) be zero-based?

Yaron

EditPad. :)

Scott Sumner

I have encountered this before and I fully agree with @Yaron . Having $(CURRENT_LINE) being zero-based pretty much destroys its usefulness for any purpose. :-(

Claudia Frank

Actually I think having $(CURRENT_LINE) not being 0-indexed doesn’t make sense.
Value comes from scintilla and can be past to scintilla so why should npp add and
substract a value to get the correct line if it just can pass the value.

@Yaron - a possible solution might be to chose a language which uses
0 based indexes - like … :-D you know it :-D

Cheers
Claudia

Scott Sumner

It is not an issue if one stays “within” Notepad++/Scintilla, but a typical use might be in interacting with other tools that you don’t control the source of (can’t edit/rebuild). These tools would typically expect a user line number (1-indexed) rather than the 0-indexed value provided by $(CURRENT_LINE).

@Yaron 's example would be perfect if he didn’t “control the source” of his Test.vbs. Clearly, he could adjust the number his vbs receives by increasing by one whatever comes in, by editing the code. Unfortunately, we don’t always have the luxury of having the code or being able to change/recompile it to make such an adjustment.

Think about an error parser for a compiler. The compiler outputs warnings/errors with a filename and a line number (and sometimes a column number too) to indicate where the problem occurred. I have never seen such a line(/column) number be zero-based; it’s always one-based because the output is intended first-and-foremost for the humans, whose first thought is to start counting from 1 not 0.

My 2c…maybe I need some change back…

Claudia Frank

I see where this could become handy but I do also see where this would be problematic.
Like you said, how to distinguish between used internally and externally.
If you change it to get work with external programs which do assume 1based indexing
you open the door to complain for those who use it internally.
So in such cases I think keeping its native feature does make more sense.

Cheers
Claudia

Yaron

a possible solution might be to chose a language which uses
0 based indexes

Test.vbs was just an example.

I’m actually using
<Command name="Open in EditPad..." Ctrl="no" Alt="no" Shift="no" Key="0">"C:\Program Files\EditPad\EditPad.exe" "$(FULL_CURRENT_PATH)" /l$(CURRENT_LINE)/c$(CURRENT_COLUMN)</Command>

how to distinguish between used internally and externally

If I understand it correctly, $(CURRENT_LINE) is meant for interacting with External Programs.
NPP uses getCurrentLineNumber() and adds +1 when necessary (e.g. setting Ln in the status bar).

So apparently

wsprintf(expandedStr, TEXT("%d"), lineNumber);

in RunDlg.cpp should be changed to

wsprintf(expandedStr, TEXT("%d"), lineNumber + 1);

Thank you.

Scott Sumner

@Claudia-Frank said:

So in such cases I think keeping its native feature does make more sense

I wasn’t advocating for change (I’ll let @Yaron do that!)…just opining that the few times I remember considering using $(CURRENT_LINE) for something, I realized I couldn’t do it because of the offset-by-1 for what I needed at the time (can’t really remember what I was attempting…).

@Yaron : Ah…@PeterJones was right…Editpad…the heresy! :-D

@Yaron : There’s a $(CURRENT_COLUMN) variable supported in Notepad++??

Yaron

Ah…@PeterJones was right…Editpad…the heresy!

Actually, the heresy was merely mentioning “other editor”.
The explicit name was my reply to his question.

I solemnly swear that I am up to no good. :)

There’s a $(CURRENT_COLUMN) variable supported in Notepad++??

					if (internalVar == CURRENT_LINE || internalVar == CURRENT_COLUMN)
					{
						auto lineNumber = ::SendMessage(hWnd, RUNCOMMAND_USER + internalVar, 0, 0);
						wsprintf(expandedStr, TEXT("%d"), lineNumber + 1);	
					}

And it’s also zero-based.
Adding +1 fixes both line and column.

Claudia Frank

But that would mean, that, for example, we cannot use

SCI_SENDMSG 2227 $(CURRENT_LINE) $(CURRENT_LINE)

in NppExec anymore and this is true for all other messages which uses CURRENT_LINE as being a parameter in the call.

Maybe I’m wrong but I still think it is correct as it is.

Cheers
Claudia

Yaron

Claudia,

Can you use

SCI_SENDMSG 2227 $(CURRENT_LINE)-1

?
I think you can’t achieve that in the command line.

Scott Sumner

@Claudia-Frank : Hmmm…have to look up 2227…what could take two parameters of current-line?..what magic is CF up to now?..hmmm…

All: Maybe the best solution is some new things being created, perhaps $(CURRENT_LINE1) and $(CURRENT_COLUMN1), or whatever names are most appropriate…

Claudia Frank

Yaron, of course we could manipulate the output but does this makes sense?
I don’t know how many macros/scripts/or_whatever_it_is_called are out there
and do use the variable in conjunction with another call expecting this variable
as paramter -> all would have to be changed in this case

Scott, it is hiding lines - just an example - nothing magic :-)
But I would vote for having an additional variable which returns the “human expected” value.

Cheers
Claudia

Yaron

Claudia,

Good point.

Scott,

Good idea.

Thank you both.

Vitaliy Dovgan

NppExec can live with any version of $(CURRENT_LINE) :) E.g.:

set local line ~ $(CURRENT_LINE) + 1 // in case of zero-based
"C:\Program Files\EditPad\EditPad.exe" "$(FULL_CURRENT_PATH)" /l$(line)/c$(CURRENT_COLUMN)

or

set local line ~ $(CURRENT_LINE) - 1 // in case of one-based
SCI_SENDMSG SCI_HIDELINES $(line) $(line)

P.S. Remembering all the Scintilla messages’ numbers (such as SCI_HIDELINES = 2227) are kind of hardcore. My colleague once said he was learning all the main GUIDs present in Windows, but he was certainly joking :)
The “NppExec” subfolder near to NppExec.dll contains header files which are read by NppExec at runtime to use string constants such as SCI_HIDELINES instead of numbers.

Yaron

@Vitaliy-Dovgan,

Thank you for the info. I appreciate it.

Remembering all the Scintilla messages’ numbers (such as SCI_HIDELINES = 2227) are kind of hardcore.

Not for @Claudia-Frank. :)

@guy038,

Regards.