~strahinja

Belgrade, Serbia

https://strahinja.org

Programmer with a wide programming skill set. Started with Basic in the 1990s, current focus: C, suckless programs.

~strahinja/public-inbox

Last active 1 year, 5 months ago
View more

Recent activity

Feed log messages parsing Markdown 13 days ago

From Страхиња Радић to ~sircmpwn/sr.ht-discuss

It seems that log messages in project feed (ex. [1], message for commit 
9de2744) are parsed and converted to HTML, unlike the log messages in the 
display of the log of a git repository.

Is this intended? I'd prefer if the log messages weren't parsed.

[1]: https://sr.ht/~strahinja/mkpk/feed
[2]: https://git.sr.ht/~strahinja/mkpk/log?from=9de274440e26b19b292a9a3a96b3fe5c7d9b7ecc#log-9de274440e26b19b292a9a3a96b3fe5c7d9b7ecc

Re: Is allowing uppercase/capital letters in nicknames/logins/usernames feasible? 3 months ago

From Страхиња Радић to ~sircmpwn/sr.ht-discuss

On 22/05/07 11:53, Norman Gray wrote:
> Thus while it is certainly conventional for unix usernames to match
> [a-z][a-z0-9_]+, and while I think it is probably asking for a greater or
> lesser amount of trouble to have a username which doesn't match this, there
> doesn't seem to be any real prohibition in 'unix' (strictly in scare-quotes)
> against such usernames.
> 
> I'm not advocating any particular conclusion to the original query, but simply
> adding references.  And getting the satisfaction of being able to reuse old
> notes, of course.

- The implementation might rely on useradd and related programs to deal with
  usernames.

Re: Is allowing uppercase/capital letters in nicknames/logins/usernames feasible? 3 months ago

From Страхиња Радић to ~sircmpwn/sr.ht-discuss

On 22/05/07 09:01, Humm wrote:
> Quoth Drew DeVault:
> > No, this will not be changed. SourceHut usernames are limited to the set
> > of valid Unix usernames.
> 
> Unix doesn’t disallow majuscules in usernames.  Not like there’s a reason
> for srht to allow them, though.

man useradd, then type "/^CAVEATS" (without quotes) and press Enter.

>        Usernames must start with a lower case letter or an underscore,
>       followed by lower case letters, digits, underscores, or dashes.
>       They can end with a dollar sign. In regular expression terms:
>       [a-z_][a-z0-9_-]*[$]?

Re: Missing www subdomain (www.sr.ht) 3 months ago

From Страхиња Радић to ~sircmpwn/sr.ht-discuss

On 22/04/23 11:17, Max Barraclough wrote:
> Thanks Strahinya but the no-www folks are explicitly *not* opposed to
> introducing a 'www.' subdomain that redirects to the top domain. They
> favour 'Class B' (redirection) over 'Class C' (no 'www.' subdomain at
> all).

Exactly. Their ideal compliance level is what you proposed.

Re: Missing www subdomain (www.sr.ht) 3 months ago

From Страхиња Радић to ~sircmpwn/sr.ht-discuss

On 22/04/22 10:14, Max Barraclough wrote:
> The www.sr.ht subdomain does not exist. I suggest it be created and
> forward to sr.ht.

http://no-www.org/faq.php

Re: Markdown, readmes and project pages. 4 months ago

From Страхиња Радић to ~sircmpwn/sr.ht-discuss

On 22/04/16 05:48, DJ Chase wrote:
> in the wild) is far from being standardized. The most common convention
> is still just a convention — people can and do break them.

While the parts of GNU coding style dealing with styling C code are limited in 
the actual adoption scope, the convention about the file names is more widely 
used, especially when it comes to the naming of README.

> Plus, what about other languages? It's true that software is developed
> in English, but personal projects needn't always be.

See GNU gettext documentation. According to it, software should be developed 
with English  messages, with the option to be localized. Proponents of other 
programming  philosophies, such as suckless software, go even further and

Re: Markdown, readmes and project pages. 4 months ago

From Страхиња Радић to ~sircmpwn/sr.ht-discuss

On 22/04/16 01:39, DJ Chase wrote:
> So standardize it.
> I fully support requiring users to comply with standards, but this
> expectation is unreasonable and unfair when there is no such standard —
> especially when the fix is as simple as toupper().

While mostly being an unwritten tradition, parts of the convention for file 
names in a project directory and their contents, like NEWS, COPYING, AUTHORS, 
etc is documented in the GNU coding standard and manuals for make, autotools, 
etc. README (traditionally being just a plain text file) is part of that 
convention.

Re: sr.ht web UI NetSurf support 5 months ago

From Страхиња Радић to ~sircmpwn/sr.ht-discuss

On 22/03/08 10:05, Sebastian LaVine wrote:
> I mean, if you want to get reeaally unbloated, I find sr.ht looks nice
> enough in TUI browsers like lynx or w3m.

	That's true (I'm mostly using elinks instead of lynx/w3m as a
TUI browser, though), but I find NetSurf the least bloated graphical browser
(if we don't count `links -g`) having an independent engine (not Chromium,
Gecko nor Webkit), so I'm using it as a graphical browser in X.Org. It's
lean and lightning fast.

Re: sr.ht web UI NetSurf support 5 months ago

From Страхиња Радић to ~sircmpwn/sr.ht-discuss

On 22/03/08 02:50, Drew DeVault wrote:
> I would be pleased to see patches improving sourcehut for netsurf, or

	I would be pleased to see them as well, especially since I'm paying a
subscription for the service.

> netsurf for sourcehut,

	This would not be very realistic to expect, I'm afraid.

> but neither is among our internal priorities at
> the moment.

	I see. Hopefully, usability in non-bloated browsers will be moved

sr.ht web UI NetSurf support 5 months ago

From Страхиња Радић to ~sircmpwn/sr.ht-discuss

Hi, currently sr.ht pages look suboptimal in NetSurf.

1. The navigation menu is displayed vertically. Example: on meta.sr.ht, the
   menu containing the items "profile", "security", "privacy"... and also
   the main menu: "git", "hg", "builds", "todo"...

2. The repository tree view has alternating background colors for rows of the
   table displaying files in the repository. In NetSurf, the darker of the two
   alternating colors has very poor contrast with the color of the text, making
   those rows unreadable.

Image demonstrating both of the issues: https://i.imgur.com/Mfq9KX9.png

It would be nice if at least the color issue was looked at, if not both of the