Hello all! Josh Wilcox here.
I'm using gnu stow with the dwm source.
I noticed that, in the Makefile, the variable DESTDIR is incorporated into
path names before the variable PREFIX. I think that in most use-cases
DESTDIR is an empty variable and this does not matter.
For my installation I need dwm to install to /usr/local/stow/dwm, but I
want the compilation step to use the default /usr/local prefix.
If I change the order of DESTDIR and PREFIX in the Makefile install and
uninstall rules and then invoke:
`make DESTDIR=/stow/dwm install'
for the install step (prior to stowing) things work as I expect/desire.
I'm a bit of a novice so I'm concerned that this change may have
unforeseen consequences, which is what led to this post.
Thanks in advance for any comments, and thanks to this community for a
truly wonderful window manager.
--Josh
2010/8/22 <dev+help_AT_suckless.org <dev%2Bhelp_AT_suckless.org>>
> On Tue, Aug 17, 2010 at 07:54:44PM -0700, Suraj Kurapati wrote:
>
>> On Tue, Aug 17, 2010 at 8:40 AM, Alexander Teinum <ateinum_AT_gmail.com>
>> wrote:
>>
>>> What is the most concise way of outputting a usage and help text?
>>>
>>
>> For my programs, the --help option simply displays their manpage. :-)
>>
>> man(1) is better suited for information display (text-wrapping to 80
>> characters or $COLUMNS, pagination, and emphasis with bold, reverse
>> video, underline, etc.) than anything I could care to reinvent poorly
>> in each of my programs.
>>
>
> GNU man has the annoying and difficult to stop habit of filling the entire
> width of the terminal rather than wrapping at 80 chars. And if you set
> $MANWIDTH or $COLUMNS to 80 and the terminal isn't that wide, you wind up
> with badly broken wrapping. As for bold, fortunately my terminal has it
> disabled, and reverse video has no place in manual pages.
>
> By the way, this is the script I use to launch man. If anyone knows of
> something better (other than Plan 9 man which unfortunately can't handle
> system man pages), please tell me:
>
> #!/bin/rc
> *=`{stty size} {
> cols = $2
> }
>
> MANWIDTH=`{9 bc<<!}
> if($cols >= 72) print 72
> if($cols < 72) {
> if($cols >= 65) print 65
> if($cols < 65) print $cols
> }
> !
> exec /usr/bin/man $* | 9 tr − - | less
>
> --
> Kris Maglione
>
> He hoped and prayed that there wasn't an afterlife. Then he realized
> there was a contradiction involved here and merely hoped that there
> wasn't an afterlife.
> --Douglas Adams
>
>
> On Tue, Aug 17, 2010 at 8:27 PM, Kris Maglione <maglione.k_AT_gmail.com>
> wrote:
> > GNU man has the annoying and difficult to stop habit of filling the
> entire
> > width of the terminal rather than wrapping at 80 chars. And if you set
> > $MANWIDTH or $COLUMNS to 80 and the terminal isn't that wide, you wind up
> > with badly broken wrapping.
>
> Agreed. GNU man really should do something like CSS's "max-width: 80em".
>
> > As for bold, fortunately my terminal has it disabled,
>
> I set up nice colors for bold and underline so things are easy to read
> (see the attached screenshot). If anyone is interested, my Xdefaults
> file is here:
>
> http://github.com/sunaku/home/blob/master/.Xdefaults
>
> > and reverse video has no place in manual pages.
>
> Hehe, I went a little overboard there. :-)
>
> On Wed, Aug 18, 2010 at 2:36 AM, Alexander Teinum <ateinum_AT_gmail.com>
> wrote:
> > It would be a nice challenge to write a really small getopt()
> > replacement, and a program that generates usage text. Okay, how about…
> >
> > usage: program -a [-b] [-c] -f file blah blah blah
> >
> > -a Required. Must always be set.
> > -b Optional.
> > -c Optional.
> > -f file Required. file must always be a string.
> > blah blah blah I guess it’s up to the program to decide if this is
> > optional or required.
>
>
> "Required options". What an oxymoron.
>
>
> --
> @chickamade
>
> On Wed, Aug 18, 2010 at 1:11 AM, Ramana Kumar <ramana.kumar_AT_gmail.com>
> wrote:
> > I finally got st to build by just copying the st.info file to the
> > (missing) st-256color.info file.
>
> It builds but it doesn't add any new description. It will just
> overwrite the previous st description.
>
> > First things I noticed:
> > 1. Backspace doesn't work (nor does CTRL-H)
>
> That should be fixed when the info file is fixed.
>
> > 2. Unicode characters don't display properly (the one I noticed is ∀)
>
> There's no unicode support atm.
>
> > 3. This one is probably not your problem, but man and vim both
> > complain about the unrecognized terminal (but I should just set $TERM
> > to something else I guess).
>
> TERM is set to st-256colors and there's no description of its
> capabilities (= correct backspace keycode). Just change TERM to st or
> xterm but the emulation not quite ready yet for the latter; some
> things get messed up. But try it anyway, it might just work for you.
> You can change TERM directly in st.c. Maybe I should put that define
> in config.h...
>
> It's good to see some feedback on the list, I thought to no one was
> interested in the project :)
> I'm planning to write the current state of st on its page along with
> some information on what can be configured, etc.
>
> Suraj Kurapati dixit (2010-08-17, 20:49):
>
> > > As for bold, fortunately my terminal has it disabled,
> >
> > I set up nice colors for bold and underline so things are easy to read
> > (see the attached screenshot). If anyone is interested, my Xdefaults
> > file is here:
> >
> > http://github.com/sunaku/home/blob/master/.Xdefaults
>
> Strange thing is that my man doesn't get colorized (only bolded via
> brightening up) in X terminal emulators. In the linux console I get
> proper colors. Any hints how to enable coloring in X terminals?
>
> --
> [a]
>
> On Tue, Aug 17, 2010 at 08:07:05PM +0200, Alexander Teinum wrote:
> > > I think the best format for usage is something like what Plan 9
> > > utilities use (BSD use the same):
> > >
> > > usage: cmd [-abcde] [-f file] [-g pattern] [file ...]
> >
> > Options without values are combined? Is that correct?
>
> Yes. If you don't use getopt like most suckless projects then no.
>
> > > With these rules flo usage should be
> > >
> > > usage: flo [-c id] [-f from] [-r id] [-t to] [-w what]
> [what[,from][-to]]
> >
> > What if the values are of the same type? -c and -r have id as value.
> > -f and -t have date as value. I think your usage-text looks prettier,
> > but out of curiosity, can they be combined like this?
> >
> > usage: flo [-cr id] [-ft date] …
>
> Didn't see anything like that. Even when the types are same, options
> mean different things so they are listed like [-f from] [-t to]. crop
> utility from Plan 9 have two arguments that accept rgb colors and they
> are listed separately.
>
> > If I decide to ditch getopt(), then I’d like to be able to type “flo
> > -c -f” to clear the from-field, which means that -f and -t have
> > optional arguments. Is it valid for an option to have an optional
> > argument?
>
> No. If there is no argument but some option goes after it like
>
> flo -c -f -t
>
> then -t would become argument for -f. That way you always have to
> make sure that -f is the last argument or write parser that don't
> allow you to use -t as argument or something like this.
>
> Most unix utilities use getopt() so you can look at Plan 9 utilities
> for examples of man pages and usage. suckless.org utilities use their
> own simple parsers that don't allow you to group options with one '-'
> so they list their options like [-a] [-b] [-c]. If you write your own
> parser that allow optional arguments and strange things like this,
> then there can be no examples or guidelines.
>
> > I found some guidelines here:
> >
> >
> http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html#tag_12_01c
> >
> > Do you agree with the guidelines listed in 12.2? I’ll find a pen and a
> > paper and try to digest those.
>
> Disagree with Guideline 6. awk can accept both -Farg and -F arg. I
> think all options should be listed like '[-o arg]' but accept both
> -oarg or '-o arg'. For ssuckless projects they should be listed like
> '[-o arg]' and accept only '-o arg' form.
>
> Guideline 8 is strange. crop utility from Plan 9 have options that
> get 3 arguments and it is ok. But with GNU getopt it would fail
> because it move 2nd and 3rd arguments to the end so they become
> non-option arguments.
>
> Guideline 9 is like BSD getopt work. GNU getopt allow you to put
> options after arguments but I don't like it.
>
> I wonder why glibc developers put arguments sorting in getopt. It
> would be much better to place it in bash and enable only when runned
> in interactive mode. I use mksh anyway :-p
>
> Guideline 13 should be deprecated. It is not compatible with Plan 9
> cat and only leads to additional code complexity. Use /dev/stdin
> instead.
>
>
> On Tue, Aug 17, 2010 at 07:35:15PM +0100, Connor Lane Smith wrote:
> > Hey,
> >
> > > Options without values are combined? Is that correct?
> >
> > Can be. Though, many suckless projects don't accept this and use, eg,
> > strcmp(argv[i], "-sb"). A number of non-suckless programs are similar.
>
> Most default X11 programs are similar, because they use XrmParseCommand.
>
>
> On Tue, Aug 17, 2010 at 09:36:14PM +0200, Alexander Teinum wrote:
> > It would be a nice challenge to write a really small getopt()
> > replacement, and a program that generates usage text.
>
> Check getflags(8)[1], it parse options and generate usage messages for
> rc scripts.
>
> For C there are ARGBEGIN, ARGEND[2] and other macros. They don't
> generate usage, but they solve another problem of getopt(): you don't
> have to check that the string that you pass to getopt() lists all
> options that you accept in switch.
>
> [1] http://plan9.bell-labs.com/magic/man2html/8/getflags
> [2] http://plan9.bell-labs.com/magic/man2html/2/arg
>
>
> On Tue, Aug 17, 2010 at 06:52:40PM -0400, Ryan Mullen wrote:
> > Second, dmenu's "suggested" integration with surf is a bit dodgy. If,
> > for example, a user is viewing surf.suckless.org and they wish to
> > navigate to suckless.org, they would be required to strike
> > shift+return in order to actually visit suckless.org. If the shift key
> > is not used, the current page will simply refresh. The reason for the
> > refresh is because dmenu matches the input text against the selected
> > text, and if it is a substring of the selected text, it will just
> > output the selected text when return has been struck, which means the
> > page simply refreshes because the new URI is the same as the current
> > one.
>
> > As far as I know, the dmenu problem is a feature for one set of users
> > and an issue for another set. I wouldn't know how to please everyone
> > on this. Feedback appreciated.
>
> Maybe just make return act like shift-return and remove shift-return?
> So dmenu will act like shell with tab-completion.
>
>
> On Tue, Aug 17, 2010 at 08:52:37PM +0400, anonymous wrote:
> > usage: cmd [-abcde] [-f file] [-g pattern] [file ...]
> What about cmd [-abcde] [-fg arg] [file ...]?
>
> > usage: flo [-c id] [-f from] [-r id] [-t to] [-w what] [what[,from][-to]]
> With the above rules this should be: flo [-cfrtw arg] [what[,from][-to]]
>
> Leaving the man page the task to teach the user what each option do.
>
> It would be nice to have a guidelines with this and other stuff there, at
> least
> for the suckless community.
>
>
> On Wed, 18 Aug 2010 01:27:22 +0200
> Alexander Teinum <ateinum_AT_gmail.com> wrote:
>
> > How many of these small tools are there?
>
> moreutils rock. they really fill some gaps. niche, but still.
>
> Dieter
>
> On Wed, Aug 18, 2010 at 7:27 AM, Antoni Grzymala <antoni_AT_chopin.edu.pl>wrote:
>
>> Suraj Kurapati dixit (2010-08-17, 20:49):
>>
>> > > As for bold, fortunately my terminal has it disabled,
>> >
>> > I set up nice colors for bold and underline so things are easy to read
>> > (see the attached screenshot). If anyone is interested, my Xdefaults
>> > file is here:
>> >
>> > http://github.com/sunaku/home/blob/master/.Xdefaults
>>
>> Strange thing is that my man doesn't get colorized (only bolded via
>> brightening up) in X terminal emulators. In the linux console I get
>> proper colors. Any hints how to enable coloring in X terminals?
>>
>> --
>> [a]
>>
>>
> I believe the options to colorize man are
> Rxvt.colorBD : #8ac6f2
> Rxvt.colorUL : #95e454
>
> L.
>
> But we don’t need the brackets. As long as the usage text is
> unambiguous, then they don’t add any information. Am I right?
>
>
> Alexander
>
> How do the colrules percentages work? Does each number represent the
> percentage of column n as a fraction of the width of the whole screen,
> or of the last selected column before it was created, or ... ?
>
> I ask because I was messing with colrules for GIMP for a while but I
> wasn't able to get it working the way I wanted it.
>
> I want to make it look like this (which I set up by manually resizing
> the columns with Mod-RMB):-
>
> http://i.imgur.com/7n47q.png
>
> I took a screenshot of that setup, got the pixel widths of each column
> and put in the numbers as pix_width_n/pix_width_screen * 100 for each in
> the colrules but it still didn't come out right (the leftmost one was
> too small, rightmost too big).
>
> Thanks for your help! :-)
>
> --
> Nikhilesh S
> http://www.nikhilesh.info
>
> On 18 August 2010 15:37, Alexander Teinum <ateinum_AT_gmail.com> wrote:
> > But we don’t need the brackets. As long as the usage text is
> > unambiguous, then they don’t add any information. Am I right?
>
> Two instances which make this untrue:
>
> > ar [-]key archive [files...]
> > eg [-b from to] files...
>
> It also just makes the usage easier to read, in my opinion. Dropping a
> few characters just isn't worth any loss in clarity. I did drop from
> dmenu's usage the [-sb <color>] syntax, though.
>
> Thanks,
> cls
>
> (Sorry for not quoting names. It’s cumbersome to do with more than one
> person in Gmail.)
>
> > With the above rules this should be: flo [-cfrtw arg] [what[,from][-to]]
>
> I think that’s too little information.
>
> > It also just makes the usage easier to read, in my opinion. Dropping a
> > few characters just isn't worth any loss in clarity.
>
> Valid point. Make things as simple as possible, but not simpler. :)
>
> From the information that I have now, then I would think that this
> should be fine:
>
> usage: program [-a] [-b] [-c] [-f file] [-n number] blah
> usage: flo [-a] [-c id] [-f from] [-r id] [-t to] [-w what]
> [what[,from][-to]]
>
> I’d like to write a KISS option parser that accepts “program -c -a -f
> some_file”, but not “program -ca -fsome_file”. I prefer to keep the
> rules simple.
>
> Is it okay to use three dots in the usage text? (See echo’s man page.)
> I think it means that you can repeat what’s before the three dots.
>
> How do you feel about sorting the options? Should it always be done?
>
> I've been using a patched version of dmenu since I started using surf.
> It sort of emulates firefox's address bar, (but I haven't been using
> firefox in a while so I'm not too sure..):
>
> 1) The Tab key acts as the Down key and Shift+Tab acts as Up.
> 2) Before Tab/Down/Shift+Tab/Up keys are pressed, no item is selected,
> regardless of if any items are matched or not.
> 3) Selecting an item doesn't cause dmenu to match, editing the char
> *text buffer does.
> 4) Selecting an item, though, fills the text buffer with the selected item.
> 5) When Return is pressed, whatever is in the text buffer will be
> outputted.
>
> So if I just want to input something, I'll type it and hit Return.
> If I want to input something similar to what dmenu matched, I'll type
> it, complete it by pressing Down or Tab, then backspace or Ctrl+w to
> edit, then I hit Return.
> Obviously if I want to input something that dmenu matched, I'll type
> enough so that the item is just a couple Tabs away, select it then hit
> Return.
>
> Attached is the patch that's really ugly, it was nicer before but
> dmenu tip's been going through some changes (thanks to cls) and I just
> wanted to make my patch work for now. If anyone's interested I can
> maintain one on the wiki.
>
> -Gene
>
>
>
>
> On Wed, Aug 18, 2010 at 4:56 AM, anonymous <ya6iod1e_AT_lavabit.com> wrote:
> > On Tue, Aug 17, 2010 at 06:52:40PM -0400, Ryan Mullen wrote:
> >> Second, dmenu's "suggested" integration with surf is a bit dodgy. If,
> >> for example, a user is viewing surf.suckless.org and they wish to
> >> navigate to suckless.org, they would be required to strike
> >> shift+return in order to actually visit suckless.org. If the shift key
> >> is not used, the current page will simply refresh. The reason for the
> >> refresh is because dmenu matches the input text against the selected
> >> text, and if it is a substring of the selected text, it will just
> >> output the selected text when return has been struck, which means the
> >> page simply refreshes because the new URI is the same as the current
> >> one.
> >
> >> As far as I know, the dmenu problem is a feature for one set of users
> >> and an issue for another set. I wouldn't know how to please everyone
> >> on this. Feedback appreciated.
> >
> > Maybe just make return act like shift-return and remove shift-return?
> > So dmenu will act like shell with tab-completion.
> >
> >
> >
>
> On Wed, Aug 18, 2010 at 10:27 AM, Kris Maglione <maglione.k_AT_gmail.com>
> wrote:
> >
> > GNU man has the annoying and difficult to stop habit of filling the
> entire
> > width of the terminal rather than wrapping at 80 chars. And if you set
> > $MANWIDTH or $COLUMNS to 80 and the terminal isn't that wide, you wind up
> > with badly broken wrapping. As for bold, fortunately my terminal has it
> > disabled, and reverse video has no place in manual pages.
> >
>
> $MANWIDTH can be abused to some extend:
>
> $ cat grepman
> #!/bin/sh
> MANWIDTH=32767 exec man "$2" | grep --color=auto -C2 -- "$1"
>
>
> Set a bigger number for your own amusement.
>
>
> --
> @chickamade
>
> 2010/8/18 Alexander Teinum <ateinum_AT_gmail.com>:
> > I’d like to write a KISS option parser that accepts “program -c -a -f
> > some_file”, but not “program -ca -fsome_file”. I prefer to keep the
> > rules simple.
>
> Such a simple option set probably doesn't actually *need* a parser. I
> don't think any lines would be freed up in dmenu. You'd just add code.
> It's got a for loop and a list of strcmps, plus usage(), which could
> be done with a goto but I wasn't sure if that's "suckless". It's
> really the simplest implementation out there.
>
> > Is it okay to use three dots in the usage text? (See echo’s man page.)
> > I think it means that you can repeat what’s before the three dots.
>
> I think "files..." means 1 or more file, and "[files]..." means 0 or more.
>
> > How do you feel about sorting the options? Should it always be done?
>
> I think it should be in the order the programmer gives them. Some
> options may be more important, for example.
>
> cls
>
> On Wed, Aug 18, 2010 at 05:55:10PM +0200, Alexander Teinum wrote:
> > Is it okay to use three dots in the usage text? (See echo’s man page.)
> > I think it means that you can repeat what’s before the three dots.
>
> It is ok and they should be used. And it should be 3 dots, not … so
> usage is in ASCII. And … look bad with monospace font.
>
> > How do you feel about sorting the options? Should it always be done?
>
> IMO yes.
>
>
> >On Tue, Aug 17, 2010 at 06:52:40PM -0400, Ryan Mullen wrote:
> >
> > The first problem is a simple patch, but I'm not sure what is the best
> > approach here. As far as I can see, I think it would be best to assume
> > that URIs without "://" in them are actually file:// types, and
> > http:// should be required for all http:// type URIs. It would be
> > trivial to insert a leading "http://" to the URI using shell tools if
> > a scripting solution is required, and in many cases, the "http://" is
> > already in place. A suggested patch is included in this mail, though
> > it isn't great because I'm using an extra struct stat for data that I
> > wind up not using, and so there is unnecessary overhead.
> I think you could use access(uri, F_OK) or access(uri, R_OK)
> instead of stat() if you just want to test the existence of a
> file.
> > As far as I know, the dmenu problem is a feature for one set of users
> > and an issue for another set. I wouldn't know how to please everyone
> > on this. Feedback appreciated.
> Indeed, there probably isn't a solution that would please
> everyone. The suggested integration is of course just a
> suggestion :). I think there are some other replies to this
> thread with some alternatives that might make you happy.
>
> On Wed, Aug 18, 2010 at 7:09 AM, Lorenzo Bolla <lbolla_AT_gmail.com> wrote:
> > On Wed, Aug 18, 2010 at 7:27 AM, Antoni Grzymala <antoni_AT_chopin.edu.pl>
> wrote:
> >> Suraj Kurapati dixit (2010-08-17, 20:49):
> >> > http://github.com/sunaku/home/blob/master/.Xdefaults
> >>
> >> Any hints how to enable coloring in X terminals?
> >
> > I believe the options to colorize man are
> > Rxvt.colorBD : #8ac6f2
> > Rxvt.colorUL : #95e454
>
> Correct. And these are the settings for XTerm:
>
> XTerm*vt100.colorMode : True
> XTerm*vt100.colorBDMode : True
> XTerm*vt100.colorULMode : True
> XTerm*vt100.veryBoldColors : 6
> XTerm*vt100.colorBD : #8ac6f2
> XTerm*vt100.colorUL : #95e454
>
> Lorenzo Bolla dixit (2010-08-18, 15:09):
>
> > > > > As for bold, fortunately my terminal has it disabled,
> > > >
> > > > I set up nice colors for bold and underline so things are easy to
> read
> > > > (see the attached screenshot). If anyone is interested, my Xdefaults
> > > > file is here:
> > > >
> > > > http://github.com/sunaku/home/blob/master/.Xdefaults
> > >
> > > Strange thing is that my man doesn't get colorized (only bolded via
> > > brightening up) in X terminal emulators. In the linux console I get
> > > proper colors. Any hints how to enable coloring in X terminals?
> > >
> > >
> > >
> > I believe the options to colorize man are
> > Rxvt.colorBD : #8ac6f2
> > Rxvt.colorUL : #95e454
>
> Suraj Kurapati dixit (2010-08-18, 10:38):
>
> > Correct. And these are the settings for XTerm:
> >
> > XTerm*vt100.colorMode : True
> > XTerm*vt100.colorBDMode : True
> > XTerm*vt100.colorULMode : True
> > XTerm*vt100.veryBoldColors : 6
> > XTerm*vt100.colorBD : #8ac6f2
> > XTerm*vt100.colorUL : #95e454
>
> They both worked, thanks a million.
>
> --
> [a]
>
> On Wed, Aug 18, 2010 at 05:55:10PM +0200, Alexander Teinum wrote:
> > I’d like to write a KISS option parser that accepts “program -c -a -f
> > some_file”, but not “program -ca -fsome_file”. I prefer to keep the
> > rules simple.
> take a look at the ARGBEGIN and ARGEND macro's in Plan 9.
>
> Hello!
>
> > Message de Kris Maglione: mar. 17/08/10, 19:19:10 -0400
> > This behavior is achievable, but considerably magnitude more
> > complex.
>
> Aha.
>
> > However, in the case of the example you provided, I don't think it's
> > that important, given that there are few enough options that you can
> > tab between them without much trouble.
>
> Yes, this is quite reasonable.
>
> > The script to make use of it would be fairly simple (the key would
> > be to check $(NF - 1) above rather than $NF and pass the part of the
> > line following the option to system()), but I'm not going to write
> > it at the moment.
>
> I really didn't expect you to give so much help as you did. Although
> not perfect, in my opinion the script is now fairly good. It would
> never have reached such a level of achievement without you.
>
> Thank you for your help,
> LuX.
>
>
> On Tue, Aug 17, 2010 at 7:54 PM, Suraj Kurapati <sunaku_AT_gmail.com> wrote:
> > On Tue, Aug 17, 2010 at 8:40 AM, Alexander Teinum <ateinum_AT_gmail.com>
> wrote:
> >> What is the most concise way of outputting a usage and help text?
> >
> > For my programs, the --help option simply displays their manpage. :-)
>
> Alternatively, in simple shell scripts (for which writing a manpage
> would be overkill), I simply print the script file's comment header
> using sed(1):
>
> #!/bin/sh
> # your program description & usage documentation here
> # nicely formatted and beautified to fit 80 columns
> # NOTE: the blank line below is the end of the file comment header
>
> # check command-line usage
> if test "$#" -lt 3; then
> sed -n '2,/^$/s/^# \?//p' "$0" # show this file's comment header
> exit 1
> fi
>
> I have written a little patch which will pop up the bar (if it is
> hidden) whilst a key is held down, over the top of all the windows. It
> allows you to "peek" at the window title/status/tags without actually
> unhiding the bar.
>
> I have it set to pop up when Super_L or Super_R is held down, as these
> are the modifier keys which all my key bindings use. I didn't bother
> adding a config.h option for which key(s) pop up the bar, but it could
> easily be done.
>
> The patch is against hg tip (as of a few days ago anyway).
>
> --
> Thomas Spurden
>
> On Thu, Aug 19, 2010 at 11:06:40AM -0700, Suraj Kurapati wrote:
> > On Tue, Aug 17, 2010 at 7:54 PM, Suraj Kurapati <sunaku_AT_gmail.com>
> wrote:
> > Alternatively, in simple shell scripts (for which writing a manpage
> > would be overkill), I simply print the script file's comment header
> > using sed(1):
> >
> > #!/bin/sh
> > # your program description & usage documentation here
> > # nicely formatted and beautified to fit 80 columns
> > # NOTE: the blank line below is the end of the file comment header
> >
> > # check command-line usage
> > if test "$#" -lt 3; then
> > sed -n '2,/^$/s/^# \?//p' "$0" # show this file's comment header
> > exit 1
> > fi
>
> That is beautiful.
>
> -Noah
>
> Hey all,
>
> The dmenu_path.c in patches seemed a bit long and complex, so I wrote
> my own. It's 100 lines, versus the other's 376. It might be a couple
> of milliseconds slower, it's difficult to tell -- but in my opinion
> its simplicity makes up for that. Source attached.
>
> cls
>
> 80 or 78? :)
>
> Sent from my iPod
>
> On Aug 21, 2010, at 2:59 AM, Noah Birnel <nbirnel_AT_gmail.com> wrote:
>
> On Thu, Aug 19, 2010 at 11:06:40AM -0700, Suraj Kurapati wrote:
>>
>>> On Tue, Aug 17, 2010 at 7:54 PM, Suraj Kurapati <sunaku_AT_gmail.com>
>>> wrote:
>>> Alternatively, in simple shell scripts (for which writing a manpage
>>> would be overkill), I simply print the script file's comment header
>>> using sed(1):
>>>
>>> #!/bin/sh
>>> # your program description & usage documentation here
>>> # nicely formatted and beautified to fit 80 columns
>>> # NOTE: the blank line below is the end of the file comment header
>>>
>>> # check command-line usage
>>> if test "$#" -lt 3; then
>>> sed -n '2,/^$/s/^# \?//p' "$0" # show this file's comment header
>>> exit 1
>>> fi
>>>
>>
>> That is beautiful.
>>
>> -Noah
>>
>>
> 2010/8/19 Suraj Kurapati <sunaku_AT_gmail.com>:
> > On Tue, Aug 17, 2010 at 7:54 PM, Suraj Kurapati <sunaku_AT_gmail.com>
> wrote:
> >> On Tue, Aug 17, 2010 at 8:40 AM, Alexander Teinum <ateinum_AT_gmail.com>
> wrote:
> >>> What is the most concise way of outputting a usage and help text?
> >>
> >> For my programs, the --help option simply displays their manpage. :-)
> >
> > Alternatively, in simple shell scripts (for which writing a manpage
> > would be overkill), I simply print the script file's comment header
> > using sed(1):
> >
> > #!/bin/sh
> > # your program description & usage documentation here
> > # nicely formatted and beautified to fit 80 columns
> > # NOTE: the blank line below is the end of the file comment header
> >
> > # check command-line usage
> > if test "$#" -lt 3; then
> > sed -n '2,/^$/s/^# \?//p' "$0" # show this file's comment header
> > exit 1
> > fi
>
> I find this solution really convoluted. Why not using echo? You can
> use an USAGE variable, or even a here-document and cat<< if you feel
> like it. And btw, it would probably be a good idea to redirect the
> help message to stderr.
>
> --
> - yiyus || JGL . 4l77.com
>
> Hey all,
>
> I've made a small patch that allows you to bind keys for
> horizontal scrolling.
>
> This approach (which imho is the least of many evils) requires
> the Arg union to be a struct, to allow the scroll() function
> to use both .b and .i as arguments.
>
> I think that horizontal scrolling via the keyboard is far from an
> "edge" use case for a web browser that already depends so heavily on
> the keyboard, so I propose that this patch be included in the
> next version of surf.
>
> On 21 August 2010 19:32, Alex Puterbaugh <puterbaugh0_AT_gmail.com> wrote:
> > Hey all,
> >
> > I've made a small patch that allows you to bind keys for
> > horizontal scrolling.
> >
> > This approach (which imho is the least of many evils) requires
> > the Arg union to be a struct, to allow the scroll() function
> > to use both .b and .i as arguments.
> >
> > I think that horizontal scrolling via the keyboard is far from an
> > "edge" use case for a web browser that already depends so heavily on
> > the keyboard, so I propose that this patch be included in the
> > next version of surf.
> >
> >
>
> Nice patch.
>
> Heh. Looks like I forgot to attach it. How's it look now?
>
> There's also some changes to the default config file, but they
> are of course just suggested.
>
> >On Sat, Aug 21, 2010 at 07:35:33PM +0100, Rob wrote:
> > On 21 August 2010 19:32, Alex Puterbaugh <puterbaugh0_AT_gmail.com> wrote:
> > > Hey all,
> > >
> > > I've made a small patch that allows you to bind keys for
> > > horizontal scrolling.
> > >
> > > This approach (which imho is the least of many evils) requires
> > > the Arg union to be a struct, to allow the scroll() function
> > > to use both .b and .i as arguments.
> > >
> > > I think that horizontal scrolling via the keyboard is far from an
> > > "edge" use case for a web browser that already depends so heavily on
> > > the keyboard, so I propose that this patch be included in the
> > > next version of surf.
> > >
> > >
> >
> > Nice patch.
> >
>
> On Sat, Aug 21, 2010 at 4:22 AM, yy <yiyu.jgl_AT_gmail.com> wrote:
> > 2010/8/19 Suraj Kurapati <sunaku_AT_gmail.com>:
> >> On Tue, Aug 17, 2010 at 7:54 PM, Suraj Kurapati <sunaku_AT_gmail.com>
> wrote:
> >> #!/bin/sh
> >> # your program description & usage documentation here
> >> # nicely formatted and beautified to fit 80 columns
> >> # NOTE: the blank line below is the end of the file comment header
> >>
> >> sed -n '2,/^$/s/^# \?//p' "$0" # show this file's comment header
> >
> > I find this solution really convoluted. Why not using echo? You can
> > use an USAGE variable, or even a here-document and cat<< if you feel
> > like it.
>
> I like to put documentation at the head of a file because that's only
> part anyone will read before deciding if it's worth spending their
> time to delve into the rest of the shell script. Also, I don't like
> messing up my program's indentation because I have to emit a big block
> of text in it:
>
> if ...; then # ugly!
> cat <<EOF
> your documentation here
> EOF
> fi
>
> > And btw, it would probably be a good idea to redirect the
> > help message to stderr.
>
> Good idea.
>
> Actually, that patch breaks the navigate() and clipboard()
> functions.
>
> There's an updated one attached.
>
> > On 21 August 2010 19:32, Alex Puterbaugh <puterbaugh0_AT_gmail.com> wrote:
> > Hey all,
> >
> > I've made a small patch that allows you to bind keys for
> > horizontal scrolling.
> >
> > This approach (which imho is the least of many evils) requires
> > the Arg union to be a struct, to allow the scroll() function
> > to use both .b and .i as arguments.
> >
> > I think that horizontal scrolling via the keyboard is far from an
> > "edge" use case for a web browser that already depends so heavily on
> > the keyboard, so I propose that this patch be included in the
> > next version of surf.
> >
> >
>
> 2010/8/21 Suraj Kurapati <sunaku_AT_gmail.com>:
> > I like to put documentation at the head of a file because that's only
> > part anyone will read before deciding if it's worth spending their
> > time to delve into the rest of the shell script. Also, I don't like
> > messing up my program's indentation because I have to emit a big block
> > of text in it:
>
> #!/bin/sh
>
> USAGE="\
> Usage: $0 -flags args
> Explain the options here.
> You even can even use use shell variables!
> "
>
> if [ $# -lt 1]; then
> echo -n "$USAGE" 1>&2
> exit 1
> fi
>
> Is this really so ugly?
>
> --
> - yiyus || JGL . 4l77.com
>
> 2010/8/21 yy <yiyu.jgl_AT_gmail.com>:
> > #!/bin/sh
> >
> > USAGE="\
> > Usage: $0 -flags args
> > Explain the options here.
> > You even can even use use shell variables!
> > "
> >
> > if [ $# -lt 1]; then
> > echo -n "$USAGE" 1>&2
> > exit 1
> > fi
> >
> > Is this really so ugly?
>
> No, it seems decent enough. Good idea.
>
> On Sat, Aug 21, 2010 at 2:12 AM, pancake <pancake_AT_youterm.com> wrote:
> > 80 or 78? :)
>
> Good point. I personally use 78 because, if you follow the Python
> suggestion of 79 characters and reserve 1 more character for +/-/>
> indicators in diff(1) output, then your code will be readable in
> terminals, editors, and also in patches.
>
> * Alex Puterbaugh <puterbaugh0_AT_gmail.com> [2010-08-21 20:32]:
> > I think that horizontal scrolling via the keyboard is far from an
> > "edge" use case for a web browser that already depends so heavily on
> > the keyboard,
>
> Yep. I've patched surf for horiz scrolling several months ago and shared
> the patch here I guess. There are so many pages which use fixed width wider
> than my netbook's screen. Horizontal scrolling is a must.
>
> Also, the following proved to be useful for me, especially for sites with
> mainly text and not sane css:
>
> # cat .surf/text_style.css
> body,textarea,p,input,td,tr,div,h1,h2,h3,h4 {
> background-color:#AFD7AF !important;
> text-color:#121212 !important;
> max-width:100%;
> }
> body{width:100%;}
>
> with following in config.h
>
> { MODKEY, GDK_t, setstyle, { .v =
> "/home/stanio/.surf/text_style.css" } },
> { MODKEY, GDK_T, setstyle, { .v = (const char *)NULL} },
>
> and in surf.c
>
> void
> setstyle(Client *c, const Arg *arg){
> WebKitWebSettings *settings;
> char *uri, *customstylefile;
>
> customstylefile = arg->v==NULL?stylefile:(char *)arg->v;
> settings = webkit_web_view_get_settings(c->view);
> uri = g_strconcat("file://", customstylefile, NULL);
> g_object_set(G_OBJECT(settings), "user-stylesheet-uri", uri,
> NULL);
> }
>
>
> cheers,
> --
> stanio_
>
> Hi everyone,
>
> I wrote my bachelor thesis using LaTeX and now I am going to write my
> master thesis. I would rather avoid TeX and everything TeX based this time.
>
> The PDF output of (La)TeX is awesome and I really like that part of it, but
> writting itself was painful, since the language is pretty cryptic and
> complex
> for 'simple document like thesis'. Overhelming compilation output
> completely
> hides any warnings and errors, which are too fuzzy and useless anyway.
> Also,
> work with images is pretty much impossible and texlive package is too big
> in
> size.
>
> I am currently looking for some replacement with:
>
> * input as plain text (NOT xml)
> * simple syntax/commands/language
> * output as PDF (acceptable as thesis), may be indirectly
> * usable compilator (readable overall output, warnings and errors)
> * overall good design
>
> I guess my demands are too high, but if you know about something
> interesting,
> please, let me know.
>
> Thank you,
> dum8d0g
>
> On 22 August 2010 12:15, Martin Kopta <martin_AT_kopta.eu> wrote:
> > * input as plain text (NOT xml)
> > * simple syntax/commands/language
>
> I suggest markdown and HTML
>
> > * output as PDF (acceptable as thesis), may be indirectly
>
> I recommend the non-free software http://www.princexml.com/
>
> It takes in HTML, despite the name.
>
> > * usable compilator (readable overall output, warnings and errors)
> > * overall good design
>
> Here is an example
> http://hsivonen.iki.fi/thesis/
>
> I want to use Markdown for writing university documents, but it lacks
> features such as table of contents, list of figures, and reference lists.
>
> HTML is not something I would choose for output format, since it doesn’t
> know the height of a page.
>
> Personally, I’d love to see a Markdown-language with some “university
> extensions”. It should have a fast compiler written in C or Go. It should
> output a PDF, follow the APA Style – well, that’s what we’re supposed to
> follow at my university in Norway.
>
> All of this can be modularized. Perhaps Markdown with macro support would
> solve the problem. Maybe it already exists?
>
> I’m learning troff right now so that I can write man-pages. It seems like a
> nice enough language. I have used LaTeX for university work earlier, and the
> result was really nice.
>
> I do find LaTeX and troff hard to get into. I am not able to fully express
> what I feel about this, but it has something to do with the documentation.
> It’s more inaccessible compared to Markdown and HTML. LaTeX in itself isn’t
> that hard, but the whole ecosystem around it feels scary.
>
> On 10-08-22 07:15 AM, Martin Kopta wrote:
>
>> Hi everyone,
>>
>> I wrote my bachelor thesis using LaTeX and now I am going to write my
>> master thesis. I would rather avoid TeX and everything TeX based this
>> time.
>>
>
> consider writing in markdown and transforming via pandoc.
> http://johnmacfarlane.net/pandoc/
> djp
>
> If you dislike TeX, use troff. If you dislike troff, just use
> microsoft word, because you're wrong.
>
> Markdown is a crippled pile of meta-shit; it is not a typesetting
> system. If you're producing anything other than blog posts in
> markdown you're fucking up.
>
> --
> # Kurt H Maier
>
> I might create a parser for a language that I just invented. It’s
> somewhat like Common Lisp.
>
> (h1 A heading)
> (p This is (strong awefully) nice.)
> (h2 Another heading)
>
> Or, it could be written this way…
>
> (h1
> A heading)
> (p
> This is (strong awefully) nice.)
> (h2
> Another heading)
>
> Writing a parser for this is ten times easier than writing one for
> Markdown. And this language is infinitely times more extensible.
>
> I'm using a Markdown-like language to write my phd thesis in LaTeX (I
> have already used it for my master thesis and several scientific
> papers). Some day I should probably clean all my stuff and release
> something, but at this moment is a very ad-hoc thing.
>
> Basicly an awk script (find attached) processes titles, emphasis and
> lists like markdown. Images are included with a tag at the begining of
> the line. It also supports footnotes, tables (in the same or different
> files), equations with LaTeX notation, an graphs (processed with
> gnuplot and the epslatex terminal). Bibliographic references, as well
> as references to figures and tables, can be included too. In the same
> way that Markdown can include raw html you can include raw LaTeX here.
> Makefiles and a series of scripts take care of building everything for
> me.
>
> If anybody is interested maybe I can privately send some of the
> material, but it won't be very useful without a full example and I'm
> not allowed to put that in the tubes. Anyway, I suggest to write your
> own toolset if you are taking this route.
>
> --
> - yiyus || JGL . 4l77.com
>
> On Sun, 22 Aug 2010, Martin Kopta wrote:
>
> Hi everyone,
>>
>> I wrote my bachelor thesis using LaTeX and now I am going to write my
>> master thesis. I would rather avoid TeX and everything TeX based this
>> time.
>>
>
> Why everything TeX based? Give ConTeXt a shot:
> http://www.contextgarden.net
>
> Overhelming compilation output completely
>> hides any warnings and errors, which are too fuzzy and useless anyway.
>>
>
> For LaTeX, filtering useless information is easy. There are plenty of
> scripts and editor plugins that do that.
>
> Also, work with images is pretty much impossible
>>
>
> Can you elaborate? Do you mean that it is hard to draw an image or it is
> hard to include an image or it is hard to predict where the image will end
> up in the document?
>
> and texlive package is too big in size.
>>
>
> For ConTeXt you can download context minimals. The install size is around
> 200MB (most of which is fonts), which is much smaller than TeXLive that can
> be around 1GB.
>
> I am currently looking for some replacement with:
>>
>> * input as plain text (NOT xml)
>> * simple syntax/commands/language
>> * output as PDF (acceptable as thesis), may be indirectly
>> * usable compilator (readable overall output, warnings and errors)
>> * overall good design
>>
>> I guess my demands are too high, but if you know about something
>> interesting,
>> please, let me know.
>>
>
> ConTeXt fits all points. The error messages in ConTeXt are more readable
> than plain TeX/LaTeX, but still somewhat cryptic if you are not used to TeX
> error messages.
>
> Aditya
>
> I didn’t want to start a completely off-topic discussion in the
> typesetting thread, so I created a new thread. I’m playing with the
> idea of creating a language that is simple to read like Markdown, but
> that has a stricter syntax. It looks like Common Lisp. I think the
> parser should be implemented in Go.
>
> (h1 A heading)
> (p This is (strong awfully) nice.)
> (h2 Another heading)
>
>
> Or, it could be written this way…
>
> (h1
> A heading)
> (p
> This is (strong awfully) nice.)
> (h2
> Another heading)
>
>
> There might be a rule that says that the first level doesn’t need the
> parentheses…
>
> h1 A heading
> p This is (strong awfully) nice.
> h2 Another heading
>
>
> There isn’t any information in that markup that says where the h1, p,
> or h2 tag ends, so it would be most sane to say that it ends at \n,
> unless the last character is a \.
>
> h1 A heading
> p This is (strong awfully) nice.\
> \
> Line breaks in a paragraph.\
>
> h2 Another heading
>
>
> Hash signs might be better than h1, h2, …
>
> # A heading
> p This is (* awfully) nice.
> ## Another heading
>
>
> That’s the idea. I’d like to discuss the language here; the syntax and
> implementation details. Maybe it has already been done. Maybe the idea
> sucks.
>
> On Sun, Aug 22, 2010 at 01:15:40PM +0200, Martin Kopta wrote:
> > Hi everyone,
> >
> > I wrote my bachelor thesis using LaTeX and now I am going to write my
> > master thesis. I would rather avoid TeX and everything TeX based this
> time.
> >
> > The PDF output of (La)TeX is awesome and I really like that part of it,
> but
> > writting itself was painful, since the language is pretty cryptic and
> complex
> > for 'simple document like thesis'. Overhelming compilation output
> completely
> > hides any warnings and errors, which are too fuzzy and useless anyway.
> Also,
> > work with images is pretty much impossible and texlive package is too big
> in
> > size.
> >
> > I am currently looking for some replacement with:
> >
> > * input as plain text (NOT xml)
> > * simple syntax/commands/language
> > * output as PDF (acceptable as thesis), may be indirectly
> > * usable compilator (readable overall output, warnings and errors)
> > * overall good design
> >
> > I guess my demands are too high, but if you know about something
> interesting,
> > please, let me know.
> >
> > Thank you,
> > dum8d0g
>
> This is probably not what you're looking for, but last year I've
> been using lout[1] (that website is awful, btw) for all of my
> university documents. It's not really suckless, but I think that
> overall it's better than LaTeX. The syntax feels rather lisp-y
> (it's actually a functional language), but is much easier to extend
> and program than TeX. It's written entirely in C and the lout
> distribution is *much* smaller than (La)TeX.
>
> $ du -sh lout.lib/
> 5.5M lout.lib/
>
> lout outputs directly to postscript, so compiling to pdf is rather
> easy.
>
> $ lout test.lout | ps2pdf - test.pdf
>
> Links:
> [1] http://lout.wiki.sourceforge.net/
>
>
-- "Ideas have a provenance, they have histories, they do not have owners."-- Anonymedian "If the Idea of `ownership' is relevant to ideas, then surely the most conventional models have the subject-object relationship absurdly inverted."-- Anonymedian "I have no idea!" -- ILF Motto http://tahoe-lafs.org/trac/tahoe-lafs <http://allmydata.org>Received on Mon Aug 23 2010 - 06:14:10 CEST
This archive was generated by hypermail 2.2.0 : Mon Aug 23 2010 - 06:24:02 CEST
