GNU bug report logs - #78053
[PATCH] Support strings for electric-pairs.

Previous Next

Full log

Message #32 received at 78053 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: 78053 <at> debbugs.gnu.org,
 João Távora <joaotavora <at> gmail.com>
Subject: Re: bug#78053: [PATCH] Support strings for electric-pairs.
Date: Mon, 26 May 2025 12:03:00 -0400

>>> +     ((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).


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.