lilypond-devel
[Top][All Lists]
Advanced

[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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]