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

[Feature]: diable auto add header temporarily #73

Open
gzqx opened this issue Dec 6, 2019 · 1 comment
Open

[Feature]: diable auto add header temporarily #73

gzqx opened this issue Dec 6, 2019 · 1 comment

Comments

@gzqx
Copy link

gzqx commented Dec 6, 2019

I am wondering whether the plugin can provide a command to temporarily disable auto add header for this buffer.
Could be useful when editing small files that will be placed at places that won't prefer a header, like latex or ppt.

@samerickson
Copy link
Contributor

I was thinking about this as well. This plugin saves me time overall, though, I have found that I do not need/want it more often than I do. The solution to this was to set the following option accordingly.

let g:header_auto_add_header = 0

The problem

The problem here is that I often forget that I have this plugin installed and end up writing headers by hand when I want them in a specific file. Another thing I noticed, when g:header_auto_add_header = 0 the timestamps on existing headers do not automatically update on close, which makes sense when you look at how the timestamps are implemented in the source code (It's done by calling :AddHeader on file save, which is smart because that is more or less what you want to do).

Technically the [Feature:] you are requesting is already implemented. There is a:

command to temporarily disable auto-add header for this buffer

There is no issue with the way it is implemented other than laziness of us users, we don't want to have to manually enable and disable the auto-add-header feature in our .vimrc dependant on when we want to use it. That said there are alternate ways to implement this in a more automatic feeling way.

Possible solutions

Given that the implementation itself is present already, it doesn't make a lot of sense to modify the project itself. I thought about maybe adding the functionality to check if a header is currently present on save; if it is, update it; if it is not, do nothing; then you could manually add the header when you want them and they would be automatically updated when the file is changed, but while thinking about it I cam up with a few alternate solutions. That said here are a few solutions I have come up with:

  1. Add auto-cmd cases for specific filetypes in your .vimrc to run AddHeader on the creation of files with specific extentions. There will still be the occasional situation where this ends up being wrong, but at least you can minimize the number of times you need to manually add/remove headers.
    Implementation:
    Add the following to your .vimrc:
    let g:header_auto_add_header = 0

    " Add all file extensions that you want the headers to be auto-added
    autocmd BufRead,BufNewFile *.sh,*.cpp,*.h,*hpp :AddHeader
  1. Add the headers manually and don't use the modified time module. Given that the places where a date last modified are valuable/required, you are likely using git, which will keep track of all that information for you (and a whole lot more). In my experience when I actually want to know this information about a file, the last place I check is in the actual file header, under the basis that not everyone uses headers, therefore using ls of git is the only way to guarantee to get that information. I, like many other people, save every file I open before closing it. That means that every time you save a file, :AddHeader is being run, which means that the "Last Modified Date:" is being updated even if no actual changes were made.

  2. Create a vim function that checks for the "Last Modified Date" line and updates that to the current date on file save.

  3. Remember to manually run :AddHeader each time a change is made.

Conclusion

The correct solution heavily depends on your personal preference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants