sublimehq / sublime_text

Issue tracker for Sublime Text
https://www.sublimetext.com
811 stars 39 forks source link

Goto Definition could prefer language syntax scope definitions first #335

Open gerardroche opened 10 years ago

gerardroche commented 10 years ago

Example

You have 2 files of different languages rb and php.

# exporter.rb
module Export
  class Exporter
  end
end

and

// exporter.php
class Exporter {}

and your current working file is a php file

// current.php
$variable = new Exporter();

With the cursor anywhere on Exporter, run the command Goto definition....

Actual

The overlay lists two possible definition locations:

1: exporter.rb
2: exporter.php

Expected

Goto definition... to only use the current scope. In the case above, Goto definition... would just directly to the php definition because that was the scope when Goto definition... was triggered.

At the very least the php definition should be listed first.

1: exporter.php
2: exporter.rb

I prefer for Goto definition... to use the current scope, because I can't even think of a valid use case where I would expect, in use cases like this, to goto the rb definition.

Vim

Vim for example, by default, jumps to the first definition. However, it also allows modifiers to the jump e.g. N where n is a index of the list so 4C-] would jump to the 4th possible definition, it also allows to jump or show list if more than one possibility.

g                       *g*
                    ** *CTRL-]*
CTRL-]          Jump to the definition of the keyword under the
            cursor.  Same as ":tag {ident}", where {ident} is the
            keyword under or after cursor.
            When there are several matching tags for {ident}, jump
            to the [count] one.  When no [count] is given the
            first one is jumped to. See |tag-matchlist| for
            jumping to other matching tags.

re: http://vimdoc.sourceforge.net/htmldoc/tagsrch.html

keith-hall commented 8 years ago

It's probably better to limit the goto definitions to the current scope. When you press Goto definition... in a php scope do you really want definitions other than php? I can't imagine why you would.

this has also been discussed a little bit here recently: https://forum.sublimetext.com/t/goto-symbol-in-same-language/23049

evandrocoan commented 8 years ago

Very similar to this other, actually solving that should fix this:

  1. https://github.com/SublimeTextIssues/Core/issues/1375, Jump to the closest upper symbol instead of the first one at the file's top on go_to_symbol command
michaelblyons commented 8 years ago

I use IronLangs which point from one language (say Ruby or Python) to another (like C#). I am totally cool with preferring the same language first, but I absolutely do not want other languages to be excluded.

Backlinking https://github.com/sublimehq/Packages/issues/647.

flux627 commented 8 years ago

This 3 year old issue seems more relevant now that linked definitions have a new accessible pop-over UI.

Thanks for the backlink @michaelblyons. This further confirms the need for having this configurable in settings.

Settings option could be a boolean named "scope_definitions_by_language". When true, it only shows definitions from the same language being viewed, and when false, it could prefer the same language as others have suggested.

Should the default be true or false? Maybe false to not throw off any current users?

keith-hall commented 8 years ago

I would suggest more customizability than a boolean toggle -> maybe a mapping of what base scopes to link to other base scopes?

evandrocoan commented 8 years ago

I would suggest more customizability than a boolean toggle -> maybe a mapping of what base scopes to link to other base scopes?

I proposed a more flexible way on: https://forum.sublimetext.com/t/goto-symbol-in-same-language/23049/2

I like it. If I have a symbol on a Pawn language file, I want it to point to the C++ file. So, a setting option to enable this behavior or not, is welcome. But of course, on an PHP/CSS project I would like this feature enabled.

Then instead of just enabled or disable crossed language symbol linking globally, add a setting to select what languages may not have crossed symbols. Example:

    "not_crossed_symbols_languages": 
    [ 
        { ["source.CSS", "source.PHP" ] },
        { ["source.Java", "source.C++" ] },
    ]

On the above example, only the symbols from CSS and PHP, will not be crossed, the same for the second line. But all other things as symbols not mentioned within the same line as from CSS, Java, C++, etc, are allowed to be crossed.

fredcallaway commented 7 months ago

I assume this isn't happening, but just in case... bump?