Re: [PATCH] mg: {beginning,end}-of-buffer don't set marks in Emacs

> Note: I only wanted to point out something that bothered me. I'm not > using mg(1) these days and I don't plan to spend time on this issue. That’s pretty much the modern internet, summarized in two sentences

Re: [PATCH] mg: {beginning,end}-of-buffer don't set marks in Emacs

Regardless of the decision on which way the behavior should go, it is a documentation bug either way. (E.g. beginning-of-buffer is missed entirely). Probably my fault (from a lng time ago.) On Wed, May 22, 2019 at 8:53 AM Leonid Bobrov wrote: > On Wed, May 22, 2019 at 01:36:41PM +0200,

Re: mg: display wide characters

Oh goodness. My recollection is that 1 byte per character is assumed all over the place. This is going to take a *while* to test properly. Maybe this is a good time for me to start looking at mg again... On Thursday, 21 January 2016, Mark Lumsden wrote: > I am busy for

Re: mg: add bounce matching for [] and {}

It should be noted, You can do that (without a code change) with an appropriate chunk of code in your ~/.mg file. (at least, that's how I have always done it) On Tuesday, October 7, 2014, Stuart Cassoff s...@bell.net wrote: On 08/13/14 18:51, Brian Callahan wrote: Hi tech -- Diff below

Re: tinyscheme + mg

Thoughts, since we have been down this road before. 1. You can remap keys, in your ~/.mg file 2. I should point out that all of mg (other than theo.c) is currently PUBLIC DOMAIN, not merely BSD, so this change is significant, license-wise. Please be pedantic about including licenses. 3. Why

Re: tinyscheme + mg

I think the massive mg user base can handle a single flavor. :) On Thu, Jun 28, 2012 at 11:20 AM, Eichert, Diana deic...@sandia.gov wrote: On Thu, Jun 28, 2012 at 08:35:18AM -0400, Kjell Wooding wrote: 2. I should point out that all of mg (other than theo.c) is currently PUBLIC DOMAIN

Re: Pipe text from mg to external command

Regardless, I stand by my original comment. :) On Thursday, March 29, 2012, Jason McIntyre wrote: On Thu, Mar 29, 2012 at 12:00:56AM -0400, Kjell Wooding wrote: There's nothing *technically* wrong with irrespective, but it is a tad awkward when compared with regardless. there's nothing

Re: Pipe text from mg to external command

There's nothing *technically* wrong with irrespective, but it is a tad awkward when compared with regardless. irregardless is a hangable offense. On Wed, Mar 28, 2012 at 1:40 AM, Jason McIntyre j...@cava.myzen.co.ukwrote: On Tue, Mar 27, 2012 at 10:46:46PM -0400, Kjell Wooding wrote: s

Re: Pipe text from mg to external command

s/irrespective/regardless/ On Tue, Mar 27, 2012 at 12:57 PM, Sunil Nimmagadda su...@sunilnimmagadda.com wrote: This version implements some off-list review comments... 1. Discard explicit checking whether command exists and it's permissions since shell already does and reports error. 2.

Re: ctags(1) and mg(1) again

I would think that automatically reading any file in pwd named tags, and trying to parse it as a tags file *by default* whenever mg is started is a bad choice.

Re: mg: dirname, basename

Looks quite fine, but I noticed there are no NULL checks for the newly allocated strings. Aborting a command gracefully might be better than crashing, should anyone ever be unfortunate enough to hit this. Absolutely true. And in thinking about adding such checks, I realize they just ugify

Re: mg:join-line

Yeah, nice catch on the twiddle bug. This looks pretty good. Anyone else try it? -kj On Mon, Jan 17, 2011 at 10:10 AM, Henri Kemppainen ducl...@guu.fi wrote: Looks pretty good. I might add an undo boundary around the whole thing (I note emacs doesn't do this properly, at least on the

mg: avoid d_namlen

Over the years, I have gotten numerous mails from people having difficulty compiling mg on other platforms. Most of these mails fall into one of two categories: * struct dirent problems, * basename, dirname problems This diff addresses the former. The essential problem is that many platforms

mg: dirname, basename

And this is the other frequently encountered issue for people trying to port our mg changes elsewhere. dirname and basename are usually stupid on other platforms, modifying their input strings, and other such silliness. This fixes this issue by wrapping everything in allocating routines. It

Re: mg:join-line

On Mon, Jan 17, 2011 at 9:52 AM, Han Boetes h...@mijncomputer.nl wrote: Kjell Wooding wrote: I might add an undo boundary around the whole thing (I note emacs doesn't do this properly, at least on the version I have here)... Undoing join-line works fine with the emacs version I am using

mg: linetostring oops

Well, this seems to be an obvious error on my part (since llength returns an int). Found while doing a portability sweep. ok? Index: line.c === RCS file: /cvs/src/usr.bin/mg/line.c,v retrieving revision 1.49 diff -u -r1.49 line.c

mg: another dumb one

augbname does the basename itself. No point calling it twice. Index: file.c === RCS file: /cvs/src/usr.bin/mg/file.c,v retrieving revision 1.72 diff -u -r1.72 file.c --- file.c 26 Jun 2010 16:18:44 - 1.72 +++ file.c

Re: mg:join-line

I'm afraid simply adding the the undo boundary around newline() will break yank(), which sets its own boundary and calls newline() among other changes. If we want this undo stuff, then we probably should add checks such that none of these functions set boundaries if they were disabled (by

mg:join-line

Looks pretty good. I might add an undo boundary around the whole thing (I note emacs doesn't do this properly, at least on the version I have here)... like so: Index: def.h === RCS file: /cvs/src/usr.bin/mg/def.h,v retrieving

Re: Allegations regarding OpenBSD IPSEC

Note that this assumes that there is no backdoor in random(6) (or arc4random_uniform, which it calls) designed to prevent the source file with the backdoor from being selected with the above command. That's true. I would submit a patch, but it would require every developer to carry around a

Re: MD5 Folding in kernel RNG

, and so on. Anyway, I'm muttering aloud now. In the meantime, is there any reason to keep the fold? On Tue, Dec 28, 2010 at 1:48 AM, Damien Miller d...@mindrot.org wrote: On Mon, 27 Dec 2010, Kjell Wooding wrote: The OpenBSD random number subsystem uses an in-kernel entropy pool. This data

Re: MD5 Folding in kernel RNG

Hi Damien. On Tue, Dec 28, 2010 at 1:45 PM, Damien Miller d...@mindrot.org wrote: On Tue, 28 Dec 2010, Kjell Wooding wrote: How would a preimage attack matter in this case? It gives you knowledge of the collection pool, which is what the very thing the design is supposed to avoid

Re: MD5 Folding in kernel RNG

There are arc4random_buf () calls in the kernel. Those can use the arc4random_buf_large() mechanism, can thy not? Or are the requests typically too small? arc4random_buf_large() is not exported as an API; this is intentional. If you do arc4random_buf_large() for a small buffer size,

Re: Add back-to-indentation (M-m) for mg

Looks good. Here is a slight cleanup. Essentially, fix alphabetical ordering, change function name : Index: def.h === RCS file: /cvs/src/usr.bin/mg/def.h,v retrieving revision 1.113 diff -u -u -r1.113 def.h --- def.h30 Jun 2010

MD5 Folding in kernel RNG

The OpenBSD random number subsystem uses an in-kernel entropy pool. This data isn't used directly. When entropy is requested, the contents of the pool are hashed with MD5, and the massaged output used to seed an RC4 PRNG. In looking at the code, however, I notice we actually fold the MD5 output

Re: Add back-to-indentation (M-m) for mg

Probably my (pasting) bad. This isn't my favourite mailer. patch -l will fix that though... On Mon, Dec 27, 2010 at 7:33 PM, Nima Hoda nimah...@gmail.com wrote: On Mon, Dec 27, 2010 at 03:01:57PM -0700, Kjell Wooding wrote: Looks good. Here is a slight cleanup. Essentially, fix alphabetical

Re: Allegations regarding OpenBSD's PRNG

Can you please stop wasting time asking questions before you bother to read about what you are asking? On Wed, Dec 22, 2010 at 10:00 AM, Marsh Ray ma...@extendedsubset.comwrote: How is this different, except for perhaps the intermediate arc4 cipher. What does that add, other than crappiness?

Re: Allegations regarding OpenBSD's PRNG

On Wed, Dec 22, 2010 at 12:24 PM, Marsh Ray ma...@extendedsubset.comwrote: On 12/22/2010 11:44 AM, Kjell Wooding wrote: Can you please stop wasting time asking questions before you bother to read about what you are asking? Consider the possibility that I have, in fact, read a little bit

Re: Allegations regarding OpenBSD IPSEC

It *seems harder* (but I'm not an expert on this kind of thing!) to predict the first couple of rounds if nanotime_noise is hashed (which means that you have to re-do the complete calculation for each possible nanotime_noise, which may not necessarily be the case above), and if this hashing

Re: A tiny feature for mg(1): beginning-of-line

not the way emacs behaves and mg is supposed to be finger-compatible with emacs. -- Christian naddy Weisgerber na...@mips.inka.de Actually, Ingo forwarded me some mails from Kjell about this and that it subtly breaks c-mode.. So it can't go in as is. -- Cheers

Fix Carpdemote in sasyncd

This diff fixes some issues around sasyncd's handling of the carpdemote flag, fixing some signal handling, cleanup, and logging issues. Here's the problem I am seeing. Some background: # ifconfig -g carp carp: carp demote count 0 This is the normal case. If I poke the demote counter

Re: suggested patch to httpd.conf in base

Very good suggestion, indeed. Especially, if someone has a 'dangerous' file, a PHP Shell for instance, (a perfect example: http://mgeisler.net/downloads/phpshell/phpshell-1.7.tar.gz) inside such a directory. (Or even maybe a simple file uploader, that will help the attacker to upload

Re: mg + tinyscheme

Frankly, having scheme in without any support for REPL in mg is not that awesome. What makes elisp so handy is an ability to see what happens in realtime while programming (the usual Lisp/REPL development way). pthth. I don't care if elisp is handy. That's not the point. The point is, would

Re: ddb.log in sysctl.conf

This is incorrect. This file is not for documentation, it is for configuration. If the user adds a new option to the file, it does not suddenly become commonly used. Ok. What is intended in the proposed changes is that the list be identified as intentionally a subset of those