Re: 'math-mode' and Insert-Math-AMS_Multline etc
On Fri, 12 Dec 2003, Andre Poenitz wrote:
On Fri, Dec 12, 2003 at 03:06:12PM +0100, Christian Ridderström wrote:
This is about a _minor_ problem, for now I'm really only planning to
bugzilla and forget about it.
However, if you already are in math-mode, you accidentally insert a
\textrm{} into the mathInset which in IMO is a bug.
One solution is to replace the command 'math-mode' with
something like 'ensure-math-mode'? Is there such an LFUN?
Which makes me think why is it that 'math-mode' in a math-inset
actually inserts a \textrm{}?
Shouldn't the LFUN be named something like 'math-mode-toggle' then?
This LFUN 'overload' is a mess and I would not mind removing it at once.
Last time I tried I got heavy flak, though...
yes... it does seem to be a mess with the LFUN, and it makes me
wonder what the purpose of the LFUNs really is, but I'll raise that
question in a different thread I think.
Some long-term solutions I can think of include:
* Modify behaviour of math-mode and math-display, i.e. let them take an
argument specifying if this is 'ensure-math-mode' or 'toggle-math-mode'
* Create 'ensure-math-mode' and 'ensure-math-display'
* If (when) key-bindings and menu-actions are mode sensistive, I guess
different command sequences can be used.
* If/when we get some kind of scripting language, the command-sequences
could check what the mode is and behave differently.
anyway, I've filed this as a minor bug, so this problem shouldn't be
forgotten at least.
/Christian
--
Christian Ridderström http://www.md.kth.se/~chr
Which name is supposed to define the intended behaviour of an LFUN?
I know that an LFUN is a lyx-function and a little more: http://wiki.lyx.org/pmwiki.php/Devel/LFUNs From lfuns.h I get: * These are all the lyx functions, the main mechanism * through which the frontends communicate with the core. * * They are managed in LyXAction.C and handled in various * ::dispatch() functions, starting with LyXFunc.C:dispatch() So far it seems clear as crystal, but looking at the enum names and the strings for the user commands I get confused. Which one is supposed to define(*) the intended behaviour of the LFUN? A function such as LFUN_QUIT / lyx-quit is straight forward, it's a command to the core to do quit, and both names indicate this. However, LFUN_HOME / line-begin is less clear to me. The enum name makes me think of the Home-key, and the intended behaviour of that key can be ambiguous - in Emacs it goes to the beginning of the buffer, and in XEmacs it goes to the beginning of the line. Consider the user command instead: It's obvious that line-begin means go to the beginning of a line in 'textEd'. However, it is less obvious that line-begin in mathEd actually means the behaviour it currently has: Go to the beginning of the current math-inset, unless already at the beginning and not at the root inset, in which case go up one level. Note that this is not a complaint about what happens when you press the Home-key in mathEd or textEd, but that I'm confused about which name is supposed to define/indicate the intended behaviour of the function. confused /Christian (*) I mean define in the sense that I think the name, either of the enum, or of the command string should be clearly connected to the intended action of the LFUN. -- Christian Ridderström http://www.md.kth.se/~chr
using ert-insert with self-insert in mathEd
I just came a across something that I think might be a bug in mathEd, that's related to self-insert. If you do this command sequence: command-sequence ert-insert; self-insert texCmd you don't end up with \texCmd, but Instead with texCmd Although there is a '\' at the beginning, it will actually disappear when you pass through it with the cursor. However, if you do: command-sequence ert-insert; self-insert t; self-insert e; self-insert x; self-insert C; self-insert m; self-insert d; you do get \texCmd as desired. Anyway, should I bugzilla this as a minor thing? Btw, I was actually expecting this to work (wishful thinking?): command-sequence ert-insert texCmd; /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: [PATCH] frameless boxes for tex2lyx
Am Freitag, 12. Dezember 2003 12:41 schrieb Andre Poenitz: Would be nice if your comment lines would not exceed 72 char or so. You mean like this +/*! + * Translates a LaTeX length into \param value, \param unit and + * \param special parts suitable for a box inset. + * The difference from translate_len() is that a box inset knows about + * some special units that are stored in \param special. + */ instead of +/*! + * Translates a LaTeX length into \param value, \param unit and \param special parts + * suitable for a box inset. + * The difference from translate_len() is that a box inset knows about some special + * units that are stored in \param special. + */ Is the reason better readability in mails or something else? I'll try to remember. Georg
Re: InsetBox and format 227
Am Donnerstag, 11. Dezember 2003 19:47 schrieb Jose' Matos: - lyxconvert_xxx.py converts from xxx format to its successor. - lyxrevert_xxx.py reverts from xxx format to its predecessor. Do you want me to put this comment in lyx2lyx? Yes, please. Georg
Re: Which name is supposed to define the intended behaviour of an LFUN?
Christian Ridderström wrote:
So far it seems clear as crystal, but looking at the enum names and
the strings for the user commands I get confused. Which one is
supposed to define(*) the intended behaviour of the LFUN?
That's clear. LyX acts on LFUN_QUIT. lyx-quit is simply translated
to LFUN_QUIT so that the core knows what to do with it.
Anyway, what really _defines_ LFUN_QUIT is the block of code that is
acted on in the switch:
switch (action) {
...
case LFUN_QUIT:
QuitLyX();
break;
So, if you really want to know, read the source.
--
Angus
Re: [PATCH] CollapseStatus
On Sat, Dec 13, 2003 at 06:08:34PM +0100, Michael Schmitt spake thusly: - In the edit menu, we add a submenu to toggle between all possible modes. ...so as to be able to postpone this chore a little. Hmmm... What does that mean? Do you like the idea - or not? I am not opposed to it, if that's what you mean. Personally I wouldn't bother though, especially not for insets that don't already have a dialog. But hey, it's you doing the work. And we will need a fast non-dialog way to set the display mode anyway -- through the dialog it will take two (or even three) mouse clicks. Regards, Michael -- Martin Vermeer [EMAIL PROTECTED] Helsinki University of Technology Dept. of Surveying, Inst. of Geodesy P.O. Box 1200, FIN-02015 HUT, Finland :wq pgp0.pgp Description: PGP signature
LyX Note inset bugs
This is with the latest CVS LyX: Create a new document. Insert-Note-LyX Note put anything in the note. Save the document. Quit. LyX crashes. Now, use LyX to open the same document. On the console, you will see: InsetCollapsable::Read: Missing 'status'-tag! BufferView::Pimpl::fitCursor. Redraw screen The status-tag message is pointing to a bug. I don't think that a Note inset can be closed right now. In fact, open the attached document, close the inset by clicking on it and save the document. Now, re-open the document and you will see the same status message (and the inset is again open). ---Kayvan #LyX 1.4.0cvs created this file. For more info see http://www.lyx.org/ \lyxformat 227 \textclass article \language english \inputencoding auto \fontscheme default \graphics default \paperfontsize default \papersize Default \paperpackage a4 \use_geometry 0 \use_amsmath 1 \use_natbib 0 \use_numerical_citations 0 \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \defskip medskip \quotes_language english \quotes_times 2 \papercolumns 1 \papersides 1 \paperpagestyle default \tracking_changes 0 \end_header \begin_layout Standard \begin_inset Note Note Note status open \begin_layout Standard Test \end_layout \end_inset \end_layout \end_document
Re: 'math-mode' and Insert->Math->AMS_Multline etc
On Fri, 12 Dec 2003, Andre Poenitz wrote:
> On Fri, Dec 12, 2003 at 03:06:12PM +0100, Christian Ridderström wrote:
> > This is about a _minor_ problem, for now I'm really only planning to
> > "bugzilla and forget" about it.
> >
> > However, if you already are in math-mode, you accidentally insert a
> > \textrm{} into the mathInset which in IMO is a bug.
> >
> > One solution is to replace the command 'math-mode' with
> > something like 'ensure-math-mode'? Is there such an LFUN?
> >
> > Which makes me think why is it that 'math-mode' in a math-inset
> > actually inserts a \textrm{}?
> > Shouldn't the LFUN be named something like 'math-mode-toggle' then?
>
> This LFUN 'overload' is a mess and I would not mind removing it at once.
> Last time I tried I got heavy flak, though...
yes... it does seem to be a mess with the LFUN, and it makes me
wonder what the purpose of the LFUNs really is, but I'll raise that
question in a different thread I think.
Some long-term solutions I can think of include:
* Modify behaviour of math-mode and math-display, i.e. let them take an
argument specifying if this is 'ensure-math-mode' or 'toggle-math-mode'
* Create 'ensure-math-mode' and 'ensure-math-display'
* If (when) key-bindings and menu-actions are mode sensistive, I guess
different command sequences can be used.
* If/when we get some kind of scripting language, the command-sequences
could check what the mode is and behave differently.
anyway, I've filed this as a minor bug, so this problem shouldn't be
forgotten at least.
/Christian
--
Christian Ridderström http://www.md.kth.se/~chr
Which name is supposed to define the intended behaviour of an LFUN?
I know that an LFUN is a lyx-function and a little more: http://wiki.lyx.org/pmwiki.php/Devel/LFUNs >From lfuns.h I get: * These are all the lyx functions, the main mechanism * through which the frontends communicate with the core. * * They are managed in LyXAction.C and handled in various * ::dispatch() functions, starting with LyXFunc.C:dispatch() So far it seems clear as crystal, but looking at the enum names and the strings for the user commands I get confused. Which one is supposed to "define"(*) the intended behaviour of the LFUN? A function such as LFUN_QUIT / "lyx-quit" is straight forward, it's a command to the core to do quit, and both names indicate this. However, LFUN_HOME / "line-begin" is less clear to me. The enum name makes me think of the Home-key, and the intended behaviour of that key can be ambiguous - in Emacs it goes to the beginning of the buffer, and in XEmacs it goes to the beginning of the line. Consider the user command instead: It's obvious that "line-begin" means go to the beginning of a line in 'textEd'. However, it is less obvious that "line-begin" in mathEd actually means the behaviour it currently has: Go to the beginning of the current math-inset, unless already at the beginning and not at the root inset, in which case go up one level. Note that this is not a complaint about what happens when you press the Home-key in mathEd or textEd, but that I'm confused about which name is supposed to "define/indicate" the intended behaviour of the function. confused /Christian (*) I mean "define" in the sense that I think the name, either of the enum, or of the command string should be clearly connected to the intended action of the LFUN. -- Christian Ridderström http://www.md.kth.se/~chr
using ert-insert with self-insert in mathEd
I just came a across something that I think might be a bug in mathEd, that's related to self-insert. If you do this command sequence: command-sequence ert-insert; self-insert texCmd you don't end up with \texCmd, but Instead with texCmd Although there is a '\' at the beginning, it will actually disappear when you pass through it with the cursor. However, if you do: command-sequence ert-insert; self-insert t; self-insert e; self-insert x; self-insert C; self-insert m; self-insert d; you do get \texCmd as desired. Anyway, should I bugzilla this as a minor thing? Btw, I was actually expecting this to work (wishful thinking?): command-sequence ert-insert texCmd; /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: [PATCH] frameless boxes for tex2lyx
Am Freitag, 12. Dezember 2003 12:41 schrieb Andre Poenitz: > > Would be nice if your comment lines would not exceed 72 char or so. You mean like this +/*! + * Translates a LaTeX length into \param value, \param unit and + * \param special parts suitable for a box inset. + * The difference from translate_len() is that a box inset knows about + * some special "units" that are stored in \param special. + */ instead of +/*! + * Translates a LaTeX length into \param value, \param unit and \param special parts + * suitable for a box inset. + * The difference from translate_len() is that a box inset knows about some special + * "units" that are stored in \param special. + */ Is the reason better readability in mails or something else? I'll try to remember. Georg
Re: InsetBox and format 227
Am Donnerstag, 11. Dezember 2003 19:47 schrieb Jose' Matos: > - lyxconvert_xxx.py converts from xxx format to its successor. > - lyxrevert_xxx.py reverts from xxx format to its predecessor. > > Do you want me to put this comment in lyx2lyx? Yes, please. Georg
Re: Which name is supposed to define the intended behaviour of an LFUN?
Christian Ridderström wrote:
> So far it seems clear as crystal, but looking at the enum names and
> the strings for the user commands I get confused. Which one is
> supposed to "define"(*) the intended behaviour of the LFUN?
That's clear. LyX acts on LFUN_QUIT. "lyx-quit" is simply translated
to LFUN_QUIT so that the core knows what to do with it.
Anyway, what really _defines_ LFUN_QUIT is the block of code that is
acted on in the switch:
switch (action) {
...
case LFUN_QUIT:
QuitLyX();
break;
So, if you really want to know, read the source.
--
Angus
Re: [PATCH] CollapseStatus
On Sat, Dec 13, 2003 at 06:08:34PM +0100, Michael Schmitt spake thusly: > >> - In the "edit" menu, we add a submenu to toggle between all possible > >> modes. > > > > ...so as to be able to postpone this chore a little. > > Hmmm... What does that mean? Do you like the idea - or not? I am not opposed to it, if that's what you mean. Personally I wouldn't bother though, especially not for insets that don't already have a dialog. But hey, it's you doing the work. And we will need a fast non-dialog way to set the display mode anyway -- through the dialog it will take two (or even three) mouse clicks. > Regards, Michael > -- Martin Vermeer [EMAIL PROTECTED] Helsinki University of Technology Dept. of Surveying, Inst. of Geodesy P.O. Box 1200, FIN-02015 HUT, Finland :wq pgp0.pgp Description: PGP signature
LyX Note inset bugs
This is with the latest CVS LyX: Create a new document. Insert->Note->LyX Note put anything in the note. Save the document. Quit. LyX crashes. Now, use LyX to open the same document. On the console, you will see: InsetCollapsable::Read: Missing 'status'-tag! BufferView::Pimpl::fitCursor. Redraw screen The "status"-tag message is pointing to a bug. I don't think that a Note inset can be closed right now. In fact, open the attached document, close the inset by clicking on it and save the document. Now, re-open the document and you will see the same "status" message (and the inset is again open). ---Kayvan #LyX 1.4.0cvs created this file. For more info see http://www.lyx.org/ \lyxformat 227 \textclass article \language english \inputencoding auto \fontscheme default \graphics default \paperfontsize default \papersize Default \paperpackage a4 \use_geometry 0 \use_amsmath 1 \use_natbib 0 \use_numerical_citations 0 \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \defskip medskip \quotes_language english \quotes_times 2 \papercolumns 1 \papersides 1 \paperpagestyle default \tracking_changes 0 \end_header \begin_layout Standard \begin_inset Note Note Note status open \begin_layout Standard Test \end_layout \end_inset \end_layout \end_document
