FWIW, I've done some LyX->LyXHTML->XML conversions, as well as
LyX->XML via Python (to fix text styling open/close mismatching) and
then XSLT.
You can find that work here: https://github.com/nicowilliams/lyx2rfc
It's a bit old and rotted, but it illustrates something like
LaTeX->XML, but for LyX
On Tue, Feb 17, 2015 at 08:45:04PM +0100, Georg Baum wrote:
> One option which is probably easy to implement would be to mark the start
> and end of the ERT inset with two unicode symbols from the private use area
> (similar to META_INSET): We could define
>
> char_type const MATH_ERT_BEG = 0x20
On Mon, Apr 7, 2014 at 8:24 AM, stefano franchi
wrote:
> I haven't done any concrete coding in the area, but my favorite strategy
> for the Word-->LyX step would tend to lean toward a direct parsing of the
> XML format produced either by Word (the docx format) or by
> {Open|Libre}Office (the odt
On Fri, Nov 8, 2013 at 2:48 AM, Vincent van Ravesteijn wrote:
> On Thu, Nov 7, 2013 at 10:40 PM, Nico Williams
> wrote:
>> _Never_ push -f to any repo that *others* (or even you, in other
>> workspaces) pull from.
>
> In general it is better to not rewrite history if
On Thu, Nov 07, 2013 at 09:23:15PM +, Tommaso Cucinotta wrote:
> Sure, feel free to commit them. Guess that in multi-user commit mode,
> it's much better to NOT rewrite history, so we won't use push -f, right ?
> (Vincent ?).
_Never_ push -f to any repo that *others* (or even you, in other
wor
Hi, this is pretty awesome indeed!
Would it be possible to do somethin OTR-like (in the sense of hiding
extra data) for exchanging cursor movement operations / cursor
location, and changes (typing, ...)? That would make it possible to
collaboratively edit LyX docs.
On Thu, Oct 17, 2013 at 8:02 PM, Vincent van Ravesteijn wrote:
> Nico Williams schreef op 18-10-2013 0:59:
>
> The ironic thing using Git is that it is very safe if and only if you know
> your way around with Git. I remember that when I started using Git, I
> frequently lost stu
On Thu, Oct 17, 2013 at 8:11 PM, Cyrille Artho wrote:
> I once made a mistake with git, too, that took a while to recover.
>
> IMHO git works well if
>
> (1) You are very careful and RTFM closely before using "reset", "rebase".
Rebase is not destructive: your commits remain available via the
refl
In general, if you stay away from destructive operations, git is quite
safe. If you find yourself wanting to perform a destructive
operation, make sure first that any extant changes in your workspace
are committed so that you can always get them back from the reflog.
Committing stuff you don't wa
On Wed, Oct 16, 2013 at 5:23 PM, John Tapsell wrote:
> Like it says, that commit is a merge..
>
> You can just checkout that commit: git checkout HEAD@{27}
>
> or reset to that commit: git reset HEAD@{27}
Personally I advise against using git reset except when you *really*
know it's what you w
On Thu, Oct 17, 2013 at 1:49 PM, Pavel Sanda wrote:
> Josh Hieronymus wrote:
>> 1. Breaking an XHTML file into smaller files can lead to better performance
>
> I think that for people who use XHTML as export format for different formats
> won't be happy about this.
Indeed, I would be unhappy abou
On Fri, May 10, 2013 at 12:45 PM, Richard Heck wrote:
> The only significant worry here concerns stability: Could a Qt update break
> us? We already depend heavily on Qt, so this is not as large a concern as
> with depending upon other external libraries. And my sense is that these
> classes are l
I should add that while *writing* XML is easy enough (valid XML too),
it's reading that's hard, so you can't avoid using a library.
On Thu, May 9, 2013 at 4:27 PM, Richard Heck wrote:
> The LyX document is internally a (very complex) tree structure, so I think
> this is pretty simple. As Jose mentioned, Lars has the write side of it
> pretty much done a long time ago. My sense is that it was so long ago that
> it would be as m
On Thu, May 9, 2013 at 8:21 AM, Alex Vergara Gil wrote:
> First of all, This is a very old feature request that will be greatly
> appreciated at least from my part!
Me too.
> I think there are much work done in this sense, please read Nico Williams'
> approach. I think is t
Reading will be easier, I think, for the reasons I've described before.
Also, you could use lyx2xml to write so you can test the read path, but I
don't know of an xml2lyx tool you could use for the reverse.
Just my 2c.
On Thu, May 2, 2013 at 2:22 PM, Richard Heck wrote:
> On 05/02/2013 03:16 PM, Nico Williams wrote:
>>
>> On Thu, May 2, 2013 at 2:01 PM, Tommaso Cucinotta wrote:
>>>
>>> As an immediate concern, adding to Pavel's ones, I have to say that I'm
>>
On Thu, May 2, 2013 at 2:01 PM, Tommaso Cucinotta wrote:
> As an immediate concern, adding to Pavel's ones, I have to say that I'm not
> so sure that merging different edits on the .lyx file level, very much like a
> version control system would do in presence of concurrent commits, would
> actual
On Tue, Apr 30, 2013 at 3:41 PM, Tommaso Cucinotta wrote:
> On 30/04/13 10:51, Nico Williams wrote:
>> Part of the XMPP/whatever fabric gets disconnected from the rest. Now
>> you have two LyX instances collaborating but unable to reach each
>> other. What do you do
On Tue, Apr 30, 2013 at 3:26 AM, Tommaso Cucinotta wrote:
> On 30/04/13 00:23, Nico Williams wrote:
>> Well... If a paragraph is deleted then the pointer might get assigned
>> in a subsequent allocation and... you end up with an aliasing problem.
>
> I was thinking of detect
On Tue, Apr 30, 2013 at 2:49 AM, Liviu Andronic wrote:
> I must admit that I share Pavel's sentiment: I'm not sure how much the
> community needs/requires a chatting function in LyX. But I was
> thinking of possibly a cheap workaround: Why not communicate with
> images?
LyX doesn't. Getting thro
BTW, this has all been solved before (clearly). Research it and use
whatever protocol pattern is most appropriate (or, if you can't
because of patents, invent a new protocol).
Some posts on this list pointed at some such prior work.
On Mon, Apr 29, 2013 at 6:21 PM, Tommaso Cucinotta wrote:
> On 30/04/13 00:11, Nico Williams wrote:
>> But do you want to reuse an OTR
>> implementation?
>
> The question is why OTR, but perhaps the answer is simply that is already
> made to be compatible with messagin
On Mon, Apr 29, 2013 at 6:03 PM, Tommaso Cucinotta wrote:
> On 29/04/13 23:32, Nico Williams wrote:
>>> However, when considering that other users might be editing stuff
>>> above/before our
>>> cursor position, then it means this way of referencing positions with
On Mon, Apr 29, 2013 at 6:06 PM, Tommaso Cucinotta wrote:
> On 29/04/13 23:26, Nico Williams wrote:
>>> It's possible to use OTR:
>>> http://en.wikipedia.org/wiki/Off-the-Record_Messaging
>>
>> Yes. Let libpurple (or similar) take care of this for you.
>
On Sat, Apr 20, 2013 at 5:33 AM, Tommaso Cucinotta wrote:
> Concerning the interactive editing, I also remembered some critical issues
> faced
> during my prior quick hack: LyX internally uses index positions for the
> cursor,
> i.e., my cursor is on the 3rd paragraph, 5th character, and in case
On Sat, Apr 20, 2013 at 7:06 AM, Vinícius dos Santos Oliveira
wrote:
> 2013/4/20 Tommaso Cucinotta
>>
>> 3) client-side encryption add-on: can we exchange b64 encoding of
>> client-side
>>encrypted text segments, so that IM servers cannot see what's being
>> exchanged ?
>
>
> It's possible to
On Thu, Apr 25, 2013 at 1:54 AM, Guenter Milde wrote:
> On 2013-04-24, Nico Williams wrote:
>> After that apply an XSL to change schemas.
>
> Yes, this was my idea.
>
> However, going the XML/XSL way we still need to handle the
> incompatibilities between the document mode
On Wed, Apr 24, 2013 at 4:40 PM, Guenter Milde wrote:
> On 2013-04-23, Zahari Dim wrote:
> On the LyX side, adding reStructuredText as one export format could be
> sensible. Again, this would not be ready for round-trips.
>
> This means it might be easier to use XML as intermediate format: Docutil
On Monday, April 15, 2013, Jean-Marc Lasgouttes wrote:
> 15/04/2013 13:54, William Adams:
>
>> I guess the best solution would be for QT to become friendly to screen
>> readers, but that's out-of-scope.
>>
>
> Actually, the WorkArea is completely curtom, not under the control of Qt.
> So we would
On Sunday, April 14, 2013, Guenter Milde wrote:
> On 2013-04-13, Fernando Botelho wrote:
> > I consider TeX and LaTeX, a potentially extremely useful technology for
> > the blind, because it can allow wonderful formatting even for someone
> > who is blind. LYX, or the idea of accessing the power o
On Thu, Apr 11, 2013 at 2:42 PM, Georg Baum
wrote:
> No. I don't want LyX to run any checkout command. I do not even need the
> simple checkout with svn that Pavel uses. If you look into the sources you
> can see that the VCS states VCS::LOCKED and VCS::UNLOCKED are not used with
> the git backend
Here's my (8), really my #1: 3-way diff/merge support.
On Thu, Apr 11, 2013 at 8:46 AM, Richard Heck wrote:
> On 04/11/2013 08:45 AM, Elias Assarsson wrote:
> Here's a quick guide to how the export routines work. Basically, it starst
> at Buffer::makeLyXHTMLFile(), which just sets up a file stream, does some
> preliminary configuration, and calls Buff
On Thu, Apr 11, 2013 at 1:42 AM, Pavel Sanda wrote:
> Nico Williams wrote:
>> Indeed. I just want LyX to not ever run a git checkout command. Not
>
> This is between you and Georg :)
>
>> limit itself to informational actions only in the case of git-like
>
On Thu, Apr 11, 2013 at 12:34 AM, Pavel Sanda wrote:
> Nico Williams wrote:
>> I see the smiley. I hope to convince you to stop the use of RCS :)
>
> Then you will need to show better arguments :) I was talking about single
> lyx documents 50-400 pages, not about linux kernel.
On Wed, Apr 10, 2013 at 11:30 PM, Pavel Sanda wrote:
> Nico Williams wrote:
>> But standalone RCS or SCCS is (should be!) a rarity now -- so early
>> 90s! no, so 70s! :) I'd encourage you to encourage your users to
>> switch to a modern VCS and drop the RCS code.
>
On Wed, Apr 10, 2013 at 7:46 PM, Pavel Sanda wrote:
> The project listed in GSoC intended 3) and perhaps fix 1. It wouldn't
> be wise to create completely new export routines and my hope is that
> routines in 2) can be reused in large part with perhaps few switches.
It might well be wiser to drop
On Wed, Apr 10, 2013 at 8:22 PM, Tommaso Cucinotta wrote:
> On 10/04/13 00:26, Nico Williams wrote:
>>> But again, git ls-files seems WAY EASIER.
>>
>> This will tell you if a file is tracked, not whether it has unstaged
>> or uncommitted changes.
>
> Ok, le
I should add that I'm willing to help you familiarize yourself with
XSLT, answer XSLT questions and so on. Then you might be better
informed about how to attack this problem. You'd still need to talk
to a proper LyX mentor.
Nico
--
On Wed, Apr 10, 2013 at 4:37 PM, Adrián Pereira wrote:
> Absolutely, i didn't know about XSLT.
> i'm actually forking lyx. Then i'll take a look at the code in the repo.
> So, the problem is to find a schema for doing the translation between .lyx
> and XML. If you have a Python script that does .l
Would it be easier/better to have XML export and then use XSLT for
XHTML/HTML/CSS and ePub conversions?
Using XML as a go-between would require doing something about defining
a stable schema, explicit or otherwise. I've a Python script to
convert .lyx to XML with an implicit schema, but it's no m
On Wed, Apr 10, 2013 at 2:52 AM, Tommaso Cucinotta wrote:
> > This means we're not in a workspace.
>
> It doesn't seem like that, from my exps:
>
> // both README and README.xx exist on FS
> tommaso@mobiletom:~/lyx-trunk-ws/lyx$ git status --porcelain README
> tommaso@mobiletom:~/lyx-trunk-ws/lyx$
On Tue, Apr 9, 2013 at 6:26 PM, Nico Williams wrote:
> So, to wrap up, I think you want:
>
> fork(), chdir() to the directory containing the file, exec() git
> status --porcelain, and parse the result in the parent process (read
> via a pipe), then display the status (for each
On Tue, Apr 9, 2013 at 6:05 PM, Tommaso Cucinotta wrote:
> Ok, really really wanting to use git status --porcelain, we can go for the
> following (but I hate it).
> Let me write it in shell code:
I guess I can't get you to give up on this :(
:)
So, to find out if a path is in a workspace:
On Tue, Apr 9, 2013 at 1:36 PM, Liviu Andronic wrote:
> On Tue, Apr 9, 2013 at 8:20 PM, Nico Williams wrote:
>> textual user, I prefer everything as textual as possible. I'd even
>> like a search feature for menus/functions, and in general I'd like
>>
> That&
Since we're piling on...
I don't mind the sort of ribbon menu as they've evolved to be at MSFT,
but I do prefer pull-down menus with *text* instead of icons. I'm a
textual user, I prefer everything as textual as possible. I'd even
like a search feature for menus/functions, and in general I'd lik
On Mon, Apr 8, 2013 at 4:22 PM, Tommaso Cucinotta wrote:
> On 04/04/13 03:03, Nico Williams wrote:
> > ...
> It looks like you'd like LyX to launch gitk! Why repeating all that stuff
> within LyX :-)?
Actually, I want LyX to do *nothing* with git *except*, maybe, tell
Please, please give me an option to have LyX do nothing regarding git.
In particular I want an option to have LyX make absolutely no
commands like: git add, git commit, git pull, git push, git merge, git
cherry-pick, git branch, or git checkout, and no versions of any of
those that have side effec
On Mon, Apr 8, 2013 at 3:34 PM, Jean-Marc Lasgouttes wrote:
> We could have a paste-special menu entry that opens a dialog with the
> text-as-line and text-as-paragraph options too.
+1. Tasting content-type is error-prone (but an OK default for ^V);
the user likely knows the content-type, and ev
On Tue, Apr 2, 2013 at 2:19 PM, Georg Baum
wrote:
> There are three (minor IMHO) drawbacks:
>
> 1) The LaTeX detection for pasting is a heuristic and may fail in some
> cases. If that happens, tex2lyx is run on text that is not really LaTeX, and
> this may give unexpected results. If that happens,
On Apr 3, 2013 6:58 PM, "Pavel Sanda" wrote:
> Perhaps we can drop this check-out behaviour if it makes troubles, wait
for Georg's opinion.
> There is also still the problem that we run GIT::find_file 2x IIRC.
I'm hard-pressed to think of git-specific behavior in LyX that i want
besides a) a menu
On Tue, Mar 26, 2013 at 2:55 PM, Pavel Sanda wrote:
> One measurable thing is asking general audience here or on users list and we
> sometimes do this to get some feeling about overall preference.
I'd say that's working, though establishing consensus has its costs,
and it's not yet clear whether
On Tue, Mar 26, 2013 at 2:42 PM, Nico Williams wrote:
> How can you know if they'd switch it on if they don't know about it?
This is a real problem when we're talking about new features. You
could disable them by default and see what happens, but users then
might not l
On Tue, Mar 26, 2013 at 1:47 PM, Pavel Sanda wrote:
> Jean-Marc Lasgouttes wrote:
>> Are there programs that you use routinely for which you do not change the
>> defaults?
>
> Sure, but why to make it worse. Anyway you are not replying to my point,
> which is:
>
> Features should be enabled by th
On Mon, Mar 25, 2013 at 4:23 PM, Richard Heck wrote:
> On 03/25/2013 04:09 PM, Scott Kostyshak wrote:
>> You describe the same use case that Liviu describes. I don't understand
>> what the advantage of toggling continuous spellcheck is over using normal
>> spellcheck for this workflow. If one does
On Mon, Mar 25, 2013 at 3:40 PM, Scott Kostyshak wrote:
> On Mon, Mar 25, 2013 at 4:29 PM, Georg Baum
> wrote:
>> Scott Kostyshak wrote:
>>
>>> Note that this discussion is related to the discussion of the toolbar
>>> button: http://www.lyx.org/trac/ticket/8589
>>>
>>> You describe the same use c
On Sat, Mar 23, 2013 at 1:00 AM, Pavel Sanda wrote:
> Scott Kostyshak wrote:
>> because my only argument in favor was a guess that most users prefer
>> to have it enabled. But after seeing Liviu's ticket (#8589) I talked
>
> How counted? :)
> The people who are satisfied are silent now of course.
On Jan 15, 2013 1:53 AM, "Kornel Benko" wrote:
>
> Am Montag, 14. Januar 2013 um 09:45:11, schrieb Nico Williams <
n...@cryptonector.com>
>
>
> > You can always git clean.
>
>
>
> Thanks, but ...
>
>
>
> 1.) This is not OK, if you hav
On Mon, Jan 14, 2013 at 1:10 PM, Jerry wrote:
> If you are implying complete automation, I have no idea how to make a script
> that scrolls through the User's Guide (my objective test) and measures how
> long it takes.
No, you have to do that part yourself. Well, there are UI macro type
tools
On Sun, Jan 13, 2013 at 7:18 AM, Kornel Benko wrote:
>> Also, does this cmake command pollute my source tree? How can I define a
>> build tree?
>
> I tried to pollute as little as possible, but in general, you are not
> encouraged to call
>
> cmake from the source tree.
You can always git clean.
git push --tags theremote thebranch
I've pushed an update to lyx2xml in my clone of lyx that uses XML
namespaces for layouts and insets, and which supports math (though it
doesn't output MathML, sadly, not yet).
So now the XML output looks more like this:
some text
Whatever
and so on.
This is much nicer than the earlier version'
On Fri, Dec 28, 2012 at 6:15 AM, Vincent van Ravesteijn wrote:
> Op 27-12-2012 23:27, Nico Williams schreef:
> On Dec 27, 2012 3:07 PM, "Vincent van Ravesteijn" wrote:
>>> You can correct almost everything with git. Just don't push a wrong tag,
>>> ...
&
On Dec 27, 2012 3:07 PM, "Vincent van Ravesteijn" wrote:
> You can correct almost everything with git. Just don't push a wrong tag,
...
Right, because deleting a branch or tag, or making a branch name refer to a
completely different line of commits (e.g., rebase) are destructive
operations, but a
On Dec 27, 2012 2:43 PM, "Richard Heck" wrote:
>
> On 12/27/2012 03:27 PM, Nico Williams wrote:
>>
>> On Thu, Dec 27, 2012 at 2:18 PM, Richard Heck wrote:
>>>
>>> So the voting seems to be that we should release a 2.0.5.1, with just
the
>>&g
On Thu, Dec 27, 2012 at 2:18 PM, Richard Heck wrote:
> So the voting seems to be that we should release a 2.0.5.1, with just the
> fix for the babel issue. The question now is how, in git, to do this.
>
> It's easy enough to do:
> git checkout tags/2.0.5
> This puts me in "detached head", thou
On Thu, Dec 27, 2012 at 11:22 AM, Richard Heck wrote:
> On 12/26/2012 01:03 PM, Nico Williams wrote:
>> Granted, if I had a faithful XML schema equivalent of .lyx then version
>> changes could break my XSLs. But I could work around that via XSLs to deal
>> with version change
On Thu, Dec 27, 2012 at 4:29 AM, Vincent van Ravesteijn wrote:
>> I'm not proposing XML as the native format.
>
> In my opinion, there is only a small step between having a "faithful .lyx
> format" and a "native LyX format".
But having a faithful XML version of .lyx is only a step in that
directi
On Wed, Dec 26, 2012 at 5:54 PM, Pavel Sanda wrote:
> Nico Williams wrote:
>> future XML document conversions based on XSLT, I think once you familiarize
>> yourself with XSLT you'll agree with me that it's much better and easier to
>> use XSLT than to write C++ to
On Wed, Dec 26, 2012 at 2:02 PM, Nico Williams wrote:
> On Dec 26, 2012 5:46 AM, "Pavel Sanda" wrote:
>> The problem is that once we ship it under LyX flag officially we are
>> responsible to fix its bug and maintain it in future. That's why so
>> much fuss ar
And my script is a Python script. It enables the use of XSLT by producing
XML, but no knowledge of XSLT is needed to support that script. As for
future XML document conversions based on XSLT, I think once you familiarize
yourself with XSLT you'll agree with me that it's much better and easier to
Regarding Docbook... if it can preserve all LyX metadata, including custom
insets and such and not lose much in a round-trip conversion, great, but I
suspect it can't. Really, you need an XML schema that is as closer an
analog of .lyx as possible.
XSLT is not going away. Reproducing its power in
On Dec 26, 2012 5:46 AM, "Pavel Sanda" wrote:
> The problem is that once we ship it under LyX flag officially we are
> responsible to fix its bug and maintain it in future. That's why so
> much fuss around.
One more thing: with a few simple rules we can make lyx2xml a maintenance
fee script. The
Also, not to belabor the point, but one of the things I want to be
able to do is import from XML. LyXHTML, as a presentation format, is
not a very good choice for generating .lyx from.
On Wed, Dec 26, 2012 at 5:45 AM, Pavel Sanda wrote:
> Nico Williams wrote:
>> I've filed a request for enhancement so that external "plugins" can be
>> found by configure.py.
>
> Sure, I know. What I don't know is whether or when someone will pick it up
On Tue, Dec 25, 2012 at 7:50 PM, Pavel Sanda wrote:
> I think we can support your converter via recognition in configure.py
> so XML convertor appears in View/Export menus when installed.
> We can also put it in contrib section on our ftp server, if you would like.
I've filed a request for enhanc
I've some code that works for my sample .lyx files, though these,
admittedly, don't really exercise the full power of LyX.
The code is here: https://github.com:/nicowilliams/lyx -- look in
lib/lyx2lyx/, there's three new files: lyx2xml, lyx2xml.py, and
xml_streamer.py.
Here's what works:
- meta
78 matches
Mail list logo
