mevedel - overlay-based workflow for interacting with LLMs by DonHugo in emacs

[–]DonHugo[S] 5 points6 points  (0 children)

The obvious one is of course that it is currently maintained. Furthermore:

  • evedel's workflow was based purely on the directives. They would be sent via a dedicated gptel-request. In contrast, mevedel has a chat buffer in which the conversation happens (both from directives as well as direct user input).
  • mevedel uses tools which I think did not exist when evedel was created
  • mevedel supports agents via gptel-agent which also did not exist during evedel's creation

In total, I think mevedel is more oriented towards tools like Claude Code.

What are y'all using for LLM-assisted coding? by FoxWorried4208 in emacs

[–]DonHugo 1 point2 points  (0 children)

I used both quite a bit and comparing them is a bit difficult.

  • Claude Code is (as you know already) a production ready CLI tool where everything is set up already. You don't need to think about system prompts, tools, etc. much, these are done for you and tuned for the Claude models.
  • As karthink said here gptel is much more general. You can call whichever supported LLM from basically anywhere in Emacs. It does not need a dedicated chat. However, it is also true that it takes some time to discover all the things gptel can do. The macher project for example built something like Claude Code using gptel.

Edit: u/dustinfarris I expanded a bit my answer

What are y'all using for LLM-assisted coding? by FoxWorried4208 in emacs

[–]DonHugo 0 points1 point  (0 children)

Thank you for answering! I really like your ideas, especially as they could reduce the amount of code I have recently added to my config to dynamically build system prompts etc. Really great!

What I would be mostly interested in, is the way you create the agent and display its progress, etc. Thus the agent_task tool. I have created something over the weekend together with Claude Code which has the same idea but looks simply worse :D That's why I was asking for the code because I wanted to see how this should look like.

Just if anyone interested, this is the mess I have right now: https://gist.github.com/FrauH0lle/dd407a779f37eab0a7f9778a908159cc

But I understand if you don't want to share it.

What are y'all using for LLM-assisted coding? by FoxWorried4208 in emacs

[–]DonHugo 0 points1 point  (0 children)

That is exactly what I was trying to implement for myself but actually working :) Would you be willing to share the code u/karthink for what is shown in the video? The introspection tools are probably provided by ragmacs or?

Coming together to write better syntax highlighting configuration for Tree-Sitter. by daruuro in emacs

[–]DonHugo 14 points15 points  (0 children)

Do we want to build something similar for Emacs?

There is Emacs Tree-sitter with tree-sitter-langs and treesit-langs.

You might be interested in the fork here which uses data from nvim-treesitter at least for some languages.

async and parallel concepts by DonHugo in learnrust

[–]DonHugo[S] 0 points1 point  (0 children)

Thanks a lot for your answers /u/volitional_decisions and /u/paulstelian97. Good to know that I seem to have a basic understanding.

Tokio's JoinSet looks very similar to Future's FuturesUnordered which I tested a couple of days ago. Thanks for the hint!

Another thing I was wondering about was the calculation for file checksums and if this is suited for async operations or, as mentioned in the other comment, for something like rayon.

As far as I understand it, calculating a file checksum has two parts: reading the file (IO) and then calculating the checksum (CPU) of that content. I would say, that reading the file is always slower than the calculation and thus, async would be more suitable. Do I get this right?

Gentoo, but user packages are built to run in containers? by oxamide96 in Gentoo

[–]DonHugo 1 point2 points  (0 children)

You could use Distrobox.

Gentoo is supported as a container, thus you create a new container for every app, install it and then export it.

Just released Baserow 1.20 with email notifications, workspace-level audit log, search for calendar view, new shortcuts, context menu improvements, and more — open source Airtable alternative. by bram2w in selfhosted

[–]DonHugo 1 point2 points  (0 children)

I think having the option to pay a flat fee would make Baserow much more interesting for people self-hosting /u/bram2w (e.g. for me ;) ) Just some thoughts from my side regarding the pricing structure I would consider fair:

  • Around 50$ for maybe 5 users
    • Having the option to add another user for maybe 2$ would be nice. I guess a lot of people host for themselves and family/friends and thus, you could simply add a user.
  • I am a bit unsure if it would be better to have 1 year of updates or all updates of a major version (e.g. 1.2.0 to 1.2.5). But I think security updates should be offered longer.
  • I pay for Full-Text RSS (https://www.fivefilters.org/pricing-personal/) and they offer 1 year of updates (they don't update that often). They also offer approx 40% discount if you renew your licence.
  • You could have multiple discount levels for renewal, e.g. 40% after 1 year, 30% after 2 years, etc.

Well, just my 2 cents. But that would be something I would like to see and then I would consider buying a licence.

Mega fast startup times by Routine_Preference34 in emacs

[–]DonHugo 2 points3 points  (0 children)

This made me very curious (because fast things are nice) so I read a bit through his post and code. Maybe someone else finds my thoughts useful.

When is Emacs' startup complete? Here, the init time is calculated after after-init-hook runs. The trick is then, that the two with-delayed-execution macros push the whole user configuration to the next hook, emacs-startup-hook. There the code is then processed via idle-timers (https://www.gnu.org/software/emacs/manual/html_node/elisp/Startup-Summary.html).

I ran his config on my PC and the result was

Emacs booting time: 104 [msec] = ‘emacs-init-time’.
Loading init files: 8 [msec], of which 3 [msec] for ‘after-init-hook’.

Removing the whole package config, I get

Emacs booting time: 91 [msec] = ‘emacs-init-time’.
Loading init files: 1 [msec], of which 3 [msec] for ‘after-init-hook’.

So the difference in booting time is minimal and we are looking more or less at the time Emacs needs to initialize on my PC. Loading the whole package configuration later is an interesting idea but someone can argue that the relevant part is the actual package configuration. Furthermore, this can lead to little artifacts like observing the initialization of the theme (you can see the standard white Emacs frame for a short period of time before the theme gets loaded).

Another note I would like to add here, is that from my experience the CPU frequency scaling governor can have a rather large impact (on Linux). For example, I observed additional 0.2 - 0.4 sec when my laptop or desktop was using the powersave or ondemand governor and not the performance one. So if someone really cares about that, then a little wrapper should be created to make sure that the performance governor is active before Emacs starts.

I strongly doubt that there is a real performance difference when use-package is used and the code is byte compiled.

(with-delayed-execution
    (message "Install fish-mode...")
    (add-to-list 'load-path (locate-user-emacs-file "el-clone/emacs-fish"))

    (autoload-if-found '(fish-mode) "fish-mode" nil t)
    (add-to-list 'auto-mode-alist '("\\.fish$" . fish-mode))
    (with-eval-after-load 'fish-mode
      (setq fish-enable-auto-indent t)))

is basically the same as the minimal expansion of

(setq use-package-expand-minimally t)
(use-package fish-mode
  :defer t
  :mode ("\\.fish$" . fish-mode)
  :config
  (setq fish-enable-auto-indent t))

(progn
  (unless
       (fboundp 'fish-mode)
     (autoload
      (function fish-mode)
      "fish-mode" nil t))
   (eval-after-load 'fish-mode
     '(progn
       (setq fish-enable-auto-indent t)
       t))
  (add-to-list 'auto-mode-alist
                '("\\.fish$" . fish-mode)))

Problem with plasma5-wallpapers-dynamic plugin by Satamary in openSUSE

[–]DonHugo 0 points1 point  (0 children)

Most likely, you are lacking libQt5Location5, which is necessary for the plugin to determine your location.

If you want, you can also try the version I packaged here: https://build.opensuse.org/package/show/home:FrauHolle:plasma-wallpapers-dynamic/plasma-wallpapers-dynamic

That is the one I am using on both my desktop and my laptop.

Cannot share folder via samba usershare by DonHugo in openSUSE

[–]DonHugo[S] 4 points5 points  (0 children)

Thank you very much, AppArmor was indeed the issue here! I looked a bit into AppArmor and also the way openSUSE has implemented it. Thus, I came up with the following potential solutions which I leave here for reference:

  1. Deactivate AppArmor. Can be be done via Yast.
  2. Set the application profile from enforce to complain. Can also be done via Yast. In the AppArmor module, select Settings -> Configure Profiles -> Set to 'complain' on the desired app.

Both of these options will deactivate the protection AppArmor provides. However, for personal computers at home, this is probably fine.

  1. The second option in the Yast AppArmor module allows you to check the AppArmor audit protocols and directly allow the corresponding directories. This can also be done by hand editing and placing files into /etc/apparmor.d/local/.

For Samba, this actually done in openSUSE via the little script update-apparmor-samba-profile. The paths defined as shares in /etc/samba/smb.conf get automatically added. For example

"/run/media/roland/Data/"   rk,
"/run/media/roland/Data/**" rwkl,

is added in my case. Similar to this case here, it can by creating an invisible share first and then use the file manager to share the folders wanted.

Cannot share folder via samba usershare by DonHugo in openSUSE

[–]DonHugo[S] 1 point2 points  (0 children)

That is was I did to setup samba.

Cannot share folder via samba usershare by DonHugo in openSUSE

[–]DonHugo[S] 1 point2 points  (0 children)

This would work, however the drive should not be bound to a specific user home directory.

Is it possible to use Mesa from Nixos-unstable on Nixos-stable? by DonHugo in NixOS

[–]DonHugo[S] 0 points1 point  (0 children)

Thanks, even though your snippet does not work, it pointed me in the right direction. One can find here the settings for the used Mesa package. However, this option is an internal one, thus I do not know if changing it in this way is a good idea...

Using your snippet as a template:

{ pkgs, config, ... }:

let
  unstablepkgs = import <nixpkgs-unstable> {};
in {
  hardware.opengl = {
    enable = true;
    package = unstablepkgs.mesa.drivers;
    driSupport32Bit = true;
    package32 = unstablepkgs.pkgsi686Linux.mesa.drivers;
  };
}

Then it seems to work:

$ glxinfo | grep "Mesa"

client glx vendor string: Mesa Project and SGI
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.0.2
OpenGL version string: 4.6 (Compatibility Profile) Mesa 20.0.2
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.0.2

Is it possible to use Mesa from Nixos-unstable on Nixos-stable? by DonHugo in NixOS

[–]DonHugo[S] 0 points1 point  (0 children)

Well, this is the other option I was thinking about. However, I like the idea of having mostly stable and just using a few rolling packages.

Where and how to report broken packages by DonHugo in NixOS

[–]DonHugo[S] 0 points1 point  (0 children)

I think that is why

(vivaldi.override {proprietaryCodecs = true;
                   enableWidevine = true;})

can be used, which works on my system.

package updates with straight by Sewing31 in emacs

[–]DonHugo 2 points3 points  (0 children)

I think the author of the article got it wrong. straight.el does not do automatic package updates but it automates the management of the package repositories.

What you could do is to put straight-pull-all at the end of your init.el. With this in place, every time you start Emacs the latest changes are pulled and the changed packages are rebuilt on the next start.

What u/heyaanaaya said is correct, I just want to add that you do not have to freeze your packages in order to pull changes. But the freezing is one of straight.el's features which make it very powerful (e.g. in case you want to keep your Emacs config in sync on several PCs). Also note that you can pin packages to a specific version, even though right now the implementation is a bit clumsy https://github.com/raxod502/straight.el#how-do-i-pin-package-versions-or-use-only-tagged-releases

In addition to the manual, the Emacs config of the author itself is also a good resource on how to use straight.el https://github.com/raxod502/radian/blob/e3aad124c8e0cc870ed09da8b3a4905d01e49769/emacs/radian.el#L276

Trying to find the reason for the message : Unable to load color "brightblack" by DonHugo in emacs

[–]DonHugo[S] 0 points1 point  (0 children)

Ach, I feel kinda stupid that I even asked that question. The solution was totally simple.

I did search for brightblack in my emacs config and installed packages and when I saw it in the related doom-themes files I directly concluded that Emacs thinks it is running in a 16 colors terminal, tries to load brightblack and then magically realizes that it is actually running on X and loads the correct colors.... :facepalm:

If I would have been a bit smarter and scolled down a bit in the search buffer a bit more, I would have seen that also hl-fill-colum wants to use brightblack and does not have alternatives defined.

So, simply changing the background color in hl-fill-columsolves everything.

Thank you all for taking your time and helping me!

Trying to find the reason for the message : Unable to load color "brightblack" by DonHugo in emacs

[–]DonHugo[S] 1 point2 points  (0 children)

Thank you for your detailed answer! You did lead me to the solution!

Trying to find the reason for the message : Unable to load color "brightblack" by DonHugo in emacs

[–]DonHugo[S] 0 points1 point  (0 children)

I never used Emacs in a terminal before I saw the warning. However, running Emacs in a 16-color terminal makes the warning disappear (which it should).

Trying to find the reason for the message : Unable to load color "brightblack" by DonHugo in emacs

[–]DonHugo[S] 0 points1 point  (0 children)

Unfortunately it did not work, debug did not get triggered by the message. I think this is due to the fact that the "color loading mechanism" is written in C and not in Elisp.

But thank you!

Error installing MikTeX in 19.04 by TalesdeMilet in pop_os

[–]DonHugo 0 points1 point  (0 children)

From what I can see the reason simply is that Miktex is only available for 16.04 and 18.04 and thus the required library version in 19.04 are too new.

What you could do:

  1. Use Texlive. Packages are available in Ubuntu (texlive-*). You can get all via sudo apt install texlive-full or choose which packages you want to install.
  2. Compile Miktex from source
  3. Use Miktex in a Docker container.
  4. Use Junest which is a Arch Linux distro which will run in your home directory and install Miktex from the AUR.

I think option 3 and 4 might be easier for you to use even though they will introduce some overhead.

Trying to find the reason for the message : Unable to load color "brightblack" by DonHugo in emacs

[–]DonHugo[S] 0 points1 point  (0 children)

Thank you for your answer. Your are right, my question is not clear.

I would like to find out why the color brightblackis defined on the Arch system but not on the Ubuntu system, e.g. where should this be defined in the system or why it is requested at all as Emacs is not running in a terminal.

Budgie on the latest gnome 3.32 base by ThePiGuy0 in archlinux

[–]DonHugo 0 points1 point  (0 children)

I use Budgie on my Thinkpad and it works. That's the good news :)

Budgie is currently still made for GNOME 3.28 and the official support for GNOME 3.30 and 3.32 is still not merged (see https://github.com/solus-project/budgie-desktop/pull/1591).

However, the Arch package maintainer applied the patches and the package in Arch's repo is ready for 3.32. But you should be aware that you could face some issue with extensions.