Skip to content

Feature: command(s) for inserting/deleting #_ ignore forms #567

New issue

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

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

Already on GitHub? # to your account

Closed
yuhan0 opened this issue Apr 25, 2020 · 5 comments · Fixed by #583
Closed

Feature: command(s) for inserting/deleting #_ ignore forms #567

yuhan0 opened this issue Apr 25, 2020 · 5 comments · Fixed by #583

Comments

@yuhan0
Copy link
Contributor

yuhan0 commented Apr 25, 2020

It would be useful to have some convenient way of inserting/deleting #_ forms built into clojure-mode, but its implementation may depend on personal preference. I hope this issue attracts some discussion as to what would suit the majority of users.

My personal implementation of this idea can be found here, which I've been tweaking over the past year: https://gist.github.com/yuhan0/38ac43c764017917fc3f3e5dc9104f1b
There are two interactive commands defined there, clojure-toggle-ignore-form and clojure-toggle-ignore-surrounding-form- see docstrings for their usage.

I made some usability choices in the way it interprets numeric and universal arguments, and there's some degree of DWIM by wrapping an active region in (comment) forms and inserting blank lines before top-level forms to reduce diffs.

But it's clear that this may not suit everyone, in particular see
https://github.com/dotemacs/clojure-comment-dwim.el/issues which takes a more DWIM approach with a single entry point and more logic to determine what the command should do in different contexts and when repeatedly called.

See also BetterThanTomorrow/calva#505
for another interpretation of what such a command may do in different scenarios (note it's more selection-based as VSCode doesn't have numeric command arguments)

@bbatsov
Copy link
Member

bbatsov commented Apr 25, 2020

I'm fine with adding something along those lines. My preference would be to have something operating on the current top-level form and the current/preceding form. I'm fine with a toggling behaviour for those commands. As for regions - I'm not sure they make a lot of sense for a command of that nature, you might not have selected a complete form.

@dotemacs
Copy link

My thinking is that since we're using s-expressions, we can be smart about it, the way paredit & smartparens modes are about navigation, slurping, barfing and so on, but in regards to commenting.

My preference would be to have something operating on the current top-level form and the current/preceding form.

I've already got that implemented.

For example, I handle commenting out the current s-expression, or with a prefix argument, PREFIX s-expressions above.

I'm fine with a toggling behaviour for those commands.

Cool, I've got that in too.

As for regions - I'm not sure they make a lot of sense for a command of that nature, you might not have selected a complete form.

I handle that also.

For example, if you've selected a whole s-expression, as a region, then the mode would comment it out with a #_ at the start of the selected region. But if your selected region is not a s-expression, then it would wrap the region in (comment ...).

It also toggles (un)commenting, depending on how is the particular point/region (un)commented.

I tried to get some clarification on the current behaviour here: dotemacs/clojure-comment-dwim.el#2

See the master branch of: https://github.com/dotemacs/clojure-comment-dwim.el

@andreyorst
Copy link
Contributor

Isn't this a duplicate of #411 ?

@yuhan0
Copy link
Contributor Author

yuhan0 commented Feb 18, 2021

I'll submit a PR with my above code, removing the (comment behaviour on regions and adding an additional command clojure-toggle-ignore-defun for top-levvel forms, hope that's ok!

@bbatsov
Copy link
Member

bbatsov commented Feb 18, 2021

Yep, that's fine.

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants