From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.help Subject: Re: Toggle appointment notification Date: Thu, 3 Dec 2020 22:58:50 +0300 Message-ID: References: <87h7p4ky4y.fsf@web.de> <875z5jiroy.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25634"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Cc: Michael Heerdegen , help-gnu-emacs@gnu.org To: pietru@caramail.com Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 03 21:01:41 2020 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kkunN-0006Xx-BU for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 03 Dec 2020 21:01:41 +0100 Original-Received: from localhost ([::1]:55990 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kkunM-0007uH-BS for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 03 Dec 2020 15:01:40 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33898) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kkumN-0007rW-7a for help-gnu-emacs@gnu.org; Thu, 03 Dec 2020 15:00:39 -0500 Original-Received: from static.rcdrun.com ([95.85.24.50]:55363) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kkumK-0005gO-T2 for help-gnu-emacs@gnu.org; Thu, 03 Dec 2020 15:00:38 -0500 Original-Received: from localhost ([::ffff:197.157.0.57]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C0007.000000005FC943E2.00004C7C; Thu, 03 Dec 2020 20:00:33 +0000 Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:125906 Archived-At: 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