# Revisiting kak_assert(fd >= 0);

I was just looking at some file diff and I noticed a boolean that stood out

Just mere curiosity to ask since I’m not sure what it does

anyhow, compiling with or without it I can’t see a discernible difference. Maybe the difference is there, but I’m blind like a bat, so I was just wondering… that’s all.

the same as above applies to kak_assert(fd >= 0); from bool fd_writable(int fd)

Currently this forum has intentionally remained focused on Kakoune end users, not to interfere with the development cycle or any development flow (mailing list or other) the Kakoune development side might setup. If @mawww ever want to use this for dev conversations he is welcome to and we would welcome it, but that currently isn’t the case. I am honestly not sure the right place to put a question like this… a github issue doesn’t feel right, but might be a fine place for it… IRC channel is probably the best place, but with all the issues around well – IRC channels.

@mawww for questions like the above, what would be the best place… random like “hmph, why does it do this?”

thank you Robert. I understand.

this issue was introduced here https://github.com/mawww/kakoune/commit/a1f0bae53a3f0f138e5d0f485699178cb4222a85

Wasn’t sure, and that’s why I asked. I scoured the difference among the files I have when I should have looked elsewhere. But it was more from an end-user’s perspective than anything.

This was definitely from an end-user’s perspective, You can close the issue.

I am not sure I see any issue at all. There are over 500 kak_asserts in the codebase… what “issue” are you referencing.

I meant the issue I created here with the topic. I should have been more explicit.

errata: You may close the topic, the thread, the posts.

So my understanding is that you wonder what kak_assert(fd >= 0); does ?

If thats correct, Kakoune is littered with kak_assert(<condition>) which are things that should always be true, if that condition is false, it means something went horribly wrong (a programmer error), and things that we held for true while writing the code were not.

In debug builds, the conditions in kak_assert(...) are checked, and if they are not true, an error is reported using xmessage if present. In release builds they are not checked at all.

This is relatively standard practice in C/C++ to use the assert macro for that, Kakoune has its own to control what to do on failure (displaying a xmessage is convenient because it means that Kakoune ends up blocked in a system() call, which allows us to attach a debugger and see what happened).

Asserts are a general mechanism that can be used to check pre/post conditions of functions, in this case, the face that we get a valid file descriptor (so a positive one) is a pre-condition of fd_(writable|readable), in the future, when we switch to C++20, we might use contract syntax that was voted in to achieve that.

This is relatively standard practice in C/C++ to use the assert macro for that, Kakoune has its own to control what to do on failure (displaying a xmessage is convenient because it means that Kakoune ends up blocked in a system() call, which allows us to attach a debugger and see what happened).

Now that you mention macros, and the control of that very one assert, I wanted to mention something for which I could probably find a use for, and doesnt’ require, and of this part I’m sure of, some sort of bash auto-completion such as whatever git or for that matter hugo employ.

I do remember reading someone’s comments, who said that [programmers] spend most of the time devising ideas on how to implement something. I’m not even sure right at the moment, if it were you who had said it, or someone else who did. It doesn’t matter. But my knowledge is limited and only chunks of a language I can reliably understand. Not the rest.

Allow me to deviate from the topic and from your excellent breakdown.

It’s not that I find it [the code of which I’ll mention in a minute] indispensable to have, but when I do, it serves as a reminder that the editor which I use, doesn’t have it. So, the playing field is uneven in this regard. And that’s why I thought of it.

Anyhow.

I have a tree full of macros. It’s a tree hierarchy, with an external tool by which these macros depend on, and calls them all out.

The tree holds different files with different suffixes across the spectrum.

You have the cls for a class file. You have the sty for the macro package file that also holds other macros, fd and def for fonts files, enc and map and pfb and so forth. The most important part of this whole paragraph, are the first two, and of course, some basic commands to start a document and end it.

The subdirectories hold the macros by which Kak would depend on.

The base directory holds for example the

alltt.sty     fontenc.sty       ltxdoc.cls    ot1lcmss.fd   t1enc.sty
ansinew.def   fontmath.cfg      ltxguide.cls  ot1lcmtt.fd   t1lcmss.fd
applemac.def  fontmath.ltx      ly1enc.dfu    ot2enc.dfu    t1lcmtt.fd
article.cls   fonttext.cfg      macce.def     ot4enc.def    t2aenc.dfu
bezier.sty    hyphen.ltx        newlfont.sty  proc.cls      testpage.tex
bk10.clo      idx.tex           next.def      proc.sty      texsys.cfg
bk11.clo      ifthen.sty        nfssfont.tex  report.cls    textcomp.sty
bk12.clo      inputenc.sty      oldlfont.sty  report.sty    tracefnt.sty
book.cls      lablst.tex        omlcmm.fd     sample2e.tex  ts1cmr.fd
book.sty      latex209.def      omlcmr.fd     sfonts.def    ts1cmss.fd
cp1250.def    latex.ltx         omlenc.def    shortvrb.sty  ts1cmtt.fd
cp1252.def    latexrelease.sty  omllcmm.fd    showidx.sty   ts1cmvtt.fd
cp1257.def    latexsym.sty      omscmr.fd     size10.clo    ts1enc.def
cp437de.def   latin10.def       omscmsy.fd    size11.clo    ts1enc.dfu
cp437.def     latin1.def        omsenc.def    size12.clo    tuenc.def
cp850.def     latin2.def        omsenc.dfu    slides.cls    tulmdh.fd
cp852.def     latin3.def        omslcmsy.fd   slides.def    tulmr.fd
cp858.def     latin4.def        omxcmex.fd    slides.sty    tulmss.fd
cp865.def     latin5.def        omxlcmex.fd   small2e.tex   tulmssq.fd
decmulti.def  latin9.def        openbib.sty   syntonly.sty  tulmtt.fd
docstrip.tex  lcyenc.dfu        ot1cmdh.fd    t1cmdh.fd     tulmvtt.fd
doc.sty       leqno.clo         ot1cmfib.fd   t1cmfib.fd    ucmr.fd
exscale.sty   leqno.sty         ot1cmfr.fd    t1cmfr.fd     ucmss.fd
fix-cm.sty    letter.cls        ot1cmr.fd     t1cmr.fd      ucmtt.fd
fixltx2e.sty  letter.sty        ot1cmss.fd    t1cmss.fd     ulasy.fd
flafter.sty   ltluatex.lua      ot1cmtt.fd    t1cmtt.fd     ullasy.fd
fleqn.clo     ltluatex.tex      ot1cmvtt.fd   t1cmvtt.fd    utf8.def
fleqn.sty     ltnews.cls        ot1enc.def    t1enc.def     utf8enc.dfu
fltrace.sty   ltxcheck.tex      ot1enc.dfu    t1enc.dfu     x2enc.dfu

anothe subdirectory might hold for example

autopagewidth.sty  extletter.cls  extsizes.sty  size20.clo
extarticle.cls     extproc.cls    size14.clo    size8.clo
extbook.cls        extreport.cls  size17.clo    size9.clo

The clo is an option of the package class file.

http://hopf.math.purdue.edu/doc/html/suffixes.html

But my question is the following: How can this be implemented without a setback. I do know for a fact that the tool is external which can even be invoke from within Kakoune by $latex$kak_bufname but I want kak to have more control of it.

On the other hand to have the whole set of macros (trivial macros such as the fontsize macros, or table macros, etc and trivial in the sense that are not necessarily required to compile a minimal document) working directly with kakoune would be a work-in-progress. Of this I have no doubt. But I’m referring mostly to have a minimal file with all the options available that your own installation allows. This last part, Kakoune has no control over it, and it’s up to the user to have the correct set of macros installed in the system. Furthermore, there’s no neeed to even think of the redundant thought of having an error prompt thrown at the code… That’s the reason why Kakoune has a :new window which can be called upon, and which would in return and accordingly, and as long as it’s invoked with a log file, which Kakoune already provides through an amazing reload feature unlike no other editor out there currently has it.

With the current state of operations, if the user makes a mistake the error would come back as a no selections remaining error or something like that. But this last part is not even relevant, as long as there’s another window opened appropiately with the log file of the file tex in question.

Everyone knows or mostly everyone should know that by having

\documentclass{article} % or extarticle for example
\usepackage{amsmath}
\begin{document}
text here math equations
\end{document}

would compile a dvi file or depending on the engine that was used,a pdf file.

Kakoune already provides the highlighting, and my question is how can this be tackled efficiently knowing that this is an external tool

In other words, The intended objective would be something in the lines of 'as soon as a file with a *.tex suffix is created, pull the respective macros cls, sty, etc that can be found on the hierarchy - usually on /usr/share/texmf-dist/tex/latex/ that are required to proceed and fall back immediately right after onto the current working directory where the file with the *.tex suffix is at.

I don’t know if the above is far-fetched, or simply impossible to accomplish. There may be better ideas than mine about it though, but I couldn’t think of anything else.

Other editors have exploited it until no end. This is the only playing field - as long as this is even possible - where Kakoune needs to catch up and maybe surpass it.

You have to remember that kakoune focuses only on the text editing part. Finding source of some command is beyond kakoune’s main task of editing text, but despite this it’s still very possible to do that all thanks to how well kakoune integrates with your system. Any tool you have on a system is directly integrable in your kakoune workflow, thank’s to the shell expansions.

There might be already existing tools for sourcing the definitions of latex commands, but for a quick and dirty solution, you could use any file searching tool. Here is example of how I could find the class source file using ag:

ag -Ql '\newcommand{\cftchapfont}' /usr/share/texlive/texmf-dist/tex/latex

Which results in: /usr/share/texlive/texmf-dist/tex/latex/tocloft/tocloft.sty

With this and %sh{} expansion you can make this process more automated by using kakoune hooks.

You have to remember that kakoune focuses only on the text editing part.

You’re right. I do tend to forget it. But I’ve heard that before too.
With that mindset we ought spend the next twenty years or so reminding each other. And this is taking into consideration that I’m not blissfully unaware of what can go awry either. I’ve seen it first hand and it’s not nice.

ag -Ql '\newcommand{\cftchapfont}' /usr/share/texlive/texmf-dist/tex/latex

Yes. I’m set through that.

`ack -r ‘\noexpand\lstset’ /usr/share/texmf-dist/tex/latex

Would thus return what I was looking for

/usr/share/texmf-dist/tex/latex/listings/lstmisc.sty:2007: {\noexpand\lstset{\lstlang@}}%

But what I mentioned earlier while trying to avoid a circulus in probando mentality here, would be the implementation of a plugin. that would pull all of of it in. Perhaps my faulty reasoning is the bias in not acknowledging that things can indeed go wrong.
But other editors have it. So now there are no other alternatives than to kludge all of it around?