I have not noticed this before, but http://tug.ctan.org/ mentions LyX
on the "Search the archive" page:
"There is a word processor-like interface for LaTeX, called LyX."
Lgb
>> Bernd Noll writes:
BN> Hi all! Have some wishes/suggestions for the next version of LyX
BN> :))
BN> LyX internal ...
BN> 1. Character Styles Strikethrough & Changebar ( it would be
BN> great, if there was an option to automatically set changebars on
BN> to everey added characte
>> Frank de Lange writes:
FdL> On another front, I'd like the GTK-port to be able to use Gnome
FdL> if present, but it should not depend on it. A small question
FdL> lingers in my mind: how free are we to create our own dialog
FdL> structure? I created a (rudimentary, only GUI stuff with
Hi,
I just wanted to put the 'replace all' stuff into 1.1. I changed form1.fd with
fdesign, did "make -f makefile.eigen". It failed, I had to remove credits_form.fd
from the makefile (otherwise: "no rule to make target credits_form.c"). Now it
seemed to work.
Lyx compiled, but linking failed wit
> You forget paste from X clipboard with "COMPOUND_TEXT" property.
That is not a performance critical operation, so the memory consumption or
Unicode middle layer is no problem.
> Unless the encoding of the file is different from the document encoding,
> the Unicode middle layer must be skipped.
I think that the different front ends should be completely open!
Any porter should decide which way to implement the LyX interface, IMO.
This could encourage more evolution of the LyX interface, and also provide an
incentive to have different front ends. If all interfaces are equal, there is
li
Hi folks,
I'm using LyX 1.0.1 on a FreeBSD 2.2.7 machine, and I just crashed it
pretty good:
## david> ll project.*
-rw-r--r-- 1 david wheel 8108 Feb 24 06:11 project.dvi
-rw-r--r-- 1 david wheel0 Mar 28 08:51 project.lyx
-rw-r--r-- 1 david wheel47571 Mar 25 05:40 project.
On Sat, 27 Mar 1999, Asger Alstrup Nielsen wrote:
> I think that we should use the same container for all documentation
> strings in LyX. Having the LString dedicated for this purpose clears
> the semantics immensely, and I would prefer to make LString a global
> phenonomem in all contexts th
>> Daniel Naber writes:
DN> Hi, I just wanted to put the 'replace all' stuff into 1.1. I
DN> changed form1.fd with fdesign, did "make -f makefile.eigen". It
DN> failed, I had to remove credits_form.fd from the makefile
DN> (otherwise: "no rule to make target credits_form.c"). Now it
D
On 28 Mar 1999, Lars Gullik Bjønnes wrote:
> Actually I can't see why we really need the InsetParbox at the first
> level. We will need something like BufferView anyway so why not let
> that take care of the first level? Of course it is nice to have a
> uniform interface... So, convince me. Why i
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> I think that the different front ends should be completely
Asger> open! Any porter should decide which way to implement the LyX
Asger> interface, IMO.
I think keeping as many similarities as possible is a good thing. I'd
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> --Boundary-=_ylneexkszGaSXFVXffuCrYJduGCm Content-Type:
Angus> text/plain Content-Transfer-Encoding: 8bit
Angus> Hi! I'm a new user of LyX although I have a good knowledge of
Angus> LaTeX and reasonable programming skills. I can't
> What I think is an error is that our atomic text data structure gets so
> tied to a very particular container that, if sometime in the future we
> find the right container to fit its requirements, we will find it
> unnecessarily difficult to do the move.
Yes, this is true.
However, with this l
> It's anyones guess which will use more memory. In the worst case, for
> LString, an LString would use 6 extra bytes per chunk. Not much of an
> arguement against LString but possibly a better arguement against a
> string<> implementation that uses power of 2 memory allocation.
Academic siden
>> Asger Alstrup Nielsen writes:
AAN> In practice, this problem is only exposed with some special
AAN> concatenation patterns, so we might not have a problem with the
AAN> current semantics. But it's worth trying to change our own
AAN> implementation to do this, and see if things improve
Hi Guys,
I've recently introduced somebody to Lyx and they love it except for one
thing and that is using citations. I've got him using Bibtex along with
harvard.sty. He has no troubles citing when the desired format is
"(Lars, 1999)", however, the problem arises when he wants to use
citeasnoun
Asger,
Why does EC.C has definitions for convertToUnicode and
convertFromUnicode? Couldn't these just be pure virtual?
and how about a name change?
toUnicode and fromUnicode, does not have less meaning than the longer
variants.
Lgb
Asger,
If I understand you correctly, you want us to use "string" in all
places where we today uses "LString". Is that correct? If so I think
we should make the switch right away.
Concerning you comment in 2.1.1 about the lack of conversions from
numbers and floats to strings: that is why we h
>> Lars Gullik Bjønnes writes:
LGB> Asger,
LGB> Why does EC.C has definitions for convertToUnicode and
LGB> convertFromUnicode? Couldn't these just be pure virtual?
Ok. For fixed with we require both to and from unicode, and for
variable length we require only from unicode.
Then I prop
>> Lars Gullik Bjønnes writes:
LGB> glyphType() decomposeGlyph(); lowercase(); uppercase();
titlecase().
Lgb
20 matches
Mail list logo
