Re: [Texmacs-dev] Reorganization of the menus

[Joris van der Hoeven]

> > > I agree that other languages (esp. French, where the convention is to
> > > capitalize only the first letter) can have other conventions, but I do
> > > not see why that should prevent us from doing the right thing for
> > > English.
> > 
> > Because Macintosh has no patent on "the right thing".
> 
> Once again, that rule is also used in the KDE User Interface Guideline
> and in Microsoft applications, and in any other professional
> application I checked.
> 
> Maybe you should realize that you, neither, have the patent on "the
> right thing".

No, but I have the right to make the application please me
as much as possible. I hate abusive capitalization in titles,
whether they occur in GUI's or in scientific papers.
There are people who share my opinion and there are others who don't.
So there is no "right thing" here. You claimed proposing
the right thing; I never did: I just say what I like most.

> > > Actually, "Revert...".
> > 
> > You mean "Revert"?
> > What about Reload by the way?
> 
> No, I do mean "Revert...". In my first message I explained that, in
> principle, menu items which simply show a confirmation dialog should
> not be followed by ellipsis, but since at the moment everything is
> done modelessly in the minibuffer it is good to break that rule so
> that the user know when to look at the minibuffer.

But there is no dialogue box nor confirmation message at all
at the moment... Hmm, but you are right if you say that
there should be..

> I do not like "Load..." and "Reload".
> 
> Every professional software use "Open..." and "Revert".
> 
> Users do not say "I load a file" but "I open a document", neither they
> say "I reload a dirty file in the buffer" but "I revert to the last
> saved version".

I'm not sure; in all web browsers I know of the similar functionality
is called Reload.

> That makes me think of the TeX vs WYSIWYG argument. Emacs was unable
> to use dialogs for long, so its user tend to think that not using
> dialog in the only Right Way, in the same manner as typesetting
> systems were not able to be WYSIWYG for long so their user developped
> a rationale for why that is a good thing.

Yes, but sometimes these rationales really exist.
I agree that dialogue boxes are fine for certain operations,
but using the footer has one big advantage:
it does not screw up the screen. The main disadavantage
is that you do not have a global view of what you are doing
in the case when you have to enter several things with
possible optional arguments. It therefore seems that
the footer is well-suited for very simple operations,
when you know precisely what you are doing.
For complex operations or in the case of non expert users,
dialogue boxes are better.

> So, one page size in the "File->Page Setup" menu (which is actually a
> persistent application setting with the system setting as a default),
> and another in the Document menu (which is a document setting).

Right.

> It is interesting if the
> application does have some advanced page swapping features like
> printing two pages by sheet or producing booklets (then the paper
> thickness must be taken in account to correct the margins).

Yes, I want to add these too; there are some standard
postscript filters for that. I have to add 

> But it does make some kind of sense if there is a meaningful system
> paper size. Is it really the case on GNU/Linux?

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

> But I really do not think that there is a need for a "Default
> Orentation".

We have to be consistent.
By the way, one may also have Seascape and Upside-down.

> > It allows you to see a text as an image.
> 
> I am absolutely not convinced it is a useful feature. All the
> PostScript files I have seen in my life were paginated.
> 
> But if you have the use for this feature, that is an obvious proof it
> can be useful.

I once had a use for it, but for simplicity we might leave it out.

> > You want to make this modification in the file chooser?
> > Don't forget to keep a "By extension" or "Automatic" option.
> 
> Well, I could do it when I have the time. Probably not anytime soon.
> But since you wanted me to give all my propositions, I did so.

This is not urgent. We can leave things as they are now and
do this when you have time.

> > Another idea: would it be somehow possible to merge "Export" and
> > "Copy to" together, as well as "Import" and "Paste from"?
> 
> There could be several possibilities:
> 
>   Having Import put the imported document at the position of the
>   cursor. I am not sure that is a good idea. For example, how would
>   the documentclass of imported LaTeX document be handled? And haw
>   would formats which rely on specific packages (like HTML) would be
>   imported?

I meant "Import from clipboard" and "Export to clipboard".

>   Symmetrically having export only export the selection (region). I am
>   not sure that is a good idea for similar reasons.
> 
>   "Export clipboard" and "Import clipboard" stateless commands to
>   perform a conversion on the content of the clipboard. Generally,
>   that would be less convenient than the current stateful behaviour.
>   That will probably become more useful the day we have intelligent
>   cut'n'paste with other programs.

Also notice that we may keep the option to set the default behaviour
in the preferences.

> I still think the current commands are fine. The only issues I see are
> with their naming and their location in the menu hierarchy.

My concern is to keep the Edit menu reasonably short.

> > I think that it is good to have Cancel => Clear
> 
> Could you explain me why Cancelling a spell check or an interactive
> minibuffer should ever clear my precious clipboard?

I use C-c for this. But it is true that this is not very clear.
I also wanted a simple keystroke for "Clear". Maybe we should
make C-g do a Cancel in your sense and C-z a real clear.
What is commonly used for Clear as a keyboard shortcut?

Also, what about putting "Cancel" just after "Undo" and "Redo"
at the top of the "Edit" menu?

> > > Ok! So there is a bug. Move does not work when the caret is after the
> > > end of the selection, and in the same STRING block as the selection.
> > > That was the first thing I tried, and since it did not move I was
> > > perplexified.
> > 
> > Please give me a more precise example; I failed to reproduce this bug.
> 
> Create a new document. Type "Hello World.". Select "Hello" using the
> mouse. *Quickly* click at the end of the line, select move. If the
> click is too late, the command works as expected. It seems the problem
> appears when the delay between clicks is close to the double-click
> time.

Strange; please put this on the bug list...

> > > And I disagree with you about changing paste to move. Paste is not
> > > expected to remove the selection. Move is fine as it is, it just need
> > > to be fixed. Hopefully, one day this feature can be implemented by
> > > drag'n'drop.
> > 
> > This is not what I say: the name of the menu item remains Paste,
> > but its action in case of an active selection is Move.
> 
> That would be giving Cut semantics (removing the selection) to Paste.
> It seems obvious it is a bad thing. One expected behaviour would be to
> overwrite the selection by the contents of the clipboard.

You are right that this is another possible interpretation
(more M$ than Unix style); this should be called "Replace selection".

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.

> But actually the problem may be more to decide which kind of selection
> semantics we want to use by default. X11 semantics, where selecting is
> implicitely copying? Or Macintosh (and basically the rest of the word
> including Windows and Mozilla) semantics where copying must be
> explicit?
> 
> Most GNU/Linux apps, even KDE and GNOME ones (but, interestingly, not
> AbiWord) just do not seem to be able to decide. That leads to various
> mixes of the two semantics which I keep finding confusing.

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.

> > No, then we should keep it in the Insert menu,
> > because images can also be inserted in Math mode.
> 
> Is that useful? In which context? Is would it not be better to ask for
> an embedded text environment, just as an embedded math environment is
> required if one want to insert symbols in a text?

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.

> So you agree that page insertions should go in the Structure menu?

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

> > > > > Header and footer insertion commands should be moved out of the
> > > > > Document->page menu and to the Insert menu.
> > 
> > You are right from a technical point of view, but I am not sure that
> > users will intuitively search for these issues in the Insert menu.
> > In current applications, it is often part of the Edit menu.
> 
> Anyway, it is much more intuitive there than buried in a fourth level
> submenu of the Document menu!

OK, lets put it in Insert.

> > Things might become possibile with a format menu.
> > We should examine that possibility.
> 
> I would not mind moving them in another menu later, but at the moment
> I just think you are confusing the discussion with that "Format" menu.

Yes, Format should only insert with-like structure.

> > > I can think of no other menu to put them in, and obviously these are
> > > inserstions, preamble mode is orthogonal to the context mode so they
> > > cannot be put in the Structure/Mathematics mode-local menu.
> > 
> > Another possible menu would be a top level menu for editing
> > in preamble mode. This is probably a good idea anyway.
> 
> So? Do you want MORE or LESS top level menus? You are confusing the
> discussion.

Less, but I also want clean semantics.
Yes, the trade-off is difficult.

I think that an extra menu in preamble mode is acceptable,
because only expert users will really need it.

> > Yes, but there are less obvious entries like abbr, dfn and acronym,
> > which are not available on the iconbar.
> 
> Which, anyway, are available nowhere but by using keybindings or
> cammand names. Please stop trying to confuse me.

Don't be confused; you will just happen to find them
in the Text menu soon :^)

> > And Tree, when it will be ready? That one will be orthogonal too.
> > I can come up with dozens of such things...
> 
> And a Tree in an Equation in a Table in a Structure?

Yes! You will need to buy a larger screen!

> > > Settings->printer items should be in "Files->Page Setup..."
> > 
> > I don't like your "Files->Page setup" menu.
> 
> I'll be back.

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

> > > One thing, though: I think "View->load in new window" should be in the
> > > File menu as "Open in New Window.." after "Open...".
> > 
> > And "Clone buffer"?
> 
> You mean "Clone Window"? It should stay in the View menu since it is
> not related to opening or closing buffers, just to managing views.

I'll rethink about this.