After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 768169 - WARNING **: Unparsable expression ... cannot copy-and-paste with defined names
WARNING **: Unparsable expression ... cannot copy-and-paste with defined names
Status: RESOLVED OBSOLETE
Product: Gnumeric
Classification: Applications
Component: GUI
git master
Other Linux
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2016-06-29 06:55 UTC by John Denker
Modified: 2018-05-22 14:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
trivial spreadsheet to help demonstrate "unparseable expression" (1.68 KB, application/x-gnumeric)
2016-06-29 06:55 UTC, John Denker
Details
spreadsheet to demonstrate setup for "unparseable expression" (83.38 KB, application/x-gnumeric)
2016-06-29 06:56 UTC, John Denker
Details
spreasheet that actually contains an "unparseable expression" (1.90 KB, application/x-gnumeric)
2016-06-29 06:57 UTC, John Denker
Details

Description John Denker 2016-06-29 06:55:30 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
Comment 1 John Denker 2016-06-29 06:56:23 UTC
Created attachment 330531 [details]
spreadsheet to demonstrate setup for "unparseable expression"
Comment 2 John Denker 2016-06-29 06:57:00 UTC
Created attachment 330532 [details]
spreasheet that actually contains an "unparseable expression"
Comment 3 John Denker 2016-06-29 14:27:42 UTC
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.
Comment 4 John Denker 2016-06-29 14:31:31 UTC
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.
Comment 5 Morten Welinder 2018-04-21 21:41:27 UTC
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.
Comment 6 GNOME Infrastructure Team 2018-05-22 14:26:16 UTC
-- 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.