From: pietru@caramail.com
To: Jean Louis <bugs@gnu.support>
Cc: Michael Heerdegen <michael_heerdegen@web.de>, help-gnu-emacs@gnu.org
Subject: Re: Toggle appointment notification
Date: Thu, 3 Dec 2020 21:23:54 +0100 [thread overview]
Message-ID: <trinity-9ff0c98f-e5be-438f-994e-f19669082ae5-1607027034393@3c-app-mailcom-bs11> (raw)
In-Reply-To: <X8lDepW1GPscEEZA@protected.rcdrun.com>
I am not pleased with the roughshod approach by Gnu Support that gives Gnu a very bad
image. Please do not address replies to me, but to the list. Totally shameful and
unprofessional.
Pietru.
> Sent: Thursday, December 03, 2020 at 8:58 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: pietru@caramail.com
> Cc: "Michael Heerdegen" <michael_heerdegen@web.de>, help-gnu-emacs@gnu.org
> Subject: Re: Toggle appointment notification
>
> Software features may influence those human methods that people
> implement themselves to better or worse.
>
> Many good useful features can be developed by looking how "others" are
> doing. By thinking in advance "how is this feature to impact future
> thousands if not hundreds of thousands or possibly millions of
> users".
>
> It is true that I sound general here, that is because I am sorry for
> many users who encounter Org mode but end up in the jungle of
> procrastination. Emacs Lisp is powerful language and may be used to
> integrate it better for users and help in improving collaboration
> between people and groups.
>
> I have given many specifics on the other mailing list of Org. I feel
> with users who spend their time in learning a tool to become
> organized, while there are others who learn not longer than 5 minutes
> and already know what is to be done.
>
> This is because their software is logically and practically organized
> with useful user interface.
>
> Then I have got quite an impression from reading of Org list that
> people are wasting their efforts. When goal is to organize project
> execution, or to know what is the agenda then is fine to discuss about
> that, with or without Org. Maybe Org can improve by looking how others
> are doing. Maybe people can improve their organization by
> understanding the ideal situation.
>
> One specific that Org mode lacks is "people" as most important focus
> there. It tries to be relational to people but it does not offer
> structure of relation. No, org-contacts package cannot replace what I
> am thinking about it.
>
> Centralized Emacs based contact management is what Emacs need to have
> as foundation. BBDB is not doing good job there. I know it maybe since
> 20 years. One other user lost people contacts on upgrade of BBDB and I
> remember this happened to me with few contacts that I used it back
> then.
>
> I would like Emacs to have GDBM built in or other database. The
> PostgreSQL dynamic module is coming to GNU ELPA, developers are
> working on it and I am using it since its inception. Before I was
> using pg module, which stopped working.
>
> I am using database backed people and contacts management through
> Emacs and I am speedy and fast, and hope that we can make some
> difference for the future by introducing at least concepts that people
> may adopt and integrate into future tools.
>
> It does not matter really how, but "people" as database is first
> foundation that Emacs should have, very robust and possibly built
> in. Then it is pretty easy to upgrade the foundation with "groups" or
> "organizations" or "companies".
>
> We have calendar but we have no people. Hmmm. While tools as such as
> interesting as hacks or amusing programs, when making them, one cannot
> expect there will be nobody to criticize it. Or that we should not
> criticize it.
>
> Unless I live alone on the deserted island using M-x calendar, any
> calendar is not fine in computing environment if there are no related
> people to it. We do planning with people.
>
> When I say "foundation", I only refer to core design of the structure
> of contacts and organizations and not to any integration. If the
> structure and core design is well made it can last for future
> decades. At least my structure is already for decades for me working
> without changes.
>
> That would be blazing quick access to contacts and organizations. It
> would be easy to refer to contacts, something like:
>
> (contact-first-name id)
> (contact-middle-names id)
> (contact-last-name id)
> (contact-full-name id)
> (contact-country-1 id)
> (contact-country-2 id)
> (contact-phone id)
> (contact-cell id)
> (contact-fax id)
>
> When contacts are there, then the Org mode's demand for contact and
> relations to contact would be fundamentally solved. Instead of
> entering per file few settings, users could simply assign a heading to
> specific contact. No writing, just semantic access. Something like
> "Joe, Guayana" would inject the hyperlink into Org. Share to contact,
> share to assigned contacts, share to groups, send task to group of
> people, or single one, share by SMS, initiate a call, do the real
> work and real collaboration.
>
> Or maybe I am just alone here who is writing tasks for groups of
> people and assigning them, maybe all other people are just writing for
> themselves and like to invoke 50-100 key presses to inform the
> assigned person of the assigned task. I like 2 key presses. I like
> when I have 77 tasks that at one key press I can inform all of
> them.
>
> I will send here to this mailing list proposal on how people database
> should look like, and then I hope we can discuss that and make one
> good foundation for future of Emacs users. From my long year
> experience I have also some features that I would maybe make little
> bit different.
>
> Then based on people and organizations we could build relations from
> other software to make life easier.
>
> Jean
>
>
next prev parent reply other threads:[~2020-12-03 20:23 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-01 3:47 Toggle appointment notification pietru
2020-12-01 4:56 ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-12-01 5:03 ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-12-01 18:35 ` pietru
2020-12-01 18:52 ` Jean Louis
2020-12-01 19:01 ` pietru
2020-12-01 19:13 ` pietru
2020-12-01 19:23 ` Jean Louis
2020-12-01 19:38 ` pietru
2020-12-01 19:53 ` tomas
2020-12-01 19:58 ` pietru
2020-12-02 15:00 ` pietru
2020-12-02 15:15 ` pietru
2020-12-02 15:47 ` Michael Heerdegen
2020-12-02 15:58 ` pietru
2020-12-02 17:39 ` pietru
2020-12-02 17:46 ` pietru
2020-12-03 1:39 ` Michael Heerdegen
2020-12-03 2:18 ` pietru
2020-12-03 22:32 ` Michael Heerdegen
2020-12-03 1:50 ` Michael Heerdegen
2020-12-03 2:14 ` pietru
2020-12-03 3:23 ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-12-03 4:06 ` pietru
2020-12-03 4:22 ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-12-03 22:38 ` Michael Heerdegen
2020-12-12 1:07 ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-12-12 1:26 ` Christopher Dimech
2020-12-12 1:50 ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-12-12 1:48 ` Christopher Dimech
2020-12-12 1:53 ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-12-12 1:59 ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-12-12 3:55 ` Michael Heerdegen
2020-12-12 4:23 ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-12-12 22:42 ` Michael Heerdegen
2020-12-17 4:31 ` Michael Heerdegen
2020-12-03 2:17 ` daniela-spit
2020-12-03 3:19 ` Pankaj Jangid
2020-12-03 5:35 ` pietru
2020-12-03 15:19 ` pietru
2020-12-03 17:09 ` Jean Louis
2020-12-03 17:20 ` pietru
2020-12-03 17:58 ` Jean Louis
2020-12-03 18:29 ` pietru
2020-12-03 19:41 ` Jean Louis
2020-12-03 19:58 ` Jean Louis
2020-12-03 20:23 ` pietru [this message]
2020-12-03 20:38 ` Jean Louis
2020-12-03 21:30 ` Christopher Dimech
2020-12-03 22:43 ` Arthur Miller
2020-12-03 22:51 ` Christopher Dimech
2020-12-03 23:12 ` Michael Heerdegen
2020-12-03 23:03 ` Michael Heerdegen
2020-12-03 23:49 ` Jean Louis
2020-12-04 0:28 ` pietru
2020-12-04 5:59 ` Jean Louis
2020-12-04 6:28 ` pietru
2020-12-04 7:11 ` Jean Louis
2020-12-03 23:59 ` pietru
2020-12-04 1:13 ` Michael Heerdegen
2020-12-04 1:39 ` pietru
2020-12-03 10:19 ` Jean Louis
2020-12-01 21:44 ` Michael Heerdegen
2020-12-02 8:41 ` tomas
2020-12-02 12:05 ` Christopher Dimech
2020-12-02 12:37 ` tomas
2020-12-02 13:15 ` Christopher Dimech
2020-12-02 13:52 ` tomas
2020-12-02 14:10 ` Christopher Dimech
2020-12-02 14:20 ` Robert Pluim
2020-12-02 15:04 ` Christopher Dimech
2020-12-02 15:08 ` Jean Louis
2020-12-02 21:14 ` tomas
2020-12-02 21:41 ` Jean Louis
2020-12-02 22:35 ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-12-02 22:54 ` Jean Louis
2020-12-02 15:25 ` Drew Adams
2020-12-02 15:04 ` Jean Louis
2020-12-02 1:54 ` daniela-spit
2020-12-02 2:47 ` Michael Heerdegen
2020-12-02 3:04 ` daniela-spit
2020-12-02 3:23 ` Michael Heerdegen
2020-12-02 4:16 ` daniela-spit
2020-12-02 4:26 ` daniela-spit
2020-12-02 4:59 ` Jean Louis
2020-12-01 9:13 ` Andreas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=trinity-9ff0c98f-e5be-438f-994e-f19669082ae5-1607027034393@3c-app-mailcom-bs11 \
--to=pietru@caramail.com \
--cc=bugs@gnu.support \
--cc=help-gnu-emacs@gnu.org \
--cc=michael_heerdegen@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).