How many bytes are in the region?

Question

After far too many years of counting the number of characters in the region by doing M-: (- (point) (mark)), I just discovered M-= (count-words-region). Much better! But now I'm looking for a way to obtain the number of bytes that the characters in the region occupy in the buffer's coding system--typically, or always really, UTF-8. Is there an easy way to do this?

For context, I've been doing some code golfing on codegolf.stackexchange.com in a language that supports various Unicode operators, and I need to know how many bytes my submission occupies. So far I've been saving the region to a file, doing ls -l on it, then deleting it. I could easily whip up a function to do this automatically, but it seems rather inelegant.

Answer 1

Sounds like you are asking for something like this:

(defun region-bytes ()
  (interactive)
  (let ((strg  (if (use-region-p)
                   (buffer-substring-no-properties (region-beginning) (region-end))
                 "")))
    (message "Region has %d bytes" (string-bytes strg))))

---

You might also be interested in showing the region size in the mode line. You can do that with library modeline-posn.el -- see Mode Line Position. One of the style choice is to show the number of bytes in the active region -- just what you are asking for here. The difference is that it would always be shown (when the region is active), instead of being reported as a message only on demand (as per the command above).

Answer 2

While Drew's answer will work correctly in many cases (where utf-8 is pervasive and if you don't use DOS-style EOLs), if you want to make it work reliably for "all" buffers, you could do something like the following:

(defun region-bytes (start end)
  "Return the number of bytes used by the region."
  (interactive "r")
  (message "Region has %d bytes"
           (- (bufferpos-to-filepos end 'exact)
              (bufferpos-to-filepos start 'exact))))

and for cases where efficiency is more important than precision, you could pass approximate instead of exact, in which case bufferpos-to-filepos will always be very fast tho it will not handle correctly cases like GBK or utf-2022 encodings.