Headers buffer

[adimit]

This is a rough draft of the edit headers functionality (#41) for UX testing. The buffer can be opened with graphql-edit-headers, which I have not bound yet. Some things I'd like to still explore:

• [x] Should we check for .graphqlconfig and do a completing read on the endpoints before opening the buffer? Then add the content for the headers from the endpoint.
• [x] Should the buffer contents override graphql-extra-headers when the buffer is currently open? This may be confusing if the buffer is currently invisible.
• [x] I'd like to name the buffer somewhat better, using the parent buffer's unique name. I'll look into that.
• [x] Reuse any existing buffer of the same name? I.e. if the user navigates away from the transient buffer, then goes back to the graphql file and uses graphql-edit-headers again?
• [x] What's a good default keybinding? I use Evil, so I have no idea how Emacs-world comes up with key bindings :laughing:
• [x] Needs documentation, at least in the readme

All the good bits here are directly nicked from org-src.el :stuck_out_tongue_closed_eyes:

I don't think we need completion. Content-Type is set, so we don't need MIME-types. The common header names are not terribly interesting. I mean, it's almost always going to be some variant of Authorization plus whatever else your endpoint requires, which may be pretty arbitrary.

[davazp]

Looks great!

Should we check for .graphqlconfig and do a completing read on the endpoints before opening the buffer? Then add the content for the headers from the endpoint.

I think it would be better to just edit the variable. You can always do C-c C-l before to load the file if you want to.

Should the buffer contents override graphql-extra-headers when the buffer is currently open? This may be confusing if the buffer is currently invisible.

I'm not sure if I understand. Do you mean changing the variable when opening the mode? I would keep them untouched until C-c C-c on the buffer.

Reuse any existing buffer of the same name? I.e. if the user navigates away from the transient buffer, then goes back to the graphql file and uses graphql-edit-headers again?

I'm not sure what is the common convention here. Maybe we can copy a bit more from org-src.el 😄

What's a good default keybinding? I use Evil, so I have no idea how Emacs-world comes up with key bindings 😆

Hm, it's a bit long but I would propose C-c e h could be nice. e from edit. h for headers. That way we extend it naturally for variables and other parameters. And it would work nicely with things like C-c e ? for help. Another option would be just C-c v / C-c C-v.

[adimit]

Thanks for your feedback! I've added the following changes:

• We'll refuse to open the buffer if not already graphql-mode (it makes no sense to edit the headers elsewhere)
• The buffer is always reused and only populated with graphql-extra-headers if it was empty before. org-src.el queries the user, but I think this is a simple enough use case to just dwim
• I added a bit of general documentation on how to query to the readme, including how to edit the headers
• The key binding for editing headers is now C-c e h, as you suggested

[adimit]

I'm not sure if I understand. Do you mean changing the variable when opening the mode? I would keep them untouched until C-c C-c on the buffer.

What I meant is that you could keep the buffer open while sending the request and didn't need to close it to save the variable. But I think if that is desired, and explicit saving function could be introduced.

I think for the feature as it stands the current behaviour is sufficient. When we add the edit variables functionality, we'll have to see how it feels.

[davazp]

Very nice. Great work! I'll give it a try later today.

[adimit]

Hey @davazp, is there anything else I could do here, or do you think it's done?

[davazp]

Sorry I forgot to merge! I looks good. Thanks!