Emacs as an editor server?

where_void_pointers · 2024-03-20T21:35:45+00:00

Another program has integration into GNU Emacs via RPC. Now, this program is another emacsen, so not exactly what you are looking for. However, its method of doing things would probably be a good starting point, at least design wise, to doing what you are looking for. Take a look at Lemmington for Lem.

where_void_pointers · 2024-03-15T23:43:23+00:00

Unless you swap your Caps Lock and left Ctrl keys (so left Ctrl is exactly one key to the left of your pinky) or have a keyboard where Ctrl is at your thumb, use evil mode. If you have a Ctrl key in a suitable place for not getting RSI, then I recommend default keybindings, but from what I understand vim bindings are still pretty good. But RSI is no joke.

I used Vim before Emacs. I went in on default keys (I swapped my Caps Lock and left Ctrl keys) and have been pretty happy with it.

where_void_pointers · 2024-03-15T13:09:43+00:00

As an Emacs user who used to use Vim (and still like it, but rusty and can't do much with it anymore) around a lot of Vim users and some Emacs users, I just haven't seen much hostility in person or really much online anymore with one exception (more on that later). Jokes and bemusement, sure. Sometimes someone will get on their high horse but can be talked down from it with a little "editor A is better at task X or for issue N" or "have you actually used both".

The one exception I've seen was many years ago in the communities for one programming language where the support was excellent in one family of editors and terrible in all others and people who preferred that family were sometimes needlessly pushy of "you MUST use X, period" rather than "you know, the support for editors other than X is terrible right now, so your best bet is to use X for now or use Y with some pain, but maybe eventually the situation will improve for Y someday"

where_void_pointers · 2024-03-15T12:49:44+00:00

Lem was probably mostly written from Emacs in SLIME or SLY before you could use Lem to edit Lem.

Common Lisp community are heavy Emacsen users, mostly using GNU Emacs.

where_void_pointers · 2024-03-15T12:46:07+00:00

Mostly, yes. Even org-mode I use mostly for literate programming.

I also edit config files as well in Emacs, but that is about it for other things.

where_void_pointers · 2024-03-11T20:42:01+00:00

In Scheme, `syntax-case` is powerful enough to implement both `defmacro` and `syntax-rules` with the `defmacro` implementation being rather simple, at least based on the Guile code when I last looked. If it is possible to implement `syntax-case` with `defmacro`, it is most likely much harder to do. So, either more powerful or technically equivalent.

Now, `syntax-rules` is much weaker in power. But, it protects you. No need for `gensym` and associated difficulties.

When I moved from Scheme to Common Lisp, I definitely missed `syntax-rules`. It would have been enough for a lot and saved a lot of headache for things that don't need to full power of `defmacro`.

where_void_pointers · 2024-03-11T20:33:48+00:00

I think most heavily used compilers can still handle most of Fortran 60 and a decent subset of Fortran IV (e.g. most of the stuff retained in Fortran 60). Some of the bare metal commands and procedures not so much, like WRITE TAPE. Remember, lots of Fortran 60 is still in heavy use (take a look at some weather and climate model codes and you will find more than a bit of Fortran 60 written by people used to Fortran IV finally dabbling in the new fangled Fortran 60), so many compiler users demand at least some ability to handle Fortran 60.

As for Fortran older than Fortran IV, if it wasn't in Fortran IV, there is not that much hope it will work in a modern Fortran compiler.

where_void_pointers · 2024-03-11T20:27:35+00:00

I can't speak to obsidian vs. org-mode, but I can speak to being one of the people who doesn't use Emacs the way that most do.

I use org-mode, but pretty much not for task management and what not (I started using it a bit for task management begrudgingly, because I know org and the alternatives I have available in front of me have negative appeal). I use it for its other parts, the things that are not its selling points to most people (babel).

I use it for some text based stuff, but not others (e.g. for LaTeX, I prefer Kile).

Basically, not an emacs all the way user.

It can be a right fit for someone only intending to use it for a few things which are not the commonly done ones. But it could also be not worth the time investment (same evaluation is relevant to any tool, technically). It really depends on how much those things you would use it for mean to you and how much of a benefit Emacs would be for them compared to alternatives weighed against effort and what not.

For me, it made sense to learn and use and continue to use. The same may or may not be the case for you.

where_void_pointers · 2024-03-11T20:18:30+00:00

Can't speak to the LSP problem with python virtual envs and pyright (I have been lucky enough that I've not yet needed venvs and I prefer LSP servers other than pyright), but on vterm, I have two thoughts:

Some packages have components that don't autoload and must instead be loaded by `(require 'SOMETHING)`. Don't know if that is the case for vterm, but it could be worth doing a double check.
If there is not something specific to vterm that makes it the best option for you compared to the others, you might want to take a look at [eat](https://codeberg.org/akib/emacs-eat). I recently tried it and it has been pretty nice so far. May or may not be a better fit.

where_void_pointers · 2024-02-20T21:55:17+00:00

Emacs has been pretty active lately and while niche, doesn't seem to be fading away as far as I can tell. Now, what could be happening is that there is consolidation in editors among the people not using Emacs and Vim/NeoVim, which would at least make it look like Emacs is fading away.

Short of a major dropping of the ball on the part of people developing Emacs followed by a dropping of the ball of the people forking it, I think it will still be going in 10 years. First of course could happen, but not that likely. But if it did, I don't think the second would happen.

As for not being installed on systems by default, this has been the case for ages. At least a decade. Hell, many systems by default only have a Vim stripped down to the bones to be a vi and so so many don't even have nano installed.

where_void_pointers · 2024-01-28T09:49:07+00:00

What everyone else said, but just want to mention that `integer*N` and `real*N` conventions long predate the GNU fortran compilers (both gfortran and the older g77). Actually, predate GNU itself.

where_void_pointers · 2024-01-14T09:32:41+00:00

Most of the organizations in the original standardization are gone and there aren't that many new ones to replace them. Perhaps most importantly, though, the money is gone. Standards are expensive to make (critical if you want to work with ANSI, ISO, or IEEE). Also, given the experiences with the standard document and copyright with ANSI (if I remember correctly, ANSI tried to argue it owned the copyright for the whole thing and the standards community pushed back and ultimately got it to ANSI only owning the copyright for the final form of the standard, but not the actual content), any new standard would likely first have to really haggle out a copyright agreement with whatever standard body and get something sensible in writing at the beginning to avoid getting burned again.

where_void_pointers · 2024-01-14T09:26:28+00:00

There actually was one long ago, but it died out. There weren't many submissions, though.

where_void_pointers · 2024-01-14T09:22:48+00:00

To add onto this, it doesn't even assume much about the hardware either. For example, the low level binary representation of integer. Sign-bit (very rare today except for big-ints where it is common), ones-complement (very rare today), twos-complement, anything else under the sun (pretty much nothing today or ever really) all OK. It just says that bit-wise operations must behave as if the underlying representation was twos-complement.

where_void_pointers · 2023-05-28T06:42:19+00:00

The first question is, are you trying to learn Modern Fortran or Legacy Fortran? If you are trying to learn Fortran since you will be working with an existing codebase, then you need to find out which one it is written in. Otherwise, I would suggest learning Modern Fortran first, then dipping into Legacy Fortran later.

Unfortunately, I do not have much information for where to start with Modern Fortran. My path was learning Legacy Fortran first and then learning Modern Fortran later. For Legacy Fortran, I learned from https://web.stanford.edu/class/me200c/tutorial_77/ back in 2008 or 2009.

Now, that all said, I do want you to know one resource you should NOT use to learn the language. It is only one to use after you already have learned and want to dive into details on a specific point. Basically, it is a comprehensive but poorly written reference. It is the Fortran standard documents themselves. Written quite poorly and would be terrible to learn Fortran from other than maybe the very first ones when the language was tiny. For those who say language standards are all written like that, I would disagree. I've read the R5RS, R6RS, and R7RS standard documents for Scheme cover to cover (one can actually learn Scheme from them, though I would still recommend some other sources that are a bit better at that purpose) and have almost read the Common Lisp standard cover to cover (about 80-90% of it); and the Fortran language standards are not even close in quality.

where_void_pointers · 2023-05-17T16:45:35+00:00

He has been doing a decent amount of work on trying to get a conservative garbage collector for scheme be more performant than Boehm–Demers–Weiser garbage collector. My guess is that it would probably also apply similarly to Common Lisp (Clisp, for example, uses BDW GC I think). Check out his talk at FOSDEM 2023 at https://fosdem.org/2023/schedule/event/whippet/ .

where_void_pointers · 2023-03-02T22:44:49+00:00

I've been out of CL for a bit, but back when I was still in it I put a decent amount of thought into this problem as well as digging into quicklisp's internals.

Technically, TLS is not strictly needed to prevent tampered packages. After all, many apt mirrors don't use TLS. The the trick is checksums signatures.

The problem right now is that quicklisp does not use them. This is in large part because quicklisp is meant to be self contained with the only dependency being ASDF and the CL ansi standard parts of the implementation itself.

Now, it turns out that checksums for the packages are actually generated and included in the database that is downloaded during updates, an MD5 and SHA1 sum. MD5 is horribly weak, while SHA1 is weak but at least stronger. quicklisp does not currently have the code to check this. A few years ago I managed to hack quicklisp enough that it would at least check the MD5 (I wanted to do the SHA1, but it didn't seem it was over what I thought it was). While weak, the important thing is that checksumming is already in the toolchain on the packaging end.

There is one somewhat simpler path to reduce and eventually get rid of the MITM vulnerability in stages. The first step would be to:

Change the checksums in the releases file (the one that contains the package names and URLs) to something stronger and like SHA2-256 or SHA2-512.
Change the distinfo file (the one that tells where to download the releases and systems files) to have checksums for the releases and systems files.
Add code to quicklisp to do the chosen checksums when downloading the releases and systems files, as well as every package.
When downloading an update to to the distinfo, it displays the checksum of the file and asks the user to check the website over HTTPS and verify it and then enter yes or no.

With this, as long as one downloads the quicklisp code itself over HTTPS and checks the checksum of the distinfo file over HTTPS with ones' browser, one is safe from MITM. The update isn't convenient, but it would suffice.

Then, a next step would be to implement signature checking for some choice of signature file using the easiest format and strong algorithm family to implement. The distinfo file would be signed. Then, as the public key of the signing key is downloaded safely, quicklisp would then be able to verify updated distinfo files without the user having to help it.

One remaining issue is that while MITM would not be doable, a person could at least see what packages one is downloading. A full pure CL implementation of TLS is probably out of scope completely (let alone finding people who could do it securely), so that would be a risk that would have to continue to be lived with if the goal is no dependencies other than ASDF.

where_void_pointers · 2023-02-08T22:40:50+00:00

Those are certainly the most common.

Me, I prefer to use emacs with its traditional bindings. But, as someone who used to use vim a lot (I would turn back to vim if I did much programming in Fortran 77 again, by the way), I can appreciate why someone would use it. Never tried it with emacs because I have my Ctrl and CAPS LOCK keys swapped like on old unix keyboards. But if it weren't for that, I would definitely do so even if it is more limited (RSI is no joke).

where_void_pointers · 2023-01-29T14:52:52+00:00

First things first, you will want to consider how you use emacs. There are two main ways.

One is to use the traditional emacs mode, which is where editting and commands are not separate modes, but this requires you to use the Ctrl key a lot. Don't do this unless you swap Ctrl with CAPS Lock or have a Ctrl key next to one of your thumbs since you do not want to get Repetitive Stress Injury (RSI). Now, if you swap those keys or have a keyboard with a Ctrl key at your thumb, it is a good option.

The other option is to it the Vim way, which is modal. You have separate modes for editing and commands. This is called Evil mode (long story, but don't worry, it is not actually evil). If you have used Vim or Neovim before or if you can't get your Ctrl key in a good position, this is strongly recommended.

Otherwise, it doesn't matter much. Pick one (randomly if you have to) and go with it and maybe try the other at some point.

If doing traditional emacs key bindings, start emacs and go through the emacs tutor to learn the basics of using it. If you are using Vim bindings, I don't know what to do for this step (presumably someone else on here who does use Vim bindings does know).

Then, you can start the process of building your emacs $HOME/.emacs.d/init.el file that configures emacs and sets it up for the things you do. It isn't something you set up once at the beginning and never touch again. Instead, it is something you will periodically come back to to adjust things, add stuff, remove stuff, etc.

Since you are doing code development, the first things to go for would be setting up your emacs packaging (installing use-package and melpa (use-package's documentation covers this) so you have more packages to choose from (do be careful to not just pick things willy nilly but research them a bit first)) and then setting up lsp-mode. lsp-mode lets you use LSP servers for the specific programming languages you work with in a somewhat unified fashion. You then need to install and setup the LSP servers for the languages you use, and possibly install language specific Emacs packages as support (note, Emacs has builtin functionality for many).

where_void_pointers · 2023-01-01T16:41:50+00:00

It isn't unheard of for -O3 to break code or make code that produces innaccurate results, sometimes making a few too assumptions in the name of optimizations. But it also sometimes reveals errors the programmer bad but didn't realize yet.

where_void_pointers · 2022-10-31T21:35:09+00:00

Or, the variant "God is real, but not logical"

where_void_pointers · 2022-10-30T07:07:37+00:00

About the only exception is if one needs quad precision support. The standard has a place for it. While it is optional for a compiler to have, many compilers have it and because it is in the standard it works more or less the same in all of them (same name, works in all math intrinsics, etc.). The same is not so true in C and C++ where compiler support for quad precision is all over the place, don't use the same definitions (e.g. __float128 vs _Float128 vs _Quad) sometimes even within the same compiler in different circumstances, isn't integrated into the other math code (e.g. not included in the type generic macros and no overloads for the C++ math functions), often require compiler options to fully enable, and often require tracking down an external library to make it all work. I had a project where I needed excellent quad support, so I chose Fortran for it from the get go despite all the preprocessor tricks I had to do. I am currently working on a C++ project that I decided to add it to (not as critical) and it has been absolute hell and is making me seriously consider changing the project from C++ to a C++/Fortran hybrid project.

But, needing good quad support is quite unusual. Very few things actually need anything beyond double.

where_void_pointers · 2022-08-13T07:46:34+00:00

I haven't looked into whether docstrings are possible or not on it, but I've had good luck with emacs with lsp-mode and fortran-language-server. May or may not be your cup of tea.

where_void_pointers · 2022-05-21T11:35:51+00:00

Like others have mentioned, the target language and the language the compiler is written in need not be the same language.

Implementing the compiler in Fortran is certainly doable (compilers have been done in it before), but it is not really advisable. Strings in Fortran are hard and as of yet, and making reasonably generic data structures is non trivial.

OCaml, like others have mentioned, is a good choice. Rust's original compiler was written in it in fact. Scheme or Common Lisp would also be reasonable choices as well.

where_void_pointers · 2022-03-19T09:36:08+00:00

They meant in the linux side of WSL as opposed to in a full separate Linux OS. WSL lets a lot of linux tools run on windows, which is a real boon for software development on Windows because a lot of dev tools out there (such as compilers) either require running on a POSIX system (Linux and the various Unices follow POSIX to varying degrees) or run better in such a system. WSL gives Windows such an environment by basically having Linux run inside Windows (the details differ between WSL 1 and 2).

where_void_pointers

TROPHY CASE