bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
daniela-s...@gmx.it writes: > So now the maintainer starts telling users that they are rare cases > for being confused. How can any woman stand this guy!!! Impossible. I'm closing this bug report. If there's anything more to be done here, please report the bug to the Org maintainers. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
* Ihor Radchenko [2020-12-14 15:46]: > Jean Louis writes: > > Do you mean this: > > > > ** DONE Objective > >CLOSED: [2020-12-13 Sun 20:00] > > *** TODO [#B] Step to do 1 > > *** TODO Step to do 2 > > > > when org-enforce-todo-dependencies is true I can still say DONE for > > Objective above. I have mentioned it today already. Maybe it works on > > your side, it does not work here. Do I do something wrong? I am on > > development Emacs version and it does not enforce under emacs -Q ... > I just looked into this more. Most likely you were trying to set this > variable manually. To take effect, this variable should be set using > customisation interface, before loading org, or you may need to run M-x > org-reload. That was it! Thank you. > I also find it helpful to combine the objective + a note about concrete > action to take on the objective. The concrete action helps to get > started on the objective without drowning myself into thinking (but not > doing) about all the things I need to do on that objective. Objectives here on my side also have their description which is meant more as communication, information and instruction to people doing it. Other notes that are maybe useful for management, thinkering, that would rather obstruct execution of single step are not written in those headings meant for execution. > Would you mind writing a paragraph or two to improve the "5 TODO Items" > section of the manual? At least, we can inform people that the ability > to scatter todo items all around the documents does not mean that it has > to be done. That would be nice. But me writing it for many would not be. It is better to define list of various paradigms of planning by group of people who are here on mailing list. Then such paradigms may be mentioned or referenced collaboratively. While this type of planning correlate to me: https://en.wikipedia.org/wiki/Project_management#Planning it may not correlate to many other people. So various types of planning should be presented in the manual. 1. Scattered method, putting notes, tasks in many various places and compensating for it with org-agenda 2. Project management as given on Wikipedia could then advise for this model: https://en.wikipedia.org/wiki/Waterfall_model#Model and describe such in short with reference to WWW hyperlink and advising Org users to define the objectives and next steps to be followed only if previous steps have been accomplished. It is natural to write notes related to action step together. But to avoid placing notes or action steps from different scope in one file. When one headline TODO have been accomplished then it is followed by next TODO headline. This way the steps are chronologically ordered. What do you think of that? 3. Project planning template could be included as laid out here: https://en.wikipedia.org/wiki/Project_management#Planning but in simpler way with the example Org template for some practical product such as "bread" in bakery or "software project". What do you think? Jean
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
Jean Louis writes: > Do you mean this: > > ** DONE Objective >CLOSED: [2020-12-13 Sun 20:00] > *** TODO [#B] Step to do 1 > *** TODO Step to do 2 > > when org-enforce-todo-dependencies is true I can still say DONE for > Objective above. I have mentioned it today already. Maybe it works on > your side, it does not work here. Do I do something wrong? I am on > development Emacs version and it does not enforce under emacs -Q >> I cannot reproduce what you observe. Also, one can forcefully change >> todo state to done even when org-enforce-todo-dependencies is set to >> TRUE. To do it, C-u C-u C-u C-c C-t needs to be used instead of C-c C-t >> for setting the todo state. > > I can observe in emacs -Q from development version. > > So you say when you try to close senior heading that you cannot close > it? I can when that variable is true or nil, do you think it is bug? > > I can give you access to Emacs over remote ssh and you can try because > if it is bug, it is serious for those other thinkers but me. I just looked into this more. Most likely you were trying to set this variable manually. To take effect, this variable should be set using customisation interface, before loading org, or you may need to run M-x org-reload. > It looks like I am only one observing that. And especially me I do not > like depending on Org mode to dictate how to close items. So when > there is somebody else to join in the notion that is where feature is > appropriate. Otherwise I consider Org rather made and designed for > other way thinkers and doers, not for us who think from senior > objectives as priorities where subordinate items should become > redundant and not marked as "done". org-mode is developed mostly be enthusiasts. Some popular features are used by many different people using different workflows. Those features get a lot of attention and become quite customisable. Other features, are only used by their author and maybe a few other people who agree on the way the feature is implemented. Naturally, these less commonly used features are more biased towards their author's workflows. However, I don't see why a patch improving org-mode flexibility would not be welcome. > My personal list of for a day has 7 items currently. Not 250. Those > are rather objectives, goals and purposes. Single items under > objectives are well known actions to be done and need not be marked as > TODO, but I can. My focus is on the meaning of what has to be done and > I do not need to look into tags or properties. Your informational > emails gave me to thinking so I have implemented it all. I also find it helpful to combine the objective + a note about concrete action to take on the objective. The concrete action helps to get started on the objective without drowning myself into thinking (but not doing) about all the things I need to do on that objective. >> Note that you are also risking to complain about things that are >> actually not a problem. Simply because you don't have a need to >> investigate what is possible. > > Yes, some of those needs disappeared when I have seen so many > obstacles. I did not use some features like org-agenda because it was > in front of me what I have to do. Things were not scattered like Org > manual advises and I disadvise. It is different paradigm approach and > so for many needs I need not even investigate what is possible. I am > interested in paradigms, approaches, methods but not in general in > gluing things together which are not meant to be together. Would you mind writing a paragraph or two to improve the "5 TODO Items" section of the manual? At least, we can inform people that the ability to scatter todo items all around the documents does not mean that it has to be done. > Jean
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
* Christopher Dimech [2020-12-13 20:49]: > > Reference to manual: > > (info "(org) TODO Items") > > > > And it is definitely not a "plain text". It is probably largest mode > > for Emacs, a true and full application handling much more than plain > > text. It has more than 129 Emacs Lisp files. Maybe in beginning it was > > plain text, not any more now. Now it is a wannabe database. > > In a way it is becoming the opposite of what Carsten was trying to do > in the beginning. And plain text is always portable. > > We should not exclude the original intention and use, making it fully > database. It is already text type of a database with structured data built into properties and tags, headings, body of headings, etc. Just that it is scattered database of things that do not have well defined its own place. As I see it, one could keep Org file in the database and edit it on the file system and that it all gets updated to the database. That way it would become collaborative Org mode. It is easier than one can imagine. I was using simple function to update Org TODO tasks to database. (defun hyperscope-capture-org-heading () "Captures Org heading and stores it in the Hyperscope dynamic knowledge repository" (interactive) (let* ((body (org-copy-subtree nil nil nil t)) (body (pop kill-ring)) (body (org-no-properties body)) (heading (org-get-heading)) (created (org-property-values "CREATED")) (date (if created (substring (car created) 1 11) nil)) (body (with-temp-buffer (insert body) (org-mode) (org-back-to-heading) (kill-line) (delete-matching-lines ":PROPERTIES:") (delete-matching-lines ":CREATED:") (delete-matching-lines ":ID:") (delete-matching-lines ":END:") (buffer-string (hyperscope-add-note-to-set-1 heading body date))) (defun hyperscope-capture-org-heading-as-note-for-person () "Captures Org heading for a person and stores it in the Hyperscope dynamic knowledge repository" (interactive) (let* ((body (org-copy-subtree nil nil nil t)) (body (pop kill-ring)) (body (org-no-properties body)) (heading (org-get-heading)) (created (org-property-values "CREATED")) (date (if created (substring (car created) 1 11) nil)) (body (with-temp-buffer (insert body) (org-mode) (org-back-to-heading) (kill-line) (delete-matching-lines ":PROPERTIES:") (delete-matching-lines ":CREATED:") (delete-matching-lines ":ID:") (delete-matching-lines ":END:") (buffer-string))) (contact (cf-search-id (read-from-minibuffer "Contact: " nil nil nil 'cf-search-history (hyperscope-add-note-to-set-1 heading body date))) Similar functions could be used to to simply update the record in the database. And all meta data of Org properties, tags, etc, all that could be inserted into database. Jean
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Sunday, December 13, 2020 at 6:31 PM > From: "Jean Louis" > To: "Ihor Radchenko" > Cc: emacs-orgmode@gnu.org > Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting > user options > > * Ihor Radchenko [2020-12-13 12:25]: > > Jean Louis writes: > > > > > Org files I have always found useful for project and plan documents > > > preparation, in particular LaTeX and PDF export. As that way I get > > > better readability on screen and good printed document. > > > > > > None of such projects and plans need be marked with TODO as its nature > > > is that it is action plan, all items are actionable items. We print a > > > project and execute it. People report on project steps by email. > > > > I disagree. Or rather it depends on workflow: > > In the process of writing a plan or document there is sometimes an urge > > to fix small details instead of finishing the first draft and moving to > > more fine-grained edits afterwards. One way around this urge is quickly > > inserting an inline todo item and continuing to write (another way is > > writing on paper, but one would need to spend extra time re-typing the > > hand writing later). > > Aha yes, in the context of finishing documents some items cannot be > completed and that is where TODO comes handy to know where to come > back to finish the document, while other items get completed in the > same time. But then again I never need an Org mode for that. I write > in LaTeX and plain TeX too, there are programs, so I always leave > there some tags in comments, usually also TODO. But is not Org mode > dependent. It becomes important for professional writers in the context of finishing articles and books. > Practically, if I write "TODO" on the heading then something is very > wrong with all heading. I write a tag ;; TODO in Lisp code when I need > to improve specific line of code to something else in future. Anybody > can invent any kind of tags or even just note line numbers at begin or > end of file. Should not be Org related in general. > > If my text under heading is large I rather like to bookmark where to > come then to rely on TODO tag on the heading as it will not pinpoint > where exactly I have to continue. > > > If the document text has inline todo items, it could be useful to mark > > the top-level headline todo as well, simply to remind about any ideas > > postponed during the writing. Such headline cannot be switched to done > > if org enforced todo dependencies. > > Do you mean this: > > ** DONE Objective >CLOSED: [2020-12-13 Sun 20:00] > *** TODO [#B] Step to do 1 > *** TODO Step to do 2 > > when org-enforce-todo-dependencies is true I can still say DONE for > Objective above. I have mentioned it today already. Maybe it works on > your side, it does not work here. Do I do something wrong? I am on > development Emacs version and it does not enforce under emacs -Q > > Project planning shall always start backwards from known objective to > be achieved. Subordinate tasks should become superfluous or redundant > as soon as objective have been achieved. > > Scattered tasks without objective also have its objectives, they are > just not sorted well. Good organizing means to put it under right > objective and work by achieving objectives. City administrations do > like that. Military does like that. Boy scouts do like > that. Humanitarian organization. > > > Todo keywords don't have to be included into exported version of the > > document. > > Sure. Sometimes is necessary, sometimes not. > > > >> Unless I am badly mistaken, I think this is only true when > > >> org-enforce-todo-dependencies is non-nil? > > > > > > Variable is nil on my side. > > > > > > - [-] Something > > > - [ ] one > > > - [ ] two > > > - [X] three > > > > > > I cannot mark Something to be done without marking those subordinate > > > items. Changing org-enforce-todo-dependencies does not change > > > anything. User will need to lie to oneself to close those items to > > > become able to close senior item. > > > > I believe it is hard-coded. One may send a feature request to have more > > control over this behaviour. > > It looks like I am only one observing that. And especially me I do not > like depending on Org mode to dictate how to close items. So when > there is somebody else to join in the notion that is where feature is > appropriate. Otherwise I consider Org rather made and designed for > other way thinkers and doers, not for us
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Sunday, December 13, 2020 at 6:31 PM > From: "Jean Louis" > To: "Ihor Radchenko" > Cc: emacs-orgmode@gnu.org > Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting > user options > > * Ihor Radchenko [2020-12-13 12:25]: > > Jean Louis writes: > > > > > Org files I have always found useful for project and plan documents > > > preparation, in particular LaTeX and PDF export. As that way I get > > > better readability on screen and good printed document. > > > > > > None of such projects and plans need be marked with TODO as its nature > > > is that it is action plan, all items are actionable items. We print a > > > project and execute it. People report on project steps by email. > > > > I disagree. Or rather it depends on workflow: > > In the process of writing a plan or document there is sometimes an urge > > to fix small details instead of finishing the first draft and moving to > > more fine-grained edits afterwards. One way around this urge is quickly > > inserting an inline todo item and continuing to write (another way is > > writing on paper, but one would need to spend extra time re-typing the > > hand writing later). > > Aha yes, in the context of finishing documents some items cannot be > completed and that is where TODO comes handy to know where to come > back to finish the document, while other items get completed in the > same time. But then again I never need an Org mode for that. I write > in LaTeX and plain TeX too, there are programs, so I always leave > there some tags in comments, usually also TODO. But is not Org mode > dependent. > > Practically, if I write "TODO" on the heading then something is very > wrong with all heading. I write a tag ;; TODO in Lisp code when I need > to improve specific line of code to something else in future. Anybody > can invent any kind of tags or even just note line numbers at begin or > end of file. Should not be Org related in general. > > If my text under heading is large I rather like to bookmark where to > come then to rely on TODO tag on the heading as it will not pinpoint > where exactly I have to continue. > > > If the document text has inline todo items, it could be useful to mark > > the top-level headline todo as well, simply to remind about any ideas > > postponed during the writing. Such headline cannot be switched to done > > if org enforced todo dependencies. > > Do you mean this: > > ** DONE Objective >CLOSED: [2020-12-13 Sun 20:00] > *** TODO [#B] Step to do 1 > *** TODO Step to do 2 > > when org-enforce-todo-dependencies is true I can still say DONE for > Objective above. I have mentioned it today already. Maybe it works on > your side, it does not work here. Do I do something wrong? I am on > development Emacs version and it does not enforce under emacs -Q > > Project planning shall always start backwards from known objective to > be achieved. Subordinate tasks should become superfluous or redundant > as soon as objective have been achieved. > > Scattered tasks without objective also have its objectives, they are > just not sorted well. Good organizing means to put it under right > objective and work by achieving objectives. City administrations do > like that. Military does like that. Boy scouts do like > that. Humanitarian organization. > > > Todo keywords don't have to be included into exported version of the > > document. > > Sure. Sometimes is necessary, sometimes not. > > > >> Unless I am badly mistaken, I think this is only true when > > >> org-enforce-todo-dependencies is non-nil? > > > > > > Variable is nil on my side. > > > > > > - [-] Something > > > - [ ] one > > > - [ ] two > > > - [X] three > > > > > > I cannot mark Something to be done without marking those subordinate > > > items. Changing org-enforce-todo-dependencies does not change > > > anything. User will need to lie to oneself to close those items to > > > become able to close senior item. > > > > I believe it is hard-coded. One may send a feature request to have more > > control over this behaviour. > > It looks like I am only one observing that. And especially me I do not > like depending on Org mode to dictate how to close items. So when > there is somebody else to join in the notion that is where feature is > appropriate. Otherwise I consider Org rather made and designed for > other way thinkers and doers, not for us who think from senior > objectives as priorities where subordinate items should become >
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Sunday, December 13, 2020 at 2:19 PM > From: "Jean Louis" > To: daniela-s...@gmx.it > Cc: to...@tuxteam.de, emacs-orgmode@gnu.org, "Ihor Radchenko" > > Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting > user options > > * daniela-s...@gmx.it [2020-12-13 08:52]: > > > In general Org mode is excellent for personal TODO lists. That is what > > > is offered in the menu, that is what is advertised. Problem is that > > > there is no warning for users that personal TODO lists are not meant > > > for anything but that. There is no collaboration, putting TODO items > > > eveywhere IS procrastination. Using org-agenda to find procrastination > > > is another procrastination. Trying to glue everything together is > > > absence of good planning and not planning. > > > > Carsten would disagree with that evaluation. It is also for organising > > professional life - with plain text. Still, if you are disorganized, > > you can use it. Or perhaps if one is lazy - like myself, many things > > I do nat have an interest in but have to oversee at least some parts of > > them. > > Agree or not, it is written in the manual. The paradigm of organizing > life does not inherit from Org. What inherits from Org is the paradigm > to put any actionable items anywhere and compensate for scattered > things by using org-agenda. > > Reference to manual: > (info "(org) TODO Items") > > And it is definitely not a "plain text". It is probably largest mode > for Emacs, a true and full application handling much more than plain > text. It has more than 129 Emacs Lisp files. Maybe in beginning it was > plain text, not any more now. Now it is a wannabe database. In a way it is becoming the opposite of what Carsten was trying to do in the beginning. And plain text is always portable. We should not exclude the original intention and use, making it fully database. > As I did notice the pattern of compensation for procrastination, and > that I need more and more Emacs Lisp to fullfil basic human real world > needs, then I rather made my own system that is meta level to Org > files. Collaboration becomes possible due to the database being > designed for multiple users. Privileges become possible for same > reason. Automatic version control becomes possible database > backed. Changes can be tracked back to know which user changed > SCHEDULED to DEADLINE or DEADLINE to SCHEDULED or moved SCHEDULED > forward in time or changed DEADLINE not to be DEADLINE any more. Who > assigned which task to which person is easily viewable. People > assigned need to be contacted, list of those people is there with > hyperlinks and functions to send them email, SMS or call them. Org > agenda need not compensate for anything. I can also put scattered > tasks and note as I wish but I don't. My capture templates are over > 1100+ subjects among which I probably use actively only 20-50, did not > count it. Emacs Lisp handling that is currently 137 kilobytes. It did > not yet reach 4.7 megabytes as Org distribution. I can convert > everything to Org file when necessary. > > Even editing Org file by updating database is possible, but I do not > wish to go back to complexities. My "headings" I call hyperdocuments > which can be just anything. They can be packaged together or released > together with the Org file summarizing them all. They can become Org > file all together. It can be markdown, really plain text, video files, > references of all kinds, also Org files, or just headings of > it. Everything becomes elementary object of one bigger picture > according to Engelbart: > > Doug Engelbart Institute - Boosting mankind's capability for coping with > complex, urgent problems > https://www.dougengelbart.org/ > > Draft OHS-Project Plan > https://web.archive.org/web/20070704185333/http://www.bootstrap.org/augdocs/bi-2120.html > > TECHNOLOGY TEMPLATE PROJECT OHS Framework > https://www.dougengelbart.org/content/view/110/460/ > > Design of any software would be better by following the Open > Hyperdocument System project plan. > > > I often include org commands in source code which I can then parse. > > For instance, I can use it to determine the cyclomatic complexity of > > code, and help in admin tasks. > > I have no idea what is cyclomatic. Code definitely get complex. Give > some example how are you putting org commands in source code. > > On my side I also use GNU Hyperbole package. In Emacs lisp M-RET on a > function brings me to function definition which is very handy. I can > invoke email on region or buffer text. I can define buttons in
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
* Ihor Radchenko [2020-12-13 12:25]: > Jean Louis writes: > > > Org files I have always found useful for project and plan documents > > preparation, in particular LaTeX and PDF export. As that way I get > > better readability on screen and good printed document. > > > > None of such projects and plans need be marked with TODO as its nature > > is that it is action plan, all items are actionable items. We print a > > project and execute it. People report on project steps by email. > > I disagree. Or rather it depends on workflow: > In the process of writing a plan or document there is sometimes an urge > to fix small details instead of finishing the first draft and moving to > more fine-grained edits afterwards. One way around this urge is quickly > inserting an inline todo item and continuing to write (another way is > writing on paper, but one would need to spend extra time re-typing the > hand writing later). Aha yes, in the context of finishing documents some items cannot be completed and that is where TODO comes handy to know where to come back to finish the document, while other items get completed in the same time. But then again I never need an Org mode for that. I write in LaTeX and plain TeX too, there are programs, so I always leave there some tags in comments, usually also TODO. But is not Org mode dependent. Practically, if I write "TODO" on the heading then something is very wrong with all heading. I write a tag ;; TODO in Lisp code when I need to improve specific line of code to something else in future. Anybody can invent any kind of tags or even just note line numbers at begin or end of file. Should not be Org related in general. If my text under heading is large I rather like to bookmark where to come then to rely on TODO tag on the heading as it will not pinpoint where exactly I have to continue. > If the document text has inline todo items, it could be useful to mark > the top-level headline todo as well, simply to remind about any ideas > postponed during the writing. Such headline cannot be switched to done > if org enforced todo dependencies. Do you mean this: ** DONE Objective CLOSED: [2020-12-13 Sun 20:00] *** TODO [#B] Step to do 1 *** TODO Step to do 2 when org-enforce-todo-dependencies is true I can still say DONE for Objective above. I have mentioned it today already. Maybe it works on your side, it does not work here. Do I do something wrong? I am on development Emacs version and it does not enforce under emacs -Q Project planning shall always start backwards from known objective to be achieved. Subordinate tasks should become superfluous or redundant as soon as objective have been achieved. Scattered tasks without objective also have its objectives, they are just not sorted well. Good organizing means to put it under right objective and work by achieving objectives. City administrations do like that. Military does like that. Boy scouts do like that. Humanitarian organization. > Todo keywords don't have to be included into exported version of the > document. Sure. Sometimes is necessary, sometimes not. > >> Unless I am badly mistaken, I think this is only true when > >> org-enforce-todo-dependencies is non-nil? > > > > Variable is nil on my side. > > > > - [-] Something > > - [ ] one > > - [ ] two > > - [X] three > > > > I cannot mark Something to be done without marking those subordinate > > items. Changing org-enforce-todo-dependencies does not change > > anything. User will need to lie to oneself to close those items to > > become able to close senior item. > > I believe it is hard-coded. One may send a feature request to have more > control over this behaviour. It looks like I am only one observing that. And especially me I do not like depending on Org mode to dictate how to close items. So when there is somebody else to join in the notion that is where feature is appropriate. Otherwise I consider Org rather made and designed for other way thinkers and doers, not for us who think from senior objectives as priorities where subordinate items should become redundant and not marked as "done". My personal list of for a day has 7 items currently. Not 250. Those are rather objectives, goals and purposes. Single items under objectives are well known actions to be done and need not be marked as TODO, but I can. My focus is on the meaning of what has to be done and I do not need to look into tags or properties. Your informational emails gave me to thinking so I have implemented it all. > > If I do turn on the mentioned variable `org-enforce-todo-dependencies' > > to TRUE, I can still close the senior objective here. This is good, > > but variable does not do expected. > > > ** DONE Senior objective > >CLOSED: [2020-12-13 Sun 11:22] > I cannot reproduce what you observe. Also, one can forcefully change > todo state to done even when org-enforce-todo-dependencies is set to > TRUE. To do it, C-u C-u C-u C-c C-t needs to be used instead of C-c C-t >
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
* daniela-s...@gmx.it [2020-12-13 08:52]: > > In general Org mode is excellent for personal TODO lists. That is what > > is offered in the menu, that is what is advertised. Problem is that > > there is no warning for users that personal TODO lists are not meant > > for anything but that. There is no collaboration, putting TODO items > > eveywhere IS procrastination. Using org-agenda to find procrastination > > is another procrastination. Trying to glue everything together is > > absence of good planning and not planning. > > Carsten would disagree with that evaluation. It is also for organising > professional life - with plain text. Still, if you are disorganized, > you can use it. Or perhaps if one is lazy - like myself, many things > I do nat have an interest in but have to oversee at least some parts of > them. Agree or not, it is written in the manual. The paradigm of organizing life does not inherit from Org. What inherits from Org is the paradigm to put any actionable items anywhere and compensate for scattered things by using org-agenda. Reference to manual: (info "(org) TODO Items") And it is definitely not a "plain text". It is probably largest mode for Emacs, a true and full application handling much more than plain text. It has more than 129 Emacs Lisp files. Maybe in beginning it was plain text, not any more now. Now it is a wannabe database. As I did notice the pattern of compensation for procrastination, and that I need more and more Emacs Lisp to fullfil basic human real world needs, then I rather made my own system that is meta level to Org files. Collaboration becomes possible due to the database being designed for multiple users. Privileges become possible for same reason. Automatic version control becomes possible database backed. Changes can be tracked back to know which user changed SCHEDULED to DEADLINE or DEADLINE to SCHEDULED or moved SCHEDULED forward in time or changed DEADLINE not to be DEADLINE any more. Who assigned which task to which person is easily viewable. People assigned need to be contacted, list of those people is there with hyperlinks and functions to send them email, SMS or call them. Org agenda need not compensate for anything. I can also put scattered tasks and note as I wish but I don't. My capture templates are over 1100+ subjects among which I probably use actively only 20-50, did not count it. Emacs Lisp handling that is currently 137 kilobytes. It did not yet reach 4.7 megabytes as Org distribution. I can convert everything to Org file when necessary. Even editing Org file by updating database is possible, but I do not wish to go back to complexities. My "headings" I call hyperdocuments which can be just anything. They can be packaged together or released together with the Org file summarizing them all. They can become Org file all together. It can be markdown, really plain text, video files, references of all kinds, also Org files, or just headings of it. Everything becomes elementary object of one bigger picture according to Engelbart: Doug Engelbart Institute - Boosting mankind's capability for coping with complex, urgent problems https://www.dougengelbart.org/ Draft OHS-Project Plan https://web.archive.org/web/20070704185333/http://www.bootstrap.org/augdocs/bi-2120.html TECHNOLOGY TEMPLATE PROJECT OHS Framework https://www.dougengelbart.org/content/view/110/460/ Design of any software would be better by following the Open Hyperdocument System project plan. > I often include org commands in source code which I can then parse. > For instance, I can use it to determine the cyclomatic complexity of > code, and help in admin tasks. I have no idea what is cyclomatic. Code definitely get complex. Give some example how are you putting org commands in source code. On my side I also use GNU Hyperbole package. In Emacs lisp M-RET on a function brings me to function definition which is very handy. I can invoke email on region or buffer text. I can define buttons in any source code to jump anywhere else. It works in Org as well. Org hyperlinks can also work in any buffer including in source codes. I am not sure if that is wanted. Text is definitely not any more "plain text" as soon as it has Org hyperlink. GNU Hyperbole type of hyperlinks: <(Look up word)> <(Find people without assigned groups)> This is because these hyperlinks are in a separate directory file and thus separate from the text file where they are located. Org hyperlinks need to be included in the text and would look like this: [[elisp:(look-up-word)][Look up word]] I do tend to have separate hyperlink meta data from the hyperlink itself. I would prefer something more generic like look up word [3:I49] to expand to hyperlink 3 words backwords or [I49:3] 3 words forward when parsing and displaying such a file. Or simply [I49] to become hyperlink itself to the node 49. If node 49 is WWW hyperlink, let user go there. If it is note, show him the note, if it is something
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
Jean Louis writes: > Org files I have always found useful for project and plan documents > preparation, in particular LaTeX and PDF export. As that way I get > better readability on screen and good printed document. > > None of such projects and plans need be marked with TODO as its nature > is that it is action plan, all items are actionable items. We print a > project and execute it. People report on project steps by email. I disagree. Or rather it depends on workflow: In the process of writing a plan or document there is sometimes an urge to fix small details instead of finishing the first draft and moving to more fine-grained edits afterwards. One way around this urge is quickly inserting an inline todo item and continuing to write (another way is writing on paper, but one would need to spend extra time re-typing the hand writing later). If the document text has inline todo items, it could be useful to mark the top-level headline todo as well, simply to remind about any ideas postponed during the writing. Such headline cannot be switched to done if org enforced todo dependencies. > There is no need to write TODO anywhere as printed file cannot be > changed easily to DONE, it is redundant marking action list item on > the paper with anything but heavy check mark ✔ with initals and date > and time when it was completed. Using it for printed projects is not > same as using computer. In general it makes more practical sense to > export Org files to paper and focus on what has to be done instead on > focusing on decorating Org properties or tags as it wastes time. Todo keywords don't have to be included into exported version of the document. >> Unless I am badly mistaken, I think this is only true when >> org-enforce-todo-dependencies is non-nil? > > Variable is nil on my side. > > - [-] Something > - [ ] one > - [ ] two > - [X] three > > I cannot mark Something to be done without marking those subordinate > items. Changing org-enforce-todo-dependencies does not change > anything. User will need to lie to oneself to close those items to > become able to close senior item. I believe it is hard-coded. One may send a feature request to have more control over this behaviour. > One would also expect that mentioned variables should influence this > type of structured action items, but it does not. It relates only to > headings. Org offers list item based actions with - [ ] but does not > handle such. > > ** TODO Buy shoes [1/3] [33%] >:PROPERTIES: >:CREATED: [2020-12-13 Sun 11:36] >:ID: d488c7e5-941a-4ce6-aec3-e1b20e1acd70 >:END: > > - [ ] Visit shop A > - [ ] Visit shop B > - [X] Visit shop C > What is good that this way the senior item can be completed without > completing subordinate items. In my opinion that is more human alike. You need org-enforce-todo-checkbox-dependencies to look into check-boxes when changing headline todo states. > If I do turn on the mentioned variable `org-enforce-todo-dependencies' > to TRUE, I can still close the senior objective here. This is good, > but variable does not do expected. > ** DONE Senior objective >CLOSED: [2020-12-13 Sun 11:22] >:PROPERTIES: >:CREATED: [2020-12-13 Sun 11:36] >:ID: 6f2fba8a-925b-4c99-9d62-5f48d433a8cc >:END: > *** TODO Subordinate action 1 > :PROPERTIES: > :CREATED: [2020-12-13 Sun 11:36] > :ID: 1c3c2da7-c564-43e0-b274-b8f0065624ec > :END: > *** TODO Subordinate action 2 > :PROPERTIES: > :CREATED: [2020-12-13 Sun 11:36] > :ID: 9cb275fd-fcbf-441c-b42d-62c82aa3ff56 > :END: > > Variable mentions: > > Its value is t > Original value was nil > > You can customize this variable. > > Documentation: > Non-nil means undone TODO entries will block switching the parent to DONE. > Also, if a parent has an :ORDERED: property, switching an entry to DONE will > be blocked if any prior sibling is not yet done. > Finally, if the parent is blocked because of ordered siblings of its own, > the child will also be blocked. > >> Non-nil means undone TODO entries will block switching the parent to DONE. > > It obviously does not do that what me as user expects. I cannot reproduce what you observe. Also, one can forcefully change todo state to done even when org-enforce-todo-dependencies is set to TRUE. To do it, C-u C-u C-u C-c C-t needs to be used instead of C-c C-t for setting the todo state. > But I am not > asking for solution neither help in solving unsolvable issues around > Org related planning as it leads to further complexities. Those issues > are really solved on my side as I just use it for documents. Note that you are also risking to complain about things that are actually not a problem. Simply because you don't have a need to investigate what is possible. > These comments are meant for people to design their own maybe better > ways than having scattered lists everywhere. > > Jean
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
* TRS-80 [2020-12-13 06:34]: :PROPERTIES: :CREATED: [2020-12-13 Sun 11:36] :ID: 2e42666a-d04b-4f46-ba90-a923a5e2c50d :END: > On 2020-12-11 21:35, Jean Louis wrote: > > > > By the way I have completely switched all action management to my > > database system with tabulated list mode. No more using Org for action > > management, only for document, not even short notes. > > It sounds like you have well moved on to another solution by now, > however I did want to point out what I thought was one small factual > inaccuracy. Org files I have always found useful for project and plan documents preparation, in particular LaTeX and PDF export. As that way I get better readability on screen and good printed document. None of such projects and plans need be marked with TODO as its nature is that it is action plan, all items are actionable items. We print a project and execute it. People report on project steps by email. There is no need to write TODO anywhere as printed file cannot be changed easily to DONE, it is redundant marking action list item on the paper with anything but heavy check mark ✔ with initals and date and time when it was completed. Using it for printed projects is not same as using computer. In general it makes more practical sense to export Org files to paper and focus on what has to be done instead on focusing on decorating Org properties or tags as it wastes time. In general I can say that any elementary object has related action. For example URL or hyperlink can demand ACTION. It is equivalent to TODO. A hyperlink may have annotation, description or relations to some pages, people, locations and similar. A paragraph can be elementary object itself. Set of paragraphs could be elementary object. A list item could be elementary object. Any elementary object may be related to person, organization, smaller group of people or other objects, assignee or group as assigned group to conduct the action, maybe related to specific opportunity, business, page in a website revision system, file of any type, tags, or what is else necessary. Things are related. We cannot deny basic fundaments of our life. Software must be there to help align relations in human life and to ease locating related and relevant objects. In general I will prevent working for computer in my future. Computer has to work for me. Those are my personal needs that reflect on the groups positively, reasonably and practically. My staff does not even know that there exists something as "TODO" item. The nature of a document has meaning that projects are to do. > > Org mode have imposed reverse on users where for example a list of > > items is only then completed as DONE when subordinate tasks have been > > completed as DONE > > Unless I am badly mistaken, I think this is only true when > org-enforce-todo-dependencies is non-nil? Variable is nil on my side. - [-] Something - [ ] one - [ ] two - [X] three I cannot mark Something to be done without marking those subordinate items. Changing org-enforce-todo-dependencies does not change anything. User will need to lie to oneself to close those items to become able to close senior item. One would also expect that mentioned variables should influence this type of structured action items, but it does not. It relates only to headings. Org offers list item based actions with - [ ] but does not handle such. ** TODO Buy shoes [1/3] [33%] :PROPERTIES: :CREATED: [2020-12-13 Sun 11:36] :ID: d488c7e5-941a-4ce6-aec3-e1b20e1acd70 :END: - [ ] Visit shop A - [ ] Visit shop B - [X] Visit shop C What is good that this way the senior item can be completed without completing subordinate items. In my opinion that is more human alike. If I do turn on the mentioned variable `org-enforce-todo-dependencies' to TRUE, I can still close the senior objective here. This is good, but variable does not do expected. ** DONE Senior objective CLOSED: [2020-12-13 Sun 11:22] :PROPERTIES: :CREATED: [2020-12-13 Sun 11:36] :ID: 6f2fba8a-925b-4c99-9d62-5f48d433a8cc :END: *** TODO Subordinate action 1 :PROPERTIES: :CREATED: [2020-12-13 Sun 11:36] :ID: 1c3c2da7-c564-43e0-b274-b8f0065624ec :END: *** TODO Subordinate action 2 :PROPERTIES: :CREATED: [2020-12-13 Sun 11:36] :ID: 9cb275fd-fcbf-441c-b42d-62c82aa3ff56 :END: Variable mentions: Its value is t Original value was nil You can customize this variable. Documentation: Non-nil means undone TODO entries will block switching the parent to DONE. Also, if a parent has an :ORDERED: property, switching an entry to DONE will be blocked if any prior sibling is not yet done. Finally, if the parent is blocked because of ordered siblings of its own, the child will also be blocked. > Non-nil means undone TODO entries will block switching the parent to DONE. It obviously does not do that what me as user expects. But I am not asking for solution neither help in
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Sunday, December 13, 2020 at 6:19 AM > From: "Jean Louis" > To: daniela-s...@gmx.it > Cc: to...@tuxteam.de, emacs-orgmode@gnu.org, "Ihor Radchenko" > > Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting > user options > > * daniela-s...@gmx.it [2020-12-12 05:41]: > > > And I think it is possible for anybody regardless of programming skill > > > level to make one's own system of management of tasks within less than > > > a week that will get more aligned to personal individualized way of > > > handling tasks, then trying to accommodate personal needs to software > > > that may have gone one completly wrong direction. > > > > If I said that I would be barraged by accusations of rudeness! :) > > The key is in steganography: > https://en.wikipedia.org/wiki/Steganography :) > Org mode is popular within subset of population using it where each > other encourage to use it more regardless of how much tedious efforts > it needs itself just to function how users would like it. Additionally > majority of users use functions of Org mode which they would not need > would they be simple be organized. A person well organized does not > look throug agenda as that means lack of organization. Agenda helps > those which are not organized. Just look at any friend or person who > organizes life without computer and compare to people using Org > mode. Software should replace slow methods with papers and make > planning faster and non-repetitive. Any software shall help human to > speed up actions. > > In general Org mode is excellent for personal TODO lists. That is what > is offered in the menu, that is what is advertised. Problem is that > there is no warning for users that personal TODO lists are not meant > for anything but that. There is no collaboration, putting TODO items > eveywhere IS procrastination. Using org-agenda to find procrastination > is another procrastination. Trying to glue everything together is > absence of good planning and not planning. Carsten would disagree with that evaluation. It is also for organising professional life - with plain text. Still, if you are disorganized, you can use it. Or perhaps if one is lazy - like myself, many things I do nat have an interest in but have to oversee at least some parts of them. > While reading how people write to mailing list trying to solve > problems they would never solve in the real world with paper I am > getting more and more surprised. > > What Org mode needs is at least few Wiki pages where various methods > of planning are presented as that could be useful to help people > minimize their procrastination. > > My experience comes from writing plans since more than 25 years. I was > always writing it on paper. Actions are chronologically and logically > ordered. Main objectives are always well defined for which purpose > subordinate actions have to be conducted. If main objectives are > fullfiled those subordinate actions become redundant or superfluous. > > From Org info file: > > > 5 TODO Items > > > > > Org mode does not maintain TODO lists as separate documents(1). > > Instead, TODO items are an integral part of the notes file, because TODO > > items usually come up while taking notes! > > For personal planning this may be fine for many, but I consider it bad > habbit. If there is an action item then put any information necessary > for that action within the action item. Print it along if > necessary. Handle your thinker notes first once and completely and > include what is necessary in action items. > > - person will not read the notes written back in time over and over > again. > > - if notes are not necessary for the action, why put them in front of > oneself to be read > > - horrible situations will take place if those notes which are not > necessary are put in front of collaborator who is now expected to > read action item and fulfill the action > > > because TODO items usually come up while taking notes! > > My action items have been written in project documents executed by > multiple groups of people in multiple countries on distances of 5000+ > kilometers away including by people who have never seen me face to > face. I have never put "notes" together with action items. > > Whoever wrote that "TODO items usually comes up while taking notes" > was referring to oneself and imposes this habit which I never had onto > others. > > In other words the manual imposes specific method of planning without > comparison to other methods of planning. Then users learn that is > right thing to do, ah, let me put everyth
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
* daniela-s...@gmx.it [2020-12-12 05:41]: > > And I think it is possible for anybody regardless of programming skill > > level to make one's own system of management of tasks within less than > > a week that will get more aligned to personal individualized way of > > handling tasks, then trying to accommodate personal needs to software > > that may have gone one completly wrong direction. > > If I said that I would be barraged by accusations of rudeness! :) The key is in steganography: https://en.wikipedia.org/wiki/Steganography Org mode is popular within subset of population using it where each other encourage to use it more regardless of how much tedious efforts it needs itself just to function how users would like it. Additionally majority of users use functions of Org mode which they would not need would they be simple be organized. A person well organized does not look throug agenda as that means lack of organization. Agenda helps those which are not organized. Just look at any friend or person who organizes life without computer and compare to people using Org mode. Software should replace slow methods with papers and make planning faster and non-repetitive. Any software shall help human to speed up actions. In general Org mode is excellent for personal TODO lists. That is what is offered in the menu, that is what is advertised. Problem is that there is no warning for users that personal TODO lists are not meant for anything but that. There is no collaboration, putting TODO items eveywhere IS procrastination. Using org-agenda to find procrastination is another procrastination. Trying to glue everything together is absence of good planning and not planning. While reading how people write to mailing list trying to solve problems they would never solve in the real world with paper I am getting more and more surprised. What Org mode needs is at least few Wiki pages where various methods of planning are presented as that could be useful to help people minimize their procrastination. My experience comes from writing plans since more than 25 years. I was always writing it on paper. Actions are chronologically and logically ordered. Main objectives are always well defined for which purpose subordinate actions have to be conducted. If main objectives are fullfiled those subordinate actions become redundant or superfluous. >From Org info file: > 5 TODO Items > > Org mode does not maintain TODO lists as separate documents(1). > Instead, TODO items are an integral part of the notes file, because TODO > items usually come up while taking notes! For personal planning this may be fine for many, but I consider it bad habbit. If there is an action item then put any information necessary for that action within the action item. Print it along if necessary. Handle your thinker notes first once and completely and include what is necessary in action items. - person will not read the notes written back in time over and over again. - if notes are not necessary for the action, why put them in front of oneself to be read - horrible situations will take place if those notes which are not necessary are put in front of collaborator who is now expected to read action item and fulfill the action > because TODO items usually come up while taking notes! My action items have been written in project documents executed by multiple groups of people in multiple countries on distances of 5000+ kilometers away including by people who have never seen me face to face. I have never put "notes" together with action items. Whoever wrote that "TODO items usually comes up while taking notes" was referring to oneself and imposes this habit which I never had onto others. In other words the manual imposes specific method of planning without comparison to other methods of planning. Then users learn that is right thing to do, ah, let me put everything together. Since 2016 almost all project planning was written by Org mode as I find it useful to get LaTeX/PDF output. It is then printed, carried physically by people on the ground and signed with initialy physically by hand as DONE with the date and time. There known objectives and those are targets to be fulfilled. Any notes arriving back from collaborators are not placed into project planning. If such would enhance project planning they could become part of planning for the next project. But generally the feedback notes do not relate to project planning itself, they relate to people, organizations, findings on ground, they are part of the report. It is not necessary to re-write the report back into any Org file as the plan is separate from reports and executions. Conclusions which come later could result in some new plan. But initial plan is not to be mixed with new information, it is rather kept intact and maybe improved for next time execution. > With Org mode, simply mark any entry in a tree as being a TODO > item. In this way, information is not
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
On 2020-12-11 21:35, Jean Louis wrote: By the way I have completely switched all action management to my database system with tabulated list mode. No more using Org for action management, only for document, not even short notes. It sounds like you have well moved on to another solution by now, however I did want to point out what I thought was one small factual inaccuracy. Org mode have imposed reverse on users where for example a list of items is only then completed as DONE when subordinate tasks have been completed as DONE Unless I am badly mistaken, I think this is only true when org-enforce-todo-dependencies is non-nil? Cheers, TRS-80
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Saturday, December 12, 2020 at 3:35 AM > From: "Jean Louis" > To: "Ihor Radchenko" > Cc: daniela-s...@gmx.it, to...@tuxteam.de, emacs-orgmode@gnu.org > Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting > user options > > * Ihor Radchenko [2020-12-11 17:24]: > > > ... there is no active > > > hacking on org-agenda and adding new features. > > > > You are welcome to submit patches. > > > > I have experimental code to use pretty-symbols in agenda and align tags > > even when frame size changes [1]. However, last time I proposed this on > > mailing list, there was no interest... > > > > [1] https://orgmode.org/list/87r1v71aw0.fsf@localhost/ > > By the way I have completely switched all action management to my > database system with tabulated list mode. No more using Org for action > management, only for document, not even short notes. Access to notes > by relevance search by using PostgreSQL full text search is so much > more logical personally. Computer performs search but as database is > more compact it does not search over all files. Things are easily > reordered rather then refiled. Key bindings for majority of actions > are way shorter as tabulated list mode is not editing mode. > > - tasks can be assigned to one among 200,000+ people in the database, > and I need not take care how their names are written and if I will > lose a task because I made a type in writing their names. Person is > rather selected and computer thinks what is their unique ID, not > name. > > - listing tasks assigned to specific person or group of people is > quick and easy, related to person or group is quick or easy. > > - daily list of pending tasks can be sent by email automatically, list > of completed tasks can be sent. Task as such can be sent with one or > two keys pressed without me thinking as all related objects are > integrated (email address of assignee is already known). > > - I need not keep one list of assignees in one file, other list in > other file, etc. I can list all asignees straight with one key or > see actions assigned to them. > > - and I do not write subordinate tasks as TODO any more, that makes no > sense. There is one senior section on what subject, project or > objective has to be fullfiled and those subordinate tasks which are > not marked with TODO repetitevely can be marked as redundant or > superfluous, purposeless when senior objective have been > completed. This means they are not done as there is no need to get > something done if objective have been fullfiled. Org mode have > imposed reverse on users where for example a list of items is only > then completed as DONE when subordinate tasks have been completed as > DONE, which makes users lie to themselves as they will then > "complete" the task which is not complete because it is purposeless > only to complete the senior task as DONE. > > And I think it is possible for anybody regardless of programming skill > level to make one's own system of management of tasks within less than > a week that will get more aligned to personal individualized way of > handling tasks, then trying to accommodate personal needs to software > that may have gone one completly wrong direction. If I said that I would be barraged by accusations of rudeness! :) > Software is there to help the human, not human to help the software. > >
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
* Ihor Radchenko [2020-12-11 17:24]: > > ... there is no active > > hacking on org-agenda and adding new features. > > You are welcome to submit patches. > > I have experimental code to use pretty-symbols in agenda and align tags > even when frame size changes [1]. However, last time I proposed this on > mailing list, there was no interest... > > [1] https://orgmode.org/list/87r1v71aw0.fsf@localhost/ By the way I have completely switched all action management to my database system with tabulated list mode. No more using Org for action management, only for document, not even short notes. Access to notes by relevance search by using PostgreSQL full text search is so much more logical personally. Computer performs search but as database is more compact it does not search over all files. Things are easily reordered rather then refiled. Key bindings for majority of actions are way shorter as tabulated list mode is not editing mode. - tasks can be assigned to one among 200,000+ people in the database, and I need not take care how their names are written and if I will lose a task because I made a type in writing their names. Person is rather selected and computer thinks what is their unique ID, not name. - listing tasks assigned to specific person or group of people is quick and easy, related to person or group is quick or easy. - daily list of pending tasks can be sent by email automatically, list of completed tasks can be sent. Task as such can be sent with one or two keys pressed without me thinking as all related objects are integrated (email address of assignee is already known). - I need not keep one list of assignees in one file, other list in other file, etc. I can list all asignees straight with one key or see actions assigned to them. - and I do not write subordinate tasks as TODO any more, that makes no sense. There is one senior section on what subject, project or objective has to be fullfiled and those subordinate tasks which are not marked with TODO repetitevely can be marked as redundant or superfluous, purposeless when senior objective have been completed. This means they are not done as there is no need to get something done if objective have been fullfiled. Org mode have imposed reverse on users where for example a list of items is only then completed as DONE when subordinate tasks have been completed as DONE, which makes users lie to themselves as they will then "complete" the task which is not complete because it is purposeless only to complete the senior task as DONE. And I think it is possible for anybody regardless of programming skill level to make one's own system of management of tasks within less than a week that will get more aligned to personal individualized way of handling tasks, then trying to accommodate personal needs to software that may have gone one completly wrong direction. Software is there to help the human, not human to help the software.
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Friday, December 11, 2020 at 4:46 PM > From: to...@tuxteam.de > To: daniela-s...@gmx.it > Cc: emacs-orgmode@gnu.org > Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting > user options > > On Fri, Dec 11, 2020 at 03:54:01PM +0100, daniela-s...@gmx.it wrote: > > Two countrymen conspiring together. > > Calm down. The Germans ain't after you (BTW: I may have a .de > address -- still I am not German. On the Internet, they say, > nobody knows you're a dog [1]). I'm a little cat really :) > Cheers > > [1] https://en.wikipedia.org/wiki/On_the_Internet%2C_nobody_knows_you're_a_dog > > - t >
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
On Fri, Dec 11, 2020 at 03:54:01PM +0100, daniela-s...@gmx.it wrote: > Two countrymen conspiring together. Calm down. The Germans ain't after you (BTW: I may have a .de address -- still I am not German. On the Internet, they say, nobody knows you're a dog [1]). Cheers [1] https://en.wikipedia.org/wiki/On_the_Internet%2C_nobody_knows_you're_a_dog - t signature.asc Description: Digital signature
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
Two countrymen conspiring together. > Sent: Friday, December 11, 2020 at 3:43 PM > From: to...@tuxteam.de > To: daniela-s...@gmx.it > Cc: emacs-orgmode@gnu.org > Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting > user options > > On Fri, Dec 11, 2020 at 02:47:27PM +0100, daniela-s...@gmx.it wrote: > > > > Freak out how much you like but it occurs to me that there is no active > > hacking on org-agenda and adding new features. Or it may be that there > > are no new ideas and you are getting upset about it. > > No need to second-guess me. As Detlef wrote in this thread, > I meant what I wrote -- no more, no less. > > Cheers > - t >
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Friday, December 11, 2020 at 3:26 PM > From: "Ihor Radchenko" > To: daniela-s...@gmx.it, to...@tuxteam.de > Cc: emacs-orgmode@gnu.org > Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting > user options > > > ... there is no active > > hacking on org-agenda and adding new features. > > You are welcome to submit patches. > > I have experimental code to use pretty-symbols in agenda and align tags > even when frame size changes [1]. However, last time I proposed this on > mailing list, there was no interest... > > [1] https://orgmode.org/list/87r1v71aw0.fsf@localhost/ Was your patch welcomed? Perhaps it is time to bring the topics again. It could be that there are some criteria for patches to go on the official version. I have had times when I made comments and the problem gets understood quite some time later. At times it is wise to assume the person reporting an encountered difficulty is aware of something you ain't. It is- good to add patches, but at times people report something for the benefit of everybody, not just themselves. I should add that I resolved the problem so have no need to argue how rude I can be. We all know that there are many in the community who lack social skills. I went to one group meeting one time, and buggered off in less than five minutes. Regards Daniela
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
On Fri, Dec 11, 2020 at 02:47:27PM +0100, daniela-s...@gmx.it wrote: > > Freak out how much you like but it occurs to me that there is no active > hacking on org-agenda and adding new features. Or it may be that there > are no new ideas and you are getting upset about it. No need to second-guess me. As Detlef wrote in this thread, I meant what I wrote -- no more, no less. Cheers - t signature.asc Description: Digital signature
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
Stick to the topic. She encountered an org-agenda problem and she figured out what was happening by herself. And I'm sure it was not without any toil. > Sent: Friday, December 11, 2020 at 2:59 PM > From: "Detlef Steuer" > To: emacs-orgmode@gnu.org > Cc: to...@tuxteam.de > Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting > user options > > Am Fri, 11 Dec 2020 14:47:27 +0100 > schrieb daniela-s...@gmx.it: > > > Freak out how much you like but it occurs to me that there is no > > active hacking on org-agenda and adding new features. Or it may be > > that there are no new ideas and you are getting upset about it. > > Hmm, may be he just meant, what he very politely said. > > Intended or not you come across in quite a rude way. > I share that feeling of Tomas. > > All the best > detlef > >
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> ... there is no active > hacking on org-agenda and adding new features. You are welcome to submit patches. I have experimental code to use pretty-symbols in agenda and align tags even when frame size changes [1]. However, last time I proposed this on mailing list, there was no interest... [1] https://orgmode.org/list/87r1v71aw0.fsf@localhost/
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
Perhaps I should be a stand up comedian! You want to enforce some social repercussions like you did with Richard Stallman? > Sent: Friday, December 11, 2020 at 2:59 PM > From: "Detlef Steuer" > To: emacs-orgmode@gnu.org > Cc: to...@tuxteam.de > Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting > user options > > Am Fri, 11 Dec 2020 14:47:27 +0100 > schrieb daniela-s...@gmx.it: > > > Freak out how much you like but it occurs to me that there is no > > active hacking on org-agenda and adding new features. Or it may be > > that there are no new ideas and you are getting upset about it. > > Hmm, may be he just meant, what he very politely said. > > Intended or not you come across in quite a rude way. > I share that feeling of Tomas. > > All the best > detlef > >
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
Am Fri, 11 Dec 2020 14:47:27 +0100 schrieb daniela-s...@gmx.it: > Freak out how much you like but it occurs to me that there is no > active hacking on org-agenda and adding new features. Or it may be > that there are no new ideas and you are getting upset about it. Hmm, may be he just meant, what he very politely said. Intended or not you come across in quite a rude way. I share that feeling of Tomas. All the best detlef
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
Freak out how much you like but it occurs to me that there is no active hacking on org-agenda and adding new features. Or it may be that there are no new ideas and you are getting upset about it. > Sent: Friday, December 11, 2020 at 9:25 AM > From: to...@tuxteam.de > To: emacs-orgmode@gnu.org > Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting > user options > > On Fri, Dec 11, 2020 at 05:32:39AM +0100, daniela-s...@gmx.it wrote: > > [...] > > > There are problems in Org-Agenda my friend [...] > > I don't know whether it's your intention (I'm assuming it's not), > but your tone comes across as pretty rude. > > Cheers > - t >
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
On Fri, Dec 11, 2020 at 05:32:39AM +0100, daniela-s...@gmx.it wrote: [...] > There are problems in Org-Agenda my friend [...] I don't know whether it's your intention (I'm assuming it's not), but your tone comes across as pretty rude. Cheers - t signature.asc Description: Digital signature
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
* TRS-80 [2020-12-11 08:23]: > On 2020-11-29 17:08, daniela-s...@gmx.it wrote: > > Yes, there are problems with the documentation. I noticed > > recently that some guy criticised the manual, and so many got > > super defensive. You should give him a medal for telling you how > > things are. > I guess in my mind, complaining about the manual, to a bunch of > volunteers and fellow users, is probably on the pretty unhelpful end > of the scale. Please assume good faith while trying not to wrong users. GNU Kind Communications Guidelines https://www.gnu.org/philosophy/kind-communication.html
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
On 2020-11-29 17:08, daniela-s...@gmx.it wrote: Yes, there are problems with the documentation. I noticed recently that some guy criticised the manual, and so many got super defensive. You should give him a medal for telling you how things are. I guess in my mind, complaining about the manual, to a bunch of volunteers and fellow users, is probably on the pretty unhelpful end of the scale. Making constructive criticism is then slightly better, at least you are not deriding (mostly volunteer) people's work and effort. Although not by much, as this still does not require too much effort. However submitting a patch with an improvement to the documentation is quite valuable. Pretty much on the opposite end of the scale in fact. And thus, only this level of contribution "deserves a medal" as far as I am concerned. I was not privy to particulars of conversation you mention, although I have seen this sort of entitled attitude often enough in F/LOSS to have somewhat of an idea of how it might have played out. Entitled users becoming demanding of things they expect (for free, no less) is not just a drag, it's the cancer that slowly kills F/LOSS projects. As eventually actually valuable contributors (maintainers, devs, etc.) have had enough of it, get burnt out and leave the project. I have seen it far too many times over the years. So I imagine what you witnessed was a sort of natural defense mechanism, protecting the overall health of the community and project by having a strong reaction to such negative attitudes. Cheers, TRS-80
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Friday, December 11, 2020 at 4:59 AM > From: "TRS-80" > To: daniela-s...@gmx.it > Cc: "Kyle Meyer" , "Tom Gillespie" , > "Org-Mode mailing list" , "Emacs-orgmode" > > Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting > user options > > On 2020-11-29 17:08, daniela-s...@gmx.it wrote: > > > > Yes, there are problems with the documentation. I noticed recently > > that > > some guy criticised the manual, and so many got super defensive. You > > should > > give him a medal for telling you how things are. > > I guess in my mind, complaining about the manual, to a bunch of > volunteers and fellow users, is probably on the pretty unhelpful end of > the scale. > > Making constructive criticism is then slightly better, at least you are > not deriding (mostly volunteer) people's work and effort. Although not > by much, as this still does not require too much effort. > > However submitting a patch with an improvement to the documentation is > quite valuable. Pretty much on the opposite end of the scale in fact. > And thus, only this level of contribution "deserves a medal" as far as I > am concerned. > > I was not privy to particulars of conversation you mention, although I > have seen this sort of entitled attitude often enough in F/LOSS to have > somewhat of an idea of how it might have played out. > > Entitled users becoming demanding of things they expect (for free, no > less) is not just a drag, it's the cancer that slowly kills F/LOSS > projects. As eventually actually valuable contributors (maintainers, > devs, etc.) have had enough of it, get burnt out and leave the project. > I have seen it far too many times over the years. > > So I imagine what you witnessed was a sort of natural defense mechanism, > protecting the overall health of the community and project by having a > strong reaction to such negative attitudes. There are problems in Org-Agenda my friend. And quite some confusion on what mailing list to use. Only one mailing list is mentioned, then people start sending you here and there. At other times, things are done in a piecemeal process. Elisp can be challenging and you will not learning in school. There needs to be some intermediate level manual if you want people to get good enough to help the project. I am quite sure that some people do spend a long time testing the code. > Cheers, > TRS-80 >
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Friday, December 11, 2020 at 4:59 AM > From: "TRS-80" > To: daniela-s...@gmx.it > Cc: "Kyle Meyer" , "Tom Gillespie" , > "Org-Mode mailing list" , "Emacs-orgmode" > > Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting > user options > > On 2020-11-29 17:08, daniela-s...@gmx.it wrote: > > > > Yes, there are problems with the documentation. I noticed recently > > that > > some guy criticised the manual, and so many got super defensive. You > > should > > give him a medal for telling you how things are. > > I guess in my mind, complaining about the manual, to a bunch of > volunteers and fellow users, is probably on the pretty unhelpful end of > the scale. > > Making constructive criticism is then slightly better, at least you are > not deriding (mostly volunteer) people's work and effort. Although not > by much, as this still does not require too much effort. > > However submitting a patch with an improvement to the documentation is > quite valuable. Pretty much on the opposite end of the scale in fact. > And thus, only this level of contribution "deserves a medal" as far as I > am concerned. > > I was not privy to particulars of conversation you mention, although I > have seen this sort of entitled attitude often enough in F/LOSS to have > somewhat of an idea of how it might have played out. > > Entitled users becoming demanding of things they expect (for free, no > less) is not just a drag, it's the cancer that slowly kills F/LOSS > projects. As eventually actually valuable contributors (maintainers, > devs, etc.) have had enough of it, get burnt out and leave the project. > I have seen it far too many times over the years. You work on it and get a lot of praise but have almost no tolerance for negative feedback. When you get project maintainers complaining about your attitude "Don't complain, I'm only volunteer. Bye Bye", something is screwed up. And now you want to start this all over again. Bye Bye. > So I imagine what you witnessed was a sort of natural defense mechanism, > protecting the overall health of the community and project by having a > strong reaction to such negative attitudes. > > Cheers, > TRS-80 >
Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> > From: "gyro funch" > > To: emacs-orgmode@gnu.org > > Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, > > overwriting user options > > If I'm not mistaken, all of the development is done by volunteers. > > > > Perhaps you could help resolve your issue instead of asking other > > people, who are likely already overworked, to shoulder the burden. Those overworked, to shoulder the burden people need not answer any issue. They are volunteers, so they need not answer. There will be those who may answer. Process I see there is: - please report the bug! You are welcome - user reports the bug - why you reported the bug here? Report somewhere else. - user asks where to report the bug and wonders why that routing - user does report the bug to other place - user is told not to ask other people While all that has deeper meanings for one set of people and one may understand it, there will be those pissed off who cannot understand what is happening. Please look at processes going on, analyze processes and what those processes are not well designed when we have Emacs with programming language to route users accordingly. In the end neither developers will get insights from users about potential bugs neither users will resolve the issue. Final question is if problem with org-agenda-files got resolved?
Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
* Tim Cross [2020-11-30 04:00]:
> The issue at this point wasn't about whether there is a problem with how
> org manages org-agenda-files or even the acknowledged weakness in the
> documentation which needs a patch. The issue here is about attitude and
> being respectful.
I think it would be best if the actual technical issue would be put
attention to and get solved as that is where problem comes from.
Every person reporting Emacs bug is very important. Finally it is
contributor to Emacs.
People use Emacs to handle their life problems. When user stumbles
upon an obstacle that is life related obstacle. It has practical
meanings related to life that are difficult to realize on distance
through a thin medium of email communication.
When the true obstacle is not handled it is quite logical that it may
lead to frustrations. It may not, but "it may" is enough and one shall
try to handle the obstacle and not put attention on frustration that
derives from the obstacle, as where one puts attention that is what
one gets.
Person is not first being surprised that M-x report-emacs-bug is not
handled as Emacs Bug. I think that alone is definitely a bug, and we
recently discussed it, and here we are again.
Good read for participants:
GNU Kind Communications Guidelines
==
Author: Richard Stallman
Type: WWW
Hyperlink: https://www.gnu.org/philosophy/kind-communication.html
Instead of using programming to automate WHERE the bug related to
org-mode should be routed there is lack of consensus and now we have:
,
| M-x report-emacs-bug
|
| M-x org-submit-bug-report
|
| M-x TeX-submit-bug-report
|
| M-x lm-report-bug
`
and so on. Emacs is already taking user's data and inserting into the
buffer to send email. Why it does not ask user to which part the bug
relates?
,
| - Do you wish to designate mode to which this bug relates?
| - Org mode
| - TeX mode
| - General editing
`
After that question the email can have a tag [org-mode] and upon the
tag the maildrop or procmail or other email filter could forward the
bug to specific mailing list. Simple really. Standard GNU/Linux and
Unix handling of emails.
Various mailing lists arrive to my IMAP by being sorted first by the
`maildrop' command line tool.
Examples:
,
| if ((/^To:.*emacs\-devel/))
| {
|to "./Maildir/.emacs-devel/."
| }
`
If email is written to `emacs-devel' please sort it in this folder. In
this fashion I can make a filter:
- if email has a tag: [org-mode] please send it to THIS-EMAIL-ADDRESS
Then emacs-report-bug could rank the user among beginner, intermediate
and advance.
Then we have the contradiction in description:
Is the Org mode part of Emacs? One gets it with Emacs so it is part of
Emacs.
Then somebody may say it is part of Emacs but somebody will tell it is
not part of Emacs.
Without listening I can observe that Org is part of Emacs and it says
so in the org.el and what is written is what is presented to users and
one need not bring these doubts onto user about facts that are clearly
there. Those are issues to be discussed beyond users' bugs.
I look at those things from a tolerant view point and that issues
reported shall better be solved in welcoming manner.
Fact is that Org is part of GNU Emacs.
,
| ;;; org.el --- Outline-based notes management and organizer -*-
lexical-binding: t; -*-
|
| ;; Carstens outline-mode for keeping track of everything.
| ;; Copyright (C) 2004-2020 Free Software Foundation, Inc.
|
| ;; Version: 9.4
|
| ;; This file is part of GNU Emacs.
`
Another ways but mail filtering ways of handling bugs that should be
forwarded to org mailing list can be very simple:
- let us discuss that it is fine to forward such issues to Org mailing
list. Issue may arrive to help-gnu-emacs mailing list and could be
copied to org mailing list as well by some of participants. Is this
alright to do?
- people who are subscribed to emacs bugs mailing list could simply
forward it to mailing list. In Mutt email reader that is very
simple, I can or could just bounce the email or forward email to
another email address and rmail and other email readers have same
functions. Easy peasy.
- some people from Org mailing list may get subscribed to bug tracker
and review emails there, when they answer the bug they may include
org mailing list.
- let us work cooperative and in welcoming manner and without
introduction of doubts
It is that simple.
Side reference from November 2020 that shows that it is legitimate to
report Org issues to Emacs bug mailing list, finally Org is part of
Emacs:
- Org issue does get discussed on Emacs bug mailing list:
https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-11/msg01832.html
- person reports Org issue to Emacs bug mailing list:
https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-11/msg01672.html
- another Org issue handled on Emacs bug mailing list:
Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
On Mon, Nov 30, 2020 at 01:05:15AM +0100, Christopher Dimech wrote: [...] > Please follow the commentary in savannah-hackers > https://lists.nongnu.org/archive/html/savannah-hackers/2020-11/msg00085.html > > I agree fully with Falcon's description. Just from a sideline: "Falcon's description" pointing to a huge post with many aspects, some related to here, and some not, doesn't seem helpful to focus here. Could you state your point (as far as it is related to the current thread's topic) in a couple of sentences? Thanks - t signature.asc Description: Digital signature
Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Monday, November 30, 2020 at 3:50 AM > From: "Tim Cross" > To: "Christopher Dimech" > Cc: emacs-orgmode@gnu.org > Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, > overwriting user options > > > Christopher Dimech writes: > > >> Sent: Monday, November 30, 2020 at 1:59 AM > >> From: "Tim Cross" > >> To: "Christopher Dimech" > >> Cc: emacs-orgmode@gnu.org > >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, > >> overwriting user options > >> > >> > >> Christopher Dimech writes: > >> > >> >> Sent: Monday, November 30, 2020 at 1:09 AM > >> >> From: "Tim Cross" > >> >> To: emacs-orgmode@gnu.org > >> >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files > >> >> variable, overwriting user options > >> >> > >> >> > >> >> daniela-s...@gmx.it writes: > >> >> > >> >> >> Sent: Sunday, November 29, 2020 at 10:51 PM > >> >> >> From: "Gyro Funch" > >> >> >> To: daniela-s...@gmx.it, "Kyle Meyer" > >> >> >> Cc: emacs-orgmode@gnu.org > >> >> >> Subject: Re[2]: bug#44935: Emacs inserts hardwired org-agenda-files > >> >> >> variable, overwriting user options > >> >> >> > >> >> >> > > >> >> >> >> Sent: Sunday, November 29, 2020 at 10:20 PM > >> >> >> >> From: "Kyle Meyer" > >> >> >> >> To: daniela-s...@gmx.it > >> >> >> >> Cc: "gyro funch" , emacs-orgmode@gnu.org > >> >> >> >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files > >> >> >> >> variable, overwriting user options > >> >> >> >> > >> >> >> >>daniela-s...@gmx.it writes: > >> >> >> >> > >> >> >> >> >> From: "gyro funch" > >> >> >> >> [...] > >> >> >> >> >> If I'm not mistaken, all of the development is done by > >> >> >> >> volunteers. > >> >> >> >> >> > >> >> >> >> >> Perhaps you could help resolve your issue instead of asking > >> >> >> >> other > >> >> >> >> >> people, who are likely already overworked, to shoulder the > >> >> >> >> burden. > >> >> >> >> > > >> >> >> >> > Is there a mailing list for abuse? If I want abuse I shall > >> >> >> >> ask for it. > >> >> >> >> > Loser! > >> >> >> > > >> >> >> >> I don't see anything that gyro said as abuse. Name calling, on > >> >> >> >> the > >> >> >> >> other hand, has no place on this list. > >> >> >> > > >> >> >> >One asks for help, and people tell you to go fix it yourself. If > >> >> >> >there > >> >> >> >is any disrespect, you bring it upon yourselves. And now you start. > >> >> >> >Another Gnu Goon. > >> >> >> > >> >> >> I have found that people on this list are extremely friendly, > >> >> >> courteous, > >> >> >> and helpful. > >> >> >> I suggest that you look back at the way you asked for/demanded help > >> >> >> and > >> >> >> the various responses you gave in this thread. > >> >> >> Taking on an attitude of entitlement and showing a lack of respect > >> >> >> for > >> >> >> others, their perspectives, and efforts may not be the best way to > >> >> >> get > >> >> >> help. > >> >> > > >> >> > Nonsense. > >> >> > >> >> Not nonsense at all. You responses have become rude and unhelpful. I can > >> >> understand how you may be frustrated by the bug reporting situation, but > >> >> your response to that frustration has been to complain and be critical > >> >> in &
Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
Christopher Dimech writes: >> Sent: Monday, November 30, 2020 at 1:59 AM >> From: "Tim Cross" >> To: "Christopher Dimech" >> Cc: emacs-orgmode@gnu.org >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, >> overwriting user options >> >> >> Christopher Dimech writes: >> >> >> Sent: Monday, November 30, 2020 at 1:09 AM >> >> From: "Tim Cross" >> >> To: emacs-orgmode@gnu.org >> >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files >> >> variable, overwriting user options >> >> >> >> >> >> daniela-s...@gmx.it writes: >> >> >> >> >> Sent: Sunday, November 29, 2020 at 10:51 PM >> >> >> From: "Gyro Funch" >> >> >> To: daniela-s...@gmx.it, "Kyle Meyer" >> >> >> Cc: emacs-orgmode@gnu.org >> >> >> Subject: Re[2]: bug#44935: Emacs inserts hardwired org-agenda-files >> >> >> variable, overwriting user options >> >> >> >> >> >> > >> >> >> >> Sent: Sunday, November 29, 2020 at 10:20 PM >> >> >> >> From: "Kyle Meyer" >> >> >> >> To: daniela-s...@gmx.it >> >> >> >> Cc: "gyro funch" , emacs-orgmode@gnu.org >> >> >> >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files >> >> >> >> variable, overwriting user options >> >> >> >> >> >> >> >>daniela-s...@gmx.it writes: >> >> >> >> >> >> >> >> >> From: "gyro funch" >> >> >> >> [...] >> >> >> >> >> If I'm not mistaken, all of the development is done by >> >> >> >> volunteers. >> >> >> >> >> >> >> >> >> >> Perhaps you could help resolve your issue instead of asking >> >> >> >> other >> >> >> >> >> people, who are likely already overworked, to shoulder the >> >> >> >> burden. >> >> >> >> > >> >> >> >> > Is there a mailing list for abuse? If I want abuse I shall ask >> >> >> >> for it. >> >> >> >> > Loser! >> >> >> > >> >> >> >> I don't see anything that gyro said as abuse. Name calling, on the >> >> >> >> other hand, has no place on this list. >> >> >> > >> >> >> >One asks for help, and people tell you to go fix it yourself. If >> >> >> >there >> >> >> >is any disrespect, you bring it upon yourselves. And now you start. >> >> >> >Another Gnu Goon. >> >> >> >> >> >> I have found that people on this list are extremely friendly, >> >> >> courteous, >> >> >> and helpful. >> >> >> I suggest that you look back at the way you asked for/demanded help and >> >> >> the various responses you gave in this thread. >> >> >> Taking on an attitude of entitlement and showing a lack of respect for >> >> >> others, their perspectives, and efforts may not be the best way to get >> >> >> help. >> >> > >> >> > Nonsense. >> >> >> >> Not nonsense at all. You responses have become rude and unhelpful. I can >> >> understand how you may be frustrated by the bug reporting situation, but >> >> your response to that frustration has been to complain and be critical in >> >> a very non-constructive manner. You have now descended into name calling >> >> and personal abuse. You are beginning to exhibit behaviour >> >> which is not welcome here and which will result in people ignoring your >> >> posts. Multiple people have now pointed this out, which should make you >> >> stop and think rather than become emotional and respond defensively. >> >> >> >> the ball is now in your court. How you respond will influence how others >> >> respond to your requests and suggestions going forward. >> > >> > Please be aware that it was pointed out that one can configure >> > org-agenda-skip-unavailable-files to a non-nil value if she wants >> >
Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Monday, November 30, 2020 at 1:59 AM > From: "Tim Cross" > To: "Christopher Dimech" > Cc: emacs-orgmode@gnu.org > Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, > overwriting user options > > > Christopher Dimech writes: > > >> Sent: Monday, November 30, 2020 at 1:09 AM > >> From: "Tim Cross" > >> To: emacs-orgmode@gnu.org > >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, > >> overwriting user options > >> > >> > >> daniela-s...@gmx.it writes: > >> > >> >> Sent: Sunday, November 29, 2020 at 10:51 PM > >> >> From: "Gyro Funch" > >> >> To: daniela-s...@gmx.it, "Kyle Meyer" > >> >> Cc: emacs-orgmode@gnu.org > >> >> Subject: Re[2]: bug#44935: Emacs inserts hardwired org-agenda-files > >> >> variable, overwriting user options > >> >> > >> >> > > >> >> >> Sent: Sunday, November 29, 2020 at 10:20 PM > >> >> >> From: "Kyle Meyer" > >> >> >> To: daniela-s...@gmx.it > >> >> >> Cc: "gyro funch" , emacs-orgmode@gnu.org > >> >> >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files > >> >> >> variable, overwriting user options > >> >> >> > >> >> >>daniela-s...@gmx.it writes: > >> >> >> > >> >> >> >> From: "gyro funch" > >> >> >> [...] > >> >> >> >> If I'm not mistaken, all of the development is done by > >> >> >> volunteers. > >> >> >> >> > >> >> >> >> Perhaps you could help resolve your issue instead of asking other > >> >> >> >> people, who are likely already overworked, to shoulder the > >> >> >> burden. > >> >> >> > > >> >> >> > Is there a mailing list for abuse? If I want abuse I shall ask > >> >> >> for it. > >> >> >> > Loser! > >> >> > > >> >> >> I don't see anything that gyro said as abuse. Name calling, on the > >> >> >> other hand, has no place on this list. > >> >> > > >> >> >One asks for help, and people tell you to go fix it yourself. If there > >> >> >is any disrespect, you bring it upon yourselves. And now you start. > >> >> >Another Gnu Goon. > >> >> > >> >> I have found that people on this list are extremely friendly, courteous, > >> >> and helpful. > >> >> I suggest that you look back at the way you asked for/demanded help and > >> >> the various responses you gave in this thread. > >> >> Taking on an attitude of entitlement and showing a lack of respect for > >> >> others, their perspectives, and efforts may not be the best way to get > >> >> help. > >> > > >> > Nonsense. > >> > >> Not nonsense at all. You responses have become rude and unhelpful. I can > >> understand how you may be frustrated by the bug reporting situation, but > >> your response to that frustration has been to complain and be critical in > >> a very non-constructive manner. You have now descended into name calling > >> and personal abuse. You are beginning to exhibit behaviour > >> which is not welcome here and which will result in people ignoring your > >> posts. Multiple people have now pointed this out, which should make you > >> stop and think rather than become emotional and respond defensively. > >> > >> the ball is now in your court. How you respond will influence how others > >> respond to your requests and suggestions going forward. > > > > Please be aware that it was pointed out that one can configure > > org-agenda-skip-unavailable-files to a non-nil value if she wants > > non-existing/unreadable files to be skipped. > > > > But that option isn't mentioned in the manual or the docstring of the > > org-agenda-files option. The problem is known and has been a source of > > great > > frustration, that's why it was introduced. > > > > Daniela is quite right. If multiple people don't want to help her, that's > > fine, many others will. > > > > The issue at this poin
Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
daniela-s...@gmx.it writes: > Sent: Monday, November 30, 2020 at 1:09 AM >> From: "Tim Cross" >> To: emacs-orgmode@gnu.org >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, >> overwriting user options >> >> >> daniela-s...@gmx.it writes: >> >> >> Sent: Sunday, November 29, 2020 at 10:51 PM >> >> From: "Gyro Funch" >> >> To: daniela-s...@gmx.it, "Kyle Meyer" >> >> Cc: emacs-orgmode@gnu.org >> >> Subject: Re[2]: bug#44935: Emacs inserts hardwired org-agenda-files >> >> variable, overwriting user options >> >> >> >> > >> >> >> Sent: Sunday, November 29, 2020 at 10:20 PM >> >> >> From: "Kyle Meyer" >> >> >> To: daniela-s...@gmx.it >> >> >> Cc: "gyro funch" , emacs-orgmode@gnu.org >> >> >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files >> >> >> variable, overwriting user options >> >> >> >> >> >>daniela-s...@gmx.it writes: >> >> >> >> >> >> >> From: "gyro funch" >> >> >> [...] >> >> >> >> If I'm not mistaken, all of the development is done by volunteers. >> >> >> >> >> >> >> >> Perhaps you could help resolve your issue instead of asking other >> >> >> >> people, who are likely already overworked, to shoulder the burden. >> >> >> > >> >> >> > Is there a mailing list for abuse? If I want abuse I shall ask for >> >> >> it. >> >> >> > Loser! >> >> > >> >> >> I don't see anything that gyro said as abuse. Name calling, on the >> >> >> other hand, has no place on this list. >> >> > >> >> >One asks for help, and people tell you to go fix it yourself. If there >> >> >is any disrespect, you bring it upon yourselves. And now you start. >> >> >Another Gnu Goon. >> >> >> >> I have found that people on this list are extremely friendly, courteous, >> >> and helpful. >> >> I suggest that you look back at the way you asked for/demanded help and >> >> the various responses you gave in this thread. >> >> Taking on an attitude of entitlement and showing a lack of respect for >> >> others, their perspectives, and efforts may not be the best way to get >> >> help. >> > >> > Nonsense. >> >> Not nonsense at all. You responses have become rude and unhelpful. I can >> understand how you may be frustrated by the bug reporting situation, but >> your response to that frustration has been to complain and be critical in >> a very non-constructive manner. You have now descended into name calling >> and personal abuse. You are beginning to exhibit behaviour >> which is not welcome here and which will result in people ignoring your >> posts. Multiple people have now pointed this out, which should make you >> stop and think rather than become emotional and respond defensively. >> >> the ball is now in your court. How you respond will influence how others >> respond to your requests and suggestions going forward. > > Look. First I was an an emacs mailing list, then was told that it was not > the right place. Then was directed to sent it here, etc etc. Then all the > talk about being volunteers and only do things when they like. WTF! > Even though it might not seem like it, many on this list, including me, understand your frustration. This is not the first time people have expressed frustration with how bug reports are managed on the list. However, what you are likely not ware of are many of the complicating factors involved which have made it difficult to implement a better solution. To understand that, you really need to look at the many threads on both the org and emacs development list where the issue of bug reporting has been discussed. You might say you don't care about all of that and just want to be able to easily report an issue and know it reaches the right people. That is fair enough. You may even have a need to express that frustration, which is also fair enough. However, attributing that failure to laziness, incompetence or lack of interest in doing something is not. Name calling and personal abuse is unacceptable regardless of the situation or level of frustration. Once you have expressed frustration about something, there is little gained by repetition. At the end of the day, it is how it is and if we cannot do something about it, such as providing a patch or improve the documentation or define a new process and work towards getting it implemented, we either have to accept it or walk away. -- Tim Cross
Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
Christopher Dimech writes: >> Sent: Monday, November 30, 2020 at 1:09 AM >> From: "Tim Cross" >> To: emacs-orgmode@gnu.org >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, >> overwriting user options >> >> >> daniela-s...@gmx.it writes: >> >> >> Sent: Sunday, November 29, 2020 at 10:51 PM >> >> From: "Gyro Funch" >> >> To: daniela-s...@gmx.it, "Kyle Meyer" >> >> Cc: emacs-orgmode@gnu.org >> >> Subject: Re[2]: bug#44935: Emacs inserts hardwired org-agenda-files >> >> variable, overwriting user options >> >> >> >> > >> >> >> Sent: Sunday, November 29, 2020 at 10:20 PM >> >> >> From: "Kyle Meyer" >> >> >> To: daniela-s...@gmx.it >> >> >> Cc: "gyro funch" , emacs-orgmode@gnu.org >> >> >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files >> >> >> variable, overwriting user options >> >> >> >> >> >>daniela-s...@gmx.it writes: >> >> >> >> >> >> >> From: "gyro funch" >> >> >> [...] >> >> >> >> If I'm not mistaken, all of the development is done by volunteers. >> >> >> >> >> >> >> >> Perhaps you could help resolve your issue instead of asking other >> >> >> >> people, who are likely already overworked, to shoulder the burden. >> >> >> > >> >> >> > Is there a mailing list for abuse? If I want abuse I shall ask for >> >> >> it. >> >> >> > Loser! >> >> > >> >> >> I don't see anything that gyro said as abuse. Name calling, on the >> >> >> other hand, has no place on this list. >> >> > >> >> >One asks for help, and people tell you to go fix it yourself. If there >> >> >is any disrespect, you bring it upon yourselves. And now you start. >> >> >Another Gnu Goon. >> >> >> >> I have found that people on this list are extremely friendly, courteous, >> >> and helpful. >> >> I suggest that you look back at the way you asked for/demanded help and >> >> the various responses you gave in this thread. >> >> Taking on an attitude of entitlement and showing a lack of respect for >> >> others, their perspectives, and efforts may not be the best way to get >> >> help. >> > >> > Nonsense. >> >> Not nonsense at all. You responses have become rude and unhelpful. I can >> understand how you may be frustrated by the bug reporting situation, but >> your response to that frustration has been to complain and be critical in >> a very non-constructive manner. You have now descended into name calling >> and personal abuse. You are beginning to exhibit behaviour >> which is not welcome here and which will result in people ignoring your >> posts. Multiple people have now pointed this out, which should make you >> stop and think rather than become emotional and respond defensively. >> >> the ball is now in your court. How you respond will influence how others >> respond to your requests and suggestions going forward. > > Please be aware that it was pointed out that one can configure > org-agenda-skip-unavailable-files to a non-nil value if she wants > non-existing/unreadable files to be skipped. > > But that option isn't mentioned in the manual or the docstring of the > org-agenda-files option. The problem is known and has been a source of great > frustration, that's why it was introduced. > > Daniela is quite right. If multiple people don't want to help her, that's > fine, many others will. > The issue at this point wasn't about whether there is a problem with how org manages org-agenda-files or even the acknowledged weakness in the documentation which needs a patch. The issue here is about attitude and being respectful. We can disagree on things. Opposing views are a good thing provided the expression of these opposing views is done with respect. This means no personal attacks, no calling names, no personal abuse. We all have different levels of sensitivity and some have thicker skin than others. However, once multiple people express the opinion that an attitude is not appropriate for the list, the responsibility is with the originator to consider that feedback and either adjust to meet community expectations, leave the community or continue without change and accept whatever consequences (if any) the list decides is appropriate. -- Tim Cross
Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
Sent: Monday, November 30, 2020 at 1:09 AM > From: "Tim Cross" > To: emacs-orgmode@gnu.org > Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, > overwriting user options > > > daniela-s...@gmx.it writes: > > >> Sent: Sunday, November 29, 2020 at 10:51 PM > >> From: "Gyro Funch" > >> To: daniela-s...@gmx.it, "Kyle Meyer" > >> Cc: emacs-orgmode@gnu.org > >> Subject: Re[2]: bug#44935: Emacs inserts hardwired org-agenda-files > >> variable, overwriting user options > >> > >> > > >> >> Sent: Sunday, November 29, 2020 at 10:20 PM > >> >> From: "Kyle Meyer" > >> >> To: daniela-s...@gmx.it > >> >> Cc: "gyro funch" , emacs-orgmode@gnu.org > >> >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files > >> >> variable, overwriting user options > >> >> > >> >>daniela-s...@gmx.it writes: > >> >> > >> >> >> From: "gyro funch" > >> >> [...] > >> >> >> If I'm not mistaken, all of the development is done by volunteers. > >> >> >> > >> >> >> Perhaps you could help resolve your issue instead of asking other > >> >> >> people, who are likely already overworked, to shoulder the burden. > >> >> > > >> >> > Is there a mailing list for abuse? If I want abuse I shall ask for > >> >> it. > >> >> > Loser! > >> > > >> >> I don't see anything that gyro said as abuse. Name calling, on the > >> >> other hand, has no place on this list. > >> > > >> >One asks for help, and people tell you to go fix it yourself. If there > >> >is any disrespect, you bring it upon yourselves. And now you start. > >> >Another Gnu Goon. > >> > >> I have found that people on this list are extremely friendly, courteous, > >> and helpful. > >> I suggest that you look back at the way you asked for/demanded help and > >> the various responses you gave in this thread. > >> Taking on an attitude of entitlement and showing a lack of respect for > >> others, their perspectives, and efforts may not be the best way to get > >> help. > > > > Nonsense. > > Not nonsense at all. You responses have become rude and unhelpful. I can > understand how you may be frustrated by the bug reporting situation, but > your response to that frustration has been to complain and be critical in > a very non-constructive manner. You have now descended into name calling > and personal abuse. You are beginning to exhibit behaviour > which is not welcome here and which will result in people ignoring your > posts. Multiple people have now pointed this out, which should make you > stop and think rather than become emotional and respond defensively. > > the ball is now in your court. How you respond will influence how others > respond to your requests and suggestions going forward. Look. First I was an an emacs mailing list, then was told that it was not the right place. Then was directed to sent it here, etc etc. Then all the talk about being volunteers and only do things when they like. WTF! > -- > Tim Cross > >
Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Monday, November 30, 2020 at 1:09 AM > From: "Tim Cross" > To: emacs-orgmode@gnu.org > Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, > overwriting user options > > > daniela-s...@gmx.it writes: > > >> Sent: Sunday, November 29, 2020 at 10:51 PM > >> From: "Gyro Funch" > >> To: daniela-s...@gmx.it, "Kyle Meyer" > >> Cc: emacs-orgmode@gnu.org > >> Subject: Re[2]: bug#44935: Emacs inserts hardwired org-agenda-files > >> variable, overwriting user options > >> > >> > > >> >> Sent: Sunday, November 29, 2020 at 10:20 PM > >> >> From: "Kyle Meyer" > >> >> To: daniela-s...@gmx.it > >> >> Cc: "gyro funch" , emacs-orgmode@gnu.org > >> >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files > >> >> variable, overwriting user options > >> >> > >> >>daniela-s...@gmx.it writes: > >> >> > >> >> >> From: "gyro funch" > >> >> [...] > >> >> >> If I'm not mistaken, all of the development is done by volunteers. > >> >> >> > >> >> >> Perhaps you could help resolve your issue instead of asking other > >> >> >> people, who are likely already overworked, to shoulder the burden. > >> >> > > >> >> > Is there a mailing list for abuse? If I want abuse I shall ask for > >> >> it. > >> >> > Loser! > >> > > >> >> I don't see anything that gyro said as abuse. Name calling, on the > >> >> other hand, has no place on this list. > >> > > >> >One asks for help, and people tell you to go fix it yourself. If there > >> >is any disrespect, you bring it upon yourselves. And now you start. > >> >Another Gnu Goon. > >> > >> I have found that people on this list are extremely friendly, courteous, > >> and helpful. > >> I suggest that you look back at the way you asked for/demanded help and > >> the various responses you gave in this thread. > >> Taking on an attitude of entitlement and showing a lack of respect for > >> others, their perspectives, and efforts may not be the best way to get > >> help. > > > > Nonsense. > > Not nonsense at all. You responses have become rude and unhelpful. I can > understand how you may be frustrated by the bug reporting situation, but > your response to that frustration has been to complain and be critical in > a very non-constructive manner. You have now descended into name calling > and personal abuse. You are beginning to exhibit behaviour > which is not welcome here and which will result in people ignoring your > posts. Multiple people have now pointed this out, which should make you > stop and think rather than become emotional and respond defensively. > > the ball is now in your court. How you respond will influence how others > respond to your requests and suggestions going forward. Please be aware that it was pointed out that one can configure org-agenda-skip-unavailable-files to a non-nil value if she wants non-existing/unreadable files to be skipped. But that option isn't mentioned in the manual or the docstring of the org-agenda-files option. The problem is known and has been a source of great frustration, that's why it was introduced. Daniela is quite right. If multiple people don't want to help her, that's fine, many others will. - Christopher Dimech General Administrator - Naiad Informatics - GNU Project (Geocomputation) - Geophysical Simulation - Geological Subsurface Mapping - Disaster Preparedness and Mitigation - Natural Resource Exploration and Production - Free Software Advocacy > -- > Tim Cross > >
Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Monday, November 30, 2020 at 12:51 AM > From: "Tim Cross" > To: emacs-orgmode@gnu.org > Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, > overwriting user options > > > daniela-s...@gmx.it writes: > > >> Sent: Sunday, November 29, 2020 at 6:22 PM > >> From: "Jean Louis" > >> To: daniela-s...@gmx.it > >> Cc: "Eli Zaretskii" , 44...@debbugs.gnu.org > >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, > >> overwriting user options > >> > >> * daniela-s...@gmx.it [2020-11-29 20:02]: > >> > Correct, everything tells you it is part of Emacs. Then one sends a > >> > report and people > >> > start sending in in a long winded road to find the appropriate > >> > channel. > >> > >> We can consider those features of reporting bugs still in > >> development. I never knew since recently that there are various > >> reporting bug functions. You can discover it easier by using > >> completion such as ivy package. > > > > Still in development? How much thinking do people have to do > > for this. I can make 34 mailing lists in a few hours! > > > > if your so sure on how it should be done and how easy it is to do it, > then step up and do it. This is open source - there is nobody here paid > to do this, there is nobody here who has full responsibility. If there > is something you think is broken or not working as best as it could, > then it is up to you to step up and do something about it rather than > sniping from the sidelines about how it isn't good enough. Please follow the commentary in savannah-hackers https://lists.nongnu.org/archive/html/savannah-hackers/2020-11/msg00085.html I agree fully with Falcon's description. - Christopher Dimech General Administrator - Naiad Informatics - GNU Project (Geocomputation) - Geophysical Simulation - Geological Subsurface Mapping - Disaster Preparedness and Mitigation - Natural Resource Exploration and Production - Free Software Advocacy > Tim Cross > >
Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
daniela-s...@gmx.it writes: >> Sent: Sunday, November 29, 2020 at 10:51 PM >> From: "Gyro Funch" >> To: daniela-s...@gmx.it, "Kyle Meyer" >> Cc: emacs-orgmode@gnu.org >> Subject: Re[2]: bug#44935: Emacs inserts hardwired org-agenda-files >> variable, overwriting user options >> >> > >> >> Sent: Sunday, November 29, 2020 at 10:20 PM >> >> From: "Kyle Meyer" >> >> To: daniela-s...@gmx.it >> >> Cc: "gyro funch" , emacs-orgmode@gnu.org >> >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files >> >> variable, overwriting user options >> >> >> >>daniela-s...@gmx.it writes: >> >> >> >> >> From: "gyro funch" >> >> [...] >> >> >> If I'm not mistaken, all of the development is done by volunteers. >> >> >> >> >> >> Perhaps you could help resolve your issue instead of asking other >> >> >> people, who are likely already overworked, to shoulder the burden. >> >> > >> >> > Is there a mailing list for abuse? If I want abuse I shall ask for it. >> >> > Loser! >> > >> >> I don't see anything that gyro said as abuse. Name calling, on the >> >> other hand, has no place on this list. >> > >> >One asks for help, and people tell you to go fix it yourself. If there >> >is any disrespect, you bring it upon yourselves. And now you start. >> >Another Gnu Goon. >> >> I have found that people on this list are extremely friendly, courteous, >> and helpful. >> I suggest that you look back at the way you asked for/demanded help and >> the various responses you gave in this thread. >> Taking on an attitude of entitlement and showing a lack of respect for >> others, their perspectives, and efforts may not be the best way to get >> help. > > Nonsense. Not nonsense at all. You responses have become rude and unhelpful. I can understand how you may be frustrated by the bug reporting situation, but your response to that frustration has been to complain and be critical in a very non-constructive manner. You have now descended into name calling and personal abuse. You are beginning to exhibit behaviour which is not welcome here and which will result in people ignoring your posts. Multiple people have now pointed this out, which should make you stop and think rather than become emotional and respond defensively. the ball is now in your court. How you respond will influence how others respond to your requests and suggestions going forward. -- Tim Cross
Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
daniela-s...@gmx.it writes: >> Sent: Sunday, November 29, 2020 at 6:22 PM >> From: "Jean Louis" >> To: daniela-s...@gmx.it >> Cc: "Eli Zaretskii" , 44...@debbugs.gnu.org >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, >> overwriting user options >> >> * daniela-s...@gmx.it [2020-11-29 20:02]: >> > Correct, everything tells you it is part of Emacs. Then one sends a >> > report and people >> > start sending in in a long winded road to find the appropriate >> > channel. >> >> We can consider those features of reporting bugs still in >> development. I never knew since recently that there are various >> reporting bug functions. You can discover it easier by using >> completion such as ivy package. > > Still in development? How much thinking do people have to do > for this. I can make 34 mailing lists in a few hours! > if your so sure on how it should be done and how easy it is to do it, then step up and do it. This is open source - there is nobody here paid to do this, there is nobody here who has full responsibility. If there is something you think is broken or not working as best as it could, then it is up to you to step up and do something about it rather than sniping from the sidelines about how it isn't good enough. -- Tim Cross
Re: Re[2]: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Sunday, November 29, 2020 at 10:51 PM > From: "Gyro Funch" > To: daniela-s...@gmx.it, "Kyle Meyer" > Cc: emacs-orgmode@gnu.org > Subject: Re[2]: bug#44935: Emacs inserts hardwired org-agenda-files variable, > overwriting user options > > > > >> Sent: Sunday, November 29, 2020 at 10:20 PM > >> From: "Kyle Meyer" > >> To: daniela-s...@gmx.it > >> Cc: "gyro funch" , emacs-orgmode@gnu.org > >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files > >> variable, overwriting user options > >> > >>daniela-s...@gmx.it writes: > >> > >> >> From: "gyro funch" > >> [...] > >> >> If I'm not mistaken, all of the development is done by volunteers. > >> >> > >> >> Perhaps you could help resolve your issue instead of asking other > >> >> people, who are likely already overworked, to shoulder the burden. > >> > > >> > Is there a mailing list for abuse? If I want abuse I shall ask for it. > >> > Loser! > > > >> I don't see anything that gyro said as abuse. Name calling, on the > >> other hand, has no place on this list. > > > >One asks for help, and people tell you to go fix it yourself. If there > >is any disrespect, you bring it upon yourselves. And now you start. > >Another Gnu Goon. > > I have found that people on this list are extremely friendly, courteous, > and helpful. > I suggest that you look back at the way you asked for/demanded help and > the various responses you gave in this thread. > Taking on an attitude of entitlement and showing a lack of respect for > others, their perspectives, and efforts may not be the best way to get > help. Nonsense.
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Sunday, November 29, 2020 at 10:02 PM > From: "Kyle Meyer" > To: daniela-s...@gmx.it > Cc: "Tom Gillespie" , "Org-Mode mailing list" > > Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting > user options > > daniela-s...@gmx.it writes: > > >> From: "Tom Gillespie" > [...] > >> If you have that then your list will be retained. However Emacs will > >> probably continue to ask you to remove the missing file until some > >> file exists at that path. Not sure about the org agenda behavior for > >> missing files since I populate org-agenda-files by scanning folders > >> for existing org files and then having a blacklist to exclude files I > >> do not want. > > > > Yes it gives you hell in its demand to delete or abort, rather than > > ignoring the file. > > > > That's why I called the problem a bug. If you don't find the file, ignore > > it. > > If you want non-existing/unreadable files to be skipped, you can > configure org-agenda-skip-unavailable-files to a non-nil value. > > That option unfortunately isn't mentioned in the manual or the docstring > of the org-agenda-files option. If anyone is interested, a patch > improving the documentation would of course be appreciated. Yes, there are problems with the documentation. I noticed recently that some guy criticised the manual, and so many got super defensive. You should give him a medal for telling you how things are. Thanks for mentioning it. If it was written up, I would not have bothered anyone who typically flame up by work. We all got work to do, not only people at Gnu. After all, it is the FSF who continually campaigns in favour of free software and to use Gnu Tools. Bad responses to those asking for help - on a mailing list that emacs admin made - ends up destroying their good work. I only say this because I want you to succeed. Thanks again
Re[2]: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
Sent: Sunday, November 29, 2020 at 10:20 PM From: "Kyle Meyer" To: daniela-s...@gmx.it Cc: "gyro funch" , emacs-orgmode@gnu.org Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options daniela-s...@gmx.it writes: >> From: "gyro funch" [...] >> If I'm not mistaken, all of the development is done by volunteers. >> >> Perhaps you could help resolve your issue instead of asking other >> people, who are likely already overworked, to shoulder the burden. > > Is there a mailing list for abuse? If I want abuse I shall ask for it. > Loser! I don't see anything that gyro said as abuse. Name calling, on the other hand, has no place on this list. One asks for help, and people tell you to go fix it yourself. If there is any disrespect, you bring it upon yourselves. And now you start. Another Gnu Goon. I have found that people on this list are extremely friendly, courteous, and helpful. I suggest that you look back at the way you asked for/demanded help and the various responses you gave in this thread. Taking on an attitude of entitlement and showing a lack of respect for others, their perspectives, and efforts may not be the best way to get help.
Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Sunday, November 29, 2020 at 10:20 PM > From: "Kyle Meyer" > To: daniela-s...@gmx.it > Cc: "gyro funch" , emacs-orgmode@gnu.org > Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, > overwriting user options > > daniela-s...@gmx.it writes: > > >> From: "gyro funch" > [...] > >> If I'm not mistaken, all of the development is done by volunteers. > >> > >> Perhaps you could help resolve your issue instead of asking other > >> people, who are likely already overworked, to shoulder the burden. > > > > Is there a mailing list for abuse? If I want abuse I shall ask for it. > > Loser! > I don't see anything that gyro said as abuse. Name calling, on the > other hand, has no place on this list. One asks for help, and people tell you to go fix it yourself. If there is any disrespect, you bring it upon yourselves. And now you start. Another Gnu Goon.
Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
daniela-s...@gmx.it writes: >> From: "gyro funch" [...] >> If I'm not mistaken, all of the development is done by volunteers. >> >> Perhaps you could help resolve your issue instead of asking other >> people, who are likely already overworked, to shoulder the burden. > > Is there a mailing list for abuse? If I want abuse I shall ask for it. > Loser! I don't see anything that gyro said as abuse. Name calling, on the other hand, has no place on this list.
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
daniela-s...@gmx.it writes: >> From: "Tom Gillespie" [...] >> If you have that then your list will be retained. However Emacs will >> probably continue to ask you to remove the missing file until some >> file exists at that path. Not sure about the org agenda behavior for >> missing files since I populate org-agenda-files by scanning folders >> for existing org files and then having a blacklist to exclude files I >> do not want. > > Yes it gives you hell in its demand to delete or abort, rather than > ignoring the file. > > That's why I called the problem a bug. If you don't find the file, ignore it. If you want non-existing/unreadable files to be skipped, you can configure org-agenda-skip-unavailable-files to a non-nil value. That option unfortunately isn't mentioned in the manual or the docstring of the org-agenda-files option. If anyone is interested, a patch improving the documentation would of course be appreciated.
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Would this affect my own custom What I did when I migrated was to manually move the existing custom-set-variables and custom-set-faces from .emacs to the new custom-file (in my case ~/.emacs.d/custom.el), that way the old definitions will still be loaded. All new customizations will live in custom-file. I'm not sure what would happen if the old definitions were still in .emacs, regardless, a good time to make a backup of .emacs just in case. Best, Tom
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
* daniela-s...@gmx.it [2020-11-29 23:46]:
> Yes, but initially people and going to take my dani.el file and if
> they happen to delete their file, the whole setup will break down.
If you wish to relate the settings to a file, you may use file local
variables so when you give them dani.el that variable get defined
already in dani.el so that it is self-contained.
- M-x add-file-local-variable
- org-agenda-files
- '("~/Org/my-file") or expand your list
Then you get this on the end of file:
> Local Variables:
> org-agenda-files: '("~/Org/my-file")
> End:
That would work local file functions using `org-agenda-files' but it
will not work for for invokation outside of file.
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Sunday, November 29, 2020 at 9:15 PM
> From: "Jean Louis"
> To: daniela-s...@gmx.it
> Cc: "Org-Mode mailing list"
> Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting
> user options
>
> * daniela-s...@gmx.it [2020-11-29 21:54]:
> > I have identified a problem. Let a user set the files to be used for
> > Org Agenda in .emacs as follows, and consider the situation when the
> > file writing.rcl.org does not exist.
> >
> > (setq org-agenda-files
> >'("~/02histr/gadmin/writing.rcl.org"
> > "~/02histr/gadmin/meeting.rcl.org"
> > "~/02histr/gadmin/household.rcl.org"))
> >
> > Emacs demands that the file writing.rcl.org be removed from
> > org-agenda-files.
> > Then Emacs sabotages the user's settings by hardwiring org-agenda-files at
> > the
> > end of the file .emacs by inserting:
>
> I know that nugging. Look what I have found for variable
> `org-agenda-files' by using inspection with
> {C-h v RET org-agenda-files RET}
>
> ,
> | Documentation:
> | The files to be used for agenda display.
> |
> | If an entry is a directory, all files in that directory that are matched
> | by ‘org-agenda-file-regexp’ will be part of the file list.
> |
> | If the value of the variable is not a list but a single file name, then
> | the list of agenda files is actually stored and maintained in that file,
> | one agenda file per line. In this file paths can be given relative to
> | ‘org-directory’. Tilde expansion and environment variable substitution
> | are also made.
> |
> | Entries may be added to this list with ‘M-x org-agenda-file-to-front’
> | and removed with ‘M-x org-remove-file’.
> `
>
> Maybe you could try the approach to customize it not to be a list by
> single file name. Then in that file name you put files one by one.
Yes, but initially people and going to take my dani.el file and if they
happen to delete their file, the whole setup will break down.
Org should stop trying to delete the file from the list.
One can use
(file-expand-wildcards "~/02histr/gadmin/*.org")
Not everyone wants agenda to simply use all the files.
For instance I usually want agenda on just a few projects in the
directory. I have all the files exist now so do not get problems.
But, for those coping the file and trying to get it to work is fraught
with difficulties, with emacs trying to do weird things behind your
back.
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Sunday, November 29, 2020 at 9:07 PM > From: "Tom Gillespie" > To: daniela-s...@gmx.it > Cc: "Org-Mode mailing list" > Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting > user options > > Here is a workaround. Emacs klobbering settings in .emacs has caused > many issues for me in the past. The solution I finally came up with > was to ensure that custom variables are loaded before any of my > settings. Near the top of my .emacs (before any calls to setq) I have > the following: > > custom set variables > ;;; PLEASE MAKE YOUR WAY TO THE EXIT AND STAY OUT OF MY INIT FILE > ;;; These come first so that they will be overwritten by settings in packages > ;;; in order to prevent stale variables from klobbering new values > (setq custom-file (expand-file-name "custom.el" user-emacs-directory)) > (when (file-exists-p custom-file) > (load custom-file)) Would this affect my own custom (custom-set-variables) (custom-set-faces ;; '(font-lock-comment-face ((t (:foreground "#00" '(font-lock-keyword-face ((t (:foreground "#FFDD00"; yellow '(font-lock-type-face ((t (:foreground "#FFDD00") ; yellow > If you have that then your list will be retained. However Emacs will > probably continue to ask you to remove the missing file until some > file exists at that path. Not sure about the org agenda behavior for > missing files since I populate org-agenda-files by scanning folders > for existing org files and then having a blacklist to exclude files I > do not want. Yes it gives you hell in its demand to delete or abort, rather than ignoring the file. That's why I called the problem a bug. If you don't find the file, ignore it. > Best, > Tom >
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
* daniela-s...@gmx.it [2020-11-29 21:54]:
> I have identified a problem. Let a user set the files to be used for
> Org Agenda in .emacs as follows, and consider the situation when the
> file writing.rcl.org does not exist.
>
> (setq org-agenda-files
>'("~/02histr/gadmin/writing.rcl.org"
> "~/02histr/gadmin/meeting.rcl.org"
> "~/02histr/gadmin/household.rcl.org"))
>
> Emacs demands that the file writing.rcl.org be removed from org-agenda-files.
> Then Emacs sabotages the user's settings by hardwiring org-agenda-files at the
> end of the file .emacs by inserting:
I know that nugging. Look what I have found for variable
`org-agenda-files' by using inspection with
{C-h v RET org-agenda-files RET}
,
| Documentation:
| The files to be used for agenda display.
|
| If an entry is a directory, all files in that directory that are matched
| by ‘org-agenda-file-regexp’ will be part of the file list.
|
| If the value of the variable is not a list but a single file name, then
| the list of agenda files is actually stored and maintained in that file,
| one agenda file per line. In this file paths can be given relative to
| ‘org-directory’. Tilde expansion and environment variable substitution
| are also made.
|
| Entries may be added to this list with ‘M-x org-agenda-file-to-front’
| and removed with ‘M-x org-remove-file’.
`
Maybe you could try the approach to customize it not to be a list by
single file name. Then in that file name you put files one by one.
Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options
Here is a workaround. Emacs klobbering settings in .emacs has caused many issues for me in the past. The solution I finally came up with was to ensure that custom variables are loaded before any of my settings. Near the top of my .emacs (before any calls to setq) I have the following: custom set variables ;;; PLEASE MAKE YOUR WAY TO THE EXIT AND STAY OUT OF MY INIT FILE ;;; These come first so that they will be overwritten by settings in packages ;;; in order to prevent stale variables from klobbering new values (setq custom-file (expand-file-name "custom.el" user-emacs-directory)) (when (file-exists-p custom-file) (load custom-file)) If you have that then your list will be retained. However Emacs will probably continue to ask you to remove the missing file until some file exists at that path. Not sure about the org agenda behavior for missing files since I populate org-agenda-files by scanning folders for existing org files and then having a blacklist to exclude files I do not want. Best, Tom
Emacs inserts hardwired org-agenda-files variable, overwriting user options
I have identified a problem. Let a user set the files to be used for
Org Agenda in .emacs as follows, and consider the situation when the
file writing.rcl.org does not exist.
(setq org-agenda-files
'("~/02histr/gadmin/writing.rcl.org"
"~/02histr/gadmin/meeting.rcl.org"
"~/02histr/gadmin/household.rcl.org"))
Emacs demands that the file writing.rcl.org be removed from org-agenda-files.
Then Emacs sabotages the user's settings by hardwiring org-agenda-files at the
end of the file .emacs by inserting:
(custom-set-variables
;; custom-set-variables was added by Custom.
;; If you edit it by hand, you could mess it up, so be careful.
;; Your init file should contain only one such instance.
;; If there is more than one, they won't work right.
'(org-agenda-files
'("~/02histr/gadmin/meeting.rcl.org" "~/02histr/gadmin/household.rcl.org")))
This should be considered a bug.
Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Sunday, November 29, 2020 at 7:20 PM > From: "gyro funch" > To: emacs-orgmode@gnu.org > Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, > overwriting user options > > On 11/29/2020 11:08 AM, daniela-s...@gmx.it wrote: > > > > > >> Sent: Sunday, November 29, 2020 at 6:22 PM > >> From: "Jean Louis" > >> To: daniela-s...@gmx.it > >> Cc: "Eli Zaretskii" , 44...@debbugs.gnu.org > >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, > >> overwriting user options > >> > >> * daniela-s...@gmx.it [2020-11-29 20:02]: > >>> Correct, everything tells you it is part of Emacs. Then one sends a > >>> report and people > >>> start sending in in a long winded road to find the appropriate > >>> channel. > >> > >> We can consider those features of reporting bugs still in > >> development. I never knew since recently that there are various > >> reporting bug functions. You can discover it easier by using > >> completion such as ivy package. > > > > Still in development? How much thinking do people have to do > > for this. I can make 34 mailing lists in a few hours! > > > > > If I'm not mistaken, all of the development is done by volunteers. > > Perhaps you could help resolve your issue instead of asking other > people, who are likely already overworked, to shoulder the burden. Is there a mailing list for abuse? If I want abuse I shall ask for it. Loser! > -gyro > > >
Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
On 11/29/2020 11:08 AM, daniela-s...@gmx.it wrote: > > >> Sent: Sunday, November 29, 2020 at 6:22 PM >> From: "Jean Louis" >> To: daniela-s...@gmx.it >> Cc: "Eli Zaretskii" , 44...@debbugs.gnu.org >> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, >> overwriting user options >> >> * daniela-s...@gmx.it [2020-11-29 20:02]: >>> Correct, everything tells you it is part of Emacs. Then one sends a report >>> and people >>> start sending in in a long winded road to find the appropriate >>> channel. >> >> We can consider those features of reporting bugs still in >> development. I never knew since recently that there are various >> reporting bug functions. You can discover it easier by using >> completion such as ivy package. > > Still in development? How much thinking do people have to do > for this. I can make 34 mailing lists in a few hours! > If I'm not mistaken, all of the development is done by volunteers. Perhaps you could help resolve your issue instead of asking other people, who are likely already overworked, to shoulder the burden. -gyro
bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Sunday, November 29, 2020 at 6:22 PM > From: "Jean Louis" > To: daniela-s...@gmx.it > Cc: "Eli Zaretskii" , 44...@debbugs.gnu.org > Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, > overwriting user options > > * daniela-s...@gmx.it [2020-11-29 20:02]: > > Correct, everything tells you it is part of Emacs. Then one sends a report > > and people > > start sending in in a long winded road to find the appropriate > > channel. > > We can consider those features of reporting bugs still in > development. I never knew since recently that there are various > reporting bug functions. You can discover it easier by using > completion such as ivy package. Still in development? How much thinking do people have to do for this. I can make 34 mailing lists in a few hours! > There is: > > - report-calc-bug > - calc-report-bug > - c-submit-bug-report > - TeX-submit-bug-report > - org and Emacs maybe others > > > You look at "Emacs Asking for help" and "Emacs Reporting bugs" and you get > > only two things > > help-gnu-em...@gnu.org and bug-gnu-em...@gnu.org. Have been following > > discussions here > > and people herd together telling others they are doing everything > > backwards. And insisting > > everything is fine, makes serious people not happy at all. I do not want > > to hurt anyone, > > but there exists a wall between maintainers and users who basically use Gnu > > Tools to do > > something else. > > Users could assign to themselves specific level such as Beginner, > Intermediate, Advance and God. > > Beginner would be welcomed to submit bugs and kindly explained that > there exists specialized mailing list with more people able to help > it. > > Intermediate user would be simply told to go somewhere else. > > Advanced user would be anyway submitting patches and be active in > Emacs development, so there would be no problem with this level. > > God would never tell anything to anybody just as what is usual that > God does, I guess M-x something... > >
bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Sunday, November 29, 2020 at 6:39 PM > From: "Glenn Morris" > To: "Eli Zaretskii" > Cc: "Jean Louis" , 44...@debbugs.gnu.org, > daniela-s...@gmx.it > Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, > overwriting user options > > Eli Zaretskii wrote: > > > In rare cases that users become confused, we gently tell them to > > report to the Org developers. So now the maintainer starts telling users that they are rare cases for being confused. How can any woman stand this guy!!! Impossible. > I think it's better all round to just reassign the bug to the "org-mode" > package. > > > There is no manager here that forwards bugs. > > And yet, all the messages in this thread (save the first) are already on > the Org mailing list... >
bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Sunday, November 29, 2020 at 6:22 PM > From: "Jean Louis" > To: daniela-s...@gmx.it > Cc: "Eli Zaretskii" , 44...@debbugs.gnu.org > Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, > overwriting user options > > * daniela-s...@gmx.it [2020-11-29 20:02]: > > Correct, everything tells you it is part of Emacs. Then one sends a report > > and people > > start sending in in a long winded road to find the appropriate > > channel. > > We can consider those features of reporting bugs still in > development. I never knew since recently that there are various > reporting bug functions. You can discover it easier by using > completion such as ivy package. For new users? Will never happen. Put the mailing lists in the damn webpage, categorising them if necessary, but having them so anybody can see them. Furthermore, Org is so integrated in Emacs that a large part of the user community would not be in a position to determine whether it is a problem of Emacs or Org. > There is: > > - report-calc-bug > - calc-report-bug > - c-submit-bug-report > - TeX-submit-bug-report > - org and Emacs maybe others > > > You look at "Emacs Asking for help" and "Emacs Reporting bugs" and you get > > only two things > > help-gnu-em...@gnu.org and bug-gnu-em...@gnu.org. Have been following > > discussions here > > and people herd together telling others they are doing everything > > backwards. And insisting > > everything is fine, makes serious people not happy at all. I do not want > > to hurt anyone, > > but there exists a wall between maintainers and users who basically use Gnu > > Tools to do > > something else. > > Users could assign to themselves specific level such as Beginner, > Intermediate, Advance and God. God does not exist, get used to it! Look, if you put the various lists there, people would use them. Making things difficult only wakes people give Emacs the finger rather than concluding the developers are smart. Does this not bother Gnu Admins? > Beginner would be welcomed to submit bugs and kindly explained that > there exists specialized mailing list with more people able to help > it. > > Intermediate user would be simply told to go somewhere else. > > Advanced user would be anyway submitting patches and be active in > Emacs development, so there would be no problem with this level. > > God would never tell anything to anybody just as what is usual that > God does, I guess M-x something... As long as developers continue thinking they are gods. they will get no respect. Grow up and do it quick!
bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
Eli Zaretskii wrote: > In rare cases that users become confused, we gently tell them to > report to the Org developers. I think it's better all round to just reassign the bug to the "org-mode" package. > There is no manager here that forwards bugs. And yet, all the messages in this thread (save the first) are already on the Org mailing list...
bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Date: Sun, 29 Nov 2020 19:29:18 +0300 > From: Jean Louis > Cc: daniela-s...@gmx.it, 44...@debbugs.gnu.org > > * Eli Zaretskii [2020-11-29 18:08]: > > Shouldn't this be reported to the Org developers? > > We have discussed that Org is part of Emacs and users shall be at all > time welcome to report their bugs and pointers can be made how to > closer report to Org mailing list. It makes it confusing to users, and > is not logical. Org is part of Emacs so it is Emacs bug. In rare cases that users become confused, we gently tell them to report to the Org developers. Like in this case. It's not a big deal. Org is a separate project with a separate mailing list and issue tracker. We just _distroibute_ it as part of Emacs. That's not the same as being an integral part of the project. > I find this more mailing list manager job to properly forward bugs. There is no manager here that forwards bugs.
bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
Correct, everything tells you it is part of Emacs. Then one sends a report and
people
start sending in in a long winded road to find the appropriate channel.
You look at "Emacs Asking for help" and "Emacs Reporting bugs" and you get only
two things
help-gnu-em...@gnu.org and bug-gnu-em...@gnu.org. Have been following
discussions here
and people herd together telling others they are doing everything backwards.
And insisting
everything is fine, makes serious people not happy at all. I do not want to
hurt anyone,
but there exists a wall between maintainers and users who basically use Gnu
Tools to do
something else.
> Sent: Sunday, November 29, 2020 at 5:29 PM
> From: "Jean Louis"
> To: "Eli Zaretskii"
> Cc: daniela-s...@gmx.it, 44...@debbugs.gnu.org
> Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable,
> overwriting user options
>
> * Eli Zaretskii [2020-11-29 18:08]:
> > Shouldn't this be reported to the Org developers?
>
> We have discussed that Org is part of Emacs and users shall be at all
> time welcome to report their bugs and pointers can be made how to
> closer report to Org mailing list. It makes it confusing to users, and
> is not logical. Org is part of Emacs so it is Emacs bug.
>
> While there is pointer under Org menu how to report the bug, it is not
> as obvious as "Help - Report Bug". So sometimes Org bugs will arrive
> here.
>
> Org bugs should be then simply forwarded to mailing list or tagged as
> being Org so that they may be picked up by mailing list.
>
> I find this more mailing list manager job to properly forward bugs.
>
> For Org one can submit {M-x org-submit-bug-report RET}
>
> For this bug, I do not think it is bug. Isn't it for all variables
> like that that when they are customized by user on top of the init
> file that they customization during the session will overwrite the
> customizations set by user on top of the init file?
>
> If this is so how I think, then users who do not want Emacs to
> overwrite their customization in init file should not use the
> customize for those variables. Then the user's customization will take
> effect.
>
> I do not see differences here with org-agenda.
>
> Are there any?
>
bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Sunday, November 29, 2020 at 4:37 PM > From: "Basil L. Contovounesios" > To: daniela-s...@gmx.it > Cc: "Eli Zaretskii" , 44...@debbugs.gnu.org > Subject: Re: bug#44935: Emacs inserts hardwired org-agenda-files variable, > overwriting user options > > daniela-s...@gmx.it writes: > > >> Sent: Sunday, November 29, 2020 at 4:07 PM > >> From: "Eli Zaretskii" > >> To: daniela-s...@gmx.it > >> Cc: 44...@debbugs.gnu.org > >> Subject: bug#44935: Emacs inserts hardwired org-agenda-files variable, > >> overwriting user options > >> > >> Shouldn't this be reported to the Org developers? > > > > What mailing should I use to report it to Org Developers? > > M-x org-submit-bug-report RET, which mails emacs-orgmode@gnu.org. Thank you Basil. > See also (info "(org) Feedback") in Emacs, or > https://orgmode.org/manual/Feedback.html on the web, > and https://orgmode.org/community.html. > > Thanks, > > -- > Basil >
bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
daniela-s...@gmx.it writes: >> Sent: Sunday, November 29, 2020 at 4:07 PM >> From: "Eli Zaretskii" >> To: daniela-s...@gmx.it >> Cc: 44...@debbugs.gnu.org >> Subject: bug#44935: Emacs inserts hardwired org-agenda-files variable, >> overwriting user options >> >> Shouldn't this be reported to the Org developers? > > What mailing should I use to report it to Org Developers? M-x org-submit-bug-report RET, which mails emacs-orgmode@gnu.org. See also (info "(org) Feedback") in Emacs, or https://orgmode.org/manual/Feedback.html on the web, and https://orgmode.org/community.html. Thanks, -- Basil
bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> Sent: Sunday, November 29, 2020 at 4:07 PM
> From: "Eli Zaretskii"
> To: daniela-s...@gmx.it
> Cc: 44...@debbugs.gnu.org
> Subject: bug#44935: Emacs inserts hardwired org-agenda-files variable,
> overwriting user options
>
> > From: daniela-s...@gmx.it
> > Date: Sat, 28 Nov 2020 22:34:07 +0100
> >
> > I have identified a problem. Let a user set the files to be used for
> > Org Agenda in .emacs as follows, and consider the situation when the
> > file writing.rcl.org does not exist.
> >
> > (setq org-agenda-files
> >'("~/02histr/gadmin/writing.rcl.org"
> > "~/02histr/gadmin/meeting.rcl.org"
> > "~/02histr/gadmin/household.rcl.org"))
> >
> > Emacs demands that the file writing.rcl.org be removed from
> > org-agenda-files.
> > Then Emacs sabotages the user's settings by hardwiring org-agenda-files at
> > the
> > end of the file .emacs by inserting:
> >
> > (custom-set-variables
> > ;; custom-set-variables was added by Custom.
> > ;; If you edit it by hand, you could mess it up, so be careful.
> > ;; Your init file should contain only one such instance.
> > ;; If there is more than one, they won't work right.
> > '(org-agenda-files
> >'("~/02histr/gadmin/meeting.rcl.org"
> > "~/02histr/gadmin/household.rcl.org")))
> >
> > This should be considered a bug.
>
> Shouldn't this be reported to the Org developers?
What mailing should I use to report it to Org Developers?
>
>
bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
> From: daniela-s...@gmx.it
> Date: Sat, 28 Nov 2020 22:34:07 +0100
>
> I have identified a problem. Let a user set the files to be used for
> Org Agenda in .emacs as follows, and consider the situation when the
> file writing.rcl.org does not exist.
>
> (setq org-agenda-files
>'("~/02histr/gadmin/writing.rcl.org"
> "~/02histr/gadmin/meeting.rcl.org"
> "~/02histr/gadmin/household.rcl.org"))
>
> Emacs demands that the file writing.rcl.org be removed from org-agenda-files.
> Then Emacs sabotages the user's settings by hardwiring org-agenda-files at the
> end of the file .emacs by inserting:
>
> (custom-set-variables
> ;; custom-set-variables was added by Custom.
> ;; If you edit it by hand, you could mess it up, so be careful.
> ;; Your init file should contain only one such instance.
> ;; If there is more than one, they won't work right.
> '(org-agenda-files
>'("~/02histr/gadmin/meeting.rcl.org"
> "~/02histr/gadmin/household.rcl.org")))
>
> This should be considered a bug.
Shouldn't this be reported to the Org developers?
