For languages like Markdown tag manager is used to display an outline of the document in the sidebar but the generated tags aren't really meant for autocompletion where they don't make much sense. Without this patch typing a word from e.g. a heading of markdown invokes the autocompletion popup anywhere in the edited text which is quite annoying.
Apart from languages that use tags for the sidebar outline (ABC, asciidoc, bibtex, ini/conf, diff, docbook, latex, markdown, rest, txt2tags, HTML), there's also JSON where autocompletion doesn't really work because tags are generated for json strings such as keys but autocompletion doesn't work inside strings currently so when one types ", the following string doesn't get autocompleted.
This is how the current behavior looks like for LaTeX:
<img width="565" alt="Screenshot 2023-10-04 at 23 17 44" src="https://github.com/geany/geany/assets/713965/2c023c53-9f6c-4448-8125-9c5f4ed...;
and this is for Markdown:
<img width="601" alt="Screenshot 2023-10-04 at 23 13 55" src="https://github.com/geany/geany/assets/713965/c24056e5-fa59-444d-b280-3059178...;
I'm not sure if it's related to the changes made in this release or if it behaved this way before too but since it's quite annoying and the patch is hopefully a low-risk one, it could be worth considering for Geany 2.0. You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3575
-- Commit Summary --
* Disable autocompletion for most non-programming/non-scripting languages
-- File Changes --
M src/editor.c (5) M src/tagmanager/tm_parser.c (23) M src/tagmanager/tm_parser.h (2)
-- Patch Links --
https://github.com/geany/geany/pull/3575.patch https://github.com/geany/geany/pull/3575.diff
I left autocompletion on for SQL where it's used for stored procedures and it is useful and for CSS where I'm not 100pct sure if it's useful or not but at least makes some sense.
I suggest this be a setting in the filetype file, not a hard coded magic list.
I suggest this be a setting in the filetype file, not a hard coded magic list.
Agree. And the user must be able to override this.
For Latex, I definitely disagree with this change. When I used Latex for my master's thesis I enjoyed auto-completion for my custom macros as well as long words.
Generally I'm not sure this change is a good idea. If you don't need auto-completion then the pop-up is relatively easy to ignore or cancel if it obscures something important. On the other hand, if you enjoy auto-completion it'll be very hard to get it back.
OK, I just wasn't sure if I didn't introduce this with my TM changes. I noticed this when writing README.md for the LSP plugin but the truth is that I used ProjectOrganizer with indexing whole Geany, including all its unit tests, and then saw various nonsense there.
And yes, I agree it should be filetype-configurable - I'll have a look at it at some later point.
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.
Closed #3575.
github-comments@lists.geany.org