Stuttgart, Germany
https://maximilian-schillinger.de
From Max Schillinger to ~sircmpwn/hare-users
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.
From Max Schillinger to ~sircmpwn/hare-users
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 '{') >
From Max Schillinger to ~sircmpwn/hare-dev
@Lorenz: Thanks for your comments. I have fixed this in v2: <https://lists.sr.ht/~sircmpwn/hare-dev/patches/47009>
From Max Schillinger to ~sircmpwn/hare-dev
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]
From Max Schillinger to ~sircmpwn/hare-dev
> 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.
From Max Schillinger to ~sircmpwn/hare-dev
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.
From Max Schillinger to ~sircmpwn/hare-users
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!?
From Max Schillinger to ~sircmpwn/hare-dev
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]
From Max Schillinger to ~sircmpwn/rc-devel
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]
From Max Schillinger to ~rjarry/aerc-discuss
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.