Le 13/07/2022 à 17:49, Kornel Benko a écrit :
Works nice. As expected, only the newly entered command is made uniq.
IMHO this should go in.
Thanks. This is in now.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Am Wed, 13 Jul 2022 17:06:33 +0200
schrieb Jean-Marc Lasgouttes :
> Le 13/07/2022 à 11:24, Kornel Benko a écrit :
> > Am Wed, 13 Jul 2022 11:14:53 +0200
> > schrieb Jean-Marc Lasgouttes :
> >
> >> Le 13/07/2022 à 09:43, Kornel Benko a écrit :
> > I suspect that the two command
> > lis
Le 13/07/2022 à 11:24, Kornel Benko a écrit :
Am Wed, 13 Jul 2022 11:14:53 +0200
schrieb Jean-Marc Lasgouttes :
Le 13/07/2022 à 09:43, Kornel Benko a écrit :
I suspect that the two command
lists should be unified.
Maybe in 2.5?
I'll have a look.
Thanks.
Here is a patch, which nicely re
Am Wed, 13 Jul 2022 11:14:53 +0200
schrieb Jean-Marc Lasgouttes :
> Le 13/07/2022 à 09:43, Kornel Benko a écrit :
> >>> I suspect that the two command
> >>> lists should be unified.
> >
> > Maybe in 2.5?
>
> I'll have a look.
Thanks.
> >> I just discovered that the sexy and fast way of rem
Le 13/07/2022 à 09:43, Kornel Benko a écrit :
I suspect that the two command
lists should be unified.
Maybe in 2.5?
I'll have a look.
I just discovered that the sexy and fast way of removing a string from a
vector of strings is the erase-remove idiom:
https://en.wikipedia.org/wiki/Erase%E2%
Am Tue, 12 Jul 2022 22:56:56 +0200
schrieb Jean-Marc Lasgouttes :
> Le 12/07/2022 à 22:19, Jean-Marc Lasgouttes a écrit :
> > I won't complain more about removing from the whole history, but the
> > original patch will need to be updated.
I planned to commit your and mine patch. What else do you
Le 12/07/2022 à 22:19, Jean-Marc Lasgouttes a écrit :
I won't complain more about removing from the whole history, but the
original patch will need to be updated. I suspect that the two command
lists should be unified.
I just discovered that the sexy and fast way of removing a string from a
v
Le 12/07/2022 à 22:15, Pavel Sanda a écrit :
On Mon, Jul 11, 2022 at 02:25:49PM +0200, Kornel Benko wrote:
Am Mon, 11 Jul 2022 13:37:31 +0200
schrieb Pavel Sanda :
On Mon, Jul 11, 2022 at 10:53:23AM +0200, Kornel Benko wrote:
So the outcome may be a new preference?
Please no.
Pavel
What
On Mon, Jul 11, 2022 at 02:25:49PM +0200, Kornel Benko wrote:
> Am Mon, 11 Jul 2022 13:37:31 +0200
> schrieb Pavel Sanda :
>
> > On Mon, Jul 11, 2022 at 10:53:23AM +0200, Kornel Benko wrote:
> > > So the outcome may be a new preference?
> >
> > Please no.
> >
> > Pavel
>
> What is your prefer
Am Mon, 11 Jul 2022 13:37:31 +0200
schrieb Pavel Sanda :
> On Mon, Jul 11, 2022 at 10:53:23AM +0200, Kornel Benko wrote:
> > So the outcome may be a new preference?
>
> Please no.
>
> Pavel
What is your preference?
Kornel
pgpigoaERAeM9.pgp
Description: Digitale Signatur von OpenPGP
On Mon, Jul 11, 2022 at 10:53:23AM +0200, Kornel Benko wrote:
> So the outcome may be a new preference?
Please no.
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Am Mon, 11 Jul 2022 10:53:23 +0200
schrieb Kornel Benko :
> Am Mon, 11 Jul 2022 00:15:40 +0200
> schrieb Jean-Marc Lasgouttes :
>
> > Le 10/07/2022 à 22:05, Kornel Benko a écrit :
> > > So I was not clear enough. With 'duplicated' I meant anywhere in the
> > > history.
> > >
> > > The (my) ar
Am Mon, 11 Jul 2022 00:15:40 +0200
schrieb Jean-Marc Lasgouttes :
> Le 10/07/2022 à 22:05, Kornel Benko a écrit :
> > So I was not clear enough. With 'duplicated' I meant anywhere in the
> > history.
> >
> > The (my) argument was seeing the session file full of the same commands
> > spread all o
Le 10/07/2022 à 22:05, Kornel Benko a écrit :
So I was not clear enough. With 'duplicated' I meant anywhere in the history.
The (my) argument was seeing the session file full of the same commands
spread all over the file, essentially shortening the maximum (different)
commands
possible.
I was
Am Sun, 10 Jul 2022 19:42:49 +0200
schrieb Jean-Marc Lasgouttes :
> Le 10/07/2022 à 18:38, Kornel Benko a écrit :
> > I don't get it.
> > 1.) I like the rim(), was about to use it too ... but was unsure if
> > sometimes
> > one needs spaces at end.
>
> In this case, I can remove it from b
Le 10/07/2022 à 18:38, Kornel Benko a écrit :
I don't get it.
1.) I like the rim(), was about to use it too ... but was unsure if sometimes
one needs spaces at end.
In this case, I can remove it from both cases. It is not right to
maintain two lists and have one which is different from t
Am Sun, 10 Jul 2022 18:08:06 +0200
schrieb Jean-Marc Lasgouttes :
> Le 10/07/2022 à 15:23, Kornel Benko a écrit :
> > Like this? Feel free to make it simpler.
>
> Rather like this. Note that your patch did not avoid duplicates on the
> command list available from the up arrow icon. There are ind
command buffer history
The situation of this code is weird because one has to update both the
history_ of GuiCommandBuffer and the lastcommands vector of Sessio
stuff. One of these should go eventually.
---
src/frontends/qt/GuiCommandBuffer.cpp | 8 +---
1 file changed, 5 insertions(+), 3
Am Sun, 10 Jul 2022 15:05:43 +0200
schrieb Jean-Marc Lasgouttes :
> Le 10/07/2022 à 11:46, Kornel Benko a écrit :
> > While testing, using history in command buffer for some often repeated
> > lyx-functions
> > is often made difficult when the previous (but not now des
Le 10/07/2022 à 11:46, Kornel Benko a écrit :
While testing, using history in command buffer for some often repeated
lyx-functions
is often made difficult when the previous (but not now desired) command
was repeated.
Objections?
I like it, but I would make it simpler, like
if (not already
While testing, using history in command buffer for some often repeated
lyx-functions
is often made difficult when the previous (but not now desired) command
was repeated.
Objections?
Kornel
diff --git a/src/Session.cpp b/src/Session.cpp
index a814991e59..5595aedf8e 100644
--- a/src
two
delimeters | |.
So, a feature request: Might there be a way to enter a math macro
using the command buffer than automatically puts selected text inside
the first argument of the macro? That way one could, for example,
create a keyboard shortcut in Preferences... to the corresponding math
a way to enter a math macro using the
command buffer than automatically puts selected text inside the first
argument of the macro? That way one could, for example, create a keyboard
shortcut in Preferences... to the corresponding math macro that correctly
wraps selected math expressions.
Thanks
Vincent van Ravesteijn wrote:
> Vincent van Ravesteijn schreef:
>> This patch will open a list (alike to the completion list) when pressing
>> the upper arrow in the command buffer.
>>
>> Especially in combination with the other patch I sent (remembering the
>>
Vincent van Ravesteijn wrote:
> This patch will open a list (alike to the completion list) when pressing
> the upper arrow in the command buffer.
>
> Especially in combination with the other patch I sent (remembering the
> commands for the next session), I find this very useful.
This patch will open a list (alike to the completion list) when pressing
the upper arrow in the command buffer.
Especially in combination with the other patch I sent (remembering the
commands for the next session), I find this very useful.
Objections or ideas ?
Vincent
sebastian guttenberg wrote:
when the toolbar "command buffer" state is set to "off", it is not
possible to enter the command buffer via alt-x. Is this intentional? I
would not see an advantage to have it completely locked...
The problem is that the mini toolbar is corre
sebastian guttenberg wrote:
when the toolbar "command buffer" state is set to "off", it is not
possible to enter the command buffer via alt-x. Is this intentional?
No, there is a bug there that I intent to correct, probably tomorrow if
nobody fixes it before.
Abdel.
Sorry, forgot to mention: I am referring to 1.6.svn
On Tue, 2007-11-13 at 19:27 +0200, sebastian guttenberg wrote:
> when the toolbar "command buffer" state is set to "off", it is not
> possible to enter the command buffer via alt-x. Is this intentional? I
> would no
when the toolbar "command buffer" state is set to "off", it is not
possible to enter the command buffer via alt-x. Is this intentional? I
would not see an advantage to have it completely locked...
-Sebastian
--
This message has been scanned for viruses and
dangerous content
On Tue, Apr 13, 2004 at 06:09:27PM +0200, Andre Poenitz wrote:
> So, if I understand correctly, the argument goes as follows.
>
> - nobody but a few knew of the command line
> - so we separated it from the status display to make them more visible
> - now it takes too much space
> - so we hide
On Tue, Apr 13, 2004 at 02:52:59PM +0100, John Levon wrote:
> In case anyone's interested, the rationale is simple - nobody* knew that
> you could type into the minibuffer. This was partly due to visual
> decoration in the xforms frontend, and partly due to its "status bar"
> behaviour.
>
> And on
On Tue, Apr 13, 2004 at 03:32:32PM +0100, Angus Leeming wrote:
> I think so. Here's why.
>
> The command buffer performs two roles:
> 1. It provides us with state information. (All those useful 'Running
> latex' etc messages.)
> 2. It gives us a means to ent
Leuven, E. wrote:
>>> Is the argument for not having it visible always, valid?
>> I think so. Here's why.
>> The command buffer performs two roles:
>
> maybe time to implement a status bar to separate the two?
Let's fix existing bugs rather than create new
>> Is the argument for not having it visible always, valid?
> I think so. Here's why.
> The command buffer performs two roles:
maybe time to implement a status bar to separate the two?
ed.
On Tue, Apr 13, 2004 at 03:14:11PM +0200, Lars Gullik Bjønnes wrote:
> Is the argument for not having it visible always, valid?
I don't think so. Personnaly I'd like to have the minibuffer always
visible. But I don't care too much about UI issues as long as it does
not interfere with the way I am
t; something
>>
> | I certainly wouldn't mind...
>
> Is the argument for not having it visible always, valid?
I think so. Here's why.
The command buffer performs two roles:
1. It provides us with state information. (All those useful 'Running
latex' etc messages
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Apr 12, 2004 at 06:02:05PM +0100, John Levon wrote:
>> On Sat, Apr 10, 2004 at 11:34:43PM +0200, Andre Poenitz wrote:
>>
>> > Well, if this would be done, I could live with it. Until then I'd
>> > prefer a visible mini-buffer. Makes debugging a
On Mon, Apr 12, 2004 at 06:02:05PM +0100, John Levon wrote:
> On Sat, Apr 10, 2004 at 11:34:43PM +0200, Andre Poenitz wrote:
>
> > Well, if this would be done, I could live with it. Until then I'd
> > prefer a visible mini-buffer. Makes debugging a bit easier.
>
> We could probably enable it by d
On Sat, Apr 10, 2004 at 11:34:43PM +0200, Andre Poenitz wrote:
> Well, if this would be done, I could live with it. Until then I'd
> prefer a visible mini-buffer. Makes debugging a bit easier.
We could probably enable it by default for development versions or
something
regards
john
Andre Poenitz wrote:
> I mean: What can I do (as a user) to have the minibuffer permanently
> enabled?
edit stdtoolbars. Of course a gui would be great.
Jürgen.
On Sat, Apr 10, 2004 at 04:08:10PM +0100, John Levon wrote:
> On Fri, Apr 09, 2004 at 05:58:57PM +0200, Andre Poenitz wrote:
>
> > Is this a permanent change?
>
> Yes. I would like some things on top though (and have done for a long
> time). First, the M-x thing Angus mentioned. Second a View->To
On Sat, Apr 10, 2004 at 09:47:00AM +0200, Juergen Spitzmueller wrote:
> Andre Poenitz wrote:
> > > agreed. In the meantime, you can turn the minibuffer on via the context
> > > menu (rmb when the mouse is over the toolbars). Just in case you didn't
> > > notice this feature (I did by chance).
> >
>
John Levon wrote:
> Yes. I would like some things on top though (and have done for a long
> time). First, the M-x thing Angus mentioned. Second a View->Toolbars
> submenu.
Welcome back :-)
Jürgen.
On Fri, Apr 09, 2004 at 05:58:57PM +0200, Andre Poenitz wrote:
> Is this a permanent change?
Yes. I would like some things on top though (and have done for a long
time). First, the M-x thing Angus mentioned. Second a View->Toolbars
submenu.
regards
john
Andre Poenitz wrote:
> > agreed. In the meantime, you can turn the minibuffer on via the context
> > menu (rmb when the mouse is over the toolbars). Just in case you didn't
> > notice this feature (I did by chance).
>
> Is this a permanent change?
What? The removal of the minibuffer? I guess so.
On Fri, Apr 09, 2004 at 12:40:18PM +0200, Juergen Spitzmueller wrote:
> Angus Leeming wrote:
> > Now, personally, I think that it should be there, but leaving that to
> > one side, why don't we have a minibuffer that 'appears' when I type
> > 'M-x' and 'disappears' when I subsequently hit return? T
Angus Leeming wrote:
> Now, personally, I think that it should be there, but leaving that to
> one side, why don't we have a minibuffer that 'appears' when I type
> 'M-x' and 'disappears' when I subsequently hit return? That way, its
> behaviour is analogous to the math and table toolbars in the Qt
John Levon wrote:
> On Thu, Apr 08, 2004 at 05:25:10PM +0100, Angus Leeming wrote:
>
>> Now, personally, I think that it should be there, but leaving that
>> to one side, why don't we have a minibuffer that 'appears' when I
>> type 'M-x' and 'disappears' when I subsequently hit return? That
>> wa
On Thu, Apr 08, 2004 at 05:25:10PM +0100, Angus Leeming wrote:
> Now, personally, I think that it should be there, but leaving that to
> one side, why don't we have a minibuffer that 'appears' when I type
> 'M-x' and 'disappears' when I subsequently hit return? That way, its
> behaviour is anal
Leaving aside Andre's assertion that it is broken at the moment, the
command buffer in the Qt frontend is turned off by default. The
rationale is that it eats up screen real estate and only gurus use it
anyway.
Now, personally, I think that it should be there, but leaving that to
one
That's right.
> Hitting M-x would make the "edit" buffer visible immediately above the
> "display" buffer and would place your cursor in it. Return would hide this
> "edit" buffer again and execute the command.
This would be a simple change to view th
On Tuesday 23 July 2002 5:54 pm, Edwin Leuven wrote:
> > Wouldn't that be a bit distracting ?
>
> Personally I don't think so. It's like run command under KDE (alt-f2) which
> I find very convenient.
>
> > Bear in mind the command buffer is
> > a featu
r (should) takes focus.
> I also think that most people are not used to the notion of a command buffer.
> And I find it a bit of an old fashioned inheritance from emacs before a world
> with windows, dialogs etc.
Perhaps. To be honest, I am not really faffed either way, and I don't
kno
> Wouldn't that be a bit distracting ?
Personally I don't think so. It's like run command under KDE (alt-f2) which I
find very convenient.
> Bear in mind the command buffer is
> a feature for power users only really, and sooner or later it will be
> possible to
On Tue, Jul 23, 2002 at 06:39:55PM +0200, Edwin Leuven wrote:
> Wouldn't it be nicer to have a little modal window with an editable combobox
> as a command buffer? It would popup with M-x and disappear after use...
Wouldn't that be a bit distracting ? Bear in mind the com
Wouldn't it be nicer to have a little modal window with an editable combobox
as a command buffer? It would popup with M-x and disappear after use...
Ed.
lyx.png
Description: PNG image
57 matches
Mail list logo
