Subject: Re: bug#78053: [PATCH] Support strings for electric-pairs.

From: Eli Zaretskii <[email-masked]>
Date: Sat, 07 Jun 2025 11:39:46 +0300

> Cc: [email-masked],
>  João Távora <[email-masked]>
> Date: Mon, 26 May 2025 12:03:00 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <[email-masked]>
> 
> >>> +     ((if-let* ((str-pair
> >>> +		 (cl-loop for pairs in fallback
> >>> +			  do
> >>> +			  (if (and
> >>> +			       (stringp (car pairs))
> >>> +			       (looking-back
> >>> +				(regexp-quote (car pairs))
> >>> +				(- (point) (length (car pairs)))))
> >>> +			      (cl-return (cdr pairs))))))
> >>> +	  (list 'str str-pair nil nil))))))
> >>
> >> BTW, here you could use `compare-buffer-substrings`.
> >
> > Thanks, Can you explain how to use it in this case?  AFAIK
> > `compare-buffer-substrings' needs 2 strings in the buffer for the
> > comparison.
> 
> Duh, you're right, it can't be used here.
> We should probably extend `compare-strings` to accept buffer arguments
> and then obsolete `compare-buffer-substrings'.
> 
> >>>  (defun electric-pair--insert (char times)
> >>>    (let ((last-command-event char)
> >>> @@ -591,6 +604,11 @@ electric-pair-post-self-insert-function
> >>>                                pos))
> >>>           (forward-char num))
> >>>          ;; Insert matching pair.
> >>> +        ;; String pairs
> >>> +        ((and (eq syntax 'str) (not overwrite-mode))
> >>> +         (insert " ")
> >>> +         (save-excursion (insert " " pair)))
> >>> +        ;; Char pairs
> >>>          ((and (memq syntax '(?\( ?\" ?\$))
> >>>                (not overwrite-mode)
> >>>                (or unconditional
> >>
> >> I can imagine some multi-char delimiters which don't call for spaces
> >> inside of them (e.g. LaTeX's ``...''), so maybe the entries in
> >> `electric-pair-pairs` should have some extra info about it.
> >> I suggest we replace the (STRING . STRING) format with
> >> (STRING STRING ...) so we can put extra info in the `...`.
> >
> > Are you sure it's good idea to replace the cons cell form with a list?
> 
> We need to keep supporting the (CHAR . CHAR) form, of course, but yes,
> I think using (STRING STRING . PROPERTIES) is a better option than
> (STRING . STRING) and there is no backward compatibility need to
> support (STRING . STRING).

Is the last patch okay to install?  If not, Elijah, would you please
submit an updated patch?