You mean like in multiterm or something? I guess so. In emacs there are always many ways to do things, which is awesome.
You can also open the file and engage auto-revert-mode or auto-revert-mode-tail. In my status bar it shows up as ARev mode.
Also you can bind those to your auto-mode-alist so all .log files get the tail treatment or whatever.
Scrolling can get weird.
Theres some google-able settings for the timeout to revert, default is about a sip of water (a few seconds?) but I guess you could crank it down to 1 second or something.
I like doing this in emacs so its all in the same ecosystem, if I need to cut and paste something weird to test it or put the message into code or even more likely to cut and paste actual error messages into docs or comments, I can do it inside emacs.
It looks like from ~24.4 onwards there's support for various notification event sources for auto-revert[-tail]-mode, as determined by the file-notify--library variable. I don't appear to have anything compiled into my prebuilt OSX emacs though, time to update the ol' source tree and see if I can remember how to build it.
This article is content marketing for Appcelerator. It builds a straw man of enterprise development that is convenient for Appcelerator's business model (scaling JavaScript applications), neglecting to consider other concerns such as stability, maintainability and support.
What would be the flaws with this 'stateless' approach:
1) for each new session, generate a secure random token as a property of the session
2) serialize session properties to a byte array and encrypt the array, using, say, AES.
3) set the encrypted session state as the value of the (HttpOnly) session cookie
4) when rendering secure pages, decrypt and include the clear CSRF token in the X-XSRF-TOKEN HTTP header (only top-level HTML pages, no other requests)
5) on the client, include the CSRF parameter in your XHR requests and form posts.
6) on the server, verify the CSRF parameter against the value in the encrypted session state from the session cookie
The only shared server state in this case would be the secret key used for AES; this could be part of the production environment configuration and updated with each deployment.
