a neat ruby idiom

[rgrau] guys, I just learned a new idiom  
[rgrau] (@foo ||= []) << bar  
[michal] :)  
[rgrau] It's not crystal clear, but I like it  
[rgrau] my perl background damaged my brain beyond repair
[jakub] rgrau: idiom or idiot?
[rgrau] you pick
[jakub] ok, done
[rgrau] I know which one you picked  
[jakub] u r smart
[rgrau] u idiom
[rgrau] that log goes to my blog inside ruby section

'symbols, :symbols and ':symbols

The other day, hacking a kind of project manager for emacs (YES. Another one) which I will explain in a future post, I bumped in a couple of wtfs, that turned out to be my own mental fuckup, not an elisp wtf.

Let's dissect plist-get with different kinds of atoms as keys, and try to explain why they work or they don't. Little schemer style.

(plist-get '('directory ":fdsa" 'irc "channel") 'directory) ; nil

Why? The whole plist is is quoted, being a literal list, so if there's no need to re-quote it again.

(plist-get (list 'directory ":fdsa" 'irc "channel") 'directory) ; ":fdsa"

Why? We built the list with the list constructor, so we have to quote the symbol directory. because we want a simbol.

(plist-get '(:directory ":fdsa" 'irc "channel") 'directory) ; nil

Why? :directory is a different symbol from 'directory, and the whole thing is quoted.

(plist-get (list :directory ":fdsa" 'irc "channel") 'directory) ; nil

Why? the plist is not a literal, but again. :directory and 'directory are different things

(plist-get (list :directory ":fdsa" 'irc "channel") :directory) ; ":fdsa"

You see?

(plist-get '(:directory ":fdsa" 'irc "channel") :directory) ; ":fdsa"

And this is again correct. Makes sense, no?

Then, the relation between :foo and 'foo is none, but (eq :foo ':foo) is t.

emacs taking to much memory?

[p1] my emacs takes up more memory than firefox, hm

[rgrau] open more firefox tabs

[p3] install more extensions

I love #emacs help style :)

If you are planning to change jobs in the programmers' world, make sure you read some of these articles. They all have very good points about what the authors think you should consider when looking for your _next_ job.

If you're not looking for a job, I'd recommend skim through them also.

They make a lot of good points IMHO, but I'll let you read them by yourself.

• http://matt.aimonetti.net/posts/2012/11/14/engineers-suck-at-finding-right-jobs/ 
• http://thecodist.com/article/what_programmers_want_is_less_stupid_and_more_programming 
• http://michaelochurch.wordpress.com/2012/10/30/what-programmers-want/
• http://coolinsights.blogspot.com.es/2011_01_01_archive.html 

HTTP status codes explained in IRC

*p1 is sending GET request since 2001
[p1] and still no response
[p2] 422
[p3] ETOOLONGTIMEOUT
[p3] malformed bitch
[p3] ah no, unprocessable
[p1] i don't do that sick stuff
[p3] unprocessable bitch
[p1] girls quite often reply with 403
[p1] if it doesn't help, they go 404
[p1] some even try 300 to their friend which is very pathetic
[p3] trying to DDOS

VPNs explained in IRC

[p1] meth. I've told you
[p2] lovely
[p2] it's like a VPN
[p2] you're comunicating where others just see noise
[p3] lol
[p3] that's a great quote
[p2] the guys from the other side of the vpn told it to me

github -> emacs : org-protocol-github-lines

Hello emacsers,

Today I'd like to present a hack I've assembled after being tired of going from github page to emacs looking for a given file/line repeteadly.

Say you collaborate in a project that's hosted in github, and you issue a pull request. If the team is minimally careful, someone will look at your code, and comment on it, pointing conventions you didn't follow, or pointing to buggy code you didn't notice you were introducing. At work, we are continuously doing comments in others pull requests as its part of our workflow.

So, wouldn't it be nice to have a custom button that opens your favourite editor in the correct file and line you're just staring at, but in your browser? Ok, that's what this hack is for.  The puzzle has 3 parts:

Browser

 When you check the pull request someone commented, you normally see something like the following.
 

Then you normally look at the file name, the line and the comment, and try to remember the three pieces of info, go to your editor, fetch the file, line and do the appropiate modifications.

Well, with org-protocol-github-lines  (yeah, the name sucks), you'll be presented with this: 

And the new link will point to "org-protocol://github-comment://kidd/org-protocol-github-lines/org-protocol-github-lines.el/28" .  This is done via a simple chromium userscript. (Alert, I suck at js, it's a complete hack)

Operating System

The second part of the puzzle is teaching your OS that org-protocol:// URIs should be opened with emacsclient. After trying some methods I found on internet and being unable to make any of those working, I went for the naive approach of copying xdg-open to my ~/bin directory, and patch it accordingly to open org-protocol:// URIs with emacsclient.  The complete xdg-open is in the git repo.

Emacs

And the last thing is the elisp part. when emacs receives an uri starting with org-protocol, you can use some org-protocol helpers to decode the parameters and such. The relevant info is in the org-mode page.

There's an alist called org-protocol-projects that you should modify to map "user/repo" -> "path/to/the/root/of/the/repo/(local)" .

And here's a video that shows the whole thing in action.

Demo of org-protocol-github-lines emacs plugin from Raimon Grau on Vimeo.

If you find more places where it makes sense to add those links, or have anything to coment, please use the comments here, or github issues, or find me in #emacs and #emacs-es as rgrau or rgc.


Clone it from https://github.com/kidd/org-protocol-github-lines