Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
Edit Octopress post
# FIX: the session waits for the editor to be done.
# Ideally this would not be a blocking command.
desc "Edit a post (defaults to most recent)"
task :edit_post, :title do |t, args|
args.with_defaults(:title => false)
posts = Dir.glob("#{source_dir}/#{posts_dir}/*.*")
post = (args.title) ? post = posts.keep_if {|post| post =~ /#{args.title}/}.last : posts.last
if post
puts "Opening #{post} with #{editor}..."
system "#{ENV['EDITOR']} #{post}"
puts "No posts were found with \"#{args.title}\" in the title."

imathis commented Mar 27, 2012


rake edit_post # opens the latest post
rake edit_post[happy] # opens the latest post with "happy" in the title


Octopress will provide a configuration where you can specify an editor which is different from your environments default editor. This will have to map to the system command for launching that editor.

My first thought would be to have a symbolic link to the latest post somewhere in your directory, and simply update that with the rake task to create a new post. The only downside is that it does not help you grep by title.


imathis commented Mar 27, 2012

@jakeonrails Ruby's Dir.glob().last seems do fine returning the most recent post. Is there a reason to believe it would fail in some case? The main issue I'm fighting is how to prevent the session from waiting for the editor to close.


system "#{ENV['EDITOR']} #{post} &"

work to not block?

That was literally the first thought I had when I saw the code, before I even read the issue. I should slow down a bit :) There's no problem with the ruby glob stuff that I can see.


imathis commented Mar 27, 2012

@jakeonrails Yep, "&" works just fine :) Can't believe I forgot about that. Thanks!

joliss commented Mar 27, 2012

I think this one of these features that just make it unnecessarily complex. I like Octopress because it's dead-simple (hence hackable).

(By the way, you shouldn't send calls to $EDITOR into the background, ever. It's against Unix convention, and it doesn't work with editors running in the terminal.)


imathis commented Mar 27, 2012

@joliss Why do you think this is complex? It seems to make a common task simpler. Using tab completion to open a post is an annoying process since prolific bloggers have to type two directories, the year, the month, and the day before they can tab to complete a recently created post.

A decent editor can handle this with its file browser or a project tree of some sort, but that isn't an argument that this wouldn't be useful. Can you elaborate on why you think this makes Octopress more complex?

An interesting point you make about the background call. For me mvim path/to/file opens MacVim without holding up my terminal session. I'd like to be able to replicate that functionality without the downsides of backgrounding it. Do you know of a way?

Crosse commented Mar 28, 2012

Why not remove the ampersand and let the user background the rake command instead, if they want to do so? Backgrounding is really only important for a subset of editors; in my informal testing, gVim will return to the command-prompt on Linux (and likewise MacVim on Mac) while gEdit doesn't; and like @joliss says, you don't want to background an editor running in the terminal. So let the user do it.

Also, $EDITOR for me is always a CLI editor, never graphical, and I expect others may do the same. However, I would rather write posts using a graphical editor (gVim or MacVim, in my case). So using $EDITOR would not be useful to me.

Bordering on the "unnecessarily complex" that @joliss doesn't want (but slightly easier than a user hacking the Rakefile code), you could put a "default_editor" variable in _config.yml and call that instead. Have it default to $EDITOR (can you do that? I don't know Ruby well enough to know), and let the user change it if they want to.


imathis commented Mar 28, 2012

@Crosse You're probably right about the backgrounding. I suppose I could add a line to the output for that task which tells the user how to background it if they are using a gui editor.

In the first comment my note field above, I mention adding an Octopress editor config. It will default to $EDITOR, and I don't think that's a complexity to be concerned with.


imathis commented Mar 28, 2012

@Crosse actually, backgrounding the rake task doesn't work so well since you won't see any output from that task when a file lookup fails. Still pining for a better solution.

Crosse commented Mar 28, 2012

@imathis, I guess I need to learn to read better! You sure did mention exactly what I proposed...sorry about the noise. Re: backgrounding when the lookup fails:

wrightst@mactex ~/code/blog $ rake edit_post['happy'] &
[1] 41094
wrightst@mactex ~/code/blog $ No posts were found with "happy" in the title.

[1]+  Done                    rake edit_post['happy']

That's typically what I expect when I purposefully background something and it immediately exits. It's not pretty, but it's consistent with what I see anytime I background something in a terminal. I agree, though, it'd be nice if it could be handled better.


imathis commented Mar 28, 2012

@Crosse, Yeah I just tried that again. A really weird behavior indeed. I had to ctrl+c to get it to quit after it output it's message. There must be a better way.

joliss commented Mar 29, 2012

Why do you think this is complex?

The headaches you are having in this thread illustrate the point. ;-)

A decent editor can handle this with its file browser or a project tree of some sort, but that isn't an argument that this wouldn't be useful.

I guess the reason why I find a feature like this suspicious is that it's orthogonal to Octopress's job, generating a blog. Other frameworks, like Rails, don't have anything like this either, and with good reason. IMO it belongs as an alias in your personal ~/.bashrc.

(Just a guess, but: Perhaps you're trying to replicate Wordpress here with its editing functionality? I actually like how Octopress isn't like Wordpress and treats me like a developer.)


imathis commented Mar 29, 2012

@joliss I think there's definitely a difference between challenge and complexity. The challenge may be due to my lack of knowledge in this area (why I asked for help). I'm not trying to replicate Wordpress. Jekyll's job is generating the blog. Octopress is trying to be both a nice default theme and an environment that makes it easier to work with Jekyll. Many of the rake tasks may be considered overly complex and not treating people like a developer. For example, setting up someone's blog for GitHub deployment based on their repo url is not simple or straightforward. It used to be a way harder multistep process. It was well documented but people kept messing up, so I automated it.

If I can't make this feature work like I want it, I won't include it in Octopress. I'm not interested in supporting something that annoys users. That being said, once you create a new post, I wish it was smoother to get into writing that post, especially since you can't just use shell command history to find the file created and pass it to your editor.

You may be right, this might be something that I can't get right and it doesn't belong in Octopress. I'm not sure yet.

once you create a new post, I wish it was smoother to get into writing that post, especially since you can't just use shell command history to find the file created and pass it to your editor.

I have this hacked up in my .bashrc (dirty, but it works...)
pedit() { find source/_posts/ -name "*$1*" -exec $EDITOR {} \; ;}

Crosse commented Mar 29, 2012

@imathis Weird...I just have to hit Enter a time or two to get back to a clean prompt.

I believe that this would be a worthwhile addition. It doesn't take away the user's ability to run things manually if they still want to, but it could be welcome functionality for other users. Note that I am in the group of users for which this probably wouldn't work: within the _posts directory I have a directory called "published" for all my published things, and a "drafts" folder for all my drafts. I made a small hack to 'rake isolate' to handle directories. But since I keep all my work-in-progress in a separate folder--and since I don't have a ton of drafts--I don't have to wade through a bunch of extraneous posts to find what I want to work on. But I still think this would be a good idea, if it can be implemented correctly.

Pesonally I added a task to my Rakefile:

desc "Open newly generated post in Emacs"
task :edit, :filename do |t, args|
  puts "Opening post in Emacs"
    `emacsclient -n #{args.filename}`

You could replace emacsclient -n with an editor variable at the top of the Rakefile (like ssh_user or deploy_branch). Also adding the globbing as a default if there is no args.filename would be easy, but personally I modified new_post and added Rake::Task["edit"].invoke(filename).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment