Re: [Texmacs-dev] Reorganization of the menus

[Joris van der Hoeven]

> Actually the use cases are completely different:
> 
> "Revert" means "discard the changes I have done since I last saved or
> last opened the document".
> 
> "Reload" means "update the page with the changes which have been done
> (by someone else) on that page since the last load".

This possibility to edit is indeed a difference.

> You will notice that web pages are loaded as in "download", but that
> files are opened as in "reopen an old case", "open a customer
> account", etc.

        .->
No, the |   icon is called "Reload".
        .-/

Remember that it should be possible to consider a web location
in a similar way as any other storage medium like a hard disk.

> > Think of the following situation: I am writing a joint paper
> > with someone in the US. He sends me the paper with the "letter"
> > paper size. I attempt to print it out. What should happen?
> > It should be possible for a document to have a different
> > page size as the default printer settings. If I attempt to
> > print such a document, I guess that a dialogue box
> > should popup (or a question in the footer).
> 
> That was exactly the kind of thing I was thinking of. My question was
> whether there was really a meaningful default paper size on GNU/Linux?

Yes, look at my (get-default-paper-size) scheme command.

> > > But I really do not think that there is a need for a "Default
> > > Orentation".
> > 
> > We have to be consistent.
> 
> Consistent? I just want to be consistent too. Anything which can be
> move up a level is going up.

I mean that options which are set globally (init-env)
should always be accompanied by an option to use
the default settings (init-default). One submenu for
a not-so-important option like Portrait/Landscape is
better then two items in the parent menu.

> > By the way, one may also have Seascape and Upside-down.
> 
> You are not being serious. For one thing Seascape and Upside-down just
> do not exist yet in TeXmacs, and for the other that would be
> ridiculous: ever tried to type text while your screen is turned upside
> down? So if that must exist on day, that must be in the "Page
> Setup..." dialog (which hopefully we will have before).

It may be interesting for setting the header of the exported
Postscript document (not for editing of course).

> > > > Another idea: would it be somehow possible to merge "Export" and
> > > > "Copy to" together, as well as "Import" and "Paste from"? 
> > 
> > I meant "Import from clipboard" and "Export to clipboard".
> 
> I think I understand: have the "Copy To" and "Paste From" submenu have
> an item group which provide conversion and copying/pasting to/from the
> system clipboard? Seems reasonable to me.

Right, but my problem was to find the appropriate name.

> > Also notice that we may keep the option to set the default behaviour
> > in the preferences.
> 
> And make it an application-wide setting?  Agreed!

OK.

> By the way, verbatim export is still really broken.

Yes. This also reminds me of a way to specify
encodings for imports and exports.

> > Also, what about putting "Cancel" just after "Undo" and "Redo"
> > at the top of the "Edit" menu?
> 
> I really do not like the Cancel item. Actually it seems to be the
> collection of all the cancel buttons in all the missing dialogs.

Notice that I *really* prefer the Emacs-style searching to
what is done in other word processors. During searches,
part of the text is covered by the popup and if you found
something it might actually be hidden! Then you move the popup,
and the next occurence may be hidden again...

> Putting it near "Undo" will introduce confusion, unless it is renamed
> in a less ambiguous way, like "Interrupt", meaning "interrupt current
> interactive minibuffer input".

In this context you make a point.

> > You are right that this is another possible interpretation
> > (more M$ than Unix style); this should be called "Replace selection".
> 
> Your are right in the abstract.
> 
> But GUI is widely a matter of convention (like having "Page Setup..."
> in the File menu). A bad convention is often better than no conventian
> at all. It seems that the universal convention nowadays is more and
> more the Macintosh style.
> 
> The fact you do not like this convention (I am not even really sure
> you understand it well) should not be a reason to force the default
> binding to follow the X11 convention.
> 
> If you like the X11 style, you are the best person to customize it
> out, and why not make a first step toward GUI profiles by introducing
> the first extra profile in the distribution: "Joris style".
> 
> That too is part of making TeXmacs fits the world instead of the
> opposite.

We may use different defaults on different platforms.

> > My concern is again to keep the number of keyboard bindings small...
> > I think that C-x, C-c and C-v do not really conflict with
> > Emacs bindings, because C-x and C-c only make sense
> > in the case when a selection is active (and the Emacs bindings
> > like C-x C-s have no particular meaning in that case).
> > The Emacs C-v is not really useful anyway,
> > because the page-down button is available on most keyboards now.
> 
> What do keyboard bindings do here?
> 
> Are not we discussing the menu hierarchy?

Yes, but in this particular case I think that the behaviour
has to be uniform (we will propose the corresponding keyboard
binding in the menus; not the corresponding icon...).

> > Right; I prefer the X11 semantics. Explicitly copying just
> > additionally clears the active selection. There is another difference:
> > in M$ application, selections are naturally overwritten when
> > you start typing. I think that this is *very bad*.
> > We already discussed this before on the texmacs-users list.
> 
> Yes *you* did. But you still do not understand what it is really about.
> 
> In the Macintosh style, the selection is very transient. Any mouse
> action (but select-dragging, shift-clicking and maybe drag-moving)
> cause it to disappear. So do any action from, say, the Insert or
> Structure menus, and without overwriting the selection with the
> inserted element. Additionally, in this convention, you cannot easily
> detach the selection from the caret (we can make this happen for the
> sake of keybord based move, but then we have a kind of "weak"
> selection).
> 
> So having pasting or typing erase the selection is not that bad
> because the selection is very unstable, and easy to disable, and it
> does provide some useful usage patterns. And anyway, it is the
> expected behaviour.

Yes, so you convinced me that different default actions
for such elementary operations are appropriate on different platforms.
I think that this is what is actually the case for applications
like netscape.

> > I am not sure, but I am not sure of the contrary either.
> > For instance, a commutative diagram may be seen as an image
> > with a mathematical meaning.
> 
> If it has a mathematical meaning (which I think is a bit hairy an
> argument) it must be kept in the math menu.

Hmm, I misexplained my feelings: if images have a mathematical
meaning (in the sense of structure), then they should indeed be
in the "Mathematics" menu. If they only have a meaning in
the sense that they "make sense inside mathematics",
then we should have images in the Edit menu. But the same is true
for including images or not in the "Text" menu (which you may
have found by now in 1.0.0.11). So I think that we should keep
them in the Insert menu as being some kind of "general objects",
which may make sense everywhere.

> Did you notice that in my proposal all markup with contextual meaning
> was moved out of the Insert menu? Which only kept formatting markup
> and a few universal tools like hyperlinking.

Right this is exactly what I am working towards to and
I see images, tables and trees (hey!) as such universal tools.

> Anyway, an image has no semantic meaning as far as TeXmacs is
> concerned.

But it can *make sense* inside mathematics.

> > No, because I rather interpret page insertions as physical than
> > logical decisions. On the other hand, logical markup which relies on
> > page insertions for its presentation should be moved into "Structure".
> 
> Footnote. Floating Table. Floating Figure.
> 
> That looks very much like "logical markup which relies on page
> insertions for its presentation".
> 
> Maybe "Floating Object" could be left in the "Insert" menu. But is it
> really useful anywhere but in text mode? I recognize the need might
> arise, but is it likely enough not to ask for defining a new macro?

Right, there is still some confusion here, also because footnotes are
not exactly implemented in the way that they should be.

> > Yes, Format should only insert with-like structure.
> 
> As you like to say: "we'll see".

What I say seems indeed to be more and more the case:
all physical typesetting related markup (spaces,
breaks, resized boxes, etc.) should rather be in Insert.

> That makes sense. But then we can think of removing all commands wich
> insert trivial non-primitive elements in Preamble mode.

For many style-dependent markup this will be automatically
the case somehow (since no style is being specified).
But I need to study this in more detail though.

> > Yes! You will need to buy a larger screen!
> 
> I was just saying that the policy you are proposing cannot avoid
> cluttering the menubar.
> 
> So, I propose an alternative:
> 
>  -- one mode-specific menu (Text, Mathematics, Biology, Poetry).
> 
>  -- one block-specific menu (Table, Tree, Drawing, anything) matching
>     the innermost block the caret is in.

This makes sense, but I am not completely sure yet.
We really should be able to cover lots of situations...
For instance, the preamble mode is orthogonal to all this...

> > I do not like "Page setup", but we might want "Printer settings",
> > like this is the case in some other word processors.
> 
> Which ones?

AbiWord, for instance.