[Texmacs-dev] Re: Compiling TexMacs on OSX

[Henri Lesourd]

Abdelrazak Younes wrote:

> Henri Lesourd wrote:
>
> > I want none of these alternatives, all these things
> > look like it would bloat the software rather than
> > helping.
>
>
> These things could help you saving some time

It looks like it will save you time, but in practice,
the risk is spending much more time in managing the
new dependencies it introduces.

It's not clever at all to depend on Qt's XML parser,
for as soon as you do this, you need the Qt lib
installed on your target system *all the time*.

That's definitely not what we want.


> to concentrate on the word processor thing but that's not your 
> business, I understand that now.
Improving the word processor is a separated
business, and the related code is completely
independent from any toolkit.

In fact, word processing has nothing to do
with widgets, for everything occurs inside
a specific widget (i.e. the "editor" widget),
and the job of the editor is mainly reading
keyboard and mouse, and drawing on the canvas.


> > Frankly, writing a simple XML parser is a matter of
> > some days and some dozens of kilobytes, I don't need
> > any "designer" to bloat my code.
>
>
> This, some days, plus that, add a few more days, oh and that too, plus 
> a bit of that...

Having a clear image of what exactly are these "that",
this other "that too" and this other "bit of that" is
exactly the job you *must* do if you are interested in
managing the architecture of your software.


> as I said, it's perfectly fine to educate yourself by reinventing 
> these things if that interests you.
The problem is not "reinventing" things, it is
having a lightweight and maintainable codebase
with as least dependencies and redundancies as
possible.


> > And in any case, loading at runtime needs *compiling*
> > some C/C++ code in a DLL, if you want to be completely
> > general. To do this, you must proceed in a specific
> > way, namely, encapsulating your C++ classes behind
> > a C API, for otherwise, you cannot link the C++
> > without recompiling the whole application.
>
>
> That's absolutely not true, I can dynamically link LyX with Qt C++ 
> dlls without any problem.
No, what you are describing is the standard sharing of
dlls performed by the OS and the compiler by means of
mangling C++ method names.

The dynamic linking by means of dl_open() is another
thing complelely, in such a case, you need to explicitely
seek for the entries in the DLL, and these entries are
exclusively C functions.

And you need this kind of dynamic link if you
really want to turn your software to be extendible
by means of loading independently compiled DLLs
inside it.


> > I don't speak about performance here: the problem with
> > object-oriented programming is that it very easily leads
> > to a sophisticated kind of spaghetti code.
>
>
> Any programming method can lead to spaghetti code and C-ish procedural 
> method is not the least one in this category.

Yes but how to do things correctly is much clearer
in C-ish dialects than in object oriented programming,
and if you do things well, it leads to much robust
and especially, code which is usually easier to refactor.

If C++ were so good, people would use it to write OS
code: it turns out that neither UNIX code, neither the
windows kernel code is written in C++.

In my opinion, there are well principled reasons to
this, these people are not masochists, you know. It
only turns out that C++ is not a sufficiently robust
language, it is for example notorious that even
very well written C++ programs tend to be fragile
and hard to debug.


> The reality is that you should adapt the method to the problem at 
> hand. C++ supports generic, OO and procedural programming hence is the 
> perfect language for *me*. This is just a matter of style, a good C++ 
> programmer will be a good C programmer and vice-versa; you can also do 
> OO with C but you need a lot of glue code. So no, I don't bye this 
> argument if you are a good programmer. Anyway, let's not engage in a 
> language flame war :-)
The real issue behind this discussion is: as far as
dynamic loading and function calls to foreign code
are concerned, and as far as sharing data is concerned,
can you trust the language ?

If you want to be really dynamic, the answer is that
in current operating systems, linkers are implemented
at the C level, thus the only reliable way is to
operate at this level, too.


> > > And I would also dare to say that the user doesn't care about 
> > > dynamically loaded interface, he/she just want something to work.
> > In the case of TeXmacs, things could be different,
> > for a user could be developing an application on
> > top of TeXmacs. In such a case, the ability to develop
> > your own Qt components, then dynamically loading them
> > inside TeXmacs (without the need of recompiling TeXmacs)
> > could be interesting, and even, important.
>
>
> Interesting, certainly but in 2020 when you have finished with this it 
> might loose a bit of its importance :-)
It does not takes working till 2020 to do this.


> > > This is open source, if the need arise for a new function, we add 
> > > it, we recompile and we release a new version, that's it.
> > It means that you don't consider LyX in the tradition
> > of emacs, i.e. as a platform that you can morph to
> > anything. Otherwise you would not say that.
>
>
> Oh I know Emacs (I prefer XEmacs), it's an excellent text editor and 
> very good for programming. At least that was the case 15 years ago. I 
> remember the good old time when I had to modify unintelligible lisp 
> code in order to have good C++ highlighting... Now I use free version 
> of MSVC and -blasphemy- I am pretty happy with it :-) Oh I also tried 
> the various embedded apps in Emacs-the-OS (totally against the Unix 
> philosophy) and, quite frankly, the special purpose apps was always 
> more powerful and simpler to use with less occasion to fuck up 
> everything. That is my personal experience... nothing more. Maybe many 
> people still use the list apps within Emacs but I would be very 
> surprised. But I am very sure that many people still use Emacs for its 
> core competence namely source-code editing.
Emacs has its problems, but it doesn't means that
the original idea is bad.


> > > My opinion: change the C++ code, recompile and release a new 
> > > version. But I already said that :-)
> > That's not what we need, we want something rather
> > like Javascript.
>
>
> When you say "we" I am not sure you speak for a lot of people and you 
> are very numerous in this way of thinking.

Well, I have been employed in a lab since 4 years now,
specifically because TeXmacs is a extendible editor
which can be used for implementing applications on
top of it.

Were it not possible to do this, these people would
not have been interested in only an editor to do
wysiwyg LaTeX. What they want is using TeXmacs as
an *interface*, and for this you need programmability.


> Maybe you should ask the TeXmacs users (and some developers too I 
> guess). Maybe they will tell you that they you that they first and 
> foremost want a WYSIWYG scientific editor that has the same 
> typesetting quality as TeX. Maybe they are not that much interested in 
> writing documents that embeds dialogs and buttons.
Embedding dialogs and buttons is a small, unnecessary
part of what you need to turn TeXmacs to an intelligent
user interface (although of course it would be nice
to have it, but this is not at all the important
point): rather, the really mandatory features are
a DOM-like API to interactively modify documents,
and a way to channel changes a la XMLHTTPRequest.


> I was just trying to tell you that, if it was me, I would concentrate 
> on providing a good GUI that would help the user to use the excellent 
> typesetting capabilities of TeXmacs, that's all.

Other developers do this in TeXmacs, not me (at
least now).


> have fun with this project, this is certainly the most important thing 
> :-)
Right :-)