From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id UCkvNIP1jGKLmAAAbAwnHQ (envelope-from ) for ; Tue, 24 May 2022 17:10:59 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id 4Pk4M4P1jGKAEQAAG6o9tA (envelope-from ) for ; Tue, 24 May 2022 17:10:59 +0200 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 5F248FF5E for ; Tue, 24 May 2022 17:10:59 +0200 (CEST) Received: from localhost ([::1]:59334 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ntWBW-0007g3-6g for larch@yhetil.org; Tue, 24 May 2022 11:10:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34120) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntWAL-0007fT-8e for emacs-orgmode@gnu.org; Tue, 24 May 2022 11:09:45 -0400 Received: from ciao.gmane.io ([116.202.254.214]:47200) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntWAJ-0007hm-Jm for emacs-orgmode@gnu.org; Tue, 24 May 2022 11:09:44 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1ntWAH-0003Pw-Sg for emacs-orgmode@gnu.org; Tue, 24 May 2022 17:09:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: About 'inline special blocks' Date: Tue, 24 May 2022 22:09:33 +0700 Message-ID: References: <87czg49cwq.fsf@posteo.net> <87bkvn7iqn.fsf@gmail.com> <875ylvzio8.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US In-Reply-To: <875ylvzio8.fsf@gmail.com> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 28 X-Spam_score: 2.8 X-Spam_bar: ++ X-Spam_report: (2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1653405059; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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; bh=xBMM/cW6Swx9d6Avia/+JvNSVFjn1xIQcOWvIH1LS5w=; b=fPORzmcfMNXPDCmOi9146ihXoA60DQDKSIfsWVwZRlYGBiVfB6MRvvaY6lLN8gmSc/bYUd aiZZOrhvSpl2KnmQep2GwcvHhdfRSe2nSnFDQGRijiZ2OjuijCC+ChabS2lx86cr+oYxhP pRu/SIn2KnM4scTUZ0YuyHVFyYozh5kVoh/bMCpqT/4b2fDlQaP0ogpjMTOtpEoB7P5Sv0 lCKLZ+UgbLWtlv9TO0Hsvp/3c65oPV6jRUV2gme10rNCRuwhZ0aiJow5zUb+lDMwkL0S4H Hl04+Mw2KALHo97XeIumHpm/B3/El9K5zHuPNOKEjcICNfXUj23OGnQ/4U/rFQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1653405059; a=rsa-sha256; cv=none; b=cJaMhXugUGll2ci87b5b9hth8aaGYe6AqH0tyvc2h60moHDdhB61M0zQuOAjYldBULkJ3n hYfs/N6rk8x4n3pVGqXo+uiEOjoHkpJozppQtADQ/m78TqiS/yus8sg+/3HWBqTdLpuhfE VSX+WQ5P2rprBcgU8jJSs9SiaRFG4g7K0zcU3skzKV4KcARLK4aMJ42fTKb9Z8/XKEsqX3 GndK4ZFUjm/NFL1NGLRoNWlE5DN2+CYv2q/z1RChatgXk7Hqt5oiPZKRkWHjT9zJzIoBym 29pUpBoE/lNHf6MDUehG3pT/N2ol5YjmSiPyfYsMRmAUSEQkklNVJ9XIHxqHiQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); 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" X-Migadu-Spam-Score: 2.65 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); 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" X-Migadu-Queue-Id: 5F248FF5E X-Spam-Score: 2.65 X-Migadu-Scanner: scn1.migadu.com X-TUID: P5a/RM/7Kcbc On 24/05/2022 09:51, Timothy wrote: > > To me, this is another reason for comment and #+attr_X lines not to break > paragraphs, as then we can just re-use #+attr_X lines. I like the idea that comments and attribute lines should not be paragraph separators. I expect, it should alleviate the issue that LaTeX and Org paragraphs may significantly differ. Do somebody has examples when such change will cause negative effects (besides broken compatibility, of course)? > ┌──── > │ Hi there look at > │ #+attr_X: :prop val > │ inline_mark{some content} > │ and now continuing the paragraph... > └──── However I am afraid that using the same construct for block-level elements and inline object will cause confusion. Consider a paragraph starting from a link. Which attributes belongs to the whole paragraph and which ones should affect the starting link only? I consider attributes specific to an inline object as a great feature, but I am unsure if it requires special inline object. Would not it be enough to allow attributes for already existing objects (emphasis, links, citations)? It is feasible to require from external tools such as pandoc to support special blocks (likely implemented in lisp code)? Concerning fear that complicated attributes makes text hardly readable, macros might be a rescue, but it would depend on implementation. I had an idea to implement proof-of-concept for inline attributes using a special link type and a parse tree filter that transfers attributes to the next object. Unfortunately time related bugs in Emacs appeared to be rather time consuming. ---- >8 ---- #+macro: nofollow [[attr:(:html (:rel "nofollow noopener"))]] An {{{nofollow}}[[attr:(:html (:title "be careful!"))]][[http://unsafe.com][unsafe link]]. ---- 8< ---- Such implementation would allow to test if it convenient enough and whether special blocks are really necessary.