11–20 of 90 posts
This limited buffer space has long been a criticism of mine and an often-used point I make when I choose to play the Holy War game between vim and emacs. 512MB is still a weak and arbitrary limitation (vim just uses up your memory), but this is much better than it was.
Earlier quoted context omitted.
All hashes suffer from collisions (Otherwise they would be great compression tools). But a collision to an arbitrary MD5 hash cannot yet be easily calculated. And producing a working (malware) binary with the same hash would be quite a challenge. So no, for these purposes, MD5 doesn't post a problem.
That doesn't appear to be true. From http://www.mscs.dal.ca/~selinger/md5collision/ : It is now well-known that the crytographic hash function MD5 has been broken. [...] The following is an improvement of Diaz's example, which does not need a special extractor. Here are two pairs of executable programs (one pair runs on Windows, one pair on Linux) [...] Here, you can download the software that I used to create MD5-co…
The maximum size of buffers (and the largest fixnum) is doubled. On typical 32bit systems, buffers can now be up to 512MB. This limited buffer space has long been a criticism of mine and an often-used point I make when I choose to play the Holy War game between vim and emacs. 512MB is still a weak and arbitrary limitation (vim just uses up your memory), but this is much better than it was.
The maximum size of buffers (and the largest fixnum) is doubled. On typical 32bit systems, buffers can now be up to 512MB. This limited buffer space has long been a criticism of mine and an often-used point I make when I choose to play the Holy War game between vim and emacs. 512MB is still a weak and arbitrary limitation (vim just uses up your memory), but this is much better than it was.
Can you give me a situation where you would need more space ?
- Extremely large log files
Why not use less? Because it's ugly and does not allow me to edit or copy specific sections out. I like having the full power of a good text editor at my back.
I have brought this concern up before, and the excuse I heard was, "Well, you should not have to work with files that large." Seems someone in emacs-land disagrees; now you can play with files up to 512 MB on a 32-bit system! If there is a legitimate use case for, oh, 500 MB, we can imagine a use case for 2 GB. The world is moving on; we aren't playing with 64 KB systems any more, and data keeps growing.
In 2010, our text editors still have hardcoded memory limits? (I understand emacs's architectural reasoning for it -- and that is a choice.) IIRC, DOS 6.2's Edit could handle large files; it accomplished this with a partial-loading/paging trick, rather than actually loading the entire file in memory.
So yes, I would like to and have enjoyed opening files of large size. Admittedly, I have to wait a bit for the I/O to catch up! :) I also have to be conscious of my memory usage, since I am unaware of any paging mode in vim (or emacs). I expect, on average, to have the option to open a file of at least 3 GB size -- and that is without taking advantage of swap. Next year, I expect more.
I know it is not a common desire, so I do not blame anyone for imposing an arbitrary limit other than to say "nyah nyah; I am free".
Mac OS X users can get a binary at http://emacsformacosx.com/ .
The maximum size of buffers (and the largest fixnum) is doubled. On typical 32bit systems, buffers can now be up to 512MB. This limited buffer space has long been a criticism of mine and an often-used point I make when I choose to play the Holy War game between vim and emacs. 512MB is still a weak and arbitrary limitation (vim just uses up your memory), but this is much better than it was.
Can you give me a situation where you would need more space ?
Edit: it's possible I used "less", I can't remember.
Earlier quoted context omitted.
Can you give me a situation where you would need more space ?
- Viewing/modifying a fasta file containing human chromosome data - Extremely large log files Why not use less? Because it's ugly and does not allow me to edit or copy specific sections out. I like having the full power of a good text editor at my back. I have brought this concern up before, and the excuse I heard was, "Well, you should not have to work with files that large." Seems someone in emacs-land disagrees; n…
I think the choice they make is to spend their very limited time on more useful features. I'm sure many of the core Emacs developers would be very happy if someone would fix this limitation. It would be a very invasive change, a fair amount of work.
Earlier quoted context omitted.
Can you give me a situation where you would need more space ?
Having once managed to delete a file with hours of edits just before committing to version control, I opened my 60 GB partition in vim, found the text of the file and copied it out. While this is "stupid" — there will be better ways to do it — searching and recovering with vim worked immediately and easily. Edit: it's possible I used "less", I can't remember.
Earlier quoted context omitted.
Can you give me a situation where you would need more space ?
- Viewing/modifying a fasta file containing human chromosome data - Extremely large log files Why not use less? Because it's ugly and does not allow me to edit or copy specific sections out. I like having the full power of a good text editor at my back. I have brought this concern up before, and the excuse I heard was, "Well, you should not have to work with files that large." Seems someone in emacs-land disagrees; n…
It might be time for Emacs to switch to 64 bit words internally, should give plenty of bits left for buffer addresses after taking a few bits of for type tags.
The memory overhead when editing small files would be larger, but I haven't really heard people complain about Emacs' memory footprint lately.