|
From: | Paul Eggert |
Subject: | Re: Generating the ChangeLog files from the commit messages |
Date: | Sun, 30 Nov 2014 21:49:06 -0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 |
Stefan Monnier wrote:
It makes sense to roll those files on a release-number basis rather than just size.
That sounds like a good idea.
What value would stop you from bumping into it, and on which kinds of files do you typically bump into it.
It's usually log files. For example, if I run 'git log >/tmp/log', and then visit /tmp/log, that's about 34 MB for Emac. Likewise for things like strace output or for random other text debugging output.
When the 10 MB limit was established back in 2003, machines typically had 64 MiB or so of RAM.Reality check: my 2003-vintage X30 laptop (which I happily use when doing presentations) came with 768MB of RAM.
You had bigger machines than I did. Even my circa-2005 laptop (which I still use) has only 512 MB of RAM. Was the limit tuned for your new laptop back in 2003? In that case, perhaps we should warn if the file is larger than 1/64th of physical RAM, though this sounds a tad conservative to me.
the size of human-edited files (the bread-and-butter for Emacs) hasn't increased nearly as much.
I mostly run into the problem when viewing files, not editing them, and the files I view can get pretty large. Sometimes I have to give up on Emacs entirely and use 'less', which is an annoying switch.
[Prev in Thread] | Current Thread | [Next in Thread] |