Smart open, double click on file in long list, goes back to start

[rowbearto]

I am using the Smart Open with 25.0.0.1 and have a directory open with lots of files. When I scroll down and double click on one of the later files in this list "starting with letter 'u'", the file list gets redisplayed starting from the first files in alphabetical order, so that to get back to files that start with letter 'u' (I want to open another similarly named file) I have to scroll down again, which  This is annoying to have to scroll down again.

I don't recall this behavior in 24.0.2.

[Dan]

I think this issue is reported here as well https://community.slickedit.com/index.php/topic,17503.0.html.

[rowbearto]

OK. This is on Linux x64 for me and soon after I reported it stopped happening. I haven't had the time to narrow down when it does/doesn't happen.

[jc44]

If it is the same issue as mine then the critical thing that makes it occur is that you scroll down and double-click on the file without any other clicks in the window.  Any other selection ops and it all works. (And yes - it is annoying)

[Clark]

This issue is a very different issue than:

https://community.slickedit.com/index.php/topic,17503.0.html

This issue is caused because a lot of operations require the list to be refreshed (clicking on a file or opening a file). No attempt is made to keep the scroll location the same after the list is refreshed. It's easy to reproduce this issue. You just need are large project and to scroll to the bottom of the list.

[jc44]

So is this the same issue where if I open the buffer list (Brief: Alt-b); move the cursor line with either cursor keys or just clicking on another buffer; hit Alt-D to delete the buffer then my cursor returns to my initial buffer rather than staying where it was put like it did before?

[Clark]

It is a similar issue. After you close the file using the Files tool window (buffer list) it gets refreshed.

[jc44]

Just to check - this is listed as a bug to be fixed please (still exists in Beta-4)?  My normal method of pruning buffers that I am editing relies on being able to hit Alt-D multiple times to delete multiple buffers.  My buffer lists are growing in a worrying fashion! (I know there are other ways to do what I want but this is the way I've always done it and it is very hard to unlearn.)

[Clark]

Just to check - this is listed as a bug to be fixed please (still exists in Beta-4)?  My normal method of pruning buffers that I am editing relies on being able to hit Alt-D multiple times to delete multiple buffers.  My buffer lists are growing in a worrying fashion! (I know there are other ways to do what I want but this is the way I've always done it and it is very hard to unlearn.)

RC1 (next installer) will have an experimental fix for the Files tool window which is off by default. Set the macro variable def_switchbuf_filelist to 0. This will allow you to press Alt+D without the selected item jumping around. I'm pretty sure it won't break anything but I'm not sure if this change will annoy others. Definitely not enough time to beta test this change to make it the default.

[jc44]

Just to check - this is listed as a bug to be fixed please (still exists in Beta-4)?  My normal method of pruning buffers that I am editing relies on being able to hit Alt-D multiple times to delete multiple buffers.  My buffer lists are growing in a worrying fashion! (I know there are other ways to do what I want but this is the way I've always done it and it is very hard to unlearn.)

RC1 (next installer) will have an experimental fix for the Files tool window which is off by default. Set the macro variable def_switchbuf_filelist to 0. This will allow you to press Alt+D without the selected item jumping around. I'm pretty sure it won't break anything but I'm not sure if this change will annoy others. Definitely not enough time to beta test this change to make it the default.

Ummm... I'm asking for a regression fix not a new feature. In all previous versions of SE going Alt-B (Brief)  gets a buffer window with the cursor line on the current buffer, then hitting Alt-D would delete that buffer and leave the current selection as the buffer after the one I've just deleted. In the current version after I've deleted a buffer the cursor jumps to the very first entry in the list.  This means you cannot just hit Alt-D three times to delete three sequential buffers like you could in all previous versions.

[Clark]

After further investigation, looks like an easy fix. Originally a callback had a bug so it typically did nothing. In this case, it means it's safe to just remove the callback which appears to do redundant work. Totally not obvious given the history of changes.

[jc44]

Hurrah! I will finally close some files!