Re: [O] Ways to make org feasible for huge files
Why not working-file and archive-file? Archive-file would be the big file and working-file would be the small file in that scheme. On Wed, 12 Oct 2011, brian powell wrote: > * Maybe EMACS "narrowing" could be used: > http://www.gnu.org/s/libtool/manual/emacs/Narrowing.html > ... > Narrowing can make it easier to concentrate on a single subroutine or > paragraph by eliminating clutter. It can also be used to limit the > range of operation of a replace command or repeating keyboard macro. > ... > C-x n n > Narrow down to between point and mark (narrow-to-region). > C-x n w > Widen to make the entire buffer accessible again (widen). > C-x n p > Narrow down to the current page (narrow-to-page). > C-x n d > Narrow down to the current defun (narrow-to-defun). > > ** I mean: Maybe an OrgMode user could do narrow-to-region (and then > just "render" on the new smaller region) and/or an implementation > something like "org-narrow-to-region" could be coded. > > *** Just an idea--your mileage may vary--it may not work at all--I > hope you try it out and tell how it works for you. > > * I ran into similar problems: I made the file into 2 separate > files--one very large and the other very small that I render a > lot--when it gets big, I just prune out older and less important now > (backburner) subjects, paste them at the bottom of the small file and > then cut and paste the less important "*" sections into the big file. > ** Works great, its really the best way to do it--for backing up and > encrypting reasons and hard drive space reasons etc. > ** Could call them blahfile_now.org and blahfile_later.org (for the > small and large files respectively). > *** Since OrgMode files are plain text files, this works great. > > On Wed, Oct 12, 2011 at 8:54 PM, Marcelo de Moraes Serpa > wrote: > > Hi list, > > > > I love org and I think there's nothing like it out there, but I'm > > considering using Evernote for reference notes, because my reference.org > > file has grown too big (4234k + lines). This makes the rendering of the file > > way too slow, and 2 times out of 10 emacs crashes because of that. > > Jude If I got a nickel for every message I've already sent supporting Microsoft Windows and its applications I'd have enough to retire on comfortably no matter what the stock market did.
Re: [O] Ways to make org feasible for huge files
If org-mode runs into that kind of problem one way might be when a new .org file is made it has a chained from [main.org] statement in the top. If the file remains small enough that's all it would get. If the file is going to go beyond x lines in length, then a chained to [file.org] would end that first file and file.org would then open up if a user went beyond the chained to statement in the first file. The file file.org would have a chained from [firstfile.org] somewhere in the top of the file and names for files ought to be selectable by the users. This will only work where good garbage collection happens, and something like it was used on CP/M systems with t-maker back before I.B.M. made its first PC. On Fri, 14 Oct 2011, Scott Jaderholm wrote: > Btw I get that behavior in emacs 23.1 too > Scott > > > On Fri, Oct 14, 2011 at 3:00 AM, Tassilo Horn wrote: > > > Marcelo de Moraes Serpa writes: > > > > Hi Marcelo, > > > > > 4328, exactly the same amount of lines I have in the file. > > > > Didn't you say that you have 4000 *k* lines? > > > > Anyway, as Scott mentiones, in emacs 24 the linum packages seems to be > > more clever and only creates overlays for the visible area of a buffer. > > For example, when opening a file with 1000 lines and enabling > > linum-mode, I only have 35 overlays, because only 35 lines are visible > > at a time. > > > > Bye, > > Tassilo > > > > > On Thu, Oct 13, 2011 at 2:07 AM, Tassilo Horn > >wrote: > > > > > >> Marcelo de Moraes Serpa writes: > > >> > > >> > Wow.. this worked Torsten. Thank you. I wonder why this happens... > > >> > > >> linum-mode works with overlays to embed the numbers at the beginnig of > > >> lines. Overlays are very flexible but not too efficient, you don't want > > >> to have too many of them. Looking at linum.el, it seems it already does > > >> pooling of overlays in order not to create one overlay for any line, but > > >> I'm not sure. Could you please do > > >> > > >> M-: (length linum-overlays) RET > > >> > > >> in that large org file with linum-mode enabled and say what it returns > > >> to satisfy my curiosity? > > >> > > >> Bye, > > >> Tassilo > > >> > > >> > > >> > > > > > Jude If I got a nickel for every message I've already sent supporting Microsoft Windows and its applications I'd have enough to retire on comfortably no matter what the stock market did.
Re: [O] Ways to make org feasible for huge files
Btw I get that behavior in emacs 23.1 too Scott On Fri, Oct 14, 2011 at 3:00 AM, Tassilo Horn wrote: > Marcelo de Moraes Serpa writes: > > Hi Marcelo, > > > 4328, exactly the same amount of lines I have in the file. > > Didn't you say that you have 4000 *k* lines? > > Anyway, as Scott mentiones, in emacs 24 the linum packages seems to be > more clever and only creates overlays for the visible area of a buffer. > For example, when opening a file with 1000 lines and enabling > linum-mode, I only have 35 overlays, because only 35 lines are visible > at a time. > > Bye, > Tassilo > > > On Thu, Oct 13, 2011 at 2:07 AM, Tassilo Horn >wrote: > > > >> Marcelo de Moraes Serpa writes: > >> > >> > Wow.. this worked Torsten. Thank you. I wonder why this happens... > >> > >> linum-mode works with overlays to embed the numbers at the beginnig of > >> lines. Overlays are very flexible but not too efficient, you don't want > >> to have too many of them. Looking at linum.el, it seems it already does > >> pooling of overlays in order not to create one overlay for any line, but > >> I'm not sure. Could you please do > >> > >> M-: (length linum-overlays) RET > >> > >> in that large org file with linum-mode enabled and say what it returns > >> to satisfy my curiosity? > >> > >> Bye, > >> Tassilo > >> > >> > >> > >
Re: [O] Ways to make org feasible for huge files
Marcelo de Moraes Serpa writes: Hi Marcelo, > 4328, exactly the same amount of lines I have in the file. Didn't you say that you have 4000 *k* lines? Anyway, as Scott mentiones, in emacs 24 the linum packages seems to be more clever and only creates overlays for the visible area of a buffer. For example, when opening a file with 1000 lines and enabling linum-mode, I only have 35 overlays, because only 35 lines are visible at a time. Bye, Tassilo > On Thu, Oct 13, 2011 at 2:07 AM, Tassilo Horn wrote: > >> Marcelo de Moraes Serpa writes: >> >> > Wow.. this worked Torsten. Thank you. I wonder why this happens... >> >> linum-mode works with overlays to embed the numbers at the beginnig of >> lines. Overlays are very flexible but not too efficient, you don't want >> to have too many of them. Looking at linum.el, it seems it already does >> pooling of overlays in order not to create one overlay for any line, but >> I'm not sure. Could you please do >> >> M-: (length linum-overlays) RET >> >> in that large org file with linum-mode enabled and say what it returns >> to satisfy my curiosity? >> >> Bye, >> Tassilo >> >> >>
Re: [O] Ways to make org feasible for huge files
For my org files my linum-overlays length is equal to the number of lines on the screen so perhaps there's something you can do to get better performance. I'm not sure what setting it would be, I'm running e24 with my own complicated linum-format. Scott On Thu, Oct 13, 2011 at 9:23 PM, Marcelo de Moraes Serpa < celose...@gmail.com> wrote: > 4328, exactly the same amount of lines I have in the file. > > > On Thu, Oct 13, 2011 at 2:07 AM, Tassilo Horn wrote: > >> Marcelo de Moraes Serpa writes: >> >> > Wow.. this worked Torsten. Thank you. I wonder why this happens... >> >> linum-mode works with overlays to embed the numbers at the beginnig of >> lines. Overlays are very flexible but not too efficient, you don't want >> to have too many of them. Looking at linum.el, it seems it already does >> pooling of overlays in order not to create one overlay for any line, but >> I'm not sure. Could you please do >> >> M-: (length linum-overlays) RET >> >> in that large org file with linum-mode enabled and say what it returns >> to satisfy my curiosity? >> >> Bye, >> Tassilo >> >> >> >
Re: [O] Ways to make org feasible for huge files
4328, exactly the same amount of lines I have in the file. On Thu, Oct 13, 2011 at 2:07 AM, Tassilo Horn wrote: > Marcelo de Moraes Serpa writes: > > > Wow.. this worked Torsten. Thank you. I wonder why this happens... > > linum-mode works with overlays to embed the numbers at the beginnig of > lines. Overlays are very flexible but not too efficient, you don't want > to have too many of them. Looking at linum.el, it seems it already does > pooling of overlays in order not to create one overlay for any line, but > I'm not sure. Could you please do > > M-: (length linum-overlays) RET > > in that large org file with linum-mode enabled and say what it returns > to satisfy my curiosity? > > Bye, > Tassilo > > >
Re: [O] Ways to make org feasible for huge files
Marcelo de Moraes Serpa writes: > Wow.. this worked Torsten. Thank you. I wonder why this happens... linum-mode works with overlays to embed the numbers at the beginnig of lines. Overlays are very flexible but not too efficient, you don't want to have too many of them. Looking at linum.el, it seems it already does pooling of overlays in order not to create one overlay for any line, but I'm not sure. Could you please do M-: (length linum-overlays) RET in that large org file with linum-mode enabled and say what it returns to satisfy my curiosity? Bye, Tassilo
Re: [O] Ways to make org feasible for huge files
Wow.. this worked Torsten. Thank you. I wonder why this happens... On Wed, Oct 12, 2011 at 9:44 PM, Torsten Wagner wrote: > Hi, > > > On 10/13/2011 09:54 AM, Marcelo de Moraes Serpa wrote: > f 10 emacs crashes because of that. > >> >> What could I do to make it faster? I'm willing to disable fancy rendering >> features if needed, but I'm loosing way too much time with the rendering >> issues and crashes. >> > > Just by chance, are you running linum-mode (line numbers in a small column > at the left side of the buffer? > I noticed this does not work well with org-mode. I had a file with a few > thousand lines and folding took ages. > Switching the linum-mode off and folding was again instantly. > > Maybe this helps > > Totti > > >
Re: [O] Ways to make org feasible for huge files
Hi, On 10/13/2011 09:54 AM, Marcelo de Moraes Serpa wrote: f 10 emacs crashes because of that. What could I do to make it faster? I'm willing to disable fancy rendering features if needed, but I'm loosing way too much time with the rendering issues and crashes. Just by chance, are you running linum-mode (line numbers in a small column at the left side of the buffer? I noticed this does not work well with org-mode. I had a file with a few thousand lines and folding took ages. Switching the linum-mode off and folding was again instantly. Maybe this helps Totti
Re: [O] Ways to make org feasible for huge files
brian powell writes: > * I ran into similar problems: I made the file into 2 separate > files--one very large and the other very small that I render a > lot--when it gets big, I just prune out older and less important now > (backburner) subjects, paste them at the bottom of the small file and > then cut and paste the less important "*" sections into the big file. > ** Works great, its really the best way to do it--for backing up and > encrypting reasons and hard drive space reasons etc. > ** Could call them blahfile_now.org and blahfile_later.org (for the > small and large files respectively). > *** Since OrgMode files are plain text files, this works great. This works for me, too. I use the archive facility. When I'm done with a tree in the small file, I C-c C-x C-a on the headline, which saves having to cut and paste. Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Ways to make org feasible for huge files
* Maybe EMACS "narrowing" could be used: http://www.gnu.org/s/libtool/manual/emacs/Narrowing.html ... Narrowing can make it easier to concentrate on a single subroutine or paragraph by eliminating clutter. It can also be used to limit the range of operation of a replace command or repeating keyboard macro. ... C-x n n Narrow down to between point and mark (narrow-to-region). C-x n w Widen to make the entire buffer accessible again (widen). C-x n p Narrow down to the current page (narrow-to-page). C-x n d Narrow down to the current defun (narrow-to-defun). ** I mean: Maybe an OrgMode user could do narrow-to-region (and then just "render" on the new smaller region) and/or an implementation something like "org-narrow-to-region" could be coded. *** Just an idea--your mileage may vary--it may not work at all--I hope you try it out and tell how it works for you. * I ran into similar problems: I made the file into 2 separate files--one very large and the other very small that I render a lot--when it gets big, I just prune out older and less important now (backburner) subjects, paste them at the bottom of the small file and then cut and paste the less important "*" sections into the big file. ** Works great, its really the best way to do it--for backing up and encrypting reasons and hard drive space reasons etc. ** Could call them blahfile_now.org and blahfile_later.org (for the small and large files respectively). *** Since OrgMode files are plain text files, this works great. On Wed, Oct 12, 2011 at 8:54 PM, Marcelo de Moraes Serpa wrote: > Hi list, > > I love org and I think there's nothing like it out there, but I'm > considering using Evernote for reference notes, because my reference.org > file has grown too big (4234k + lines). This makes the rendering of the file > way too slow, and 2 times out of 10 emacs crashes because of that.
[O] Ways to make org feasible for huge files
Hi list, I love org and I think there's nothing like it out there, but I'm considering using Evernote for reference notes, because my reference.orgfile has grown too big (4234k + lines). This makes the rendering of the file way too slow, and 2 times out of 10 emacs crashes because of that. What could I do to make it faster? I'm willing to disable fancy rendering features if needed, but I'm loosing way too much time with the rendering issues and crashes. I'm using emacs 23.3.1 on Lion, org version 7.4. Any hints appreciated. Cheers. - Marcelo.
