Re: [PATCH] change semantics of "delete" LFUNs again (was: Re: Assertion from command-sequence)

On Sun, 2022-12-04 at 22:14 +0100, Jean-Marc Lasgouttes wrote: > > On the other hand I was concerned with encoding a text message in > > integer number that in Python is infinite precision: > > You lost me here. > > JMarc That is a way to pass a a light message (season's greetings) into a seriou

Re: [PATCH] change semantics of "delete" LFUNs again (was: Re: Assertion from command-sequence)

Le 04/12/2022 à 22:13, José Matos a écrit : On Sun, 2022-12-04 at 21:12 +0100, Jean-Marc Lasgouttes wrote: I finally managed to convinced python to like me, and pushed the result. JMarc Nice, I intended to look into this issue this weekend. Let's say I believe you ;) On the other hand I w

Re: [PATCH] change semantics of "delete" LFUNs again (was: Re: Assertion from command-sequence)

On Sun, 2022-12-04 at 21:12 +0100, Jean-Marc Lasgouttes wrote: > I finally managed to convinced python to like me, and pushed the > result. > > JMarc Nice, I intended to look into this issue this weekend. On the other hand I was concerned with encoding a text message in integer number that in Py

Re: [PATCH] change semantics of "delete" LFUNs again (was: Re: Assertion from command-sequence)

On Sun, Dec 04, 2022 at 09:12:45PM +0100, Jean-Marc Lasgouttes wrote: > Le 02/12/2022 à 18:11, Scott Kostyshak a écrit : > > > Just as a reminder, the goal is to have char-delete-backwards without > > > argument actually delete previous element, without consideration of > > > confirmation that are

Re: [PATCH] change semantics of "delete" LFUNs again (was: Re: Assertion from command-sequence)

Le 02/12/2022 à 18:11, Scott Kostyshak a écrit : Just as a reminder, the goal is to have char-delete-backwards without argument actually delete previous element, without consideration of confirmation that are only relevant to interactive use. Sorry, I have no experience with this. Once sorted

Re: [PATCH] change semantics of "delete" LFUNs again (was: Re: Assertion from command-sequence)

On Mon, Nov 28, 2022 at 05:40:44PM +0100, Jean-Marc Lasgouttes wrote: > Le 21/02/2022 à 15:10, Jean-Marc Lasgouttes a écrit : > > Le 21/02/2022 à 03:27, Scott Kostyshak a écrit : > > > On Sun, Feb 20, 2022 at 07:20:24PM +0100, Jean-Marc Lasgouttes wrote: > > > > I really wonder why this special beh

Re: [PATCH] change semantics of "delete" LFUNs again (was: Re: Assertion from command-sequence)

ge semantics of "delete" LFUNs again Instead of specifying "force" to disable the deletion protection mechanism, invert the default so that "confirm" is needed to activate it. The idea is to keep the lfun reasonable for scripting and add a special argument for interact

Re: [PATCH] change semantics of "delete" LFUNs again (was: Re: Assertion from command-sequence)

On Mon, Feb 21, 2022 at 03:10:00PM +0100, Jean-Marc Lasgouttes wrote: > Le 21/02/2022 à 03:27, Scott Kostyshak a écrit : > > On Sun, Feb 20, 2022 at 07:20:24PM +0100, Jean-Marc Lasgouttes wrote: > > > I really wonder why this special behavior is by default, since it is only > > > useful for interac

[PATCH] change semantics of "delete" LFUNs again (was: Re: Assertion from command-sequence)

ughts? JMarcFrom 1eb6a6da66ad3f73bd37bf63033579dcefa56074 Mon Sep 17 00:00:00 2001 From: Jean-Marc Lasgouttes Date: Mon, 21 Feb 2022 14:00:14 +0100 Subject: [PATCH] Fixup 71623b88: change semantics of "delete" LFUNs again Instead of specifying "force" to disable the deletion pro

Re: [LyX/master] Document new behavior of "delete" LFUNs

Le 06/04/2017 à 06:41, Scott Kostyshak a écrit : commit 22c4a24a360b4607551ff5275cf24ac5f5e5eb4a Author: Scott Kostyshak Date: Thu Apr 6 00:34:51 2017 -0400 Document new behavior of "delete" LFUNs - Describe the change in RELEASE-NOTES. - Update the example for in

Re: About WORD_FIND* LFUNs

Tommaso Cucinotta wrote: > I'm attempting a refactoring of these, but some feedback from the list would > be useful in terms of: > a) do we really need all of these LFUNs just to support simple search ? I can imagine WORD_FIND_FORWARD being used by scripts through lyx server where

About WORD_FIND* LFUNs

C-F and I find a string, then I use word-find-fwd, nothing happens, but I'd expect to keep searching fwd (or bwd, if I use the other lfun). I'm attempting a refactoring of these, but some feedback from the list would be useful in terms of: a) do we really need all of these LFUNs just

Help texts for LFUNs etc (Was: Starting Development)

On Mon, 18 May 2009, Jean-Marc Lasgouttes wrote: "Vincent van Ravesteijn - TNW" writes: I thought it would look good to show it in a little LyX-buffer. I fear it could look clunky... And the data could be useful in the binding editor too. Do you have an idea how to do integrate it into the

Re: [PATCH] r28814: inset-begin/end lfuns

Edwin Leuven writes: > jean-marc wrote: >> the following patch [...] implements inset-begin/end which >> do not exactly do what you think they do ;) > > perhaps they need different names then? inset-goto-begin/end ... Well, they look like buffer-begin or line-begin. The only difference is that

RE: [PATCH] r28814: inset-begin/end lfuns

jean-marc wrote: > the following patch [...] implements inset-begin/end which > do not exactly do what you think they do ;) perhaps they need different names then? inset-goto-begin/end ...

[PATCH] r28814: inset-begin/end lfuns

I committed the following patch which implements inset-begin/end which do not exactly do what you think they do ;) For example, for buffer-begin - if cursor is in the middle go to the beginning of the inset - if it is already at the beginning, go at the beginning of the enclosing inset This is in

Re: [PATCH] bug 1784: Saving with LFUNS breaks the serverpipes

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> schrieb: > Enrico Forestieri <[EMAIL PROTECTED]> writes: >> On Thu, Oct 02, 2008 at 04:40:05PM +0200, Jean-Marc Lasgouttes wrote: >>> Enrico Forestieri <[EMAIL PROTECTED]> writes: >>> I think your patch is the right one. I'll wait until Günter can test it.

Re: [PATCH] bug 1784: Saving with LFUNS breaks the serverpipes

Enrico Forestieri <[EMAIL PROTECTED]> writes: > On Thu, Oct 02, 2008 at 04:40:05PM +0200, Jean-Marc Lasgouttes wrote: >> Enrico Forestieri <[EMAIL PROTECTED]> writes: >> > I admit that the code is not very clear as the test on errno should >> > only be performed if read() returns -1. So, I would r

Re: [PATCH] bug 1784: Saving with LFUNS breaks the serverpipes

On Thu, Oct 02, 2008 at 04:40:05PM +0200, Jean-Marc Lasgouttes wrote: > Enrico Forestieri <[EMAIL PROTECTED]> writes: > > I admit that the code is not very clear as the test on errno should > > only be performed if read() returns -1. So, I would rather propose > > the attached patch. > > I think y

Re: [PATCH] bug 1784: Saving with LFUNS breaks the serverpipes

Konrad Hofbauer <[EMAIL PROTECTED]> writes: > Pavel Sanda wrote: >> Jean-Marc Lasgouttes wrote: >>> [stuff about pipes] > > Since you are looking at pipes right now, I just want to mention > > > I am on the verge of writing myself an external script th

Re: [PATCH] bug 1784: Saving with LFUNS breaks the serverpipes

Enrico Forestieri <[EMAIL PROTECTED]> writes: > I admit that the code is not very clear as the test on errno should > only be performed if read() returns -1. So, I would rather propose > the attached patch. I think your patch is the right one. I'll wait until Günter can test it. JMarc

Re: [PATCH] bug 1784: Saving with LFUNS breaks the serverpipes

Jean-Marc Lasgouttes schrieb: Pavel Sanda <[EMAIL PROTECTED]> writes: unfortunately - after these few last patches are applied and i send echo "LYXCMD:test:buffer-write" to pipe file is correctly saved,but CPU load gets to maximum and stays there. Details please. What are you doing? It might b

Re: [PATCH] bug 1784: Saving with LFUNS breaks the serverpipes

Konrad Hofbauer wrote: Pavel Sanda wrote: Jean-Marc Lasgouttes wrote: [stuff about pipes] Since you are looking at pipes right now, I just want to mention I am on the verge of writing myself an external script that removes the pipe-files at ever

Re: [PATCH] bug 1784: Saving with LFUNS breaks the serverpipes

On Wed, Oct 01, 2008 at 03:59:59PM +0200, Jean-Marc Lasgouttes wrote: > > Here's a patch for a very old bug. It is not the first time that I try > to tackle it, but it only occured to me today that the existing code > tests a value of errno that is probably the result of another IO action > done i

Re: [PATCH] bug 1784: Saving with LFUNS breaks the serverpipes

On Wed, Oct 01, 2008 at 04:24:17PM +0200, Jean-Marc Lasgouttes wrote: > I do not know whether read() can return 0, and what that would mean. When attempting to read from a FIFO, read() returns 0 when: - no process has the pipe open for writing (in this case 0 indicates end-of-file) or - some

Re: [PATCH] bug 1784: Saving with LFUNS breaks the serverpipes

Pavel Sanda wrote: Jean-Marc Lasgouttes wrote: [stuff about pipes] Since you are looking at pipes right now, I just want to mention I am on the verge of writing myself an external script that removes the pipe-files at every LyX-start ... /Konra

Re: [PATCH] bug 1784: Saving with LFUNS breaks the serverpipes

Jean-Marc Lasgouttes wrote: > Pavel Sanda <[EMAIL PROTECTED]> writes: > >> Details please. What are you doing? It might be because I changed > > > > investigating now... > > I see it too. As soon as LyX has acted on one server request, it starts > to have a high load. in the very begining of loa

Re: [PATCH] bug 1784: Saving with LFUNS breaks the serverpipes

Pavel Sanda <[EMAIL PROTECTED]> writes: >> Details please. What are you doing? It might be because I changed > > investigating now... I see it too. As soon as LyX has acted on one server request, it starts to have a high load. JMarc

Re: [PATCH] bug 1784: Saving with LFUNS breaks the serverpipes

fun (buffer-write, for example). pitty you havent said it... i was trying to debug where the errno in buffer-write happens since i thought, its just very old and unappropriate way of locating errs in lfuns... :) > > The patch is tested and works. But since I do not really now much about &

Re: [PATCH] bug 1784: Saving with LFUNS breaks the serverpipes

Jean-Marc Lasgouttes wrote: > Pavel Sanda <[EMAIL PROTECTED]> writes: > > unfortunately - after these few last patches are applied and i send > > echo "LYXCMD:test:buffer-write" to pipe file is correctly saved,but CPU load > > gets to maximum and stays there. > > Details please. What are you doing

Re: [PATCH] bug 1784: Saving with LFUNS breaks the serverpipes

Pavel Sanda <[EMAIL PROTECTED]> writes: > unfortunately - after these few last patches are applied and i send > echo "LYXCMD:test:buffer-write" to pipe file is correctly saved,but CPU load > gets to maximum and stays there. Details please. What are you doing? It might be because I changed if (s

[PATCH] bug 1784: Saving with LFUNS breaks the serverpipes

Here's a patch for a very old bug. It is not the first time that I try to tackle it, but it only occured to me today that the existing code tests a value of errno that is probably the result of another IO action done in the execution of the lfun (buffer-write, for example). The patch is tested an

Documentation of LyX functions (aka LFUNs)

Dear LyXers, I'm proud to announce that the LFUNs documentation project has been finished. If you are interested in mastering LyX this documentation could be useful for your needs. Some technical speech: * All documentation is orginally written as doxygen comments in our source code,

Re: [more updated patch] Bug 4341: LFUNs for Branch (De)Activation

Abdelrazak Younes wrote: rgheck wrote: Here's why I'm unhappy with the patch. It's simple in a way: We have a vector of commands to execute rather than just one---that was the first problem. So now you could do something like: lyx -x "file-open /tmp/branchTest.lyx" -x "buffer-end" -x "break-

Re: [more updated patch] Bug 4341: LFUNs for Branch (De)Activation

rgheck wrote: Here's why I'm unhappy with the patch. It's simple in a way: We have a vector of commands to execute rather than just one---that was the first problem. So now you could do something like: lyx -x "file-open /tmp/branchTest.lyx" -x "buffer-end" -x "break-paragraph" -x "self-insert

Re: [more updated patch] Bug 4341: LFUNs for Branch (De)Activation

rgheck <[EMAIL PROTECTED]> writes: > ...I don't think this will actually be necessary. I don't envisage us > going through LyXFunc::dispatch when we don't have a frontend, but > instead just calling Buffer::dispatch() directly, which is what we > already do. Or do you have something else in mind?

Re: [more updated patch] Bug 4341: LFUNs for Branch (De)Activation

Abdelrazak Younes wrote: rgheck wrote: Jean-Marc Lasgouttes wrote: rgheck <[EMAIL PROTECTED]> writes: OK. So, let me ask the question I asked in another message: Should I just add LFUN_BRANCH_ACTIVATE to BufferView::dispatch() for now, and we can deal with this mess later? With Beta 1 on th

Re: [more updated patch] Bug 4341: LFUNs for Branch (De)Activation

Jean-Marc Lasgouttes wrote: rgheck <[EMAIL PROTECTED]> writes: OK. One other thing, then, before I try to do this. In Application.h, Abdel says that BufferView should provide only const access to its Buffer. Abdel, why is that? Because BufferView is (should be) only about metrics

Re: [more updated patch] Bug 4341: LFUNs for Branch (De)Activation

rgheck wrote: Jean-Marc Lasgouttes wrote: rgheck <[EMAIL PROTECTED]> writes: OK. So, let me ask the question I asked in another message: Should I just add LFUN_BRANCH_ACTIVATE to BufferView::dispatch() for now, and we can deal with this mess later? With Beta 1 on the horizon, it doesn't seem

Re: [more updated patch] Bug 4341: LFUNs for Branch (De)Activation

rgheck <[EMAIL PROTECTED]> writes: > OK. One other thing, then, before I try to do this. In Application.h, > Abdel says that BufferView should provide only const access to its > Buffer. Abdel, why is that? JMarc

Re: [more updated patch] Bug 4341: LFUNs for Branch (De)Activation

y to call Buffer::dispatch() from LyXFunc.h, then I'll need to do something like: view()->buffer()->dispatch(cmd); which will depend upon non-const access. Is this bad? If so, what to do? I committed the other patch separately and will move the LFUNs when this gets done. rh

Re: [more updated patch] Bug 4341: LFUNs for Branch (De)Activation

rgheck <[EMAIL PROTECTED]> writes: > OK. So, let me ask the question I asked in another message: Should I > just add LFUN_BRANCH_ACTIVATE to BufferView::dispatch() for now, and > we can deal with this mess later? With Beta 1 on the horizon, it > doesn't seem like the right time to mess with this p

Re: [more updated patch] Bug 4341: LFUNs for Branch (De)Activation

Jean-Marc Lasgouttes wrote: rgheck <[EMAIL PROTECTED]> writes: ...maybe BufferView is the right place right now. But I still don't quite understand which dispatch() functions do which things, and what the chain of control is supposed to be. So if you (or someone) could explain that, then I th

Re: [more updated patch] Bug 4341: LFUNs for Branch (De)Activation

rgheck <[EMAIL PROTECTED]> writes: > There also seems to be a call to Cursor::dispatch(). Should the Buffer > be tried before or after that? I do not think that the order matters actually, but it would probably be a good idea to go from the most general to the most specific (which does not give a

Re: [more updated patch] Bug 4341: LFUNs for Branch (De)Activation

rgheck <[EMAIL PROTECTED]> writes: > So there are various things you might want to do from the command > line, and they need to be implemented somewhere we don't assume we > have any frontend. That's not generally true in LyXFunc, as you say. > So we should do this stuff somewhere else, and... If

Re: [more updated patch] Bug 4341: LFUNs for Branch (De)Activation

Abdelrazak Younes wrote: rgheck wrote: I guess what I'm not sure about is how and whether to call Buffer::dispatch() from LyXView::dispatch() in a kind of "global" way, yes, that's the idea: - first try theApp() - then LyXView - then BufferView - then Buffer There also seems to be a call to C

Re: [more updated patch] Bug 4341: LFUNs for Branch (De)Activation

rgheck wrote: I guess what I'm not sure about is how and whether to call Buffer::dispatch() from LyXView::dispatch() in a kind of "global" way, yes, that's the idea: - first try theApp() - then LyXView - then BufferView - then Buffer or whether to let it happen more on a case-by-case basis, as

Re: [more updated patch] Bug 4341: LFUNs for Branch (De)Activation

rgheck wrote: ...maybe BufferView is the right place right now. Beware that there is a BufferView only if there is a frontend. Did you read Application.h? I should probably update it a bit but it does explain a few things you want to know. Abdel.

Re: [more updated patch] Bug 4341: LFUNs for Branch (De)Activation

Jean-Marc Lasgouttes wrote: rgheck <[EMAIL PROTECTED]> writes: BUT this will not work when we are exporting. The reason is that when you use the export feature, LyX calls Bufer::dispatch() rather than (say) lyx::dispatch(), and the only thing that previously got handled in Buffer::dispatch()

Re: [more updated patch] Bug 4341: LFUNs for Branch (De)Activation

rgheck <[EMAIL PROTECTED]> writes: > Here's why I'm unhappy with the patch. It's simple in a way: We have a > vector of commands to execute rather than just one---that was the > first problem. So now you could do something like: > lyx -x "file-open /tmp/branchTest.lyx" -x "buffer-end" -x > "bre

Re: [more updated patch] Bug 4341: LFUNs for Branch (De)Activation

rgheck wrote: > Pavel Sanda wrote: >> rgheck wrote: >> >>> Comments welcome, of course. >>> >> >> btw while you are at this - would it be easy to detect buffer export >> problems? >> (http://bugzilla.lyx.org/show_bug.cgi?id=4097) >> >> > Done. It was actually the file load errors that w

Re: [more updated patch] Bug 4341: LFUNs for Branch (De)Activation

Pavel Sanda wrote: rgheck wrote: Comments welcome, of course. btw while you are at this - would it be easy to detect buffer export problems? (http://bugzilla.lyx.org/show_bug.cgi?id=4097) Done. It was actually the file load errors that weren't being reported. Export problems were.

Re: [more updated patch] Bug 4341: LFUNs for Branch (De)Activation

rgheck wrote: > > Comments welcome, of course. btw while you are at this - would it be easy to detect buffer export problems? (http://bugzilla.lyx.org/show_bug.cgi?id=4097) > Index: src/FuncCode.h > === > --- src/FuncCode.h(revis

[more updated patch] Bug 4341: LFUNs for Branch (De)Activation

An even more updated patch, thanks to Pavel's comments. To test it, put branchTest.lyx into /tmp and run: /cvs/lyxsvn/src/lyx -userdir /tmp/test -x "branch-activate test" -e pdf2 /tmp/branchTest.lyx /cvs/lyxsvn/src/lyx -userdir /tmp/test -x "branch-deactivate tester" -e pdf2 /tmp/branchTes

Re: [patch] Bug 4341: LFUNs for Branch (De)Activation

Pavel Sanda wrote: rgheck wrote: Conceptually, this is pretty straightforward, but can someone tell me if this is the right place to implement these? LFUNs are implemented all over, and I don't really understand the logic to what happens where. my understanding is that when you

Re: [patch] Bug 4341: LFUNs for Branch (De)Activation

rgheck wrote: > > Conceptually, this is pretty straightforward, but can someone tell me if > this is the right place to implement these? LFUNs are implemented all over, > and I don't really understand the logic to what happens where. my understanding is that when you don'

[updated patch] Bug 4341: LFUNs for Branch (De)Activation

This now works completely, but I'm not at all sure this is the right way to proceed. To test it, put branchTest.lyx into /tmp/ and run: /cvs/lyxsvn/src/lyx -userdir /tmp/test -x "branch-activate test" -e pdf2 /tmp/branchTest.lyx /cvs/lyxsvn/src/lyx -userdir /tmp/test -x "branch-deactiva

[patch] Bug 4341: LFUNs for Branch (De)Activation

Conceptually, this is pretty straightforward, but can someone tell me if this is the right place to implement these? LFUNs are implemented all over, and I don't really understand the logic to what happens where. Unfortunately, this doesn't seem to answer the 4341 request, since I

Re: Lfuns doxy -> .lyx

> I took a look at the lfuns doxy -> .lyx shell script. I wasn't able to run > it on my computer (I got error messages), but as far as I can tell it takes > the documentation in LyXAction.cpp and converts it into a LyX file. I read a the script itself is little obsolete, so

Lfuns doxy -> .lyx

Hi, I took a look at the lfuns doxy -> .lyx shell script. I wasn't able to run it on my computer (I got error messages), but as far as I can tell it takes the documentation in LyXAction.cpp and converts it into a LyX file. I read a little bit about Doxygen, and it seems that Doxygen ca

Re: doxy lfuns -> .lyx convertor

Pavel Sanda <[EMAIL PROTECTED]> writes: > please, am i allowed to put such kind of beast somewhere in our svn tree (and > where?) First, it would be great to have it in python :) Concerning where, lib/scripts would make sense, but somebody may have a better idea. If this script proves useful,

doxy lfuns -> .lyx convertor

please, am i allowed to put such kind of beast somewhere in our svn tree (and where?) pavel #!/bin/sh cat <

[PATCH] comments on CT-related LFUNs

Sorry, without sophisticated optimizations (which are outside of the scope of 1.5.X), several CT-related LFUNs are always enabled. The attached patch has already been committed. Michael Index: text3.C === --- text3.C (Revision

Re: LFUN question 3: LFUNs for math-mode only?

On Sun, Sep 17, 2006 at 12:04:20AM +0200, [EMAIL PROTECTED] wrote: > On Sat, 16 Sep 2006, Andre Poenitz wrote: > > > On Sat, Sep 16, 2006 at 05:34:37PM +0200, [EMAIL PROTECTED] wrote: > > > The function InsetERT:getStatus() suppress (disable) accents within ERT > > > insets, which makes sense. >

Re: LFUN question 3: LFUNs for math-mode only?

On Sat, 16 Sep 2006, Andre Poenitz wrote: > On Sat, Sep 16, 2006 at 05:34:37PM +0200, [EMAIL PROTECTED] wrote: > > The function InsetERT:getStatus() suppress (disable) accents within ERT > > insets, which makes sense. > > > > But MathNestInset::doDispatch() contains the equivalent of this: > >

Re: LFUN question 3: LFUNs for math-mode only?

On Sat, Sep 16, 2006 at 05:34:37PM +0200, [EMAIL PROTECTED] wrote: > The function InsetERT:getStatus() suppress (disable) accents within ERT > insets, which makes sense. > > But MathNestInset::doDispatch() contains the equivalent of this: > > case LFUN_ACCENT_ACUTE: > bre

Re: LFUN question 3: LFUNs for math-mode only?

On Fri, 15 Sep 2006, Angus Leeming wrote: > [EMAIL PROTECTED] wrote: > > None of the attribues say if an LFUN only works in math-mode, do they? (That > > information might be interesting to tabulate for the users though) > > > > Which of the following LFUNs only

Re: LFUN question 3: LFUNs for math-mode only?

On Sat, Sep 16, 2006 at 12:06:09AM +0200, [EMAIL PROTECTED] wrote: > On Fri, 15 Sep 2006, Jean-Marc Lasgouttes wrote: > > > Angus> Why don't you loop over all commands in the sequence and > > Angus> establish if any actions are disabled? There are no if-blocks to > > Angus> complicate the logic.

Re: LFUN: Check description of accent LFUNs

recognized and spacing is preserved. Useful for very simpel tables, i.e. Column 1 Column 2 column 23 Bla Bla Bla bla @] Having said the above, maybe I should relatively soon do as you suggest and move the documentation to the s

Re: LFUN: Check description of accent LFUNs

Am Freitag, 15. September 2006 23:01 schrieb [EMAIL PROTECTED]: > (In addition, I'm trying to make it as easy as possible for you guys to > check/modify my texts. I think that's easier if I can just link to a wiki > page, or email a piece of text). I don't know how it is for others, but for me

Re: LFUN: Check description of accent LFUNs

ar combining-latin-acute | | Good idea. Would be nice to be able to do soill enable us to also bolt | on a dialog to enable these things to be composed. | | > something like this would superseed the accent lfuns imo. | | But it doesn't negate his opinion that we still need an inset to hold |

Re: LFUN question 3: LFUNs for math-mode only?

[EMAIL PROTECTED] wrote: None of the attribues say if an LFUN only works in math-mode, do they? (That information might be interesting to tabulate for the users though) Which of the following LFUNs only work in math-mode? I'd be grateful if someone can tell me, or tell me how I can fin

LFUN question 3: LFUNs for math-mode only?

l action 1 has been done (for > example, action 1 opens a math inset and action 2 is a math-only > operation). None of the attribues say if an LFUN only works in math-mode, do they? (That information might be interesting to tabulate for the users though) Which of the following LFUNs only

Re: LFUN: Check description of accent LFUNs

On Fri, 15 Sep 2006, Georg Baum wrote: > [EMAIL PROTECTED] wrote: > > > I think I've putten together a decent description of LFUNs like > > accent-acute etc, could someone please check the text. > > > > http://wiki.lyx.org/devel/pmwiki.php/Devel/LyxFunctionL

Re: LFUN: Check description of accent LFUNs

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Incidentally, that's "supercede". But superseed sounds good, at least to some french ears. JMarc

Re: Documenting LFUNs

On Fri, 15 Sep 2006, Jean-Marc Lasgouttes wrote: > > "christian" == christian ridderstrom <[EMAIL PROTECTED]> writes: > > christian> It'll probably take a while to get it documented, but > christian> should the LFUN documentation go into lfuns.h or > christian> LyXAction.C (or some other file

Re: LFUN: Check description of accent LFUNs

On Thu, Sep 14, 2006 at 11:36:02PM +0200, Lars Gullik Bjønnes wrote: > [EMAIL PROTECTED] writes: > > | I think I've putten together a decent description of LFUNs like > | accent-acute etc, could someone please check the text. > > I am not even sure that we should kee

Re: LFUN: Check description of accent LFUNs

us to also bolt on a dialog to enable these things to be composed. something like this would superseed the accent lfuns imo. But it doesn't negate his opinion that we still need an inset to hold multiple code points that can be represented as a single grapheme/glyph. Or do I miss some

Re: LFUN: Check description of accent LFUNs

tten | once in a while too. Yes, but perhaps we should add a way to insert any unicode codepoint and/or sequences. Both numerical and perhaps also textual. unicode-insert # #0302 unicode-inserr non-visible-char combining-latin-acute something like this would superseed the accent lfuns imo. -- Lgb

Re: LFUN: Check description of accent LFUNs

On Friday 15 September 2006 10:35, Helge Hafting wrote: > Why?  Will all these characters be available in unicode anyway, > and so we're supposed to set up our keyboards to do this > in an application-independent way? Yes. There should be a way to insert all the graphemes you want not just thos

Re: LFUN: Check description of accent LFUNs

Lars Gullik Bjønnes wrote: [EMAIL PROTECTED] writes: | I think I've putten together a decent description of LFUNs like | accent-acute etc, could someone please check the text. I am not even sure that we should keep these accents for 1.5. Why? Will all these characters be availab

Re: LFUN: Check description of accent LFUNs

[EMAIL PROTECTED] wrote: > I think I've putten together a decent description of LFUNs like > accent-acute etc, could someone please check the text. > > http://wiki.lyx.org/devel/pmwiki.php/Devel/LyxFunctionListTrunk#accent > > Here's the text (wiki markup actually):

Re: LFUN: Check description of accent LFUNs

>>>>> "christian" == christian ridderstrom <[EMAIL PROTECTED]> writes: christian> I think I've putten together a decent description of LFUNs christian> like accent-acute etc, could someone please check the text. christian> The LFUNs called @@acce

Re: Documenting LFUNs

> "christian" == christian ridderstrom <[EMAIL PROTECTED]> writes: christian> It'll probably take a while to get it documented, but christian> should the LFUN documentation go into lfuns.h or christian> LyXAction.C (or some other file)? I think LyXAction is better, since it has the advantage

Re: LFUN: Check description of accent LFUNs

On Thu, 14 Sep 2006, Lars Gullik Bjønnes wrote: > [EMAIL PROTECTED] writes: > > | I think I've putten together a decent description of LFUNs like > | accent-acute etc, could someone please check the text. > > I am not even sure that we should keep these accents for 1.5.

Re: Documenting LFUNs

On Thu, 14 Sep 2006, Lars Gullik Bjønnes wrote: > [EMAIL PROTECTED] writes: > > | And any ideas on how to keep this information up-to-date in the future? > | (One way is to insert a descriptive text inside a comment directly in for > | instance LyXAction.C) > > That way. It'll probably take a

Re: LFUN: Check description of accent LFUNs

[EMAIL PROTECTED] writes: | I think I've putten together a decent description of LFUNs like | accent-acute etc, could someone please check the text. I am not even sure that we should keep these accents for 1.5. -- Lgb

Re: Documenting LFUNs

[EMAIL PROTECTED] writes: | And any ideas on how to keep this information up-to-date in the future? | (One way is to insert a descriptive text inside a comment directly in for | instance LyXAction.C) That way. -- Lgb

LFUN - question 2: About the font-... LFUNs

There's a start of a description of LFUNs like font-bold here http://wiki.lyx.org/devel/pmwiki.php/Devel/LyxFunctionListTrunk#font but there is some question marks... Here's the text for your convenience: --- The following LFUNs cal

LFUN: Check description of accent LFUNs

I think I've putten together a decent description of LFUNs like accent-acute etc, could someone please check the text. http://wiki.lyx.org/devel/pmwiki.php/Devel/LyxFunctionListTrunk#accent Here's the text (wiki markup actually): The LFUNs called @@accent-@@ are used to place an acc

Re: Documenting LFUNs

On Thu, 14 Sep 2006, Georg Baum wrote: > Am Donnerstag, 14. September 2006 20:32 schrieb Paul A. Rubin: > > [EMAIL PROTECTED] wrote: > > > > > > And any ideas on how to keep this information up-to-date in the future? > > The only chance for that to happen is if the documentation is in the > sou

Re: Documenting LFUNs

Am Donnerstag, 14. September 2006 20:32 schrieb Paul A. Rubin: > [EMAIL PROTECTED] wrote: > > > > And any ideas on how to keep this information up-to-date in the future? The only chance for that to happen is if the documentation is in the source. Please add the docuemntation as doxygen comments

Re: Documenting LFUNs

[EMAIL PROTECTED] wrote: And any ideas on how to keep this information up-to-date in the future? (One way is to insert a descriptive text inside a comment directly in for instance LyXAction.C) Javadoc is an incredibly easy to use tool for documenting Java source code. Near the bottom of htt

Documenting LFUNs

I thought I'd start a small project regarding documenting the LFUNs here http://wiki.lyx.org/devel/pmwiki.php/Devel/LyxFunctionListTrunk For now I'm just keeping all the information about the LFUNs in a single page. Here's the current idea: * Keep it all in one page

Re: Obsolete LFUNs?

On Wed, 2006-09-06 at 11:56 +0200, Michael Gerz wrote: > Jean-Marc Lasgouttes schrieb: > > Michael> ? caption-insert - no effect ? > > > > This is related to the inactive caption inset. Keep it unless this > > code is removed. > > > Hmmm. Do you want me to keep the LFUN or to remove the complet

Re: Obsolete LFUNs?

Jean-Marc Lasgouttes wrote: >> "Michael" == Michael Gerz >> <[EMAIL PROTECTED]> writes: > > Michael> Jean-Marc Lasgouttes schrieb: ? caption-insert - no effect ? >>> This is related to the inactive caption inset. Keep it unless this >>> code is removed. >>> > Michael> Hmmm. Do you want

Re: Obsolete LFUNs?

>>>>> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes: Michael> Hi, this patch removes two obsolete LFUNs. It seems that not Michael> much effort was spent on their development (yes, I did a Michael> global 'grep'). Actually, they have been incompletely removed, I think. JMarc

Re: Obsolete LFUNs?

Hi, this patch removes two obsolete LFUNs. It seems that not much effort was spent on their development (yes, I did a global 'grep'). I will commit later today, unless someone objects (JMarc already gave his OK). Michael Index: src/L

Re: Obsolete LFUNs?

> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes: Michael> Jean-Marc Lasgouttes schrieb: ? caption-insert - no effect ? >> This is related to the inactive caption inset. Keep it unless this >> code is removed. >> Michael> Hmmm. Do you want me to keep the LFUN or to remove the Michael>

Re: Obsolete LFUNs?

Michael Gerz wrote: Thank you very much for your excellent explanations! maybe they should be added as a comment at an appropriate place in the code..?

  1   2   3   >