unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: chen bin <chenbin.sh@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: [PATCH] add 'string-distance' to calculate Levenshtein distance
Date: Thu, 19 Apr 2018 11:05:52 +0300	[thread overview]
Message-ID: <83wox3zkm7.fsf@gnu.org> (raw)
In-Reply-To: <CAAE-R+-YRbMNMMt67hz2XHrBeAj+By4mhOo13vj_cuF-R=wJfw@mail.gmail.com> (message from chen bin on Tue, 17 Apr 2018 22:31:20 +1000)

> From: chen bin <chenbin.sh@gmail.com>
> Date: Tue, 17 Apr 2018 22:31:20 +1000
> Cc: emacs-devel@gnu.org
> 
> As you suggested, I re-write the code using 'FETCH_STRING_CHAR_ADVANCE'.

Thanks.

> I also implemented the byte comparing version. It's 4 times as fast. And I do
> need use it to compare file path in my package 'counsel-etags'.

File names are just strings for this purpose, and they can potentially
include any non-zero characters.  So I don't see why they are special.

> The fille path couldn't contain any funny characters (emoji). so
> it'sperfectly fine
> to use byte comparing version.

File names can very well include emoji and other "funny" characters,
Emacs supports that on all modern systems (including even MS-Windows).

> diff --git a/etc/NEWS b/etc/NEWS
> index 5aa92e2991..3cce2c48c7 100644
> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -490,6 +490,8 @@ x-lost-selection-hooks, x-sent-selection-hooks
>  +++
>  ** New function assoc-delete-all.
>  
> +** New function string-distance to calculate Levenshtein distance between two strings.

This long line should be filled using the fill-column setting we use
in NEWS.  Even better, make the header a short summary, like

  ** New function 'string-distance'

and then describe its functionality in a separate sentence that starts
immediately below that header.

> +DEFUN ("string-distance", Fstring_distance, Sstring_distance, 2, 3, 0,
> +       doc: /* Return Levenshtein distance between STRING1 and STRING2.
> +If BYTECOMPARE is nil, we compare character of strings.
> +If BYTECOMPARE is t, we compare byte of strings.

Please lose the "we" part, it's inappropriate in documentation,
because it describes what Emacs does.

> +Comparing by byte is faster and non-ascii characters has weighted distance.

I would delete this sentence, it is IMO confusing more than anything
else.  (And I still think the bytewise comparison is not needed.)

> +  bool use_bytecompare = !NILP(bytecompare);
                                ^^
Space between these 2 characters.

> +  else
> +    {
> +      int c1, c2;
> +      ptrdiff_t i1, i1_byte, i2, i2_byte;
> +      i2 = i2_byte = 0;
> +      for (x = 1; x <= len2; x++)

Please move the initialization of i2 and i2_byte into the for-loop
initializer (suing the comma operator).

> +          i1 = i1_byte = 0;
> +          for (y = 1, lastdiag = x - 1; y <= len1; y++)

Likewise here with i1 and i1_byte.

Thanks.



  reply	other threads:[~2018-04-19  8:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-14  2:35 [PATCH] add 'string-distance' to calculate Levenshtein distance Chen Bin
2018-04-14  7:05 ` Eli Zaretskii
     [not found]   ` <87lgdq831h.fsf@gmail.com>
2018-04-14 13:24     ` Eli Zaretskii
2018-04-14 16:40       ` Chen Bin
2018-04-14 17:08         ` Eli Zaretskii
2018-04-15  7:15           ` Chen Bin
2018-04-15 14:47             ` Eli Zaretskii
     [not found]               ` <CAAE-R+-RDWvyrv+uqHszzh6VMH6An3disOw=PyPWaTnUTHDOCw@mail.gmail.com>
     [not found]                 ` <83k1t72b2o.fsf@gnu.org>
2018-04-17  2:43                   ` chen bin
2018-04-17 15:44                     ` Eli Zaretskii
2018-04-18  7:11                       ` chen bin
     [not found]                   ` <CAAE-R+8s++_LRcQCLX60Z=TQeQHdtbM5X1k525bfNnnPSLDvRw@mail.gmail.com>
     [not found]                     ` <83bmei36dw.fsf@gnu.org>
2018-04-17 12:31                       ` chen bin
2018-04-19  8:05                         ` Eli Zaretskii [this message]
2018-04-19 14:55                           ` chen bin
2018-04-20  4:37                             ` chen bin
2018-04-20  6:01                             ` Thien-Thi Nguyen
2018-04-20 10:47                             ` chen bin
2018-04-21  7:22                               ` Eli Zaretskii
2018-04-21 20:47                                 ` Juri Linkov
2018-04-28  7:36                                 ` Eli Zaretskii
2018-05-06  9:53                                   ` chen bin
2018-04-15 18:53             ` Paul Eggert
2018-04-14 17:18 ` Nathan Moreau
2018-04-14 17:36   ` Paul Eggert
2018-04-15 18:17     ` Andreas Politz

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83wox3zkm7.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=chenbin.sh@gmail.com \
    --cc=emacs-devel@gnu.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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).