Comment by ~scoopta on ~scoopta/glpaper
Fixed by f89e60b7941f
REPORTED RESOLVED FIXED
Comment by ~scoopta on ~scoopta/wofi
I can probably fix the prompt issue trivially(I hope), I'm not so sure about
--lines 0I'll look into both if I have time. I might start trying to work on addressing the open issues here, no promises but it could be good for me to work on wofi again.
Comment by ~scoopta on ~scoopta/wofi
I'm not super familiar with how nix works. Programs launched by wofi should inherit its environment and in most distros that is the desired behavior. While this could be closed due to the work around and the fact that I think it's nix specific I am a tad curious as to the cause if you're more familiar with how nix handles environments.
Comment by ~scoopta on ~scoopta/wofi
Added by 8818a1738582
REPORTED RESOLVED IMPLEMENTED
Comment by ~scoopta on ~scoopta/wofi
To be honest, I really should release a wofi v1.3 because there's a lot not in any current release. For example this was addressed quite a while ago and is present if you're running the latest tip but if you're running the latest versioned release v1.2.4 this still hasn't been addressed. I'm closing this as invalid as it's not present in tip but I'll work on getting a v1.3 out. It's been a long time since the last release and there's a lot missing from it. Specifically the issue you're running into is the removal of field codes and and it was added here by 75f1dba264d9. It wasn't even added as an option, that's just the behavior as it was considered pretty much universally undesirable to have them printed.
REPORTED RESOLVED INVALID
Comment by ~scoopta on ~scoopta/wlrobs
Alright, thanks for confirming
REPORTED RESOLVED NOT_OUR_BUG
Comment by ~scoopta on ~scoopta/wofi
I apologize for the late reply, I haven't had a lot of time for wofi. I'm hoping to get around to the issues that have piled up though. This is most likely caused by a bad line in your cache file. I'm working on a fix so that wofi will gracefully handle this condition but this can probably easily be fixed by either clearing your cache file in
$XDG_CACHE_HOME/wofi-drunor removing the bad line
Comment by ~scoopta on ~scoopta/wofi
I apologize for the late reply, I haven't had a lot of time for wofi. I'm hoping to get around to the issues that have piled up though. I'm unable to reproduce this with either tip or 1.2.4 no matter how many times I run it.
Comment by ~scoopta on ~scoopta/wofi
Hmmmmm, I tried creating an executable in my home folder(not in my path) and then linking it to /usr/local/bin but it shows up no problem. Wofi doesn't actually care about symlinks outside of directory links. That is it checks to see if the directories in
$PATHare links and if they are resolves them and uses their actual path, reason being to avoid doubling the entries on distros that link /bin to /usr/bin etc, however whether an executable is a link shouldn't matter. Wofi usesstat()to determine type of file andstat()resolves links so at no point should wofi even be aware of the link. I guess what I'm getting at is are you sure that's what's happening for you or is it just a coincidence? Actually...I bet I know what's happening. Is this related to #98 and the myriad of other optimization bugs reported? Easy way to test is does it happen with executables in your cache, if not do the executables show up if given enough time...if so...I really need to figure out a way to get that list populating faster or replace the FlowBox with something custom perhaps because there's so many people experiencing problems with how quickly wofi populates the results.
Comment by ~scoopta on ~scoopta/wofi
...ok so this is a very weird bug...apparently it depends on how fast you type in the search box, or something to that affect. I haven't fully traced it down but I have an idea of what could cause this