> 2025/07/28 21:28、Pavel Sanda のメール:
>
> would mind chaning few string in the prefs for colors, which were recently
> introduced?
>
> I think using "Enter" instead of asking is more in line with current strings
> and also
> string "Are you sure?" free of context looks little awkward while trans
> 2025/07/23 21:11、Jean-Marc Lasgouttes のメール:
>
> I would say that this "switch off" property could be added as a new languages
> file tag. But of course, having other input method users chime in would be
> useful. Asking on lyx-users may help.
I see. That seems a better way. Thanks!
> Concer
> 2025/07/23 16:29、Jean-Marc Lasgouttes のメール:
>
> Le 23 juillet 2025 03:28:12 GMT+02:00, Koji Yokota a
> écrit :
>> This part of code prohibits only CJK from entering their characters in the
>> math mode, so it is a minimal list. I’m thinking of taking a strategy to add
>> another language if
2025/07/16 12:45、Koji Yokota のメール:2025/07/16 6:17、Scott Kostyshak のメール:On Tue, Jul 15, 2025 at 08:14:38PM +0200, Kornel Benko wrote:You have use -DLYX_CXX_FLAGS_EXTRA='-Woverloaded-virtual'Note that I only see the warning with GCC. I do not see it with Clang.Below are my build commands to reproduce
> 2025/07/13 22:18、Scott Kostyshak のメール:
>
> On Thu, Jul 03, 2025 at 12:55:02AM +0200, Scott Kostyshak wrote:
>> On Thu, Jul 03, 2025 at 12:10:10AM +0200, Jean-Marc Lasgouttes wrote:
>>> Le 02/07/2025 à 18:16, Scott Kostyshak a écrit :
>
src/insets/Inset.h:217:22: warning: ‘virtual void
>>
> 2025/07/13 22:18、Scott Kostyshak のメール:
> Could you please double-check my commit (406a1357) looks OK to you?
Dear Scott,
Sorry that I missed your mail. I misunderstood the usage of the function. Thank
you very much for fixing.
Koji--
lyx-devel mailing list
lyx-devel@lists.lyx.org
https://li
> 2025/06/09 3:52、Pavel Sanda のメール:
>
> Maybe just single icon which would be part of other sets?
> Can be intertext part of fonts in similar way as we have
> "Normal text mode" there?
With a second thought, these functions may be categorized as “inserting text in
math” including unlisted exis
> But I wonder if it contaminates the code excessively. For example, raising a
> pop-up from namespace lyx doesn’t look straightforward to me (A code in
> lyx::frontend should regularly check a “signal" raised from namespace lyx?) I
> wonder if I should go along with that line to implement a war
> 2025/05/23 10:24、Pavel Sanda のメール:
>
> As JMarc wrote, I am not sure whether format increment is needed.
> Will be LyX 2.4 read the files with your changes (and produce correct output)?
> Pavel
LyX 2.4 reads and output PDF correctly the file with \intertext that LyX 2.5
exported with LyX 2.4.x
> 2025/03/27 22:23、Scott Kostyshak のメール:
> Just a note that I'm fine with "Object/Element" or "Object or Element"
> since I think Kornel pointed out that not everything is an object (like
> for "background”).
I see. It seems I missed Kornel’s mail. Then let’s go with "Object/Element”.
Koji--
ly
> 2025/02/13 20:20、Scott Kostyshak のメール:
>
> Was this fixed at 3c70535b?
>
> Scott
Yes, I think so.
Koji
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
https://lists.lyx.org/mailman/listinfo/lyx-devel
> For example, if preediting is canceled on selected text, the selected text is
> restored on other systems, but it doesn’t look so on Linux.
I mean, this seems to be a standard behavior of input method on Linux after
checking it with other apps.
Koji
> 2025/01/30 21:09、横田 宏治 のメール:
>
> I conf
d, Jan 29, 2025 at 11:48:07AM +0900, Yokota K. wrote:
>> I could not reproduce it on Mac, but judging from the fact that the problem
>> occurs when a focus changes, it can be related to calls of
>> inputItemTransform() or setInputItemTransform functions in
>> src/fronte
I could not reproduce it on Mac, but judging from the fact that the problem
occurs when a focus changes, it can be related to calls of inputItemTransform()
or setInputItemTransform functions in src/frontends/qt/GuiWorkArea.cpp.
I’m not sure how selection is related since new codes related to sel
Thanks, I updated it in 2.4.x.
Koji
> 2025/01/27 20:03、Pavel Sanda のメール:
>
> On Sat, Jan 25, 2025 at 01:37:32PM +, Koji Yokota wrote:
>> commit 011d3d214145b2ddbd8e1ec50d2de164b8d206e0
>> Author: Koji Yokota
>> Date: Sat Jan 25 21:57:23 2025 +0900
>>
>>Changing default Japanese quote
Pavel,
> I agree, if you send me some small screenshot, I'll put it into wiki.
I could somehow figure out how to upload an image to wiki, many thanks!
> No, we do not have any mail server, tough job to get right nowadays. We only
> have @lyx.org addresses forwarding to the real one.
>
> Depen
Dear Prof. Klingenberg,
Looking at related LaTeX News
(https://www.latex-project.org/news/2022/03/21/latex-dev-2022-1/ under the
title of \DocumentMetadata), is it sufficient to add \DocumentMetadata{…} at
the head of LaTeX file to create PDF/UA?
LaTeX tagging-project
(https://github.com/late
Filed as ticket #13121 at Trac.
Koji
> 2024/11/06 1:43、Jean-Marc Lasgouttes のメール:
>
> Le 05/11/2024 à 01:44, Yokota K. a écrit :
>> The attached is the additional patch to separate preedit strings from
>> completion strings by introducing PREEDIT row element. This
> This looks very interesting. I have plenty of style comments, but I'd like
> first to understand what you are doing.
Many thanks for looking at it. As there can be inefficient or inappropriate
usages which comes from my short experience in C++, I’m more than glad if you
could point them out
Dear list,Sorry for a subsequent post of an offer. Mac's app manager Homebrew recently began to say that the external program dia for diagram is going away:> dia: 0.97.2,7> http://dia-installer.de/> Deprecated because it is discontinued upstream! it will be disabled on 2024-12-17.So, recently I st
s のメール:
>
> Le 28/10/2024 à 06:08, Yokota K. a écrit :
>> Dear All,
>> I wrote a code to introduce OnTheSpot style in the input method and would
>> like to hear how you think.
>
> Hi Koji,
>
> Wow! This looks like a big advance. I am in vacation and will n
Thank you for your comments, Riki and JMarc!
> That looks good, but of course, the devil is in the details. Note that you
> can create a new Row element type if this is useful.
Indeed, interaction between completion and preedit strings is a great concern.
For the moment, I judged it would be ok
Dear All,
I wrote a code to introduce OnTheSpot style in the input method and would like
to hear how you think.
It relates mainly to CJK languages and translates phonetic inputs to the right
written characters. Current LyX adopts OverTheSpot style so that typed phonetic
inputs (preedits) overw
Committed on 2.4.x and master. Thanks!
Koji
> 2024/08/20 18:51、Yokota K. のメール:
>
> Pavel,
>
> Oops, I’ll post it to the master as well. I missed to mention about it as I
> was thinking of the possibility to overwrite it with another version before
> 2.5 comes (hopeful
vel Sanda のメール:
>
> On Tue, Aug 20, 2024 at 02:02:01PM +0900, Yokota K. wrote:
>> LyX-2.4.1 built on Qt5 seems to have wrong cursor position while editing
>> preedit strings using the input method. Since this is annoying for input
>> method users, may I apply the attac
Dear developers,
LyX-2.4.1 built on Qt5 seems to have wrong cursor position while editing
preedit strings using the input method. Since this is annoying for input method
users, may I apply the attached patch to the 2.4.x code?
The preedit cursor position in the completing mode (choosing right c
Thanks for the fix. I agree with the fix.
The line seems to have mistakenly slipped in.
Koji
> 2024/07/20 6:53、Pavel Sanda のメール:
>
> On Thu, Jul 18, 2024 at 06:57:22PM +0200, Jean-Marc Lasgouttes wrote:
>> Removing the setBusy(false) looks like the right thing to do. It is never a
>> good idea
To the manager of Trac:
Hi, I tried to post to Trac and found I seem to have lost my Trac password.
Could you kindly reset it? If my user ID is needed, I will send it personally.
Koji
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
It seems they have fixed it yesterday. We can wait until it is reflected in the
upstream.
Koji
2023年2月25日 21:24 +0900、Scott Kostyshak のメール:
> On Fri, Feb 24, 2023 at 10:57:47PM +0900, Yokota K. wrote:
> > > Has anyone done a tlmgr update in the last week or so, and if so can
> &g
> Has anyone done a tlmgr update in the last week or so, and if so can
> you reproduce?
I can confirm this after tlmgr update. It seems a side effect of an
inappropriate patch to a different problem.
I asked them if they could fix it at the mentioned ticket:
https://github.com/texjporg/platex/is
➢ Koji, could you look after that, please?
I haven’t sorted out the problem yet, but indeed ja/UserGuide.lyx doesn’t
create index at the end of the document (compilation itself ends without halt).
I realized from the information bar at the bottom of LyX during compilation,
both mendex and makei
Hi Kornel,
The Japanese part seems good.
Koji
2017-06-09 1:11 GMT+09:00 Kornel Benko :
> Am Donnerstag, 8. Juni 2017 um 02:34:46, schrieb Pavel Sanda <
> sa...@lyx.org>
> > Kornel Benko wrote:
> > > commit 6a4a88e98afbb9555f502d6aebef1f0ae84cff31
> > > Author: Kornel Benko
> > > Date: Wed Ju
Dear Roger,
> terminate called after throwing an instance of 'std::bad_cast'
> what(): std::bad_cast
> Abort trap
That's something I'm also struggling with. I tried to compile LyX
1.6.5-release with exactly the same settings as I did with trunk,
which runs successfully. So the problem seems to
Roger,
I thought this was a bug in gettext on Mac and fixed in newer versions
(may not be released yet).
I fixed it with the following patch:
--- po/Makefile.in.in.orig 2010-01-22 01:13:10.0 +0900
+++ po/Makefile.in.in 2010-01-22 01:13:44.0 +0900
@@ -56,7 +56,7 @@
XGETTEX
Looking at my current situations, I feel like my current pace (i.e. to
post from time to time) is the most I can do at this moment. So, I
think I'd better ask you for the right when not having it becomes an
obstacle...
Thank you so much for the offer. I'm going to continue posting as before.
Best
Thank you! It's honorable for me, but I feel like my contributions
need to be checked by someone else. I think it'd be safer that I
continue posting staying at current status ;)
Thanks and regards,
Koji
> docstream.cpp:19:19: error: iconv.h: No such file or directory
Maybe you need
./configure --with-libiconv-prefix=/usr/local
given that you have installed libiconv?
Koji
> I came across this site,
>http://www.passiv.de/
Yes, this design of language switch seems more noticeable and it is
also natural. In this case, the language switch is only indicated to
the home page?
I personally don't have a special preference on whether we should have
a switch for ind
I think it's a good idea, but if the indicator of translations sits among
other menus, it may be slightly confusing. (In this case, the meaning of
flags is slightly different from the one of other menus, isn't it? They are
not submenus of Languages menu.)
Moving flags to, say, top-right corner of
> Well, which will be easier for japanese viewers to easily find? If it's
> the english text "japanese" among the other text, or if it's an image with
> it written in japanese? (I suspect the latter, but I don't know).
Well, of course, if it is written in Japanese language, it's much more
easil
>
> You mean I may translate 'Japanese' into Japanese :) in the main side bar?
>
That is, I suspect it becomes a mess if Japanese font is not installed. So,
I may better change it only on WebJa.SideBar or put a Japanese translation
of 'Japanese' as an image.
Koji
>
> What do you think of the current change? (Fell free to translate 'Japanese'
> into japanese)
>
It looks nice. You mean I may translate 'Japanese' into Japanese :) in the
main side bar?
PS I did look for flags, but so far I've only found really small ones.
>
Indeed, small icons seem standard
Automatic change of languages according to web browser setting sounds great.
As for the menu entry, I'm not sure if there is enough space when several
languages become available. Some design invention may become necessary (e.g.
putting small country flags?)
Regards,
Koji
2008/12/21 Christian Ridderström
> I believe there was in fact no actual damage at all... Apparently I had
> already created a side bar that was local to the group 'Web', i.e. the page
> 'Web.SideBar'. This means that when you modified 'Site.SideBar', this didn't
> affect the primary web pages at
Oh, so I have changed the common sidebar. Sorry for my mistake.
I hope the damage was not huge...
Best regards,
Koji
45 matches
Mail list logo