From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.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 4AagHqQiEmOokQAAbAwnHQ (envelope-from ) for ; Fri, 02 Sep 2022 17:35:00 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id GAqXHqQiEmN6EAEA9RJhRA (envelope-from ) for ; Fri, 02 Sep 2022 17:35:00 +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 EC8A1F968 for ; Fri, 2 Sep 2022 17:34:59 +0200 (CEST) Received: from localhost ([::1]:43808 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oU8h9-0006aW-65 for larch@yhetil.org; Fri, 02 Sep 2022 11:34:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37906) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oU8fZ-0006XQ-1T for emacs-orgmode@gnu.org; Fri, 02 Sep 2022 11:33:22 -0400 Received: from mout02.posteo.de ([185.67.36.66]:58835) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oU8fW-0008Fr-03 for emacs-orgmode@gnu.org; Fri, 02 Sep 2022 11:33:19 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 411EE240104 for ; Fri, 2 Sep 2022 17:33:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.eu; s=2017; t=1662132794; bh=Yyj5SPcVoNd59Gvf8ZVU9QR36wxkzpKts5ULQxL2VeY=; h=Date:Subject:To:From:Cc:From; b=pL8uYGVDcj0uTNdWwr2X7Lkrhf+bTGpiGU1HIpmsUD5j3HyKQLlfecqcwMNCcY5d5 HSfzsn69PND4Zf0aS/xJQbNUawnpgUNmmVbut6slqSWTLVXNqtdf5PKMvlonTTiUGg I7jau/7yAH+7yQuFjmE4iJRDa4tbog48Mk8VxVntw7w35QXHctUsOmpG1b/muQnJA2 P1SdfyLHW64FfIjZWONg9XkYkhXUrotJBcFtmY68WslI42eNIuoNMp+5C0XmUjbtx6 Y88v/rKtF5sZ18GyQJUAg91i2V8EA9jHZ2Fhki+wvlpcl/ibMSRBMOthSRKlu4wp7H 2ZrmZtseGMSdg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4MK23s73c2z9rxM; Fri, 2 Sep 2022 17:32:54 +0200 (CEST) Message-ID: <8f79980b-e903-c68a-cf07-6c5265215ee4@posteo.eu> Date: Fri, 2 Sep 2022 15:32:26 +0000 MIME-Version: 1.0 Subject: Re: Support for tagging (special) blocks Content-Language: fr To: Ihor Radchenko References: <8735dbbuku.fsf@gmail.com> <87ler3oc4u.fsf@localhost> <30d5a0be-4651-3f41-8b53-91acd4a86ca5@posteo.eu> <87a67hncp7.fsf@localhost> From: =?UTF-8?Q?S=c3=a9bastien_Miquel?= Cc: emacs-orgmode In-Reply-To: <87a67hncp7.fsf@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=185.67.36.66; envelope-from=sebastien.miquel@posteo.eu; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, 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: , Reply-To: sebastien.miquel@posteo.eu 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=1662132900; h=from:from:sender:sender:reply-to: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=zNHTe1Es7J9sXfxLy0bXXMliNqSZ0dpYw2RIsjbaLdw=; b=DvYqIF8pR3Rr4ELw+AWTFPQLTyrpk7/tbrbvzMhIFmgvBaTgauGqfRA0fFN5di8Su3GCgq eK2AI8t21WHS+yXBWiyTGaYzfA1/zJybYOGO4xpmFhUqYZKQRpc0w+zAKI9dWu/3YBqjSP yCKaGAt6SNRiJ3Z/Vp2fSxM19YSPdptpOIqO+2XrUlpwJqHzQYzZ8zQhdKOP1qnary5L6a 4jSHZgg/GFGzCfPKvyG69k76V4mB08J7/rryAAw+tdAofi2O/14JnfyDrJxVDYhPybqqfO VK0KpblINh6WceGgbQUpj9bM3ttV0JKDcHHC/drYPyiQChyl2hUHcaFIa7A/GQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1662132900; a=rsa-sha256; cv=none; b=Fc6kUrFm5nJA41Vjf5CubY6rLpAw3/h6ob8hybBJK2H+25sl/kq0Kt2sNM3RO56ThWl/sW BW6BpasnFR2RTavg5aUVU5i7hKpYIjuMuh2qTLS6xanC6yJZyxl4q3PWLYTXyv2gsVbmIZ Amwk5+kpVRxOQleu0apuPlzmJT4Na0000JNAU1W68x5lDjTTrno3NYnhsEDSKy57uEjgzv DDw4/MMjYe7GqDr/sA1953PCMg5iukFgkETWymT/sELe38TK5JTXii5CkjCKAXMgKfKzvo iUrorPZsy8z5nSSpX3EkHtArfyrBtbUnwov78dkDhf0BIWvs/P96+wdqo4+IAA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.eu header.s=2017 header.b=pL8uYGVD; dmarc=pass (policy=none) header.from=posteo.eu; 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: -7.47 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.eu header.s=2017 header.b=pL8uYGVD; dmarc=pass (policy=none) header.from=posteo.eu; 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: EC8A1F968 X-Spam-Score: -7.47 X-Migadu-Scanner: scn0.migadu.com X-TUID: /A/WQKfqfSi2 Ihor Radchenko writes: > Sébastien Miquel writes: > >> Ihor Radchenko writes: >> > They do not. Tags are only considered inside headlines. Trying to allow >> > tags outside headlines will require major changes across the whole Org >> > codebase and will still make things incompatible with third party >> > packages, like org-ql. Not to mention the whole new concept for block >> > syntax. >> >> Tags on block do not need to have the same support as headlines tags. >> I'm not suggesting they should interact with the agenda or whatnot. >> Support could be behind a user option, and consist only of say easy >> tag edition, and `#+exclude_tags:` support. With that scope, the >> implementation should be fairly simple. As for third party packages, >> it is up to them whether to extend their features to tagged blocks ; >> in some case it might not make sense. > > We already have ":exports none" header argument. For src block yes, but not for special blocks. To explain where I'm coming from : I write mathematical content categorized using special blocks, such as theorems, exercices, proofs, personnal notes, etc. Then from a single org file, I export several pdf files, filtering the content according to the types and tags of special blocks : for example, to exclude some proofs, or exercices that are too hard. > >> > If one wants to add "tags" or other keywords associated with blocks or >> > other Org elements, the right tool to use is affiliated keywords. But >> > note that Org search infrastructure is tailored towards searching >> > headlines. >> >> Two inconvenients with using affiliated keywords. >> 1. There would be no uniform treatment with headline tags. In my use, >> I have the same tags on headline and blocks, and I filter the >> export according to them with #+exclude_tags. > > Affiliated keywords are indeed not uniform with headlines. But they are > uniform with everything else. Paragraphs can have affiliated keywords. > Or other blocks. Or lists. Or tables... That's indeed a good point. In fact, I had been wondering recently how I could tag a single list item, but I guess affiliated keywords still can't do that. > >> 2. They waste too much space. Say I have some 20 short exercices >> (represented by special blocks). Since I dot not display the >> #+end_ line, each of them takes 2 or 3 lines in my screen. If I >> want to tag those using affiliated keywords that makes for a 50% >> or 33% size increase, with very poor readability. > >> On a slightly related note, I find it quite unfortunate that one >> presently cannot make use of the #+begin_ line of special blocks to >> set some kind of optional title instead of using #+name or >> #+attr_latex. That's a lot of wasted real estate. > > Yes, but we do not want to overcomplicate Org syntax. Affiliated > keywords are universal across multiple element types. Adding a > specialized syntax for src blocks will make things complex technically > and create duplicate code. > > We can alter the fontification to compact the screen space though. Will > it suffice? > I don't see any possible compactification that doesn't hinder readability. From my perspective, it is important that the type of the special block, its title, and its tags are readable. One thing that org can do in that regard is hide the #+end_ line. For special blocks, a requirement is that the org-block face should apply to them too, to see where the block ends. -- Sébastien Miquel