[Markdown] Add headings to symbol index?

[FichteFoll]

Currently, headings in markdown are only added to the local symbol list for navigation, but I believe it also makes sense to add the to the indexed list for section navigation in the whole project.

Opinions?

[michaelblyons]

I like it. [Edit: I think my hopes were that typing a word that had a ReadMe would lead you somewhere helpful, but reasonable arguments have been made against indexing.]

What do you think about adding link (or [link]) from [link]: https://example.com and [text][link] to the local index?

[keith-hall]

It might be a bit weird to get Goto Definition offer markdown headings... Would you also update the indexed reference list for anchors linking to the headings?

[FichteFoll]

What do you think about adding link (or [link]) from [link]: https://example.com and [text][link] to the local index?

Hm, I think adding URL definitions to the local symbol list (not "index") might be a good idea. I'll experiment with that locally. Not sure what you want to do with [text][link] references, though. Goto Definition requires the symbols being indexed.

It might be a bit weird to get Goto Definition offer markdown headings...

It's unfortunate that you can't decouple these, but I suspect exact collisions between markdown headings and class (or other) names will be few.

Would you also update the indexed reference list for anchors linking to the headings?

Can references for markdown headings be transformed? Otherwise I don't see how this could possibly work out, considering most markdown interpreters create anchor links using hyphens as the alphanumeric joiner.

[deathaxe]

Not sure which - maybe Markdown Editing - package added headings to the global index, but I found that annoying in the long term and disabled it.

It may make sense when working in a documentation only project, but mixing that up with other entities in the Goto Definition?

What's the general use of having them in the global index?

Headings especially some sub headings (H2, H3, ...) maybe something which is relevant in the current document only and may not be useful without context.

[FichteFoll]

It may make sense when working in a documentation only project, but mixing that up with other entities in the Goto Definition?

I agree that I am writing this from the perspective of a documentation project, but I don't see how one or two markdown files would pollute the project symbols too much, unless you name your headings exactly like your function or class names. With the new kind hints, sections are easily distinguished from function or class definitions, by the way.

Still, if that imposed a problem, I would rather suggest to separate goto definition and the project-wide "go to symbol" feature, because there are a couple usage difficulties with that, like not being able to go to a symbol in the current file without also adding it to the index.

[deathaxe]

I just remembered the Goto Symbol Palette had been flooded by # Haadfa ###dfasdfasdf stuff, which somehow mixed up with other stuff. If captions appear as normal strings, maybe the experience is better. Haven't investigated that too much.

... difficulties with that, like not being able to go to a symbol in the current file without also adding it to the index.

I am curious about why they shouldn't be found by lookup_symbol_in_open_files_by_kind() with the help of the local SymbolList entry. Does it make use of the IndexedSymbolList entries only as well?

see Default/symbols.py

def lookup_symbol(window, symbol, kind=sublime.KIND_ID_AMBIGUOUS):
    index_locations = window.lookup_symbol_in_index_by_kind(symbol, kind)
    open_file_locations = window.lookup_symbol_in_open_files_by_kind(symbol, kind)

In general I agree local symbols in the currently open document should be part of the Goto Definition without being published project wide.

There are a couple languages like Erlang, Pascal or Perl, which define functions locally but export only few of them by explicit statements. Those syntaxes need a local symbol index in order to prevent leaking local functions project wide.