From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id SKWiKTF11mUN3QAA62LTzQ:P1 (envelope-from ) for ; Wed, 21 Feb 2024 23:12:01 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id SKWiKTF11mUN3QAA62LTzQ (envelope-from ) for ; Wed, 21 Feb 2024 23:12:01 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=m0Bcu+bE; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1708553521; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=Abxsly/162QZ6Q5AWh57i17sP9TZtlfDVPCTly0EA4Q=; b=D7C5JC4HIAXAgDOs1IulXPyzSdaI9HIeUCeA0L1ZHbB9n9tkbo7UPPFtwztRC9yw1oVall XYfp7L2FJWGpcmwfyplTlYlbBO9WUyxxrfiw202T+t5XvVj4Z7Dv5KFuIlKPVr+NCg3c6Z 4U/HjWsRcFAGfT2pqJzeo921YXHalB994oEpRynQSwk5CTUO1bdDwqnx2lmvoUP1Eycp9s RIQMFLOUJLXR0YbH2x3GKX4qzwhb1Bsbtcuufd5FMd2uGKGHvYHf6h+B0kIIOvhIlVbA0C 2/u7LEpGMGGF66fjKyCuuDwuRJPmggIus6G6c5ICUkU9KAtiAnDhUBckH9BoRg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=m0Bcu+bE; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1708553521; a=rsa-sha256; cv=none; b=hpz0GRYKpLPqugCe22Bd4DGAgnOVnxjk7IcC7bum4iHBvw9MHLDPfC4XupFw+Ki0DlmteS UG3NJbkg+m9f1QY+yfQEBqGRoGzssGDODOnfXsvD4BFRjFG3n1APrDoOO9lwEudgjje57o UriM+wIzz5e2i5QrfJa+XHaOAacMpkIyEvlPQVxiqO32shazF38JSaCFxJnZ+yERAudcnN ujWJAcQFnPXk8pPLR9+efVGNiMMc2a39Pd0KYFtTpLwoR224PMfqxsSb1La2breY76m/UC a/wdNwYswKjeOWRYQRvs/pN2NzGMsJ3w89GjKnkYaGPBgYWCnBRUWmlvoCVUpA== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 80FC416486 for ; Wed, 21 Feb 2024 23:12:00 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rcuoA-0002oW-NO; Wed, 21 Feb 2024 17:11:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rcuo9-0002o6-4i for emacs-orgmode@gnu.org; Wed, 21 Feb 2024 17:11:17 -0500 Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rcuo7-00047k-2S for emacs-orgmode@gnu.org; Wed, 21 Feb 2024 17:11:16 -0500 Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-5114a21176cso1831148e87.1 for ; Wed, 21 Feb 2024 14:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708553473; x=1709158273; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Abxsly/162QZ6Q5AWh57i17sP9TZtlfDVPCTly0EA4Q=; b=m0Bcu+bE5plsqOlcylAMg7/GLS5sL3PVw5fUcFtdqcTbtcSTHYU0gNEixcIoBz+bWY fah4fjpaQQOAvKHNko3DkhdQ22pjV/oy+MKnSq/ucbsac258S1L0IH3Ez0diX4DxwmOa Z9sSVoT23cNU5rX3CHYK0IKPZywj92/mEFH7XU1Dq7ydQD3f9AR/Cuf1GzfXCclfF3Sz pHN1pBwSGdJztaBMBFwARsOu2BihZYMVngssUqnAmBH8D2vU6r9U6uTnhti42/20Bif3 X0zwXI1M6zQiGgZ8B0WlOCX4BncNgg7G14gL+y/jEVR+2ctUIYpMITJzca4VdFa2Xz8L rHQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708553473; x=1709158273; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Abxsly/162QZ6Q5AWh57i17sP9TZtlfDVPCTly0EA4Q=; b=YZK/aahB0RcrzHv1JXKwUXoSLNCPeyBED0kGnoJqaCua6VpAe/2VVS1B3TQEGXePf3 B1BHKMi0pmgpBH8OvOaEapfIH4J3xvhd3rrLMCJHomcVO5hG13WFq2+sAccc+jwugKkp jqwZiu7iNm9rKQ1tNWHTBtvUVTZhhe8spwRkSxpQlfL2gVvXUyMIl6wuZdgytU/HDhuf vK5Ne+SJP+hHJQkRvCzehRwloCTPpnAjOx0jqYWKoXFApAfp1bbc6JvxBLI1Al5DWsaP bgVaM9UseHOXyzyoYiNCCgsu0I8nzASz6ePGcJdjT1na+8Uxskak1+eD6VvY1LtiVdvc i84A== X-Forwarded-Encrypted: i=1; AJvYcCVU3hT9xjYRHwpePPjBeGy63p/1NkF5AphU5ducVkx7GBo9yniSVLiAzYLDFELB79KPIgcmJXX4QVrLWKkGVaXLi2QSEQ4= X-Gm-Message-State: AOJu0YxPsYBbb5kHl1//by9xQyXlXkzHoDZfgMES5prSRTDupE64KKZW bZT5dc8sGHSGgZvQEkaj7xV6e9Qhygl8Dm1qukdLW0u2MQ4AN5N9fgCwzwHdjBaqmmjpjIdeUbt swAesN/qx2voFflLlmjFRNSVrazM= X-Google-Smtp-Source: AGHT+IGZSJye+Fhx8INA6fqRU0HE+5jliiOQ8TlEQRDQtZ1eFQbnQZbn66MqyE67xGFCwNVrC0nB1ZV/EQMzK7v0ubg= X-Received: by 2002:a05:6512:4023:b0:512:adb7:7951 with SMTP id br35-20020a056512402300b00512adb77951mr8515420lfb.5.1708553472357; Wed, 21 Feb 2024 14:11:12 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a9a:5589:0:b0:288:95f1:2d3b with HTTP; Wed, 21 Feb 2024 14:11:11 -0800 (PST) In-Reply-To: <875xyhzyzl.fsf@posteo.net> References: <87msrudgcn.fsf@posteo.net> <8734tmmcnv.fsf@localhost> <87edd6ytiy.fsf@posteo.net> <87sf1mrpr6.fsf@localhost> <87a5nuyo4w.fsf@posteo.net> <87frxmrmjb.fsf@localhost> <875xyhzyzl.fsf@posteo.net> From: Samuel Wales Date: Wed, 21 Feb 2024 15:11:11 -0700 Message-ID: Subject: Re: [proof of concept] inline language blocks To: =?UTF-8?Q?Juan_Manuel_Mac=C3=ADas?= Cc: Ihor Radchenko , orgmode Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::132; envelope-from=samologist@gmail.com; helo=mail-lf1-x132.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -9.56 X-Spam-Score: -9.56 X-Migadu-Queue-Id: 80FC416486 X-TUID: YQaydaEHjxLO 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=C3=ADas wrote: > Ihor Radchenko writes: > >> Juan Manuel Mac=C3=ADas 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 >> class=3D"type">text 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=C3=ADas -- Composici=C3=B3n tipogr=C3=A1fica, tratamiento= de datos, dise=C3=B1o > editorial y ortotipograf=C3=ADa > > > --=20 The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com