From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id GO+1JIoXnF5yJwAA0tVLHw (envelope-from ) for ; Sun, 19 Apr 2020 09:19:06 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 2OjfBI8XnF4VQgAAB5/wlQ (envelope-from ) for ; Sun, 19 Apr 2020 09:19:11 +0000 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 922EB941D7E for ; Sun, 19 Apr 2020 09:19:10 +0000 (UTC) Received: from localhost ([::1]:39490 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQ66X-0001lI-KO for larch@yhetil.org; Sun, 19 Apr 2020 05:19:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50538) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQ66A-0001ku-MF for emacs-orgmode@gnu.org; Sun, 19 Apr 2020 05:18:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jQ66A-00022V-7G for emacs-orgmode@gnu.org; Sun, 19 Apr 2020 05:18:46 -0400 Received: from [183.249.128.92] (port=9452 helo=dark.localdomain) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQ669-0001t9-6m for emacs-orgmode@gnu.org; Sun, 19 Apr 2020 05:18:45 -0400 Received: by dark.localdomain (Postfix, from userid 1000) id 4556524249D; Sun, 19 Apr 2020 17:10:16 +0800 (HKT) References: <87ftdact0g.fsf@gmail.com> <87eesu2ekz.fsf@nicolasgoaziou.fr> <87d08c9i7j.fsf@gmail.com> <87ftd7agwl.fsf@localhost> <877dyj9wkc.fsf@gmail.com> <87k12j491l.fsf@localhost> <87wo6jw3yi.fsf@nicolasgoaziou.fr> <87eesqmylz.fsf@gmail.com> <877dyi1b22.fsf@nicolasgoaziou.fr> <87o8rteekx.fsf@gmail.com> <87zhb8wuqb.fsf@nicolasgoaziou.fr> User-agent: mu4e 1.4; emacs 28.0.50 From: stardiviner To: Nicolas Goaziou Subject: Re: [SOLVED] Re: [PATCH] Show hidden drawers when org-cycle on headlines In-reply-to: <87zhb8wuqb.fsf@nicolasgoaziou.fr> Date: Sun, 19 Apr 2020 17:10:12 +0800 Message-ID: <877dybx2mj.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Received-SPF: softfail client-ip=183.249.128.92; envelope-from=numbchild@gmail.com; helo=dark.localdomain X-detected-operating-system: by eggs.gnu.org: Linux 2.2.x-3.x [generic] X-Received-From: 183.249.128.92 X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: numbchild@gmail.com Cc: emacs-orgmode@gnu.org, Ihor Radchenko Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 X-Spam-Score: 1.49 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@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Scan-Result: default: False [1.49 / 13.00]; HAS_REPLYTO(0.00)[numbchild@gmail.com]; GENERIC_REPUTATION(0.00)[-0.57228147904398]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.51.188.0/24:c]; FREEMAIL_FROM(0.00)[gmail.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; R_MISSING_CHARSET(2.50)[]; IP_REPUTATION_HAM(0.00)[asn: 22989(0.24), country: US(-0.01), ip: 209.51.188.17(-0.57)]; MX_GOOD(-0.50)[cached: eggs.gnu.org]; MAILLIST(-0.20)[mailman]; FORGED_RECIPIENTS_MAILLIST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[209.51.188.17:from]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[larch=yhetil.org]; ASN(0.00)[asn:22989, ipnet:209.51.188.0/24, country:US]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FROM_NEQ_ENVFROM(0.00)[numbchild@gmail.com,emacs-orgmode-bounces@gnu.org]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; URIBL_BLOCKED(0.00)[nicolasgoaziou.fr:email,stardiviner.github.io:url]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; HAS_LIST_UNSUB(-0.01)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_CC(0.00)[gnu.org,gmail.com]; FORGED_SENDER_MAILLIST(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : SPF not aligned (relaxed), No valid DKIM,none] X-TUID: IrGtuGAU5N6B =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Nicolas Goaziou writes: > Hello, > > stardiviner writes: > >> This sounds reasonable. (I deleted my patch on my local fork, I think yo= ur solution is better.) > > I pushed the changes. Now drawers folding is on par with blocks. You can > hide or show a drawer with `org-hide-drawer-toggle', which is similar to > `org-hide-block-toggle'. You may want to use it. I today update Org Mode source code, found this change. Thanks for your wor= k. > > Now, visibility behaviour of drawers might be discussed. Currently, all > drawers are "mostly folded", which means that Org tries to fold them > whenever it can. OTOH, blocks are "mostly expanded", i.e., most > operations of the structure of the document opens the blocks. An > alternative would be to have property drawers "mostly folded" and > regular drawers "mostly expanded", i.e., like regular blocks. But that > would partly defeat the "tuck stuff away" feature from drawers. I thought intuitively that property drawers "mostly expanded" and regular drawers like :LOGBOOK: drawer "mostly folded". > > Another (better?) option would be: "don't mess with folding state" for > regular drawers and blocks, i.e., what is open stays open, what is > closed stays closed. But that's more difficult to achieve. Any taker? This indeed will be more difficult. I agree. It's not worth to be more comp= licated. > > In any case, I think property drawers need to be "mostly folded". In my opinion, this design is decided by the usage of properties drawers and other regular drawers. For now, I only used this two drawers. For properties drawer, I use them to store meta data. Like org-contacts inf= o, and URL, Git path, Magit revision link, Author, Email, IMDb, DATE, TIME, CUSTOM_ID etc. I record those info for review in case of I want to know rel= ated info about current headline's content. For examples: =2D - the "DATE" property :: I want to know when I record this headline and= content. =2D - the "AUTHOR", "EMAIL" property :: I want to know the author name and = email. =2D - the "URL" property :: I might want to open it if I only record a part= of original web page content. =2D - the Magit revision link :: I might want to open it when I read the Or= g content. About the "LOGBOOK" drawer, I usually record one log entry, or many log ent= ries. The log entry can be multiple lines, so I can be very long. This long drawer "should be folder". Instead, the properties drawer is strict to one line as value, It will not be very long, so should "keep it expanded". This is one reason too. I just checked out insert regular drawer keybinding [C-c C-x d]. I think th= is should be hidden. Because it is user defined drawers, no one will know how = long it is, and what purpose it is used for. And it's format similar with LOGBOO= K. Not like properties drawer which has property key and value. On the other side, this properties drawer might be used by some Org related extensions, like org-contacts, org-drill etc. For org-contacts, the propert= ies drawer should be expanded, for org-drill, this properties drawer should be hidden. At the end, I know this is just my usage experience, this should consider m= ost Org user's habit of how to use those drawers. =2D --=20 [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 =20=20=20=20=20=20 =2D----BEGIN PGP SIGNATURE----- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl6cFXQUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsPCWgf9F0Za1sfg26LoCOH+gbHwlUEkCFKh 4Q6w8e1qb0Onwf7VP167WGq1ooQBkb2S4K/A8t+ZnepKjLasKM3j7x48Og4kAgCp 4aU3HN1q1z5dQKlcmPSFwTw4hmFXohQa/5+8nnKaPMZExuD427qdLtIRWKUiK7lO vwI+E0oAGroVG+auUk/iH3hxKQrd4GCVIo93nVR7pG3agR+1Ql1acuVSXmFwqhUF nO6qmiVzA2EWXaqtpWwQzagpc3hzRbqi3TP8yMaMM6nldyai5wsGFIl2LjDFF1Tk rgE9diGs2ZX+wPS+H5A/Ty97EeigPI1PjchErneZQDnEfiuclezqnJhhTA=3D=3D =3D4m2J =2D----END PGP SIGNATURE-----