Re: [Texmacs-dev] Reorganization of the menus

[David Allouche]

As you may have noticed, I am back from holidays, with renewed energy.
Before starting new work, I want to answer all that old mail which is
cluttering my inbox.

So, let us go on with a revival of the menu items discussion.


On Thu, Aug 01, 2002 at 04:21:04PM +0200, Joris van der Hoeven wrote:
> 
> > 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.

Okay.


> > 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.

That is right. When I wrote that mail I forgot that setting default
values for document variables in the style files could be very useful.

So it does make sense to put a "Default" menu item for every document
property, but the menu must also make it clear what value is the
default (as it does in 1.0.0.17). Fine.

 
> > 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.

I forgot the context... I think that my previous proposal was wrong...
I may come back with something else later.

 
> > 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.

Agreed. That is even clearer now that the new menu shortcut system
make Edit->Copy and "Edit->Copy to->Primary" have the
same shortcut, thus making it obvious that they are different names
for the same action.

However I want to point out that is only obvious because you can see
the two menu items at the same time! So that kind clueing must not be
abused.


> > Or "Secondary Clipboard" (etc.), or maybe just plain "Secondary"...
> > not sure of this one...
> 
> Maybe "Main clipboard", "Second clipboard", "Third clipboard",
> "Other clipboard".

Maybe talk again of that issue later.

 
> > 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.

You really should know emacs better.

In isearch, "C-g" *cancels* the search, moving the point back in its
orginal position before the search started. But "enter" *validates*
the search, putting the mark at the previous position and placing the
point where the isearch left the caret.

So "C-g" and "enter" do different things.

Moreover, I find it very natural to press "return" to complete a
command, and very awkyard to have to type the awful, non-mnemotic,
"C-g".


> > > 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 think we are getting awoy from the original point. So, of course,
different platforms must have different defaults. But we just do not
agree on what the default should be on Unix.
 

> > 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.

Anyway, one has to choose. I admit that the current style may make
some sense to you and to older users of TeXmacs, so it may not be a
good thing to throw it away.

However we may consider making the default someting more familiar to
new users. Of course differents bindings sets should be maintained by
people with a clear vision of what is expected in a given style.

Maybe we should put designing af at least one alternative GUI style on
my short-term agenda and see the user feedback... There would also be
a need for some process in order to make it easier to update alternate
bindings as changes are made to the available commands and to the
primary binding.


> > 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...

Well, multiple clipboards is a widely expected feature in advanced
editors. It does make a lot of sense in some use cases, like
creating documents with redundant content or performing three-ways
rotation of document fragments.

But I really cannot figure out any use case for clearing clipboards,
other than freeing memory and getting a clean state, which are both
best served by a global "Clear clipboards" command.


> 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.

Could you provide a couple of use cases?


> > 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.

Yes, superscripting in text mode would be best designed as a font
property. The typesetter would have to provide special support for
this feature, but it would indeed make it impossible to have recursive
superscripts.

I do not know well enough how TeXmacs font handling works to do it
myself. I just hope you will address this sometime soon.


> > > 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...

You are right, so "Footnote" stays in "Insert".
 
> > 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.

I do not understand what you mean here.

> > 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.

Well, I admit that problem is not really critical, and fixing it can
wait for after the new stylesheet system is implemented, since then a
lot of things will be easier.


> > > 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.

Agreed.

Yet I think you missed my point about preamble. I think that in
preamble mode it should be easy to insert all primitives, and less
easy to insert logical structure. For example "Insert->Macro",
"Insert->Header and footer" and especially "Insert->Executable" should
be moved upwards, maybe even to top-level menus, and sectioning,
environment, contents tags, theorems, etc. could be made less
accessible.


> > > > > 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.

I take note you agreed on a "Page setup" item... I would have to
synthetize all that have been said on that point before making a new
suggestion.

-- 
_.      _    .   GNU TeXmacs -- Writing is a pleasure.
 |\     |    |\       Home page -- http://www.texmacs.org
 | \ ,-.|,--.| \      Resources -- http://alqua.com/tmresources
 |  \|  |,-+||--\            TeXmacs is NOT a LaTeX front-end
-+--'`- \`-'\-   -           and is unrelated to emacs.