Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support editing a blog post after creating it with -e #203

Merged
merged 3 commits into from Jun 24, 2016

Conversation

nogweii
Copy link
Contributor

@nogweii nogweii commented Mar 13, 2014

Passing -e or --edit to 'middleman article' will open the user's $EDITOR
with the new blog post. It will fall back to vi if $EDITOR hasn't been exported.
(A fairly normal behaviour in Linux anyways.)

Closes #201.

@karlfreeman
Copy link
Contributor

Quite like this, but perhaps if there is no $EDITOR set it simply does not edit the article? instead of assuming vi?

@bhollis
Copy link
Contributor

bhollis commented Mar 13, 2014

This is great, but I don't think it'll work right on Windows, and it won't open the file in a GUI editor on Mac. We're going to need to figure out a cross-platform way of opening the file in the user's preferred editor.

@nogweii
Copy link
Contributor Author

nogweii commented Mar 13, 2014

I don't think it'll work right on Windows, and it won't open the file in a GUI editor on Mac.

I don't think there are any problems, so long as $EDITOR is set to the editor's binary. I also think system() would work on Windows for our use-case, but I'm not 100%.

@coveralls
Copy link

Coverage Status

Coverage remained the same when pulling e77aadd on evaryont:edit-new-article into 394e8f4 on middleman:master.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage remained the same when pulling e77aadd on evaryont:edit-new-article into 394e8f4 on middleman:master.

@bhollis
Copy link
Contributor

bhollis commented Mar 14, 2014

I think I'd want to do some experiments on OS X and Windows to make sure it'll do what users expect.

@bhollis
Copy link
Contributor

bhollis commented Mar 25, 2014

Yeah, this is tricky. EDITOR is nice for CLI editors like emacs or vim, but I use a GUI markdown editor (Mou) just for Markdown files, and that's my default program for opening them. So for me, on OS X, I'd want to call open to open my article in Mou, even though my EDITOR is emacs. On Windows, I would just want to call start on the file to open it in my default editor. On *nix, I'd want to run xdg-open or kde-open or gnome-open, unless they really did want to use EDITOR.

I'm not sure how to make everyone happy without a ton of weird platform-specific code and platform detection.

@karlfreeman
Copy link
Contributor

@bhollis 👍. It might be more frustrating that this works sometimes for some people than the benefit this feature brings.

@nogweii
Copy link
Contributor Author

nogweii commented Mar 25, 2014

I can see that, quite a rabbit hole.

Instead, how about something like --editor=BINARY? Perhaps paired with an
option in config.rb. I think that handles pretty much every use case,
though a little bit more manually.
On Mar 24, 2014 11:42 PM, "Ben Hollis" notifications@github.com wrote:

Yeah, this is tricky. EDITOR is nice for CLI editors like emacs or vim,
but I use a GUI markdown editor (Mou) just for Markdown files, and that's
my default program for opening them. So for me, on OS X, I'd want to call
open to open my article in Mou, even though my EDITOR is emacs. On
Windows, I would just want to call start on the file to open it in my
default editor. On *nix, I'd want to run xdg-open or kde-open or
gnome-open, unless they really did want to use EDITOR.

I'm not sure how to make everyone happy without a ton of weird
platform-specific code and platform detection.


Reply to this email directly or view it on GitHubhttps://github.com//pull/203#issuecomment-38535026
.

@bhollis
Copy link
Contributor

bhollis commented Mar 26, 2014

Here's another proposal, based off what Git does. We could check a MM_EDITOR environment variable and use that, then fall back to EDITOR, then raise an exception if that's not present. That avoids hardcoding vim, and gives users an option to set an editor specific to Middleman - so I could set it to open while others could use vim or notepad.exe or whatever.

@karlfreeman
Copy link
Contributor

@bhollis 👍.

@tdreyno
Copy link
Member

tdreyno commented Mar 26, 2014

👍 I think Sublime and Bundler follow this convention too.

@coveralls
Copy link

coveralls commented Jun 24, 2016

Coverage Status

Coverage decreased (-0.9%) to 93.617% when pulling 4ce6c51 on evaryont:edit-new-article into fe6f382 on middleman:master.

@nogweii
Copy link
Contributor Author

nogweii commented Jun 24, 2016

Wow, I lost track of this PR. Here it is, revivied.

I've implemented @bhollis suggested algorithim. It'll look for $MM_EDITOR and fall back to $EDITOR. If neither is set, it will suggest setting MM_EDITOR. All of this is opt-in, and if I got my ruby right, shouldn't change any current behaviours.

This fixes the call to the external editor to, as I copied the line from
my old revision of this change. The API has since changed in the
intervening 2 years, so update my code to match.
@coveralls
Copy link

coveralls commented Jun 24, 2016

Coverage Status

Coverage decreased (-1.3%) to 93.193% when pulling 7dd4b0b on evaryont:edit-new-article into fe6f382 on middleman:master.

@coveralls
Copy link

coveralls commented Jun 24, 2016

Coverage Status

Coverage decreased (-0.9%) to 93.617% when pulling 2d9147e on evaryont:edit-new-article into fe6f382 on middleman:master.

@tdreyno
Copy link
Member

tdreyno commented Jun 24, 2016

Wow, the 2 year old PR bump :) Awesome.

@tdreyno tdreyno merged commit 0c44ce0 into middleman:master Jun 24, 2016
@nogweii nogweii deleted the edit-new-article branch June 25, 2016 06:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Open new articles in the user's editor
6 participants