Aitenate writes:
> It sound like the same issue I've experienced [1]. Try using an older
> version of haskell-mode and it should workaround the problem.
>
> [1] - https://github.com/haskell/haskell-mode/issues/1867
This seems to be fixed on haskell-mode side (the linked issue is resolved).
No ac
Finally got things back to normal by using locally on my machine a 2018
version of ob-haskell and the 17.5 (ca. 2024) version of haskell-mode.
Thanks for advice.
On Tue, Feb 25, 2025 at 2:09 PM Aitenate wrote:
> On 25/02/2025 16:28, Lawrence Bottorff wrote:
> > Could you show me what your init f
On 25/02/2025 16:28, Lawrence Bottorff wrote:
> Could you show me what your init for using this looks like. I either have
> use-package or a location on my computer for packages.
>
Before it was addressed upstream, I used the following to load from a
clone of the repo:
(use-package haskell-mode
Could you show me what your init for using this looks like. I either have
use-package or a location on my computer for packages.
On Tue, Feb 25, 2025, 02:42 Aitenate wrote:
> On 24/02/2025 14:45, Lawrence Bottorff wrote:
> > Where can I find an older haskell-mode? Not finding one...
>
> I was u
On 24/02/2025 14:45, Lawrence Bottorff wrote:
> Where can I find an older haskell-mode? Not finding one...
I was using load-path [1] to install it from a local copy. That said,
the change to haskell-mode has been reverted [2] and Melpa has updated
its package. I switched back to that and it seems
Where can I find an older haskell-mode? Not finding one...
On Mon, Feb 24, 2025 at 4:00 AM Aitenate wrote:
> It sound like the same issue I've experienced [1]. Try using an older
> version of haskell-mode and it should workaround the problem.
>
> [1] - https://github.com/haskell/haskell-mode/iss
It sound like the same issue I've experienced [1]. Try using an older
version of haskell-mode and it should workaround the problem.
[1] - https://github.com/haskell/haskell-mode/issues/1867
Regards,
Aitenate
On 19 January 2025 3:45:05 pm GMT+05:30, Ihor Radchenko
wrote:
>Pranshu writes:
>
>> I think being able to customise the run-haskell function and the haskell
>> buffer name should be enough, since they both use comit
>
>No, it is not.
>We use `haskell-mode', `run-haskell', `inferior-haskell-loa
On 19 January 2025 3:32:33 pm GMT+05:30, Ihor Radchenko
wrote:
>Pranshu writes:
>
>> Just uninstall haskell mode, restart emacs, execute babel haskell code block
>> without session and see what happens.
>
>Ok. I see what happens. haskell-mode is not required only in a single
>scenario - when :c
On 19 January 2025 2:57:20 pm GMT+05:30, Ihor Radchenko
wrote:
>Pranshu writes:
>
>>>AFAIU, it is not strictly required, unless you need session support.
>>>If you do not use sessions, things should work without haskell-mode.
>>
>> When I tried to run code normally, without session, it still req
On 19 January 2025 1:52:28 pm GMT+05:30, Ihor Radchenko
wrote:
>Pranshu Sharma via "General discussions about Org-mode."
> writes:
>
>> Can we also remove the requirment of haskell-mode to run code?
>
>AFAIU, it is not strictly required, unless you need session support.
>If you do not use session
Pranshu Sharma via "General discussions about Org-mode."
writes:
> Can we also remove the requirment of haskell-mode to run code?
AFAIU, it is not strictly required, unless you need session support.
If you do not use sessions, things should work without haskell-mode.
--
Ihor Radchenko // yanta
Bruno Barbier writes:
>> Only for sessions. For src blocks with :session none, we directly call
>> `org-babel-haskell-compiler'.
>
> Good point. I didn't check that execution path (probably because I
> assumed the OP was speaking only about GHCi).
>
> But, from what I see (function `org-babel-ex
Hi Ihor,
Ihor Radchenko writes:
> Bruno Barbier writes:
>
>>> If you've gotten this far you probably know more
>>> about the Haskell Babel situation than you ever wanted to, but maybe you
>>> can sniff out where this hardwire is happening.
>>
>> It's not hard coded (there is quite a lot of co
Bruno Barbier writes:
>> If you've gotten this far you probably know more
>> about the Haskell Babel situation than you ever wanted to, but maybe you
>> can sniff out where this hardwire is happening.
>
> It's not hard coded (there is quite a lot of code just to guess the
> right interpreter). o
Laurence von Bottorff writes:
> I'm on Debian 12 and I just started using Haskell's ghcup tools, leaving
> the stack tools behind, as advised these days. ghcup puts executables for
> Haskell such as ghc, ghci (REPL), cabal, etc. in its ~/.ghcup/bin
> directory. Next, to stop using the stack tools
Hi Laurence,
Laurence von Bottorff writes:
> I'm on Debian 12 and I just started using Haskell's ghcup tools, leaving
> the stack tools behind, as advised these days. ghcup puts executables for
> Haskell such as ghc, ghci (REPL), cabal, etc. in its ~/.ghcup/bin
> directory. Next, to stop using
Lawrence Bottorff writes:
> Enclosing code in :{ ... :} is fairly good -- again you can type this in at
> the REPL prompt and see how it works -- however, there are gotchas.
>
I don't think I understand what the problem is with :{ ... :}. Doing
this manually has worked pretty well for me.
>
> W
Hi Lawrence,
This isn't a method for official language support, but I've had success with
entirely unsupported REPLs and ob-screen. A .screenrc can launch the REPL, and
then Org ob-screen just sends each line to the buffer. It works OK for me.
-k.
On 2021-01-02 at 13:44 -08, Lawrence Bottorf
19 matches
Mail list logo
