Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use completion-at-point and abbrev-mode for LaTeX substitution, take 2 #185

Merged
merged 18 commits into from
May 4, 2023

Conversation

tpapp
Copy link
Collaborator

@tpapp tpapp commented May 4, 2023

This finishes #100.

non-Jedi and others added 17 commits December 6, 2022 14:22
This is a version of #82 without the usage of :exit-function to
replace the LaTeX string with a unicode symbol.
This allows user abbrevs to keep on working with the expected behavior.
Hook into :exit-function to automatically replace LaTeX codes with
unicode symbols when completion is finished. This will not work when
ivy is used for completion due to
<abo-abo/swiper#2345>. Using abbrev-mode or
expand-abbrev still works for those users.
Co-authored-by: Tamas K. Papp <[email protected]>
See comments for reasoning. This commit allows company-mode users to comfortably press TAB
for completion of latex codes to unicode symbols. Previously, indent-for-tab-command would
fallback to emacs' native completion UI instead of using company.

This commit also contains a slight cleanup to make the :exit-function more robust to the
condition where abbrev-symbol fails.
This follows the pattern for conditional integration code from "net/tramp-integration.el".
This predicate ensures that the symbol you're trying to complete is a substring of the
completion candidates. With "before" completion this isn't necessary since there isn't
potential for the symbol you're trying to complete containing text that isn't intended to be
completed.

This commit also includes some refactors for clarity and DRY.
@tpapp
Copy link
Collaborator Author

tpapp commented May 4, 2023

@non-Jedi, thanks for the great work on this. I understand that you did not have to time to review my changes, but I have been using this version for months now and it works fine, on Emacs 28 and 29, so I am merging. A separate PR will remove support for 25.

@tpapp tpapp merged commit 0167210 into master May 4, 2023
@non-Jedi
Copy link
Contributor

non-Jedi commented May 9, 2023

Thank you for pushing this over the finish line @tpapp. And apologies for ghosting you a little bit with respect to non-Jedi#1. Hopefully we won't get a sudden raft of bug reports like #188, but I'll try to at least poke my head in a bit more often to triage those that I can.

@dhanak
Copy link
Contributor

dhanak commented May 18, 2023

Hello!

I have set up my Emacs to upgrade my (m)elpa packages automatically on a weekly basis. Thus, it came as a surprise to me that tab completion substitution for LaTeX symbols in julia-mode broke some time earlier this week. Then it took me a while to investigate the issue and track the root cause down to this PR.

Granted, I have ivy-mode installed, and I noticed the comments in the source code related to a bug. But that seems like an old issue, yet julia-mode worked perfectly until recently. Furthermore, there is nothing wrong with the substitution of LaTeX symbols which are unambiguous, e.g., \circeq, only those which have multiple possible suffixes, e.g., \circ and \in.

Moreover, when I type \circ<TAB> 99.99% of the time I want it to be substituted with the circle symbol, and not to be completed to some hardly ever used LaTeX symbol name that also happens to begin with \circ. The same goes for \in.

I spent the better part of an hour trying to figure out how to patch the change to bring the old behavior back, to no avail. I finally gave up and went back to the January 19 version of julia-mode which I restored from a snapshot.

Note that I don't really want to start using abbrev. As I switch back-and-forth between Emacs and REPL, I definitely want to use the same key to expand symbols, otherwise I'm sure to mess it up regularly.

I think this will be an issue for others as well, so I'd like to offer my help to come up with a solution that suits (almost) everybody.

@tpapp
Copy link
Collaborator Author

tpapp commented May 18, 2023

@dhanak, the issue is discussed in #193. We are planning to enable something like the old behavior, and would appreciate your input there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants