Received-SPF: pass (google.com: domain of seladwa@gmx.de designates 212.227.15.19 as permitted sender) client-ip=212.227.15.19;
Message-ID: <52CB3AC2.3070507@gmx.de>
Date: Tue, 07 Jan 2014 00:22:42 +0100
From: selpa'i <seladwa@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: lojban@googlegroups.com
Subject: Re: [lojban] [oz] Use of elidable {cu}
References: <CALMa68qddROnjBs-HBeR4C_eZwXikkb26KRHHgYShQHg+mVpQQ@mail.gmail.com>
In-Reply-To: <CALMa68qddROnjBs-HBeR4C_eZwXikkb26KRHHgYShQHg+mVpQQ@mail.gmail.com>
Reply-To: lojban@googlegroups.com
Precedence: list
Mailing-list: list lojban@googlegroups.com; contact lojban+owners@googlegroups.com
Sender: lojban@googlegroups.com
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam_score: 0.0
X-Spam_score_int: 0
X-Spam_bar: /

la .asiz. cu cusku di'e
> I know about the "cmevla as brivla" rule in the translation grammar. But
> still there remains a great amount of elidable {cu} occurrences
> throughout the text.

There may be some that really are elidible, but I'm fairly sure that=20
most of the {cu} that seem elidible actually are not. I will explain why=20
below.

> E.g.,
>
> (1) {lo zd=C5=95ni cu pu se cintypu'i}
> (2) {la nakf=C5=95mti .x=C4=8Dnris. cu no roi cm=C4=9Bla}

These two are truly stylistic choices, but there is an advantage to=20
using {cu} before TENSE+selbri. It makes it less likely to accidently=20
say something like the following (at least I assume that's true):

    lo nu broda pu cinri
    ! "The event of brodaing in the past is interesting."

Using {cu} before {pu} is necessary there to prevent the accidental=20
slipping of the {pu} into the abstraction. So maybe that's one reason to=20
use {cu} even when it's not necessary: to be less likely to forget it=20
where it must be used.

> (3) {xy ji'a cu gr=C5=AFsi}
> (4) {ca lo c=C5=95bdei cu na k=C4=8Dlci}

Probably the same habit as in (1) and (2).

> Granted, these are perfectly correct. It just made me curious to hear
> any thoughts you have on the usage of {cu}.
>
> In any case, the common usage exemplified above seems inconsistent with
> more rare examples such as
>
> (5) {sei ny sp=C5=AFda}
> (6) {sei ny sp=C5=AFsku} (3 times)
> (7) {pa la m=C5=95xpre pu p=C5=88nse}
> (8) {la .oz. na d=C5=AFnda lo b=C4=8Dsna do}
> (9) {la .t=C5=88tos. ca lo n=C5=AFncfa na n=C4=8Dlci lo vi ziljm=C4=9Bna =
be lo b=C4=8Dnde}
> (10) {la .d=C5=88rotis. na sai ka'e v=C4=9Bska}
> (11) {la .t=C5=88tos. ja'a ka'e go'i}

The actual answer to your question is this: What happens when you erase=20
all the spaces from the text? The answer to this question will reveal=20
why there are {cu} in seemingly unnecessary places. To name just one=20
general example ({nu} is by far not the only place where it occurs):

{nu + BY + broda} =3D lujvo (nuBYbroda}
{nu + BY + cu + broda} =3D abstraction containing a bridi

In other words, leaving out {cu} will make the text parse differently!=20
I'm very careful with that; one needs to keep in mind that the whole=20
point of my orthography is to have full audio-visual isomorphism - the=20
speech stream should fully correspond to the string of letters. There=20
are no spaces in the speech stream. Everything depends on clusters and=20
stress. Therefore, spaces are to be meaningless in writing, too. And my=20
orthography enables exactly that: to omit all the spaces. You can either=20
use {cu} to prevent the accidental lujvo as in the example above, or you=20
can use a glottal stop, like so:

{nu + BY. + broda}

Then, it also cannot parse as a single word.

You will find both methods used in the text.

mi'e la selpa'i mu'o

--=20
You received this message because you are subscribed to the Google Groups "=
lojban" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to lojban+unsubscribe@googlegroups.com.
To post to this group, send email to lojban@googlegroups.com.
Visit this group at http://groups.google.com/group/lojban.
For more options, visit https://groups.google.com/groups/opt_out.