[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fix most encoding problems with Guile 2.x (issue 555420043 by addres
From: |
jonas . hahnfeld |
Subject: |
Re: Fix most encoding problems with Guile 2.x (issue 555420043 by address@hidden) |
Date: |
Sun, 08 Mar 2020 01:42:29 -0800 |
On 2020/03/08 09:37:23, hanwenn wrote:
> On 2020/03/08 09:33:24, hahnjo wrote:
> > On 2020/03/07 23:15:09, hanwenn wrote:
> > >
>
https://codereview.appspot.com/555420043/diff/549710049/lily/text-interface.cc
> > > File lily/text-interface.cc (right):
> > >
> > >
> >
>
https://codereview.appspot.com/555420043/diff/549710049/lily/text-interface.cc#newcode70
> > > lily/text-interface.cc:70: SCM ligature = ly_assoc_get (substr,
> > > replacement_alist, SCM_BOOL_F);
> > > this whole thing is a bit clumsy. Couldnt we do
> > >
> > > for k, v in replacement-alist
> > > str = re.sub(k, v, str)
> > >
> > > (python code, but you get the idea.)
> >
> > While simpler, your code does not do the same. The currently
implemented
> > algorithm is really text replacement per textbook: Try the longest
replacement
> > first to make sure we match the longest substring at each position.
This
> > warrants the "clumsy" structure as you call it.
>
> Well, what if you sort the replacements by decreasing size?
Yes, but you still have to check every position and not do a global
search-and-replace.
> If you want to keep this around, can you add a comment why it needs to
be like
> this,
> with an example where my simplistic approach wouldn't work.
https://codereview.appspot.com/555420043/