[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Idea] Org Collections
From: |
Roland Everaert |
Subject: |
Re: [Idea] Org Collections |
Date: |
Mon, 23 Dec 2019 14:31:55 +0100 |
User-agent: |
mu4e 1.2.0; emacs 26.2 |
Gustav Wikström writes:
> Hi!
>
>> -----Original Message-----
>> From: Emacs-orgmode <emacs-orgmode-bounces+gustav=address@hidden> On Behalf
>> Of Roland Everaert
>> Sent: den 16 december 2019 12:26
>> To: address@hidden
>> Subject: Re: [Idea] Org Collections
>>
>> +1 for this idea.
>>
>> You speak about one document used by multiple collections, how do you
>> plan to manage that from a file system point of view?
>
> The idea was to let the user define the scope of each collection herself.
> Similar to how an agenda is defined today (Maybe in the same way even?). Most
> simple configuration would be to let a collection be one folder. But in the
> end it would be up to the imagination of and usefulness for the user. Having
> one document in multiple collections wouldn't be any issue because the
> collections are only pointing to locations of files in the filesystem. And if
> creating overlap between collections sounds dumb then it's a simple choice by
> the user to not do it!
Have you had a look at org-brain. I don't use is much, but there are
some overlapping functionnality to merge, maybe.
>
>> How will be organized a collection, still from the FS point of view?
>
> Maybe the comments above answer that as well?
>
>> As some are delving into the abyss of sementic, I propose aspects
>> instead of collections or contexts. Ultimately we are trying to manage
>> various aspects of our life, by splitting those aspects into files or
>> diretories and what not. So, if it is the intent of your idea, the term
>> aspect seems more appropriate than collection or context IMHO.
>
> Many words could work. Context, Project, Group, Aspect, Areas, etc. I first
> thought of the name "project" to match the Projectile package. But I think
> collection is a better concept here. It lets the user think not of how it
> should be used but rather of what it consists. Which is a collection of files
> (and settings). That collection can ofc. be used for project, as aspects, or
> be seen as contexts or areas. So in my mind collection is the broader, more
> applicable term. It has less subjective meaning attached to how this
> functionality could be used. It IS a collection but can be USED as aspects,
> for projects, etc. What do you say? đ
I think I can live with it ;)
>
>>
>> Did you think about the specific UI of aspects management?
>> Proposal of UI I particularly like:
>> - Mu4E
>> - forge/magit
>
> Not really.. Except I agree with you on magit. The other I haven't used.
Mu4E is a major mode for managing e-mails using the mu index. it
provides a main view with bookmarks and entries to perform searches and
composing message, among othe thing, but what I find more useful are the
header view, which displays a multi-columns list of e-mails with
associated meta-data and a message view allowing to view the content of
an e-mail. The header view allows for bulk actions while the message
view act, obiously, on the current message and permit replying and
transfering the current e-mail.
>
>>
>> How to keep track of all those aspects?
>
> My first thought was to define them in a simple list.
>
>>
>> I will surely have more to say, but, as of know I am at work.
>>
>> Regards,
>>
>> Roland.
>
> Thanks for your comments!
>
> Regards
> Gustav
--
Luke, use the FOSS
Sent from Emacs