Hello,
Aseprite doesn’t remember my choice for “Not visible Grid” in new documents 
It usually checks that checkbox again and again, no matter how many times I uncheck it (it does it usually when I restart the program). Its really frustrating ^^U
I’m on Windows 7 64-bits, and my aseprite version is: 
That’s strange, I’m testing here (but on macOS) and it does work 
I’ll give a try next week on Windows. At the moment, could you please check your aseprite.ini file inside your configuration folder and see if you have this [show] section with grid = false:
[show]
grid = false
And that you don’t have:
[grid]
visible = true
if you have that one, remove the visible = true line.
Thanks for the help! 
I have checked aseprite.ini inside of my AppData /Roaming/Aseprite but I didn’t have
[grid]
visible = true
I had only the other two lines.
I’m thinking that maybe the problem could be that I have several Aseprites installed, is that possible? (in the past I had to install several versions at the same time, because some of the old versions didn’t have some bugs that the actual ones had).
I have (at least) these versions installed:
Still, is very strange, because (to my knowledge at least) I always open the Steam version (using a shortcut icon on my taskbar, so I don’t need to open Steam each time I want to use Aseprite), so the preferences file should be located at the same place, isn’t that right?
Are there other places where the preferences file could be located? If so please tell me and I’ll try to search & delete them, just in case.
Edit: Just to clarify, the problem happens sometimes, I still haven’t been able to locate the exact moments, and right now I couldn’t replicate the problem ^^U
If you are using portable versions of Aseprite, there might be an aseprite.ini file in the same location the portable aseprite.exe file is. You should check those aseprite.ini file too (if you remove the aseprite.ini file, it will use the one from AppData).
It might be related to the different versions. I don’t remember when I changed from [grid] visible to [show] grid, but if newer versions find [grid] visible=true then it will migrate the setting to [show] grid=true and remove the [grid] visible. But [grid] visible=true should appear only if you set the property from an old version.
Thank you very much, I’ll check those .ini files
I’ve deleted all the portable aseprites and its .ini files, but the grid appeared again ^^U
I’m using now only the last Steam version (v1.2.12.1-x64), is possible that the bug is caused by the file “pref.xml”?
I’ve found the following (suspicious) line:
<option id="grid" type="bool" default="false" migrate="grid.visible" />
I’ll try to change it to something like:
<option id="grid" type="bool" default="false" migrate="grid.invisible" />
Or:
<option id="grid" type="bool" default="false" migrate="grid.transparent" />
Or something else. Please tell me if you know the correct one XD
The pref.xml file is not used on runtime so it doesn’t affect the execution if you modify those values there.
I’m not sure what could be happening, I’ll take note about it if I can reproduce it just in case.
I just want to add a +1 to this on windows. I’m not sure what causes it but this setting appears to toggle itself on regularly. I never turn it on myself, yet have made a habit of “ctrl+h” whenever I open documents to get rid of the grid.
It’s not every time, but often enough, and will persist for multiple documents that I open in the same session.
Currently using the steam version of Aseprite, latest build with beta enabled. I remember this issue also existing in previous versions of the app.
I might have found something related to this bug.
tl;dr version: In Aseprite v1.2.16 we’ll simplify the behavior of default docs settings: if there exists a .ini file storing the preferences of a sprite (in the preferences folder / files/ … .ini location), the defaults settings for that sprite are not modified.
Long version: If the global setting for the visible grid are changed (e.g. View > Show > Grid menu option is selected when there is no document opened), then that change could set the default of the other sprites (even when the sprites were already opened in the past so they have their own preferences set). This is more visible in the File > Export Sprite Sheet preferences, e.g. if we create a new sprite, export a sprite sheet from it with the “Trim” option checked, that option is saved as the default option for future files, but if we open an old file that we’ve exported but it doesn’t specify the “trim” option (not false nor true), the new default will be copied, so the trim option will be enabled for a sprite that was exported in the past with the trim option unchecked.
This was found with a re-design of the Export Sprite Sheet dialog and thanks to @KashouC for reporting the bug 
and I guess it’s related to this bug too.
Commit fixing this (supposedly): Don't set preferences with latest defaults if there is an existent .i… · aseprite/aseprite@002abc9 · GitHub
So the fix in v1.2.16 caused more problems. Now I’ve fixed these problems (to be released in v1.2.16.3) but I might have found the cause of the original issue in this thread.
I’ve created a test case, where it shows a possible problem (this line):
Answer: As we never specified the grid size, the saved preferences for the given sprite will not contain the grid size (now .aseprite format can contain the grid size, but imagine that we’ve saved the sprite in a .png file, so this information was lost), the sprite is expected to use the default grid size. So if we change the default grid size, after re-opening the sprite we will see the new grid size (and not the grid size visible when the sprie was saved).
This situation is a little complex, but maybe there are some parameters that should be saved “as a group”. For example: the grid or the background settings. If you change one parameter that makes the whole thing (e.g. the grid) visible in certain way, I think all values should be saved in the preferences (in this case, if we make the grid visible for a specific sprite, we should save all grid parameters, size and color, etc. for that sprite, not only the changed values; the same should be true for the background configuration, changing just one parameter should save all parameters of the background).
What do you think about this?
I think storing Aseprite specific settings should, or could, be limited to the .aseprite file format. (project file vs image file)
And yeah, I’m not 100% sure what you mean, or with “as a group” I think, but I do think if we’re working with an .aseprite file settings should be saved. Grid size, background color, background grid size, what have you. Personally I don’t feel like it’s necessary to store all that kind of data for .pngs as they are generally the end product used for importing somewhere instead of something you actually work on. At least from my perspective. I also think default settings should be saved to the file right away and not just after they’re altered. Because otherwise, what if you have it set to what you thought it should be as default, then change the default later, and come back and then its now wrong in your old file because it didn’t get saved?
Hope it makes sense.
Hi! 
I’ve been thinking about this for the last couple of days, and I’ve rewritten this several times so I hope it makes sense XD
One option would be as @dacap said, saving certain small groups of parameters related to a functionality (for example, the “grid group” would save grid size, grid offset, snap to grid and grid visibility), and a second option could be using all the workspace configurations as a whole (although to tell you the truth I’m not sure of which parameters should be grouped here, and maybe it’s more complicated for users and also for development).
Now I’ll try to explain what I think that would be optimal behaviour, using a group of parameters, for “Grid Configuration”:
What do you think?