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

smartparens breaks LaTeX quotation marks mechanism for language styles #1100

Open
vitaminace33 opened this issue Aug 24, 2021 · 5 comments · May be fixed by #1151
Open

smartparens breaks LaTeX quotation marks mechanism for language styles #1100

vitaminace33 opened this issue Aug 24, 2021 · 5 comments · May be fixed by #1151

Comments

@vitaminace33
Copy link

Expected behavior

Press ["] once to get «.», twice for "." (or vice-versa if TeX-quote-after-quote is non-nil).

Notes

  • Brackets indicate a key.
  • Dot indicates the point or cursor position.
  • Double angular brackets are the hypothetical current value of TeX-quote-open and TeX-quote-close but could be different depending on the applied language style, e.g. "< and ">, respectively.
  • Check AUCTeX's reference manual for regular (non-electric) behavior.

Actual behavior

Press ["] once, depending on the value of TeX-quote-after-quote and if TeX-quote-open and TeX-quote-close are single or double characters, different behavior are present. Worst case scenario is that only part of the quote string is inserted, moreover partly in the previous line and partly in the current, while deleting a previous character. Refer to syl20bnr/spacemacs#15003 for specific "experiments".

Steps to reproduce the problem

  1. On vanilla Emacs, install auctex and smartparens.
  2. Open a .tex file including \usepackage[german]{babel} (parsing on load must be activated to successfully load the language style).
  3. Write any quote. Again, refer to [WORKAROUND] LaTeX quotation mechanism is broken syl20bnr/spacemacs#15003 for specific "experiments".

I leave here my .emacs for reference.

(require 'package)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t)
(package-initialize)
(require 'smartparens-config)
(setq TeX-parse-self t) ; Enable parse on load.
(setq TeX-auto-save t)  ; Enable parse on save.
(custom-set-variables
 '(package-selected-packages '(smartparens auctex)))

Workaround

A workaround has been documented in syl20bnr/spacemacs#15003 that allows the use smartparens.

Environment & version information

  • smartparens version: 20210817.1912
  • Active major-mode: latex-mode
  • Smartparens strict mode: nil
  • Emacs version (M-x emacs-version): GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2020-09-19
  • Starterkit/Distribution: Vanilla
  • OS: gnu/linux (Ubuntu 20.04)
@thobl
Copy link

thobl commented Oct 14, 2022

The above mentioned workaround improves the behavior for German quotes (by a lot) but does not resolve the issues completely.

When pressing ", it inserts "`▂' (with ▂ being the cursor) instead of "`▂"'. When finishing the quote and pressing " again, it correctly inserts "' at the end, but leaves the additional ' from before, i.e., typing "foo" gives me "`foo"'▂' instead of "`foo"'▂.

For better reproducibility, here is my tex-code:

\documentclass{article}
\usepackage{ngerman}
\begin{document}
"`foo"'
\end{document}

And here the value I have set TeX-quote-language-alist to:

'(("ngerman" "\"`" "\"'" nil) ("german" "\"`" "\"'" nil))

@dschrempf
Copy link

Hi, I just want to state that this is still an issue.

@Fuco1
Copy link
Owner

Fuco1 commented Mar 16, 2023

Since TeX-insert-quote provides its own behaviours, the easiest would be to disable smartparens handling of quotes if you prefer the auctex way.

(sp-local-pair 'latex-mode "`" nil :actions nil)
(sp-local-pair 'latex-mode "\"" nil :actions nil)
(sp-local-pair 'latex-mode "``" nil :actions nil)

I'm sure it could be made to work together, for example by dynamically adding pairs based on TeX-quote-language, then if you insert the opening smartparens would insert the ending. But I guess this is also somehow implemented in auctex itself.

To be completely honest, I don't really use tex anymore so this is not very high priority for me. Plus I don't understand how auctex handles this and what users expect, so it's really hard to create a good solution. We can brainstorm some ideas and if there is consensus something can be implemented. But a safe way would be to defer the quote handling to auctex.

@dschrempf
Copy link

Hi!

Thanks for your reply. I have played around a bit, and I sincerely do not understand what is going on.

Using

(sp-local-pair '(tex-mode plain-tex-mode latex-mode LaTeX-mode) "``" nil :actions nil)

I can normally write a single double quote " in the comments, but NOT in the
rest of the document. For example, typing " would insert a triple of ```
I can not see how smartparens distinguishes comments from non-comments. It could
be that AucTeX mode is doing some magic behind the scenes, but well.

Then, further deactivating

(sp-local-tag '(tex-mode plain-tex-mode latex-mode LaTeX-mode) "\"" nil nil :actions nil)

doesn't really change things (which is a further indication that we are
observing a weird interaction with AucTeX).

Finally, deactivating

(sp-local-pair '(tex-mode plain-tex-mode latex-mode LaTeX-mode) "`" nil :actions nil)

leads to classic AucTeX behavior: In LaTeX comments, insertion is unchanged. In
the document (non-comments), a single ` or ' are inserted without further
changes. A double quote " is changed to a double `` quote at the beginning of
a word, and a double '' (two ' quotes) at the end of a word, as expected (only the insertion
has to be manual, and not automatic like with smartparens)

So in the end, I think it is probably best to deactivate all three quotes in smartparens-mode, as you suggested (but use all four modes like in this comment). I can create a PR, if you like.

Finally, I do not understand what this statement does in smartparens-latex.el:

  (sp-local-tag "\"" "``" "''" :actions '(wrap))

Should we also remove it?

@Fuco1
Copy link
Owner

Fuco1 commented Mar 16, 2023

Yea, tags no longer exist

@dschrempf dschrempf linked a pull request Mar 16, 2023 that will close this issue
@Fuco1 Fuco1 added this to Triage Mar 18, 2024
@Fuco1 Fuco1 moved this to To triage in Triage Mar 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: To triage
Development

Successfully merging a pull request may close this issue.

4 participants