The warning that you did not save the changes in the file only happens when you
save as a csv file. THe csv file will _not_ contain all the formatting in th
ecurrent file.

When you open a csv file lots of formatting information is added depending on
the users preferences. All that information is not sqved when you save as a csv
file. So the warnings dialog is correct: those changes are not saved.

The argument that the formatting will be added again when the file is reopened
is only valid if it is the same user with the same preference settings.

Your explanation makes it seem like Gnumeric is either pointlessly nagging
and/or treating me like a moron.

I have just saved a file as CSV.
Therefore, I'm basically stating that I do *not* want any of the formating
information (which can't be expressed in a CSV).
Now, without changing the file Gnumeric complains that I haven't saved the
formatting (which I don't care, otherwise I wouldn't have saved as CSV)??

I don't care about the formatting. I don't want to see any errors due to the
fact that I haven't saved it, unless and until I have changed the file. Why is
this warning necessary (or useful)?

We aren't out to insult you.

Creating .csv files have two different uses:

1. "Export", that is to say mass-dump the values of a range into a text file.
   This is not unlike export to, say, LaTeX format.

2. "Save", i.e., a general-purpose (if severely restricted) spreadsheet
   language.

You're a "2" guy.  If we were to change Gnumeric as you wish, the "1" guys of
the world would lose a lot of data and would roast us over a slow fire.

I don't see us acting here unless someone can devise a plan that avoids data
loss.

I know you aren't out to insult me.
I apologise for that phrase.

How about having Gnumeric check what I will lose?

For each action, place it into general categories (such as "text","format",
"graphs", "functions" and so forth).
For each exporter, have a checklist of what it can and can't export.

Say something like a flat file that would look like this for CSV
text - 1
format - 0
graphs - 0
functions - 0
multiple_sheets - 0

I'm not sure about the functions, but you get the idea. This can also be useful
for status of exporters.

Now, when I export to CSV, Gnumeric can warn me that I'll lose Formating,
Graphs, and Functions.
(Perhaps this can be customized per spreadsheet - having a Details button which
will say "You will lose formating in all your cells, the graph at sheet 1, all
sheets except the present...")

If I choose to save as CSV, Gnumeric will take note of that.
Now, if I change any of the things that are lost without changing Text, or add
additional Text, Gnumeric should warn me again (that I need to save).

If I don't add anything, Gnumeric will consider everything saved.

Perhaps these two paragraphs would need Gnumeric to maintain a list of flags of
what has changed, and every action will belong to a category.
Something like:
Bold - Format
Graph Resize - Graph
Typing - Text
Insert Function - Functions

Activating Bold will turn the Format flag on.

I hope this is clear. If it isn't, I'll try to rephrase.

Will it lead to people losing information if they save as CSV and quit? Possibly
still, but (only) if they've changed the format, added graphs or functions on
their own (and Gnumeric should warn them).

*** Bug 354400 has been marked as a duplicate of this bug. ***

*** Bug 526051 has been marked as a duplicate of this bug. ***

--Quote by Andreas on duplicate bug--
But it is not the same spreadsheet! Your spreadsheet as it is open contains
lots of info that is not saved in the csv file (like all the formatting).

If we would silently default to saving as a csv because you happened to have
saved it as a csv file last time and so you loose all the fancy formatting you
may have added since that last save you may be (justifiable) upset.

--Reply--
@Andreas - hmm... But then the wording ("Save") is confusing. A better term
would be "Export". When you use Save, it is expected that all formatting
options are preserved, and thus the next save should be able to overwrite that.
Alternatively, you could do it like OpenOffice does: whenever saving in a
non-native format, add a warning that formatting might be lost and an option to
save it as a *.gnumeric file. You could then just let consecutive saves
overwrite the previous one, and when it is a non-native format, that warning
would pop up (of course, with an option to "Never show this again").

If I open a CSV in Gnumeric, make NO format changes (just add/delete text) and try to save, the Save As dialogue STILL appears. This does not fall under the following:

"But it is not the same spreadsheet! Your spreadsheet as it is open contains
lots of info that is not saved in the csv file (like all the formatting)".

Additionally, if formatting changes are made, and then I still want to save as CSV (e.g. I just resize columns to view the whole contents), I have to do Ctrl-S, select CSV and confirm overwrite. Why not ask:

"Formatting will be lost
"Save as other format/Save as CSV anyway"

Using the keyboard for the former:

Ctrl-S, Shift+Tab Tab Tab, Space, Arrow, Arrow, Enter, Tab, Tab, Space, Tab, Space => 13 keypresses

Using the keyboard for the latter:

Ctrl-S, Tab, Space => 3 keypresses

For the user who doesn't want to save as CSV and was unaware of the problem, there would  in theory be one extra click/keypress once (to confirm 'Save as other format'). Thereafter they would be able to use 'Save as' (possibly there could be a pointer to this option in the above warning), thus avoiding the extra step in future.

Everyone wins.

The moment you open/import a csv file lots of things happen. Dates are being interpreted, digit strings are being turned into numbers etc. So even if you actively don't do anything, the file that will be saved/exported will be different from the one you opened/imported.

What happens behind the scenes shouldn't be to the user; just the end result. Also, it could be argued that if I open a CSV and only add or delete data, Gnumeric shouldn't touch the format of other, unrelated cells.

Another option might be to offer the user the choice, either on a per-file basis or universally, about how to deal with CSV - edit in a CSV-compatible way or in a more complex way. Possibly warn if <<user-initiated>> changes cannot be saved.

I use Gnumeric all of the time. It is by far my favorite spreadsheet program. I have two primary usage patterns:

1) Creating actual spreadsheets, with embedded formulas, graphs, multiple sheets, etc....

2) Editing data sets for further processing by R (because editing .csv files in a text editor is painful).

This discussion largely has to do with the latter, and I have to agree with the original bug reporter and some of the other comments here. There are two problems: it doesn't remember my last save format was .csv (even if I opened a .csv file), and it pretends it didn't save when it actually did.

It is true that these are mostly nuisance issues and don't critically affect the program, but when you process 20 or 30 .csv files at a time, these kinds things can really start to irritate you. As for the loss of formatting issues, it isn't really any different from saving in any other non-Gnumeric format (or even something like Abiword saving your document as a text file). Give a warning to the user about the potential data loss, and that should be the end of it. There really shouldn't be a need to continually remind the user that they aren't saving in a rich spreadsheet format.

Another option is alluded to by Vincent is to just create an Export option (with a button in the toolbar) that is separate from the Save option. Inkscape does this for creating bitmaps of the current drawing, which I think makes it pretty clear that you are saving in a format that won't be editable by Inkscape.

Allow me to cast my vote in favor of an option to manipulate csv files and keep them as such with no prompting.

Here is my rationale (ahem, rant... my apologies in advance...):

I am a unix guy, and I download and manipulate A LOT of tab delimited files full of data.  I WILL NEVER store these as anything except text, because it then becomes (1) impossible to process them downstream with all the unix tools like sed, (2) it is hard/ impossible to read them as a person, (3) it becomes (unnecessarily) harder to write code to manipulate the data downstream (I personally hate XML crap in my code, ...), (4) tab delimited (with readable column headers and a comment syntax) works really well in 98% of the cases (the other 2% being naturally binary like images or shapefiles), (5) there is an equivalent to "readcsv()" in almost every data language on the planet, (6) I like to separate format from data, (7) etc, etc, etc

I avoid doing complex work in spreadsheets, since I think that is best done in either a matrix language like octave/ matlab/ R or by importing the data into a real database and using SQL.  I also avoid doing complex analysis in spreadsheets because I believe that readable code is orders of magnitude more scalable and maintainable than complex formulas embedded in spreadsheets (such things make my stomach hurt almost as much as XML). 

(Even if the XML format is open, using XML adds orders of magnitude of complexity and obfuscation for no real payoff most of the time.)

So what I often want is some software that can open a csv file, tweak it in a nice visualizable way, and save the result back into the csv file for downstream processing.  That's all. And I want to do that with as few clicks and B.S. as possible. Because I have to do it A LOT -- like 30 times a day sometimes.  

I like Gnumeric, and would love it if it had a checkbox in the preferences that allowed me to do that.  If I find a spreadsheet that does this, I will drop Gnumeric like a hot potato.

I also sometimes like to put in bold font and graphics and pivot tables.  But only sometimes, and never when I save something as csv.

Now, us Unix / data weenies are only a small minority of spreadsheet users, and maybe the appropriate design for 85% of Gnumeric users is the current approach.  So... perhaps the excellent hardworking maintainers could entertain the thought of letting us users take the safety off the footgun, if we know what we are doing?

I also realize that I could write this and add it to Gnumeric, but I am not that macho, and will probably at some point feel desperate enough to hack something out of Tcl/Tk and tktable....  Don't make me go there, please.... ;)

Sorry for the long rant:  I have been clicking "yes I know it won't save the format " idiot boxes in Excel for over ten years, and it still pisses me off. I expect better from open source, especially when there is a well articulated and reasonable need being expressed by users.

Fork.

*** Bug 627499 has been marked as a duplicate of this bug. ***

Honestly, this behavior would not bother me so much if I could just hit enter a few times.

i.e. process like this

1) $ gnumeric some.csv

2) edit CSV file

3) alt-f4 to exit

4) save dialog pops up

5) hit enter to save to same exact format as before

6) dialog pops up asking do you really want to save as a CSV as you'll lose data (again with the default as yes, so all I have to do is hit enter)

7) gnumeric exits

currently, gnumeric defaults it to .gnumeric file which doesn't do me any good if I want to save it to a CSV and requires me to take my hands off the keyboard and move the mouse (or do a lot of tab key pressing) to gingerly select the CSV output option.

and guess what, the steps I described above is how Excel works.

There is no good reason why gnumeric should assume that any file it opens should be converted to the gnumeric format. 

The lack of an easy save for other file types is like shooting yourself in the foot.

Whoever is responsible for ignoring this problem for 8 years must be a strange person.

I am starting to write by own little app to handle csv files... and only because gnumeric 
is so so so hard to save a file with. 

So much good work might as well be flushed down the drain with the save from hell.

There are lots of programs that can handle csv files. Apparently none handles it just the way you like. Please let us know when your program is available.

> There is no good reason why gnumeric should assume that any file it opens
> should be converted to the gnumeric format. 

Right.  And Gnumeric doesn't do that.

I am starting to think that the solution to this issue is to move csv (and
its friends tsv and txt) out of the open and save dialogs altogether.  All
import could go through the configurable text importer dialog.  Export could
be via print-to-file.

> Whoever is responsible for ignoring this problem for 8 years must be a strange
> person.

Yes, we're strange.  Aren't we all?

The strong advice is:

    ***********************************************
    *  Do not use CSV formats if at all possible  *
    ***********************************************

Note: this advice is not specific to Gnumeric.   Do not use Excel or OO for
csv either -- the problem is the format:

1. The format is incapable of storing most things a spreadsheet is about.
2. The format generally loses precision.
3. Different programs interpret them differently.  I know of no two programs
   that handle csv files identically.

Making people happy with csv handling requires mind reading.  We don't know
how to do that.   Experience shows that people who deal with csv files are
have very strong my-way-and-only-my-way-is-right beliefs.  Conflicting
beliefs, of course.

Consequently I do not intend to to any serious effort into csv handling
in Gnumeric.  If that means you can't use Gnumeric, well, sorry.

Created attachment 192437 [details] [review]
tentative patch re export versus save

The attached patch splits the save-as dialog into 2 parts:
1) a save-as dialog for the full file savers
2) an export dialog accessed through Data->Export (next to our existing Import from Text File) that lists the other file savers.

Splitting the dialog would ake it clear that there are 2 types of filesavers. Those that interact with spreadsheet files and those that are lossy exporters to some othe rfile format (html,...)

I can see in the future expanding the export dialog to let users select the sheets to be exported (depending on file saver).

Of course the same should probably happen with the file openers.

Looks good on visual inspection, but let's hold off on this until we
branch.  That'll be soon.

(In reply to comment #19)
> Looks good on visual inspection, but let's hold off on this until we
> branch.  That'll be soon.

Seem like the proposed patch would just make it harder use csv files.

For those who (must or like-to) use csv files gnumeric is a good app to use because it 
will open a csv without any dialog. Pop... it's there.  How nice, but then 
the save already wants too much attention.

Make save like the open only backwards. 

If someone is using a csv file and enters formulas, pictures, etc into 
their spreadsheet a mild warning would be more than sufficient. They 
must be someone eager to learn.

If I apologize for being rude would you just put and end to this dialog 
by removing save dialog...like you already removed the open dialog?

I understand that you want to protect the user from saving files incorrectly.

I just dont understand why you make it SO difficult to actually save CSV files some of us just find using gnumeric as being an easy way to handle CSV files.

Why not just do what Excel and OpenOffice do.  Warn the user when they try to save as CSV that a) only that sheet will be saved and b) formatting and formulas will be lost and give them the option to "save as" as a different format (but the default selection would be to save as is).

This way, all I'd have to do is 

ctrl-s (to initiate the save)
<enter> (to dismiss the warning dialog)

if I wanted to save as a different format, all I'd have to do is <tab> <enter> to select the other button (or use the mouse).

AFAIK, this is how Excel and OpenOffice work.

The question that has to be asked, do any users who use CSV files on a regular basis actually like the way Gnumeric deals with it?  If not (and I don't see anyone here who uses CSV's alot defending Gnumeric), you should ask how can we make this situation better instead of how can we make their lives more difficult.

@durable, 
I do not know what you are talking about. There is an open dialog and if you want to open a file you need to select the file via that dialog. (You can start gnumeric with a file on its command line, that is not affected by the patch.)

The patch is simply intended to clarify that you can export data to a csv file but that format is not a spreadsheet format. At some time we may have a "Repeat Export" option (see bug #594154), but that would require us to have the distinction between save and export that this patch creates.

@Shaya,
while it is nice to read that "some of us just find using gnumeric as being an easy way to handle CSV files" the csv file handling causes the most complaints from users since every user seems to want it done differently. 

Regarding your question "do any users who use CSV files on a regular
basis actually like the way Gnumeric deals with it", the answer is yes. About half the files I open are csv or text files.

Created attachment 192529 [details] [review]
expanded patch to also separate open and import

This patch incorporates the previous patch and also separates open and import (matching the save/export separation).

Created attachment 192532 [details] [review]
expanded patch

This patch changes the Data->Export into a submenu. This will allow users with an attachment to csv files to export an imported csv file by just using the keyboard (alt-d x c enter enter)

Created attachment 192596 [details] [review]
slightly further expanded patch

This patch also has the workbook remember the last export (during a session) and the import format. This could simplify working with cvs files slightly.

The patches have been committed. I am closing this bug as INVALID since you now cannot "save" as csv anymore so the report does not apply. You can more easily reexport as a csv file (using only key strokes) so the spirit of the bug report has been addressed.