-
Notifications
You must be signed in to change notification settings - Fork 22k
Added --editor (-e) option to open generated files in the user's editor #32996
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
Conversation
d7139f1
to
1294857
Compare
20dd022
to
8900c4e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice idea!
|
||
module Rails | ||
module Generators | ||
module PrimaryFileHelpers # :nodoc: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
extend ActiveSupport::Concern
?
template "controller.rb", File.join("app/controllers", class_path, "#{file_name}_controller.rb") | ||
destination = File.join("app/controllers", class_path, "#{file_name}_controller.rb") | ||
template "controller.rb", destination | ||
primary_file(destination) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This obstructs the flow a bit too much for me.
How about adding a primary_template
method? Or overriding template
so we can pass a primary_file: true
option?
Or perhaps primary_file
can just return the destination. So we can do template "controller.rb", primary_file(File.join(…))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to open multiple files in the editor too? It might be nice to open the whole shebang after a scaffold generator has run for instance.
Then it could make sense for template
to collect files to open after the generator has finished.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That it depends on the editor whether or not can open multiple files (I'm not sure if it is possible with an editor without tab functions)
It is difficult to check the operation with various editors, so I would like to avoid supporting it.
template "controller.rb", primary_file(File.join(…))
seems nice. I will update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My bad. In order to generate a file, need to run template
first. So template "controller.rb", primary_file(File.join(…))
does not work.
Instead, I added the primary_template
method.
|
||
def primary_file? | ||
shell.base.class.to_s == "Rails::Generators::MigrationGenerator" | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand how these primary_file?
checks work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This generator will be triggered from Rails::Generators::MigrationGenerator
, so this check works(Does this make the answer as expected...?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand what you mean. Can you give an example of the complete code flow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps it's just because I don't understand what shell
or shell.base
is here.
def self.included(base) | ||
base.class_option :editor, type: :string, aliases: "-e", lazy_default: ENV["EDITOR"], | ||
required: false, banner: "editor", | ||
desc: "Open generated primary file in the specified editor (Default: $EDITOR)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What type of generators can't support the --editor option?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For example, it can not support scaffold generator which can not decide primary file.
f125234
to
c422c20
Compare
This is a retry of rails#8553. Added support for generators added later from the original PR, and extract the function on the primary file into method. Also avoied adding the `editor` option to `Generators::Base`. If add it to `Generators::Base`, `editor` option will be output to the help of generator which does not support it. This confuses the user.
c422c20
to
d9118db
Compare
included do | ||
class_option :editor, type: :string, aliases: "-e", lazy_default: ENV["EDITOR"], | ||
required: false, banner: "editor", | ||
desc: "Open generated primary file in the specified editor (Default: $EDITOR)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this really be an --editor
option or a --edit
option? Because we don't allow editor customization for the credentials:edit
or secrets:edit
commands, there $EDITOR
is assumed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we indent arguments like this. I'd just do:
class_option :editor, type: :string, …
required: false, …
end | ||
|
||
def primary_file? | ||
self.instance_of?(shell.base.class) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could remove the self.
here.
included do | ||
class_option :editor, type: :string, aliases: "-e", lazy_default: ENV["EDITOR"], | ||
required: false, banner: "editor", | ||
desc: "Open generated primary file in the specified editor (Default: $EDITOR)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we indent arguments like this. I'd just do:
class_option :editor, type: :string, …
required: false, …
def primary_template(source, destination) | ||
template(source, destination) | ||
primary_file(destination) | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think this makes more sense in the PrimaryFileHelpers
module.
|
||
module Rails | ||
module Generators | ||
module PrimaryFileHelpers # :nodoc: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious about the naming choice here by the way. Why the word primary
? Since there's only ever one file that's editable — and thus no secondary
files — what makes it primary? Especially when this adds an editor
option and not a primary_file
option?
How about Rails::Generators::TemplateEditing
which overrides template
to support an edit: true
option?
end | ||
end | ||
end | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dig all these tests 😍
|
||
def primary_file? | ||
shell.base.class.to_s == "Rails::Generators::MigrationGenerator" | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps it's just because I don't understand what shell
or shell.base
is here.
@y-yagi I just had a use for this, are you interested in picking it up again or do you want me or someone else to take over? It'd be really cool to have in 6.1 ✌️ |
Ya, I'm still interested in this. But I have another idea related to this. I'd like to think about what to do with this, so please wait ;) |
Sounds great! 😄 |
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
@y-yagi did you get to attempt the other idea? |
Sorry for the late action. I plan to provide a callback to perform processing on the generated file after the file is generated(The callback will support file operations in the editor and execution of But still working on it. y-yagi@0470943 I am going to finish this in the new year holidays. |
Cool, interesting 😊 |
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
@y-yagi this would be really helpful for me (and I was thinking about similar idea few times already) for generated migrations. I was looking at master...y-yagi:add_after_generate. Is there still any plan from your side for this? Is there anything I can help you with? |
@simi I think this has utility enough that 2 people can work on it — as long as you don’t erase credit. Base your work on the commit in that branch, get it rebased, flesh it out more and check allow edits from maintainers on the PR. Then @y-yagi will have an easier time wrapping it up if he has time to jump in or we can wrap it up if you make progress on it 👌 |
@y-yagi looking in there. Thanks for info. |
This is a retry of #8553.
Added support for generators added later from the original PR, and extract the function on the primary file into method.
Also avoied adding the
editor
option toGenerators::Base
.If add it to
Generators::Base
,editor
option will be output to the help of generator which does not support it. This confuses the user.