Sublime Forum

Sublime Text 3 "goto definition" case sensitivity

#1

Absolutely love ST3. Got a question tho.

I write mostly SQL which is a case insensitive language. The goto defintion feature workes wonderfully (once I did some light hacking on the definition file). The matching regexes work properly: they do case insensitive matching when requested. However, when I f10 on a token that is different in terms of case, it will not find the definition:

create table foo();

Foo <- f12 will not match the definition

foo <- f12 will match the definition

Is there any way to fix that?

1 Like
API Suggestions
#2

+1
My concern too. Most funcions/class are case-insensitive, so it’s make sense for Goto Definition to ignore case

1 Like
#3

Use symbolIndexTransformation to transform all the symbols to lowercase, you’ll want something along the lines of:

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
    <key>scope</key>
    <string>source.sql</string>
    <key>settings</key>
    <dict>
        <key>symbolIndexTransformation</key>
        <string>/.*/\L$1/;</string>
    </dict>
</dict>
</plist>

Save this to “SQL Symbols.tmPreferences” (only the extension is important). Let me know how you go.

2 Likes
#4

The regex should be: /(\w)/\L$1/g

Still not work. Example: Symbol list has “plist”.
Goto Definition on “plist” does well
Goto Definition on “Plist” says “Unable to find Plist”

I think we need to convert both symbol_at_point(view, pt) AND symbol Index to lower case

P.S: ST updated to Oniguruma version 5.9.6?

1 Like
#5

You can enter view.indexed_symbols() in the Console to see what symbols are being indexed in the current file. These will have already had any transformations applied to them, so the key part is verifying that they’ve all been transformed to lower case. If not, the primary thing to check would be that the scope is set correctly (i.e., is source.sql the correct scope for the file you’re editing). You can check the tmPreferences file is being applied by entering ‘view.meta_info(‘symbolIndexTransformation’, 0)’ in the Console and verifying that the above setting is present.

Yes, Goto Definition would need some changes to handle lower case transformation, but Goto Symbol in Project will only need the above.

1 Like
#6

Edited my previous post as the correct regex should be “/(\w)/\L$1/g”

0 Likes
#7

@Jon: please have a look at your symbol.py

[code]def symbol_at_point(view, pt):
symbol = view.substr(view.expand_by_class(pt,
sublime.CLASS_WORD_START | sublime.CLASS_WORD_END,
“]{}()<>:.”))
locations = lookup_symbol(view.window(), symbol)

if len(locations) == 0:
    symbol = view.substr(view.word(pt)).lower()
    locations = lookup_symbol(view.window(), symbol)

return symbol, locations[/code]

Please change symbol = view.substr(view.word(pt))tosymbol = view.substr(view.word(pt)).lower()

0 Likes
#8

I don’t think changing all function lookups to use smaller case is a good idea. It would make it unusable for case-sensitive languages where you define an upper case and a lower case variant of the same letters, and also would require ALL languages to add transformations to lower case.

Imo this needs an additional setting for tmPreferences, something along the lines of “symbolCaseInsensitive”, which then tells symbol.py it should change the case of the current word to lower case, or maybe add case-insensitive functionality elsewhere.

2 Likes
#9

Is there any update on this? I would also like a case-insensitive goto definition for Fortran. I think the idea of the symbolCaseInsensitive tmPreference is the best option.

1 Like
#10

Yes please.
Working with case insensitive language will be easier.

0 Likes
#11

Could anyone find a solution for this?

0 Likes
#12

I have not tried, but is it possible to apply my “workaround” to specific language? i.e: save this .py file into language-specific package (so that it override default symbol.py):

import sublime, sublime_plugin

def symbol_at_point(view, pt):
    symbol = view.substr(view.expand_by_class(pt,
        sublime.CLASS_WORD_START | sublime.CLASS_WORD_END,
        "[]{}()<>:."))
    locations = lookup_symbol(view.window(), symbol)

    if len(locations) == 0:
        symbol = view.substr(view.word(pt)).lower()
        locations = lookup_symbol(view.window(), symbol)

    return symbol, locations
1 Like
#13

Probably the way I would do it, would be to create/update a tmPreferences file with a custom key, something like caseInsensitiveSymbols, and then in the symbol_at_point method, read the value of this variable (using view.meta_info('caseInsensitiveSymbols', pt), defaulting to False if unspecified) and then decide which case sensitivity logic to use :slightly_smiling:

EDIT: oh, I see FichteFoll already suggested this :slight_smile:

0 Likes
#14

I think this method will not work, as it will only change the binding of symbol_at_point within this language specific plugin, and will not be used when goto_definition is called from somewhere else.

0 Likes
#15

Hi,

Have someone the solution to this problem. I am a fortran developer and this feature will help me.
Thanks

0 Likes
#16

VHDL is also a case insensitive language and I’ve had a user point out that Goto Definition will only find case sensitive matches. It would be helpful to have a tmPreferences flag that could mark a index search as case insensitive.

0 Likes