I pulled the latest code (24676:b5dbcfa1e3e7). I certainly can see a change in both the core's PR-printout--or whatever it is called--and the VE display. Basically,

Compare both of the above with what I listed in #14. Now the numeric cell entry is not right-aligned, but left-aligned--it also has the 4 number fractional width where before the 00 was dropped. But here again it looks like the number entry is leaving a space at front for the minus symbol.

When viewed within V.E., the above has both fields left-aligned and that space in front of 1.2300 above is gone.

And, as Rik reported, the trailing 00s are dropped in V.E. for something like

So, there looks to be a combination of things, in the core and whatever Qt tables are doing.

There may be a spread-sheet-like interpretation of the entered string. It's clear there is a difference. Try the following:

(Note how the above variable print-out has strings left-aligned, numbers right-aligned.) Now experiment with entering in these entries something like "001.2300" in these cells. For the numeric cell, the 00 is dropped.

Then again, a similar thing happens when I do so at the command line:

But maybe cells are different from arrays within Octave core too:

Perhaps there is a special table member function which sets the table cell entry to be a string even if the ASCII translates to a valid string. Or experiment with tacking an apostrophe to the front of what is passed to the Qt table, as I know in spreadsheets entering something like '0123 (only apostrophe at front) will interpret the contents as a string rather than numeric.

This could explain the left-aligned "0" and possibly why I was seeing the initial left-aligned numbers suddenly jump to right aligned. I'm not sure how, but I would guess it can be a confusing lost-in-translation kind of thing.

I'm testing some recent mods to the variable editor autofit/optimal-width. In particular

changeset: 24670:62a05d23cd00

I find that the autofit isn't the way I'd prefer. It seems to be right-aligning within a 10-character width, which doesn't seem to achieve optimal width for matrices that have short numbers like zeros() or eye(), that is "0" or "1".

Try the following:

At this point I see in the V.E. the cell contents are left aligned. Now, select one of the cells and change a value from, say, "0" to "123". All of the numbers in the table will suddenly become right aligned.

Furthermore, decimal points don't align, enter 1.23 in one cell and 12.3 in a cell below that one. (It's OK to not have alignment, but if there is any, decimal point would be my preference.)

[From a different bug report] Now, as to the autofit behavior, the one thing we have right now is the double-click to autofit feature that Philip mentioned. I use that, and the autofit doesn't seem quite right. As an example, do

There is a great deal of whitespace to the left of the zero when there could be more columns autofit in the view. Also, if I shrink the width of column 1, say, down to nearly nothing and double-click the line between column 1 and 2, the autofit occurs and goes back to that large-pre-whitespace width. If I expand the first column so there is a large amount of white space after the zero and double-click the line the the column goes back to the original autofit size. So it seems that there is more pre-whitespace than necessary or some type of minimum limit on the column width. Is this happening because the code attempts to align the numbers, i.e., its format is 10 character width numbers so that is somehow the minimum allowable size?

Yes, it's exactly the same issue with decimal point alignment, something that is probably best solved by the method I described earlier. Especially if we want the display in the editor to respect format settings. Do we? Some people might like to see engineering format, or fixed format, or always have "long E" or whatever.

Makes sense. Why not just add the space to the output format? That would take care of the problem, and wouldn't even require parsing the value to display (although you would do that anyways to determine integer or floating point).

The problem with alignment is caused by only looking at one element at a time in the variable editor. That's the way this table widget works. It requests a single element for display at any given time.

When Octave displays an array in the command window, it looks a the values of the whole array to decide what format to use. We could do something similar for the variable editor when the first element of an array is displayed and then cache the result for subsequent elements. I've been thinking about trying this, but just haven't gotten to it yet.

Strange. It's only the zero that will align one character to the left. I say one character because if I mouse-drag expand the columns/cells it's clear that the numbers/contents are left-aligned. But all numbers, except 0 (and that includes fractions which begin with 0), are aligning left but leaving one extra blank character at the front--it's as though the numbers are leaving space for a negative symbol at the front. Maybe the code is assuming that a 0 cannot have a minus sign in front of... but of course it can in Octave, i.e., -0 is valid.

The value '0' has a different justification then any other value when displayed in the variable editor. This causes columns of numbers to mis-align. It is not tragic, but it is annoying and the terminal output, for example, already gets this right.

Sample code:

Notice how the the number '0' aligns with '8' and '4' in the first column. Attached is a screenshot of how it displays in the variable editor with the '0' cell left-aligned.