Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[timwtheov]

The new delimiter is a semicolon only, not a semicolon with a space, so the functions will not write a list the way you want going forward.  You will have to adjust.

You can however DISPLAY things however you want by parsing a list using the ListItem() function and manipulating the contents for display, instead of just displaying the raw list.  This is a thread about bugs, so if you want help with that, please start a new thread elsewhere asking for help on how to use ListItem. You might perhaps first read about it here.

As I said in this post

https://yabb.jriver.com/interact/index.php/topic,125608.0.html

readability is a problem when you get rid of the space after semicolons if you use such in view schemes. Right now I have a number of classical music views that use the simple expression

Code: [Select]

ListBuild(1, ;, [artist])
where [Artist] contains any number of semicolon delimited items, depending on artists in the recording, i.e., there might be only conducter; orchestra, or it might be vocalist; soloist; ensemble; conductor; orchestra, and so on. With the new semicolon stuff, the lists get mashed together without spaces and thus get hard to read (plus, they just look crappy, are incorrect in terms of the English language and so on).

I build [Artist] from a custom expression field like the following after tagging from AMG using amg.pl:

Code: [Select]

=If(!IsEqual([Genre], Classical, 1), [Album Artist (auto)], If(IsEmpty(ListBuild(1, ;, [Soloists], [Vocalist], [Conductor],  [Orchestra], [Ensemble]), 0), [Album Artist (auto)], ListBuild(1, ; ,[Soloists], [Vocalist], [Ensemble], [Conductor], [Orchestra])))
So: I don't want crappy-looking view schemes without spaces (what, are we in ancient Rome again? why not get rid of spaces between words too!  ), and Wer suggested using ListItem in my view. Trouble is, as per usual, the expression language wiki is for me unintuitive (to say the least), and I'm therefore not seeing any means of getting spaces back from ListItem in combination with all the if isequal/if isempty stuff. So again, Wer, help!!

[RoderickGI]

I think Wer's answer was brutal, but fair.

Also, as an English teacher, you should recognize a semicolon delimited list, with or without a space, is not gramatically correct. This is data, not an English Language sentence. Deal with it.

You would never see; for example; a sentence which explained; in simple terms; how to write English; old English not new; like this.

We are talking about data, not the English language.


Try this:

ListCombine([Artist], ,;,;/ )

[timwtheov]

@Roderick, I missed that last bit of nastiness on the part of Wer. I was trying to be lighthearted in my original, but I guess my tone didn't translate. Speed kills.

He's wrong, though: you couldn't have a semicolon-delimted list on its own and be grammatically correct, but you can certainly use semicolons in a list, especially a long one; and in older iterations of English, even as recent as the early 20th century, writers often used semicolons like commas. Spacing isn't grammar either: it's technically mechanics (punctuation, spelling). But he's as out of his depth with English as I am with programming/expression language. 

OK, and yes, a fair point, about the fact that we're talking about data, for as I said, it makes no difference to me how it works on the backend, but when stuff is on display . . . that matters to me (and probably to others on here that use expressions, even simplistic ones, in their views). And to be fair, too, when I'm looking at text in a display/view, we are talking about the English (or some non-programming) language, are we not? I'm not reading code there.

Thanks for the expression! By the way, what does the "/" do exactly? I know the */ */ (do I have that right?) escapes what's inside, but what does a lone / do, generally speaking? 

[wer]

He's not wrong.  You're displaying a semicolon delimited list on its own, and thinking a space improves it grammatically. That's just silly.  Don't think of it as nastiness, think of it as a response to frivolous pedantry.  So please don't try to make false comparisons between written language and data syntax.  It's out of place and wrong-headed.

Instead, learn about how you can use the expression language....

Why don't you try something like this, which should satisfy you completely:

Code: [Select]

The artists are Listitem([Artist],0,;) and Listitem([Artist],1,;).
The point is if you don't like the way something is displayed in MC, you can change it - if you take the time to learn.  I'm sure that, as an English teacher, you often run into students who just want to be given the answer, instead of trying to learn the underlying concepts that will enable them to achieve success not only with their current problem, but with future undertakings as well.

By using the ListItem function, you can extract data elements from the list, manipulate them however you choose, and insert them back into a string suitable for display in any situation, no matter what your requirements.  The MC Expression Language performs data processing, and does not conform to any rules other than its own syntactical structure.  English grammar is irrelevant. It's data in, and data out.  You can choose to make the data output look as much like English as you'd like, as my example above demonstrates.

My example outputs an English-language sentence because the MC parser treats anything not recognized as an expression as literal text to be quoted.

In the MC Expression Language, the / character functions as a type of quotation character, or escaped literal in data processing parlance, that ensures that the character that follows it, a space in that case, is processed literally by the interpreter. In the case Rod provided, it has the effect of adding a space to the output.

Have fun...

[timwtheov]

@Wer, a couple of points, and then I'll drop this, as I know it's unproductive.

As I said above, it's a question of mechanics (spacing's not grammar) and more importantly readability, not "frivolous pedantry"--that is, the space simply helps readability on the screen when I search through classical works or albums or whatever. I completely understand the difference between "data syntax" and written language: the former is what I'm calling "the backend" in previous posts. Again, I could care less if there are spaces between semicolons or none when I'm dealing with expressions themselves; but when what those expressions make appear on the screen is a mashed-together string, then some of the usability of the software is diminished. Yes, I could get used to it, but I was guessing there was a way not to make the display of my classical artist lists, which I use a lot, so hard to read. That's all I was after.

Expression language: no need to preach here, as I've tried again and again to learn how to use it fluently. I can in fact do some rudimentary stuff, but the syntax just makes my head hurt after a while. I get the logic of all of it, as it's pretty simple stuff, but it reminds me why I switched from programming to English in college 28 years ago (and destroyed my income potential, alas).

Thanks for the expression!

[RoderickGI]

Actually it's not completely unproductive.

MC Expression language functions used to always take care of the space. But with more complex functions, a lot of them recently, and some older functions not taking the space into account we ended up with a mixture of some that handled the space and some that didn't, and we only found out by trial and error. So the users that are doing a lot of expressions discussed it with Matt and decided to go with no space.

Matt still isn't comfortable with the new paradigm.

All functions could be made to handle the space, I believe, but it would be a lot of work. Particularly for some of the new functions. Plus there are a lot of complex new functions.

Readability of fields in Standard View and Theatre View is an important issue. Capitalisation of each record in a list, and the detailed Views in Theatre View compensate for this a bit.


So, if enough people really had an issue with the missing space, I guess Matt could go through the functions and fix them. I don't know that for sure though. Let's see what happens.

[zybex]

(what, are we in ancient Rome again? why not get rid of spaces between words too!  )

Welcome to Germany.

[lepa]

For me to store and to display are two different things. I want store a list in format which is easiest to manipulate and don't leave room for guessing (i.e. rules must be the same everywhere). When it is stored in that way it is now easy to display it anyway I want.

There is of course some glitches in that like you cannot edit data which is displayed using expression but I mostly don't expect to edit data in place which I have decorated to be displayed more nicely.

[zybex]

Fully agree Lepa.

It's fine to change the list separator to ";", and tune the existing ExpressionLanguage code to deal with it. It simplifies things.
For UI however, MC could have an option in settings for user to enter the "list separator" which would be used when displaying lists. User could select from a list or could enter a custom separator to get lists to display like e.g. "Portugal/Spain/France". Internally and in code/EL, everything would still be semicolon-only.

[mwillems]

Actually it's not completely unproductive.

MC Expression language functions used to always take care of the space. But with more complex functions, a lot of them recently, and some older functions not taking the space into account we ended up with a mixture of some that handled the space and some that didn't, and we only found out by trial and error. So the users that are doing a lot of expressions discussed it with Matt and decided to go with no space.

Matt still isn't comfortable with the new paradigm.

All functions could be made to handle the space, I believe, but it would be a lot of work. Particularly for some of the new functions. Plus there are a lot of complex new functions.

Readability of fields in Standard View and Theatre View is an important issue. Capitalisation of each record in a list, and the detailed Views in Theatre View compensate for this a bit.


So, if enough people really had an issue with the missing space, I guess Matt could go through the functions and fix them. I don't know that for sure though. Let's see what happens.

For my part, I get the data/display distinction, and think that a display including a space is significantly more readable.  This change broke the display of several of my views and I'm not a fan of breaking changes, in general, but I get why the change is helpful. I'm happy to put in the work on my end to deal with a breaking change that actually improves things for other folks, but:

You're displaying a semicolon delimited list on its own, and thinking a space improves it grammatically. That's just silly.  Don't think of it as nastiness, think of it as a response to frivolous pedantry.  So please don't try to make false comparisons between written language and data syntax.  It's out of place and wrong-headed.

I think some of the comments in response to this are gratuitously unpleasant, both in the prior thread this branched from and here.  It's not a choice between being right and being kind, one can easily be both.

[timwtheov]

I like Zybex's idea: having a display choice would be nice, though I don't know how much work it would be to integrate.

For my part, I get the data/display distinction, and think that a display including a space is significantly more readable.  This change broke the display of several of my views and I'm not a fan of breaking changes, in general, but I get why the change is helpful. I'm happy to put in the work on my end to deal with a breaking change that actually improves things for other folks, but:

Yes! this was exactly how I felt last night when I noticed the mashed-together strings.

Anyway, RoderickGI's short expression fixed my view, but then my semicolon-delimited artists look bad on their own; but then again, I haven't had a chance to play around with Wer's expression, so maybe that will be fixed too. At any rate, again, I like Zybex's idea: keep the (necessary) expression changes but give us some display choices.

[wer]

Personally I found the whole approach of "I'm an English teacher and this is wrong" to be gratuitously unpleasant.  Others are free to think differently.

We already have the tools to display the elements of a list however is desired, with or withheld a space or in any other fashion. It can be setup once per view and then forgotten about.  As someone mentioned, displaying a list just as text with semicolons between elements doesn't look very good anyway, with or without an extra space. 

Theater view displays list fields as separate rows of text, so it looks decent.  Standard view has always displayed lists as an ugly row of cluttered text, and the presence or absence of a space doesn't significantly change that.  But if you don't like it, you can just reformat it.

I get that people don't like to have to adjust for change. Expressions have to be modified. Zybex had to change his app. But things like this have happened in MC before.  This change does not really increase the burden for output beautification.  I think it was a smart change to make, and I don't have a problem modifying my expressions to match. It's a minor inconvenience.

[jherbert]

Glad to see others noticed this change, too.

As most complaints concern readability (which is really bad now) why not just add an option on the display side: add space after delimiter when displayed in any view.

I under stand I can build a custom view to do that, but that would require me to know how to do it (I don't) and it would render predefined views useless.

On a side note field content now is not consistent any more: Older entries still feature "; " while new ones lack the space.

[JimH]

We will fix the readability issue.

[Otello]

Any news on the readability issue? 

[Hendrik]

Lists should be formatted with a space between elements on display, while still being stored in the database without one in the latest version of MC26 and MC27.

[Otello]

Lists should be formatted with a space between elements on display, while still being stored in the database without one in the latest version of MC26 and MC27.

Well, maybe I'm missing something.  ?
At the moment I get the old data in my DB correctly displayed, (with space after semicolon), but new entries have no space.
Please look at the attached image: the first edition is in my DB by long time and is correctly spaced, the second, a new entry, don't. (V.26.107 and 27.11)

[Matt]

It's only in the actual list the formatting is changed.  The header text will just show as is.