Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
To expand:
Generally I'm not sure this change is a good idea.
Agree, especially if its not possible for the user to reverse it. The example given to support preventing autocomplete is headings in markup languages, but many of those languages allow cross references to headings, but the cross reference has to use the correct heading text, and autocomplete provides that. So although such languages may have less use for autocomplete, such languages are not entirely without use-cases for autocomplete.
The UI only provides control of autocomplete by one global setting in the prefs dialog, but practical projects have a mix of filetypes, Markdown docs and C files for example. Using the UI to control autocomplete when switching documents in the project is impractical, perhaps it could be per document, but that requires UI (and the document menu is already the largest) and the user to set it every time a document is opened.
Hence my suggestion of a filetype file setting, that way it can be controlled per language by the default value in the filetype file and modified by the user in their local filetype file. Whilst that modification is not convenient it is likely to be one-off, change the default for the language and be done with it.
Or the above could be combined, the filetype file sets the default value when a document is opened and the UI can change an individual document in the rare case that the user has a need contrary to the filetype selection. This then reduces the need for filetype file modifications since rare use-cases can be handled per document.
Anyway it doesn't sound like something to rush into 2.0.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.