emacs-orgmode
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]