Should $(CURRENT_LINE) be zero-based?

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.