Re: [Texmacs-dev] Reorganization of the menus

[Joris van der Hoeven]

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

Yes, we still need a good name here...

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

Yep.

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

OK, so this should be done. Can you make up a small list with all items
which remain to be done on the wiki, so that I can quickly fix them
as soon as I have time?

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

You may design an M$-like look and feel.

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

You may want to clear the primary clipboard without clearing
the others though (and similarly for all other clipboards with
a special semantics w.r.t. the GUI).

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

For instance: swapping two selections,
or expanding a mathematical expression w.r.t. a selected variable or
substituting a variable by an expression in another expression.

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

-> list above.

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

Will be rediscussed later.

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

OK, later.

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

Yes, but after 0.1.1.

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

-> above list.