From: "João Távora" <joaotavora@gmail.com>
To: Jonas Bernoulli <jonas@bernoul.li>
Cc: joseph@ushin.org, adam@alphapapa.net, 67390@debbugs.gnu.org
Subject: bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator
Date: Sat, 25 Nov 2023 00:03:10 +0000 [thread overview]
Message-ID: <CALDnm51mFNghCZiMFThKrLyjeoLidbzKZiDvQf6+Ou8sJ88XAQ@mail.gmail.com> (raw)
In-Reply-To: <87msv2vmzf.fsf@bernoul.li>
On Fri, Nov 24, 2023 at 9:51 PM Jonas Bernoulli <jonas@bernoul.li> wrote:
> I haven't found any issues beside this off-by-one font-lock issue.
Good.
> So far I have used this beauty:
>
> diff --git a/lisp/emacs-lisp/shorthands.el b/lisp/emacs-lisp/shorthands.el
> @@ -57,7 +57,7 @@ shorthands--mismatch-from-end
> for i from 1
> for i1 = (- l1 i) for i2 = (- l2 i)
> while (and (>= i1 0) (>= i2 0) (eq (aref str1 i1) (aref str2 i2)))
> - finally (return (1- i))))
> + finally (return (if (eq (aref str2 (1+ i2)) ?-) (1- i) i))))
>
> Is that good enough? Depending on how you look at it, this changes what
> is being returned, but IMO this function is a bit murky to begin with.
A bit dodgy, no :-) Maybe a docstring would shed some light
on what this function is supposed to do, so I'll propose one below.
> The function name is `shorthands--mismatch-from-end', but it returns the
> length of the common suffix, minus one, to account for the separator.
> This change ensures that the separator is accounted for, even if it
> differs between the shorthand and real symbol.
>
> Since this function returns the length of the *matching* suffix after
> the prefixes (including separator), I find it weird that its name
> contains *MISmatch*.
Probably I wanted to emulate what CL's MISMATCH does to some degree.
cl-mismatch exists in Emacs, but it's not available in shorthands.el,
and it seems to be buggy anyway.
You can rename the function shorthands--common-suffix-length if
you want. I probably meant it to be separator-agnostic function,
and be replaceable by a cl-mismatch some time around 2084,
Now to your problem: I think what you want is to customize element
comparison (CL's MISMATCH allows that, btw). Here's one way.
diff --git a/lisp/emacs-lisp/shorthands.el b/lisp/emacs-lisp/shorthands.el
index 82200ab88e9..36a862bc037 100644
--- a/lisp/emacs-lisp/shorthands.el
+++ b/lisp/emacs-lisp/shorthands.el
@@ -52,11 +52,18 @@ elisp-shorthand-font-lock-face
:version "28.1"
:group 'font-lock-faces)
-(defun shorthands--mismatch-from-end (str1 str2)
- (cl-loop with l1 = (length str1) with l2 = (length str2)
+(defun shorthands--mismatch-from-end (str1 str2 &optional test)
+ "Compute position of first mismatching element of STR1 and STR2, from end.
+The return value is the reverse index of that element. If 0, the
+last characters of STR1 and STR2 differ, if 1, the penultimate
+characters differ, and so on. If optional TEST is passed,
+compare elements using that function, else compare with `eq'."
+ (cl-loop with test = (or test #'eq)
+ with l1 = (length str1) with l2 = (length str2)
for i from 1
for i1 = (- l1 i) for i2 = (- l2 i)
- while (and (>= i1 0) (>= i2 0) (eq (aref str1 i1) (aref str2 i2)))
+ while (and (>= i1 0) (>= i2 0)
+ (funcall test (aref str1 i1) (aref str2 i2)))
finally (return (1- i))))
(defun shorthands-font-lock-shorthands (limit)
And now using the following lambda for TEST yields what you want:
(shorthands--mismatch-from-end "s-tail" "long-tail") ;; => 5
(shorthands--mismatch-from-end "s/tail" "long-tail"
(lambda (c1 c2)
(or (and (eq c1 ?/) (eq c2 ?-))
(eq c1 c2)))) ;; => also 5
Of course, you can hardcode this test inside the function, no need
for a parameter, and rename the function to whatever you find more
appropriate. This allows us to keep control over what things
are considered acceptable separators from a font-locking perspective
> It might make more sense to return the length of the shorthand prefix.
I've been away from this code for a couple of years, so feel free to
propose more extensive changes. As long as they don't increase the
complexity and are suitably tested, I have nothing against.
> Also, have you considered throwing in a
> (not (string-equal (match-string 1) sname))
>
> to avoid having to call `shorthands--mismatch-from-end' at all?
Where and how this be thrown in? How would you know what to highlight
in the shorthand printed form? There can be many shorthand prefixes
in a given file. But do show some code.
> Maybe you have, but concluded it is cheaper to do a bit too much work
> for non-shorthands, than to effectively repeat some work for shorthands.
Maybe. Not sure this is more work (string-equal must still compare
every character right?), but, in summary, I'm not married to this
implementation. I somewhat appreciate that I could still read it
after not having looked at it for a couple years, but feel free to
change it.
João
next prev parent reply other threads:[~2023-11-25 0:03 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-22 22:18 bug#67390: 28; shorthands-font-lock-shorthands assumes shorthand uses same separator Jonas Bernoulli via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-23 12:57 ` João Távora
2023-11-24 21:51 ` Jonas Bernoulli via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-25 0:03 ` João Távora [this message]
2023-11-25 3:26 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-25 16:01 ` Jonas Bernoulli via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-25 22:42 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-26 13:52 ` João Távora
2023-11-26 20:35 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-26 22:02 ` João Távora
2023-11-27 3:48 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-27 12:10 ` Eli Zaretskii
2023-11-29 8:21 ` João Távora
2023-11-29 9:12 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-29 13:56 ` João Távora
2023-11-29 13:30 ` João Távora
2023-11-29 23:27 ` João Távora
2023-11-30 14:16 ` João Távora
2023-11-30 15:23 ` Eli Zaretskii
2023-11-30 15:29 ` João Távora
2023-12-09 18:50 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-03 7:10 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-03 14:50 ` João Távora
2024-02-03 19:43 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-03 22:25 ` João Távora
2024-02-03 23:48 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-21 22:05 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALDnm51mFNghCZiMFThKrLyjeoLidbzKZiDvQf6+Ou8sJ88XAQ@mail.gmail.com \
--to=joaotavora@gmail.com \
--cc=67390@debbugs.gnu.org \
--cc=adam@alphapapa.net \
--cc=jonas@bernoul.li \
--cc=joseph@ushin.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.