Should $(CURRENT_LINE) be zero-based?

  • 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">&quot;C:\Program Files\EditPad\EditPad.exe&quot; &quot;$(FULL_CURRENT_PATH)&quot; /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.

  • @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++??

  • 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.

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


    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.


  • Claudia,

    Can you use


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

  • @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…

  • 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.


  • Claudia,

    Good point.


    Good idea.

    Thank you both.

  • 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)


    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.

  • @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. :)



Log in to reply