Dear all, Thorsten wrote a page about the Google Summer of Code on Worg: http://orgmode.org/worg/org-contrib/gsoc2012/ He described his own project on the "ideas" page: http://orgmode.org/worg/org-contrib/gsoc2012/orgmode-gsoc2012-ideas.html (See "Real webprogramming with Org Mode and PicoLisp".) If you are a student and want to submit an Org-mode project for the GSoC 2012, please reply in this thread - we will give directions on how to edit the Worg page. When you have the first draft for your project, you'll then have to find a mentor for it, which I guess will also happen by discussing it in this list. The timeline for applications is here: http://www.google-melange.com/gsoc/events/google/gsoc2012 Organization (GNU) should register *before March 9th*. Students should register before *April 6th*. Org-mode related projects are likely to be presented under the GNU umbrella, but we are still waiting to know if GNU will apply as an Organization this year. Let's make this happen! And thanks to Thorsten who paved the way for _any_ project, not only his own. -- Bastien
Hi, Thanks to Bastien and Thorsten for advancing this opportunity. I think this could be a good chance for the community to collect and prioritize some of our more ambitious development goals, and to widen the pool of users who are familiar with the Org-mode internals -- a wonderful journey to take through some of the most hackable code I've ever had the pleasure of working on [1]. If there is any interest in working on the Babel (source code) elements of Org-mode I would be happy to serve as a mentor. Some ideas that come to mind include; - implementing a multi-programming-language "notebook" like console interface build on top of Org-mode and Babel (with both Emacs and HTML interfaces) - adding support for asynchronous code block execution - adding support for piping results between code blocks allowing many blocks to run concurrently (probably best combined with asynchronous execution) - adding support for handling output written to STDERR I'm sure there are many more exciting things to be done, the above are just those that come to mind at the moment. Best, Bastien <bzg@altern.org> writes: > Dear all, > > Thorsten wrote a page about the Google Summer of Code on Worg: > http://orgmode.org/worg/org-contrib/gsoc2012/ > > He described his own project on the "ideas" page: > http://orgmode.org/worg/org-contrib/gsoc2012/orgmode-gsoc2012-ideas.html > > (See "Real webprogramming with Org Mode and PicoLisp".) > > If you are a student and want to submit an Org-mode project for the > GSoC 2012, please reply in this thread - we will give directions on > how to edit the Worg page. When you have the first draft for your > project, you'll then have to find a mentor for it, which I guess > will also happen by discussing it in this list. > > The timeline for applications is here: > > http://www.google-melange.com/gsoc/events/google/gsoc2012 > > Organization (GNU) should register *before March 9th*. > > Students should register before *April 6th*. > > Org-mode related projects are likely to be presented under the GNU > umbrella, but we are still waiting to know if GNU will apply as an > Organization this year. > > Let's make this happen! And thanks to Thorsten who paved the way > for _any_ project, not only his own. Footnotes: [1] I can't count the number of times I've sat down to implement something thinking I had hours of work ahead of me, only to find that thanks to well placed hooks, and thoughtfully created and exposed variables the task was trivial. -- Eric Schulte http://cs.unm.edu/~eschulte/
"Git merge tool for Org files" http://lists.gnu.org/archive/html/emacs-orgmode/2011-08/msg00601.html
Jambunathan K <kjambunathan@gmail.com> writes: > "Git merge tool for Org files" > > http://lists.gnu.org/archive/html/emacs-orgmode/2011-08/msg00601.html > Interesting, along these lines, I know git is able to use custom diffs (e.g., there exist sentence rather than line-based diffs for writing prose). I wonder if an outline diff would be useful, so that re-ordering subtrees in an Org-mode file was represented as a single operation rather than many un-related deletions and insertions. -- Eric Schulte http://cs.unm.edu/~eschulte/
Eric Schulte <eric.schulte@gmx.com> writes: > Jambunathan K <kjambunathan@gmail.com> writes: > >> "Git merge tool for Org files" >> >> http://lists.gnu.org/archive/html/emacs-orgmode/2011-08/msg00601.html >> > > Interesting, along these lines, I know git is able to use custom diffs > (e.g., there exist sentence rather than line-based diffs for writing > prose). I wonder if an outline diff would be useful, so that > re-ordering subtrees in an Org-mode file was represented as a single > operation rather than many un-related deletions and insertions. Caveat: I know practically nothing - technically - about the project being discussed. I am commenting here as a lay user. Sometime back while looking at change tracking within OpenDocument files, I stumbled upon the following two entries. http://wiki.documentfoundation.org/Track_changes#Google_Summer_of_Code_2009:_Improve_Writer.27s_compare_function http://gsoc-tzvetelina.blogspot.in/ In the above blog, the author is talking about paragraphs as a unit and makes a note of the algorithms he uses to narrow down the paragraphs of interest. I think in Org's context, outline could (also) be considered as a unit.
Here are some ideas, which are maybe more from a user point of view. * Tables (babel) I would love to see work on making table work easy for non-programers; that is perhaps making babel 'easier' to use for common task. For text table I often have tasks that should be applied to say every other row. Recently, for example I needed to apply \multiolumn{1}{l}{\1} to every cell of every other row. The latex function of Hmisc and xtable does a nice job of making 'programable' changes tables easy. * Knitr-like (babel + org) There is a new package Knitr, a Sweave replacement. It does a nice work of working perfectly out of the box. For example inline-number expressions are formatted to a limited number of sign, it is very easy to use tikz-device (for R), which ensures consistent fonts. Code-blocks are automatically nicely formatted etc. I would be interesting if Org could be made more dwim in this manner (for many languages). * Better item handling At the moment it is hard to change lists. Often I need inline items and interrupted list. This is hard to do with Org at the moment. –Rasmus -- Enought with the bla bla!
Hello,
Rasmus <rasmus@gmx.us> writes:
> * Better item handling
>
> At the moment it is hard to change lists. Often I need inline items
> and interrupted list. This is hard to do with Org at the moment.
There is support for inline lists in the experimental LaTeX back-end.
Also, I'm not sure about what you mean with "interrupted lists", but
counters may be the answer, i.e.:
6. [@6] Start at 6
7. Following item
Regards,
--
Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 1483 bytes --] Nicolas Goaziou <n.goaziou@gmail.com> writes: > Hello, > > Rasmus <rasmus@gmx.us> writes: > >> * Better item handling >> >> At the moment it is hard to change lists. Often I need inline items >> and interrupted list. This is hard to do with Org at the moment. > > There is support for inline lists in the experimental LaTeX back-end. > > Also, I'm not sure about what you mean with "interrupted lists", but > counters may be the answer, i.e.: > > 6. [@6] Start at 6 > 7. Following item From OpenDocument side of things, I am inclined to cite the attached example. See comments in the attachment. Talking of migration to org-export.el/org-e-odt.el, indented tables pose special challenges because a list has to be broken and continued. It poses *more* challenges if I add "listified headlines" to the mix. Nicolas, Given the above context, one enhancmenet request that I have for you is this: Can the org-export driver make listified headings transparent to the backend? Currently listified headings are handled within org-e-backend-headline through first-sibling and last sibling checks and the backends *do know* that it is handling a headline in a special way. If you have reservations in considering the above request, I believe handling of indented tables will be fragmented across plain-list/item callbacks and headline callbacks. Note that I am not saying that it is not doable but only that it requires some deliberate effort and extra code. > Regards, -- [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: indented-table.org --] [-- Type: text/x-org, Size: 2504 bytes --] * Table within a Table Indented tables in ODT discontinue and continue a list. - Item1 - Item2 - Item2.1 | 1 | 2 | | 3 | 4 | - Item2.2 - Item3 * COMMENT XML for above table Here you can see table is syntactically outside of a list. There is a special list-header tag that is used for continuing an item. #+begin_src nxml <text:list text:continue-numbering="false" text:style-name="OrgBulletedList"> <text:list-item> <text:p text:style-name="Text_20_body"> Item1 </text:p> </text:list-item> <text:list-item> <text:p text:style-name="Text_20_body"> Item2 </text:p> <text:list text:continue-numbering="true" text:style-name="OrgBulletedList"> <text:list-item> <text:p text:style-name="Text_20_body"> Item2.1 </text:p> </text:list-item> </text:list> </text:list-item> </text:list> <text:section text:style-name="OrgIndentedSection-Level-2" text:name="Section1"> <table:table table:name="Table1" table:style-name="OrgTable"> <table:table-column table:style-name="OrgTableColumn"/> <table:table-column table:style-name="OrgTableColumn"/> <table:table-rows> <table:table-row><table:table-cell table:style-name="OrgTblCellT"><text:p text:style-name="OrgTableContentsRight">1</text:p></table:table-cell> <table:table-cell table:style-name="OrgTblCellT"><text:p text:style-name="OrgTableContentsRight">2</text:p></table:table-cell> </table:table-row> <table:table-row><table:table-cell table:style-name="OrgTblCellB"><text:p text:style-name="OrgTableContentsRight">3</text:p></table:table-cell> <table:table-cell table:style-name="OrgTblCellB"><text:p text:style-name="OrgTableContentsRight">4</text:p></table:table-cell> </table:table-row> </table:table-rows> </table:table> </text:section> <text:list text:continue-numbering="true" text:style-name="OrgBulletedList"> <text:list-item> <text:list text:continue-numbering="true" text:style-name="OrgBulletedList"> <text:list-header> </text:list-header> <text:list-item> <text:p text:style-name="Text_20_body"> Item2.2 </text:p> </text:list-item> </text:list> </text:list-item> <text:list-item> <text:p text:style-name="Text_20_body"> Item3 </text:p> </text:list-item> </text:list> #+end_src
On 2 mars 2012, at 18:12, Jambunathan K wrote: > Sometime back while looking at change tracking within OpenDocument > files, I stumbled upon the following two entries. > > http://wiki.documentfoundation.org/Track_changes#Google_Summer_of_Code_2009:_Improve_Writer.27s_compare_function > > http://gsoc-tzvetelina.blogspot.in/ > > In the above blog, the author is talking about paragraphs as a unit and > makes a note of the algorithms he uses to narrow down the paragraphs of > interest. I think in Org's context, outline could (also) be considered > as a unit. If I may advertise some things I did a while back, which may be useful to convert between textual formats: http://www.seas.upenn.edu/~harmony/ We also worked on a synchronizing algorithm that mixed diff3 with our tree synchronizer. I could try to dig that up as well. Alan
Eric Schulte <eric.schulte@gmx.com> writes: Hi Eric, Hi List, > Some ideas that come > to mind include; > - implementing a multi-programming-language "notebook" like console > interface build on top of Org-mode and Babel (with both Emacs and > HTML interfaces) > - adding support for asynchronous code block execution > - adding support for piping results between code blocks allowing many > blocks to run concurrently (probably best combined with asynchronous > execution) > - adding support for handling output written to STDERR Eric - I added these 4 proposels to the GSoC 2012 ideas page: http://orgmode.org/worg/org-contrib/gsoc2012/orgmode-gsoc2012-ideas.html and put you as potential mentor - is that OK with you? Since the deadline for the GNU application is approaching rapidly (9th of march) I would like to encourage anybody with an Org Mode related project idea (no matter if from a mentors or a students point of view) to add his proposol to the ideas page. This is a good chance for students to "flip bits, not burgers" during the summer, paid by Google, working on their favorite software-project, and contributing to the GNU project and the idea of free software. -- cheers, Thorsten
Hi all, I'm struggling to get reactions from the GNU project. Given the rich list of Org ideas on these pages, I will try to have Org accepted as a new organization and I will ask GNU to vouch for Org. If we are successful, I volunteer to work as a GSoC admin for Org, and we will have to find mentors for the projects. If we are not successful, then we can still try to participate under the GNU umbrella if GNU gets accepted. In any case, thanks for polishing ideas (by adding mentors, detailed deliverables and deadlines) on this page: http://orgmode.org/worg/org-contrib/gsoc2012/orgmode-gsoc2012-ideas.html Best, -- Bastien
Dear all, The Free Software Foundation will vouch for Org as a new organization. Is there any Googler reading this list? If so, is this Googler ready to vouch for Org-mode as a new organization? That would help a lot! In the meantime, please have a look to the last version of the ideas page and suggest improvements wildly: http://orgmode.org/worg/org-contrib/gsoc2012/orgmode-gsoc2012-ideas.html Thanks! -- Bastien
Hello, Jambunathan K <kjambunathan@gmail.com> writes: > Can the org-export driver make listified headings transparent to the > backend? I am reluctant to fake data presented to transcoders. I am even more reluctant when some information is lost in the process. A back-end might need to tell the difference between an headline that should be treated as a list and a regular list. For example some back-end with weak list concept (limited in the types of objects lists can contain) would rather not turn headlines into items. Currently, the exporter API is more oriented towards showing full info, and giving clues on how to handle it. > Currently listified headings are handled within org-e-backend-headline > through first-sibling and last sibling checks and the backends *do > know* that it is handling a headline in a special way. > > If you have reservations in considering the above request, I believe > handling of indented tables will be fragmented across plain-list/item > callbacks and headline callbacks. This is a back-end specific limitation. I guess it is unavoidable. Though, if you think about a generic tool that could reduce the amount of work required, I will include it in org-export.el. Regards, -- Nicolas Goaziou