XYplorer Beta Club

Wow lots of activity here, im glad other folks see that this is a useful feature! I was able to achieve the effect with the replace and copytext example, but there is one huge drawback -- it has no effect on the tree, only in the list?

If i want to use the hotkey for the UDC, I have to select a target folder's parent folder in the tree so that target folder displays in right-hand list, select target folder in right-hand list, hit hotkey, then click target folder again in the tree to show its contents.

ryanagler wrote:If i want to use the hotkey for the UDC, I have to select a target folder's parent folder in the tree so that target folder displays in right-hand list, select target folder in right-hand list, hit hotkey, then click target folder again in the tree to show its contents.

If I understand you correctly, it seems that what you want is to use the current path, instead of the current List item (item focused&selected on List).

To do that, simply replace in your script <curitem> by <curpath> and then regardless of what item is selected on List, it is the current path that will be treated/converted.

jacky wrote: If I understand you correctly, it seems that what you want is to use the current path, instead of the current List item (item focused&selected on List).

To do that, simply replace in your script <curitem> by <curpath> and then regardless of what item is selected on List, it is the current path that will be treated/converted.

Thanks, curpath does work on the tree -- but then, that breaks copying a filename in the right-hand list. Really what I am looking for is for it to use whatever is currently highlighted in blue, whether that is a folder in the tree or a file in the list, using a single hotkey.

ryanagler wrote:Thanks, curpath does work on the tree -- but then, that breaks copying a filename in the right-hand list. Really what I am looking for is for it to use whatever is currently highlighted in blue, whether that is a folder in the tree or a file in the list, using a single hotkey.

Well, what you could use then is <focitem> instead. This will return the focus item, that means :

- if focus is on Tree, the focused item is selected as well, so it is the current location

- if focus is on List, it will be the focused item, which may or may not be the selected item. Selected items are highlighted in blue by default, while the focused item is the one with the little dotted line box around its name. (More on this on the wiki here)

I think this is the closest to what you want here.

PS: Seems there's a bug currently with <focitem> because the path returned when focus is on Tree does include a backslash ( \ ) at the end, while it should not.

PeterH wrote:

jacky wrote:As Don said, it goes along with the substr function of PHP. It is common usage, so it makes sense to find it here in XY as well.

I'm afraid there are a lot of systems, some count strings from position 0, some from pos 1. Wouldn't it be best to take the better version - whatever? And I wouldn't have posted my question, if there wouldn't be the discrepancy of 1 = 2nd character, but -1 = 1st character from the end. So if 0 is the first char, I would ask for -0 to be the last char...

You see, the blatant absence of "-0" in our number system causes the trouble...

About the position 0/1. As jacky said I simply go with PHP here, and AFAIK it is the more common way to use 0 for the first position. I know only one language that uses 1: my own (VB)! So if even I opt for 0 here...

ryanagler wrote:So I have been using XY and Directory Opus for over a year now, and I find myself switching back and forth because each one has its specialty. I find XY to be orders of magnitude faster browsing linux network shares, which is what I spend mot of my time working with, so Id prefer using XY for as much as I can.

So, is the issue settled for you now? I think it should be.

Tell me if you find any other reason to switch to DO once in a while.

admin wrote:About the position 0/1. As jacky said I simply go with PHP here, and AFAIK it is the more common way to use 0 for the first position. I know only one language that uses 1: my own (VB)! So if even I opt for 0 here...

Sorry - I still don't understand. (Again...)
What's more intuitive?
- take the first character, or
- take char with offset 0 from start of string?

When programming and having a pointer I understand, why the second form is better - use an offset if an offset is needed!
But when handling a (sub)string in a script I normally don't think of offsets. And I don't understand the intention of any language forcing me to do so, no matter if these languages are used more or less...

In this situation it's quite funny, that the use of -0 for the "first char from the end" is unusable

PeterH wrote:

admin wrote:About the position 0/1. As jacky said I simply go with PHP here, and AFAIK it is the more common way to use 0 for the first position. I know only one language that uses 1: my own (VB)! So if even I opt for 0 here...

Sorry - I still don't understand. (Again...)
What's more intuitive?
- take the first character, or
- take char with offset 0 from start of string?

More intuitive is probably using 1 for the first. But if you have experience with programming you are likely to be used to using 0. I go with the de facto standard this time. It's not bad enough to warrant a detour.

jacky wrote:PS: Seems there's a bug currently with <focitem> because the path returned when focus is on Tree does include a backslash ( \ ) at the end, while it should not.

Thanks, fixed.

In programming, our version of "Which came first? Chicken or egg?" is "0 or 1?"!
Been there...done that...many times! It all depends on how it was coded...I've run into both so often...the worst is when it depends on which command/function is being used, so there is no consistency.

j_c_hallgren wrote:In programming, our version of "Which came first? Chicken or egg?" is "0 or 1?"!
Been there...done that...many times! It all depends on how it was coded...I've run into both so often...the worst is when it depends on which command/function is being used, so there is no consistency.

Yep.

I think another advantage of using 0 is that you don't have an illegal value between -1 and 1.

admin wrote:I think another advantage of using 0 is that you don't have an illegal value between -1 and 1.

Hey - you are joking? Almost every number is illegal. (Or leads to no result.) But allowing the 0, by making 1 the opposite of -2? Strange...
And if you always would refer to how others make things instead of making what you think it's best, XY would be a copy of win explorer...
OK - if scripting explicitely is intended for programmers, I understand your position. But I've learned, that by designing and interface (for users) it's best not to think like a programmer - though I know it's not easy.

But don't get me wrong, I don't expect this to be changed. Just want to show why I don't understand your arguments.

Take a look at this script: That's not the result I would expect, are my expectations wrong?

I can get around it by making it replace "^(.+)$" with "+$1" but I'm confused by the current behavior and where the additional lines are coming from.

TheQwerty wrote:Take a look at this script:

Code: Select all

 //Test with items from list.
 Focus(L);
 SelPos(1,2);
 #101;
 RegExReplace($r, <clipboard>, "^", "+");
 Msg("|$r|");

That's not the result I would expect, are my expectations wrong?

I can get around it by making it replace "^(.+)$" with "+$1" but I'm confused by the current behavior and where the additional lines are coming from.

Line feeds are 0d0a (2 bytes).

well,
i blame microsoft first they decide to use CRLF as end of line
than they make a regex engine that in multiline mode will match the position after CR or LF as the start of a new line

ofcourse you could use "^(?!\x0a)" instead of "^" to get the expected result.

which is still not what TheQwerty wanted since it'll also add a + to the start of the last and emty line thats always there (theres a new line added after each list item, even the last).

to get that you use "^(?!\x0a)(?=.)" instead of "^".

note:
LF (Line Feed): \n Matches a newline character. Equivalent to \x0a and \cJ
CR (Carriage Return): \r Matches a carriage return character. Equivalent to \x0d and \cM.