Re: [Texmacs-dev] Reorganization of the menus

[Joris van der Hoeven]

> Maybe there should be a few, group-related "Revert to default
> settings" commands (e.g. only one for page size, orientation and
> margins) but not one for every individual setting.

No, I don't like this kind of design, because it will harder to
keep things matching.

> Once again you are designing the GUI based on the underlying
> implementation, which is just the wrong way to go 90% of the time.

No, a structured word processor like TeXmacs has a few particularities
which the users must get used to. Two major particularities are:

1. Switching from one color/font/etc to another is not a property of
   your text, but structure inside your text.

2. Texts are based on style files, which are shipped with good default
   settings for your document.

Point 1 explains why the o-tag is different from the *-tag.
Point 2 explains why reverting to the default settings can be
an important operation.

> Copy To >
>   LaTeX
>   HTML
>   Scheme
>   Verbatim
>   ---
>   Primary
>   Secondary
>   Ternary

In the case of the first four items, I would rather say "Copy as";
that's all.

> Yet... I am not sure Primary is really useful, since that is  the
> default anyway.

It is there as a reminder. I think that redundancy is not a problem here.

> Or "Secondary Clipboard" (etc.), or maybe just plain "Secondary"...
> not sure of this one...

Maybe "Main clipboard", "Second clipboard", "Third clipboard",
"Other clipboard".

> > 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...
> 
> I agree, that style of searching is often a nuisance. Yet, maybe
> "return" or "esc" should stop the ISearch... that is the natural
> behaviour for emacs users.

For "escape" I agree, but for "return" I think that
this is not quite natural.

> For other users, there could be a "Stop" button next to the ISearch
> input field (currently that would be in the minibuffer) with the
> appropriate tooltip (say, "return").

I do not really like "return". The user should be teached to
systematically use "C-g" for canceling operations.

> > We may use different defaults on different platforms.
> 
> Obviously you want to make your liking the default, and you will not
> be talked out of that.

That is not the point here. I just say that different default settings may
be appropriate on different platforms. Didn't you say that the "About" menu
comes very early on the Macintosh? It would not really be handy either to
simulate the Apple keyboard layout on a PC, right?

> I do not get your point. And anyway I think that mixing emacs-like
> binding with M$ like binding and Mac-like binding is recipe for
> disaster.
> 
> For example, one have "C-y" for pasting and "C-w" for cutting just as
> in Emacs but "E-w" does not copy as expected... Even without
> mentioning the fact the your shortcut for cut is "E-x", copy "E-c",
> leading the user to think that your may be following the
> Macintosh-style shortcuts (remember, Esc is Meta in TeXmacs) but "E-v"
> do not paste, but move, while "E-r" clears the primary clipoard
> instead of redoing...
> 
> I can make pages of this.

You may be right, but I have a great difficulty to choose.
As soon as I choose for Emacs-style, M$-style, etc.,
then I will get many complaints. As soon as I support all
at the same time, we risk confusion. This is really the hardest
part of designing good keyboard shortcuts.

> BTW: I still do not understand the interest of Clear as in "Clear
> Clipboard". Maybe a "Clear Clipboards" could be useful to free some
> memory after some intensive processing could be useful... but really I
> do not see the point of being able to clear clipboard individually.

Just as I did not see the point of having individual "Cut to clipboard"'s
until some user requested this...

By the way, I also intend to implement multiple active selections:
one in red, one in blue, etc. This can be very useful for certain
complex operations and we should already think about how to make
that fit into the Edit menu.

> BTW: superscripting is often useful in text mode too...

Yes, but it has a different functionality, since recursive superscripting
is not allowed; also it is usually rather seen as a property of the font.
But you are right that we should keep this in mind.

> > Right, there is still some confusion here, also because footnotes are
> > not exactly implemented in the way that they should be.
> 
> I see no confusion here. It seems to me that a footnote is very much
> logical markup, and it seems very unlikely to me that users would use
> the low-level footnate facility even if it was implemented as it
> should be.

No, it is physical markup: you say that this part of text should be
displayed at the bottom(s) of the page(s). What would be logical
markup is something like "more-details" which corresponds to
more detailed information about a piece of text or "extra-notes"
which gives addional less important information. This would usually
physically appear in a footnote, but one might also imagine that
it shows up in a popup or another way...

> I keep on disliking being able to have some inline content applied
> paragraph markup.

I think that you are somehow right here; maybe we should really have
environment variables for such markup. However, the variables are
not inherited; they are really attributes like in XML.

> The editor should really know better (center should
> span paragraphs, indentiation flags should be on the ends, etc...).
> The right implementation should allow intelligent merging and
> splitting of paragraph, and easy insertion of text at the ends of the
> paragraph...

There is a similar problem with page breaking penalties by the way.
I am still thinking about better schemes, but we will not be able to
change this in the near future. You should first finish the rewriters;
next we will improve the typesetter again.

> > 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 would rather have a very different layout in Preamble mode. Giving
> easy access to TeXmacs primitives, and secondary access to everything.

Some other orthogonal modes: Mail, Presentation, ...

No, I think that it is impossible to let everything fit into
a rigid scheme. But we can do part of what you say:
I agree that if we are inside a tree inside a table,
it makes sense not to show the table menu.
This is even more important for the iconbars by the way.

> > > > 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.
> 
> Here, AbiWord has a plain classic "Page Setup..." item in the file
> menu and no "Printer settings" item I can see.
> 
> Using version 1.0.2.

OK, so let's call it "Page setup" then.