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 8H34G7Icxl+oegAA0tVLHw (envelope-from ) for ; Tue, 01 Dec 2020 10:36:34 +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 +IXJF7Icxl/JSwAAB5/wlQ (envelope-from ) for ; Tue, 01 Dec 2020 10:36:34 +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 9070794023A for ; Tue, 1 Dec 2020 10:36:33 +0000 (UTC) Received: from localhost ([::1]:44636 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kk31L-00021D-0z for larch@yhetil.org; Tue, 01 Dec 2020 05:36:31 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41670) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kk2zs-0001yN-AK for emacs-orgmode@gnu.org; Tue, 01 Dec 2020 05:35:00 -0500 Received: from static.rcdrun.com ([95.85.24.50]:47249) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kk2zo-0003jd-17 for emacs-orgmode@gnu.org; Tue, 01 Dec 2020 05:34:59 -0500 Received: from localhost ([::ffff:41.202.241.16]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C0006.000000005FC61C4C.000020EB; Tue, 01 Dec 2020 10:34:52 +0000 Date: Tue, 1 Dec 2020 13:30:29 +0300 From: Jean Louis To: Ihor Radchenko Subject: Re: Bring up a screen giving option to open a series of orgmode files Message-ID: References: <87eekkcwzs.fsf@localhost> <874klfcj5k.fsf@localhost> <878saj192u.fsf@localhost> <87tut6uu74.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87tut6uu74.fsf@localhost> User-Agent: Mutt/2.0 (3d08634) (2020-11-07) 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: 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: , Cc: Maxim Nikulin , emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.79 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=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-Migadu-Queue-Id: 9070794023A X-Spam-Score: -1.79 X-Migadu-Scanner: ns3122888.ip-94-23-21.eu X-TUID: mC0kVFxMfeNn * Ihor Radchenko [2020-12-01 05:35]: > Jean Louis writes: > > * Ihor Radchenko [2020-11-30 12:31]: > >> I can see that you have implemented many of the suggested commands > >> yourself. Why don't you just propose patches extending the functionality > >> you desire? > > > > Good question, I have no idea in this moment why not. Maybe I just > > make a function that works for me and is not that easy to provide a > > patch that enhances some Org functionality. Example is sending Org > > tasks by email, if somebody of developers wish to do that they can > > do. For me is concept more important than specific function. Concept > > of being able to send any object from anywhere to anybody is more > > important than functions. Then if developers have different concepts > > and do not think of sending or sharing objects, then those are > > colliding minds and different experiences. I need to put more effort > > to write it why, how, where, what, then to write the function itself > > that just works. That is reason why people make separate packages. > > I would like to remind you that all the Emacs and org-mode development > is only volunteer-based. As a result, people implement things they are > interested in and they have spare time for. If the features you find > useful are not implemented, there are at least three possibilities: > > 1. Others do not use them and do not need them. > In such a case, you can just implement the desired functionality > privately. I have packages that will be published for that. But not that I want to engage in discussions what is usable or not. I consider integrations necessary and known to be necessary and it is not found in many pieces of software. It is also trivial, so if somebody wants, may include it. On mobile device every day I am sharing notes, images, tasks, files without much thinking. Recent targets where I should share files are shown automatically. Often recent people to which I have already shared something are shown automatically. Tasks applications on mobile phones allow sharing of tasks to other people. Why then bother group of people that existed longer than I know Org mode and that in 5 years did not provide any sharing capability that I know? No need for that. GNU Hyperbola package is way older and mature than Org mode, it has region and buffer sharing capability on a key press or invoking a command. Let us say that I would propose sharing email in Org mode in the exact way how I am doing it, that would not work. We already said that development "does not want structure" and files should be self-sufficient. But again contradiction is that development does use structure, only not as foundation. How I create and share for collaboration? 1. First thinking that person need to do a project, with the first task to be made for person I press F4. This alone would require Org developers to implement centralized contact management which does not exist. F4 would require to implement feature where Org file is expanded from a template that contains person's name, hyperlinks, dates, and various heading sections, prepared table for transactions and similar. 2. Then I write some tasks. When I write it, the task is assigned to person. 3. I press key and task is sent to that person, because underlying program knows which email to use, what type of task is that. I do not normally see email software in front of me. It is just sent with formatting and signature from my proper identity. Now I should ask for proposal to implement sending it by email where there is no central contacts database, no streamlining, where Emacs would not know automatically which email address to choose, etc. Too many things. Those are fundamental disagreements. I also hold Org mode as nice outline for text editing. Keeping notes in Org is fine but whenever note need to be related to a person I have to relate it in such way that it is stable for future, so notes are related in the PostgreSQL database. I must know what I wrote about specific person at specific time related to specific other objects accessible on a key press like F3. While Org mode is editing structure of text there is rigid data structure. I can assign person as Joe, or as hyperlink to anything, it is free but that freedom does not help me. What helps is integration, not freedom. mutt email reader has aliases for email addresses, like I can write "Joe" and get email address. But that is not full integration. If I can search among 200000 email addresses in the database that would be integration. Software may not be made for that. If planners of a project such as Org mode do not see or do not know that sharing of objects has been established as useful feature in other systems, other methodologies, software, then I feel no urge personally to propose some new features as it is not goal of that project. Doug Engelbart institute influenced WWW and many hypertext systems: https://www.dougengelbart.org/content/view/110/460/#2d so if principles are not followed and collaboration was not prime purpose from beginning, then I leave that and I consider Org file more destined for other purposes. We speak of sharing heading or sharing task or assigning tasks to people, and sharing tasks to related people and assignees. Well, I did not start with project management with Org, I have started back in 198x something. We were using TRS-80 clone computers and before these computers I was using a typewriter and notebooks (paper notebooks) for project planning. Since 1995 to 1998 my project planning skills enhanced greatly, and Org was just let us say handy extension to scattered tasks. For project planning it is useful for me more as a quick formatter (with errors) that exports nicely to PDF. Before I was using LateX straight. I am transitioning and moving away from Org to meta level editing and I will not think of exporting more then a key press. If Org already has many features as envisioned by Doug Engelbart, and there are mobile devices around us, and many applications already share notes, images, files, contacts around, then it seem to me like going through a wall. And I do remember asking and proposing that somewhere 2015, begin 2016 on IRC. Because we have non-organization of many people from end users to developers and sponsors we cannot get routed properly to right person who would be handling the thing. If nobody wants to send task by email when feature has been already proposed why should I again send it same mailing list. Just think about impressions on other users, as I am not important. There are many blocks in using Org. It is software made for advanced users. CRM is Customer Relationship Management, it better be called People Relationship Management. It is a method, not software, although people refer too often to software. And almost every such software has task sharing, note sharing, case sharing abilities and collaboration. And I have used it for years before I even found Org mode. Org mode never replaced what I used. The Org files became just one node to one bigger senior structure. And I use various other files as well, like PDF, images, where all of them are part of senior structure. >From that viewpoint of looking at Org file as elementary object if I am surprised by people's design that implied to me they do not share viewpoint of sharing, so there is no personal motivation to do something what is not wanted or not planned from ground up. > 2. Others would find the feature useful, but they never thought of > it. I do not think that it is proper after 5 years experience with Org mode. It may be usable to small group and they can anyway copy and paste into email. I have my system where I can send a fax straight from Emacs, send SMS, send email, initiate a call and record all those actions for future and relate them to people. Personally, from proposing single function I would not have any use. As again I would not have use without environment such as central database of companies and people and very quick workflow. Many times Emacs developers helped in solving bugs and I could finally get database editing features. It did not work before. One could not move from a buffer of editing to other buffer when editing a string in full window. Several times improvements were made when I proposed or discovered a bug. > In any scenario, it would be useful to send feature request/patch to > this mailing list: > > 1. You will let others know about your ideas > 2. You might get new ideas what can improve your workflow or even find > some superior approach that makes your feature obsolete > 3. You can get the feature into org-mode, likely improved in the > process >From these discussion there will be place for people to read, and all discussions can be easily re-formatted into EmacsWiki or websites. I can make a meta level website that explains on handling projects, and tasks. If I find a bug I am reporting anyway. > Important note: it is not very useful to dump all the ideas into a > single email in the above scenario. The suggestion would more likely be > noticed if one idea/feature is limited to a single thread. When doing anything, one shall have bigger picture in mind. So I do when we are discussing. It may all become a published set of planning that not only Org mode would find useful but other systems as well. We are in progress and we are in a mailing list in collaborative environment, great thing. By doing this we are influencing outcomes in future. Other people will built upon ideas. I have got personal use as anti-mode. The references collected in last weeks helped me realize that scattered task management is wrong way to go. I had "tasks", "simple-todos" simpler than tasks, Org files, various files and that sums to thousands of pieces of information not necessarily nicely related to other objects. So I have transitioned and removed those and created generic hyperdocuments that may be related to anything, that may also keep tasks and can create Org files on the fly. No more thinking "where is the Org file", I have connected the dots and related it to meanings so that I think only of meanings and relations to locate files. Next step will be to exterminate those parts in Org files that represent transactions and tasks and move such to relational database. Org files without tasks and without relations can be well used for preparation of instructional books and group knowledge as that is how I use it. Until of it gets transitioned into higher level hyperdocuments on which a group may collaborate. Then Org file and also parts of the Org file become an elementary object in a mixed-object environment. It takes about 15 seconds to make an Org file on the fly from 19700 various objects. Jean