Re: [O] feature request
Recommendation: use something like GIT (or one of the other fine source control systems out there) to checkpoint your work, and save the history of your org files. It can even be set up in emacs to periodically save all org files and check in a snapshot. HTH, Brian From: Jude DaShiell jdash...@shellworld.net To: emacs-orgmode@gnu.org Sent: Monday, July 18, 2011 4:36 PM Subject: [O] feature request A little data destruction protection. I put together a table and had to destroy all copies of it after having tried to set up averages for a couple columns. The averages didn't work and data got zeroed out and I lost an entire column of data that way. One of my problems I'm sure was caused because I tried data gathering first then tried modifying the original table and adding the formulas later. Next time I attempt anything with org and mathematics, I'll write my data set down in braille and ought to have done that with this data set as well. What might have helped here a little is if a column is going to be put into existing columns the column inserts rather than overwrites any column that might be there. The broken table I ended up with had six columns and two of those were single space columns out to the right with nothing in them. There ought to have been before I did anything with formulas at most four columns in the table. I did enter time stamps in as two separated date and time fields originally then when I read what all could be put into time stamps, I consolidated those first two columns into a single time stamp column. I don''t know if that consolidation did further damage or not.
Re: [O] Regression bug in tangle/weave
I tested this again over the weekend, and finally understood what you were saying. I put a #+resname: blah : blahcontent and then I can use blah() to get blahcontent replaced without keeping the newlines. Is this abusing resname, or is it a proper use of the keyword? Will this behavior be stable in the future? Brian - Original Message - From: MidLifeXis at PerlMonks midlife...@wightmanfam.org To: Eric Schulte schulte.e...@gmail.com Cc: emacs-orgmode emacs-orgmode@gnu.org Sent: Friday, July 1, 2011 3:40 PM Subject: Re: [O] Regression bug in tangle/weave I am still getting prompted with the 'Evaluate this text code block (file-version) on your system?' message. What is your value of org-confirm-babel-evaluate set to? Mine is set as the default, 't. According to the docs, this is the more secure setting. I updated no more than two weeks ago. I will refresh my org-mode setup over the weekend and see if that takes care of it. Brian - Original Message - From: Eric Schulte schulte.e...@gmail.com To: MidLifeXis at PerlMonks midlife...@wightmanfam.org Cc: emacs-orgmode emacs-orgmode@gnu.org Sent: Friday, July 1, 2011 2:14 PM Subject: Re: [O] Regression bug in tangle/weave Yes, the second example I gave (shown immediately below) requires no execution of code. #+begin_src text :tangle yes file-version(). #+end_src #+results: file-version : 1.2.3.4 Best -- Eric MidLifeXis at PerlMonks midlife...@wightmanfam.org writes: Is there an example of this that does not use something like elisp, R, perl, python, shell, or some other process that requires either allowing all blocks to execute without prompting, or prompting for authority to run the block every time the file is tangled? Brian - Original Message - From: Eric Schulte schulte.e...@gmail.com To: MidLifeXis at PerlMonks midlife...@wightmanfam.org Cc: emacs-orgmode emacs-orgmode@gnu.org Sent: Thursday, June 30, 2011 1:30 PM Subject: Re: [O] Regression bug in tangle/weave Hi, Indeed this example below no longer works, however I believe the new behavior is both desired and permanent. I'll explain and include an option for how your example could be restructured to work with the new code. We ran into problems automatically removing trailing newlines from code block bodies as in some languages (looking at you Python and Haskell) things like trailing newlines are of syntactic importance. In your example this behavior results in the insertion of newlines after file-name and file-version. Babel is careful to preserve line prefixes when expanding references in comments, so it then reproduces the # Generated from portion of that line for every line of the expanded noweb references. I would suggest the following alternatives, either using a data references in stead of a code block reference as in the file-version example below, or using an evaluated code block as in the file-name example below. Hope this helps. Best -- Eric MidLifeXis at PerlMonks midlife...@wightmanfam.org writes: It appears that there may be a regression problem with the current tangle/weave process. I used to be able to have a noweb section for the name of the file, another for the version of the file, and then have an autogenerated header section that included those two pieces of information on a single line. Following is an org file snippet of my bug description. * Bugs ** SOMEDAY org-mode bug with tangle and newlines :BUG: :PROPERTIES: :created: [2011-06-30 Thu 10:00] :ID: e4c992b5-4d35-443b-b34a-0fbda7c66aea :END: :LOGBOOK: - Added on [2011-06-30 Thu 10:00] :END: [2011-06-30 Thu] A regression bug has surfaced in org-mode with the tangle/weave process mangling the following setup: #+begin_src perl :noweb yes :tangle testoutput.pl :shebang #!perl # generated-from print Hello world\n; #+end_src #+srcname: generated-from #+begin_src text :noweb yes Generated from file-name version file-version. #+end_src #+srcname: file-name #+begin_src text :noweb yes ATestFile.org #+end_src #+srcname: file-version #+begin_src text :noweb yes 1.2.3.4 #+end_src The last it worked* was sometime in the early 7.4 timeframe. If I get some time, I may do a bisect on it, although others are welcome to do the work required. Timeframe is based on memory, not actual checking, so first a bisect needs to be done to find where it last worked. *** Actual output #+begin_src perl #!perl # Generated from ATestFile.org # Generated from version 1.2.3.4 # Generated from file-name version . # print Hello world\n; #+end_src *** Expected output (or at least similar) #+begin_src perl #!perl # Generated from ATestFile.org version 1.2.3.4. print Hello world\n; #+end_src * End of org file -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Regression bug in tangle/weave
Is there an example of this that does not use something like elisp, R, perl, python, shell, or some other process that requires either allowing all blocks to execute without prompting, or prompting for authority to run the block every time the file is tangled? Brian - Original Message - From: Eric Schulte schulte.e...@gmail.com To: MidLifeXis at PerlMonks midlife...@wightmanfam.org Cc: emacs-orgmode emacs-orgmode@gnu.org Sent: Thursday, June 30, 2011 1:30 PM Subject: Re: [O] Regression bug in tangle/weave Hi, Indeed this example below no longer works, however I believe the new behavior is both desired and permanent. I'll explain and include an option for how your example could be restructured to work with the new code. We ran into problems automatically removing trailing newlines from code block bodies as in some languages (looking at you Python and Haskell) things like trailing newlines are of syntactic importance. In your example this behavior results in the insertion of newlines after file-name and file-version. Babel is careful to preserve line prefixes when expanding references in comments, so it then reproduces the # Generated from portion of that line for every line of the expanded noweb references. I would suggest the following alternatives, either using a data references in stead of a code block reference as in the file-version example below, or using an evaluated code block as in the file-name example below. Hope this helps. Best -- Eric MidLifeXis at PerlMonks midlife...@wightmanfam.org writes: It appears that there may be a regression problem with the current tangle/weave process. I used to be able to have a noweb section for the name of the file, another for the version of the file, and then have an autogenerated header section that included those two pieces of information on a single line. Following is an org file snippet of my bug description. * Bugs ** SOMEDAY org-mode bug with tangle and newlines :BUG: :PROPERTIES: :created: [2011-06-30 Thu 10:00] :ID: e4c992b5-4d35-443b-b34a-0fbda7c66aea :END: :LOGBOOK: - Added on [2011-06-30 Thu 10:00] :END: [2011-06-30 Thu] A regression bug has surfaced in org-mode with the tangle/weave process mangling the following setup: #+begin_src perl :noweb yes :tangle testoutput.pl :shebang #!perl # generated-from print Hello world\n; #+end_src #+srcname: generated-from #+begin_src text :noweb yes Generated from file-name version file-version. #+end_src #+srcname: file-name #+begin_src text :noweb yes ATestFile.org #+end_src #+srcname: file-version #+begin_src text :noweb yes 1.2.3.4 #+end_src The last it worked* was sometime in the early 7.4 timeframe. If I get some time, I may do a bisect on it, although others are welcome to do the work required. Timeframe is based on memory, not actual checking, so first a bisect needs to be done to find where it last worked. *** Actual output #+begin_src perl #!perl # Generated from ATestFile.org # Generated from version 1.2.3.4 # Generated from file-name version . # print Hello world\n; #+end_src *** Expected output (or at least similar) #+begin_src perl #!perl # Generated from ATestFile.org version 1.2.3.4. print Hello world\n; #+end_src * End of org file -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Regression bug in tangle/weave
I am still getting prompted with the 'Evaluate this text code block (file-version) on your system?' message. What is your value of org-confirm-babel-evaluate set to? Mine is set as the default, 't. According to the docs, this is the more secure setting. I updated no more than two weeks ago. I will refresh my org-mode setup over the weekend and see if that takes care of it. Brian - Original Message - From: Eric Schulte schulte.e...@gmail.com To: MidLifeXis at PerlMonks midlife...@wightmanfam.org Cc: emacs-orgmode emacs-orgmode@gnu.org Sent: Friday, July 1, 2011 2:14 PM Subject: Re: [O] Regression bug in tangle/weave Yes, the second example I gave (shown immediately below) requires no execution of code. #+begin_src text :tangle yes file-version(). #+end_src #+results: file-version : 1.2.3.4 Best -- Eric MidLifeXis at PerlMonks midlife...@wightmanfam.org writes: Is there an example of this that does not use something like elisp, R, perl, python, shell, or some other process that requires either allowing all blocks to execute without prompting, or prompting for authority to run the block every time the file is tangled? Brian - Original Message - From: Eric Schulte schulte.e...@gmail.com To: MidLifeXis at PerlMonks midlife...@wightmanfam.org Cc: emacs-orgmode emacs-orgmode@gnu.org Sent: Thursday, June 30, 2011 1:30 PM Subject: Re: [O] Regression bug in tangle/weave Hi, Indeed this example below no longer works, however I believe the new behavior is both desired and permanent. I'll explain and include an option for how your example could be restructured to work with the new code. We ran into problems automatically removing trailing newlines from code block bodies as in some languages (looking at you Python and Haskell) things like trailing newlines are of syntactic importance. In your example this behavior results in the insertion of newlines after file-name and file-version. Babel is careful to preserve line prefixes when expanding references in comments, so it then reproduces the # Generated from portion of that line for every line of the expanded noweb references. I would suggest the following alternatives, either using a data references in stead of a code block reference as in the file-version example below, or using an evaluated code block as in the file-name example below. Hope this helps. Best -- Eric MidLifeXis at PerlMonks midlife...@wightmanfam.org writes: It appears that there may be a regression problem with the current tangle/weave process. I used to be able to have a noweb section for the name of the file, another for the version of the file, and then have an autogenerated header section that included those two pieces of information on a single line. Following is an org file snippet of my bug description. * Bugs ** SOMEDAY org-mode bug with tangle and newlines :BUG: :PROPERTIES: :created: [2011-06-30 Thu 10:00] :ID: e4c992b5-4d35-443b-b34a-0fbda7c66aea :END: :LOGBOOK: - Added on [2011-06-30 Thu 10:00] :END: [2011-06-30 Thu] A regression bug has surfaced in org-mode with the tangle/weave process mangling the following setup: #+begin_src perl :noweb yes :tangle testoutput.pl :shebang #!perl # generated-from print Hello world\n; #+end_src #+srcname: generated-from #+begin_src text :noweb yes Generated from file-name version file-version. #+end_src #+srcname: file-name #+begin_src text :noweb yes ATestFile.org #+end_src #+srcname: file-version #+begin_src text :noweb yes 1.2.3.4 #+end_src The last it worked* was sometime in the early 7.4 timeframe. If I get some time, I may do a bisect on it, although others are welcome to do the work required. Timeframe is based on memory, not actual checking, so first a bisect needs to be done to find where it last worked. *** Actual output #+begin_src perl #!perl # Generated from ATestFile.org # Generated from version 1.2.3.4 # Generated from file-name version . # print Hello world\n; #+end_src *** Expected output (or at least similar) #+begin_src perl #!perl # Generated from ATestFile.org version 1.2.3.4. print Hello world\n; #+end_src * End of org file -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] Regression bug in tangle/weave
It appears that there may be a regression problem with the current tangle/weave process. I used to be able to have a noweb section for the name of the file, another for the version of the file, and then have an autogenerated header section that included those two pieces of information on a single line. Following is an org file snippet of my bug description. * Bugs ** SOMEDAY org-mode bug with tangle and newlines :BUG: :PROPERTIES: :created: [2011-06-30 Thu 10:00] :ID: e4c992b5-4d35-443b-b34a-0fbda7c66aea :END: :LOGBOOK: - Added on [2011-06-30 Thu 10:00] :END: [2011-06-30 Thu] A regression bug has surfaced in org-mode with the tangle/weave process mangling the following setup: #+begin_src perl :noweb yes :tangle testoutput.pl :shebang #!perl # generated-from print Hello world\n; #+end_src #+srcname: generated-from #+begin_src text :noweb yes Generated from file-name version file-version. #+end_src #+srcname: file-name #+begin_src text :noweb yes ATestFile.org #+end_src #+srcname: file-version #+begin_src text :noweb yes 1.2.3.4 #+end_src The last it worked* was sometime in the early 7.4 timeframe. If I get some time, I may do a bisect on it, although others are welcome to do the work required. Timeframe is based on memory, not actual checking, so first a bisect needs to be done to find where it last worked. *** Actual output #+begin_src perl #!perl # Generated from ATestFile.org # Generated from version 1.2.3.4 # Generated from file-name version . # print Hello world\n; #+end_src *** Expected output (or at least similar) #+begin_src perl #!perl # Generated from ATestFile.org version 1.2.3.4. print Hello world\n; #+end_src * End of org file
Re: [O] How can I review a day?
#+BEGIN: clocktable :block today :scope agenda :maxlevel 4 :link 2 #+END: clocktable You can also use agenda-with-archives for the scope if needed. - Original Message From: Robert Inder rob...@interactive.co.uk To: Puneeth Chaganti puncha...@gmail.com Cc: emacs-orgmode@gnu.org Sent: Tue, April 19, 2011 10:06:12 AM Subject: Re: [O] How can I review a day? On 19 April 2011 14:59, Puneeth Chaganti puncha...@gmail.com wrote: So I'd like a way to review the time-line for a day: a way to see all the clock-in/clock-out pairs in order, so I can see any gaps or overlaps. Hit l in agenda mode to enable the log mode. Is this what you need? Whoa! Close, but not touching. I nearly mis-read/understood you. I initially thought you just meant ^C-a-L -- Timeline for current buffer. Which doesn't show any clock-related information. But I realise you actually meant that after I've done that, I should type l to get Log mode, it DOES show clock-related information. That's a really neat feature, and it's very close to what I want. But not quite right. It shows me the sequence of activities I logged time to, and how much time I logged. But it doesn't show me WHAT time I logged I want to check that (after I have manually edited one or more CLOCK lines) I haven't missed some time or double-logged any. And I can't see how to get that information. Robert. -- Robert Inder,0131 229 1052 / 07808 492 213 Interactive Information Ltd, 3, Lauriston Gardens, Edinburgh EH3 9HH Registered in Scotland, Company no. SC 150689 Interactions speak louder than words
Re: [O] Formal description of Org files
This is something I would like to see adopted by the org community as well. One of my main reasons is to allow other languages to be able to at least, given the proper configuration information (for TODO keywords, etc), to be able to deal with org files. I am not quite sure where the lines should be drawn, but I am envisioning something like: * The ORG format definition and actions The format of the .org file (ORG) itself and a set of actions that are well behaved (add node, move node up, node id, property value, etc). A core set of validation tests could be created to exercise any compliant org library. * The configuration for a set of ORG files The configuration for a given org (note the small org) application, defining particular tweaks that an application can use to make sense of a properly formatted ORG file, such as valid TODO keywords, etc. This area is muddy in my mind. * The org application itself - how the org files are used in a particular application, or the ideas and data that set of ORG files represents, or how an exporter handles the data thrown at it, or But that is just /my/ dream. From: Rustom Mody rustompm...@gmail.com To: emacs-orgmode emacs-orgmode@gnu.org Sent: Fri, April 15, 2011 12:13:45 PM Subject: Re: [O] Formal description of Org files Hi, I have a question. At FOSDEM, someone asked me if there was a formal description of the structure of Org files, in some language that would be the input for a parser (or parser generator?) so that Org file could be easily parsed. Unfortunately I did not catch the name of the format description language that could be used for something, not did I catch the name of the person who talked to me. Can anyone help out here? Let me know what language to use, and maybe help work on such a formal description? I think it would be useful to have Something like yacc (bison, antlr etc) are all 'executable BNF' languages. When they work they can make the code an order of magnitude smaller and development/programming correspondingly easier. That said I see a couple of hitches. 1. Grammatical handling of languages is based on the assumption of a clear and well defined set of tokens/lexemes. I expect this would be harder in org than the typical programming languages for which yacc etc are used. For example in most 'normal' languages there are comments and strings. These involve some non trivial handling which is entirely hidden from the grammar by being pushed into the lexer. 2. Parsing a program is done for the full program as a rule (IDEs are the exception to the rule). Sensible parsing of program fragments, where the fragmenting could be quite arbitrary, is a bit of a research problem 3. As I see it, the main declarative tool (somewhat akin to grammars) that org uses is regular expressions. IOW org is written with re-s strung together with programming logic ie vanilla elisp. An alternative that stays within the regular framework (not using the heavy guns of context free parsing) may be ragel: http://www.complang.org/ragel/ Rusi
Re: [O] Re: Test framework needed
As a heavy Perl user, writing /automated/ tests is a large part of my dev work. I would suggest / plea / encourage that whatever framework is used can be automated. If it cannot be run as part of an automated process it is not going to be run. Also consider a set of testing platforms (emacs version, supporting versions of other .el modules, OS version, external software). There are many dependencies that org has - being able to automate this testing is a must. Just my $0.02. Brian / MidLifeXis - Original Message From: Eric Abrahamsen e...@ericabrahamsen.net To: emacs-orgmode@gnu.org Sent: Wed, March 30, 2011 9:11:23 AM Subject: [O] Re: Test framework needed On Wed, Mar 30 2011, Rainer M Krug wrote: On 30/03/11 15:46, Eric Abrahamsen wrote: On Wed, Mar 30 2011, Rainer M Krug wrote: Hi I was bitten again from an unintended regression in org-mode, and that the second time in two weeks. I am probably not the right person to suggest this, but I think it is time to introduce a test framework for org-mode, to ensure that the (without doubt useful) approach to develop org-mode does not lead to regressions. This would be the page to start with, though the most likely candidate (Elisp Regression Testing) is only available in Emacs trunk at the moment… http://www.emacswiki.org/emacs/UnitTesting Am I right in assuming, that all of the possible test frameworks would require org files and the expected output (tengle, export to ..., agenda, ...)? In this case, would it make sense to start collecting those, as they can easily be user contributed, consequently representing a cross section of the use cases (even not intended use cases)? Yup, what you would need is some org source files that exercise all of the possible export options (for testing export, for example), including weird edge cases, and then ERT (if that's what we ended up using) would provide handy functions for making sure the export output matches expectations. The excellent gentleman who created the ODT exporter, whose name currently escapes me, has already created test files for his exporter—that would be a perfect place to start. Covering all of org's various functions would end up being a bit of a PITA, though you're quite right that it's an excellent idea, and will become more and more necessary. E
Re: [O] Slow movement in large buffers
I have seen this happen when I have largish files with tables. I also have a file setting of: #+begin_src org #+STARTUP: align #+end_src which turns on automatic alignment of things recognized as table-like. If I remove this startup directive, things tend to run more smoothly. I have not formally reproduced this problem, and am currently going by memory as to when I have seen it, so YMMV (and so might mine). MidLifeXis - Original Message From: Chris Randle ch...@amlog.co.uk To: emacs-orgmode@gnu.org Sent: Tue, March 15, 2011 11:11:23 AM Subject: Re: [O] Slow movement in large buffers Hi Matt On 2011-03-15 03:25, Matt Lundin wrote: I've been navigating the org-issues file (14000+ lines) and have found movement within the file to be fairly slow. Sometimes Emacs will lock up for several seconds. snip Do others have the same experience? If so, does anyone have any tips on how to diagnose this further? I keep all my info in one big Org-mode file which is currently just shy of 115,000 lines. There's the occasional stutter of a fraction of a second when I move across closed nodes containing large chunks, but it's still perfectly acceptable (to me, anyway!). My PC is an Intel dual-core 2.66GHz with 4GB RAM, so nothing earth-shattering. -- Chris Randle
[Orgmode] Bug: contrib/src/org-collector.el [7.3]
Hello, org-read-prop treats strings beginning with digits as numbers. contrib/lisp/org-collector.el: (line 124ish: http://repo.or.cz/w/org-mode.git/blob/5f77fd6a81a4241ce5a8e346acb9df089d65b462:/contrib/lisp/org-collector.el#l124) (org-read-prop 123abc-def543) returns 123, should return 123abc-def543 Creates problems trying to include org-generated ID numbers (UUID style) into a propview table. Perhaps later I can submit a patch, but I don't currently have the cycles. My current configuration is: Emacs : GNU Emacs 22.2.1 (i386-mingw-nt5.1.2600) of 2008-03-26 on RELEASE Package: Org-mode version 7.3 but the problem is still in the master branch (see link above). Brian ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
