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
How add something authomatically in preamble?
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