On 2020/04/30 07:58:09, dak wrote: > On 2020/04/30 07:42:16, hahnjo wrote: > > On 2020/04/27 11:58:11, dak wrote: > > > Tracker issue: 5946 (https://sourceforge.net/p/testlilyissues/issues/5946/) > > > Rietveld issue: 577840053 (https://codereview.appspot.com/577840053) > > > Issue description: > > > Use Scheme_hash_table for keyword handling > > > > We should probably decide between these two approaches, we likely can't do > both. > > I see the advantage of using SCM values for everything, but I'm not familiar > > with the code. > > I think it makes more sense here not to introduce new data types for a job that > is inherent to Scheme's operation. Having both patches on countdown at the same > time obviously does not make sense: if discussion is required (Han-Wen?), it > would make sense to stop both until this is resolved. > > An independent component is the removal of ly:lexer-keywords . There is no > indication that it ever has been used; it is cheap to provide with my version. > However, revisiting its code I also see that it takes a lexer as an argument. > My patch, like Han-Wen's, stops lexers from having their individual keytable (an > implementation detail that was never used for any purpose). So even if the > function were retained, letting it take an argument, while making for backwards > compatibility, does not appear to make sense. This could be addressed in a > separate patch/issue. Or it could be removed in a separate patch/issue. > > One possible use for it would be using LilyPond itself for generating syntax > highlighting for editors. The current solutions rather extract stuff from the > source I seem to remember.
1) we can take dak's patch if you prefer. They're roughly equivalent anyway. 2) I suppose ly:lexer-keywords was for editor modes, but it hasn't been used for that. Updating the scripts to generate the modes is extra work, so I vote for removing it. If nobody bothered in the last 13 years, it can't be that important. https://codereview.appspot.com/549920043/
