Re: One vs many directories
Texas Cyberthal writes: > Agreed. I thought the Treefactor gif videos would be enough, but it's > clear that people's imagination cannot extrapolate the utility of > RIITR. That would be appreciated. I tried to read Treefactor docs at least 3 times and failed to understand its utility. Best, Ihor
Re: One vs many directories
Hi Jean, > For that I need video to understand. Agreed. I thought the Treefactor gif videos would be enough, but it's clear that people's imagination cannot extrapolate the utility of RIITR. I developed this skill long ago on the Windows app Brainstorm, and have forgotten how rare and unintuitive it is. This is the key missing concept preventing people from understanding and adopting Textmind, because Textmind is designed primarily to exploit this concept. So I plan to play AI Dungeon with Treefactor, using RIITR to make sense and fun of nonsense, and record it on YouTube with live audio commentary. Monkey see, monkey do. Then people will be able to do RIITR.
Re: Remembrance Agents
Thanks! I get an idea. Will try to use soon and let you know. Thanks for the links, very helpful. Question: when you say it uses emails, can it read any email database (I have old ones from Microsoft outlook both Mac and Windows)? What if you only use webmail, in which format shall you feed the RA? Thanks El dom, 29 nov 2020 a las 15:52, Eric S Fraga () escribió: > On Sunday, 29 Nov 2020 at 15:07, Gerardo Moro wrote: > > Has somebody installed it and tried it? It would be great to have a > > screen recording demo. > > I've used it on and off in the past, within the past 2 years most > recently. I populate the database it uses with both emails and org > files. While writing, it shows lines from documents that match in a > separate window (whose size can be customized). > > It does work but I find that I tend to forget about the remembrance > window most of the time so eventually I turn it off. I never seem to > have enough screen real estate to justify its use (despite having 38" > and 27" monitors side by side on my desk ;-)). > > There was a blog post early this year on this topic [1] which you might > find interesting. It talks mostly about recoll [2] which is not so much > a remembrance agent but a search tool > > HTH, > eric > > Footnotes: > [1] https://blog.jethro.dev/posts/remembrance_agents/ > > [2] https://www.lesbonscomptes.com/recoll/ > > -- > : Eric S Fraga via Emacs 28.0.50, Org release_9.4-143-g9a1549 >
Re: Missing line breaks in Beamer with alltt
Eric S Fraga writes: Hi there! > On Sunday, 29 Nov 2020 at 11:22, Jarmo Hurri wrote: >> Any ideas? > > First of all, the first frame works just fine for me. Line breaks are > preserved. Fascinating: it has to be something in my settings. I went through my init files and did not find anything relevant. Off to debug I go then. > When in doubt, export to LaTeX (C-e l b) and have a look at the LaTeX. > Also then run pdflatex yourself on that LaTeX code to see what errors > come up. I did that but did not notice anything weird in the latex code. Then again, if I export to regular latex, line breaks are preserved just fine. Therefore, this has to be related to some beamer settings (or my texlive version or something like that). Thanks for pointing me in the right direction. All the best, and stay safe. Jarmo
Re: difficulty extracting email address from property field containing gmail link
Ian Garmaise writes: > This is working well, except for the property used for the email address. > Unfortunately, I stored this as a gmail link. This makes it difficult to > extract the actual email address using org-collector as follows: > > #+BEGIN: propview :cols ((car (s-split " " ITEM)) EMAIL_ADDRESS) :id > "candidates" :match "testthis" :wrap example > > the result produced looks like this: > > | (car (s-split " " ITEM)) | EMAIL_ADDRESS >| > |--+-| > | "Ciara" | > [[https://mail.google.com/mail/?view=cm=1=ciaraxyz@gmail\.com]] > | > | "Duncan" | > [[https://mail.google.com/mail/?view=cm=1=duncanxyz@indeedemail\.com]] | > > I have looked at several methods that I found on the web to extract the > email address from the link in the property, but haven't yet found a > solution that I could get to work. Still building up my elisp skillset, > would appreciate suggestions. I've never used org-collector, but quickly trying to wire up a function to extract the email part of the text you show, I suspect some of the trouble you're having is that the value comes in as a vector because org-propview-collect processes it with org-babel-read. So perhaps something like this would get you on the right track: (require 'subr-x) (defun my/extract-email-from-link (value) (setq value (format "%S" value)) (when-let ((link (and (string-match org-link-bracket-re value) (org-link-unescape (match-string-no-properties 1 value) (thread-last link (replace-regexp-in-string (rx string-start (one-or-more not-newline) "to=" (group (one-or-more not-newline)) string-end) "\\1") (replace-regexp-in-string (rx "\\.") "." --8<---cut here---start->8--- #+BEGIN: propview :cols ((car (s-split " " ITEM)) (my/extract-email-from-link EMAIL_ADDRESS)) :id global | (car (s-split " " ITEM)) | (my/extract-email-from-link EMAIL_ADDRESS) | |--+| | "Ciara" | "ciara...@gmail.com" | | "Duncan" | "duncan...@indeedemail.com"| |--+| | || #+END: * Ciara :PROPERTIES: :EMAIL_ADDRESS: [[https://mail.google.com/mail/?view=cm=1=ciaraxyz@gmail\.com]] :END: * Duncan :PROPERTIES: :EMAIL_ADDRESS: [[https://mail.google.com/mail/?view=cm=1=duncanxyz@indeedemail\.com]] :END: --8<---cut here---end--->8---
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 > >> >> 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
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 >> > 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. > > Ok, let me deal with this. But please, can we be better ourselves. Am > sure she wanted to send a report so things get better for others. She > knew how to solve the problem by only putting a list of files that exist. > >
difficulty extracting email address from property field containing gmail link
I have created a kind of mini CRM using properties. Now I need to extract data from the entries to create a CSV file for use with an external email tool. I have used org-collector.el to extract tagged entries to a table, on which I then use orgtbl-to-csv to create the CSV file. This is working well, except for the property used for the email address. Unfortunately, I stored this as a gmail link. This makes it difficult to extract the actual email address using org-collector as follows: #+BEGIN: propview :cols ((car (s-split " " ITEM)) EMAIL_ADDRESS) :id "candidates" :match "testthis" :wrap example the result produced looks like this: | (car (s-split " " ITEM)) | EMAIL_ADDRESS | |--+-| | "Ciara" | [[ https://mail.google.com/mail/?view=cm=1=ciaraxyz@gmail\.com]] | | "Duncan" | [[ https://mail.google.com/mail/?view=cm=1=duncanxyz@indeedemail\.com]] | I have looked at several methods that I found on the web to extract the email address from the link in the property, but haven't yet found a solution that I could get to work. Still building up my elisp skillset, would appreciate suggestions. -- = Ian Garmaise Consultant Phorix Solutions Group ia...@phorixsol.com Toronto cell: 416.432.2251 NYC: 917.512.9535 https://www.linkedin.com/in/igarmaise/ http://www.PhorixSol.com
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 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. Ok, let me deal with this. But please, can we be better ourselves. Am sure she wanted to send a report so things get better for others. She knew how to solve the problem by only putting a list of files that exist. Furthermore, we are updating the manual on the available option that addressed her problem, a detail that was most likely obscure. Some good she has done. We are not doing the work
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: set source directory for org-attach
gyro funch writes: > I am probably missing something obvious, but is there a way to set the > default source directory for attachments? Not by default. I am using the following advice (requires helm and f.el): (defvar yant/org-attach-default-source "~/Downloads/" "Default directory to attach the files from.") (define-advice org-attach-attach (:around (oldfun files args) start-from-default-directory) "Look for new attachments from `yant/org-attach-default-source' directory instead of `default-directory'." (interactive (list (mapcar #'directory-file-name (helm-read-file-name "File to keep as an attachment:" :initial-input (or (progn (require 'dired-aux) (dired-dwim-target-directory)) (and yant/org-attach-default-source (f-slash yant/org-attach-default-source)) default-directory) :marked-candidates t)) current-prefix-arg nil)) (unless (listp files) (setq files (list files))) (mapc (lambda (file) (apply oldfun file args)) files)) Best, Ihor
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 > >
Org-GCal ?
Anyone using org-gcal? I just got it hooked up and am now trying to figure out how to fit it into my workflow. My issue is (CMIAW) that org-gcal seems to have a 1 to 1 connection between a Google calendar and an Org file (org-gcal-file-alist). I'm trying to figure out how to use this when my workflow is split across many Org files. Any ideas? -- David Masterson
Re: set source directory for org-attach
gyro funch writes: Hi, I'm relatively new to org-mode. I am tending to use org-attach quite a bit as part of my workflow. Instead of having to navigate from default-directory to the source of the attachment, it would be great if I could set a better default. I am probably missing something obvious, but is there a way to set the default source directory for attachments? Any advice is greatly appreciated. Thank you for your help.As far as I’m aware, the attachments need to be kept in a directory that is special and separate, because *every item* in the directory is treated as an attachment. If you set this to a different directory, and then from within your document tried to delete all attachments, then *everything* in the whole directory would be lost. Wouldn’t it? I think your particular workflow might possibly be better served by creating file: links to all those files instead of attaching them - that way, you can keep your files wherever you wish. It might be safer to treat the attachment function as being a way to manage finished permanent files that no longer need editing, to be included as-is. Section 4 of the Org-mode manual, titled “Hyperlinks”, shows everything about links including links to your own files. You may use Org-mode functions to help you create links, or you can type them out by hand - the result is exactly the same, as long as there are no typos of course. -- David Rogers
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: Adding Org Files to org-agenda-files
Jeremie Juste writes: > Hello, > >>> If you have *both* a settings in your emacs init file for >>> org-agenda-files using (setq org-agenda-files...) and you have a line in >>> your (custom ...) section, you should remove one of them to avoid >>> confusion. In general, what is in the custom section will take >>> preference as it is usually loaded last. If your going to remove the one >>> in the custom section, run M-x customize-variable org-agenda-files >>> and then select the options under the 'state' button to 'Erase >>> Customisation', don't just erase the values in the 'Value Menu' box. >> >> Emacs automatically introduced the custom, did not write it myself. >> > I fear I might have been the source of the confusion by suggesting > the command (org-agenda-file-to-front), which has triggered another > definition of org-agenda-file in the custom-set-variables section. I > hadn't realized fully the consequences. > > I apologize for this and I hope that it won't turn any user > against each other. I must confess that among the mailing-lists I have > subscribed to, this mailing list is the most cordial. > > Yes using both the `custom-set-variables` section and setting variable > can introduce confusion. I am sure many of us have fallen prey to > (counting me many times). > > At the same time it is convenient for some people to be able to > customize easily some variable and some users might use > custom-set-variables exclusively. > > We just need to understand the consequences of it and I guess many > users of emacs eventually come to do with these two options and even use > the best of both world modifying directly variables in the init files > and using the custom-set-variables section. > > It is a bug? I wouldn't say so. Can we explain to (new) users better > about it? Probably. > I think your right. In addition, based on more info which has come out on the list, I agree with what Kyle has pointed out re: variable to tell org to ignore missing files. This needs to be referenced in the manual and the documentation for org-agenda-files. If nobody else has done it by the time I have finished my current priorities, I will put a patch together to add such references. This won't be for a couple of weeks. -- 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: Adding Org Files to org-agenda-files
Hello, >> If you have *both* a settings in your emacs init file for >> org-agenda-files using (setq org-agenda-files...) and you have a line in >> your (custom ...) section, you should remove one of them to avoid >> confusion. In general, what is in the custom section will take >> preference as it is usually loaded last. If your going to remove the one >> in the custom section, run M-x customize-variable org-agenda-files >> and then select the options under the 'state' button to 'Erase >> Customisation', don't just erase the values in the 'Value Menu' box. > > Emacs automatically introduced the custom, did not write it myself. > I fear I might have been the source of the confusion by suggesting the command (org-agenda-file-to-front), which has triggered another definition of org-agenda-file in the custom-set-variables section. I hadn't realized fully the consequences. I apologize for this and I hope that it won't turn any user against each other. I must confess that among the mailing-lists I have subscribed to, this mailing list is the most cordial. Yes using both the `custom-set-variables` section and setting variable can introduce confusion. I am sure many of us have fallen prey to (counting me many times). At the same time it is convenient for some people to be able to customize easily some variable and some users might use custom-set-variables exclusively. We just need to understand the consequences of it and I guess many users of emacs eventually come to do with these two options and even use the best of both world modifying directly variables in the init files and using the custom-set-variables section. It is a bug? I wouldn't say so. Can we explain to (new) users better about it? Probably. Best regards, Jeremie
Re: looking for a macro eval workaround (9.1 vs 9.2 and +) for export backend test
Not sure if this helps, but the example that I came up with for the
quickstart https://orgmode.org/quickstart.html#macros has an example
(see below) of using multiple @@ export snippets in a single macro. If
you have consistent naming conventions for pdf vs svg you might be
able to write a variant #+macro: image that works like
{{{image(file-name-without-extension)}}}. Not sure this will get you
what you want though since I imagine that you want to modify how links
such as [[file:file-name.ext]] are exported. One alternative would be
to define a custom link type
https://orgmode.org/manual/Adding-Hyperlink-Types.html that would do
the type setting for you. If you want those definitions to live in the
org file you could use Eric's eval: (org-sbe startup) local variable
approach to ensure that the elisp definitions are always available.
Best,
Tom
The example from the quickstart:
#+MACRO: red @@html:$1latex:\textcolor{red}{$1}@@
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... > >
Re: One vs many directories
* Ihor Radchenko [2020-11-29 10:52]: > Jean Louis writes: > > > When task is assigned to somebody notification of a deadline or alerts > > are definitely useful for me. But they are are useful for those > > conducting the tasks. > > > > Thus integration to remind those *related* people to the assigned > > tasks and their deadlines or schedules would be useful. > > I think that can be done by extending alert.el package (which org-alert > is based on). alert.el allows the user to define custom alert styles, > including sending sms or email. Yes, that is great. We need more integration. There are low level packages but we need integration, high level, user accessible and for users useful features. Emacs is itself useful but there may be long process until user starts doing some programming. Then it becomes trivial to alert self or othre people by SMS, yet majority of users will not have that functionality unless we make it somehow. org-set-reminder by SMS could send it to assigned person. This is for me so important that it deserves menu item where user can assign that reminder. Once assigned it would run in intervals until task has been closed. org-send-task-by-email would find out which user is assigned to (feature is not built-in) and send it to assigned user automatically. It is trivial, but we do not have that. One click and it should go. > >> I agree that org-agenda has many issues that cannot be easily solved > >> because of its complexity. However, everything you describe (including > >> multi-occur) can also be achieved with org-ql > >> (https://github.com/alphapapa/org-ql) - analogue of SQL query language > >> for org-mode (with more optimisations in comparison with org-agenda). > > > > Definitely good only too much low-level. Users need finished functions > > that integrate stuff. To adopt myself to org-ql would mean to read > > documentations, meanings, and starting with some functions, while this > > may be possible for me that approach is not user friendly as users > > need integration and accessible interfaces. > > Not really. Searching in org-ql is made very intuitive - just like you > would search in google. There are multiple interactive commands: > - helm-org-ql :: The user simply types search keywords and the commands > shows all the matching headlines. For example, user can type > "headline:Doe call todo:WAIT tags:invoice" and get all kinds of > matches as he/she types > - org-ql-view :: shows the menu for different pre-customised searches > like "Calendar: This week" or "Overview: NEXT tasks" That is game changer. > > > Example of lack of integration would be to tell to user to simply > > construct the link in the form: [[Here][Link]] and that alone would > > require some thinking and learning. > > There is also (slower) helm-org (https://github.com/emacs-helm/helm-org) > offering similar interface to helm-org-ql, but also adding an option to > do various actions with the selected tasks, like inserting correctly > formatted link. The same can be done in helm-org-ql. I think the author > plans to extend that command in the near future. Or one can add extra > actions as needed - it is trivial to do in helm. > > > Good integration for org-ql would be a wizard that can add to the list > > of various queries and offers users various ways to search such as > > searching by headline, tags, or having both tags involved, date, > > deadlines and so on. > > All these are already available. The user can search tags:tag1,tag2,..., > headline:word1,word2 (or shortly hl:word1,...), scheduled:on=today, > deadline:from=-7,to=2020-12-01 org-ql is indeed a wizard for searching agenda and looks better than default. Jean
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!
Re: looking for a macro eval workaround (9.1 vs 9.2 and +) for export backend test
On Sunday, 29 Nov 2020 at 18:30, Bruno BEAUFILS wrote: > Any way this nice clean solution works well for almost all my cases > but one: when I include image I want them to be in pdf format in LaTeX > export and in original svg source when exporting in HTML. I used to do this the same way you are trying, using the backend information, but I was never entirely happy with what I achieved. Since then, I simply avoid having documents that will be exported to more than one target... yes, I chickened out! ;-) Hopefully somebody else can chime in. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4-143-g9a1549
Re: Remembrance Agents
On Sunday, 29 Nov 2020 at 20:29, Jean Louis wrote: > Sadly there are some errors today. On Debian, at least, there is a remembrance-agent package which has the binaries and the Emacs package. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4-143-g9a1549
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...
Re: Adding Org Files to org-agenda-files
> Sent: Sunday, November 29, 2020 at 6:01 PM
> From: "Tim Cross"
> To: daniela-s...@gmx.it
> Cc: emacs-orgmode@gnu.org, "Jean Louis"
> Subject: Re: Adding Org Files to org-agenda-files
>
>
> daniela-s...@gmx.it writes:
>
> >> Sent: Sunday, November 29, 2020 at 5:46 AM
> >> From: "Jean Louis"
> >> To: daniela-s...@gmx.it
> >> Cc: "Org-Mode mailing list"
> >> Subject: Re: Adding Org Files to org-agenda-files
> >>
> >> * daniela-s...@gmx.it [2020-11-29 02:30]:
> >> > > What you see as a problem some see as a solution. For instance, it
> >> > > depends how many
> >> > > org-files you want to add to the agenda. Some users including me have 2
> >> > > or three files in org-agenda-files so I never interact with this
> >> > > variable directly.
> >> >
> >> > I have many and they change quite frequently, depending on project.
> >> > So often torture emacs hard. Have sent a bug-report about it. Keen
> >> > for a change to go through.
> >>
> >> You may customize any Emacs variables yourself. Just define your
> >> agenda files yourself in your init file. Then do:
> >>
> >> {M-x customize-variables RET org-agenda-files RET} and erase what you
> >> find there.
> >>
> >> Anything before the `custom' section in your init file will be then
> >> defined by you and not by the built in system.
> >>
> >> In that case you should take care as user over time not to use
> >> org-agenda-file-to-front command as that would again start adding
> >> agend files to init file. Then just use your own settings.
> >>
> >> As long as you have your own settings hard coded you may erase the
> >> variable org-agenda-files
> >
> > That worries me because I do not want to change the behaviuor of Emacs
> > for users. Otherwise when people ask for help they will become confused.
>
> Just a small clarification on the above directions.
>
> If you have *both* a settings in your emacs init file for
> org-agenda-files using (setq org-agenda-files...) and you have a line in
> your (custom ...) section, you should remove one of them to avoid
> confusion. In general, what is in the custom section will take
> preference as it is usually loaded last. If your going to remove the one
> in the custom section, run M-x customize-variable org-agenda-files
> and then select the options under the 'state' button to 'Erase
> Customisation', don't just erase the values in the 'Value Menu' box.
Emacs automatically introduced the custom, did not write it myself.
> I'm not sure if I would classify the problem you ran into as a bug or
> user error. Emacs has 2 main ways to customise behaviour. either you can
> do it manually using things like (setq ...) in your init file, *OR* you
> can use the customize interface to make the changes using a high level
> 'widget' base UI. This all works pretty well unless you try to use both
> methods to customise the same thing.
Yes, if one uses Emacs Customise Behaviour, that's what happens. But I was
not using that. Helping people using elisp must be encouraged, because it
opens up many possibilities.
> In your case, the correct way to update the org-agenda-files list was to
> edit your init file, remove the reference to the missing file and then
> re-evaluae the variable. this is because you have decided to manage that
> variable yourself using setq.
>
> The other alternative is to remove the setq setting from your init file
> and then set your agenda file list using customize. The critical point
> is not to use both - one or the other.
>
> Many people will use a combination of some things set by hand in their
> init file and other things set using the customise interface. This is
> fine but you must ensure you don't use both for the same thing.
>
> In your case, because you are not use to configuring Emacs manually, I
> would strongly recommend you stick to using the customise interface.
> Later, when your more use to customising Emacs, you can move to doing
> your customisation in your init file by hand (if you want/need to - many
> never do and just use the customisation interface). The customisation
> interface is great when your not use to Elisp and don't yet know how to
> re-evaluate expressions etc. I know lots of users where the only thing
> in their init file is the custom section. All of their customisation is
> done using the custom interface and they are never required to write a
> single line of elisp.
>
> The org-agenda-files variable is also a little more complicated than
> most configuration variables because org allows you to add/remove files
> from that list interactively as well. For these interactive changes to
> persist across sessions, Emacs has to store them somewhere and it uses
> the custom section of your init file to do this. It cannot update your
> manual setting with setq because that would require parsing and
> modifying user controlled/written configuration code, which can be very
> complicated and could be spread over many different files (some people
> with large complex manual
Re: Remembrance Agents
* Eric S Fraga [2020-11-29 16:52]: > On Sunday, 29 Nov 2020 at 15:07, Gerardo Moro wrote: > > Has somebody installed it and tried it? It would be great to have a > > screen recording demo. > > I've used it on and off in the past, within the past 2 years most > recently. I populate the database it uses with both emails and org > files. While writing, it shows lines from documents that match in a > separate window (whose size can be customized). > > It does work but I find that I tend to forget about the remembrance > window most of the time so eventually I turn it off. I never seem to > have enough screen real estate to justify its use (despite having 38" > and 27" monitors side by side on my desk ;-)). Sadly there are some errors today. depmode=gcc3 /bin/sh ../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../savutil -I../savutil/parsedate -I../template -I../plugins -I\/usr/include/pcre -I\/sw/include-g -O2 -c `test -f 'gbuf.c' || echo './'`gbuf.c gbuf.c:43:8: error: conflicting types for ‘strnlen’ size_t strnlen (char *s, size_t n) ^~~ In file included from ../savant.h:50:0, from gbuf.c:39: /usr/include/string.h:401:15: note: previous declaration of ‘strnlen’ was here extern size_t strnlen (const char *__string, size_t __maxlen) ^~~ make[2]: *** [Makefile:191: gbuf.o] Error 1 make[2]: Leaving directory '/home/data1/protected/.emacs.d/remem/savutil' make[1]: *** [Makefile:394: ../savutil/libsavutil.a] Error 2 make[1]: Leaving directory '/home/data1/protected/.emacs.d/remem/main' make: *** [Makefile:428: main/ra-index] Error 2 ~/.emacs.d/remem $
Re: looking for a macro eval workaround (9.1 vs 9.2 and +) for export backend test
On Mon, Nov 23, 2020 at 01:12:45PM +, Eric S Fraga wrote:
> Don't be too hard on yourself! :-)
:-)
Any way this nice clean solution works well for almost all my cases
but one: when I include image I want them to be in pdf format in LaTeX
export and in original svg source when exporting in HTML.
I tried different way without any success without my old eval-fueled
=if-backend= MACRO, which I used that way {{{svg(myimage)}}}
(extension being added correctly depending of the backend).
Any idea how to achieve this?
--
Bruno BEAUFILS
signature.asc
Description: PGP signature
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.
Re: Remembrance Agents
* Gerardo Moro [2020-11-29 16:08]: > Thanks, I had seen those pages. Seems an old project and I haven't used it. > The Github page is here https://github.com/emacsmirror/remem That is great, I am much interested in that. I was thinking it is not available any more. I will test it.
Re: Adding Org Files to org-agenda-files
* Tim Cross [2020-11-29 16:01]: > >> If the type of heading is "task" then I do not need to use "TODO" as > >> it implies it is task. But Org headings do not have fixed types so it > >> is visually and practically better to use TODO. Here would the > >> inheritance be useful more than to tags. As if user marks one heading > >> as TODO, then all subtrees could automatically get its TODO. > > > > This assumes the only things you have under a TODO heading is other TODO > headings. That isn't how I structure my work. I might have many other > headings under a TODO heading which are not tasks, but are perhaps > related to the task. Sometimes I might have many tasks which are not > dependent on each other and so are all at the same level. That is amazing and true how you say. One heading may have many other non-TODO related headings which should not inherit the tag. When I was writing about htat I was thinking on database backed tasks. Every node has its "type" and if type is "Action/TODO" then such could inherit TODO tag to be visible. But if node is WWW, Note, or other type of hyperdocument, then not. For me that would be only visual tag, something in red color or similar or highlighted stuff because the hyperdocument in the system already has "Action type" assigned. Node or heading is already TODO internally. It is very trivial on a press of a key to get all lines highlighted which are TODO. Other assignments from a parent can make more sense, for example if task is assigned to group of 3 people then such designation could be inherited or invoked to be inherited. If there are other designations such as person connected, assigned, etc. all those may be inherited in a subtree or invoked explicitly to be inherited. This spares user not to type so much and curate tasks.
Re: Adding Org Files to org-agenda-files
* Ihor Radchenko [2020-11-29 15:25]: > Jean Louis writes: > > > Currently I am researching "NEXT" and how people are thinking and > > trying to see if I miss some concepts. My approach seem to be > > simpler. There is project and there are tasks in their most logical > > chronological or executable order just as a program. One has to do > > first one, then next. Which one is next is clear from the order of > > tasks. Marking it "NEXT" to me seem redundant as it would mean I have > > not made good order. > > NEXT is relevant to complex projects where multiple tasks can be active > at the same time. Or when some urgent tasks are added to the project as > it goes. Then, instead of constant reshuffling of the task order and > re-evaluating the order of tasks, one can simply mark the new urgent > tasks NEXT and later use sparse trees to only look at the tasks that > should be done at the current stage of the project. The key point is > minimising exposure to irrelevant information - the number of tasks in > large project can be demoralising, especially if one gets reminded about > it frequently. > > You might also check > https://old.reddit.com/r/orgmode/comments/i4hx1z/gtd_problem_with_todo_workflowconstantly/g0ihg2d/ , | So anything that is actionable is NEXT and anything that is depends on | something else should be a TODO? That seems like most tasks are NEXT | as opposed to TODO--intuitively, I would think most tasks should be | TODO and moved to NEXT when they are to be worked on now. Or do you | pluck from a large list of NEXT items and schedule them when you want | to work on them? | | The concept of NEXT tasks is most relevant to big projects. If, say, | you have a project with 10 big tasks you need to do in order to | complete the project, it is not very good idea to work on them at the | same time. Instead, you only mark 1-2 tasks as NEXT to finish them | first. Once you mark them DONE, the project will become stuck (no NEXT | tasks), which will be seen during GTD review process. So, you will | mark another 1-2 tasks as NEXT and continue working. ` >From there I can understand that. We are doing that for projects but we never assign NEXT. Because TODO group of tags and DONE group of tags designate basically something TO DO and something that is DONE and completed, then NEXT in itself is basically TODO-NEXT. But some people are designated several tasks as NEXT so that is contradictory to logic as only one should be next according to me. We write tasks in their most logical chronological order and every staff member is instructed to follow the order. One simply cannot drive a car without putting petrol first, so that system is followed. Some tasks on the ground can be done without chronological order and our staff members are left to decide on that. When they arrive to town and need to buy timber, maybe carpenter is discovered right there while the task says that once they arrive to village that they should look for carpenter. What is NEXT is mostly practically decided while doing things at my side. > > If the type of heading is "task" then I do not need to use "TODO" as > > it implies it is task. But Org headings do not have fixed types so it > > is visually and practically better to use TODO. Here would the > > inheritance be useful more than to tags. As if user marks one heading > > as TODO, then all subtrees could automatically get its TODO. > > That can be done. Should be trivial using org-edna > (http://www.nongnu.org/org-edna-el/), for example. Or you can use > org-trigger-hook and mark all the children with TODO keyword if the > parent heading is marked TODO. Interesting complication (Edna) that is supposed to be useful. Before constructing the series of those tasks user would need to construct series of tasks to construct series of tasks. Concept is great: This task can be completed only when tasks 1, 4 and 7 are completed. But practical life is different. When conducting projects staff members may discover on ground that dependable task can be completed without 1, 4 and 7 being completed as one could not predict future randomity. It may be also discovered that those 1, 4 and 7 are not true dependencies but some other tasks. This would imply that planner must know very well future incidents which is rarely the case as it would be so easy to predict future one would not be writing tasks. It is useful in trees and it should be an org built-in to mark all children nodes with the tag. It becomes very trivial when using database with nodes having a parent: , | UPDATE hlinks SET hlinks_tags = 'TODO' WHERE hlinks_parent = THIS ONE; ` But rather a function would be used or type assigned. The above is only example that shows how complex hard coded Elisp functions can be replaced with 3-4 lines single function when database is a backend. No wonder this guy has put Org mode in a sandwich on the logo of SMOS. It eats the Org. SMOS - A Comprehensive Self-Management System
Re: Adding Org Files to org-agenda-files
daniela-s...@gmx.it writes:
>> Sent: Sunday, November 29, 2020 at 5:46 AM
>> From: "Jean Louis"
>> To: daniela-s...@gmx.it
>> Cc: "Org-Mode mailing list"
>> Subject: Re: Adding Org Files to org-agenda-files
>>
>> * daniela-s...@gmx.it [2020-11-29 02:30]:
>> > > What you see as a problem some see as a solution. For instance, it
>> > > depends how many
>> > > org-files you want to add to the agenda. Some users including me have 2
>> > > or three files in org-agenda-files so I never interact with this
>> > > variable directly.
>> >
>> > I have many and they change quite frequently, depending on project.
>> > So often torture emacs hard. Have sent a bug-report about it. Keen
>> > for a change to go through.
>>
>> You may customize any Emacs variables yourself. Just define your
>> agenda files yourself in your init file. Then do:
>>
>> {M-x customize-variables RET org-agenda-files RET} and erase what you
>> find there.
>>
>> Anything before the `custom' section in your init file will be then
>> defined by you and not by the built in system.
>>
>> In that case you should take care as user over time not to use
>> org-agenda-file-to-front command as that would again start adding
>> agend files to init file. Then just use your own settings.
>>
>> As long as you have your own settings hard coded you may erase the
>> variable org-agenda-files
>
> That worries me because I do not want to change the behaviuor of Emacs
> for users. Otherwise when people ask for help they will become confused.
Just a small clarification on the above directions.
If you have *both* a settings in your emacs init file for
org-agenda-files using (setq org-agenda-files...) and you have a line in
your (custom ...) section, you should remove one of them to avoid
confusion. In general, what is in the custom section will take
preference as it is usually loaded last. If your going to remove the one
in the custom section, run M-x customize-variable org-agenda-files
and then select the options under the 'state' button to 'Erase
Customisation', don't just erase the values in the 'Value Menu' box.
I'm not sure if I would classify the problem you ran into as a bug or
user error. Emacs has 2 main ways to customise behaviour. either you can
do it manually using things like (setq ...) in your init file, *OR* you
can use the customize interface to make the changes using a high level
'widget' base UI. This all works pretty well unless you try to use both
methods to customise the same thing.
In your case, the correct way to update the org-agenda-files list was to
edit your init file, remove the reference to the missing file and then
re-evaluae the variable. this is because you have decided to manage that
variable yourself using setq.
The other alternative is to remove the setq setting from your init file
and then set your agenda file list using customize. The critical point
is not to use both - one or the other.
Many people will use a combination of some things set by hand in their
init file and other things set using the customise interface. This is
fine but you must ensure you don't use both for the same thing.
In your case, because you are not use to configuring Emacs manually, I
would strongly recommend you stick to using the customise interface.
Later, when your more use to customising Emacs, you can move to doing
your customisation in your init file by hand (if you want/need to - many
never do and just use the customisation interface). The customisation
interface is great when your not use to Elisp and don't yet know how to
re-evaluate expressions etc. I know lots of users where the only thing
in their init file is the custom section. All of their customisation is
done using the custom interface and they are never required to write a
single line of elisp.
The org-agenda-files variable is also a little more complicated than
most configuration variables because org allows you to add/remove files
from that list interactively as well. For these interactive changes to
persist across sessions, Emacs has to store them somewhere and it uses
the custom section of your init file to do this. It cannot update your
manual setting with setq because that would require parsing and
modifying user controlled/written configuration code, which can be very
complicated and could be spread over many different files (some people
with large complex manual configurations will break them up into
separate files and include them using (reqire...) or load. This makes
updating such settings very dangerous. On the other hand, the custom
section is managed by Emacs and not modified by hand, so it can store
the updated list in that section safely, which means the changes will
persist across sessions.
for this reason, I would recommend using custom to set/modify your
agenda file list and copletely delete the (setq org-agenda-files...)
from your init file.
You might still consider how this works to be a bug because the way it
works is confusing. However, it is very
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?
>
Re: Is Org really so simple?
* Ihor Radchenko [2020-11-29 10:16]: > > Jean Louis writes: > > Rather the query that is made by the user should be remembered as such > > and be made available as a command, macro or similar that can be saved > > for later. > > Users can explicitly define custom searches using > org-agenda-custom-commands. That is definitely useful feature. Just not as accessible and understandable. It needs chunk of effort to learn. I would rather prefer something like: "I wish to find [Headings] in [file] from [date] to [date] etc" [TODO Headings] [TAGS] [Headings with tags] etc. ^ drop down Not for me, but for future of Org mode I would find dropdowns more useful for users who would simply say what they want and choose it from drop downs "I wish to get list of ... with attributes ..." And multiple such examples could be offered and user could customize them. As C in (org-agenda) function shows this: Hide Org Agenda Custom Commands: INS DEL Choice: Value Menu Command series, all agenda files: Access Key(s): n Description : Agenda and all TODOs Component: INS DEL Choice: Value Menu Agenda: Local settings for this command. Remember to quote values: INS INS DEL Choice: Value Menu TODO list (all keywords): Local settings for this command. Remember to quote values: INS INS Settings for entire command set: INS [ ] Export: INS Which is simply not user friendly. I would prefer it as: "I wish to find [Headings] in [file] from [date] to [date] etc" [TODO Headings] [TAGS] [Headings with tags] etc. ^ drop down where [date] is not important but generation and construction of a human readable expression that user may easier relate to it. INS - what is it? Sure I know, but user only wants to see agenda. Emacs is advanced editor but we invite non-advanced users to become advanced. Those advanced are already using it. This design being too hackish be major block for an organization to adopt Emacs without previous knowledge about it. INS DEL Choice: Value Menu Agenda: Local settings for this command. Remember to quote values: INS INS DEL Choice: Value Menu TODO list (all keywords): Local settings for this command. Remember to quote values: INS Agenda in the real world is never that complicated and never complicated in same difficult manner. Paper based organization or even hand writing is easier than using the Org mode. It is for advanced users and it would be great to see simplifications and integrations bringing it closer to beginners. In comparison to Emacs based agenda views, I find it easier to use SQL: SELECT notes FROM table WHERE notes_tags LIKE 'TODO'; Something like that is more readable and human friendly. I find it funny that in customizations somebody actually put effort to tell users "Remember to quote values:". > Though format of that variable is indeed quite complex (similar to > org-capture-templates). I think that wizard or code generation function is very easy to make in Emacs, think like this: - press C or other key to generate your own query - User is asked "Press a key you wish to use for this query?" - User press "n" - Then user is offered values in a visible way to choose as Choice such as those in customization - "Do you want to add more choices to search from? yes/no" - "Do you want to export?" etc. When designing computer programs one should think to make things faster, easier, more useful than what people would otherwise do let us say on paper. If paper tasks have been spread in various groups, those would be already containing headlines that may be used for agenda. > > Example is when I search for TODO entries with special TODO kwd, then > > I may search for 3-4 keywords or 7-10 keywords during one > > day. Then there would be repetition to search again for those > > keywords. There is history value access in the minibuffer but that > > does not remember searches for the next Emacs session. Having > > rememberable customized searches for users would be useful. > > Take a look at savehist-mode. Enabling it should save all the minibuffer > history by default. However, the history of your agenda searches will be > mixed with global minibuffer history. If you do not like this behaviour, > feel free to open feature request to make org-agenda keep history > separately. Then, savehist can be configured to save that across Emacs > sessions. savehist-mode is all time enabled on my side. I am not sure if I can see here in
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?
Re: Adding Org Files to org-agenda-files
> Sent: Sunday, November 29, 2020 at 5:46 AM
> From: "Jean Louis"
> To: daniela-s...@gmx.it
> Cc: "Org-Mode mailing list"
> Subject: Re: Adding Org Files to org-agenda-files
>
> * daniela-s...@gmx.it [2020-11-29 02:30]:
> > > What you see as a problem some see as a solution. For instance, it
> > > depends how many
> > > org-files you want to add to the agenda. Some users including me have 2
> > > or three files in org-agenda-files so I never interact with this
> > > variable directly.
> >
> > I have many and they change quite frequently, depending on project.
> > So often torture emacs hard. Have sent a bug-report about it. Keen
> > for a change to go through.
>
> You may customize any Emacs variables yourself. Just define your
> agenda files yourself in your init file. Then do:
>
> {M-x customize-variables RET org-agenda-files RET} and erase what you
> find there.
>
> Anything before the `custom' section in your init file will be then
> defined by you and not by the built in system.
>
> In that case you should take care as user over time not to use
> org-agenda-file-to-front command as that would again start adding
> agend files to init file. Then just use your own settings.
>
> As long as you have your own settings hard coded you may erase the
> variable org-agenda-files
That worries me because I do not want to change the behaviuor of Emacs
for users. Otherwise when people ask for help they will become confused.
Re: Remembrance Agents
On Sunday, 29 Nov 2020 at 15:07, Gerardo Moro wrote: > Has somebody installed it and tried it? It would be great to have a > screen recording demo. I've used it on and off in the past, within the past 2 years most recently. I populate the database it uses with both emails and org files. While writing, it shows lines from documents that match in a separate window (whose size can be customized). It does work but I find that I tend to forget about the remembrance window most of the time so eventually I turn it off. I never seem to have enough screen real estate to justify its use (despite having 38" and 27" monitors side by side on my desk ;-)). There was a blog post early this year on this topic [1] which you might find interesting. It talks mostly about recoll [2] which is not so much a remembrance agent but a search tool HTH, eric Footnotes: [1] https://blog.jethro.dev/posts/remembrance_agents/ [2] https://www.lesbonscomptes.com/recoll/ -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4-143-g9a1549
Re: Remembrance Agents
Thanks, I had seen those pages. Seems an old project and I haven't used it. The Github page is here https://github.com/emacsmirror/remem Has somebody installed it and tried it? It would be great to have a screen recording demo. So as I see, it basically shows in the minibuffer documents that are related to what you write. Correct me if I'm wrong. Your project sounds intriguing! GM El sáb, 28 nov 2020 a las 20:29, Jean Louis () escribió: > * Gerardo Moro [2020-11-28 20:02]: > > Is there currently any (good) implementation of the idea of the > Remembrance > > Agents in Emacs? > > According to this document: > > Hyperlink: https://alumni.media.mit.edu/~rhodes/Papers/remembrance.html > > the implementation was running already in Emacs! > > There is more to it: > > https://www.emacswiki.org/emacs/RemembranceAgents > > And picture: https://alumni.media.mit.edu/~rhodes/Papers/ra.small.gif > > As I am developing HyperScope that is to augment the knowledge, at > least for those objects displayed within HyperScope but also in other > context or modes I could invoke something similar as Speedbar on the > side or in separate window that would show all relations to specific > object. It could also look from time to time into what text is user > writing and search relevant terms or tags to display such as > hyperlinks that are accessible on the side. The more information user > enters into the database and the more tags and relations have been > created the better the relevance. > > In the context of web applications providing CRM Customer Relationship > Management there are always various related objects hyperlinked on the > same page. Same is valid for ERM or Enterprise Resource Management and > similar systems as they are already based on the relational databases. > > Automatic hypertexting is another good feature that may be implemented > within Emacs for any relevant terms. >
Re: Adding Org Files to org-agenda-files
Ihor Radchenko writes:
> Jean Louis writes:
>
>> Currently I am researching "NEXT" and how people are thinking and
>> trying to see if I miss some concepts. My approach seem to be
>> simpler. There is project and there are tasks in their most logical
>> chronological or executable order just as a program. One has to do
>> first one, then next. Which one is next is clear from the order of
>> tasks. Marking it "NEXT" to me seem redundant as it would mean I have
>> not made good order.
>
> NEXT is relevant to complex projects where multiple tasks can be active
> at the same time. Or when some urgent tasks are added to the project as
> it goes. Then, instead of constant reshuffling of the task order and
> re-evaluating the order of tasks, one can simply mark the new urgent
> tasks NEXT and later use sparse trees to only look at the tasks that
> should be done at the current stage of the project. The key point is
> minimising exposure to irrelevant information - the number of tasks in
> large project can be demoralising, especially if one gets reminded about
> it frequently.
>
> You might also check
> https://old.reddit.com/r/orgmode/comments/i4hx1z/gtd_problem_with_todo_workflowconstantly/g0ihg2d/
>
Exactly. Not all the tasks in my task list are related or have
dependencies between them. I use NEXT as part of my planning process.
>> If the type of heading is "task" then I do not need to use "TODO" as
>> it implies it is task. But Org headings do not have fixed types so it
>> is visually and practically better to use TODO. Here would the
>> inheritance be useful more than to tags. As if user marks one heading
>> as TODO, then all subtrees could automatically get its TODO.
>
This assumes the only things you have under a TODO heading is other TODO
headings. That isn't how I structure my work. I might have many other
headings under a TODO heading which are not tasks, but are perhaps
related to the task. Sometimes I might have many tasks which are not
dependent on each other and so are all at the same level.
> That can be done. Should be trivial using org-edna
> (http://www.nongnu.org/org-edna-el/), for example. Or you can use
> org-trigger-hook and mark all the children with TODO keyword if the
> parent heading is marked TODO.
>
>> The DELEGATED type, I have seen people using this and myself also. But
>> if something is fully delegated and not any more mine, then I would
>> not have it in my file. So it is something usually that I have to
>> think of. Many of the tasks I think of are already assigned, I could
>> call it delegated. And I keep property :ASSIGNED: under the Org
>> heading. When I wish to send this task, I press one key and it is
>> automatically sent to the person assigned. But I am one supervising it.
>
> I guess the key reason to have DELEGATED is just to be reminded to
> followup on the progress.
>
Exactly. I don't just assign a task to someone and then forget about it.
I want to be reminded about which tasks have been delegated so that I
can follow up on them. Sometimes a delegated task is a dependency in
tasks which I have to do. I need to know when it is done in order to do
my task etc.
>> By using this approach one can assign tasks:
>>
>> #+TITLE: My Org File
>> #+AUTHOR: Me
>> #+PROPERTY: ASSIGNED_ALL James Jane John Juda Mehdi
>>
>> ** TODO Negotiate with land owner
>>
>> Now when one does {C-c C-x p} the minibuffer prompt asks for
>> "Property: " and there is ASSIGNED available as one of choices.
>>
>> In the next step it asks user for ASSIGNED value, and there are
>> choices such as James Jane John Juda and Mehdi. Then it becomes like
>> this.
>>
>> ** TODO Negotiate with land owner
>>:PROPERTIES:
>>:ASSIGNED: Mehdi
>>:END:
>>
>> This way the major type TODO does not change, but one knows that it is
>> assigned or delegated to Mehdi.
>
> I would do it in an opposite manner - mark the task DELEGATED, which
> triggers {C-c C-x p} and prompts me for the ASSIGNED value. The
> advantage of my method is simply that it is easier to see later -
> DELEGATED keyword is visible on the headline, which the PROPERTY drawer
> is folded by default. Of course, it would not matter if you configure
> org to not fold the PROPERTY drawers.
>
nd this highlights the main benefit of org mode. There is no 'one right
way'. It is up to the user to decide how to best use it to meet their
requirements. For me, I want a text only, relatively simple system which
has minimal dependencies on anything else (such as a database). I want
to be able to copy all my org files onto a thumb drive or put them into
the cloud and know I can access/use them from anywhere where I can run
Emacs or if Emacs is unavailable, just a basic editor where I can
edit/update them as text.
--
Tim Cross
Re: Missing line breaks in Beamer with alltt
On Sunday, 29 Nov 2020 at 11:22, Jarmo Hurri wrote:
> Any ideas?
First of all, the first frame works just fine for me. Line breaks are
preserved. However, I do know that in the past I have had problems with
alltt environments in beamer. I tend to use one of the algorithm
packages instead.
Your second frame leads to an error because the \in and \leftarrow are
not in math mode. Because your LaTeX code is explicitly in an export
LaTeX environment, org doesn't do its usual magic with LaTeX entities so
you need to put the maths delimiters yourself:
> #+begin_src latex
> \defverbatim\SomeCode{
> \begin{alltt}
> x $\in$ {0, 1, ..., n}
> z $\leftarrow$ x + 1
> \end{alltt}
> }
> #+end_src
When in doubt, export to LaTeX (C-e l b) and have a look at the
LaTeX. Also then run pdflatex yourself on that LaTeX code to see what
errors come up.
HTH,
eric
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.4-143-g9a1549
Re: Adding Org Files to org-agenda-files
Jean Louis writes:
> Currently I am researching "NEXT" and how people are thinking and
> trying to see if I miss some concepts. My approach seem to be
> simpler. There is project and there are tasks in their most logical
> chronological or executable order just as a program. One has to do
> first one, then next. Which one is next is clear from the order of
> tasks. Marking it "NEXT" to me seem redundant as it would mean I have
> not made good order.
NEXT is relevant to complex projects where multiple tasks can be active
at the same time. Or when some urgent tasks are added to the project as
it goes. Then, instead of constant reshuffling of the task order and
re-evaluating the order of tasks, one can simply mark the new urgent
tasks NEXT and later use sparse trees to only look at the tasks that
should be done at the current stage of the project. The key point is
minimising exposure to irrelevant information - the number of tasks in
large project can be demoralising, especially if one gets reminded about
it frequently.
You might also check
https://old.reddit.com/r/orgmode/comments/i4hx1z/gtd_problem_with_todo_workflowconstantly/g0ihg2d/
> If the type of heading is "task" then I do not need to use "TODO" as
> it implies it is task. But Org headings do not have fixed types so it
> is visually and practically better to use TODO. Here would the
> inheritance be useful more than to tags. As if user marks one heading
> as TODO, then all subtrees could automatically get its TODO.
That can be done. Should be trivial using org-edna
(http://www.nongnu.org/org-edna-el/), for example. Or you can use
org-trigger-hook and mark all the children with TODO keyword if the
parent heading is marked TODO.
> The DELEGATED type, I have seen people using this and myself also. But
> if something is fully delegated and not any more mine, then I would
> not have it in my file. So it is something usually that I have to
> think of. Many of the tasks I think of are already assigned, I could
> call it delegated. And I keep property :ASSIGNED: under the Org
> heading. When I wish to send this task, I press one key and it is
> automatically sent to the person assigned. But I am one supervising it.
I guess the key reason to have DELEGATED is just to be reminded to
followup on the progress.
> By using this approach one can assign tasks:
>
> #+TITLE: My Org File
> #+AUTHOR: Me
> #+PROPERTY: ASSIGNED_ALL James Jane John Juda Mehdi
>
> ** TODO Negotiate with land owner
>
> Now when one does {C-c C-x p} the minibuffer prompt asks for
> "Property: " and there is ASSIGNED available as one of choices.
>
> In the next step it asks user for ASSIGNED value, and there are
> choices such as James Jane John Juda and Mehdi. Then it becomes like
> this.
>
> ** TODO Negotiate with land owner
>:PROPERTIES:
>:ASSIGNED: Mehdi
>:END:
>
> This way the major type TODO does not change, but one knows that it is
> assigned or delegated to Mehdi.
I would do it in an opposite manner - mark the task DELEGATED, which
triggers {C-c C-x p} and prompts me for the ASSIGNED value. The
advantage of my method is simply that it is easier to see later -
DELEGATED keyword is visible on the headline, which the PROPERTY drawer
is folded by default. Of course, it would not matter if you configure
org to not fold the PROPERTY drawers.
Best,
Ihor
'documentation.org' now being required
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I have just updated my packages using the paradox package manager and then restarted emacs. And these were the packages that were updated - org-special-block-extras, binder, clojure-mode, helm, magit, esxml, org-ref, fountain-mode, link-hint, org=ql, org-cliplink, perspective, projectile, pyvenv, restart-emacs, smartparens, treemacs, transient, w3m. Every org-mode buffer now requires it to have a 'documentation.org' file to being its folder before 'imenu' will run and show in the taskbar. And then I got this message in the minibuffer, 'Current desktop was not loaded from a file. Overwrite this desktop file? (y or n)' for 906 times! How can I get emacs to not require 'documentation.org' in all my org-mode folders please? And for emacs to behave itself again please. Thanks Sharon. - -- Debian 10.6, fluxbox 1.3.7, emacs 27.1.50, org 9.4 -BEGIN PGP SIGNATURE- iQJPBAEBCgA5FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAl/DfmsbHGJvdWRpY2Nh c0Bza2ltYmxlLnBsdXMuY29tAAoJEDaBgBkK+INbfkkQAIZan8QFUS7mHBdaGhVl 5GwZ3VQNfASQJa2KBCxA7YtC1baqU0PZurss+TW2IIATGAbkCz6zg1J9hSIyrV4q VeFx5mR9UQMrxLVbwa1GhQywGu6PGxoBElU8DoHNrR0aGlYuTgXUbe7jlmhozwYV lgePGKon2tmVHnggBj9O9bpoOGeQj78Zxs9S+rT6RtgYm4g/LAtwh7Cp5IRjUc3L LF7hGLjXH4Up8jzm88G2NPSPoBWBP5yZEKgDXo5Z4Ut8qcasTzg+QSAqu8MPWf2Z 1YyfmeKzRNDAYvBiUlyTLYJNhAiQnYCOJRE+S/c8PwFY+qGwuAyi41AVMRDgj06K f9YPX/xNOzjoELAhUo3A5OtcvWl2B2tiZojNb3ME+p+nGlwUGJPN7zRYoEIqyFOK 3XmR5F4EtK5aZapvo28/5bIsws9lewrxGiFIKBnDL396z33l+z88CxZiiJJdEpP8 UACvElRcjlx8uCUXUoqheVktOlAbVT0T2Q3Ul7DmoTRGwQwTU3Fl6lHaSoa7DaOF MOhrtWzilG1rioFu5SMt41swaoJAU0ZTyMtC4JwWBTpea6DoptzRK9XTyGXv1M9s pBq24XR1NMXL2HH5Vsu+wC0P+ZGBs+HNMZejhdsUwhLl9QVeoTeyqapXM1rNgx53 JVYSKqS4nD/xtjY5kgVLZYPW =Tc7e -END PGP SIGNATURE-
Re: Adding Org Files to org-agenda-files
* Tim Cross [2020-11-29 08:24]:
> * Research
> ** TODO Explore enhancement to HTTP/2 [0/4]
> *** TODO Research HTTP/2
> *** TODO Implement HTTP/2 in feature branch
> *** TODO Test and benchmark HTTP/2
> *** TODO Generate report for board
> ** TODO Migrate from REST to GraphQL API
> *** TODO Research graphql
> *** TODO Plan graphql implementation
> *** TODO Implement new API
> *** TODO Plan migration to production
> TODO Merge into master
> TODO Update API documentation
> TODO Coordinate release with PROD team
Unrelated to the message, the repetitive TODO above after some while
could lose the purpose of alerting the user. By habit user may
indurate to seeing TODO.
One among several definitions of "indurate"
4. inure, harden, indurate -- (cause to accept or become hardened to;
habituate; "He was inured to the cold")
Then again there is problem that if TODO is forgotten the heading
loses its type of being actionable and more important, user may lose
track of forgotten TODOs.
Enhanced workflow would be that when actionable heading is added that
such cannot be changed easily to non-actionable. That would be something like:
- press key, maybe {C-c t} which would create
** TODO And user writes the heading
But TODO would not be possible to just remove, it would be the TODO
type. User could as usual switch to DONE or similar but the type of
heading would not be editable. One would better invoke some key to
remove the action type. That way Org editing and task creation would
be more rigid and help not in losing some of them.
> All of the tasks have been captured using the same TODO capture
> template. I can easily generate reports on total time spent in
> development, total time spent in development for each main 'feature' or
> time spent in each sub task or sub-sub task etc simply by selecting
> different 'scope' and 'level' settings for the clocktable report.
>
> In my project org files, I have a heading called '* Clocks', where I
> have all my clock reports. I will have as many different clock reports
> as required. For example, I might have one which clocks the time for all
> tasks in the file with up to 3 levels, then I might have one which only
> clocks the time for tasks in a specific subtree or perhaps one which
> only clocks/summarises times for tasks with a specific tag. It is very
> flexible.
When I read your workflow it is interesting. It also reminds me how
much of those functions are built-in into PostgreSQL database and how
such backend could enhance and speed up things and minimize the
development of features that already exist.
Then heading become something like this:
** Heading
DEADLINE: <2020-11-23 Mon> SCHEDULED: <2020-11-29 Sun>
:LOGBOOK:
CLOCK: [2020-11-30 Mon 10:15]--[2020-11-30 Mon 16:06] => 5:51
CLOCK: [2020-11-29 Sun 14:06]--[2020-11-29 Sun 20:06] => 6:00
CLOCK: [2020-11-29 Sun 12:06]--[2020-11-29 Sun 12:25] => 0:19
CLOCK: [2020-11-29 Sun 11:06]--[2020-11-29 Sun 11:35] => 0:29
CLOCK: [2020-11-29 Sun 10:15]--[2020-11-29 Sun 10:30] => 0:15
CLOCK: [2020-11-29 Sun 10:06]--[2020-11-29 Sun 10:10] => 0:04
:END:
And that is where Org defeats itself to be plain simple text. It wants
to be relational database. org-clock.el is great code of 114K and does
probably much more than the above ordering. Yet by using PostgreSQL
and maybe other SQL database in background, the clocking in and
clocking out becomes trivial and reliable:
- DEADLINEs may be entered in the database and their modifications can
automatically be recorded for later review. Isn't that significant
piece of information if person modified a deadline? That could be
dodging of the work. Deadline could be displayed if necessary but it
could also totally disappear. One only need unique way of
identifying the heading.
- SCHEDULED the same, if it is changed it is piece of information
indicating dodging. It should be recorded. Recording change into SQL
database is trivial, it is normally just one function, 3-4 lines of
Emacs Lisp.
- CLOCK-IN and CLOCK-OUT becomes also trivial. One database table may
record all of them. Press key and CLOCK-IN is done. It could be
displayed in various manners, under heading, or in message buffer or
in separate info buffer, frame, etc. Total time spent can be easily
calculated as that is the power of PostgreSQL and other SQL
databases that may calculate periods of time and add them together.
Finally the above table of CLOCK data does not look human friendly to
me. It is good for advanced users. But even as advanced user I would
not like spending time in interpretation of data that is meant to be
interpreted by computer. I would rather like to be told like:
"Total time spent 12 hours and 58 minutes" and nothing much more.
Org provides this feature:
#+BEGIN: clocktable :scope subtree :maxlevel 2
#+CAPTION: Clock summary at [2020-11-29 Sun 10:17]
| Headline | Time| |
|--+-+---|
|
Missing line breaks in Beamer with alltt
Greetings.
Any ideas?
#
--
#+startup: beamer
#+latex_header: \usepackage{alltt}
* A slide with some code
- export to beamer pdf with =C-e l O=
- line breaks disappear from this:
#+begin_alltt
x \in {0, 1, ..., n}
z \leftarrow x + 1
#+end_alltt
* An effort to fix this
- tip from
https://tex.stackexchange.com/questions/68064/beamer-alltt-environment-and-only
- the effort is here, but the end result is an error
#+begin_src latex
\defverbatim\SomeCode{
\begin{alltt}
x \in {0, 1, ..., n}
z \leftarrow x + 1
\end{alltt}
}
#+end_src
\SomeCode
#
--
All the best, and stay safe.
Jarmo
Re: Multiple named code blocks
Hi Felix,
You need to use the noweb-ref header argument instead of #+NAME, then the
block are all concatenated on output.
Best,
--Diego
On Sat, 28 Nov 2020 at 23:35, mooss wrote:
> Hi,
>
> I have been using org-mode for almost three years and I loved it so much
> that I started working on a literate programming tool based on it.
> One particular technique that I use is having multiple named code blocks,
> like so:
>
> #+begin_src perl :noweb yes :results output
> <>
> sub foo {
> <>
> }
> foo;
> #+end_src
>
> #+name: Before foo
> #+begin_src perl
> print "Before foo definition.\n";
> #+end_src
>
> #+name: Before foo
> #+begin_src perl
> my $value = 'Inside foo call';
> #+end_src
>
> #+name: In foo
> #+begin_src perl
> print $value . "\n";
> #+end_src
>
> This technique worked without issue until I recently updated Emacs and
> org-mode with it.
> I do not know the version of org-mode I was using before, but this was
> with Emacs 26.3 and I upgraded to Emacs 27.1 with org-mode 9.4 according to
> the information at the top of elpa/org-plus-contrib-20201116/org.el.
>
> Before the update, the code block after expansion (obtained with
> org-babel-expand-src-block via the C-c C-v C-v shortcut) looked like this:
> #+begin_src perl
> print "Before foo definition.\n";
> my $value = 'Inside foo call';
> sub foo {
> print $value . "\n";
> }
> foo;
> #+end_src
>
> Now the definition of $value is gone:
> #+begin_src perl
> print "Before foo definition.\n";
> sub foo {
> print $value . "\n";
> }
> foo;
> #+end_src
>
> I have looked at the info manual so I realise that according to "15.2
> Structure of Code Blocks": "For duplicate names, Org mode’s behavior is
> undefined" so it follows that:
> - Up until now, I was incorrectly assuming that duplicated named code
> blocks were supposed to result in them being concatenated in the noweb
> expansion phase.
> - This is not a bug report, org-mode is working as documented.
>
> I find this technique pretty useful for two reasons:
> 1. Importing packages right when they are needed.
> 2. Declaring variables in a broader scope than the one where they are
> first used.
> Here is an short example of this kind of situation:
>
> #+begin_src perl :noweb no
> # Expansion of <>:
> my $even_counter = 0;
> my @array = (4, 8, 15, 16, 23, 42);
> # A
> # lot
> # of
> # other
> # code
> # [...]
> foreach my $n (@array) {
> # Expansion of <>:
> $even_counter++ if $n % 2 == 0;
> }
> print "$even_counter";
> #+end_src
>
> In this example, $even_counter could not have been declared on the
> spot.
> Of course, this example is too basic to really paint the usefulness of
> this technique but an actual example would be too long, the goal here is
> just to explain the general idea.
>
> With all that being said I would suggest to define the behaviour for
> multiple named code blocks as resulting in a concatenation of the code
> blocks, in the order of their apparition.
> If you agree about defining this behaviour but think adapting the
> implementation is of low priority, I could try to implement it myself
> though I have little experience in emacs-lisp development beyond basic
> configuration and no experience whatsoever in contributing to FOSS, but I'm
> willing to start in both domains.
>
> Best regards,
> Félix
>
>
