Re: Microsoft Excel spreadsheet editing directly from within emacs.

[Stefan Nobis <stefan-ml@snobis.de>]

Jean Louis <bugs@gnu.support> writes:

> You speak of a programming language and what is possible with
> programming language.

That's not the point. Org table is integrated with Calc and Calc is a
Computer Algebra System. That is something like Excel combined with
Mathematica (with a little less GUI stuff) - that is powerful
integration to me.

Lisp is nice and for me as a programmer a helpful tool. But the main
point is Calc.

Just putting data in a tabulated form is seldom the interesting part.
It starts to get interesting when you try to do something with the
data, e.g. make some calculations. At this point it is significant,
how many calculations you can do out-of-the box (without much
programming). I did not count, but I assume that Calc has more
calculations to offer than Excel and even for a wider range of topics
(even symbolic math).

Therefore, from this point of view of core functionality, I would say
Org tables with Calc are more powerful that MS Excel. And thinking of
the many quirks and bugs in MS Excel, I still say: Excel is the toy
software and Emacs + Org + Calc is more mature and more professional
and the file format much more future proof (yes, nowadays Excel uses
XML, but the definition and documentation is lacking and too complex;
it seems not possible to re-implement it fully).

I emphasize this, because you wrote: "In comparison to all major known
spreadsheets Org tables is not powerful and not even comparable."

And "powerful" for me means core features, i.e. calculations. And in
this respect, I think the statement is wrong.

> In a spreadsheet program I may visually and nicely presented see a
> slice of a whole table. I may move from slice to slice to other
> pieces of the whole table of data. Moving from cell to cell is
> pretty easy and there are no screen distortions.

If your point of view is, that the main feature are the visual
interactions (hiding/revealing rows/columns, sorting, filtering data
etc.) then yes, maybe Org lacks a bit in these areas (but I think not
quite as much, as you imply; e.g. Org can show labels for rows and
columns and there are ways for hiding, sorting and filtering).

On the other hand: I do find GUI spreadsheets also quite lacking in
this regard (e.g. regex pattern are seldom easy to use). If I need to
tinker with data, explore it, I would put it into a database (or into
R or Julia or - depending on the size of the data - using R/Julia from
within Emacs via Org tables). That's much faster, maintainable and
reproducible.

> Spreadsheet user interface is integrated, it does not require user
> to remember much, or maybe nothing, just use a mouse.

Nice try: There are tons of books about the question what are the best
user interfaces. I have seen people working with computers with
exactly this mindset: "I do not need to learn/remember anything, it
should be easy, just clicking a bit with my mouse". At this level, it
just does not work.

So, yes, a very text-oriented UI is not the best solution for every
task. But then a GUI is also not the best solution for every task.

> Org mode is bringing us back into the era before Doug Engelbart.
> Back to history.

That's IMHO a very simplistic and ignorant view on UX. The problem is
much more complex and yes, in quite some cases are text-based
interfaces even one of the best solutions (and next to never exists a
single best solution, UX always depends very strongly on context and
details).

> Combining various sheets is standard spreadsheet feature. Examples
> you have shown are cryptic for spreadsheet users.

I once showed rather simple Excel sheet to an Excel user and he was
overwhelmed and did not understand how to create such a structure (2-3
tables with formulas across tables). So Excel is cryptic for
spreadsheet users, too. :)

With other words: No tool is simple, you need to learn at least a
little bit - in all cases. I only showed the final result, not the way
how it has been created. Emacs and Org have ways to ease some of the
seemingly complicated parts, just as Excel tries to help formulate
complicated calculations. And then comes habit.

I fully understand that a tool like Excel at least seems to be easier
for the first steps. But that does not mean that it is a given fact,
that it is easier and better suited for any task that is spreadsheet
like (you already mentioned databases - I would say for the typical
spreadsheet users databases are even more cryptic that Emacs and Org).

>> Maybe advanced visual presentation of the data is easier with GUI
>> Spreadsheets -- then again, it is so easy to combine Org tables with
>> the power of Gnuplot, R, Python, Julia, TeX etc. to create
>> astonishing visuals, that I prefer this way in many situations.

> That is like saying to a user to switch from Emacs to C programming
> language as it gives user far more capabilities

No, quite the contrary. I think, this is the main point, you seem not
to understand. Emacs with Elisp is much more expressive than C. Org
with Calc is (for calculations) more expressive than Excel. And this
expressiveness can help in efficiency and maintainability.

Is this the one and only solution for everyone? No, of course not.

But you seem to imply, because some data viewing aspects and the very
first steps with spreadsheet programs may(!) be easier with tools like
Excel, everyone who needs some spreadsheet-like tools should always
only look at Excel or LibreOffice. With this argument you could also
say that no one should use CAD tools - with Paint you can draw
everything and 3D modelling with CAD is too complex and has a very
steep learning curve.

We talk about Org users and therefore Emacs users. Not every Emacs
user knows about Calc, but some do and other may benefit from learning
about it. And for users already comfortable with Emacs and Org, Calc
and the combination of Org tables with Calc may be even easier to
handle than Excel or LibreOffice. That's the point: GUI spreadsheets
have some disadvantages (and some advantages) when compared to Org
tables; maybe not many, maybe not relevant for everybody - but they
exist. Thus GUI spreadsheets are not the best tool for everybody and
all tasks.

And I never said, that Org tables should strive for world domination
(hmmm... maybe it would be a better world). I just questioned your
statement, that Org tables are a toy and not really up to real tasks
that Excel et. al. can handle and that only GUIs provide good UX.

BTW: I know quite some people missing good old mainframe UIs. A simple
text based mask with only a couple of actions to be executed via
F-keys. And todays mobile apps are rather a revival of those simple
mainframe screens (more shiny and with touch instead of F-keys) rather
than a copy of complex desktop GUIs.

> Users need integration, they don't mind of the mentioned powers.
> They want to enter rows, columns and click button and get a chart.

This is possible with Org tables - besides the point that not every
user is the same. I fully understand that Emacs is not the tool for
everyone, neither is Org. In my younger days I often tried (sometimes
very hard) to convince people to use LaTeX or Linux (or both). I
learned my lessons. :)

But just because there are some or even a majority of people that
prefer tool A does not mean that you should advocate tool A to
everyone. There might be quite some people that would much more
benefit from using tool B or C. I've been a teacher for adult evening
classes, I know a little bit about how Jane or Jo User struggles with
computers. But I've also seen how some of these everyday users are
able to use complex tools. It's just not as simple and black-and-white
as you picture it.

As a loose analogy: See how Maker spaces are flourishing nowadays.
There are many people that are eager to understand, how the world is
build (at least some parts of it). Yes, that is not true for everyone,
but do not underestimate curiosity and the fun to tinker. Even
nowadays new, young users discover Emacs and love to use it (despite
all the shiny sparkling GUI and web-based tools out there).

-- 
Until the next mail...,
Stefan.