Edit Octopress post

task.rb

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} &"
  else
    puts "No posts were found with \"#{args.title}\" in the title."
  end
end

@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.

does

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.

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

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.)

@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?

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.

@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.

@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.

@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.

@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.

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.)

@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 {} \; ;}

@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}`
end

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).