GNOME Bugzilla – Bug 768169
WARNING **: Unparsable expression ... cannot copy-and-paste with defined names
Last modified: 2018-05-22 14:26:16 UTC
Created attachment 330530 [details] trivial spreadsheet to help demonstrate "unparseable expression" Rationale: The overall objective is to cut-and-paste a sheet from one workbook to another. Recipe: 1) Start *one* instance of gnumeric looking at both of the attached files: :; gnumeric blank.gnumeric uncopyable.gnumeric 2) Copy all the non-blank cells from the source. Paste them into the destination. Observe everything seems more-or-less normal at this point, if you don't look too closely. Save the destination workbook as unparseable.gnumeric. Quit out of gnumeric. My version of unparseable.gnumeric is also attached. 3) Open the new file: :; gnumeric unparseable.gnumeric Observe some very strange cell contents, i.e. equations converted to strings. Observe scary messages on the controlling window: ** (gnumeric:26536): WARNING **: Unparsable expression for A5: ='multi-bit'!eps ** (gnumeric:26536): WARNING **: Unparsable expression for B5: ='multi-bit'!eps*2 ** (gnumeric:26536): WARNING **: Unparsable expression for A6: ='multi-bit'!eps*3 ** (gnumeric:26536): WARNING **: Unparsable expression for B6: ='multi-bit'!eps*4 ================================ No matter what else is going on, gnumeric should not write unparseable files. This is presumably related in some way to "Defined Names". Copy-and-paste seems to have multiple issues with Defined Names. This is a big problem for me, because I really need to copy-and-paste some sheets from one workbook to another, and many of my sheets use Defined Names. Background info: :; gnumeric --version gnumeric version '1.12.31' datadir := '/usr/local/share/gnumeric/1.12.31' libdir := '/usr/local/lib/gnumeric/1.12.31' :; git log commit e86ea3144fafb4b886c24b86f2bee0796220723c Date: Tue Jun 28 13:46:58 2016 -0400 :; uname -a Linux asclepias 3.18.0+ #4 SMP Mon Jul 6 15:51:42 MST 2015 x86_64 x86_64 x86_64 GNU/Linux :; lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04 LTS Release: 16.04 Codename: xenial
Created attachment 330531 [details] spreadsheet to demonstrate setup for "unparseable expression"
Created attachment 330532 [details] spreasheet that actually contains an "unparseable expression"
Additional observations: Recipe: 1) Start *one* instance of gnumeric looking at both of the attached files: :; gnumeric blank.gnumeric uncopyable.gnumeric 2) Copy all the non-blank cells from the source. Paste them into the destination. Observe everything seems more-or-less normal at this point, if you don't look too closely. Save the destination to some temporary file. 3) Hit F9 to recalculate the destination sheet. Observe no obvious problems. 4) Close the source workbook window. Hit F9 again in the destination window. Observe that some cells that previously had the correct numerical value now say "#REF!". 5) FWIW, even though the sheet is now different, it does not consider itself to be modified, i.e. no "*" in the title bar. You can prove that it is different in content (not just in appearance) by doing a Save_As to a different temporary file, and comparing the file contents. ================== This further evidence that the handling of Defined Names is not quite right. Suggestion #1: Evaluation in general (and F9 in particular) should never change the workbook. During evaluation, if it seems necessary to change the worksheet, this should generate an error message. Suggestion #2: In absolutely all situations, anything that changes the contents should mark the workbook as modified, with all that that implies, including a "*" in the title bar.
One more observation: The command :; ssconvert --merge-to ..... appears to do a much better job with Defined Names. This is useful as a workaround. Also it means that the code exists. The ssconvert code might serve as a model for how to improve copy-and-paste.
The warnings are gone, but the underlying problem is done. For the record, a similar problem occurs with inter-sheet references being copies. For sheet-local names, a fix would entail adding the names to the clipboard- xml, at least if they are inside the range being copied. For names outside the range, I think a #REF would be in order. (Actually since names refer to expressions, not simply cells, I think the condition would have to be that all references in the expression must be in the copies range.) For workbook level names I am not sure what the right thing to do is. RE your comment 3, that's not F9 changing anything other than the values in cells. The *close* is what changes the references. The is part of the highly non-ideal way we handle inter-workbook references. This is covered in other bugs, I believe. I'm not sure ssconvert --merge-to is a great model for copy-and-paste. It brutally moves the name definitions over to the target workbook, something that isn't completely right for copy-and-paste. Also, it didn't really work, see bug 795408.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/306.