Re: [proof of concept] inline language blocks

[Samuel Wales <samologist@gmail.com>]

at risk of being like a broken record [over many years]: i still like
cl lambda lists e.g. $[thing arg :kw value :kw value] or %(thing ...)
for allowing generality to basically all new syntax of most types,
extensibility, user-defined major ["thing"] and minor [":kw"] features
if desired to support, reduced parsing risk, ability to control
display and export and visibility and folding and other stuff like
locale or whatever, nestability, escaping/quoting, and familiar
defined syntax, all applicable to new features without having to
change anything.  also, you won't have to look up how to use it much
when you use a new feature.

i'm not expressing this as well as i have in unpublished posts or
previous posts.

i might be in the minority, and it was once said that it is too
verbose.  if so, i value desiderata like the above higher.

i feel org has proliferated different syntaxes and special cases a bit
too much.  it's hard to have to look up what's needed, detect errors
manually etc.  some of the more basic  things are good with special
syntax, such as emphasis and \\.  but we contend with invisible space,
variant quoting, ....

there is a school of thought that more types of syntax are usually
good; in most cases, i do not agree with that school of thought.

it's a bit like the old conflict between lisp vs. the original perl.
i never agreed with larry wall on arguments like [paraphrased,
possibly not correctly] "english is not orthogonal; lisp is, which is
bad; perl is not orthogonal; it shouldn't be because english isn't [or
perhaps for the [unspecified] reasons english isn't]".  plenty of
human languages are orthogonal in places where english isn't, and i
believe they work well in those places because of, not in spite of,
that convenient orthogonality.  you can know how to get the transitive
if you have the intransitve, for example.  i say this despite being a
huge fan of english.


for language feature, there are various options here which range from e.g.

:fr{some text in French}

being expressed as

$[lang :fr "bonjour"]

which i think is pretty straightforward and not much more verbose,

to a more block style like this

$[lang :fr :start]
bonjour
$[lang :fr end]

and of course that "lang" can be replaced with any other new feature
we dream up, having nothing to do with languages.  all the
meta-features like parsing, quoting, invisibility, folding,
nestability, extensibility will already have been worked out, and will
apply to new features and sub-features.


On 2/21/24, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Ihor Radchenko writes:
>
>> Juan Manuel Macías <maciaschain@posteo.net> writes:
>>
>>>> We need to finalize inline special block syntax first, and then talk
>>>> about special cases like inline language markup you propose.
>>>
>>> As I already said, in my local branch I have both elements created,
>>> based on the same syntax:
>>>
>>> - language block: :lang{text}
>>>
>>> - special block &type{text}
>>>
>>> the latter would be exported, for example, to html as <span
>>> class="type">text</span> or to LaTeX as \type{text}
>>>
>>> I like the syntax because it is minimalist and not verbose at all. That
>>> could serve as a basis (at least it is good to have a starting point,
>>> because otherwise everything will be diluted in discussions). Then we
>>> can start thinking about whether to add options and how to add them.
>>
>> We do not need to design the inline special block markup fully to
>> introduce it. However, we do need to make sure that whatever simple
>> version of inline markup we introduce does not prevent further planned
>> extensions.
>
> My proposed syntax could be:
>
> &type[options]{content}
>
>> My main concern is the possibility to introduce multi-argument markup.
>> Like @abbrev{EA}{example abbreviation}. This will be necessary to
>> achieve parity with Texinfo markup.
>> However, it is not yet clear about the best syntax to pass multiple
>> arguments.
>
> I imagine multiple arguments would depend on each backend, right?
> Because I don't quite see much sense in html, for example. However, it
> occurs to me to reuse content, and add some separator character:
>
> &type[options]{arg1::arg2::etc}
>
> or better:
>
> &type[options and aditional args]{content}
>
> to maintain a certain parallelism with the large blocks.
>
> --
> Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
> editorial y ortotipografía
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com