Re: [dev] [st] UTF-8 not working
Hi Robert, > Hi, according to the st Status, UTF-8 should be working. Much needed for > multilingual typing with ú, ü, ß, µ, ¿ etc. > However, I only get 00e9 if I type é; anything, I need to specify in > config.h? No, you just should only need to declare correctly your LC_CTYPE
Re: [dev] Some direction with my project
On Fri, Apr 15, 2022 at 09:37:07AM -0500, Chibby Bromanson wrote:
> On Fri, Apr 15, 2022 at 08:34:51AM +, Hadrien Lacour wrote:
> > On Thu, Apr 14, 2022 at 09:42:51PM -0500, Chibby Bromanson wrote:
> > > Greetings,
> > >
> > > I am very impressed with the suckless software movement and I am doing
> > > my best to try to create my own tool that follows the philosophy. I
> > > still have a lot to learn with the C language but so far I am proud of
> > > the results. I would be greatful if someone would review my tool and
> > > consider it for inclusion in the list of tools that ROCK! :D
> > >
> > > The tool is for maintaining a list of descriptive tags on an extended
> > > file attribute. It plugs in nicely with fzf and other command line
> > > tools.
> > >
> > > http://github.com/bromanbro/taggins
> > >
> > > Thank you for your consideration.
> > >
> > > Dorian
> > >
> >
> > Any reason for using space as internal delimitor when it could be anything
> > that's unlikely to be used in a tag (e.g. ASCII US)?
> >
> > Although I had the same idea a long time ago, I decided that using some
> > kind of database [1] solves both the problem of xattr portability and
> > performance (no need to crawl the filesystem to get your tags).
> >
> >
> > [1] Would have to be anything with a daemon to avoid reading/writing the
> > db constantly and using a tree structure for performance reasons.
> > Said daemon could also do stuff like Windows -> POSIX and/or character
> > encoding
> > path translation if more portability is wanted.
> >
> >
> > Regards,
> > Hadrien Lacour
> >
>
> Greetings,
>
> A space is used as a delimeter primarily because tags are by nature a
> single word. And this tagging system, unlike many others, is made
> specifically to feed other command line tools while maintaining
> transparency and legibility.
>
Then I'd suggest \n: you get the same ease of use in sh, but you can have
your space.
> There are different ways to solve the problem of tagging. All the
> technologies listed above; the need for a database, a daemon to monitor
> files etc. That is why Xattribute is used. So that you do not need
> those things. Maintaining files and file information is the
> responsibility of the filesystem.
>
I understand the choice, believe me, but performance was high in my concerns
and my usecase is acting on a great number of files ("list all files with this
tag combination" or "sort this file list by tag(s)") on HDDs.
> After 12 years of Xattributes most tools and filesystems now respect
> them. Your grandfathers zip program may not but tar will.
>
For example, NFS on Linux only got support for them with 5.9. And I don't think
NetBSD/OpenBSD support it (ZFS on NetBSD might, though).
Re: [dev] Some direction with my project
On Fri, Apr 15, 2022 at 02:20:25PM +0200, Wolf wrote: > On 2022-04-15 08:51:50 +, Hadrien Lacour wrote: > > > > Some implementation details: do you really need autohell when the only thing > > you use it for is to detect the presence of sys/xattr.h? That's only a few > > lines > > of sh calling cc to do the same. > > Personally, I use POSIX sh to "augment" make with the usual stuff like > > [un]install or what GNU make provides. > > Configure script provides lot more then detection though. I have yet to > see a hand written make providing support for --program-prefix or > --program-transform-name for example. For packaging software, these > additional features are useful from time to time. > > W. This was the decision that I struggled with the most to be completely honest. In the end though, this still ensures maximum portability and greatly increases your chances of some kind soul packaging it up for various platforms. D
Re: [dev] Some direction with my project
On Fri, Apr 15, 2022 at 08:34:51AM +, Hadrien Lacour wrote: > On Thu, Apr 14, 2022 at 09:42:51PM -0500, Chibby Bromanson wrote: > > Greetings, > > > > I am very impressed with the suckless software movement and I am doing > > my best to try to create my own tool that follows the philosophy. I > > still have a lot to learn with the C language but so far I am proud of > > the results. I would be greatful if someone would review my tool and > > consider it for inclusion in the list of tools that ROCK! :D > > > > The tool is for maintaining a list of descriptive tags on an extended > > file attribute. It plugs in nicely with fzf and other command line > > tools. > > > > http://github.com/bromanbro/taggins > > > > Thank you for your consideration. > > > > Dorian > > > > Any reason for using space as internal delimitor when it could be anything > that's unlikely to be used in a tag (e.g. ASCII US)? > > Although I had the same idea a long time ago, I decided that using some > kind of database [1] solves both the problem of xattr portability and > performance (no need to crawl the filesystem to get your tags). > > > [1] Would have to be anything with a daemon to avoid reading/writing the > db constantly and using a tree structure for performance reasons. > Said daemon could also do stuff like Windows -> POSIX and/or character > encoding > path translation if more portability is wanted. > > > Regards, > Hadrien Lacour > Greetings, A space is used as a delimeter primarily because tags are by nature a single word. And this tagging system, unlike many others, is made specifically to feed other command line tools while maintaining transparency and legibility. There are different ways to solve the problem of tagging. All the technologies listed above; the need for a database, a daemon to monitor files etc. That is why Xattribute is used. So that you do not need those things. Maintaining files and file information is the responsibility of the filesystem. After 12 years of Xattributes most tools and filesystems now respect them. Your grandfathers zip program may not but tar will. As far as searching and locating files, that is not the responsibility of this application. It does one thing only. Tag the files. Have a Great Day Dorian
[dev] [st] UTF-8 not working
Hi, according to the st Status, UTF-8 should be working. Much needed for multilingual typing with ú, ü, ß, µ, ¿ etc. However, I only get 00e9 if I type é; anything, I need to specify in config.h? Best, Robert
Re: [dev] Some direction with my project
Hi Dorian,
Took a quick glance into the source and a couple things which stood out,
that haven't been pointed out already:
#define BUFFER_SIZE MAX_TAGS * MAX_TAG_SIZE
Macros like this pretty much always should be parenthesized. It costs
nothing and can save you from getting into potential bugs. See
http://c-faq.com/cpp/safemacros.html for a more detailed explanation.
else if (strlen(temp) > 0) {
strcat(tempForWrite, temp);
I see lots of `strcat` calls going on, and maybe you *are* checking for
overflow somewhere out there, but it's not immediately obvious where.
I would suggest using `strlcat` instead. I would also suggest being very
careful with the str* family of functions, they often contain various
bear traps.
if (errno == ENOTSUP) {
fprintf(stderr, "Extended attributes are not available on your
filesystem.\n");
return -1;
} else if (errno == ENOENT) {
fprintf(stderr, "File does not exist.\n");
return -1;
}
Use strerror().
Also a lot of these messages are being used in multiple location. I'd
just use a macro for them.
#define ERRMSG_X "error x"
...
fprintf(stderr, "%s\n", ERRMSG_X);
...Or an array of them and index into it using enum.
Lastly, it's already been pointed out, but it's very cringe having to go
into a `src` dir just to find a single source file in there.
And related to that, given it's a single source file and none of the
functions are being called externally, you should declare (as well as
define) all the functions as `static`.
- NRK
Re: [dev] Some direction with my project
On 22/04/15 02:20, Wolf wrote:> > Configure script provides lot more then detection though. I have yet to > see a hand written make providing support for --program-prefix or > --program-transform-name for example. For packaging software, these > additional features are useful from time to time. They are trivial to program in a handwritten makefile. On topic, suckless programs usually make use of makefiles which are hand-customized, just like the program settings (config.h). For bonus points, use Plan9 mk. For my own programs, I prefer djb redo[2], which uses simple shell scripts and is better than GNU make[3]. About the Changelog/NEWS, they originate before the time of git and are superseded by git log/git shortlog. 1: https://9p.io/sys/doc/mk.html 2: https://github.com/apenwarr/redo 3: https://redo.readthedocs.io/en/latest/#whats-so-special-about-redo signature.asc Description: PGP signature
Re: [dev] [surf] Link hints (javascript) not working
On Fri Apr 15, 2022 at 5:12 AM CDT, Viktor Grigorov wrote:
> Hey,
>
> I have a slightly modified linkhints, that i use with both surf and
> boredserf. I'm attaching it so to forgo more questions, but the gist is:
> if(e.altKey && String.fromCharCode(e.keyCode) == '1') { hintMode(); }
> else if(e.altKey && String.fromCharCode(e.keyCode) == '2') {
> hintMode(true); }
>
> cheers
>
> Apr 15, 2022, 02:05 by robert.wink...@bioprocess.org:
>
> > Used to qutebrowser, vimb and SurfingKeys, I can't use a browser without
> > link hints anymore!
> >
> > I tried
Re: [dev] [surf] Link hints (javascript) not working
On Fri Apr 15, 2022 at 5:12 AM CDT, Viktor Grigorov wrote:
> Hey,
>
> I have a slightly modified linkhints, that i use with both surf and
> boredserf. I'm attaching it so to forgo more questions, but the gist is:
> if(e.altKey && String.fromCharCode(e.keyCode) == '1') { hintMode(); }
> else if(e.altKey && String.fromCharCode(e.keyCode) == '2') {
> hintMode(true); }
>
> cheers
>
> Apr 15, 2022, 02:05 by robert.wink...@bioprocess.org:
>
> > Used to qutebrowser, vimb and SurfingKeys, I can't use a browser without
> > link hints anymore!
> >
> > I tried
Re: [dev] Some direction with my project
On 2022-04-15 08:51:50 +, Hadrien Lacour wrote: > > Some implementation details: do you really need autohell when the only thing > you use it for is to detect the presence of sys/xattr.h? That's only a few > lines > of sh calling cc to do the same. > Personally, I use POSIX sh to "augment" make with the usual stuff like > [un]install or what GNU make provides. Configure script provides lot more then detection though. I have yet to see a hand written make providing support for --program-prefix or --program-transform-name for example. For packaging software, these additional features are useful from time to time. W. signature.asc Description: PGP signature
Re: [dev] Some direction with my project
On Thu, 14 Apr 2022 21:42:51 -0500
Chibby Bromanson wrote:
Dear Dorian,
> I am very impressed with the suckless software movement and I am doing
> my best to try to create my own tool that follows the philosophy. I
> still have a lot to learn with the C language but so far I am proud of
> the results. I would be greatful if someone would review my tool and
> consider it for inclusion in the list of tools that ROCK! :D
>
> The tool is for maintaining a list of descriptive tags on an extended
> file attribute. It plugs in nicely with fzf and other command line
> tools.
>
> http://github.com/bromanbro/taggins
>
> Thank you for your consideration.
thanks for reaching out! I am not a fan of xattrs, but they have their
place in the world and are a good vehicle for tagged file systems. This
space is not explored deeply enough, and some of my customers regularly
ask me if I know of a tagged fs solution that is easy to use for
non-technical people.
Regarding the code itself: As Hadrien already mentioned, autohell is
way overkill for what you're doing. In general, given xattrs are
non-portable, I would use a construct like
#ifdef __linux__
#include
#else
#error "system not supported"
#endif
and possibly create a "translation" layer of some sorts in a separate
compilation unit tag.c which handles all the unportable stuff.
tag.h would specify "general" functions (whose interfaces themselves are
POSIX compliant) like
int tag_add(...)
int tag_remove(...)
bool tag_is_set(..)
and all the ugly details would be "hidden" in tag.c, where you could
have a rough structure like
#ifdef __linux__
#include
#else
#error "system not supported"
#endif
int
tag_add(...)
{
...
#ifdef __linux__
...
#else
#error "system not supported"
#endif
...
}
If you, some day, decide to add extattr_ support (used in FreeBSD), you
simply add another case in the ifdef, but you won't need to change any
code outside of tag.c. As a crazy idea, you could also include a
fallback in the else-case where you create a dot-metafile in the
directory to store the attributes, but that's another matter.
Given the program's simplicity I wouldn't use separate src- and
man-folders, but that's a matter of taste.
I'd nuke AUTHORS (that's what LICENSE is for), COPYING (you already
have LICENSE), ChangeLog (put this stuff in README), Makefile.am,
Makefile.in, NEWS (no one cares), README.md (I'd just use README and
use markdown in there), compile, config.h.in, configure, configure.ac,
depcomp, install-sh, missing (for obvious reasons. Your tool can be
compiled with a 5-line-Makefile. If you don't know how, let me know and
I'll help you out).
With best regards
Laslo Hunhold
Re: [dev] Some direction with my project
On Thu, Apr 14, 2022 at 09:42:51PM -0500, Chibby Bromanson wrote: > Greetings, > > I am very impressed with the suckless software movement and I am doing > my best to try to create my own tool that follows the philosophy. I > still have a lot to learn with the C language but so far I am proud of > the results. I would be greatful if someone would review my tool and > consider it for inclusion in the list of tools that ROCK! :D > > The tool is for maintaining a list of descriptive tags on an extended > file attribute. It plugs in nicely with fzf and other command line > tools. > > http://github.com/bromanbro/taggins > > Thank you for your consideration. > > Dorian > Any reason for using space as internal delimitor when it could be anything that's unlikely to be used in a tag (e.g. ASCII US)? Although I had the same idea a long time ago, I decided that using some kind of database [1] solves both the problem of xattr portability and performance (no need to crawl the filesystem to get your tags). [1] Would have to be anything with a daemon to avoid reading/writing the db constantly and using a tree structure for performance reasons. Said daemon could also do stuff like Windows -> POSIX and/or character encoding path translation if more portability is wanted. Regards, Hadrien Lacour
Re: [dev] Some direction with my project
On Thu, Apr 14, 2022 at 09:42:51PM -0500, Chibby Bromanson wrote: > Greetings, > > I am very impressed with the suckless software movement and I am doing > my best to try to create my own tool that follows the philosophy. I > still have a lot to learn with the C language but so far I am proud of > the results. I would be greatful if someone would review my tool and > consider it for inclusion in the list of tools that ROCK! :D > > The tool is for maintaining a list of descriptive tags on an extended > file attribute. It plugs in nicely with fzf and other command line > tools. > > http://github.com/bromanbro/taggins > > Thank you for your consideration. > > Dorian > Some implementation details: do you really need autohell when the only thing you use it for is to detect the presence of sys/xattr.h? That's only a few lines of sh calling cc to do the same. Personally, I use POSIX sh to "augment" make with the usual stuff like [un]install or what GNU make provides. About my previous message, SQlite may work, I don't really know anything about the support of tree structures in it. It is rarely wise to write your own database, after all.
