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
article.sty fonttext.ltx makeidx.sty preload.cfg t2benc.dfu
ascii.def graphpap.sty minimal.cls preload.ltx t2cenc.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.
To read more about the extensions
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?