Re: [Texmacs-dev] Reorganization of the menus

[Joris van der Hoeven]

> Menus must be stable. They must not appear and disappear. If some
> items cannot be used in a certain context, they must be dimmed out. If
> all items in a menu are dimmed, the menu title must be dimmed, yet
> still allow the user to unroll it.

This needs some changes in the code. I prefer to wait for a new GUI port 
before doing this. Also, this criterion will not always work in TeXmacs
(see below).

> In principle, all menus items which require further information from
> the user, and only these, must be followed by ellipsis ("..."). Menu
> items which merely prompt for confirmation must not be followed by
> ellipsis.

This can be taken care of. I would like a more structural thing than
ellipses though. I do not know if the Chinese use ellipses...

> All menu items must be capitalized in title style.

I hate abusive capitalization in "Start Up the Computer".
This is ugly, even in titles, and very language dependent.
I am willing to capitalize the first letter, not the rest.

> Hierarchical menus are bad, one level of submenu is acceptable but
> best avoided, two levels should only be used if no other reasonable
> solution can be found. More than two levels of submenus is a bug.

I agree, we have to take care of this.

> All submenus with only two non-interactive items will be removed and
> replaced by toggled menu items.

Yes; but we need to modify the code for this;
again I prefer to wait a while with this.

I also see a difference between choosing an item (like a shrinking factor)
and selection of an environment change (like an italic font).
Both things should be indicated in the menus, but in a different way.
Since TeXmacs is particular on this issue, we must not follow
the classical rules here.

> Why "revert buffer" instead of just "revert", or "revert to saved"?

If you want I can replace it by revert.

> The import and export menus items are only useful if they perform
> importation in the current document, or exportation of the current
> selection.

No, they are used for importation from and exportation to extern formats.

> The print menu should use a dialog. So we keep on with the same
> hierarchic menu.

OK; on dialogues & emacs-style entering arguments in the footer:
this should really be an option for the user. Many Emacs users
just hate dialogues and so do I.

> There should be a "Page Setup..." menu items allowing to configure
> page parameters through a dialog. Instead we would use a hierarchical
> menu with items taken from the Settings and Document menu hierarchies.
> The "Page Setup" items set the page size and margins.

Yes, but we need dialogues for this.

>   -- "Document->page->size" should be moved to "File->Page
>       Setup->Size" and keeped as is.

I disagree; this is clearly a document property and has nothing
to do with file handling.

>   -- "Document->page->orientation" should become a toggled menu item
>      associated to the actions "Use Landscape Orientation" (initially)
>      and "Use Portrait Orientation" (when the current orientation is
>      landscape).

OK, but we do not have toggles yet.

>   -- "Document->page->layout" should be replace by two items in the
>      "Page Setup" submenu. "Customize margins" would allow the user to
>      set the left, right, top and bottom margins, and "Restore
>      margins" would revert to the built-in default. If margins have no
>      been customized, the "Restore Default Margins" item must be dimmed.

We'll see.

>      WARNING: the "Document->page->layout->set margins" is broken,
>        since it sets the "page right margin" which is no longer
>        meaningful. Instead it should set the "paragraph width" by
>        substracting the requested left and right margins from the page
>        width.

Yes.

>   -- The predefined paper types should use a "odd page margin"
>      bigger than the "even page margin" if and only if the document is
>      being printed recto-verso. We should control this option with
>      toggled menu items "Constant Margins" and "Recto-Verso Margins".
>      
>   -- For the sake of simplicity, I propose we do not allow the user to
>      use "Recto Verso Margins" with customized values. So, when the
>      margins are customized the "Constant/Recto Verso Margins" items
>      must be dimmed and the "Constant Margins" item must be checked.
>      If the user then decide to "Restore Default Margins", "Constant
>      Margins" will be left checked.

In fact, I have to rethink page formatting...

> The "File->import" menu item is redundant with open. The open dialog
> should provide a popup menu to allow choosing between TeXmacs format
> (.tm .ts .tp), LaTeX (.ltx .tex), HTML (.htm .html), verbatim or
> scheme; and the "File->import" item should be removed.

Might be, but I like the symmetry with export. We'll see.

> "File->export->postcript" is redundand with "File->print->print all to
> file" and should be removed.

There is a slight difference: if I remember well, everything is printed
to a single page in one of the cases. Anyway, this should be made clearer
if we want to keep this possibility.

> The "File->export" submenu should be moved to the "Export" dialog in
> the form of a pop-up menu.

Or to save as, if you want to be consistent with what you said above.

> Edit menu:
> ==========
> 
> First, a bit of terminology. Xlib has brain damaged terminology
> regarding copy and paste. What Xlib calls the "selection", is the
> "clipboard" to the rest of the world. For the civilized world (not
> Xlib) the selection is only what emacs calls the "region".

I prefer selection to clipboard as a terminology,
also because we can have multiple selections.

> "Undo" and "Redo" are universally the first items of the "Edit" menu.
> It should be so in TeXmacs too.

OK.

> Clear is broken. In any sane application "Edit->clear" removes the
> contents of the selection without putting a copy of it in the
> clipboard (as opposed to Cut, which removes the contents of the
> selection and put a copy of it in the clipboard). In TeXmacs, "clear"
> only clears the clipbord, which is an action I see no use for. So,
> "Clear" must be fixed to properly clear the selection without
> affecting the clipboard.

I noticed that too.

> The two menus "Tools->selection->import" and
> "Tools->selection->export" should be moved back to the Edit menu where
> they really belong and be renamed "Pasting imports >" and "Copying
> exports >". This phrasing make it clear that these menu are only meant
> to change the behaviour of the copy and paste command when relating to
> external applications.

Well, this is not what other users tend to say.

> The "cancel" command is not really an edition command, and its
> presence in the Edit menu is absolutely not informative. Emacs users
> instinctively use C-g when they want cancel. Other users may use
> various tricks. I guess all non-emacs user get out of incremental
> search by moving the caret (either by clicking or with the arrows).

I agree that one among cancel and clear there might be one too much.
Maybe cancel is just at the wrong place.

> Also, the "Edit->clear selection" submenu must be removed.

We'll see, this depends on the reply to the previous question.

> For the cancel command to be of any use, it must be extended with the
> name of the action to cancel (e.g. "Cancel Search" or "Cancel
> Customize Margins"). Actually, I think that "Interrupt" would be much
> more meaningful.

Not sure; interrupt has another meaning during sessions to.

> "Spell" is a bit a shorthand. "Spell Check..." is much more
> informative.

OK.

> Questions: What is the use of Edit->move?

The selected region is moved to the current cursor position.
I actually would like to make this the default behaviour of paste,
when a region is being selected; in that case we do not need
this item anymore.

> This menu should be broken in three separate menus: Structure, Math,
> and Insert.

We do not have space for this.
The number of top level menus has to remain reasonably small.
Math is also ugly, because it is an abbreviation.
Also, we cannot avoid a certain degree of context dependency
in the menus. When switching to a radically different mode,
like math mode, or worse, when editing a technical drawing,
we should make an exception to the stable-menus criterion.

> The item "Structure->Description" must not be hierarchic when it
> contains only one item.

There will be more later.

> The transient Table menu should be made permanent. The contents of the
> Structure->table and Mathematics->table menus should be moved as the
> first groups of the Table menus. The enable state of the items of the
> Table menu should match their current visible state.

NO SPACE FOR THIS.

We cannot make every possible option of TeXmacs permanent!
We would have a top menu like

File Edit Insert Structure Mathematics Physics Chemistry Biology Law Art Poem|

(the rest is not visible).

> The submenu Insert->image should be moved to the Structure menu. Its
> items should be made permanent. Of course the "Small Figure" and "Big
> Figure" items should only be enable in text context.

No: the figures should be moved, not the images.

> The submenu "Insert->page insertion" should be moved to the Structure
> menu and enabled only in text context.

No.

> Menus items relating to vertical space insertion and indentation flags
> should be moved to the Paragraph menu since they only work on
> paragraph blocks. Menus items from "Insert->space" not related to
> vertical spaces should be moved to the top-level of the Insert menu.

I am not sure, but this might be an idea.

> Header and footer insertion commands should be moved out of the
> Document->page menu and to the Insert menu.

This is not coherent with what you say above.

In fact, you mix things up here: header and footer definitely
should stay where they are, since these are not *insertions*;
these are rather properties of the page.

> The submenus "citation", "index entry" and "glossary entry" of the
> "Insert->link" submenus must be moved to the "Structure" menu, since
> they are only relevant in text context.

I am not quite sure about this. I think that semantic closeness
with other types of links should be privileged here.
We may just disable the entries in math-mode. It is true that the precise
borderline of what should be in Insert and what should be in Structure is
not yet clear to me. I gave a rough criterion, but it does not seem
to work always.

> The items of "Insert->executable" must be moved in a new group at the
> top-level of the "Insert" menu.

They really should be enabled only in something like preamble mode.

> The submenu "Insert->executable->programming" has a too generic name,
> "Control" (as in flow control, or execution control) would be a better name.

Same story.

> Structure
>   Section        >
>   Environment    >
>   Automatic      >
>   Session        >

OK.

>   --
>   Itemize        >
>   Enumerate      >
>   Description

OK.

>   --
>   Citation       >
>   Index Entry    >
>   Glossary Entry >
>   --
>   Image          >
>   Page Insertion >

NO.

Missing: entries for "strong, emphasize, etc."

> Mathematics
>   Formula
>   Equation
>   Equations
>   Numbered Equations

Mostly a submenu of structure.

>   Fraction
>   Square Root
>   N-th Root
>   Negation
>   Tree
>   Text
>   --
>   Script       >
>   Accent Above >
>   Accent Below >
>   Symbol       >

In the insert menu in text mode.

> Insert
>   Rigid Space
>   Horizontal Space
>   Break             >

OK

>   Header and Footer >

OUT

>   ---
>   Link              >
>   Switch            >
>   Specific          >
>   Special           >

OK
>   ---
>   Arithmetic        >
>   Text              >
>   Tuple             >
>   Condition         >
>   Control           >

OUT

> Indentation switches like "disable/enable indentation before/after"
> should be made more smart. For example, in normal mode, they should
> insert a tag at the beginning (ident. before) or a the end (indent.
> after) of the current paragraph. Before displaying the menu texmacs
> should check the current environment and the tags in the current
> paragraph to display the appropriate "disable/enable" prefix.

Yes.

> I strongly believe we can avoid almost all hierachical menus of more
> than just one level of depth. However the introduction of the
> Structure, Mathematics and Table menus may make us lack some room.

Yes, and that is why we do not want permanent Mathematics and Table menus.
We might have a Mathematics menu in math mode though, but I am not even
sure that we have room for this.

> Maybe we could get some room back by scaterring the items of the
> Settings menu in the appropriate semantic categories, or all in the
> Edit menu where the Preference menu item (displaying a dialog) should
> be.

No.

Please let me know of your other ideas about the other menus.
It is still time to incorporate (some of) them.
However, they are less stable anyway.