On Thu, Sep 30, 2021 at 12:54:20PM +0200, Jürgen Spitzmüller wrote:
> Am Samstag, dem 25.09.2021 um 14:04 -0400 schrieb Scott Kostyshak:
> > On master, the \emph is not closed after "regardless" as what happens
> > on 2.3.x.
>
> It was closed after the comment, w
Am Samstag, dem 25.09.2021 um 14:04 -0400 schrieb Scott Kostyshak:
> On master, the \emph is not closed after "regardless" as what happens
> on 2.3.x.
It was closed after the comment, which does not seem to work.
I fixed it with a rather specialized case. Probably we need
Am Mittwoch, dem 29.09.2021 um 22:23 -0400 schrieb Scott Kostyshak:
> On Sun, Sep 26, 2021 at 10:58:25AM +0200, Jean-Pierre Chrétien wrote:
> > Le 25/09/2021 à 20:04, Scott Kostyshak a écrit :
> > > The attached example compiles fine with 2.3.x. On master, the
> > >
On Sun, Sep 26, 2021 at 10:58:25AM +0200, Jean-Pierre Chrétien wrote:
> Le 25/09/2021 à 20:04, Scott Kostyshak a écrit :
> > The attached example compiles fine with 2.3.x. On master, the \emph is not
> > closed after "regardless" as what happens on 2.3.x.
>
> Rig
Le 25/09/2021 à 20:04, Scott Kostyshak a écrit :
The attached example compiles fine with 2.3.x. On master, the \emph is not closed after
"regardless" as what happens on 2.3.x.
Right, the comment is encapsulated in the \emph command.
With 2.3.7, the command is closed all right
The attached example compiles fine with 2.3.x. On master, the \emph is not
closed after "regardless" as what happens on 2.3.x.
Scott
emph-and-comment-mwe.lyx
Description: application/lyx
signature.asc
Description: PGP signature
--
lyx-devel mailing list
lyx-devel@lists.ly
1 at 09:32:01AM +0100, Stephan Witt wrote:
> >>>> commit a9342ae098024e363891653d1bcf7a8d485a271c
> >>>> Author: Stephan Witt
> >>>> Date: Mon Feb 15 09:35:31 2021 +0100
> >>>>
> >>>> #8055 use standard shortcut for
3d1bcf7a8d485a271c
>>>> Author: Stephan Witt
>>>> Date: Mon Feb 15 09:35:31 2021 +0100
>>>>
>>>> #8055 use standard shortcut for font-emph on Mac
>>>> ---
>>>> lib/bind/mac.bind |5 ++---
>>>> 1 files change
5, 2021 at 09:32:01AM +0100, Stephan Witt wrote:
> >>>> commit a9342ae098024e363891653d1bcf7a8d485a271c
> >>>> Author: Stephan Witt
> >>>> Date: Mon Feb 15 09:35:31 2021 +0100
> >>>>
> >>>>#8055 use standard shortcut f
098024e363891653d1bcf7a8d485a271c
>>>> Author: Stephan Witt
>>>> Date: Mon Feb 15 09:35:31 2021 +0100
>>>>
>>>>#8055 use standard shortcut for font-emph on Mac
>>>> ---
>>>> lib/bind/mac.bind |5 ++---
>>>> 1 file
>> Date: Mon Feb 15 09:35:31 2021 +0100
> >>
> >> #8055 use standard shortcut for font-emph on Mac
> >> ---
> >> lib/bind/mac.bind |5 ++---
> >> 1 files changed, 2 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/li
On 2/15/21 10:24 AM, Scott Kostyshak wrote:
> On Mon, Feb 15, 2021 at 09:32:01AM +0100, Stephan Witt wrote:
>> commit a9342ae098024e363891653d1bcf7a8d485a271c
>> Author: Stephan Witt
>> Date: Mon Feb 15 09:35:31 2021 +0100
>>
>> #8055 use stand
On Mon, Feb 15, 2021 at 09:32:01AM +0100, Stephan Witt wrote:
> commit a9342ae098024e363891653d1bcf7a8d485a271c
> Author: Stephan Witt
> Date: Mon Feb 15 09:35:31 2021 +0100
>
> #8055 use standard shortcut for font-emph on Mac
> ---
> lib/bind/mac.bind |5 ++---
On 05/25/2017 02:42 PM, PhilipPirrip wrote:
This used to work fine until LyX 2.3:
insert a hyperlink
select, toggle noun
you'll get
\noun{}\href{http://www.lyx.org}{lyx}
instead of
\noun{\href{http://www.lyx.org}{lyx}}
Is this intended behavior?
With \marginpar one gets
\noun{}\marginpar{\
Am Donnerstag, den 25.05.2017, 14:42 -0400 schrieb PhilipPirrip:
> This used to work fine until LyX 2.3:
>
> insert a hyperlink
> select, toggle noun
>
> you'll get
> \noun{}\href{http://www.lyx.org}{lyx}
>
> instead of
> \noun{\href{http://www.lyx.org}{lyx}}
>
>
> Is this intended behavior?
This used to work fine until LyX 2.3:
insert a hyperlink
select, toggle noun
you'll get
\noun{}\href{http://www.lyx.org}{lyx}
instead of
\noun{\href{http://www.lyx.org}{lyx}}
Is this intended behavior?
With \marginpar one gets
\noun{}\marginpar{\noun{bbb}}
which kind of makes more sense, bu
On 07/17/2015 06:12 AM, Jean-Marc Lasgouttes wrote:
Le 26/06/2015 15:20, Cor Blom a écrit :
Hi,
Sometimes I want text to be both small caps and emphasized. I can do
that and it is correct in the output, but in lyx itself it just shows as
regular text, indistinguishable from normal text, which m
Le 26/06/2015 15:20, Cor Blom a écrit :
Hi,
Sometimes I want text to be both small caps and emphasized. I can do
that and it is correct in the output, but in lyx itself it just shows as
regular text, indistinguishable from normal text, which makes it hard to
use this. Is this a bug? Or is there
makes it hard to
use this. Is this a bug? Or is there something else wrong?
Using 2.1.3 on openSUSE 13.2
Hello,
Could you send an example file? I fail to get this emph+textsc
combination working in latex output anyway.
JMarc
Attached is an example file.
example.lyx
Description: application
something else wrong?
Using 2.1.3 on openSUSE 13.2
Hello,
Could you send an example file? I fail to get this emph+textsc
combination working in latex output anyway.
JMarc
Hi,
Sometimes I want text to be both small caps and emphasised. I can do
that and it is correct in the output, but in lyx itself it just shows as
regular text, indistuinguisable from normal text, which makes it hard to
use this. Is this a bug? Or is there something else wrong?
Using 2.1.3 on
On Wed, Nov 18, 2009 at 5:17 PM, Enrico Forestieri wrote:
> Maybe something a bit more light, as the attached?
i like it...
Enrico Forestieri wrote:
> Ok, given that we are back again to the 1.3 icon
Ah, I wondered why it looked so familiar.
Jürgen
Enrico Forestieri schreef:
On Wed, Nov 18, 2009 at 03:58:13PM +0100, Edwin Leuven wrote:
i wouldn't mind seeing a hint that this marks up text (as in attached
for example)
Why not? Maybe something a bit more light, as the attached?
Looks nice.
Vincent
On Wed, Nov 18, 2009 at 03:58:13PM +0100, Edwin Leuven wrote:
> i wouldn't mind seeing a hint that this marks up text (as in attached
> for example)
Why not? Maybe something a bit more light, as the attached?
> before i always wondered what this exclamation mark meant. probably
> "DANGER!" i th
i wouldn't mind seeing a hint that this marks up text (as in attached
for example)
before i always wondered what this exclamation mark meant. probably
"DANGER!" i thought and never dared clicking it...
<>
Enrico Forestieri wrote:
> The current one is too tall and thin, IMHO.
+1
pavel
> the word-like solution.
> > Both solutions are feasible easily, we just have to decide whih one is
> > best.
>
> What I like wrt Uwe's proposal is that it abstracts from any static markup
> (like the noun button does already), and thus maybe indicates a bit bette
ide whih one is
> best.
What I like wrt Uwe's proposal is that it abstracts from any static markup
(like the noun button does already), and thus maybe indicates a bit better
that the emph button does not the same as the "I" button in Word or OOo.
(In the long run, if we manage
Le 16 nov. 09 à 07:40, Jürgen Spitzmüller a écrit :
Uwe Stöhr wrote:
When I see an exclamation mark I think of something that must be
important.
And that's what \emph is for: highlight text parts that are
important.
I therefore propose to replace the existing button with the
attache
>> When I see an exclamation mark I think of something that must be important.
>> And that's what \emph is for: highlight text parts that are important.
>> I therefore propose to replace the existing button with the attached one.
>
> I like the idea (but we should
Uwe Stöhr wrote:
> When I see an exclamation mark I think of something that must be important.
> And that's what \emph is for: highlight text parts that are important.
> I therefore propose to replace the existing button with the attached one.
I like the idea (but we should do
While "E" stands for
emphasize would have to be in German an "H" (Hervorgehoben).
As Georg stated in the bug report we shouldn't use letter abbreviations for
buttons.
When I see an exclamation mark I think of something that must be important. And that's what \emph is
Jean-Marc Lasgouttes wrote:
> Finally, the lines
>
> > if (layout.font.family() == INHERIT_FAMILY)
> > lf.setFamily(buffer.params().getFont().fontInfo().f
> >amily());
>
> (which are Juergen's) do not look right. I would have expected
> something like
>
> >
If so, then getLayout(BufferParams const &) is fine, and does what
it should. So it might be that we could go with the attached, which
is what you suggested earlier. I'm not sure, however, because e.g.
pars_[pit].inInset()->getLayout(buffer.params()).font()
will be sane_font for InsetText, and
rgheck wrote:
So it might be that we could go with the attached, which is what you
suggested earlier. I'm not sure, however, because e.g.
pars_[pit].inInset()->getLayout(buffer.params()).font()
will be sane_font for InsetText, and I'm worried that that isn't right.
The right patch is attached--
Jean-Marc Lasgouttes wrote:
rgheck <[EMAIL PROTECTED]> writes:
I propose we get rid of Inset::getLayout() altogether. It's not
needed. As the attached shows.
The potential usefulness of getLayout for basic insets is to be able
to define the fonts used by all insets (ref, cite, math) fr
rgheck <[EMAIL PROTECTED]> writes:
> There is a getLayout(BufferParams const &), but the one I was using is
> getLayout(), which is only defined in InsetCollapsable. I could use
> the other one, but there's a lot of weirdness here, now that I look at
> it. I take it that Inset::getLayout(BufferPara
Jean-Marc Lasgouttes wrote:
rgheck <[EMAIL PROTECTED]> writes:
OK, progress. The attached patch seems to fix the bug.
The patch looks good. Note however that getLayout is defined at Inset
level, so you do not need to play tricks with InsetCollapsable.
There is a getLayout(BufferP
rgheck <[EMAIL PROTECTED]> writes:
> OK, progress. The attached patch seems to fix the bug.
The patch looks good. Note however that getLayout is defined at Inset
level, so you do not need to play tricks with InsetCollapsable.
I tried the same thing with FontInfo::realize, which is supposed to b
OK, progress. The attached patch seems to fix the bug.
Here's how to trigger it prior to the patch. Create a footnote. Type
"this footnote". Now put the cursor after the "s", type a space, type
Ctrl-E (emph), and now type some text. Check View>Source. You
I think I understand what is happening here now. The problem is more or
less here, with irrelevant bits snipped:
void Text::setFont(Cursor & cur, Font const & font, bool toggleall)
{
FontInfo layoutfont;
pit_type pit = cur.pit();
if (cur.pos() < pars_[pit].beginOfBody())
layout
As a wild guess of sorts, the attached seems to work.
rh
Index: Text2.cpp
===
--- Text2.cpp (revision 26155)
+++ Text2.cpp (working copy)
@@ -299,13 +299,15 @@
cur.real_current_font.update(font,
rgheck wrote:
rgheck wrote:
I've chased this bug a bit, but I don't understand fonts well enough
to fix it.
In a footnote, hitting "Ctrl-E" causes the textcolor and size to be
set as well. These are the color and size defined for the
InsetLayout, but for some reason those are being picked
rgheck wrote:
I've chased this bug a bit, but I don't understand fonts well enough
to fix it.
In a footnote, hitting "Ctrl-E" causes the textcolor and size to be
set as well. These are the color and size defined for the InsetLayout,
but for some reason those are being picked up also as the
I've chased this bug a bit, but I don't understand fonts well enough to
fix it.
In a footnote, hitting "Ctrl-E" causes the textcolor and size to be set
as well. These are the color and size defined for the InsetLayout, but
for some reason those are being picked up also as the output font
pa
Abdelrazak Younes wrote:
Helge Hafting wrote:
This is crazy. When I apply "emph" (ctrl+e or the emph button)
then I get emph, but also english language. My document is
in norwegian, so this is most unwelcome.
Fixed.
Confirmed, this got fixed quickly!
The current workaround is
Helge Hafting wrote:
This is crazy. When I apply "emph" (ctrl+e or the emph button)
then I get emph, but also english language. My document is
in norwegian, so this is most unwelcome.
Fixed.
The current workaround is to revert the language using
the textstyle dialog. :-(
You
This is crazy. When I apply "emph" (ctrl+e or the emph button)
then I get emph, but also english language. My document is
in norwegian, so this is most unwelcome.
The current workaround is to revert the language using
the textstyle dialog. :-(
Weird.
Helge Hafting
>>>>> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> On Tue, Jul 23, 2002 at 12:14:36AM +0200, Jean-Marc Lasgouttes
John> wrote:
>> >I'd like to understand why I need to add a special case for emph()
>> to >my Qt code but n
On Tue, Jul 23, 2002 at 12:14:36AM +0200, Jean-Marc Lasgouttes wrote:
> >I'd like to understand why I need to add a special case for emph() to
> >my Qt code but not xforms
>
> This should not be needed.
Hmm, once again ...
If I set italic in char dialog all is OK,
John Levon wrote:
> How does the X font loader get to display font emph code in italic ?
> There doesn't seem to be any checking for emph() in the font loader
> code.
The font loader does not know about emph. Only LyXFont knows and the
magic is done in LyXFont::realShape().
How does the X font loader get to display font emph code in italic ?
There doesn't seem to be any checking for emph() in the font loader
code.
I'd like to understand why I need to add a special case for emph() to
my Qt code but not xforms
thanks
john
--
"Of all manifest
On Fri, Jul 27, 2001 at 02:58:28PM +0100, John Levon wrote:
> On Fri, Jul 27, 2001 at 04:50:56PM +0300, Dekel Tsur wrote:
>
> > In my opinion the current behavior is not fine.
> > Please revert to the old one.
>
> which old one ? it did this in 116 at least ...
argh,sorry, no it didn't of cour
On Fri, Jul 27, 2001 at 04:50:56PM +0300, Dekel Tsur wrote:
> In my opinion the current behavior is not fine.
> Please revert to the old one.
which old one ? it did this in 116 at least ...
john
--
"I'd rather be rudely informed than politely left in the dark."
On Fri, Jul 27, 2001 at 02:08:45PM +0100, John Levon wrote:
> at least openoffice doesn't change the preceding word. But this is not necessarily
> a thing to copy ...
>
> so perhaps the current behaviour is fine; it just surprised me ...
In my opinion the current behavior is not fine.
Please rev
On Fri, Jul 27, 2001 at 03:29:04PM +0200, Jean-Marc Lasgouttes wrote:
> I don't know what we want to do, actually. Stealing ideas from others
> is always good.
Do I take it it is fairly easy to separate the mechanisms ?
Index entry should always work on last word.
Font changes etc. should be t
On Fri, Jul 27, 2001 at 11:33:33AM +0200, Jean-Marc Lasgouttes wrote:
> Did it work with 1.1.6? I cam to the conclusion at the time that
> font-emph did not really work like that.
hmm, you're right. I must have been luck enough to have always pressed space
first (really I had ne
JMarc, you changed it recently to locate the nearest word. Now I know you asked
about doing this, so apologies for not thinking at the time.
But there is now a big user problem - if I am typing, I cannot go into font-emph
mode via the toolbar, as it operates on the last word it seems.
what can
59 matches
Mail list logo
