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, Jeremie Courreges-Anglas wrote: > > On Wed, May 22 2019, Leonid Bobrov wrote: > > > It seems that nobody cares about compatibility with GNU Emacs. Besides > > > this behaviour is annoying because when I set a mark, scroll a buffer, > > > and decide to go to the end of buffer that overwrites my mark and I > have > > > to start over. Also besides that you have to figure out this behavior > > > because manpage just says: > > > ``` > > >M-< beginning-of-buffer > > >M-> end-of-buffer > > > ``` > > > Should we consider this documentation bug and patch a manpage? > > > > > > On Thu, Feb 14, 2019 at 04:46:21PM +0200, Leonid Bobrov wrote: > > >> Ping. > > >> > > >> On Wed, Feb 06, 2019 at 11:29:47PM +0200, Leonid Bobrov wrote: > > >> > Hi! > > >> > > > >> > Going to end and begging of buffer doesn't set marks in Emacs. > > > > This doesn't match my understanding of marks in emacs, nor what emacs > > C-h k says: > > > > --8<-- > > M-< runs the command beginning-of-buffer (found in global-map), which is > > an interactive compiled Lisp function in ‘simple.el’. > > > > It is bound to ., b, , , , > > M-<,. > > > > (beginning-of-buffer &optional ARG) > > > > This function is for interactive use only; > > in Lisp code use `(goto-char (point-min))' instead. > > > > Move point to the beginning of the buffer. > > With numeric arg N, put point N/10 of the way from the beginning. > > If the buffer is narrowed, this command uses the beginning of the > > accessible part of the buffer. > > > > Push mark at previous position, unless either a C-u prefix > > ^^ > > is supplied, or Transient Mark mode is enabled and the mark is active. > > -->8-- > > > > So if you're pushing for a change here we'd need a better explanation. > > > > -- > > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 > E7EE > > > > Oh, I haven't noticed that behavior in Emacs before. So, if I haven't > pushed a mark before, then Emacs will automatically push it (while mg > pushes it in all cases). > > Also that C-u prefix part is not true (I made a check, also thank you > for new knowledge), in Emacs it pushes a mark if I haven't pushed it > myself. > > In Emacs Transient Mark mode is on by default, but mg doesn't have this > mode. Also mg doesn't have that N/10 behavior when giving it a numeric > arg. > > In order to be compatible with GNU Emacs, I have to implement Transient > Mark mode, make it on by default, while in this mode using M-< and M-> > shouldn't push mark if it's active and I have to implement N/10 behavior > when giving a numeric arg to M-< and M->, is everything correct? > >
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: 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 the next month or so, but will try and look at your diff > afterwards. Hopefully some others will be able to test/comment as > well, in the mean time. > > Mark > >
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 wrote:
> On 08/13/14 18:51, Brian Callahan wrote:
> > Hi tech --
> >
> > Diff below adds the bounce matching for [] and {} in mg like it does for
> ().
> > I miss having that from GNU Emacs, anyone else?
> >
> > OK?
> >
> > ~Brian
>
> Just noticed this yesterday. Thanks!
>
>
> Stu
>
>
>
Re: A tiny feature for mg(1): beginning-of-line
Overloading goto-bol is a terrible idea. If it's really desirable, it should become a function (back-to-indentation), and get bound go M-m... On Wed, Oct 6, 2010 at 5:43 AM, Jasper Lievisse Adriaanse wrote: > On Wed, Oct 06, 2010 at 11:37:39AM +, Christian Weisgerber wrote: > > Jasper Lievisse Adriaanse wrote: > > > > > Would this be OK with anyone? > > > > > > -Move cursor to the beginning of the line. > > > > +Move cursor to the beginning of the line. Calling this function > again moves > > > > +the cursor to the first non-whitespace character of the line. > > > > That's 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, > Jasper > > Stay Hungry. Stay Foolish.
Re: Allegations regarding OpenBSD IPSEC
>"MD5(time), MD5(time + 1ns), MD5(time + 2ns) etc into the buffer. This
does not increase entropy, but having more-or-less uncorrelated data
in the entire buffer should make attacks more difficult."
No. Unless you know something I don't, This is voodoo. To do it once might
add something, but to do it multiple times, with strongly correlated inputs
seems potentially dangerous. Especially since you are XORing them. Does
anyone elsewhere in the cryptographic world do something like this?
Can you prove there are no statistical weaknesses in MD5 for such inputs?
On Tue, Dec 21, 2010 at 1:04 PM, Joachim Schipper <
joac...@joachimschipper.nl> wrote:
> On Tue, Dec 21, 2010 at 08:27:49PM +0100, Kurt Knochner wrote:
> > 2010/12/21 Joachim Schipper :
> > > + get_random_bytes(buf, sizeof(buf));
> > > + nanotime(&ts);
> > > + for (i = 0; i < sizeof(ts); i++)
> > > + buf[i] ^= ((uint8_t *) &ts)[i];
> >
> > I like the idea of using XOR. However, there are two issues:
> >
> > 1.) if nanotime() was called because of not enough random data from
> > get_random_bytes() then you could end up with only the value &ts in
> > buf. Why not use a md5 hash of the time value (better than the plain
> > time value) or better just don't use the time value at all.
>
> New diff.
>
> Improvements:
> - document the "why" of this loop (from Otto's message)
> - Instead of XOR'ing the results of nanotime into the buffer, XOR
> MD5(time), MD5(time + 1ns), MD5(time + 2ns) etc into the buffer. This
> does not increase entropy, but having more-or-less uncorrelated data
> in the entire buffer should make attacks more difficult.
>
>Joachim
>
> Index: ../../dev/rnd.c
> ===
> RCS file: /usr/cvs/src/src/sys/dev/rnd.c,v
> retrieving revision 1.104
> diff -u -p -r1.104 rnd.c
> --- ../../dev/rnd.c 21 Nov 2010 22:58:40 - 1.104
> +++ ../../dev/rnd.c 21 Dec 2010 20:01:02 -
> @@ -779,13 +779,29 @@ get_random_bytes(void *buf, size_t nbyte
> static void
> arc4_stir(void)
> {
> - u_int8_t buf[256];
> - int len;
> + u_int8_t buf[256], md5_buf[MD5_DIGEST_LENGTH];
> + MD5_CTX md5_ctx;
> + struct timespec ts;
> + int i, j;
>
> - nanotime((struct timespec *) buf);
> - len = sizeof(buf) - sizeof(struct timespec);
> - get_random_bytes(buf + sizeof (struct timespec), len);
> - len += sizeof(struct timespec);
> + get_random_bytes(buf, sizeof(buf));
> +
> + /*
> +* extract_entropy(), and thus get_random_bytes(), may not actually
> be
> +* very random early in the startup sequence of some machines. This
> is
> +* a desperate attempt to increase the randomness in the pool by
> mixing
> +* in nanotime().
> +*/
> + nanotime(&ts);
> + KDASSERT(sizeof(buf) % MD5_DIGEST_LENGTH == 0);
> + for (i = 0; i < sizeof(buf); i += MD5_DIGEST_LENGTH) {
> + ts.tv_nsec = (ts.tv_nsec + 1) % (1000 * 1000 * 1000);
> + MD5Init(&md5_ctx);
> + MD5Update(&md5_ctx, (u_int8_t *) &ts, sizeof(ts));
> + MD5Final(md5_buf, &md5_ctx);
> + for (j = 0; j < MD5_DIGEST_LENGTH; j++)
> + buf[i + j] ^= md5_buf[j];
> + }
>
>mtx_enter(&rndlock);
>if (rndstats.arc4_nstirs > 0)
> @@ -793,7 +809,7 @@ arc4_stir(void)
>
>rc4_keysetup(&arc4random_state, buf, sizeof(buf));
>arc4random_count = 0;
> - rndstats.arc4_stirs += len;
> + rndstats.arc4_stirs += sizeof(buf);
>rndstats.arc4_nstirs++;
>
>/*
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 is hashed (which > means that you have to re-do the complete calculation for each possible > , which may not necessarily be the case above), and if > this hashing is used to distribute the noise over the entire initial > state of the cipher (so that no known portion exists). > > Hashing wasn't my objection. Hashing 3 times with data-dependent inputs and XORing them together was.
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 wrote: > How is this different, except for perhaps the intermediate arc4 cipher. > What does that add, other than crappiness? (RC4 is known to be > distinguishable from a good random source.) > Oh good grief. Yes, ARC4 is being used to stretch a random source. Feel free to hunt for the distinguisher in the OpenBSD multi-consumer model. There's a good paper in there. If you can show a distinguisher (even without reseedings) with an equivalent number of consumers randomly pulling data from the stream, then you might be able to tell us how long we should go between reseeding. I would be (very?) surprised if you have time to see a bias under the current model (multi-consumer, rapid reseeding), though that doesn't mean it isn't possible. The problem is you are asking boneheaded questions without taking the time to understand what you are asking about. You are all noise, and no signal. -kj
Re: Allegations regarding OpenBSD's PRNG
On Wed, Dec 22, 2010 at 12:24 PM, Marsh Ray wrote: > 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 about it > and am asking some of these questions because I suspect you don't actually > have a good answer for them. People who are deeply convinced of their > correctness usually aren't able to reflect on it objectively. > Perhaps that's why you seem unwilling to listen to what you are being told. Which is why I'm wondering what exactly, this 'multi-consumer' design > feature is all about. Is it simply that more userland stuff is pinging the > kernel at unpredictable times resulting in more timestamps feeding into the > central entropy pool? It seems like you could accomplish that with any > syscall. Or is there some other effect being claimed? Can you please stop wasting time asking questions before you bother to read about what you are asking? You have flipped the bozo bit. You're on your own until you bother doing some of your homework. -kj
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 19:12:54 -1.113
+++ def.h27 Dec 2010 21:58:28 -
@@ -511,6 +511,7 @@
int forwdel(int, int);
int backdel(int, int);
int space_to_tabstop(int, int);
+int backtoindent(int, int);
/* extend.c X */
int insert(int, int);
Index: funmap.c
===
RCS file: /cvs/src/usr.bin/mg/funmap.c,v
retrieving revision 1.32
diff -u -u -r1.32 funmap.c
--- funmap.c15 Sep 2008 16:13:35 -1.32
+++ funmap.c27 Dec 2010 21:58:28 -
@@ -26,6 +26,7 @@
{auto_execute, "auto-execute", },
{fillmode, "auto-fill-mode",},
{indentmode, "auto-indent-mode",},
+{backtoindent, "back-to-indentation",},
{backchar, "backward-char",},
{delbword, "backward-kill-word",},
{gotobop, "backward-paragraph",},
Index: keymap.c
===
RCS file: /cvs/src/usr.bin/mg/keymap.c,v
retrieving revision 1.43
diff -u -u -r1.43 keymap.c
--- keymap.c27 Aug 2008 04:11:52 -1.43
+++ keymap.c27 Dec 2010 21:58:28 -
@@ -241,7 +241,7 @@
static PF metal[] = {
lowerword,/* l */
-rescan,/* m */
+backtoindent,/* m */
rescan,/* n */
rescan,/* o */
rescan,/* p */
Index: mg.1
===
RCS file: /cvs/src/usr.bin/mg/mg.1,v
retrieving revision 1.47
diff -u -u -r1.47 mg.1
--- mg.17 Oct 2010 17:08:58 -1.47
+++ mg.127 Dec 2010 21:58:28 -
@@ -230,6 +230,8 @@
forward-word
.It M-l
downcase-word
+.It M-m
+back-to-indentation
.It M-q
fill-paragraph
.It M-r
@@ -304,6 +306,8 @@
to a new line.
.It auto-indent-mode
Toggle indent mode, where indentation is preserved after a newline.
+.It back-to-indentation
+Move the dot to the first non-whitespace character on the current line.
.It backward-char
Move cursor backwards one character.
.It backward-kill-word
Index: random.c
===
RCS file: /cvs/src/usr.bin/mg/random.c,v
retrieving revision 1.26
diff -u -u -r1.26 random.c
--- random.c15 Sep 2008 16:13:35 -1.26
+++ random.c27 Dec 2010 21:58:28 -
@@ -440,3 +440,16 @@
return (linsert((n << 3) - (curwp->w_doto & 7), ' '));
}
#endif /* NOTAB */
+
+/*
+ * Move the dot to the first non-whitespace character of the current line.
+ */
+int
+backtoindent(int f, int n)
+{
+gotobol(FFRAND, 1);
+while (curwp->w_doto < llength(curwp->w_dotp) &&
+(isspace(lgetc(curwp->w_dotp, curwp->w_doto
+++curwp->w_doto;
+return (TRUE);
+}
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 in half. From extract_entropy(): MD5Final(buffer, &tmp); /* * In case the hash function has some recognizable * output pattern, we fold it in half. */ buffer[0] ^= buffer[15]; buffer[1] ^= buffer[14]; buffer[2] ^= buffer[13]; buffer[3] ^= buffer[12]; buffer[4] ^= buffer[11]; buffer[5] ^= buffer[10]; buffer[6] ^= buffer[ 9]; buffer[7] ^= buffer[ 8]; /* Copy data to destination buffer */ bcopy(buffer, buf, i); nbytes -= i; buf += i; My question: Why? What exactly are we protecting against, and is this really protection? (the comment indicates "some recognizable output pattern, but that means little to me as is) Can we really be sure it doesn't make things worse? Is this done elsewhere, or is it our particular brand of voodoo? Happy ho ho, -kj
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 wrote:
> On Mon, Dec 27, 2010 at 03:01:57PM -0700, Kjell Wooding wrote:
> > Looks good. Here is a slight cleanup. Essentially, fix alphabetical
> > ordering, change function name :
>
> The patch isn't applying for me. It seems tabs have been converted to
> spaces in your diff.
>
> > 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 19:12:54 -1.113
> > +++ def.h27 Dec 2010 21:58:28 -
> > @@ -511,6 +511,7 @@
> > int forwdel(int, int);
> > int backdel(int, int);
> > int space_to_tabstop(int, int);
> > +int backtoindent(int, int);
> >
> > /* extend.c X */
> > int insert(int, int);
> > Index: funmap.c
> > ===
> > RCS file: /cvs/src/usr.bin/mg/funmap.c,v
> > retrieving revision 1.32
> > diff -u -u -r1.32 funmap.c
> > --- funmap.c15 Sep 2008 16:13:35 -1.32
> > +++ funmap.c27 Dec 2010 21:58:28 -
> > @@ -26,6 +26,7 @@
> > {auto_execute, "auto-execute", },
> > {fillmode, "auto-fill-mode",},
> > {indentmode, "auto-indent-mode",},
> > +{backtoindent, "back-to-indentation",},
> > {backchar, "backward-char",},
> > {delbword, "backward-kill-word",},
> > {gotobop, "backward-paragraph",},
> > Index: keymap.c
> > ===
> > RCS file: /cvs/src/usr.bin/mg/keymap.c,v
> > retrieving revision 1.43
> > diff -u -u -r1.43 keymap.c
> > --- keymap.c27 Aug 2008 04:11:52 -1.43
> > +++ keymap.c27 Dec 2010 21:58:28 -
> > @@ -241,7 +241,7 @@
> >
> > static PF metal[] = {
> > lowerword,/* l */
> > -rescan,/* m */
> > +backtoindent,/* m */
> > rescan,/* n */
> > rescan,/* o */
> > rescan,/* p */
> > Index: mg.1
> > ===
> > RCS file: /cvs/src/usr.bin/mg/mg.1,v
> > retrieving revision 1.47
> > diff -u -u -r1.47 mg.1
> > --- mg.17 Oct 2010 17:08:58 -1.47
> > +++ mg.127 Dec 2010 21:58:28 -
> > @@ -230,6 +230,8 @@
> > forward-word
> > .It M-l
> > downcase-word
> > +.It M-m
> > +back-to-indentation
> > .It M-q
> > fill-paragraph
> > .It M-r
> > @@ -304,6 +306,8 @@
> > to a new line.
> > .It auto-indent-mode
> > Toggle indent mode, where indentation is preserved after a newline.
> > +.It back-to-indentation
> > +Move the dot to the first non-whitespace character on the current line.
> > .It backward-char
> > Move cursor backwards one character.
> > .It backward-kill-word
> > Index: random.c
> > ===
> > RCS file: /cvs/src/usr.bin/mg/random.c,v
> > retrieving revision 1.26
> > diff -u -u -r1.26 random.c
> > --- random.c15 Sep 2008 16:13:35 -1.26
> > +++ random.c27 Dec 2010 21:58:28 -
> > @@ -440,3 +440,16 @@
> > return (linsert((n << 3) - (curwp->w_doto & 7), ' '));
> > }
> > #endif /* NOTAB */
> > +
> > +/*
> > + * Move the dot to the first non-whitespace character of the current
> line.
> > + */
> > +int
> > +backtoindent(int f, int n)
> > +{
> > +gotobol(FFRAND, 1);
> > +while (curwp->w_doto < llength(curwp->w_dotp) &&
> > +(isspace(lgetc(curwp->w_dotp, curwp->w_doto
> > +++curwp->w_doto;
> > +return (TRUE);
> > +}
Re: MD5 Folding in kernel RNG
How would a preimage attack matter in this case? Even if I could pull one off, (i.e. guess the contents of the entropy pool based on the output of the hash), we perturb it again right afterwards. Furthermore, how would this be any different than choosing just the upper or lower half? And again, is this *ever* used directly, or is it simply the input to the RC4 generator? In which case, pulling off a preimage attack would be essentially miraculous. In any case, if there is not a good reason to keep it (since it's not standard practice), why not eliminate it? I just don't see what it accomplishes. Sure, it may be worth investigating another hash function. Maybe even another stream cipher for use with the PRNG, but we should be clear about what the requirements for such a hash / cipher should be. Certainly, speed is a factor for both. RC4 is hella fast, but since we need to dump k*256 bytes of keystream every time, something else may end up being faster. Lack of a distinguisher in the stream cipher would also seem to be important, of course, given the application. Set-up time matters for the stream cipher, since we routinely set up new instances for large random requests, 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 wrote: > On Mon, 27 Dec 2010, Kjell Wooding wrote: > > > 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 > in > > half. From extract_entropy(): > > > > MD5Final(buffer, &tmp); > > > > /* > > * In case the hash function has some recognizable > > * output pattern, we fold it in half. > > */ > > buffer[0] ^= buffer[15]; > > buffer[1] ^= buffer[14]; > > buffer[2] ^= buffer[13]; > > buffer[3] ^= buffer[12]; > > buffer[4] ^= buffer[11]; > > buffer[5] ^= buffer[10]; > > buffer[6] ^= buffer[ 9]; > > buffer[7] ^= buffer[ 8]; > > > >/* Copy data to destination buffer */ > > bcopy(buffer, buf, i); > > nbytes -= i; > > buf += i; > > > > My question: Why? What exactly are we protecting against, and is this > really > > protection? (the comment indicates "some recognizable output pattern, but > > that means little to me as is) Can we really be sure it doesn't make > things > > worse? > > I think it is intended to make preimage attacks more difficult. > > > Is this done elsewhere, or is it our particular brand of voodoo? > > I'm not aware of it being done elsewhere. Usually the recommendation is > to truncate, rather than fold hash output. > > IMO we should reassess the output hash. Something like Whirlpool might be > significantly faster given its large block size. > > -d
Re: MD5 Folding in kernel RNG
Hi Damien. On Tue, Dec 28, 2010 at 1:45 PM, Damien Miller 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. > But again, we perturb it immediately afterwards, so what good is such knowledge? Also, see next comment > > > RC4 generator? In which case, pulling off a preimage attack would be > > essentially miraculous. > > > And again, is this *ever* used directly, or is it simply the input to the > It is used to seed RC4. In the past it used to be used for other things, > but we switched them over to RC4 a while back. > So one would have to guess the MD5 output from the RC4 output in order to even pull off an attack like this. This kind of complete break would seem... unlikely... That was what I was getting at with my first query (how would a preimage attack matter in this case) > In any case, if there is not a good reason to keep it (since it's not > > standard practice), why not eliminate it? I just don't see what it > > accomplishes. > > I think the choice would be to truncate or to use the whole hash. > > Yeah, so without any good reason to truncate it, let's just use the whole hash, and hence, use all the entropy that we extracted from the pool. > This matters for userspace, but not for the kernel. We only start up one > RC4 > instance, so RC4's low key agility doesn't really bother us. > 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? -kj
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, say 8, you > are not winning the output performance vs output quality vs system > interactiveness tradeoff in any way. It is a loss in all respects. > > 2048 was estimated as a knee where it the setup cost for a seperate > RC4 is cheap enough so that PRNG data can be created for independent > kernel threads without contention/holding of the mutex. > > This mechanism was invented to improving interactive performance. However > it is still expensive. > Right. the arc4random_buf_large() mechanism will still get used, though, by anyone who calls arc4random_buf() with a big enough request, correct? And the setup time in this case will also be affected by the multiplier we choose for dumping initial keystream. I think I need to code up some test cases... -kj
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 deck of cards, 12 dice, and a large pot full of numbered balls... -kj
Re: mg:join-line
Good grief. Who builds emacs? Half of the point of mg is to avoid doing exactly that! ;) (The version I have here is 22.1.1.) By the way,if anyone looking for free commits, there are a bunch more missing undo boundaries in mg. I haven't yet had a chance to chase them all down properly... -kj On Mon, Jan 17, 2011 at 9:52 AM, Han Boetes 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 > here. Built 2 days ago, from git. > > ~% emacs --version > GNU Emacs 24.0.50.1 > > > > # Han
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 some other function) to start with. What > do you think? > > Hmm. You are right. I considered this problem once before (and could swear I remember solving it). Let me scour my drive for notes. A disable refcount might do the trick, ignoring re-enables until all nested boundary calls are done. will look at the rest of the diff shortly. thanks! -kj
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 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 version I have here)...
> I like it. If undo is a concern, then it might be a good idea to
> check the other functions while we're here.
>
> I found at least the following offenders in random.c:
> twiddle() might return early, leaving the boundaries disabled;
> openline() can open many at once, but each gets its own boundary;
> justone() makes two changes but doesn't set the boundary;
> lfindent() and newline() have the same problem as openline().
>
> There's also indent() which makes two changes, but it's not bound
> to a key and is only called via cmode, where the undo boundaries
> are in place already.
>
> 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 some other function) to start with. What
> do you think?
>
> The following diff fixes twiddle() and adds boundaries for openline(),
> justone(), and lfindent(). I leave newline() intact for now.
>
> --- src/usr.bin/mg.old/random.c Mon Jan 17 15:16:09 2011
> +++ src/usr.bin/mg/random.c Mon Jan 17 16:25:21 2011
> @@ -119,7 +119,6 @@ twiddle(int f, int n)
>
>dotp = curwp->w_dotp;
>doto = curwp->w_doto;
> - undo_boundary_enable(FFRAND, 0);
> if (doto == llength(dotp)) {
>if (--doto <= 0)
>return (FALSE);
> @@ -129,6 +128,7 @@ twiddle(int f, int n)
>if (doto == 0)
>return (FALSE);
> }
> + undo_boundary_enable(FFRAND, 0);
> cr = lgetc(dotp, doto - 1);
>(void)backdel(FFRAND, 1);
>(void)forwchar(FFRAND, 1);
> @@ -158,6 +158,7 @@ openline(int f, int n)
>return (TRUE);
>
>/* insert newlines */
> + undo_boundary_enable(FFRAND, 0);
> i = n;
>do {
>s = lnewline();
> @@ -166,6 +167,7 @@ openline(int f, int n)
>/* then go back up overtop of them all */
>if (s == TRUE)
>s = backchar(f | FFRAND, n);
> + undo_boundary_enable(FFRAND, 1);
> return (s);
> }
>
> @@ -223,8 +225,11 @@ deblank(int f, int n)
> int
> justone(int f, int n)
> {
> + undo_boundary_enable(FFRAND, 0);
> (void)delwhite(f, n);
> - return (linsert(1, ' '));
> + linsert(1, ' ');
> + undo_boundary_enable(FFRAND, 1);
> + return (TRUE);
> }
>
> /*
> @@ -318,10 +323,12 @@ int
> lfindent(int f, int n)
> {
>int c, i, nicol;
> + int s = TRUE;
>
>if (n < 0)
>return (FALSE);
>
> + undo_boundary_enable(FFRAND, 0);
> while (n--) {
>nicol = 0;
>for (i = 0; i < llength(curwp->w_dotp); ++i) {
> @@ -337,10 +344,13 @@ lfindent(int f, int n)
>curbp->b_flag & BFNOTAB) ? linsert(nicol, ' ') == FALSE
> : (
> #endif /* NOTAB */
>((i = nicol / 8) != 0 && linsert(i, '\t') == FALSE) ||
> - ((i = nicol % 8) != 0 && linsert(i, ' ') == FALSE
> - return (FALSE);
> + ((i = nicol % 8) != 0 && linsert(i, ' ') == FALSE {
> + s = FALSE;
> + break;
> + }
>}
> - return (TRUE);
> + undo_boundary_enable(FFRAND, 1);
> + return (s);
> }
>
> /*
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: 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. Remove unnecessary bzero call.
>
> 3. Document minor deviation from emacs behaviour in README.
>
> Index: README
> ===
> RCS file: /cvs/src/usr.bin/mg/README,v
> retrieving revision 1.8
> diff -u -p -r1.8 README
> --- README 1 Aug 2011 12:15:23 - 1.8
> +++ README 20 Mar 2012 17:54:12 -
> @@ -61,7 +61,9 @@ recognized as special cases.
> On systems with 16 bit integers, the kill buffer cannot exceed 32767
> bytes.
>
> -
> +Unlike GNU Emacs, Mg's minibuffer isn't multi-line aware and hence
> +some commands like "shell-command-on-region" always pop up a buffer to
> +display output irrespective of output's size.
>
> New implementation oddities:
>
> Index: def.h
> ===
> RCS file: /cvs/src/usr.bin/mg/def.h,v
> retrieving revision 1.118
> diff -u -p -r1.118 def.h
> --- def.h 10 Dec 2011 14:09:48 - 1.118
> +++ def.h 16 Mar 2012 04:59:14 -
> @@ -567,6 +567,8 @@ int prefixregion(int, int);
> int setprefix(int, int);
> int region_get_data(struct region *, char *, int);
> voidregion_put_data(const char *, int);
> +int markbuffer(int, int);
> +int piperegion(int, int);
>
> /* search.c X */
> int forwsearch(int, int);
> Index: funmap.c
> ===
> RCS file: /cvs/src/usr.bin/mg/funmap.c,v
> retrieving revision 1.36
> diff -u -p -r1.36 funmap.c
> --- funmap.c14 Mar 2012 13:56:35 - 1.36
> +++ funmap.c16 Mar 2012 04:59:14 -
> @@ -113,6 +113,7 @@ static struct funmap functnames[] = {
>{localbind, "local-set-key",},
>{localunbind, "local-unset-key",},
>{makebkfile, "make-backup-files",},
> + {markbuffer, "mark-whole-buffer",},
>{do_meta, "meta-key-mode",},/* better name, anyone? */
>{negative_argument, "negative-argument",},
>{newline, "newline",},
> @@ -166,6 +167,7 @@ static struct funmap functnames[] = {
>{setfillcol, "set-fill-column",},
>{setmark, "set-mark-command",},
>{setprefix, "set-prefix-string",},
> + {piperegion, "shell-command-on-region",},
>{shrinkwind, "shrink-window",},
> #ifdef NOTAB
>{space_to_tabstop, "space-to-tabstop",},
> Index: keymap.c
> ===
> RCS file: /cvs/src/usr.bin/mg/keymap.c,v
> retrieving revision 1.47
> diff -u -p -r1.47 keymap.c
> --- keymap.c14 Mar 2012 13:56:35 - 1.47
> +++ keymap.c16 Mar 2012 04:59:14 -
> @@ -135,7 +135,7 @@ static PF cXcar[] = {
> #endif /* !NO_MACRO */
>setfillcol, /* f */
>gotoline, /* g */
> - rescan, /* h */
> + markbuffer, /* h */
>fileinsert, /* i */
>rescan, /* j */
>killbuffer_cmd, /* k */
> @@ -257,7 +257,7 @@ static PF metal[] = {
>rescan, /* y */
>rescan, /* z */
>gotobop,/* { */
> - rescan, /* | */
> + piperegion, /* | */
>gotoeop /* } */
> };
>
> Index: mg.1
> ===
> RCS file: /cvs/src/usr.bin/mg/mg.1,v
> retrieving revision 1.58
> diff -u -p -r1.58 mg.1
> --- mg.19 Feb 2012 09:00:14 - 1.58
> +++ mg.116 Mar 2012 04:59:14 -
> @@ -196,6 +196,8 @@ call-last-kbd-macro
> set-fill-column
> .It C-x g
> goto-line
> +.It C-x h
> +mark-whole-buffer
> .It C-x i
> insert-file
> .It C-x k
> @@ -260,6 +262,8 @@ copy-region-as-kill
> execute-extended-command
> .It M-{
> backward-paragraph
> +.It M-|
> +shell-command-on-region
> .It M-}
> forward-paragraph
> .It M-~
> @@ -572,6 +576,9 @@ Bind a key mapping in the local (topmost
> Unbind a key mapping in the local (topmost) mode.
> .It make-backup-files
> Toggle generation of backup files.
> +.It mark-whole-buffer
> +Marks whole buffer as a region by putting dot at the beginning and mark
> +at the end of buffer.
> .It meta-key-mode
> When disabled, the meta key can be used to insert extended-ascii (8-bit)
> characters.
> @@ -734,6 +741,8 @@ Used by auto-fill-mode.
> Sets the mark in the current window to the current dot location.
> .It set-prefix-string
> Sets the prefix string to be used by the 'prefix-region' command.
> +.It shell-command-on-region
> +Provide the text in region to the shell command as input.
>
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 wrote: > On Tue, Mar 27, 2012 at 10:46:46PM -0400, Kjell Wooding wrote: > > s/irrespective/regardless/ > > > > there's nothing wrong with "irrespective". it's used correctly here (to > mean exactly the same as "regardless"). are you maybe confusing it with > the classic "irregardless"? > > "irregardless" is sometimes worth slipping in, in my opinion ;) > > jmc > > > 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. Remove unnecessary bzero call. > > > > > > 3. Document minor deviation from emacs behaviour in README. > > > > > > Index: README > > > === > > > RCS file: /cvs/src/usr.bin/mg/README,v > > > retrieving revision 1.8 > > > diff -u -p -r1.8 README > > > --- README 1 Aug 2011 12:15:23 - 1.8 > > > +++ README 20 Mar 2012 17:54:12 - > > > @@ -61,7 +61,9 @@ recognized as special cases. > > > On systems with 16 bit integers, the kill buffer cannot exceed 32767 > > > bytes. > > > > > > - > > > +Unlike GNU Emacs, Mg's minibuffer isn't multi-line aware and hence > > > +some commands like "shell-command-on-region" always pop up a buffer to > > > +display output irrespective of output's size. > > > > > > New implementation oddities:
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 *at all* wrong with "irrespective". you obviously just > don;t like it (if we don;t use words or phrases, they often sound odd, > or just plain wrong). but that's no reason to ask someone to change it. > > having said that, there is a huge bias towards "regardless" in the man > pages, and relatively few instances of "irrespective". perhaps it is no > longer fashionable. > > > "irregardless" is a hangable offense. > > > > aww! but it's so cute! > > jmc
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 scheme? Yes, emacs uses Lisp. But seriously, so? Why not just add, say, perl bindings? 4. Seriously, please be pedantic about licenses. Part of me dies when we see a new source file without one. I'm all for adding support for scripting into mg, though I would be tempted to rip out all nonessential functionality first (ng? ;) and add it back via the scripting language. I would think the goal should be to make mg significantly *smaller* any such change -kj On Thursday, June 28, 2012, Loganaden Velvindron wrote: > If Jasper is going to take care of it, why not :-) ? > > I'd like to get the ability to remap keys, without hacking src. > > (As an mg user) > > On Thu, Jun 28, 2012 at 2:06 PM, Mark Lumsden > > > wrote: > >> Here is an updated diff for mg with tinyscheme integration. It's based > on > >> tedu's original diff with various tweaks and changes. For those worried > about > >> mg being too bloated, rest assured, it's still small and lean and a big > part > >> smaller than vi ;-) > >> It's not fully possible to turn mg into your mail client, but I'd like > to commit > >> this diff and work on it futher in tree (not the mail-client thing, > that would > >> bloat mg and that's far from desired). > >> > >> Includes some fixes by lum@ and Sunil Nimmagadda too. > >> > >> Diff is also at http://crappydiffs.org/tinyschemg.diff > >> > > > > I would appreciate some feedback on the inclusion of this diff in mg > > since I am unlikely to use tinyscheme myself but can see why others > > would like it added. Are there are strong feelings about it either > > way? > > > > -lum > > > > > > -- > Brightest day, > Blackest night, > No bug shall escape my sight, > And those who worship evil's mind, > be wary of my powers, > puffy lantern's light !
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 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, not merely BSD, so this change is significant, > license-wise. > > Please be pedantic about including licenses. > > I'm no developer, but why not create an mg port where various capabilities > are added via FLAVORS? > > diana
