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 <maciasch...@posteo.net> wrote: > Ihor Radchenko writes: > >> Juan Manuel Macías <maciasch...@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