On Wed Nov 29, 2023 at 2:31 AM CET, Ember Sawady wrote:
> > So far I didn't care about runtime errors (because I only want to 
> > compile inside vim but not run/test the software inside vim). My 
> > pain point is this use case: When I compile rc in vim (using 
> > `:make`) and there is an error in its dependency madeline (caused by 
> > myself), I want to jump to the error line. But the output looks like 
> > this:
>
> the reason i brought runtime errors up is because your patch also
> affects them, and i'd like to see a solution which keeps them as they
> currently are

OK, now I get it.

On Mon Nov 27, 2023 at 11:08 PM CET, Ember Sawady wrote:
> there are two contexts in which harec has to print out paths: when
> generating abort messages, and when generating compile-time error
> messages
>
> for the former, i'd like to keep the behavior we have today (though not
> necessarily the implementation), where the path is relative to -M:
>
> $ cat main.ha
> use fmt;
> export fn main() void = fmt::printf("{")!: void;
> $ hare run main.ha
> Abort: fmt/iter.ha:218:14: Invalid format string (unterminated '{')
>

@Lorenz: Thanks for your comments. I have fixed this in v2: 
<https://lists.sr.ht/~sircmpwn/hare-dev/patches/47009>

Signed-off-by: Max Schillinger <max@mxsr.de>
---
* Prevent out-of-bounds access.
* Rename 'dir' parameter to 'filepath'.

 include/util.h |  2 ++
 src/main.c     | 11 ++---------
 src/util.c     | 47 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 51 insertions(+), 9 deletions(-)

diff --git a/include/util.h b/include/util.h
index 42127c4..b29cc3e 100644
--- a/include/util.h
+++ b/include/util.h
[message trimmed]

> note that unique_part might be '\0' here, again, just when this function
> is called in a way that it wont be? (yet)

Same as for your other comment: It shouldn't happen because the file 
name should have a length >= 1 but I'll fix it to be on the safe side.

True. Actually, the input variable is a file, not a directory. I'll 
rename it. This means, this case should indeed never happen. But I'll 
fix it anyway.

On Wed Nov 15, 2023 at 4:37 AM CET, Ember Sawady wrote:
> it started doing this as part of the fix for
> https://todo.sr.ht/~sircmpwn/hare/877. that being said, i think that the
> thing that'd make the most sense here is to strip the -M parameter in
> aborts and $PWD in compiler error messages. feel free to send a patch
> for this if you'd like

I have created a patch:

https://lists.sr.ht/~sircmpwn/hare-dev/patches/47004

I'm not sure if I understood you correctly. In case of an abort, isn't 
it too late to strip the -M parameter!?

Signed-off-by: Max Schillinger <max@mxsr.de>
---
Currently, error locations are printed relative to dependencies' root
directories. This can't be processed easily automatically (p.e. by vim's
:make). Also see
<https://lists.sr.ht/~sircmpwn/hare-users/%3CCWQ9IWWELP77.2TIL8M24VF5F5%40mxsr.de%3E>.

 include/util.h |  2 ++
 src/main.c     | 11 ++---------
 src/util.c     | 44 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 48 insertions(+), 9 deletions(-)

diff --git a/include/util.h b/include/util.h
index 42127c4..b29cc3e 100644
[message trimmed]

Accept expressions like these:

$var( 3 )
$var(2 - 4)
$var(2 -)
$var( $i )
$var($start - $end)
$var(- $end)

Add more tests.
---
Don't insert carets in parse_value for access lists. This allows a
simpler/shorter parse_access_range function.
[message trimmed]

On Sun Nov 19, 2023 at 11:35 AM CET, Moritz Poldrack wrote:
> > My guess: When I answer by clicking on the "Reply to thread" button 
> > on the patch page[2], the "In-Reply-To" header field is set (I can 
> > see this when I hover over the button) but it's not set when I 
> > answer directly in aerc.
> If you take a look at the raw message[0] you'll notice that the
> In-Reply-To header is properly set. What the exact reason for the weird
> display is, I am pulling a bit of a blank.

Thanks for your answer! I have checked the header of the sent e-mail: 
You are right, it *does* include the "In-Reply-To header" with exactly 
the same value that the reply button on sourcehut sets.

Thus, this isn't an issue with aerc but only with sourcehut.