Sublime Forum

Goto Definition should respect target file already opened in non-single layout

#1

Hi,

I love the feature of opening a file defining the function/variable and directly jumping to it. It also behaves as expected when other definition is onened on the same target – it reuses the file in the editor. But, it seems the feature does not work across multiple layouts.

I work in two-column mode with, for example, controllers on the left side and routes on the right. Files on both sides are from the same Project. When I click on a Definition on a route (on the right), the correct (controller) file is targeted, but instead of switching cursor/focus to the controller file already open (on the left) – which should be the expected behavior, a new view of the same file (same path) is opened next to the route (on the right).

I’m using ST3, 3126.

Thanks in advance for looking into this :slightly_smiling:

Best regards,
VipSaran

1 Like
#2
1 Like
#3

I see… So, lots of "me too"s, acknowledged as a bug, moved to the “other repo” and that is where I lost track of it as there was no link to the “other repo” :frowning:

I know this is a minor issue, but out of curiosity: is this still planned?

0 Likes
#4

you could have a go at fixing it yourself, and then submitting your patch diff as a comment on the issue.

Take a look in the Packages/Default/symbols.py file, specifically at the open_location method and the navigate_to_symbol/highlight_entry method. I see it uses an undocumented flag FORCE_GROUP. Maybe removing that will help? Otherwise, try changing it to lookup if the file is already open in any group in the window, and activate that view if it is, rather than always calling window.open_file…

2 Likes
#5

+1

The open issue is also locked and so we are unable to +1 the issue.

I’m a fan of the +1, it can reflect the priority of something. There’s always an easy way to solve the +1s issue: 1) fix it or 2) acknowledge and schedule it e.g. assign it to a clearly defined milestone.

0 Likes
#6

I’ve unlocked the issue, I hadn’t noticed that earlier - it looks like it was locked as it was moved to the different repo and then what that repo got disbanded, it was re-opened but not unlocked. So you can vote on it now with GitHub’s reactions - please don’t just put a +1 as a comment as it email spams everyone subscribed to the repo. (I’m not saying I think you’d do that, just want to point out that if people want to write something, please make sure it is constructive.)

1 Like
#7

Yes, by adding +1 I mean GitHub reactions, not commenting +1.

0 Likes
#8

As you suggested, I’ve removed the | sublime.FORCE_GROUP (from Default/symbol.py, line 57) and the functionality now works as expected :slightly_smiling:

I’ve tried with 3 columns and 2 views of the target of the Definition and it also works fine (the last one that was highlighted gets the focus --> expected).

Next steps?

0 Likes
#9

next steps are to wait and see if the ST devs will decide to include your change in a future build of ST :wink:

it would be trivial to create a new preference to control the behavior, such that the old functionality could be kept for people that want it, so they shouldn’t be worried about it being a breaking change I think :slight_smile:

3 Likes
#10

Not corrected in build 3143…

Even though Default package in 3143 contains the code:

def open_location(window, l):
    fname, display_fname, rowcol = l
    row, col = rowcol

    window.open_file(
        fname + ":" + str(row) + ":" + str(col),
        sublime.ENCODED_POSITION | sublime.FORCE_GROUP)

that corrected the error in the previous build, still the new instance of the file is opened even though the target file is already open in another column.

Possibly another change made this workaround/fix obsolete?

0 Likes
#11

Hmmm … I think I’m missing something about to actually go about editing Default/symbol.py.

I’m on ST4 (4136) BTW … does this change things?

I can extract the file with PackageResource but as for actually altering the code that gets run by Sublime … that escapes me as it’s not clear where the file is actually coming from and where to save it to.

0 Likes
#12

If you use PackageResourceViewer, it takes care of putting the file in the place and name that it needs to be, so you can just make the change and save (but don’t; use OverrideAudit instead, which has a Create Override command in the command palette that does the same thing, but safer, and will tell you when your override is out of date).

How the content of the file might have changed is a whole other topic though. If I had to guess the content is somewhat different now based on bug fixes and new features added in the new build, so while the same sorts of changes may still work, they may not need to be in the same part of the file.

0 Likes
#13

Right, thanks! And thanks for the OverrideAudit recommendation … didn’t know about it. Package Control link here for the curious … from my experience so far … excellent package!!

I didn’t quite figure that such a “hack” was a good idea at all, let alone something worth doing … I now worry that a pandora’s box has been opened for me :smirk:

Is this another one of those sublime things that people just come to know? Or is there one of your wonderful videos on it that I haven’t watched?

FWIW, the basic idea of the fix still seems to work.

I just went through Default/symbol.py searching for all instances of flags = sublime.ENCODED_POSITION | sublime.FORCE_GROUP and removed the sublime.FORCE_GROUP flag. Without knowing the ins-and-outs of the module, all such instances seemed to target the desired functionality (going to definitions in already opened buffers) and it appears to work for me so far.

0 Likes
#14

The idea of augmenting a package is a very Sublime thing indeed; I don’t have a video on modifying this particular hing though.

I would say though that despite potential augmentations, backwards comparability in the API is high priority, so if removing that flag worked in ST3 then all else being equal it will also do the same in ST4.

0 Likes
#15

Yea I think the obstacle for was not knowing about how much of the sublime interface was written in python using the sublime API. Maybe I did something to remove it, but I didn’t have a Default package in my Packages directory until I “augmented” it … so it wasn’t really a “discoverable” feature or behaviour for me. I still don’t even know where the Default package is coming from!

But thanks so much for your help on this!!

0 Likes