Re: [dev] [st] Problems when typing
2015-03-16 8:36 GMT+03:00 Christoph Lohmann <2...@r-36.net>: > Sincerely, > > Christoph Lohmann Wow, didn't ever seen ye that full of yerself, 20h. Making up challenges for random people at the same time you tell them to never come back, eh? Must make a ton of sense to you.
Re: [dev] Potential bug in st fallback font code
2015-03-11 2:00 GMT+03:00 Eric Pruitt : > First, you say thanks for reporting the issue: Don't try to argue with Christoph, please. His words are rarely the reason for why he's pissed off, but most often are the rationalization he invented on the fly to make his opinions appear objective and justified with project's goals or whatnot. He was probably pissed by you sending 4 emails in quick succession instead of 1.
Re: [dev] [RFC] Design of a vim like text editor
Oh, another C vs C++ holy crusade, it seems. I'd like to note here that while object-oriented progamming can be done in C, doing polymorphism, for example, is a pain in the ass; furthermore, syntactic sugar and an ability to write e. g. win.repaint(rect) instead of window_repaint_rectangle(win, &rect) actually *increases* the readability of code when you have to deal with several lines of that fashion in a row. Syntactic sugar, say what you want about it, tends to reduce noise, as does language support for certain powerful programming practices. On 17 Sep 2014 11:04 GMT +3, Roberto E. Vargas Caballero wrote: > If you want to use the type > system to ensure the correctness of your code, instead of writing > good code then you have an understanding problem about programming. That's an odd thing to hear from a professional like you. Making mistakes isn't about "writing good code" (what does this even mean per se) or not, it's about the fact that humans are not infallible. If someone knows their own mistakes and wants to use the benefits of proper type system (which C unfortunately lacks altogether and C++ attempts to fix the C mess are, while valiant, broken as well), you cannot possibly condemn him for that. The fact that in C++, you have to use ad-hoc structs for that instead of just defining a new numeric type is, of course, another sad topic altogether. TLDR: C++ does many things to simplify a programmer's life, and you cannot deny that. But it is also undeniable that it does them all poorly, with rather obscure semantics even. 2014-09-17 1:16 GMT+04:00 FRIGN : >> Can't we have a civilized discussion ? > Is Maxime a male or female name? ...I wonder if you find your own question rude or not.
Re: [dev] [dwm][patch] limit updates per second for win move/resize
2014-08-02 18:16 GMT+04:00 Hiltjo Posthuma : > Hi, > > Attached is a patch which fixes an issue I have with laggy screen > updates when resizing or moving floating windows. > > What the patch does is: > Limit the amount of updates when resizing or moving a floating window > to 60 times per second. This makes resizing and moving alot smoother > and by limiting it it also uses alot less resources. > > Patch also available at: > http://www.codemadness.nl/downloads/patches/dwm/0001-limit-updates-per-second-for-win-move-resize.patch > > Applies cleanly against latest git master > (18248ebf4b9465b837e717dcd14a5202a98248e0). > > Kind regards, > Hiltjo Posthuma Could you reformat it as git send-email (1) patch? It would be much more pleasant for a maintainer to apply. Otherwise, great job! This will hopefully fix a couple of issues I have.
Re: [dev] Misbehaving floating window in dwm
2014-07-05 0:03 GMT+04:00 Michal Haško : > 2014-07-04 13:15 GMT+02:00 Alexander S. : >> 2014-07-04 0:08 GMT+04:00 Michal Haško : >>> Nope, doesn't help. >> Did you try xdotool/wmctrl, also? > > As I understand it, that would mean manual intervention every time I > use pianoteq, right? I certainly don't want that. > > I've just discovered, that pianoteq menubars work correctly when > executed with --fullscreen flag. Not ideal, but at least I don't have > to find a replacement for dwm. The point is to test, not to provide a replacement :). If we find a basic way to move it, it may provide an insight of the problem.
Re: [dev] [PATCH] Move default rows, cols to config.def.h
2014-06-25 21:00 GMT+04:00 Roberto E. Vargas Caballero : >> > is this really necessary? Default constants don't really mean >> > anything, they persist literally until the window is mapped and the >> > text buffer is resized at >> (apologies for accidentally sending) >> L3726, so if anything, I'd vote for their removal, not their >> canonicalization through config.[def.]h. > > In this case I don't agree with you guys. The size 80x24 is a very standard > size and I don't understand why the user could want another default size. > Remember that the user can pass parameters to st to select the initial > size of the terminal. > In my case 80 and 24 are more meaningful that if you use a symbolic name > (for example default_cols or default_rows), because they are values > that directly indicate me they are related to the default number of > columns and rows. I agree that symbolic constants would be odd to use, but the oint I'm trying to make is that those numbers specifically don't mean anything. They are replaced before subprocess is started, right after the X window is mapped.
Re: [dev] Misbehaving floating window in dwm
2014-07-04 0:08 GMT+04:00 Michal Haško : > Nope, doesn't help. Did you try xdotool/wmctrl, also?
Re: [dev] Misbehaving floating window in dwm
2014-07-03 10:44 GMT+04:00 Michal Haško : > Hi all, > > I'm new to the list, although I've been active user of dwm for 3+ years. > There's this misbehaving program whose window I cannot move whatsoever. > xprop-ing the window doesn't report any wm_class, which is by itself > weird. In other window managers (kwin) the window behaves properly, > can be moved (but not resized, which is by design, you'll see if you > try it). >From quick code digging, it seems that moving and resizing both call XConfigureWindow with CWX|CWY|CWWidth|CWHeight|CWBorderWidth [0]. If the application in question is simply ignoring all events that look even remotely like resizing, without applying the movement part, that would explain this behaviour. While separating resize and move is indeed possible, its a workaround for what I'd call... not sane behaviour, and also extremely not common case. My guess is that it won't be fixed. Try writing to Pianoteq support, maybe they'll file a bug about it. For quickly confirming it, you can replace the mask in question with CWX|CWY, that'll produce version of DWM incapable of resizing windows, but you'll be able to test if it moves then. [0] http://git.suckless.org/dwm/tree/dwm.c#n1260 -- Best regards, Alexander Sedov.
Re: [dev] Plain text editor that sucks less - an alternative to VIM?
2014-07-02 18:22 GMT+04:00 Charlie Kester : > On Wed 02 Jul 2014 at 06:52:41 PDT Alexander S. wrote: >> >> >> Good sntax highlighting allows you to *ignore* syntax >> better, rather than focusing your attention on it. > > > You say that like it's a good thing. > To be able to ignore correct syntax in favor of reading semantics? It most obviously is. If you want to read some syntax, you go and open K&R. -- Peace, Alexander Sedov.
Re: [dev] Plain text editor that sucks less - an alternative to VIM?
2014-07-02 13:12 GMT+04:00 Dimitris Papastamos : > On Wed, Jul 02, 2014 at 09:39:20AM +0400, Alexander S. wrote: >> 2014-06-29 18:43 GMT+04:00 Aapo Vienamo : >> >> 2. Fantastic syntax highlighting >> > This may be considered harmfull in general. [0] >> > [0] http://www.linusakesson.net/programming/syntaxhighlighting/ > >> Hello, >> This snippet of thought makes a case that reading code is like reading >> a literature, when in fact, surprise, it is not. > > He specifically says "Unlike novels blabla". Yeah yeah, I know, but saying something and making the case against it is strange. Good sntax highlighting allows you to *ignore* syntax better, rather than focusing your attention on it. >> You can literally replace his arguments against syntax highlighting >> with arguments against alignment in tabular data, >> because reading a literature with alignment will prove to be >> difficult. Or that you don't need indentation because it makes >> you focus on parsing tree rather than semantics, if we're taking it >> closer to the programming world. > > There are always trade-offs. Indentation is worth it. Trade-offs? What do we lose? >> The ridiculousness of a comparison would be more apparent if, instead >> of coloring verbs in text (which I personally >> do not consider keywords, verbs are operators; the program text is not >> very saturated with keywords, and those serve >> more as headings), it indeed did compare a snippet with and without >> highlighting. > > Try it. Uh, I did. I obviously have seen code without synta highlighting, what are you talking about? >> Quote: >> > Syntax errors will be found by the compiler anyway; the developers >> > shouldn't waste time looking for them. >> The point of syntax highlighting is that you don't have to waste time >> looking for them, as they become apparent; >> indeed, you also don't need to spend time compiling it and reading >> what the compiler spew forthh at you in response. > > The compiler output should be relatively easy to read assuming you are > familiar with your compiler (with the exception of g++). You can pattern > match it for the most part because of the limited amount of different > error messages you can get. You can then simply jump to the corresponding > line in the code. > > Use your compiler with sensible options enabled. Because compiling is fast, right? Well, it is not. >> This statement would be like saying that spellcheckers are useless >> because correctors are there to fix typos in a draft. > > Stop applying this concept to everything. He's applying typography concepts to code editing, so that's just pot calling kettle black. Don't forbid my analogies just because they're analogies. I don't apply it to everything, just to that specific case. Tell me why I'm wrong. >> The desire of some people even in spheres that are supposedly >> technologically advanced to go all "I'm better than you because I >> don't >> NEED your newfangled this and that" is frightening. > > That's just his opinion and his experience. Get over it. > > FWIW I have not used syntax highlighting in years. My personal > experience is similar to what lft is talking about in his article. Yeah but saying "that's just his opinion" doesn't absolve said opinion from criticism. You cannot have any discourse if you just keep repeating that mantra. (Though I think arguing with him would be hopeless, as, in comments, he presents the fact that improper highlighting of the word "white" in Alice snippet went unnoticed for long as an evidence of highlighting failure to show errors, whil it is clear, that highlighting cannot show errors in highlighting.) It's still incredible to me how some people think they're better than others on absolutely no grounds, though. And while I agree that colorful highlighting only looks good on certain languages, and C is not among them, (but assembly absolutely is), Emacs-style fontstyle highlighting is uncluttery and helps you unconsciously make notes of what's going on without having to read through keywords. Which is what the "article"'s author wants anyway.
Re: [dev] Plain text editor that sucks less - an alternative to VIM?
2014-06-29 18:43 GMT+04:00 Aapo Vienamo : >> 2. Fantastic syntax highlighting > This may be considered harmfull in general. [0] > [0] http://www.linusakesson.net/programming/syntaxhighlighting/ Hello, This snippet of thought makes a case that reading code is like reading a literature, when in fact, surprise, it is not. You can literally replace his arguments against syntax highlighting with arguments against alignment in tabular data, because reading a literature with alignment will prove to be difficult. Or that you don't need indentation because it makes you focus on parsing tree rather than semantics, if we're taking it closer to the programming world. The ridiculousness of a comparison would be more apparent if, instead of coloring verbs in text (which I personally do not consider keywords, verbs are operators; the program text is not very saturated with keywords, and those serve more as headings), it indeed did compare a snippet with and without highlighting. Quote: > Syntax errors will be found by the compiler anyway; the developers shouldn't > waste time looking for them. The point of syntax highlighting is that you don't have to waste time looking for them, as they become apparent; indeed, you also don't need to spend time compiling it and reading what the compiler spew forthh at you in response. This statement would be like saying that spellcheckers are useless because correctors are there to fix typos in a draft. Then, having falsibly dismissed syntax highlighting for experienced programmers, the author goes on to suggest that it is a handicap to... uh, what exactly? Learning all 20 keywords in a language? Quote: > They will have to, eventually, and then they will have to un-learn the > colours. Obviously, syntax highlighting isn't crucial for understanding code, indeed, it often doesn't even distinguish between keywords. So the analogy falls flat: you don't have to unlearn the colors to learn the names, you know the names already. This is especially strange, because author apparently understands that typos are important to detect. The desire of some people even in spheres that are supposedly technologically advanced to go all "I'm better than you because I don't NEED your newfangled this and that" is frightening. -- Peace, Alexander Sedov.
Re: [dev] [st] [PATCH] Explicit cast in CEIL macro
2014-06-24 23:16 GMT+04:00 Roberto E. Vargas Caballero : >> But who'd specify a scaling factor of 1.9 or sth.? >> BTW: Casting to int yields the exact same results for both CEIL and >> ceilf in my setup. > > There is an implicit casting because xw.cw and xw.ch are integers, > so the explicit casting is redundant. This macro is used only in one place, > xloadfonts, that is out of the main loop (usually is only called in > the init process), so it is a waste of time try to optimize it for speed. > A macro like: > > CEIL(x) ((int)(x) + ((x) > 0 && (int)(x) != (x))) > > Can take more bytes that the direct call to ceilf because it has > only one parameter, so the calling sequence is short, and in case of > being and inlined function, the compiler version will be better > that our version, so my proposal for the patch is: Greetings, I would vote to drop the macro, because supporting it for future use-cases can be a nightmare. What to use for ceiliing in those calculations is another matter... we could always just add 1 - FLT_EPSILON and call it a day.
Re: [dev] [PATCH] Render faint attribute
2014-06-25 1:50 GMT+04:00 Anders Eurenius : > Render faint attribute > > Faint text is implemented by allocating a new color at one-half > intensity of each of the r, g, b components, or if the text bold at the > same time, it is not made lighter. > > cheers > aes Greetings, could you provide a use-case for this attribute? It seems very obscure to me, and not so long ago, there was a huge debate which resulted in mucking with colours being interpreted as negative. -- Best regards, Alexander Sedov.
Re: [dev] [PATCH] Move default rows, cols to config.def.h
2014-06-25 3:42 GMT+04:00 Alexander S. : > 2014-06-25 1:51 GMT+04:00 Anders Eurenius : >> Move default rows, cols to config.def.h >> >> Add default_cols, default_rows as static ints in the config.def.h >> header, instead of using constants directly in the code. >> >> cheers >> aes > Greetings, > is this really necessary? Default constants don't really mean > anything, they persist literally until the window is mapped and the > text buffer is resized at (apologies for accidentally sending) L3726, so if anything, I'd vote for their removal, not their canonicalization through config.[def.]h. -- Best regards, Alexander Sedov.
Re: [dev] [PATCH] Move default rows, cols to config.def.h
2014-06-25 1:51 GMT+04:00 Anders Eurenius : > Move default rows, cols to config.def.h > > Add default_cols, default_rows as static ints in the config.def.h > header, instead of using constants directly in the code. > > cheers > aes Greetings, is this really necessary? Default constants don't really mean anything, they persist literally until the window is mapped and the text buffer is resized at
Re: [dev] [PATCH] Fixed copying empty lines inside selection.
2014-05-26 9:23 GMT+04:00 Alexander : > The code was assuming that empty lines have implicit wrap-around attribute. Was this issue considered a bug after all? -- Best regards, Alexander Sedov.
Re: [dev] [st] Blank lines not preserved
2014-05-26 19:36 GMT+04:00 FRIGN : > On Mon, 26 May 2014 18:42:50 +0400 > "Alexander S." wrote: > >> Well, for low colours, you did? Correct me if I'm wrong. > > Read this first: http://lists.suckless.org/dev/1405/21569.html > > The point is: We can't mess with the high colors (i.e. > 256-colour-space/grayscale), especially not when our gamma-scaling is > messed up. Sorry, overlooked it. Fair points.
Re: [dev] [st] Blank lines not preserved
2014-05-26 17:25 GMT+04:00 FRIGN : > On Mon, 26 May 2014 09:00:01 +0400 > "Alexander S." wrote: > >> Guys, stop derailing the thread, please. If the issue concerns you, >> answer in the original thread to a solution I proposed. > > http://git.suckless.org/st/commit/?id=3544e354b2dcdfcced1a2f4aeedb4d479abd543c > > I already fixed this issue. So there's no point in discussing it anyway. Well, for low colours, you did? Correct me if I'm wrong. -- Best regards, Alexander Sedov.
Re: [dev] [st] Blank lines not preserved
2014-05-21 22:40 GMT+04:00 Eric Pruitt : > When copying text from st, all intermittent blank lines get removed. For > example, if I run "printf 'XXX\n\n\nXXX\n'" then copy and paste the > printed text, I get: > > XXX > XXX > > Instead the expected: > > XXX > > > XXX This is most assuredly a bug. It was a past behaviour, then it got fixed in http://git.suckless.org/st/commit/st.c?id=e5ff746430725b05e223c454febbde949df2fde2 but somehow creeped back in. The bug was reintroduced in http://git.suckless.org/st/commit/st.c?id=eeae9b0ceef9e2fec4cb4f1132748c302e5ac702 , which fixed a core crash on OpenBSD. The correct behaviour would, of course, be to assume that a non-existent character doesn't have wrap, as opposed to does. -- Best regards, Alexaner Sedov.
Re: [dev] [st] Blank lines not preserved
2014-05-22 23:52 GMT+04:00 Roberto E. Vargas Caballero : >> I'm curious what non-st terminal emulator you use. On Urxvt, my all >> colors beyond #16 look the same as in Xterm without any changes to my >> Xresources file or the need to recompile Urxvt. Likewise for MinTTY and >> its parent PuTTY. You can even see a comparison of Urxvt and Xterm's 256 > > In POSIX systems I only use st, but I have to use another systems (some of > them a bit legacy) where I use another terminals. > > -- > Roberto E. Vargas Caballero > Guys, stop derailing the thread, please. If the issue concerns you, answer in the original thread to a solution I proposed.
Re: [dev] [st] [PATCH] Refactor xsetcolorname()
2014-05-25 14:23 GMT+04:00 FRIGN :
> Hello,
>
> attached is a small patch to refactor xsetcolorname().
> Note the high similarity to xloadcols(). I wonder how necessary it is
> to realloc if name==NULL, given dc.col[] is only read except in
> xloadcols(), where exactly the same stuff is done to each array-item as
> repeated in xsetcolorname().
>
> If I'm wrong, let me know. If not, we could skip the entire if(!
> name)-part.
>
> Cheers
>
> FRIGN
Hello FRIGN,
this function implements STR command for changing a palette. Empty
name specifically tells to revert to system color, thus, if(!name)
clause is there for restoring a color that may have been changed using
the same procedure.
Here:
> if(BETWEEN(x, 16, 6*6*6+16)) { /* 256 colour */
you forgot -1. Don't forget BETWEEN() is inclusive on both ends.
However, the removal of extra stack variable and some additional
comments are very nice. I wholeheartedly approve of them.
Your concern about repetitiveness is valid and bothered me when I
wrote that function, although back then xloadcols() was in much poorer
state. By now, we may as well reimplement xloadcols() in terms of
xsetcolorname(i, NULL). I'd be glad if you did this, as unfortunately,
I do not have access to development environment right now.
--
Best regards, Alexander Sedov.
Re: [dev] [st] Colors slightly different hue than in xterm
2014-05-22 1:57 GMT+04:00 Roberto E. Vargas Caballero :
>> Read this: http://www.4p8.com/eric.brasseur/gamma.html
>>
>> We need to generally re-think the algorithm used here. I hate the idea
>> of being conformant to this or that terminal emulator and instead
>> prefer an implementation according to how it's defined (!).
>
> I like this idea, but I don't know how it could be implemented.
The obvious idea is to convert a colour to HSV/HSL, increase
brightness, and convert it back
(One cannot help but notice that such a calculation is a matter of
initialization, since appropriate bright colours may be calculated for
all built-in colours in advance. Therefore, one possible solution may
be to modify dc.col (also xloadcols and xsetcolorname) to have
structures, containing normal and bold variants for a colour.)
After this point, dragons lie.
In HSV model, there are notions of Value, which is equal to maximum
among colors, and Saturation, which is 1 - Max/Min. Thus, Max = V, Min
= V (1 - S).
Then,
R = r * Max + (1 - r) * Min = V * (r + (1 - r) * (1 - S)),
G = g * Max + (1 - g) * Min = ..., and so on, and r, g, b depend only
on Hue. It is then trivial to see that a change in Brightness is a
trivial rescale: R_{new} = V_{new} * R_{old}/V_{old}. (In linear
space, not gamma space.) It's a simple calculation indeed, but, as
XTerm cube contains a lot of colours close to pure, it may not look
appropriate.
In HSL model, there are notions of Saturation and Lightness.
Saturation is calculated as (Max - Min)/(1 - |1 - (Max + Min)|), and
Lightness as (Max + Min)/2. Thus, reverse calculations of Max and Min
are a little more involved, but the general truth remains the same:
all colour components are convex combinations between Max and Min,
whose coefficients depend only on Hue.
Thus, for R coordinate for example, R_{new} = (R_{old} - Min_{old}) /
(Max_{old} - Min_{old}) * (Max_{new} - Min_{new}) + Min_{new}. It's
the same rescaling but with two points instead of one.
(I cannot emphanise enough that we DO NOT need luminance or perceived
brightness here. These define the brightness of all colours to come
common reference point, whereas lightness/value define brightness
relative to a reference color of the same hue. Which is exactly what
we need. Default colors are of different brightnesses, and this is not
our concern.)
Let us now estimate how precise should we be in our tables of sRGB <->
linear conversion. Let's say that, for the simplicity, we use the
evenly-spaced table and linear interpolation. (Dreadful.) The error is
estimated thus by h^2 * 1/8 max(f''(x)). for sRGB->linear, the
constant is 3.429/8 = 0.428. Let's say we want the precision of 2e-16,
which is totally reasonable considering that we use 16-bit color
model. And I might say, is ain't so bad! We merely need ~170 data
points. Let's go big and make it 257. (Then, the index for a 16-bit
integer is just number>>8.)
As for the reverse transofrmation, there we experience a big uprise
around zero. In fact, the second derivative peaks at ~-2300, which is
indeed true: the function curves a lot there, and interpolating it is
the world of trouble, requiring ~4300 points, which is distressingly
only slightly more than 4096. Makes things even worse.
Fortunately, we happen to know the reverse function for this one,
which is not only pretty smooth - but we also have a table for it! So
the task results in binary search in aforementioned table (of size
257, I might remind you, so it's more or less instant) and doing a
linear interpolation afterwards. Slower, but saves us a lot of
trouble!
Thus, the proposal requires addition of:
- the table of 16-bit integers of size 257;
- the function of interpolating y given x1, x2, y1, y2 and x;
- the function of increasing a given color's brightness;
- possibly changes to dc.col, depending on how costly it will be to do
such calculations on the fly vs in the initialization.
--
Best regards,
Alexander Sedov.
Re: [dev] [tabbed] [PATCH] Remove unnecessary xargs call.
2014-04-09 22:02 GMT+04:00 Alexander S. : > 2014-04-08 1:14 GMT+04:00 Markus Teich : >> The removed call can stop the pipeline from working, if one adds e.g. his >> history to the possible selections and the amount of entries gets too big. > Sorry, but this call is necessary if the property in question contains > non-ASCII characters. It's not unnecessary. Unless you can solve the > problem by other means, please don't break existing code. > Best regards, Alexander, the introducer of this xargs call. Oh wait, I actually introduced it into surf's SETPROP, but this one was probably copied from there. The point stands. For detailed explanation, see http://git.suckless.org/surf/commit/config.def.h?id=f6dc8b25418e541f7d7b9c3ce63c763918a15d90 http://git.suckless.org/surf/commit/config.def.h?id=e0e4a844f76311f4bfed542d34459dcfc68f9ddf Best regards, Alexander.
Re: [dev] [tabbed] [PATCH] Remove unnecessary xargs call.
2014-04-08 1:14 GMT+04:00 Markus Teich : > The removed call can stop the pipeline from working, if one adds e.g. his > history to the possible selections and the amount of entries gets too big. Sorry, but this call is necessary if the property in question contains non-ASCII characters. It's not unnecessary. Unless you can solve the problem by other means, please don't break existing code. Best regards, Alexander, the introducer of this xargs call.
Re: [dev][announce] slm - music curation
2013/11/28 Markus Teich : > Patrick wrote: >> An example use-case shows why you would rm a file in your central media >> repository. .e.g. It was rm'd because it was Thursday and that's the day that >> I let Chaos Monkey fuck up my tunes. > > I for example see my music collection not as only-growing but also delete > stuff > I don't want to hear anymore regularly. > The consensus solution: 1) hardlinks, 2) delete them when inode link count drops to one.
Re: [dev] [st] Colors slightly different hue than in xterm
2013/12/3 Alexander S. : > Hello, > it seems that st uses one of color-cube colors to introduce bold > brightening. Clearly, for a color in xterm color cube, there is almost > never a color with the same hue, but another lightness. Probably > modifying color components, like with ATTR_INVERSE, would be better? Err, MODE_REVERSE, of course.
Re: [dev] [st] Colors slightly different hue than in xterm
2013/12/2 Eric Pruitt : > On Mon, Dec 02, 2013 at 10:54:54AM +0100, Christoph Lohmann wrote: >> No, fix xterm to brighten all colors. I won’t reduce the features of st >> because of compatibility to a sloc beast. > > I'm not asking you to apply the patch to tip, I'm simply posting the > patch for other people that may also like their existing color scheme to > remain unchanged. That said, I don't really think the current method of > "increase the color number" actually guarantees the replacement color > will actually be brighter outside the grayscale range, and on my > monitor, the change in color by brightening them is too drastic for me > to consider many of the replacements the same color as the unadulterated > values; in the screenshot I posted, what was once green became yellow, > and what was once blue purple. Although colors are a very subjective > thing, perhaps a more sophisticated method could be used to brighten > colors that makes this less of an issue. > > Eric Hello, it seems that st uses one of color-cube colors to introduce bold brightening. Clearly, for a color in xterm color cube, there is almost never a color with the same hue, but another lightness. Probably modifying color components, like with ATTR_INVERSE, would be better? -- Best regards, Alexander.
Re: [dev] [st] st does not show window name for wmctrl
2013/11/25 Carlos Torres : >> 2013/11/25 Martti Kühne : >>> How many people commit suicide per year because their application >>> windows use utf-8 titles? >>> > > I submitted another "simpler patch" that doesn't revert the setting of > WM_NAME to XStringStyle. Since i don't really have a use case for > UTF8. > > The simpler patch only adds _NET_WM_NAME, and as > UTF8_STRING for consistency. which wmctrl works with. (not that this > fix is solely driven by wmctrl. i wouldn't want it to, i just happend > to test this on an old st and noticed the difference). > > On 11/25/13, Alexander S. wrote: >> Is it definitely okay to use Xutf8TextListToTextProperty with XStringStyle? >> > > i didn't think about that to be honest, but i did think about the flame > possibly ignited by breaking the peoples st title when they use utf8... > Well, st once couldn't handle "umlauts" (as in, all utf-8) in title, which was very frustrating to use with... well, any window manager (I managed to configure dwm for itf-8 without using xft), and easy enough to fix. I get to use utf-8 quite often. I am ambivalent about not setting WM_NAME at all. This is a standard thing to set. This is a thing on which DWM can match windows, if I'm not mixing anything up. -- Best regards, Alexander.
Re: [dev] [st] st does not show window name for wmctrl
2013/11/25 Martti Kühne : > On Fri, Nov 22, 2013 at 5:06 PM, Carlos Torres wrote: >> The attached patch reverts to setting WM_NAME to STRING >> and adds _NET_WM_NAME in UTF8_STRING >> > > > How many people commit suicide per year because their application > windows use utf-8 titles? > Why would they? Just writing in because I was the one responsible for the change. Sorry, never was thinking that some program cannot handle UTF8String style. Is it definitely okay to use Xutf8TextListToTextProperty with XStringStyle?
Re: [dev] [dwm] Xft patch
Hello, 2013/11/23 : > For my personal use of dwm I have written a small > patch to support Xft---it actually decreases the > line count of dwm. I thought it would be useful > to share it with you. > > You will also notice that the patch changes the > window creation semantics. This is because I > wanted new windows to appear close the currently > focused one. Not systematically in the master > area. Please try to break patches down to atomic changes relevant to each other. -- Best regards, Alexander.
Re: [dev] [st] why is Glyph.fg, Glyph.bg long?
2013/11/13 Thorsten Glaser : > Roberto E. Vargas Caballero dixit: > >>long, because long is at least 32 bits for sure, but int can be only 16 > > On POSIX, int is a minimum 32 bit data type. Also, stdint.h. -- At your service, Alexander S.
Re: [dev] Suckless remote shell?
2013/11/8 Szabolcs Nagy : > * Alexander S. [2013-11-08 02:10:49 +0400]: >> 2013/11/7 Szabolcs Nagy : >> > with a single pointer arg this assumes that all pointers have >> > the same representation or that you create a separate version >> > of pthread_create for every type used >> Pthread_create doesn't need to know anything about the type of the >> pointer! In fact, nobody except the typechecker needs to. > > if different pointers have different representations > then the caller needs to know that at runtime to pass > the argument to the callback > >> Runtime information is only needed if you are going to actually >> introspect that arbitrary number of args. If you are going to plop >> them back onto the stack, the only thing you need to know is a total >> size, which can be calculated in compile time. > > that's not how the function call abi works > > and what you describe can be done now in c without the syntax: > allocate a char array on the stack serialize everything into it, > and pass the pointer and size > > you don't get typesafety, but that cannot be done in general > accross a serialize/deserialize step, you could only type > check a few special case of that at best.. by making things > more complicated There seems to be some misunderstanding about what is type-safety and when checks are made. They are actually made when you are calling a function with signature described above. I used higher-order lambda to express the notion that, for example, an extra argument in pthread_create is the same type as the only argument to its entry point. To the *implementation*, these are just opaque pointers. We don't get our typechecking by substituting templates and checking that calls don't violate the rules; something more beautiful is going on here. (C++ templates don't support type lambdas, sadly). >> expansion C varargs undergo. But, I suppose, asking that all arguments >> be either floating-point or pointer-size isn't asking too much. It is >> doable. > > the size is not all > > there are function pointers, structures with alignment requirements, > paddings and bitfields, some implementations support more than three > different floating-point types.. > > in the end you either have runtime type information to be able to > unpack the arguments and construct calls with them or you have what > c has now Structures are usually passed by pointer anyway if they don't fit in 64-bit register, I believe? Of course, you can do serialization by hand; but that way, you get it exactly right in one line looking almost like a call. And a free type-checking! (See above about why it's compile-type and why implementation doesn't need to care about it). But yeah, there is probably not much point in such varargs without runtime information. They cannot even be used for printf or alike.
Re: [dev] Suckless remote shell?
2013/11/7 Szabolcs Nagy : > * Alexander S. [2013-11-07 16:55:35 +0400]: >> Context pointers for callbacks... well, they exist because of the >> limitations of the type system. I'd rather see >> ?A,[Types...].pthread_create(pthread_t*, A(*callback)(Types...), Types >> args...) (so, arbitrarily many additional args for callbacks). A >> type-checker can properly check it, and even in current calling >> conventions, it's quite fast to handle: you just copy a chunk of >> memory fro and to stack, wholesale. Failing that, there's always >> ?A,B.pthread_create(pthread_t*, A(*callback)(B), B arg). > > with a single pointer arg this assumes that all pointers have > the same representation or that you create a separate version > of pthread_create for every type used Pthread_create doesn't need to know anything about the type of the pointer! In fact, nobody except the typechecker needs to. > arbitrary number of args does not work: you need runtime type > information for that (which is complex, slow and problematic > to define the binary interface), var arg calls are not just > passing a chunk of memory on the stack (would be suboptimal > on archs like x86_64 with lot of registers) Runtime information is only needed if you are going to actually introspect that arbitrary number of args. If you are going to plop them back onto the stack, the only thing you need to know is a total size, which can be calculated in compile time. As for amd64, I didn't mention it because that's, really, details. va_list implementation solves the problem of native 64-bit calling convention; surely we can, too. The only difficulty is the size of arguments that need to be copied to and fro stack, and sadly, not every widely-used type is the same width, even after standard expansion C varargs undergo. But, I suppose, asking that all arguments be either floating-point or pointer-size isn't asking too much. It is doable. >> mmap is another matter, but whether for turning file into RAM or for >> IPC, it tends to have some structure, I guess? > > you can allocate memory with mmap and reuse it several times for > different type of objects or you may need to parse the mmaped > data so you don't know static types Parsing is usually done with the stream (especially if you don't know static types), but I suppose there are some use cases which include random access AND heterogenous data. Well, not everything can be perfect; that's what explicit casts are for.
Re: [dev] Suckless remote shell?
2013/11/7 Szabolcs Nagy : > * Alexander S. [2013-11-07 04:27:26 +0400]: >> Seriously, simple parametric types wouldn't hurt C. Not at all. No >> need for that automatic pointer conversion, additional parameters to >> sort() and alike, and such. (I'm going to make a confession, I really >> think C would benefit from C++ templates, even in their current >> state). > > c has no implicit pointer conversion other than for void* > > void* is important to represent pointers in a generic way, > parametric types do not help with this, those assume a > statically known type which is not always the case > > the way c++ eliminated the implicit conversion is actually > less safe than the c semantics: in c++ one has to use casts > to convert void* and this turns off the type-checker > > there are plenty source for void pointers: mmap, dlsym, > context pointers for callbacks, etc. if you incorrectly > assume in c that a pointer is void* then you get a type error, > in c++ your cast will mask this error so it can go unnoticed, > in c a cast is a code smell that alarms you, in c++ they are > not uncommon at all in code interacting with the os, actually > c++ has at least 4 different casts with different semantics > based on what you cast, this is not how to improve safety Well, in code interacting with low-level you are probably going to meet just static_cast<>, which is everywhere, and reinterpret_cast<>, that's reserved for casting pointers. I can argue about necessity of these four types of casts (dynamic_cast<> is quite important for safety, imo). Context pointers for callbacks... well, they exist because of the limitations of the type system. I'd rather see ЛA,[Types...].pthread_create(pthread_t*, A(*callback)(Types...), Types args...) (so, arbitrarily many additional args for callbacks). A type-checker can properly check it, and even in current calling conventions, it's quite fast to handle: you just copy a chunk of memory fro and to stack, wholesale. Failing that, there's always ЛA,B.pthread_create(pthread_t*, A(*callback)(B), B arg). mmap is another matter, but whether for turning file into RAM or for IPC, it tends to have some structure, I guess? > parametric types have problems on their own: eg the type > parameters have to be encoded into the name of the interface > which gives rise to name mangling with all its warts > (c++ name mangling is not specified so you get a fragile binary > interface with names so long that the hash lookups by the elf > dynamic loader becomes a bottleneck..) -- Best regards, Alexander S.
Re: [dev] Suckless remote shell?
2013/11/6 Dmitrij D. Czarkoff : > 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. There were wonderful times when any language that had "while" at its disposal was known as high-level one. If by "representation of hardware properties" you mean "providing an easy way to really mess things up", then, yes, such a type system would be necessary for representing hardware properties. (Today I met people, they were so confused, that they were writing stuff like `*(pointer + i * sizeof(int))`, where `pointer` was, of course, int * variable). Seriously, simple parametric types wouldn't hurt C. Not at all. No need for that automatic pointer conversion, additional parameters to sort() and alike, and such. (I'm going to make a confession, I really think C would benefit from C++ templates, even in their current state). -- Have a nice evening, Alexander S.
Re: [dev] Suckless remote shell?
2013/11/5 Markus Wichmann : >> if something was invented in the era of insufficient computing power, >> it does make it more clunky to use. > True. C's dynamic memory management is proof of that. Yes, and I believe they got it about right in Go. (They got it mathematically right in Rust, but using that requires you to understand their papers). >> Being old isn't what makes C old; > Yes it does! But it doesn't make C bad. Yeah, I indeed meant to say "bad". >> the "1001 C Gotcha" lists are about what makes it bad. > Apparently, the existence of such lists is the sign of a good > programming language, because they don't exist for languages that don't > allow enough leeway to do much wrong - so are unusable - or that no-one > uses long enough to find pitfalls - so are evidently unusable. Huh. That's an interesting and decent point of view. >> The ugly hacks >> like longjmp and varargs make it bad. > longjmp() is kinda hacky, granted (for instance, setjmp() can only be > used portably in a small number of contexts), but varargs? What's bad > bout them? They have zero type-checking (which is more or less normal for C), and you have to use sentinels or counts even to know the number of arguments. gcc has special support for format strings and sentinels. When compiler authors have to support commonly-used crunches, you know something has gone >> C++ would be a much more decent >> language if it didn't build on C syntax. > C++ is broken in about every way, and it all comes back to exactly this > point. C is simply a very bad language to base OOP on. But, to be fair, > C++ managed to fuck up magnificently in its own right (Overcomplex > language spec, fucking with C programmers by removing the implicit > conversion from void* to every other pointer and vice versa, lack of GC, > making it hard to use a GC,...) 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.
Re: [dev] Suckless remote shell?
2013/11/4 Szabolcs Nagy : > * Alexander S. [2013-11-04 17:11:40 +0300]: > > the state-of-the-artedness is not a virtue of a programming language > > the main problem with go is that (like java and many other high level > languages) it tries to ignore unix legacy while building on it > > go cannot completely replace the c ecosystem in the unix userspace > because of its runtime (gc etc) so we are left with yet another set > of reimplementation of the world, a separate platform to maintain > for eternity Thanks for the answer! i see your point and I feel more educated now.
Re: [dev] Suckless remote shell?
2013/11/4 Raimundo Martins : > On Mon, 4 Nov 2013 17:11:40 +0300 > "Alexander S." wrote: > >> Don't want to start a flame, but C isn't exactly state of the art >> language. I shall agree that Go has problems, but why it would be a >> disgrace any worse than a living fossil C is? > > So being old implies it's bad? That's the kind of thinking that makes > people try to reinvent something that is already good and then ruin it. > We could land a man on the moon with 4K ram, but we can't run a > formatted text editor which complies with most standards without 100MB. > > Most e-mail now contains html because someone thought there was a need > to make them pretty. Now you need a whole graphical interface just to > read a stupid email from some institution or corporation which thinks > that they must "modernize". And even then.. > > Not saying that C is the holy god of all languages and everything > should be in C. Everything has a purpose. > Being old doesn't make it bad! if something was invented in the era of insufficient computing power, it does make it more clunky to use. Being old isn't what makes C old; the "1001 C Gotcha" lists are about what makes it bad. The ugly hacks like longjmp and varargs make it bad. C++ would be a much more decent language if it didn't build on C syntax.
Re: [dev] Suckless remote shell?
2013/11/4 FRIGN : > On Sun, 3 Nov 2013 18:57:23 -0500 > Jacob Todd wrote: > >> No one ever said it had to be in c you fucking nerd. > > No one ever said it, because it is expected to be in C. > Go is a disgrace and I'm glad every time I see a Go-Project bit-rot to > death. > > Best Regards > > FRIGN, a fucking nerd. Don't want to start a flame, but C isn't exactly state of the art language. I shall agree that Go has problems, but why it would be a disgrace any worse than a living fossil C is?
Re: [dev] Some thoughts about XML
2013/10/24 Bobby Powers : > I think Russ Cox said it very well[1]: > > Mapping between XML elements and data structures is inherently flawed: > an XML element is an order-dependent collection of anonymous values, > while a data structure is an order-independent collection of named > values. See [...] json for a textual representation more suitable to > data structures. > > 1 - http://tip.golang.org/src/pkg/encoding/xml/read.go?s=257:579#L7 Yeah. For documents, XML suits more, because (reading) order usually matters and "names" are given through elements like captions.
Re: [dev] Some thoughts about XML
2013/10/24 Charlie Kester : > So don't use it as a markup language. > > As far as I know, it was never claimed to be fit for that purpose. Um. 2013/10/23 Mihail Zenkov : > It not mention good xml alternative: TOML > https://github.com/mojombo/toml 1) TOML is basically .ini on steroids, 2) XML is a markup language, 3) anything that claims to be "xml alternative" ought to be a markup language. Personally, I'm okay with XML, and feel like Archangel Uriel, may he rest in peace, was slightly exaggerating. XSLT may be horrid, though, and XML is maybe *too* verbose, but the idea of having a structure as a building block is totally okay with me. There is expat parser, and who needs anything else. Using XML for simple, non-hierarchical config files is just plain wrong, not because XML is bad, but because it is misapplied. Using XML for storing Rhythmbox music database is wrong for the same reason. XML is for documents.
Re: [dev] Some thoughts about XML
2013/10/24 Samuel Holland : > [body] > content="%ol%%p%" > [ol] > style="list-style-type: decimal" > content="%li.1%%li.2%%li.3" > [li] > style="display: list-item" > content1="Lack of proper hierarchy, for one;" > content2="Lack of proper heterogeneous containers, for two;" > content3="%b%:\nlack of multiline strings." > [b] > style="font-weight: bold" > content="The most important one" > [p] > style="display: block" > content="Try to express something as simple as %i% (which is\nrather trivial > HTML snippet) in .ini format." > [i] > style="font-style: italic" > content="my answer" I didn't say it was impossible, mind you. I just said it would be the opposite of okay. Thanks for clearly demonstating my point :).
Re: [dev] Some thoughts about XML
2013/10/24 Mihail Zenkov : > 2013/10/23, Alexander S. : >>> I'm confused as to what is wrong with the .ini style configurations. >>> They're not just used in Windows, they're used in many other places that >>> require simple, easy to use configurations. Python uses it, there are C >>> api's for it, etc. >>> >>> So what problem do you have with a .ini file? >> They are okay for simple config files. They are the opposite of okay >> for a markup language. > > Why? Lack of proper hierarchy, for one; Lack of proper heterogenous containers, for two; The most important one: lack of multiline strings. Try to express something as simple as my answer (which is rather trivial HTML snippet) in .ini format.
Re: [dev] Some thoughts about XML
2013/10/24 William Giokas <1007...@gmail.com>: > On Tue, Oct 22, 2013 at 10:35:03PM +, Thorsten Glaser wrote: >> Mihail Zenkov dixit: >> >> >It not mention good xml alternative: TOML >> >> Thank gods the time of Windows 3.x *.ini files is long gone. > > I'm confused as to what is wrong with the .ini style configurations. > They're not just used in Windows, they're used in many other places that > require simple, easy to use configurations. Python uses it, there are C > api's for it, etc. > > So what problem do you have with a .ini file? They are okay for simple config files. They are the opposite of okay for a markup language.
Re: [dev] Some thoughts about XML
2013/10/23 Mihail Zenkov : > 2013/10/21, hiro <23h...@gmail.com>: >> It seems like some subscribers haven't read the bible of suckless yet. >> http://harmful.cat-v.org/software/ >> and >> http://harmful.cat-v.org/software/xml/ > > It not mention good xml alternative: TOML > https://github.com/mojombo/toml > no multiline strings > obscure syntax for declaring hashes > when I change hash top name, I need to change all that are nested Heck, even Python ConfigObj would be nicer to use for documents. How will you type texts in *this*? \n all the way?
Re: [dev] [st] [patch] Cleanup config.def.h, eliminate mappedkeys, simplify matching.
2013/10/19 Mark Edgar :
> A series of patches for consideration.
>
> The first patch is purely aesthetic: it cleans up column headings (comments)
> and internal tabs in the shortcuts/key/mshortcuts tables in config.def.h. It
> also renames the fields in Key to match the nicer names given in
> config.def.h.
>
> The second patch removes the mappedkeys[] optimization. I tested this by
> adding 1.000.000 additional entries to the end of key[]:
>
> static Key key[] = {
> ...
> #include "lots"
> /*
> * "lots" contains 999.999 repetitions of this entry, which is crafted
> * to hit all the tests in kmap() and fail the last:
> * { 'x', XK_ANY_MOD, "nope", .keypad=-1, .cursor=-1, .crlf=1 },
> */
> { 'x', XK_NO_MOD, "exit" },
> };
>
> While gcc goes from a few seconds to more than a minute to compile and link
> the above, I could not detect a performance regression in st. ;)
>
> The third patch simplifies the matching logic in kmap() and match() without
> changing the behavior. Hopefully, it is straightforward, but it probably
> deserves a careful reading to make sure I haven't made any mistakes.
Why removing mappedkeys? Sure, there may be no visible regression, but
checking every keypress against key bindings seems unreasonable to me.
As for the last patch: it seems to me that behaviour is unchanged.
However, I do not like using != as a logical operator. I'd suggest
using (IS_SET(MODE_APPKEYPAD) ? kp->keypad < 0 : kp->keypad > 0),
which is about the same length, but a bit more clear. I'd also suggest
following the same pattern for all three clauses, as nested if() is
unnecessary (clearly, kp->keypad == 2 may evaluate to true only if
kp->keypad is nonzero).
Re: [dev] [sbase] Command list
Contributing into the discussion about find.
Most of its selectors are implemented by stest(1); commonly useful
ones that I can think of are -user and -group. However:
1) ostracize me, but I like find "one dash, long option" style way
more than stest "a thousand of letters a-la test". I understand the
test(1) legacy here, I just say that it wouldn't be very pleasant to
consult with manual each time I'm trying to write a command.
2) there is no way to express intersection, union and negation of a
test. They are mostly irrelevant for test(1), but here we ought to
have at least disjunction, because making temporary lists and merging
them with sort -u or comm(1) is unpleasant to say the least. (Also,
slow). Theoretically speaking, every logical expression can be
represented in conjunctive normal form, so providing support for
negation and union and using multiple commands & pipes as intersection
("| stest test1 | stest test2") should be enough, but in some cases,
unpleasant too.
3) we need a program that can print a directory tree well, with
-mindepth, -maxdepth, and sorted/unsorted options.
4) we need some standard way to separate file names in a stream.
Basically, ^@ is our only refuge, because path can contain any other
character. But maybe newline is good enough?
5) we need a program that can take input and convert into a
commandline. So, xargs (but of course without space-separation
quotation nonsense. Not once nor twice had I written the glorious "tr
'\n' '\0' | xargs -0" to turn it off). I suppose most of POSIX options
are worth keeping.
So, the former "find" command would be like
ptree -maxdepth 2 | ftest "( perm 111 || newer ./reference ) && user
root" | xargs rm
I feel that going the awk way (e. g. inventing the mini-language and
passing expression as one string) is better than find way, with -a and
-o and escaped parens.
--
Best regards, Alexander.
Re: [dev] Some thoughts about XML
2013/10/18 Dmitrij D. Czarkoff : > Szymon Olewniczak said: >> Another advantage of XML is its adaptation. We've already have MathML, >> SVG and many many others[1] all build on top of XML. > > SVG and MathML are probably the best arguments against XML ever. I am yet to > see two SVG libraries that would render sufficiently complex spec-complient > SVG equally. And I have no hope for seeing any spec-complient SVG rendering > library ever. > > MathML is yet worse. To save words: http://aiju.de/rant/XML/MathML I'd not agree that SVG render problems are due to XML parsing. I think it's just that anything that attempts to draw SVG according to a spec must be *very* capable, with all those filters and transforms and animations and ecmascripts. It might as well be a TeX extension, and we would have the same (actually, probably even more) problems.
Re: [dev][dwm] Launching new terminals in $PWD
2013/10/18 Raphaël Proust :
> On Fri, Oct 18, 2013 at 11:28 AM, Manolo Martínez
> wrote:
>> On 10/18/13 at 06:12pm, Chris Down wrote:
>>> On 2013-10-18 12:03, Manolo Martínez wrote:
>>> Environments only propagate to children, not their parents. You'll need to
>>> get
>>> the pwd of the currently focussed window if you want to do that.
>>>
>>
>> You meant "the pwd of the children of the currently focused window",
>> right? I've just seen that the pwd of urxvt is always my home directory,
>> even if the pwd of the shell process running in it is not. This is all
>> pretty arcane to me.
>
> AFAIU: if you `cd` in urxvt, the pwd of the urxvt process will change.
> If you `vim` and then `:cd` then pwd of the urxvt process will not
> change (i.e. the parent process (urxvt) keeps its pwd, while the child
> process (vim) will have a new pwd).
The "parent process" is shell, not the terminal. Terminal needs
explicit support to keep its pwd consistent with its shell's.
By the way, pwdx can be replaced by readlink("/proc//cwd").
Re: [dev] Tabbed status?
2013/10/10 Christoph Lohmann <2...@r-36.net>: > Greetings. > I tried a simple > > rppick :from alex0player :subject tabbed > rpview p | git am --signoff > > This gave back the whole e‐mails. Then it took your first comment and > all the diffs. They are all in the last patch. I will have to write some > rpgit utility. Ah, makes sense. I can confirm that the resulting patch was successfully picked up with git-rebase and contains exactly intended changes. The comment is a little misleading, though. -- Best regards, Alexander.
Re: [dev] Tabbed status?
2013/10/10 Christoph Lohmann <2...@r-36.net>: > Greetings. > Your patches have been applied. Sorry for the latency. Thanks for the > contribution! Sorry for nagging you, but what about the last one, that fixes selecting tabs with mouse? Should I resend this one? -- Best regards, Alexander.
Re: [dev] Re: [st] [PATCH] Avoid buffer overflows in the case of key-mapped strings.
2013/10/9 Roberto E. Vargas Caballero : > I think we shouldn't check this kind of things, because otherwise > we must check all the parameters from config.h, and it is not done now. > I usually check all the parameters which come from the user, and trust > parameters from the own code, because they are my responsability (or in > this case, is responsability of the user who modified config.h) It's runtime segfault (that may be rare and hard to catch) that is worth exactly one additional check.
[dev] Tabbed status?
Hello, who happens to be tabbed (1) maintainer? I sent some patches over a period of time but it seems that they were not reviewed. -- Best regards, Alexander.
Re: [dev] [sbase] [PATCH] ls: add option to reverse the sort order
2013/10/5 Rob : > On Fri, Oct 04, 2013 at 05:45:56PM +0400, Alexander S. wrote: >> 2013/10/4 Raphaël Proust : >> If we want to retain this patch, I'd suggest reversing array after >> sorting, not multiplying by `sortorder' in comparison functions. This >> avoids code duplication. > > I disagree - rather than adding a sort call and changing the program's > runtime complexity, can't we just reduce the amount of lines _and_ > duplication like this: Reversing an array we just sorted isn't adding complexity, it's O(n) adding to O(n log n).
Re: [dev] [sbase] [PATCH] ls: add option to reverse the sort order
2013/10/4 Raphaël Proust : > On Fri, Oct 4, 2013 at 2:32 PM, Alexander S. wrote: >> Uh, cannot this be achieved by piping output to tac? > > At which points someone asks why is there a sorted order at all in ls > output… cannot this be achieved by piping output to sort? sort(1) can only sort by name, which is clearly less powerful than we want. So no, we cannot. If we want to retain this patch, I'd suggest reversing array after sorting, not multiplying by `sortorder' in comparison functions. This avoids code duplication.
Re: [dev] [sbase] [PATCH] ls: add option to reverse the sort order
Uh, cannot this be achieved by piping output to tac?
Re: [dev] Re: [st] [PATCH] Avoid buffer overflows in the case of key-mapped strings.
2013/10/2 Mark Edgar :
> On Mon, 23 Sep 2013 10:06:13 +0200, Roberto E. Vargas Caballero wrote:
>> On Sat, Sep 21, 2013 at 03:41:01PM +0200, Mark Edgar wrote:
>> I don't agree here, because if you insert a escape sequence is not dificult
>> get more of 16 characters (for example a key combination which updates the
>> bar title).
>
> Yes, agreed.
>
>
>> > +#define STRNLEN(s) ((s)[LEN((s)) - 1] == '\0' ? strlen((s)) : LEN((s)))
>> This trick is only useful when you usually have strings with a size of
>> LEN(s)-1, but in our case we will usually have string with a small size,
>> so it means we always will add a new test before of calling to strlen.
>
> This test here was to ensure the string is NUL-terminated. With a
> 16-char length buffer, it's more likely that someone will accidentally
> use it all. In other words, this Key entry is legal, but strlen()
> can't handle it:
>
> static Key key[] = {
> { XK_F12, XK_NO_MOD, "0123456789012345" },
>
> With the current version of st, that string literal would have to be
> 512 characters long before overflow. This is unlikely, but still
> possible.
>
>
>> Could you explain what overflow are you fixing here?, because I only
>> can see you are returning the Key struct instead of returning directly
>> the char representation.
>
> There's actually two here: the strlen(customkey) I mentioned above,
> and the original memcpy(buf[32], customkey[512], len<512) call in
> kpress(). The following key entry will overflow buf[] in kpress() in
> the current version of st. If it doesn't go boom for you, try doubling
> the length of the string literal:
>
> static Key key[] = {
> { XK_F12, XK_NO_MOD, "01234567890123456789012345678901" },
>
>
> A much neater fix might be to make Key.s a char pointer instead. This
> also solves the question of what to use as the string length limit
> (should it be 16 or 32 or 512 -- well, how about unlimited?), avoids
> invalid strlen() calls (assuming config.h doesn't do anything too
> tricky), and entirely avoids the extra memcpy():
>
> --- a/st.c
> +++ b/st.c
> @@ -250,7 +250,7 @@ typedef struct {
> typedef struct {
> KeySym k;
> uint mask;
> - char s[ESC_BUF_SIZ];
> + char *s;
> /* three valued logic variables: 0 indifferent, 1 on, -1 off */
> signed char keypad; /* application keypad */
> signed char cursor; /* application cursor */
> @@ -3538,7 +3538,10 @@ kpress(XEvent *ev) {
> /* 2. custom keys from config.h */
> if((customkey = kmap(ksym, e->state))) {
> len = strlen(customkey);
> - memcpy(buf, customkey, len);
> + ttywrite(customkey, len);
> + if(IS_SET(MODE_ECHO))
> + techo(customkey, len);
> + return;
> /* 3. hardcoded (overrides X lookup) */
> } else {
> if(len == 0)
>
>
> What do you think?
>
>
> FYI: I have another patch which allows for keys to send the NUL byte
> to the tty, but I'm not really sure how generally useful it really is.
> It would look like this in config.h:
>
> static Key key[] = {
> { XK_F12, XK_NO_MOD, "\0", .len=1 },
>
> -Mark
>
Isn't there strnlen() function?
Re: [dev] [surf][patch] MODKEY + button 1 opens new window
2013/9/7 David Dufberg Tøttrup : > Hi! > > I don't have button 2 (and emulate 3 button mouse sucks). With this patch > you can open a new window if you hold MODKEY and click the link. Apply if it > makes sense. > > Sincerely, > David I want to thank you for this patch. I stumble on my old habits of Ctrl-clicking every now and then.
