Re: [dev] st -e
S. R. Gal said: 1. what would be st syntax for xterm -e 'tmux a -d || tmux'? st -e sh -c 'tmux a -d || tmux' 2. what font st uses when there is no glyph in the default one? Whatever system provides? -- Dmitrij D. Czarkoff
Re: [dev] st -e
S. R. Gal said: Is there an advantage of sh -c as oposed to double quotes? Looks like opposite is true - with double quotes you'll get one process less. -- Dmitrij D. Czarkoff
Re: [dev] [surf] new surf2 branch
Wolfgang Corcoran-Mathe said: Doesn't this imply a DBus dependency? AFAIR WebkitGtk itself depends on DBUS since inception. -- Dmitrij D. Czarkoff
Re: [dev] no-confing-file orthodoxy
S. R. Gal said: What if I want some blue and orange dwm because the stock choice pale-ish blue and grey (in the 5.x days) is in humble my opinion ugly? I have a question about the no-config-file policy. What if there are multiple user with different color scheme taste? Should be separete binaries the only option? Yes. You can have your dwm with colors you like most in ~/bin/dwm. -- Dmitrij D. Czarkoff
Re: [dev] surf release?
7heo said: Package management is none of suckless's concern. Not in case of package that has a metric fucktone of dependencies. -- Dmitrij D. Czarkoff
Re: [dev] surf release?
7heo said: I don't get how that is a problem. Versions don't have a 1:1 mapping to any mathematical function taking SLOCs as input, do they? If you are done with pretending to be clueless, can we just assume that versions have something to do with package management? -- Dmitrij D. Czarkoff
[dev] surf release?
Hi! There have been more then 2 years since 0.6 surf release (2013-02-10). Maybe it is time for 0.7? -- Dmitrij D. Czarkoff
Re: [dev] surf release?
Greg Reagle said: I don't know git well, just the basics, but why don't you use a git commit id as the target for patching and packaging? As far as I understand, a tag is just a friendly name for a commit id anyway. 1. In some packaging software that will fuck up package versioning and updates beyond repairs. 2. If there is any review process, maintainer will have hard time explaining why he packages snapshot - it is widely believed that maintainers make releases when they consider software stable enough for packaging. 3. It requires quirks that suck so much that it is not suckless any more. -- Dmitrij D. Czarkoff
Re: [dev] surf release?
Martti Kühne said: However upstream is not everyone's taste either, in that configuration changes require recompiling of the respective binary. Exactly! I have a big patch for surf 0.6; it takes time to adopt these changes to current snapshot, and there are better ways to waste that time then to cherry-pick the changes. You may argue that I could follow the development closely and update my patch with every commit. But that actually requires even more time, and yet more time to build every revision. My solution is simple - I have a patch against surf package (which is - wait for it! - of latest *version*). This way I only have to modify my patch with every release. This works perfectly when maintainer indeed bumps package version when user-visible feature lands in source tree. Of course, this fails miserably when maintainer doesn't grasp the concept of version. -- Dmitrij D. Czarkoff
Re: [dev] surf release?
Martti Kühne said: Did you release your big patch to the public? It is a set of patches. Some are from wiki; some are mine; some are published. Is it that hard to port it to HEAD? Trivial in my case. The point still stands though. Also, I am planning to add gtk3 patch to the mix - gtk2 webkit fails on several web applications I am forced to use - and then porting effort won't be trivial any more. -- Dmitrij D. Czarkoff
Re: [dev] surf release?
Greg Reagle said: In bash, it would be: date --date $(git log -1 --pretty=format:%aD) -u +%Y.%m.%d.%H.%M.%S date: unknown option -- - usage: date [-aju] [-d dst] [-r seconds] [-t minutes_west] [-z output_zone] [+format] [[cc]yy]mm]dd]HH]MM[.SS]] But you have a point - this idea would sound awesome to some GNU folks. I bet autoconf people would absolutely love it. -- Dmitrij D. Czarkoff
Re: [dev] What is a good EPUB reader for the Linux terminal (C coded, ncurses)?
patrick295767 patrick295767 said: Would you know a good EPUB reader for our Linux terminal (in C language coded, ncurses)? I use ebook-tools (https://sourceforge.net/projects/ebook-tools/). There is no curses interface, but the flow is pretty much suckless: $ einfo -pp book.epub | lynx -stdin I didn't look into their code, but they use cmake, which suggests that they may do other things wrong as well. -- Dmitrij D. Czarkoff
Re: [dev] [surf] [patch] 13 patches from my Universal Same-Origin Policy branch
tauto...@gmail.com said: My view is that the progression of the web has been actively manipulated, but technical solutions exist. There is power in creation. It isn't just hype, but money, and its creations. Sure the progress of web was manipulated - standards are not plants, they won't develop by themselves. The problem is that the direction of that manipulation was generally well-recieved, so little hope left that it will be discarded any time soon. I have a vision for the web, but it seems you do, too. What is your vision? Very simple. Initially the web was basically a set of tools to transmit NeXTSTEP UI over network in somehow more human-readable form. Then it started to grow monstrous extensions, that were initially directed into making the content more visually appealing, and then to turn the web into another framework for client-server applications, and ended up becoming an overengineered replacement for X11. -- Dmitrij D. Czarkoff
Re: [dev] [surf] [patch] 13 patches from my Universal Same-Origin Policy branch
Ben Woolley said: This is realistic because it happens often when standards clearly suck, and there are better alternatives. Sorry, but the web increasingly sucks over time. If there is anything it proved by now, it is that it just can't get better until the hype goes away, which is unlikely to happen any time soon. -- Dmitrij D. Czarkoff
Re: [dev] [surf] [patch] 13 patches from my Universal Same-Origin Policy branch
non...@inventati.org said: How about sending no UA at all? There are two issues here: * No UA may break things - some sites may expect UA. * There are many sites that render something meaningless to browsers with unknown UAs. * UAs are not the only way of identifying browser, and not even a reliable one. FWIW the Web is too broken for an easy workable solution. -- Dmitrij D. Czarkoff
Re: [dev] [surf] [patch] 13 patches from my Universal Same-Origin Policy branch
Markus Teich said: The really long term solution would imho be to establish web standards which forbid such identifying information leakage by default. Good luck with that. Write back once you establish such a standard. -- Dmitrij D. Czarkoff
Re: [dev] [surf] Webapps in Surf
Jeroen Op 't Eynde said: On Thu, Mar 5, 2015 at 11:29 PM, Dmitrij D. Czarkoff czark...@gmail.com wrote: What about other webkit-based browsers? Do you have the same issue with them? I've tried some of Google Sheets in Midori in a Virtualbox here The idea was not to test midori, but to see whether your webkit is functional, so please install and try midori on the system where you are having the problems with surf. If this is the same VM, there is a note to take: webkit implements its own memory management, as well as virtualbox does, so you may be hitting an interference of memory management bugs. Whatever, I would suggest you to reproduce the issue on real hardware first. -- Dmitrij D. Czarkoff
Re: [dev] [surf] Webapps in Surf
Jeroen Op 't Eynde said: ** Message: console message: @0: Unable to post message to https://docs.google.com. Recipient has origin https://drive.google.com. ** Message: console message: @0: Blocked a frame with origin https://docs.google.com; from accessing a frame with origin https://drive.google.com;. Protocols, domains, and ports must match. ** Message: console message: https://docs.google.com/static/spreadsheets2/client/js/2179867742-ritz_waffle_i18n_core.js @2867: TypeError: undefined is not an object (evaluating 'imb.open') What about other webkit-based browsers? Do you have the same issue with them? -- Dmitrij D. Czarkoff
Re: [dev] [sbase][PATCH] Add col command
FRIGN said: Or gcc(1), generate cool columns. This. -- Dmitrij D. Czarkoff
Re: [dev] Suckless unit testing in C?
Rian Hunter said: In many cases it would be simpler to have a single program. Looks like you are in a wrong crowd. -- Dmitrij D. Czarkoff
Re: [dev] [st] Strange behaviour with bitmap font
Wander Nauta said: https://i.imgur.com/kXY1jQX.png Don't think it is st's fault. -- Dmitrij D. Czarkoff
Re: [sbase] [dev] [ls] [PATCH] Add ls -A
Dimitris Papastamos said: We might want to consider defaulting to -A for root. Wouldn't it be awkward? I would leave that to users - shell aliases do the trick better then one fits all approach IMO. -- Dmitrij D. Czarkoff
Re: [dev] keyboard layouts and shorcuts
Markus Teich said: Are there people on this list using different keyboard layouts and switching between them regularly? I use Yugoslav keyboard layout and switch between Latin and Cyrillic. The layouts only differ in letters, and even then the matching letters (A and А, Z and З, etc.) are on the same keys. So technically I don't have a problem of symbols rotation when I switch layouts. That said, I'd love to have Ctrl-з to be equivalent to Ctrl-z. But I am not sure whether I would tolerate any additional complexity as a trade-off. -- Dmitrij D. Czarkoff
Re: [dev] keyboard layouts and shorcuts
Markus Teich said: sure. Unfortunately I see no easy way of achieving that. Either use the keycodes, which are layout agnostic, but have the disadvantage, that different keyboard models can report different keycodes for the „same“ key. Or use the KeySyms which are keyboard model agnostic but the key combinations would change with the layout. I'm all for keycodes, - all users of multiple layouts I know pass much more time in one layout. Ideally, there should be an include file with macros, so that users could reassign keycodes. -- Dmitrij D. Czarkoff
Re: [dev] st: selecting text affects both primary and clipbaord
Greg Reagle said: - selecting but with no explicit copy should only set PRIMARY, never CLIPBOARD FWIW in suckless context selecting _is_ explicit copy. -- Dmitrij D. Czarkoff
Re: [dev] Suckless web rendering engine
Calvin Morrison said: lacks javascript. See their Plans page.¹ but fails badly on things with floating elements instead of tables. According to their Changelog,² floating elements are already supported in tip. There was a time when I used dillo much, and it was exceptionally good. These were the times when CSS was only starting to surface, and GTK+1 was still used a lot. It's a pitty they don't keep up with web standards. ¹ http://www.dillo.org/Plans.html ² http://hg.dillo.org/dillo/raw-file/tip/ChangeLog -- Dmitrij D. Czarkoff
Re: [dev] Re: [dwm] Most fonts do not work
Joshua Krämer said: I have figured it out myself: the non-working fonts are available with utf8 encoding only, but dwm (without Xft patch) does not support utf8. Sorry, but this doesn't make any sense. Firstly, dwm supports utf-8 without any patches. (Although I don't normally use non-ASCII with dwm, I specifically tried now setting WM_NAME to привет, and it worked just fine.) Next, utf-8 is not font encoding, so it can't influence font rendering. Utf-8 is responsible for set of glyphs that is displayed, but not for fonts. Most likely, your problem is with missing font metadata. See mkfontscale(1) and mkfontdir(1) for details. Alternatively, you may have your font path wrong; see xset(1). But utf-8 has definitely nothing to do with your issue. -- Dmitrij D. Czarkoff
Re: [dev] [sbase] [PATCH-UPDATE] Rewrite tr(1) in a sane way
FRIGN said:
On Sat, 10 Jan 2015 02:52:09 +0100
Dmitrij D. Czarkoff czark...@gmail.com wrote:
+#define UPPER A-Z
+#define LOWER a-z
+#define PUNCT !\#$%'()*+,-./:;=?@[\\]^_`{|}~
These definitions hugely misrepresent corresponding character classes.
I interpreted the character classes by default for the C locale. What do
you mean by hugely misrepresenting? They are just fragments to build the
classes later on.
No, you interpret the character classes for the C locale only, not just
by default. Character classes are useless for C locale (A-Z is easier
to type then [:upper:] anyway); they only really make sense for
scripts that are supposed to do The Right Thing™ for every locale.
Also, defining ranges on systems with no locale-aware collation rules
may be tricky.
As I gather, sbase is supposed to ignore POSIX locales, so there is no
reasonable hope that [A-Z] would actually match the whole alphabets of
languages based on Latin script. Thus the sanest default I see here is
to use isw* family of functions for matching characters against classes,
delegating the problem to libc, where it actually belongs.
That said, the defines in your patch appear to be fully compatible with
GNU and BSD implementations of tr(1), so you may as discourage use of
character classes in manual, label them as legacy compatibility syntax
and be done with it.
--
Dmitrij D. Czarkoff
Re: [dev] [sbase] [PATCH-UPDATE] Rewrite tr(1) in a sane way
FRIGN said:
+#define UPPER A-Z
+#define LOWER a-z
+#define PUNCT !\#$%'()*+,-./:;=?@[\\]^_`{|}~
These definitions hugely misrepresent corresponding character classes.
--
Dmitrij D. Czarkoff
Re: [dev] security issue running surf from home folder
Christoph Lohmann said: Theses patches have been discussed on IRC. The optimal solution has been to make the default DOWNLOAD macro to ask for a string. If the string is empty, pass ‐O to curl, if it’s non‐empty add ‐‐create‐dirs and ‐o $string to curl. Any comments on this? If prompt is shown, it would be nice to have an option to abort download at this point. Otherwise every flash ad gets downloaded without any sort of confirmation. -- Dmitrij D. Czarkoff
Re: [dev] [surf] tabs and clipboard
Markus Teich said: I would like to open a link in a new tab with ctrl-button1 instead of opening up a new surf instance outside of tabbed. You can already do it with ctrl-button2 (middle button/wheel). See buttonrelease() in source if you really want to map it to button1. Also I noticed, if i select some text in surf it is not copied to the primary selection buffer, so I cannot use shift+ins (my primary way of pasting) to insert the selected text in this or any other surf instance. Actually shift+ins is X11 clipboard, and surf indeed fills primary selection and not X11 clipboard. You can use middle mouse button (wheel) to paste. Otherwise you need a tool like parcellite¹, or you can edit surf's source to make use of X11 clipboard. -- Dmitrij D. Czarkoff ¹ http://parcellite.sourceforge.net/
[dev]
From eb5d7870f800a201b23c5e96c4a2b2fac9848b80 Mon Sep 17 00:00:00 2001
From: Dmitrij D. Czarkoff czark...@gmail.com
Date: Fri, 5 Dec 2014 11:08:12 +0100
Subject: [PATCH 2/2] Decouple build system from program settings
---
config.mk | 3 ++-
slock.c | 4 +++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/config.mk b/config.mk
index 8cc3f68..520fe8a 100644
--- a/config.mk
+++ b/config.mk
@@ -14,12 +14,13 @@ INCS = -I. -I/usr/include -I${X11INC}
LIBS = -L/usr/lib -lc -lcrypt -L${X11LIB} -lX11 -lXext
# flags
-CPPFLAGS = -DVERSION=\${VERSION}\ -DHAVE_SHADOW_H -DCOLOR1=\black\
-DCOLOR2=\\#005577\
+CPPFLAGS = -DVERSION=\${VERSION}\ -DHAVE_SHADOW_H
CFLAGS = -std=c99 -pedantic -Wall -Os ${INCS} ${CPPFLAGS}
LDFLAGS = -s ${LIBS}
# On *BSD remove -DHAVE_SHADOW_H from CPPFLAGS and add -DHAVE_BSD_AUTH
# On OpenBSD and Darwin remove -lcrypt from LIBS
+# Redefine COLOR1 and COLOR2 to set custom colors
# compiler and linker
CC = cc
diff --git a/slock.c b/slock.c
index d281965..1ddc35b 100644
--- a/slock.c
+++ b/slock.c
@@ -1,4 +1,3 @@
-
/* See LICENSE file for license details. */
#define _XOPEN_SOURCE 500
#if HAVE_SHADOW_H
@@ -23,6 +22,9 @@
#include bsd_auth.h
#endif
+#define COLOR1 black
+#define COLOR2 #005577
+
typedef struct {
int screen;
Window root, win;
--
2.1.3
[dev]
From 8cbd13d15492fb428b08fb2e298be2cada224e07 Mon Sep 17 00:00:00 2001 From: Dmitrij D. Czarkoff czark...@gmail.com Date: Fri, 5 Dec 2014 11:05:28 +0100 Subject: [PATCH 1/2] Remove .hgtags --- .hgtags | 10 -- 1 file changed, 10 deletions(-) delete mode 100644 .hgtags diff --git a/.hgtags b/.hgtags deleted file mode 100644 index 99325db..000 --- a/.hgtags +++ /dev/null @@ -1,10 +0,0 @@ -0a95c73c7374fbc2342b6040d9f35ddf597729e1 0.1 -da5cb1f0a685258d5315ea109860bacbc2871a57 0.2 -f9157b1864388ad8f1920e5fde7c5849e73d8327 0.3 -4c2cf4d6a2d0e08cbe280ec50ef76c9aecfc0fbe 0.4 -bd24ea7fcca26b161225c464df23ecbfe85280e1 0.5 -dd226a81c09adfa86db232419b3000b7e406df68 0.6 -c4635bb35a4581261f0187b347d5e596dd390ca3 0.7 -c0eb8221ba49c6d10becc93c063c45196a3bb1ba 0.8 -1e8a77601cb9c872921bbfc47909d9339027b295 0.9 -05b949016e85da011c48783d6896de801d347bed 1.0 -- 2.1.3
Re: [dev] Decouple build system from program settings
FRIGN said: This is just wrong. Or do you expect people to dig in the code to change the colours? No. Dmitrij D. Czarkoff said: diff --git a/config.mk b/config.mk ... # On *BSD remove -DHAVE_SHADOW_H from CPPFLAGS and add -DHAVE_BSD_AUTH # On OpenBSD and Darwin remove -lcrypt from LIBS +# Redefine COLOR1 and COLOR2 to set custom colors So I expect people to read config.mk. Better yet, if you want to make the separation, create a config.h and put the option in there. This was my initial thought, but config.def.h with 2 lines doesn't seem sane. Although it is saner then mixing configuration of build system and program options in one file. -- Dmitrij D. Czarkoff
Re: [dev] lsw 0.3
Anselm R Garbe said: I will create a formal release tonight. Thanks! -- Dmitrij D. Czarkoff
[dev] lsw 0.3
Hi! I noticed that lsw in repo has its version bumped in 2011, and no new commits went in since. Provided that current master is much more useful then lsw-0.2, I wanted to ask someone commit access to tag lsw-0.3 and add it to downloads, so that it could be packaged for distros. -- Dmitrij D. Czarkoff
Re: [dev] GCC situation
Anselm R Garbe said: I see a lot of opportunity in a decent C-only compiler. Not sure if OpenBSD achieved anything wrt its pcc porting efforts that Uriel once pushed for. It was not pcc effort, and it is not even in OpenBSD source tree any more. The project's site¹ says it is mostly complete C99 compiler. I tried it quite a while ago, and it did fairly well with suckless projects. It had no support for GNU extentions though. I believe it is not actively developed for several years, and it seems to have lost its momentum. -- Dmitrij D. Czarkoff ¹ http://pcc.ludd.ltu.se/
Re: [dev] Operating system choice
Markus Wichmann said: sabotage/Morpheus/sta.li: All great ideas, but since they're lacking the sheer manpower the major distributions boast, they can't possibly have the same library of packages. They can't possibly have the same library of packages simply because their goal is to be suckless, which implies not including software that sucks too much. If your choice of software would correspond to that of sabotage/Morpheus/sta.li developers, you could easily contribute back packages for those few tools you would be missing. -- Dmitrij D. Czarkoff
Re: [dev] Operating system choice
Lee Fallat said: I would like to use an alternative OS, such as OpenBSD or Plan 9 full time, but I don't have the resources. Resources in this case are servers running mainstream OSs to run services and tools like apache, database software, 3d modeling software and so on. Which of these aren't available on OpenBSD in your opinion? -- Dmitrij D. Czarkoff
Re: [dev] why avoid install?
FRIGN said: We could discuss install, but there's nothing suckless about pkgconfig. What is wrong with pkg-config? -- Dmitrij D. Czarkoff
Re: [dev] why avoid install?
pancake said: Just read the src. Last time i saw it ... It was about 38kloc Wander Nauta said: It also depends on glib, which is at the top of the sucks list. I don't care this particular implementation. All I care is the idea of pkg-config. On OpenBSD there is another implementation, which is not suckless (~900 lines of Perl), but it does not depend on glib. -- Dmitrij D. Czarkoff
Re: [dev] why avoid install?
pancake said: I didnt knew that pkg-conf thing, but perl or 900 lines seems still too bloated for me. I agree. i have a two line shellscript that can replace 99% use of pkg-config, because its just grep and cut with few conditionals. that's why i was proposing to have a suckless pkg-config. I don't have such script, but I suppose that all of pkg-config can be implemented in awk or in shell+grep. That would be suckless. Provided that suckless.org does not provide many needed tools, and that writing suckless code to replace everything that actually needs replacement takes long, I gather that such suckless pkg-config should happen. More so if it can replace tools that suck even more, like GNU autocrap. -- Dmitrij D. Czarkoff
Re: [dev] why avoid install?
pancake said: oh. that's why ldd was telling me that there was no glib --with-internal-glibuse internal glib Nice they didn't bundle glibc and linux kernel as well. -- Dmitrij D. Czarkoff
Re: [dev] slock segfault on rhel7
Johan Guldmyr said: Output: https://pastee.org/35jas You should try building it with -g in CFLAGS. -- Dmitrij D. Czarkoff
Re: [dev] [surf] added dns prefetching option
Quentin Rameau said: Here is a little patch for enabling DNS prefetching in surf via config.h Why? -- Dmitrij D. Czarkoff
Re: [dev] rebooting the web (it was: surf rewrite for WebKit2GTK)
As I see it, modern web consists of several distinct things, that are only loosely coupled together, mostly by being accessible via the same technology: * Social networks. I personally still fail to see any value in these tools, so can't suggest anything here. * Content delivery (newspapers and blogs) venues, which are basically fancy versions of newsgroups / mailing lists. I believe that this particular class of the web use cases is the easiest to replace simply by providing mailing list backend in combination with some sane lightweight markup language, preferably like ReStructured Text. * Portable GUI software that has no dependencies, installation and local storage needs. This class of web uses is the most problematic, and I am not aware of any possible replacements. Thankfully, many services have APIs, which may be used to build more or less suckless clients. FWIW the real problem with making web suck less is that if tech behind web would not suck this much, users would be able to easily decouple interesting parts of the content, omitting ads and other things that actually allow publishers to pay their bills, making web economically viable. Another, lesser problem is that content providers are really keen on differentiating themselves, and thus use CSS/JS quirks much more then is really needed to address issues with aesthetics, usability, accessibility and other aspects. Ultimately, this need of being different will always provide incentive for making web more complex, and thus ultimately suck more. P.S.: Lately more and more sites tell me that my version of Chrome is not supported, which is probably related to surf being stuck with webkit1. Likely things will only become worse over time, so I'd probably have to switch back to Lynx soon. While it sucks, it does so much less then most GUI alternatives. -- Dmitrij D. Czarkoff
Re: [dev] rebooting the web (it was: surf rewrite for WebKit2GTK)
Anthony J. Bentley said: The sane place is the HTTP header. Well, saner would be to assume UTF-8 by default, but this is the next best option. No. There is only one sane place for stating encoding: the bloody standard. It should unambiguously require that no other encoding then UTF-8 may be used for HTML5, and that browser should not render document that failed UTF-8 validation. If UTF-8 ever becomes inadequate for some reason, there should be HTML6 (or whatever next number will be then), that states the next sane encoding. -- Dmitrij D. Czarkoff
Re: [dev] rebooting the web (it was: surf rewrite for WebKit2GTK)
Sorry for replying to single message with two. Anthony J. Bentley said: HTML5 has been some steps forward and some steps back. But one of the unambiguously good things they did was drop any pretense of SGML compatibility, and introduce well‐defined error handling rules (instead of the XML practice of dropping things on the floor as soon as it sees a missing angle bracket). IMO this is the worst thing about HTML currently. There may be only three possible rules for sane markup language: * drop offendig subtree, * abort rendering on first error or * replace malformed document with warning. -- Dmitrij D. Czarkoff
Re: [dev] rebooting the web (it was: surf rewrite for WebKit2GTK)
Anthony J. Bentley said: Does grep abort upon encountering invalid UTF-8 sequences in a file? No. Grep's syntax is not in file input, it is in search strings. So yes, grep always aborts encountering invalid syntax. Does troff abort rendering on invalid macro usage? Practically never. Troff has too much of dialects and incompatibilites, and no standards to help. For HTML closer alternative is TeX, which requires user input in case of invalid macro usage and drops subtree if user refuses to deal with breakage. Also note: unlike HTML both Troff and TeX are supposed to be extensible, which makes some degree of error handling sane. HTML has no macros, no ability to include external packages or other ways to extend its syntax (well, JavaScript is a way to extend HTML, but we are talking about HTML parser, aren't we), so the only effect of relaxed parser is an accumulation of historical garbage that is carried from version to version. Just look at your user agent string to see what I mean. P.S.: HTML would become a better language if the standard (1) deprecated head and body tags, which are useless anyway, (2) required strict rules for tags, and (3) required UTF-8. P.P.S.: Same applies to CSS. Several tricks could make it suck times less. JavaScript can't be fixed though. -- Dmitrij D. Czarkoff
Re: [dev] rebooting the web (it was: surf rewrite for WebKit2GTK)
Teodoro Santoni said: Good evening, I'm not replying to anyone, I need a starting point to avoid demotivation for speculating on this problem. So, you guys wanna get your feet in lava while your hands swim in shit. Is there something that does what, at the core, (X)HTML v.X does, without being that shitty? A document (or UI) format that loves to specify the tree of elements in it, supports media elements without putting them _over_ the text, is free as in far west freedom, and doesn't require to fuck up a parenthesis key. Or a programming language that does what tcl/tk does, with the plethora of tools tcl/tk offers, and can be easily restricted (it has to define rpc services with built-in - or embedded in the #define sense - UI). The latter is not that mandatory, but KISS HTML would be really sad if it was unsafe for the clueless user. Or both. Tcl/Tk. -- Dmitrij D. Czarkoff
[dev] [PATCH] Replace character with U+FFFD if wcwidth() is -1
Helpful when new Unicode codepoints are not recognized by libc.
---
st.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/st.c b/st.c
index 23dd7f1..ad52280 100644
--- a/st.c
+++ b/st.c
@@ -2576,7 +2576,10 @@ tputc(char *c, int len) {
unicodep = ascii = *c;
} else {
utf8decode(c, unicodep, UTF_SIZ);
- width = wcwidth(unicodep);
+ if ((width = wcwidth(unicodep)) == -1) {
+ c = \357\277\275; /* UTF_INVALID */
+ width = 1;
+ }
control = ISCONTROLC1(unicodep);
ascii = unicodep;
}
--
2.1.2
Re: [dev] [PATCH] Replace character with U+FFFD if wcwidth() is -1
Silvan Jegen said: I do agree that this is the right approach. There is however another instance of a wcwidth call on line st.c:3443 that should be handled as well (maybe with abs in that particular case?). As I get it, by the time wcwidth() is called there, all codepoints libc is unaware of are already replaced with U+FFFD. If libc doesn't know U+FFFD either, there will be enough problems running st that adding workarounds for that case will not make sense. -- Dmitrij D. Czarkoff
Re: [dev] [PATCH] [st] Fix issues with wcwidth() returning -1 for
FRIGN said: DESCRIPTION The wcwidth() function returns the number of columns needed to represent the wide character c. If c is a printable wide character, the value is at least 0. If c is null wide character (L'\0'), the value is 0. Otherwise -1 is returned. That's how POSIX-2001 defines it. So yeah, using abs() to catch the invalid case is fine, but could be refined even more. I don't follow your logic here. Glibc currently yelds incorrect result for a set of valid Unicode 7.0 codepoints that were invalid previously. This time they are 1 column width (I didn't verify that, so don't take my word for it), but in future wide characters may be added as well, and wcwidth() will return -1 for them as well, so the abs() hack won't work. IMO ideally st should either not print characters whose codepoints are unknown to libc, or should silently replace them with U+FFFD. At any rate, assumptions about codepoints' properties are not st's business. -- Dmitrij D. Czarkoff
Re: [dev] Ideas for using sic
random...@fastmail.us said: It occurs to me that a line input program (that would work along the lines of a mud client, with a separate editable input line from where output goes, and maybe managing scrollback) would be a good candidate for a do one thing utility. srw[1] apparently does that. [1] http://bitbucket.org/emg/srw -- Dmitrij D. Czarkoff
Re: [dev][sbase] Proposal of suckless compression
Ralph Eastwood said: Although the norm changes - if 'compress' wasn't patent encumbered, I guess there would be wide support for it still. And there is. Check -Z option in the manual of you tar. -- Dmitrij D. Czarkoff
Re: [dev][sbase] Proposal of suckless compression
Ralph Eastwood said:
OpenBSD even had 'gzip' aliased to? compress.
Had? From gzip(1) manual:
| HISTORY
| gzip compatibility was added to compress(1) in OpenBSD 3.4. The
| `g' in this version of gzip stands for ``gratis''.
$ ls -1i /usr/bin/{compress,gzip}
1455743 /usr/bin/compress
1455743 /usr/bin/gzip
It appears that the lz77/deflate gzip is a GNUism.
All three implementations (by GNU, NetBSD and OpenBSD) use deflate.
Naturally this is GNUism - GNU version is canonical one.
Nothing bad about that - but I think although the current norm
dominates, it is only the current norm and people can shift.
People can shift, but archives can't. Most of tarballs that already
available as .tgz or .tar.gz will remain in that format forever, and
having to use GNU tar in order to use them is unacceptable.
Sure, one can do just cat tarball.tgz | gunzip | tar x, which is even
more UNIXy then tar xzf tarball.tgz, but the latter form is what
literally all UNIX users do for at least a decade.
P.S.: GNU and FreeBSD implementations of tar have -J option for
xz-compressed tarballs. NetBSD and OpenBSD don't have it. I am not
sure whether this allows to say that .txz tarballs are not a norm yet.
--
Dmitrij D. Czarkoff
Re: [dev][sbase] Proposal of suckless compression
Ralph Eastwood said: The introduction of bzip2 and xz always surprised me. Perhaps the authors of those formats were the only ones that approached GNU to have them included. Actually GNU tar supports several compression tools: * gzip * xz * bzip2 * lzip * lzma * lzop * compress Bzip2 and xz-utils are merely most popular. Bzip2 was patent-free compression tools with best ratio for quite some time, and xz-utils most likely owe to popularity of 7-zip on Windows. (AFAIK it is also the tool providing the best compression ratio on UNIX now.) -- Dmitrij D. Czarkoff
Re: [dev] [RFC] Design of a vim like text editor
Marc André Tanner said: Editor Frontends The editor core is written in a library like fashion which should make it possible to write multiple frontends with possibly different user interfaces/paradigms. At the moment there exists a barely functional, non-modal nano/sandy like interface which was used during early testing. The default interface is a vim clone called vis. The frontend to run is selected based on the executable name. While I am probably too late to the party, I would suggest to separate your vis into two distinct parts on the same principle as vi and ex: the should be an ex-like CLI editor accepting commands from stdin and printing output to stdout, and there should be separate UI that wraps ex-like CLI, sending commands and parsing output. Such split would make possible to have static build of ex-like CLI on embedded device and controling it with local interface over SSH/telnet. P.S.: there is already a program called vis – replacement for cat -v as suggested by Rob Pike and Brian Kernighan.[1] Probably another name could be chosen. I like vie option, although svi also appears to be available (according to OpenBSD ports at least). [1] http://harmful.cat-v.org/cat-v/unix_prog_design.pdf -- Dmitrij D. Czarkoff
Re: [dev] gtk3 support for surf?
Greetings! Sorry for reviving old thread, but what happened to porting surf to GTK3? There was a discussion in January 2014, where Christoph Lohmann said: Are there any arguments against switching to GTK3? Otherwise I will switch surf to GTK3 using the smootscrolling patch. surf still depends on GTK2 flavor of WebKit. Any status update? -- Dmitrij D. Czarkoff
Re: [dev] suckless distro
Andrew Gwozdziewycz said: Arch is pretty good, has great documentation and is quite lightweight. The most suckless aspect of Arch is nearly undisposable systemd, I believe. -- Dmitrij D. Czarkoff
Re: [dev] Re: suck-less XML parsing
pancake said: Xml standard is bloated, but you can get some assumptions to make it simpler like only accepting utf8. This assumption violates the standard. From 2.2 Characters: | All XML processors must accept the UTF-8 and UTF-16 encodings of | Unicode [Unicode]; the mechanisms for signaling which of the two is in | use, or for bringing other encodings into play, are discussed later, | in 4.3.3 Character Encoding in Entities. -- Dmitrij D. Czarkoff
Re: [dev] C coded lightweight Linux vector graphics editor
patrick295767 patrick295767 said: Because you have always very fantastic/great ideas in this field, I would like to ask if you would know a cool vector graphics editor. Basically, all of them suck. The best SVG editor I came across to date was your favorite plain text editor name here, although SVG already sucks enough to make the idea of suckless SVG editor self-contradictory. On a side note: I really enjoy the idea behind Tkpaint,[0] which produced Tcl script as an output. I believe drawing capabilities of TCL are not good enough to match SVG though. [0]: http://aspbak.netanya.ac.il/~samy/tkpaint.html -- Dmitrij D. Czarkoff
Re: [dev] C coded lightweight Linux vector graphics editor
78...@web.de said: What's wrong with MetaPost? http://ect.bell-labs.com/who/hobby/MetaPost.html Dependencies. It is OK for use in TeX, but for vector graphics alone it's an overkill. -- Dmitrij D. Czarkoff
Re: [dev] C coded lightweight Linux vector graphics editor
Truls Becken said: There is also the pic preprocessor for troff. IMO suffer from the same issue: OK for its domain, but somehow inappropriate elsewhere. -- Dmitrij D. Czarkoff
Re: [dev][project] soap - a simple xdg-open replacement
FRIGN said: This is a solution, but who likes dealing with this xdg-crap if he doesn't even have desktop-icons. Why do you need xdg at all then? Soap doesn't break it either. If the package-manager overwrites the soap-xdg-open, you just go to your soap-repo and reinstall it. Your software calls xdg-open, so either you install soap as $PREFIX/xdg-open or it is not used. In former case you overwrite $PREFIX/xdg-open from xdg-utils. I've been thinking about scrapping xdg-open completely and make soap configurable in a way that it doesn't need to rely on xdg-open any more. BTW, what is wrong with just using st dmenu for this stuff? Wow! And you complain about the danger of my `-escaped shell-parameter. I didn't. I complained about custom format in place of standard mailcap. -- Dmitrij D. Czarkoff
Re: [dev] [ANNOUNCE] req 1.0 - a gawk und dmenu powered plumberlike
Robert Figura said: A little more than two years ago i started coding some plumberlike in gawk, and i think it's time for me to seek suggestions and share what Why not POSIX awk? -- Dmitrij D. Czarkoff
Re: [dev][project] soap - a simple xdg-open replacement
FRIGN said:
I did not investigate issue in detail, but apparently xdg-open treats
all http links as text/html. xdg-open http: starts Firefox.
Yes, that's the problem. That's why I wrote soap in the first place.
But this is easy to work around with a shell script. Having something
like http-helper.sh below, you may make a simple .desktop file and:
$ xdg-mime default http-helper.desktop text/html
It is more consistent with a model, doesn't break package manager (you
have xdg-utils in dependecies for software, don't you?) and is easier to
fine-tune.
Well, if you edit your .mailcap frequently, why not just alias a
command like
editsoap = vim /path/to/soap/config.h make clean make install
to provide the same functionality?
Obviously, this is the way to work around the issue. Still, moving
configuration of program X to configuration file of program Y feels like
bad taste to me.
--
Dmitrij D. Czarkoff
http-helper.sh:
#!/bin/sh
MIME=`curl -I --max-redirs -1 -s $@ | sed -Ee '/Content-Type/!d' -e 's/.+:
([^;]+)(;.*)?/\1/'`
if [ $MIME == text/html -o x$MIME == x ]
then
$BROWSER $@
else
file=`mktemp -p ${TMP:-/tmp} xdgXX`
curl -s $@ $file
xdg-open $file
rm $file
fi
Re: [dev] C coded cross-platform youtube video viewer
patrick295767 patrick295767 said: One can retrieve the link and send it over mplayer on nix, vlc,... and any win32 apps as well. quvi dump -b mute -e ffplay %u $URL -- Dmitrij D. Czarkoff
Re: [dev][project] soap - a simple xdg-open replacement
FRIGN said: mailcap files come pretty close, but only offer detection by mime (you couldn't for instance parse youtube-links if you wanted or differentiate between a file:// and http://-URL). You can. Use text/html mime type and a script to parse URLs. (You'll need to parse URLs anyway, if you want to do anything useful with them.) Additionally, with mailcap you can only provide one command, whereas soap offers you to give a whole set of commands, including piping and other stuff. You could do that with mailcap, too, by writing a shell-script for each handler. Arbitrary shell commands work in mailcap. Now, most importantly, what you have to consider is that mailcap isn't called by X-programs, which soap is directed at (- replacing xdg-open). I must have worded it clearer: I suggested using mailcap as configuration format for soap. Or at least extend it to support whatever you want to support. -- Dmitrij D. Czarkoff
Re: [dev][project] soap - a simple xdg-open replacement
FRIGN said: You can. Use text/html mime type and a script to parse URLs. (You'll need to parse URLs anyway, if you want to do anything useful with them.) Well, Youtube-links don't end with .html. That's the problem with MIME-detectors. I did not investigate issue in detail, but apparently xdg-open treats all http links as text/html. xdg-open http: starts Firefox. File-based configuration sounds interesting, but I personally see no need to make it more complex than compiling it in directly. This concept is already working great for dwm and other pieces of suckless software. I edit my ~/.mailcap much more frequently then I build all suckless tools combined. That happens mostly because I stumble across file formats that I didn't need to deal with before, or simply didn't need to define. I expect that if I would be using soap, it would end up being the most frequently compiled software on my system. This is an easy shot, given that your design suggests hardcoding URLs, which, given the nature of modern web, would lead to very frequent changes. -- Dmitrij D. Czarkoff
Re: [dev][project] soap - a simple xdg-open replacement
FRIGN said:
A configuration can look like this:
{ \.mp3,st -e mplayer %s },
{ \.(jpg|png|tiff)$,feh %s},
{ \.gif,wget -O /tmp/tmp.gif %s gifview -a
/tmp/tmp.gif },
{ ^(http://|https://)?(www\.)?(youtube.com/watch\?|youtu\.be/),
youtube-viewer %s }
where %s is the _shell-escaped_ argument given to xdg-open.
Am I missing something, or mailcap files already do that?
--
Dmitrij D. Czarkoff
Re: [dev] [proposal] Suckless Tox-Client as a Skype replacement
FRIGN said: Well I looked into SIP a few months ago and couldn't become a fan of it. Can you please go in more detail about SIP? I looked into it some time ago, and (apart from several ugly XML-based extensions) it seemed fine. I actually use baresip[0] – a small command line client with audio and video support. Although it lacks several features I would like to see, it is quite usable, 2) ncurses needs to be discussed. A design like we have with ii would be very creative, but (imho) not very pleasant in everyday life with a proper secondary interface on top of it. Actually I would choose ii-like interface over curses-based UI. One may implement latter on top of former, but not vice versa. It's different, because it's decentralized. You don't need to register, as it's building on top of a DHT-P2P-network and you just have a hash-key you give to your friends and they can directly add you. This strong benefit is imho one of the key advantages over centralized systems like those based on XMPP (Pidgin being a client). Actually, this is a good argument for choosing Tox over SIP. Unfortunately, http://tox.im appears to be unreachable, so I can't comment on protocol itself yet. [0] http://www.creytiv.com/baresip.html -- Dmitrij D. Czarkoff
Re: [dev] dmenu and unicode
fREW Schmidt said:
As far as I can tell dmenu doesn't work with unicode input.
To see an example, check this out:
perl -E'binmode(STDOUT, :encoding(UTF-8)); say \N{HEAVY BLACK HEART}'
vs
perl -E'binmode(STDOUT, :encoding(UTF-8)); say \N{HEAVY BLACK HEART}'
| dmenu
Anyone have tips on making this work? Thanks!
Just choose proper font, eg.:
perl -E'binmode(STDOUT, :encoding(UTF-8)); say \N{HEAVY BLACK HEART}' |
dmenu -fn -*-dejavu sans mono-medium-r-normal-*-*-*-*-*-*-*-iso10646-1
--
Dmitrij D. Czarkoff
Re: [dev] Shell vs C where is the border?
Markus Wichmann said: The more I read of POSIX, the more I think those options are only there because they were easy to add to some specific implementations. Actually options in POSIX are mostly those already found in some specific implementations - the main idea behind POSIX is to create a subset of UNIX interfaces one should expect on generic POSIX system. [...] and when you try to do something really crazy and new, like using a new language (go) or a new paradigm (haskell) then good luck getting that to conform. Which is not surprising, given that POSIX is about compatibility, which is almost directly opposite concept to innovation. -- Dmitrij D. Czarkoff
Re: [dev] Screencasts?
Kai Hendry said: Videos should be easier to store (if they are self-contained), create and consume. Videos are harder to store (they are a lot larger then every other type of content), to create (video codecs are very bad at encoding text) and - the hardest part - to consume (you need to either memorize the whole process or enter infinite play - skip backwards - pause cycle to follow instructions). It only pays of for very UI-heavy software with tricky interaction and low discoverability of UI elements, but even then screenshots normally do better. Effectively the only good cases for screencasts I've seen to date are video games and Metro UI. Anyway, there is room for both mediums. Suckless software workflow is much easier to describe in plain text. If there is any room for screencasting, it definitely isn't here. -- Dmitrij D. Czarkoff
Re: [dev] Screencasts?
Caleb Malchik said:
I switched to Linux/cli/dwm from OS X just a few years ago, and since the
switch I feel the way I do certain basic things is embarrassingly
inefficient. For example, if I find an article on the web I want to come
back to, I will copy the URL from the address bar, open a terminal window
with ctl-shift-enter, type 'vi doc/toread', then paste the URL
at the top of the file. Yes it's still faster than what I would have done on
OS X, but it feels clunky.
You may put together a script like this:
#!/bin/sh
TMPFILE=`mktemp -p /tmp toread.XX`
{xclip -o echo; cat doc/toread} $TMPFILE
mv $TMPFILE doc/toread
and then after selecting URL in address bar you could just run this
script (eg. via Ctrl+p in dwm).
--
Dmitrij D. Czarkoff
Re: [dev] tmux/screen alternative
On Sunday, February 23, 2014 11:58:36 AM Raphaël Proust wrote:
Comment:
The manpage states
if a given session name starts either with a dot or a forward slash
it is interpreted as a path name and used unmodified i.e. relatively to
the
current working directory.
That seems a bit surprising. Either the wording and the functionality
differ or the functionality is very surprising. I'd expect
if a given session name starts with a forward slash
it is interpreted as an absolute path, if a dot followed
by a slash (./) it is interpreted a relative path.
Actually it is exactly as is stated:
if (name[0] == '.' || name[0] == '/') {
strncpy(sockaddr.sun_path, name, maxlen);
--
Dmitrij D. Czarkoff
Re: [dev] XML vs HTML (was: Article about suckless on root.cz)
Eckehard Berns said: You only write a parser once. But you write some magnitude more markup that is going to be parsed by it. So optimizing the markup specification for authoring has a better net gain than to optimize the protocol just to get away with a simpler parser. Actually, if parser behavior is simple and easily predictable, the task of writing markup is easier. When I write correct HTML, I still have to open browser to see how it renders, because I have no way to predict the actual result (apart from my experience with different generally unexpected results that serve me the basis for educated guess). This alone is sufficient for me to be all for simplistic strict parser with zero fault tollerance. -- Dmitrij D. Czarkoff
Re: [dev] XML vs HTML (was: Article about suckless on root.cz)
FRIGN said: Actually, if parser behavior is simple and easily predictable, the task of writing markup is easier. When I write correct HTML, I still have to open browser to see how it renders, because I have no way to predict the actual result (apart from my experience with different generally unexpected results that serve me the basis for educated guess). I'm interested. Do you have a specific case where that happened? I happen to come over different issues here and there. They are mostly either bugs (which appear due to always changing nature of modern web engine) or optimizations supposed to address bad HTML code. Eg. I had problems with tables, which were optimized by Firefox and Chrome differently, resulting in different numbers of rows when I used empty cells for complex table drawing. Thus, rendering issues are either originating from bad browser-defaults or faulty CSS. I don't even touch CSS. And I just can't see any valid argument for existance of browser-defaults – the format that is supposed to deliver pixel-perfect rendering for given screen size the very fact that there is something left for browser to decide is already complete and utter defeat for the whole markup language. -- Dmitrij D. Czarkoff
Re: [dev] XML vs HTML (was: Article about suckless on root.cz)
Charlie Kester said: (As, for example, epub vs pdf.) These formats serve different functions. It would be more fair to compare PDF to PS and ePub to roff respectively. -- Dmitrij D. Czarkoff
Re: [dev] Reasonable Makefiles
Nick said: Interesting. How do you handle things like ldflags and cflags for specific libraries? Are they just all listed in the central config.mk, with more lines added when an application is added that needs them? You might have a look at BSD's ports infrastructure: there is some single location of settings somewhere in ports infrastructure itself, a user-editable configuration file (I expect Anselm would replace those with one config.mk) and individual ports that need some specific flags override the config values in their makefiles. -- Dmitrij D. Czarkoff
Re: [dev] Patch Licenses
Eric Pruitt said: I may be missing it, but I don't see anything on the site that governs what license contributors' content falls under, so I'm wondering: what license do patches and other contributions submitted to the wiki fall under? I would assume that contributed patches are under the license of software they are intended to be applied to. Eg. patches for surf are under whatever license surf is. -- Dmitrij D. Czarkoff
Re: [dev] gtk3 support for surf?
FRIGN said: Well, maybe that GTK3-programs suck? They feel very slow imho and don't fit well into a world where GTK2 is still the least-painful way to go. At least on OpenBSD GTK+3 is already required for GTK+2 webkit: /usr/ports/www/surf $ make full-run-depends | grep gtk gtk-update-icon-cache-2.24.22 gtk+3-3.10.6 gtk+2-2.24.22p0 This makes the whole point of GTK+3 is bad a bit moot here from practical standpoint. AFAIK webkit2 (GTK+3 version) is also a bit ahead of webkit1 feature-wise, which may be important, specificly given that surf is indeed an interface to things that already suck big time. -- Dmitrij D. Czarkoff
Re: [dev] [surf] view local file
Markus Teich markus.te...@stusta.mhn.de wrote: Heyho, this morning I wondered how to open a file from the filesystem in surf, but neither file:// nor file:/// did work. Is it even possible? Thanks. --Markus file:///home/user/example.html works for me. -- Dmitrij D. Czarkoff
Re: [dev] portable photoshop-like lite application based on C?
patrick295767 wrote: When I am using Windows, I need sometimes to use Linux without touching anything. So I run Debian from the USB stick. It must remain very light and fast. Use a live media that copies everything to RAM. Make your own if no readily available is there - it is quite easy with Gentoo, Arch or whatever remains more or less simple these days. -- Dmitrij D. Czarkoff
Re: [dev] portable photoshop-like lite application based on C?
Nick said: Use a live media that copies everything to RAM. Make your own if no readily available is there - it is quite easy with Gentoo, Arch or whatever remains more or less simple these days. Yep, that's a good idea, but obviously depends on the host computer having lots of available RAM. But if you're able to it'll make everything fast and delightful. These days nearly everything has enough RAM - even phones. FWIW a specially crafted LiveUSB containing bare minimum to run GIMP and its plugins comfortably would require small amount of RAM, particularly if all squeezed into initramfs. -- Dmitrij D. Czarkoff
Re: [dev] Bringing together OS'es terminals and their codepages
Troels Henriksen said: You really shouldn't write terminal programs that require precise colours. FWIW as a rule you really shouldn't write terminal programs that use colours. -- Dmitrij D. Czarkoff
Re: [dev] [st] System freeze when killing X after using st-git
Andreas Marschall wrote: Yes, very mature. The first statement I would agree on but in what way is Arch Linux with systemd a disaster? It runs very smoothely and fast over here. Or is it just the usual wannabe elitist bull...? You know, the systemd (and friends) actually does a great job of ruining my day with Arch boxes - by now I have one permanently hanging on boot, another booting up twice as slowly as it did before the switch and a third one, which gets misconfigured by the boot-time voodoo. Sure, at least some of these problems are solvable, but I have to invest quite some time into it - and all of it goes into compensating the improvements in boot process. And I still can't see any benefit from the switch. -- Dmitrij D. Czarkoff
Re: [dev] Mailing list behavior
Thorsten Glaser said: Can we please ban Googlemail from this mailing list? Obviously I'm against this. (Funnily enough, recently I’ve started looking at From headers more, and, sure enough, Googlemail users are the biggest average idiots on other mailing lists as well.) Thanks. -- Dmitrij D. Czarkoff
Re: [dev] Mailing list behavior - was: Question about arg.h
Calvin Morrison said: Why do I top post? yes i am lazy! After being with gmail since it was in beta, I still don't have an option to god damned bottom-post by default!! Then go and get any of the scripts to enable it. Or just install MUA. Top-posting since Gmail beta has nothing to do with being lazy - it is just showing disrespect to others. -- Dmitrij D. Czarkoff
Re: [dev] Mailing list behavior - was: Question about arg.h
random...@fastmail.us said: Top posting or bottom posting isn't an option, it's determined by _where you click the mouse_. You're not supposed to just start typing where the cursor drops, you're supposed to edit out the bits of the quote that you're not replying to. You probably didn't use Gmail for a while - they now collapse quotes, and AFAIR don't allow typing below them. -- Dmitrij D. Czarkoff
Re: [dev] Question about arg.h
Chris Down ch...@chrisdown.name wrote: On 2013-11-06 06:38:23 +0100, Christoph Lohmann wrote: You have nothing to say, I guess. What does it make you feel that I do not append a salutation and closing to this e-mail? Does it bother you in any way? If so, why? If not, why should I do so? I'm puzzled too. For years e-mail netiquette developed in direction of reducing text PSNR, and having no greetings and signatures goes in line with that. FWIW do you really have to say anything with your signature? -- Dmitrij D. Czarkoff
Re: [dev] Suckless remote shell?
Alexander S. wrote: The implicit conversion removal is a good example of how much C is reliant on a weak type system. They have to break it in C++, at least partially, and imo, weak type systems are just bad taste. Indeed they are in high level languages. C is a low level language, and its type system is barely a representation of hardware properties. -- Dmitrij D. Czarkoff
Re: Asshole vs. reality [was: Re: [dev] Question about arg.h]
Christoph Lohmann 2...@r-36.net wrote: What does it make you feel that I do not append a salutation and closing to this e-mail? Does it bother you in any way? If so, why? If not, why should I do so? This is not twitter. He has a point, and this discussion is related to usage of this mailing list. -- Dmitrij D. Czarkoff
Re: [dev] Question about arg.h
Alexander Huemer wrote: P.S. I passionately hate people who top-post, don't give enough details and cannot say hi or bye in an email. I wonder about the last bit: aren't hi and bye implied? -- Dmitrij D. Czarkoff
Re: [dev] IRC on Free node
Thorsten Glaser said: And neither the one nor the other Googlemail user know how to properly write eMails. I sense a theme there. Gmail's webmail doesn't allow to tune quoting attribution in a sensible manner, so repeating this every time doesn't make much sense. May be you just move the links to your signature? -- Dmitrij D. Czarkoff
Re: [dev] IRC on Free node
Chris Down said: On 2013-11-02 11:13, Dmitrij D. Czarkoff wrote: Irony? Surely the answer to that is to not use Gmail's webmail client, then? It isn't always an option. You might be tied to using Gmail UI for some reason, which makes using other clients impractical. -- Dmitrij D. Czarkoff
Re: [dev] IRC on Free node
Thorsten Glaser said: it just involves a little bit of effort. But not much more, since one needs to trim the quote in other MUAs as well. Such amount of effort stopped me from using mobile Gmail app - I now get to PC in order to answer mail. -- Dmitrij D. Czarkoff
Re: [dev] IRC on Free node
Thorsten Glaser said: (The frontend needs not be graphical, of course.) Why? -- Dmitrij D. Czarkoff
Re: [dev] Some thoughts about XML
Szymon Olewniczak said: I'm serching for something similar as dwm in the web services world. The thing you were talking about initially - if I got you right - is another CMS engine. You may look at werc for a good implementation of this idea. If you want something more lightweight, you may have your data in JSON and provide URLs for raw data together with HTML presentation either via JS or your custom CGI script. We cannnot force everyone to use something diffirent than HTML and HTTP becouse noone want a huge revolution(users, web browsers and http servers developers). What are you talking about? We are stuck with HTML+JS+CSS over HTTP with no possible workaround. (Apart from re-doing the web stack from scratch and mirroring it with HTML+JS+CSS over HTTP for unbelievers.) But maybe we can use this tools to create something less sucky, something that would make the web a better place. Better place undefined. Really, to date you suggested XML+XSLT, which doesn't sound like a workable replacement, leave alone suckless bit. -- Dmitrij D. Czarkoff
