The CSV import dialog is redundant and adds an extra step to open a file for users who work with the same types of CSVs that have identical delimiters and charsets.
Microsoft Excel opens CSV files silently. The issue of different delimiters/charsets is handled by using delimiters that are common in the user's country. For example, the U.S. version of Excel will use commas by default, and some European versions of Excel will use semicolons.
I suggest that LibreOffice adds an option for the user to select his or her own defaults when opening CSV files.
I would go even further by separating the Open and Import options for CSV files. The double-click or File=>Open... menu would open the CSV file silently with the default options applied while File=>Import... would allow to change delimiters and character sets.
Operating System: All
Version: 18.104.22.168 release
thanks for writing and your interest in LibreOffice. However...
(In reply to comment #0)
> The CSV import dialog is redundant and adds an extra step to open a file for
> users who work with the same types of CSVs that have identical delimiters
> and charsets.
It remembers the last choice. so Enter (OK) is enough.
> Microsoft Excel opens CSV files silently. The issue of different
> delimiters/charsets is handled by using delimiters that are common in the
> user's country. For example, the U.S. version of Excel will use commas by
> default, and some European versions of Excel will use semicolons.
What a pitiful limitation :(
> I suggest that LibreOffice adds an option for the user to select his or her
> own defaults when opening CSV files.
Could be done of course, but then when a non default setting is imported, the current window is necessary too. And as written, the setting last done is the default one..
So I will close this as WorksForMe. But of course if there are realy strong arguments that I've missed, pls report.
> It remembers the last choice. so Enter (OK) is enough.
I'm not sure what you mean by "enough." It requires you to do that for every CSV file that you ever open. For people who opens lots of CSV files every day, this really adds up.
> What a pitiful limitation :(
Bashing Microsoft is always fun, but what's more pitiful is putting down a competing product instead of actually addressing the issue. Please stop antagonizing users of commercial software who look to switch to open-source alternatives.
> but then when a non default setting is imported, the current window is necessary too.
That's why I proposed the Open and Import functions for CSV files. Open would use the default settings and Import would bring up a dialog.
Why can't we save the settings for a file type?
I'd like csv's to always be one way without the dialog all the time.
It would be nice if we could save the settings with the dialog for file types or go to the settings somewhere to setup for cvs to use these settings for txt files always ask maybe create a bunch of our own filetypes and set them up with the different import options.
(In reply to Jeff Sadowski from comment #3)
> Why can't we save the settings for a file type?
Because not every csv that people import, has the same format.
> I'd like csv's to always be one way without the dialog all the time.
Then there need to be something as
> Insert > Sheet from File
> Sheet from File with previous Settings
(In reply to Cor Nouws from comment #4)
> (In reply to Jeff Sadowski from comment #3)
> > Why can't we save the settings for a file type?
> Because not every csv that people import, has the same format.
I understand that is why I ask for an option in the settings. To select whether or not we get the dialog.
> > I'd like csv's to always be one way without the dialog all the time.
> Then there need to be something as
> > Insert > Sheet from File
> > Sheet from File with previous Settings
Not sure what you are asking here.
If there where command line options to select the input filter options we could add it ourselves how we want it.
example of what I would like:
scalc.exe --character-set="Western Europe (Windows-1252/WinLatin 1)" --language=Default --seperated-by="tab,comma,semicolon" --text-delimiter="\"" myfile.csv
Latin 3 (ISO-8859-3)
Western Europe (Windows-1252/WinLatin 1)
(comma separated list of the following use --seperated-by-other= for other charaters --sererated-by-fix-with= for fixed width)
(In reply to Jeff Sadowski from comment #5)
> I understand that is why I ask for an option in the settings. To select
> whether or not we get the dialog.
Sorry, but it was not clear to me that you wanted a setting - not only reuse settings ;)
> > > I'd like csv's to always be one way without the dialog all the time.
> > Then there need to be something as
> > > Insert > Sheet from File
> > > Sheet from File with previous Settings
> > ?
> Not sure what you are asking here.
If you do it with a global setting, indeed you don't need an extra menu entry.
> If there where command line options to select the input filter options we
> could add it ourselves how we want it.
> example of what I would like:
OK, so command line option to use various settings for various file types according to your like, and then then menu Import > Sheet from file as we know it now?
(In reply to Cor Nouws from comment #6)
> (In reply to Jeff Sadowski from comment #5)
> > I understand that is why I ask for an option in the settings. To select
> > whether or not we get the dialog.
> Sorry, but it was not clear to me that you wanted a setting - not only reuse
> settings ;)
> > > > I'd like csv's to always be one way without the dialog all the time.
> > >
> > > Then there need to be something as
> > > > Insert > Sheet from File
> > > > Sheet from File with previous Settings
> > > ?
> > Not sure what you are asking here.
> If you do it with a global setting, indeed you don't need an extra menu
> > If there where command line options to select the input filter options we
> > could add it ourselves how we want it.
> > example of what I would like:
> > [...]
> OK, so command line option to use various settings for various file types
> according to your like, and then then menu Import > Sheet from file as we
> know it now?
That would make me happy and I'm sure I could explain to others how to set it up.
This should not be marked resolved. The program behaviour ignores a significant use case.
The use case ignored is where an office has a program which generates many csv files per day, which need to be opened in Calc. I work in such an office now and have at another in the past.
For such a use case, Calc is seriously deficient, particularly compared with Excel. The deficiency is worse than Knocks has described, partly because of another closely related bug/misfeature, which I am about to report.
Right click on file and select 'Open With... Calc'.
EXPECTED/HOPED FOR BEHAVIOUR ON FIRST USE
(whether Calc already running or not)
Calc opens a new window on top of all other windows, and over this new window opens its CSV settings dialog. The dialog has an option to save the settings chosen. When the dialog is closed, Calc opens the CSV in the same new window.
EXPECTED/HOPED FOR BEHAVIOUR ON SUBSEQUENT USES
Calc opens the CSV in a new window on top of all other windows, using the previously saved CSV settings. (There would need to be an option in Calc's general preferences to change CSV import settings.)
ACTUAL BEHAVIOUR IF CALC IS NOT RUNNING
As hoped for except that there is a CSV settings dialog to dismiss every time.
ACTUAL BEHAVIOUR IF CALC IS ALREADY RUNNING
Calc opens its CSV settings dialog over an existing window, which may be deeply buried. It does not bring that window or the dialog to the top. Once the user has manually brought that window to the top, and dismissed the dialog, it opens the CSV in a new window (not the window over which the dialog was opened).
Found the other bug has already been reported many times. Added a link.
Same applies to HTML imports.
Should another bug be raised for that?
I'm hoping to reopen this as something the developers will look into as it is the main issue keeping me from using Calc instead of Excel. I also have to open multiple CSV files every day. Each time I open one, not only do I get the dialog box, but it appears behind the active window. So, to open a CSV file, I have to double-click it, move my cursor to the taskbar and click the dialog box, then click "OK" from within the dialog box. This doesn't sound like much until you have to open a few dozen CSV files every day and have to jump through these hoops each time. When I set Excel as the default program, the files open automatically. It is incredibly frustrating.
Please just add a simple option to set a default that Calc remembers. I shouldn't have to do four mouse clicks to open a file.
I would also like for this issue to be addressed. My job involves opening dozens of CSV files every day (sometimes hundreds, depending on the current project I'm working on), and as all of them are comma-delimited, it is incredibly time-consuming and inconvenient to go through the dialogue box every time I open a CSV file.
In this issue, various ideas are mentioned.
a) two menu options:
Import file (with dialog)
Import file directly (and use default settings, i.e. settings that were kept from lat time the import dialog)
b) command line options.
So I suggest to make this issue represent a. and that e.g Jeff creates the issue for b.
I m facing the same issue, have tons of CVS files generate by a internal website we use at the company. The final user manually open the CVS reports but it s annoying getting the same dialog asking the same question always, and worse people sometimes before accept the default config like to play around with the options and mess up the results
Having the possibility to set a default option somewhere in the settings will dramatically reduce people opening IT tickets and asking why their reports are broken.
(In reply to Pablo Frias from comment #14)
> I m facing the same issue, have tons of CVS files generate by a internal
I very well understand your point and understand it's annoying for your colleagues.
You may consider to take the lead and see if you can get a developer working on it. Maybe it's not too hard?
See http://www.libreoffice.org/get-help/professional-support/ for people you may ask.
I want this too.
This is now 2 1/2 years old.
It doesn't seem that tough, but what do I know.
How about a -NocsvDialog option. If something screws up, then put up a warning
and/or the 'Text Import' dialog.
Dear Bug Submitter,
This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INSUFFICIENTDATA
due to lack of needed information.
For more information about our NEEDINFO policy please read the
wiki located here:
If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
Thank you for helping us make LibreOffice even better for everyone!
Dear Bug Submitter,
Please read this message in its entirety before proceeding.
Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):
a) Provide details of your system including your operating
system and the latest version of LibreOffice that you have
confirmed the bug to be present
b) Provide easy to reproduce steps – the simpler the better
c) Provide any test case(s) which will help us confirm the problem
d) Provide screenshots of the problem if you think it might help
e) Read all comments and provide any requested information
Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:
a) respond via email
b) update the version field in the bug or any of the other details
on the top section of our bug tracker
imo this can still be open as an enhancement.. not?
despite no reply came on the question/suggestion in comment #13
This does seem like an obvious and easy problem to resolve--as stated above, and elsewhere, simply create an option to open with whatever default character set the user has chosen--that's what options are for, rather than forcing the user to constantly specify all of the hundreds of "possible variations" we run into, have the program try a simple resolution, which is what all software does. I uninstalled OpenOffice because of this and similar problems, hoping LibreOffice would have used some common sense resolutions, but clearly not. After years of having to use OpenOffice to open dbf files for QuantumGIS, and always getting the same stupid prompt for every file I have to open, I have never once had to do anything other than simply hit the enter button. Its is patronizing and dismissive to respond "it's only one extra click" or "deal with it" when it's such a simple fix.
This is plain stupid. That's why free software is doomed. Every user says: "just do the same thing that successful MS Excel did long ago", and every free developer says: "that won't work".
I'd like dev input, but believe a parsing filter set from the CSV input dialog will always be necessary to assure correct data type handling. End of story.
However, the nuisance to users is that there is no means to capture/reapply the CSV filter, and they must repeatedly work through the dialog, even if defaults are correct. More so if they have a fairly complex CSV file that requires data type settings on multiple columns.
Seems there should be a means to capture the parsing/formatting filter for reuse against _recurring_ CSV files, even in multiple LO sessions--so filter(s) would need to be held in user profile.
Then adding an option to by-pass the dialog popup (for GUI use) when applying that filter from profile would be reasonable. And probably would want something for use with CLI conversions.
As already mentioned in comment 1 the settings meanwhile are remembered and, except the column types, presented as pre-set for the next open. An extra "open bypassing the dialog" option IMHO just adds confusion when things go wrong, and the user will have to differentiate or select that somehow which is more work than just hitting Enter for OK. YMMV though and some may prefer an extra menu entry or some such, I don't know. For me it's unnecessary.
And as others have mentioned above, Excel does this right. LibreOffice does it wrong and is user-hostile. I opened this ticket 4 years ago and have since moved to a different industry that no longer requires opening lots of CSV files daily. But I do remember uninstalling LibreOffice and feeling great about it, because of how stubborn and unwilling to consider the user experience its developers are.
Suggest discussing at UX-meeting.
Just hitting "Enter" is enough.
One might expect that the regular csv-openers will understand that soon enough.
Also looking at Eike's advice, my suggestions is: Close as NOTABUG.
(In reply to Knocks from comment #25)
> And as others have mentioned above, Excel does this right. LibreOffice does
> it wrong and is user-hostile.
I have to contradict, sorry. :)
Sometimes I work with CSV files from different sources. There is one thing that should be understood clearly. CSV is not a file format. It is an extension which people use for different formats.
Literally it means _Comma_ Separated Values but the same extension is used for tab-separated, semicolon-separated and other file formats. Sometime windows-line-endings are used, sometimes not.
You simply cannot rely solely on the extension to guess how you should interpret the content of a file. That's the reason why two technics can be used:
1. heuristics, that try to make smart guesses how to understand files. It mostly works but sometimes not. This is what Excel does and if it fails then you have no chance to convice it to think differently. (I hate it if this comes up. :))
2. user interaction, when I can configure each nuances of the content interpretation.
I think LO does the correct way: make a reasonable guess and then asks the user whether they confirm or not. This should not be changed.
A small feature we could do is, however, to introduce a new setting under Preferences => LibreOffice Calc => Import (doesn't exist yet).
On this page, each file extension could have a separate section, currently only CSV would exist there. The CSV section should have the following settings:
( ) Apply smart guess
(O) Use the most recent settings
[X] let the user to confirm/change the proposal
With this, the use can toggle whether they want to confirm each dialog or just trust the system, plus could tell they want to use the heuristics or simply just use the latest one.
It would be even better in the future if the heuristic would be pluginable: some users would write smart code that recognise which software created that particular CSV, and so on. It would go far beyond the topic of this ticket but the perspective is quite interesting, I think.
At the moment, I would just stick with the two radio buttons and one checkbox I detailed above.
In reply to firstname.lastname@example.org (Comment #27)
> currently only CSV would exist there
The same issue exists with HTML. (As mentioned above at Comment #10.) If csongor's solution is chosen, then a separate task probably needs to be raised for an HTML section in the new preference settings page.
The HTML import dialog is simpler than the CSV one because the HTML format contains more column format information, and the same will apply to its preferences section. But there is an import dialog, so the basic issue is the same.
(In reply to Gareth from comment #28)
> The same issue exists with HTML. (As mentioned above at Comment #10.) If
> csongor's solution is chosen, then a separate task probably needs to be
> raised for an HTML section in the new preference settings page.
An HTML import uses the generic textimportoptions.ui; CSV is textimportcsv.ui completely different GUI and data handling.
> The HTML import dialog is simpler than the CSV one because the HTML format
> contains more column format information, and the same will apply to its
> preferences section. But there is an import dialog, so the basic issue is
> the same.
Hmm, not really.
Importing sheet data from HTML is very much a corner case, in fact a user given a preference shuold be picking TSV or CSV to assure data quality compared to a table pulled from HTML.
Having the minimally intrusive textimportoptions.ui dialog  appear when opening a non-CSV document, including HTML, into Calc is not the issue here. Rather improving work flows for parsing complex CSV
In reply to Comment #29 (from V Stuart Foote)
re. whether a parallel task is needed for the HTML import.
> Importing sheet data from HTML is very much a corner case, in fact a user given a preference shuold be picking TSV or CSV to assure data quality compared to a table pulled from HTML.
Importing a table is one possibility, but you can simply save or generate a spreadsheet as HTML. It has some advantages over CSV, especially in formatting.
Anyway, it doesn't really matter whether it's a corner case, or what some developer or discussion participant magisterially thinks users 'should' do. The fact is that it is an existing use case, in regular use in businesses I have come across. Calc currently handles it in the same way as importing a CSV (simplified, since importing HTML is simpler) and I merely point out that it would be good practice for it to continue to do so, if the way of importing CSVs changes.
TSV may also be a corner case. I had to look it up. But if Calc currently handles it in the same way as CSV, yes, it would be good to continue to do so.
> Having the minimally intrusive textimportoptions.ui dialog  appear when opening a non-CSV document, including HTML, into Calc is not the issue here. Rather improving work flows for parsing complex CSV
The dialog is as intrusive as the CSV dialog, in the sense that it appears every time.
We discussed the topic in the design meeting with the following outcomes:
* special uno:command(s)
* checkbox in open dialog to bypass the import dialog (jay)
* use <ctrl> or <shift> to bypass the dialog when it is intended to appear (jay)
in the file dialog when pressing open button, clicked the file in start center, or drag and drop
* introduce some kind of heuristics that detects the format and only asks if unsure (csongor)
* simplest heuristic would be the URL and after first time reading file from this place
the dialog doesnt pops-up again (jay) perhaps plus a filename comparison
* rather improve the import dialog with use of parser settings saved to profile (stuart)
*** Bug 115415 has been marked as a duplicate of this bug. ***
We have a checkbox in Save As dialog named "Edit filter settings". A counterpart in File Open dialog would be natural and consistent. It could be checked by default, and when unchecked, would suppress the CSV/DBF/... filter settings dialogs.
(In reply to csongor from comment #27)
> 1. heuristics, that try to make smart guesses how to understand files. It
> mostly works but sometimes not. This is what Excel does and if it fails then
> you have no chance to convice it to think differently. (I hate it if this
> comes up. :))
This is not true and comes across as misinformation intended to justify something that has pissed users off for years.
In Excel if you open a csv file from Explorer by just clicking on it, yes it will use basic locale based heuristics and attempt to open the file. For Unicode csv files it does get this wrong sometimes. However it's heuristic is perfectly adequate for opening the vast majority of ASCII csv files, and I've never had a problem with it.
If you have a csv file that Excel's automatic opening cannot handle, then you can click Data -> from Text/CSV, select your file, and you are then presented with a dialog similar to the one in LibreOffice that enables you to manually select the encoding, character separation options etc.
If LibreOffice can just do that same as Excell in this regard, and with better Unicode support too, that would make a lot of people very happy.
I know it has been a while but I would like to add my two cents worth to this also.
We are providing computers as part of an industrial research rig package- the rigs are controlled using propriety software that outputs data as a tab delimited file.
Due to various ball-aches from Microsoft we are now looking at dropping providing Office software as part of the control system, instead using LO as a replacement. However, the one sticking point is the pop-up box when opening the .tsv file. It is not an issue to me personally, however, not all of our customers are particularly tech savvy, and as such a pop-up box is going to be daunting, and also a chance for them to mess it up. The software always outputs as a .tsv, so once any options are set then it would be fantastic if LO could open the file every time. In my opinion, most of the time the delimiter will be the same from one file to the other, and so the option to turn off the prompt and use the last values seems common sense for the majority of people using LO. In the cases where they aren't, then the option to still have the pop up on every opening will cater for this also.
I see this issue was raised 4 years ago, and I really can't understand why there is so much resistance to aiding usability for the majority of users.
(In reply to James from comment #35)
> I see this issue was raised 4 years ago, and I really can't understand why
> there is so much resistance to aiding usability for the majority of users.
You are very welcome to implement the feature :-).
If you seek for an intermediate solution that works in your particular scenario then you might want to think about macros. Not a big deal to read delimited text files.
The public has been asking for this to be addressed to our needs for years at this point.
I too must beg for this bug/enhancement to be fixed/improved.
Like Dirk from 2015, I have to open/edit 25-100s of CSV files every day. Every one of them is formatted the same "standard" way that Excel reads inherently. But my version Libre Office 5 still asks how to open every single file. Not only is it time consuming and aggravating, but often the CSV Import dialog comes up behind another application on another monitor. So not only can I not open the file the way I should be able to open it, but now I must hunt for the dialog also.
The dialog issue should be reported as its own bug, but I decided it is more important to address the base issue. The users should not be required to see this dialog in the first place.
PLEASE, Developers, PLEASE give your users what we need! Thank you!!!!
In addition to comment 31, a very simple option could be to introduce a checkbox that is reset to the default (show the dialog) per session.
Let's go with a higher importance as many users are affected.
A second problem, with both CSV and HTML import dialogs, is that they have the wrong parent window. In Windows 7-10, this leads to the following behaviour:
* If LibreOffice is closed, the dialog appears first, with no parent, always on top
* If any LibreOffice window is already open, the dialog appears attached to the first LibreOffice window down in the Z-order. Occasionally this comes to the top, but usually not, and then it has to be searched for. If you have many LibreOffice and other windows open, you must find the right one, and it may not be at all obvious.
I suggest that correct behaviour would be either:
* always have no parent; or
* first open the window in which the import is to happen, and then attach the dialog to that
Either of these would guarantee that the dialog appears on top, as well as having it attached to the window it actually refers to, rather than some random other window.
This should probably be (and maybe already is) a separate bug, but I mention it here because it is the reason why it is not true to say that all that is required is one click. You often have to search through any open windows first.
(In reply to Gareth from comment #39)
> A second problem, with both CSV and HTML import dialogs, is that they have
> the wrong parent window. In Windows 7-10, this leads to the following
Thanks Gareth. I can't test or confirm (easily..) but could you please be so kind to make a separate bug(s) for that problem?
That is the best way to get attention.
Cheers - Cor
(In reply to Gareth from comment #39)
> A second problem, with both CSV and HTML import dialogs, is that they have
> the wrong parent window. In Windows 7-10, this leads to the following
> * If any LibreOffice window is already open, the dialog appears attached to
> the first LibreOffice window down in the Z-order. Occasionally this comes to
> the top, but usually not, and then it has to be searched for. If you have
> many LibreOffice and other windows open, you must find the right one, and it
> may not be at all obvious.
You have never stated LO version you use; and based on what you write, I get it as you likely use some older version that doesn't have a fix for bug 32935. What you write should not be an issue for Windows currently AFAICT. If it is, then by all means do file a separate bug.
Thanks Mike, and apologies, Cor. I can confirm that it is fixed for CSV imports in 6.12. However, the ability to open HTML imports from Windows Explorer in Calc appears to have been removed: they get redirected to Writer/Web, even if you select Calc.
HTML files can still be opened in Calc from an existing Calc window, which I guess avoids the bug, fixed or not, but unfortunately may also make it more awkward to use than the version with the bug. I need both CSV and HTML (and HTML more often), so I have to consider whether to go back to a buggy version. Hey ho!
Maybe I should open a bug for that. I see that 6.2 Alpha is now available. Maybe I should check what happens in that first.
HTML opening issue seems to be fixed in 6.2. Many thanks again.
Adding another vote for this issue.
I understand that CSV files *can* have significant variation in format. However, that variation is likely to be much lower for each individual user.
A similar issue has already been dealt with in Writer, where there are two plain text formats to choose from: "Text" and "Text - Choose Encoding". The first option (which is the default, and used when a *.txt file is opened via the command line, or if "All Files" is selected in the dialog box uses the current default character encoding. To open a file with a non-default, the "Text - Choose Encoding" option *must* be selected. If the user forgets to do so, the file opens with the default, and renders incorrectly.
This is not unreasonable behaviour. As a user, I understand that not all csv files are formatted correctly, and if I don't automatically get the results I expect, I will need to adjust the filter, and if I deal with multiple formats, I'm going to have to adjust the filter often.
Similar behaviour for CSV files makes sense. The "CSV" file format should automatically apply the currently specified csv encoding parameters to files detected or specified as csv. There should also be a "CSV - Choose Encoding" file format which brings up the current filter dialog that allows the user to specify the formatting for that particular file. I would also suggest that the filter dialog include a new checkbox to specify that these new settings should become the default.
A possible new configuration checkbox could be added to "Tools -> Options -> Load/Save -> Load" labelled "Always prompt for Text or CSV Encoding", which (if set) would result in the current behaviour.
For me this is also a misfeature/bug.
I am creating usualy 4 to 10 csv at a time and they are opened simutaniously, so it is very tedious to click to all boxes. When i hit enter after generating a batch, i only get one calc window opend with the last file.
Please add a feature for autoimport! I will use MS in the meanwihle.
V22.214.171.124 on Win10
This is a major issue. Those saying it is not significant have never experienced it. Add 100 clicks per day to your ongoing click count and you will very shortly have a different opinion. It is a known issue in healthcare; an administrator will add a single required click to the physician workflow. Analyses have been done multiplying the time it takes for 1 click by the number of physician-times, per physician, per year, and 1 analysis I saw showed a billion dollars in healthcare costs in the US for a single added click (opportunity cost from taking time to do something else, not to mention significant negative costs from alert fatigue). Frequently there is uniform criticism by those who bear the cost, and in-appreciation by those who do not, but everyone who has to face the problem themselves quickly changes their mind. A keyboard stroke is not as bad as a click, but still a significant problem. There is development of carpal tunnel and tendinitis from repetitive motions.
With libreoffice, most users will uninstall and use something else without ever reporting the problem on a bug request website (first being required to register an account), so the problem is likely greatly underreported. More persons not using libreoffice because they uninstalled it or stopped using it is not good for the future of libreoffice.
I am not clear on why I have to have the same CSV import dialog open for the SAME file. After I have opened a .csv file once and set (or not set, typically) the import settings for that file, why can it not save the settings for that exact same file? This would solve the problem for a large number of use cases.
For the users with an ongoing need to open a large number of new .csv files, why not have a global setting that they can find somewhere in Options that would allow them to turn off the dialog? Most users will never see this option.
+1 for addressing this. I too have to open lots of CSV files, and am trying to transition from Windows/Excel to Ubuntu/LO. I was happier running a Windows VM just to keep using Excel, due to this issue.
Thanks to a few posts on the subject however, I've set up a custom csv opening option for when I double-click on csv files in a file-browser, which appears to work for me. In case it helps anyone else:
# cat ~/.local/share/applications/defaults.list
And added an infilter to the Exec line:
# cat ~/.local/share/applications/libreoffice-calc_csv.desktop | grep -v '#' | head -n7
Exec=libreoffice --calc --infilter="Text - txt - csv (StarCalc)":44,34,0,1 %U
I think I needed to delete the application/csv and text/csv entries in /usr/share/applications/defaults.list - time will tell if they get added back in again automatically (but dpkg-reconfigure didn't).
As for many others, for me, Excel gets this right - make the common use case quick and easy (open with default, or saved, options - as configured by the user) and make the rare use case possible (support opening with options via the File|Open dialog).
It's a shame that only tech nerds can fix this deficiency for now, apparently.
OP here. It's been nearly 6 years since I opened this ticket, and since no one seems to care about fixing an issue that so many people are complaining about, I am washing hands away from it and unsubscribing from emails.
I have uninstalled LibreOffice and now use Google Docs exclusively.
Great job, the people who run this project are real champs.
Not a bad hack to solve this.
For those who want to use this, and are interested, the options for the "--infilter" argument (which allows the separator and text quoting characters to be defined) are described at https://wiki.openoffice.org/wiki/Documentation/DevGuide/Spreadsheets/Filter_Options
Is there a way to apply this fix on Windows? I would love to be able to open CSV files without having to go through that dialogue box every time.
To set up the workaround described in Comment 47 so that it works in Windows, you need to edit the file association. Windows makes this unreasonably difficult to do, but luckily there is a freeware tool, Nirsoft's FileTypeMan, which you can download at:
First, make sure CSVs are already opened with LibreOffice. If not, open a CSV using "Open with..." and "Always use this app" to choose LibreOffice.
Unzip and run FileTypeMan, and navigate to the CSV extension. I recommend maximising the window for ease of use.
In the top half of window, click on the entry for CSV.
There should now be one line in the bottom half, called "open" with a command line pointing to LibreOffice.
Select this line and choose Edit Selected Action (f3).
Now edit the command line, by adding between the app name and "%1", the following parameter:
--infilter="Text - txt - csv (StarCalc)":44,34,0,1
with a space either side, so in the end the command line should look like:
"C:\Program Files\LibreOffice\program\scalc.exe" --infilter="Text - txt - csv (StarCalc)":44,34,0,1 "%1"
(May vary slightly depending where LibreOffice is on your PC.)
Click OK, and try double clicking a few CSVs. If it worked, you'll see no more pesky dialogs.
For more details see Comment 47 and Comment 49
And, just in case anyone else also uses them, here is a parameter that does the same job for HTML imports:
--infilter="calc_HTML_WebQuery":"Neutral locale language : 0"
^That worked perfectly. Thank you very, very much!
(In reply to Gareth from comment #52)
> --infilter="calc_HTML_WebQuery":"Neutral locale language : 0"
I don't know where you got the "Neutral locale language : 0" part from. While that works accidentally, it's wrong. There is no such text part in the filter options, what happens here is that the string value is parsed away and taken as zero. That by chance results in the system language/locale. I assume you read a description of the parameter somewhere and inserted the entire description as filter value.
The calc_HTML_WebQuery filter's parameters are two numbers separated by one space, so a valid filter string here would be
The first number is the MS-LCID of the language/locale to use (0 for default), the second number is a boolean value whether dates and "special numbers" are to be converted to numeric or kept as strings.
Many thanks. Couldn't find any useful documentation on the HTML filter options, so tried hacking a filter based on the CSV one, the info required by the HTML import dialog, and the limited info in the docs linked in Comment 49, and stopped when I found a formula that worked. Good to have a properly constructed one.