Another puzzle appears: how to make an initialization of this file? I tried update -> buffer. Nothing happens.
How add something authomatically in preamble?
I believe my-init-buffer.scm is run for every opened file, but this line prevents the code from running on existing files:
(if (not (buffer-has-name? (current-buffer))))
I don’t think the current code would work on an existing file. I believe it would overwrite the preamble, although I haven’t tested it.
You can append to an existing preamble, but then one would have to check whether the desired command is already in the preamble or not, so as not to add another copy every time the file is opened.
I deleted this part of the code and it works!
I did not understand the question, sorry.
Getting back to what @jeroen wrote, my-init-buffer.scm is run every time a buffer is initialized.
The line
(if (not (buffer-has-name? (current-buffer))))
makes the code run only for buffers which do not have a name. To have the <specific|latex|... macro in your file, you do not need to update anything: you just need to start a new file, and it will be there.
@jeroen It overwrites the preamble, I just checked it.
I expect it will work the first time. Judging from @pireddag comments, however, it seems like if you would make any changes to the preamble later, they would be overwritten the next time you open the file.
Perhaps a menu item “append my LaTeX preamble” would be a good way to handle existing files. You would just need to click it once for existing files. For that the code needs to be changed a bit, though.
I wrote in a misleading way. I meant: if the conditional (if (not (buffer-has-name? (current-buffer))) is not there, the preamble is overwritten the next time you open the file. If it is there, you get the insertion for a new file and no changes when you open the file later.
“append my LaTeX preamble” is a good idea. Maybe better to send in savanah as a suggestion?
It’s worth a try. It may take a while for anyone to look at it, developer resources are limited.
There’s also a wishlist here: https://texmacs.github.io/notes/docs/wishlist.html
I understand. I started to learn scheme and can not be a developer. One question. Where in texmacs source I could find definitions of variables like, for example, buffer-has-name?
That particular function happens to be defined in the C++ part of GNU TeXmacs, it’s the buffer_has_name function in src/Texmacs/Data/new_buffer.cpp
It is exported to Scheme as buffer-has-name? in src/Scheme/Glue/build-glue-basic.scm
Thank you. I’m a physicist and learning a little bit scheme and did not produce a program. I read that the TexMacs was written by using scheme. But the source code of the Texmacs is C++. I thought that I could read the source code in scheme and (maybe) understand it. Could you explain me this point?
Before @jeroen tells you how-to find the place where a Scheme function is defined—Scheme is used by TeXmacs as an extension language: that means that TeXmacs is written in C++, but one can modify the behaviour of the program without recompiling it through Scheme code. I do not know how this works, but there are interfaces (I think that they are called the “glue”) through which Scheme communicates with the compiled C++ code.
Thanks a lot. In directory Texmacs, all files are written in scheme.
Probably the most convenient way to explore the source code is via Help -> Search -> Source Code inside TeXmacs.
According to Github 25.7% of the TeXmacs repo is C++, while 22.7% is Scheme.
I’m not a developer either, but from browsing the C++ code, it seems to contain various important functionality: the GUI interface, font handling, the typesetter, datatypes such as tree,…
I can’t say I know what rationale determines what is done in C++ and what is done in Scheme. My guess is that if you only need to access the document tree structure and can make do with the functionality exposed by the C++ code, you can stick to Scheme. This is what we did previously in our development of new label selection functionality, we searched the tree and used GUI elements that were already present.
If you want to implement more fundamental functionality, such as line numbering or wrapping figures, you’ll most likely have to dig into the C++ code.
See also “The gory details” section in this blog post.
I feel that a better solution is to create your own style file with your preferred macros and customisations and then, whenever needed you just click on the “+” sign in the focus bar (when you are focussing on the whole document) and select “Other packages…” and then type the name of your style file which probably should be in $TEXMACS_HOME_PATH/packages/. You can use the function “Edit package” to add things to it (but I think it should exist already). If you want to see examples of packages just look into $TEXMACS_PATH/packages/example where there are some user customised style files (e.g. the one of Joris).
I agree that in general a style file is the way to go, but the problem with this case is that a <specific|latex|…> tag in an included style file is ignored during conversion. If you put it in the preamble it does work.
Ok, I see. Sorry I think I have read the discussion too fast. Is this not a bug? Maybe Joris should be made aware of this problem.
It’s certainly not very intuitive 
I would have expected the preamble and style files to behave equivalently. The question is, should they both include or both ignore <specific|...|...> tags?
The HTML export does things a bit differently. There you can manipulate parts of the “head” by assigning to html-css, html-head-javascript, etc. Perhaps instead of using specific a latex-preamble could be used to specify additions to the latex preamble?
We should give a look in the LaTeX conversion code if there is some “hidden” hook we can use.
Some experimenting with html-css and html-head-javascript shows that these work the other way around, only in style files, not in preambles!
This could certainly do with some unification