Files in the buffer are opened in reverse order than they were added

[vitor]

When actioning files from the File Buffer, they are opened in the reverse order than they were added in. This may not seem like it would make much of a difference, but it does.

For example, when opening multiple image files in a file editing application, the order may not be what we expect. As another example, picking a bunch of video/audio files to open at once (so they play in sequence) will play them in the wrong order.

When we have a sequence of files, adding them all to the File Buffer in order is simple (keep ⌥↓ing), but adding them in the reverse order is not as simple (and not as logical).

Is there any technical reason why it is done this way?

Alfred 2.8.1 (425).

[Andrew]

I've just had a play with this and Alfred is actioning the buffer items in the order you see, so the behaviour may be caused by the destination software.

 

i.e. if I have pdf1, pdf2 and pdf3 in the buffer and use "Open With..." in Preview, I see that Asks OS X to open pdf1 in Preview, then pdf2 in Preview, then pdf3 in Preview.

 

One thing I remember a long time in the past was an odd behaviour where some software wasn't correctly buffering up the open requests and would buffer up while the app was launching, opening these ones after the app had launched and dealt with the latest open with commands.

 

Try using the buffer with the destination app open and see if you get different behaviour.

 

Cheers,

Andrew

[vitor]

Seems like you’re right.
 
I was seeing this mainly with mpv, but before opening the bug report I did try in other ways, one of which was just to echo the files with RunCommand and they did appeared in the reverse order¹. Doing it today I can’t reproduce with RunCommand, so now I’m questioning my own sanity a bit. Actioning the files to mpv via the GUI version doesn’t work anymore (though I’m certain it did before) as it only opens one of the files (but still the wrong one). I did upgrade recently, so that might be part of the issue. Calling mpv with its CLI version (via RunCommand) does work, though, which suggests the behaviour you noticed in the past might’ve been the culprit here as well.

Apologies for the noise. Closing.

——————————
¹ Or so I thought, but I could swear that was the case.