gmane.emacs.devel

Re: MS-Windows build using Posix configury

Stephen Leake — 2013-05-21T19:36:36


Ok; INSTALL should say that. The point is to make clear what your
reasons are, so if I decide to ignore your advice, I know what the
issues are.

I had the same complaint about the Cygwin installer; it used to complain
if I installed to c:/ (requiring an extra confirming click), without
saying anything about why that might matter, leaving me to wonder if
Cygwin would break in some way. In that case, there was a rationale
posted online, which boiled down to "users might have other stuff
installed at c:/". 


I'm one :). I don't use Cygwin Emacs, because it doesn't work well
with the MinGW and native Windows tools I use. Although that may have
improved since I first played with this, back in Emacs 21 days. I do use
Cygwin bash and make, under native Emacs; that works well.

Re: reveal-filename

Stefan Monnier — 2013-05-21T19:37:24

Thanks, no hurry,


        Stefan

Re: [PATCH] Make `C-x {' and `C-x }' repeatable

Juri Linkov — 2013-05-21T18:34:04

Thanks for this useful feature.  I am experiencing the same difficulties
with `C-x }' and `C-x {', so your feature would be of a great help.


Please make the keymap user-customizable, e.g. if you'll create
a separate keymap with a name like `window-size-adjust-keymap' then
users would be able to add more keybindings in ~/.emacs like:

  (define-key window-size-adjust-keymap [right] 'enlarge-window-horizontally)
  (define-key window-size-adjust-keymap [left]  'shrink-window-horizontally)
  (define-key window-size-adjust-keymap [down]  'enlarge-window)
  (define-key window-size-adjust-keymap [up]    'shrink-window)

to use arrow keys for window resizing.  Then having such map
you could just add one line:

  (set-temporary-overlay-map window-size-adjust-keymap)

to the end of all these four functions to implement this feature.
I mean changing existing commands:

(defun shrink-window-horizontally (delta)
  (interactive "p")
  (shrink-window delta t))

to

(defun shrink-window-horizontally (delta)
  (interactive "p")
  (shrink-window delta t)
  (set-temporary-overlay-map window-size-adjust-keymap))

and the feature will just work without creating a "dispatcher" kind
of function `window-size-adjust'.  This will preserve the current global
keybindings (i.e. `shrink-window-horizontally' still bound to `C-x {' etc.)
and provide more customizability.

Then remaining possible improvements would be adding an option
to disable this feature (I think it should be enabled by default),
adding an informative echo-area message about available keybindings,
adding a keybinding (like `RET' in `isearch-mode') to exit a keysequence
of resizing keys, etc.


It's very difficult to find a free global keybinding for
such less frequently used commands.  But there is no need
because users could use the existing global keybindings
to initiate a window-resizing keysequence and use other keys
from the map for more fine-grained resizing.

Re: emacs takes exhorbitantly long to read long, one-line files.

Dmitry Antipov — 2013-05-21T18:28:44


RTSL, it's better to start from comments in xdisp.c and dispextern.h.

Dmitry

Re: global-auto-revert-mode and file time stamps

Michael Albinus — 2013-05-21T18:17:10


Hi,


I could reproduce the problem. I will check tomorrow what's up. Likely,
it is because the new file change notification mechanism introduced with
Emacs 24.3.50.

Best regards, Michael.

Re: emacs takes exhorbitantly long to read long, one-line files.

Randy Yates — 2013-05-21T18:03:54

Allow me to take a look. Are these algorithms documented? Or is it RTSL?

Re: emacs takes exhorbitantly long to read long, one-line files.

Eli Zaretskii — 2013-05-21T17:55:33

I see no degradation in performance: both 4 sec and 6 sec, let alone 9
and 34, are the same as infinity.  You cannot have any useful editing
with such reaction times to a simple cursor movement command.  It is
therefore meaningless to compare such "performance" figures and draw
any conclusions from them.

Emacs 24 has got a bidirectional display engine.  Bidirectional
display needs to do much more work than the previous unidirectional
one in Emacs 23 and before.  In a nutshell, where the unidirectional
display simply incremented a pointer, the bidirectional display calls
a complex function that does some very non-trivial processing based on
the bidirectional class of each character.

Now, this sounds scary, but really isn't.  The bidirectional display
was optimized so that in all the known uses where the old display
provided reasonable performance, the new one does, too.  While the
bidi display is still slower than the unidirectional one, the
optimizations keep the slowdown in check, such that the delays are
below humanly perceptible threshold on reasonably modern and even
fairly old machines.  (I developed and debugged most of the code on a
7-year old machine that died less than a year ago.)

By contrast, use cases such as the above, where the old code performs
abysmally inadequately, were explicitly excluded from the scope of the
optimizations, because it doesn't make sense to punish 99.9% of users
on behalf of the rest.  And that is what you see above.

Emacs needs some non-trivial changes in display-related algorithms to
adequately support very long lines.  When those changes are designed
and implemented, I promise you that the bidirectional display will
keep up.

Re: emacs takes exhorbitantly long to read long, one-line files.

Eli Zaretskii — 2013-05-21T17:21:16

Not sure the bidi display is involved in 6 vs 4 sec, but you should
know that turning off bidi-display-reordering doesn't revert all the
differences between the old unidirectional display and the
bidirectional one.  It was never meant to do that in the first place.

Re: emacs takes exhorbitantly long to read long, one-line files.

Eli Zaretskii — 2013-05-21T17:18:24

2 to 3 times in my experience, unless you specifically choose
character classes to trip the bidi iterator.

Re: MS-Windows build using Posix configury

Eli Zaretskii — 2013-05-21T17:07:50

Yes, "make install" will create it, but that's not the point.  See the
second part of the sentence I wrote and you quoted above.  The point
is that I want to encourage people to install ports of GNU and Unix
software in a single tree, so that they all play together well without
a lot of tinkering with environment variables.  And _since_ there
usually is not /usr/local on Windows systems, I doubt that /usr/local
will be a good guess of where people might put such a tree.  So I
_want_ them to think about the root of that tree, and I want them to
use that in the --prefix option.


Are there such users who don't prefer Cygwin instead?


Actually, still yes, although for a slightly different reason ;-)

Re: Any posibility get non-dw2 libiconv2-dll and libintl-8.dllforgnutls/libxml2 emacs-compatible

Eli Zaretskii — 2013-05-21T16:45:07

The small print near the end of that page says "last edited
2011-03-23".  So this is more than 2 years old now, and clearly
outdated, as the name of the libgcc_s_dw2-1.dll tells you (that "dw2"
part does stand for DWARF 2").


I'm glad you solved your problem, but that cannot be the solution for
everyone else.  There are at least 3 different chains of GCC and
related tools ported to Windows; supporting only one of them, and not
the main one at that, cannot be good enough.  FWIW, that's the first
time I heard from anyone that they build Emacs with TDM; most use the
tools provided by mingw.org, and a few reported they use MinGW64
tools.  I have nothing against supporting TDM as well, but forcing
users to use only that is a non-starter.


If you follow that, you already know that there are no firm
conclusions reached in that discussion yet.  Until the upstream GCC
maintainers say their definitive word on this, raising the issue here
is not very useful.


That's not true, at least not with the GnuTLS and libxml2 distros from
my ports (on http://sourceforge.net/projects/ezwinports/files/).  I'm
quite sure that if you have those dependencies, you got libintl and
libiconv from some other place, not from those zip files.  Please
double check.  With the DLLs that I provided in the zip files, there's
no dependency on libgcc DLL, and no crashes at all.  (I will never
ever produce any port that depends on libgcc as a shared library, for
reasons that have nothing to do with the issue at hand here.)


Sorry, but I will only use one toolchain, and currently that is the
toolchain distributed by mingw.org.  I cannot afford to have more than
one development environment, and I cannot invest more effort I already
do in porting optional libraries.  Moreover, since the problem with
libgcc_s_dw2-1.dll doesn't happen with my ports, I see no reason to
switch to TDM toolchain in the first place.

The problem which I'm trying to solve, and which prompted me to start
a discussion on the GCC list, is that I'd like this to work with any
GCC-based toolchain.  So switching to TDM, even if I wanted to, is not
the solution at all.

Eventually, with help from the GCC maintainers, we will crack this
problem, and find how to solve it.  I really suggest that people wait
for a little bit more; in the meantime, as already written in the
other thread here that raised the issue, using the DLLs from my ports
is a much easier work-around than switching to a completely different
development environment.

Re: reveal-filename

Eli Zaretskii — 2013-05-21T16:22:09

The problem is, it can be neither.  If the argument is just "foo", it
will be returned unchanged.


Well, that will be changed when the function is renamed.

Re: reveal-filename

Eli Zaretskii — 2013-05-21T16:20:31

Will do.

Re: reveal-filename

Eli Zaretskii — 2013-05-21T16:19:24

But that's what the function does, no less, no more.  And yes, it's
ad-hoc, because it simply works around an MSYS bug (I tried to find
other solutions, but failed).


When the function is extended to do that, it would make sense to
change the doc string along these lines.  For now, saying that would
be simply incorrect.

Re: [PATCH] Make `C-x {' and `C-x }' repeatable

Gauthier Östervall — 2013-05-21T13:53:34

It would. It could even work after entering with C-x {, and { could
work after entering with C-x ^. For example:
C-x { { { { } } ^ ^ }
C-x ^ ^ } }
could be valid sequences.

One problem is that there is currently no standard key binding for
(shrink-window). That would need to be decided upon first. Having
(enlarge-window) and not its opposite would not work well.

Even more, + (balance-windows) could be included (and possibly exit
this resize mode).
Same thing with - (shrink-window-if-larger-than-buffer).

I'm willing to implement (balance-windows) as a second step if this
patch is accepted.

I nearly never `C-x -' or `C-x ^', but I could put it in once there is
an opposite to `C-x ^', for completeness. How are standard key
bindings decided upon, may I just come up with something?

global-auto-revert-mode and file time stamps

Timur Aydin — 2013-05-21T13:40:44

Hi, I have sent this message to help-gnu-emacs, but I thought maybe 
development list is better, because I am using a development version. 
Here it goes:

When a file's timestamp has been changed, but the contents are still the
same, what should be the behavior of emacs be? With the emacs that I am
using (development version):

GNU Emacs 24.3.50.1 (i686-pc-linux-gnu, GTK+ Version 3.6.3)
  of 2013-05-01 on bonsai

It thinks the file is changed. Here is what I do:

- Open a file, edit it and then save.

- use the "touch" command to update the time stamp of this file.

- Wait way more than the auto revert interval (which is set to 5 seconds
in my case).

- Try to make a change to the buffer corresponding to this file.

At this point, emacs says that the file has changed and asks whether I
really want to edit it. I was expecting emacs to auto revert this buffer
and allow me to edit it without further questions. So my question is, am
I looking at a bug, or a feature?

Re: emacs takes exhorbitantly long to read long, one-line files.

Ulrich Mueller — 2013-05-21T12:06:04



It's 6 s / 11 s then.

Ulrich

Re: emacs takes exhorbitantly long to read long, one-line files.

Dmitry Antipov — 2013-05-21T10:20:58


Can you try 24.3 with (setq-default bidi-display-reordering nil)?
With BIDI disabled, it shouldn't be 4x at least.

Dmitry

Re: [PATCH] Make `C-x {' and `C-x }' repeatable

Vitalie Spinu — 2013-05-21T09:58:36

I think this is a very nice idea. Similar change would make sense for
C-x ^.

    Vitalie

 >> Gauthier Östervall <gauthier< at >ostervall.se>
 >> on Mon, 20 May 2013 21:59:06 +0200 wrote:

 > Ever since I started using emacs and tried to say good bye to my
 > mouse, I have felt that the resizing of windows with `C-x }' and
 > `C-x {' is too cumbersome to use.

 > - Typing `C-x }' several times in a row is not practical.
 > - I always undershoot when using things of the form `M-10 C-x }'
 > - I alway overshoot when using `C-x } C-x zzzzz'

 > This branch makes `C-x {' and `C-x }' behave similarly to `C-x
 > C-+' (text-scale-adjust).  After the original `C-x }' (or `C-x
 > {'), additional `{' and `}' continue to resize the window, until
 > the user enters another character.

 > The change is in lisp/window.el, which has dynamic scoping.  I
 > understand that this new function would be better with lexical
 > binding, allowing for a clean closure.  However I do not feel
 > confident enough (yet) with dynamic scoping to change the file's
 > binding mode by myself.

 > Please tell me if I should have done that differently, and I'll
 > try to implement it.  I'd be happy to see window.el get lexical
 > binding, and use a closure instead of a macro.   If the patch is
 > acceptable as is, it would be very nice to see it integrated.

 > Note that this is my first patch to GNU Emacs and with bzr.  I
 > might for example have missed indentation conventions (no tabs in
 > the new function, only spaces), but I could not find info about
 > tabbing conventions on the wiki or gnu.org (a link would be
 > welcome, if available).  Please guide me if I missed other
 > standard things.

 > https://code.launchpad.net/~gauthier-i/emacs/resize-window-repeatlp:~gauthier-i/emacs/resize-window-repeat
 > Launchpad says that the branch is "Updating" and "empty", and has
 > been saying so for days.  Weeks, really.  The code seems to be
 > there though.  Tell me if it's not reachable for you, and if you
 > have suggestions for how to fix it, it'd be nice.

 > Otherwise, here's the bundle:

 > # Bazaar merge directive format 2 (Bazaar 0.90)
 > # revision_id: gauthier< at >ostervall.se-20130520193632-fm01gjdl38ux3egc
 > # target_branch: file:///media/sf_prog/emacs/trunk/
 > # testament_sha1: 6d88925597179e2c8c55153d5f9c62703d6ecd68
 > # timestamp: 2013-05-20 21:51:05 +0200
 > # base_revision_id: rgm< at >gnu.org-20130430101735-ccy06l3ndx4vrj18
 > #
 > # Begin patch

 > === modified file 'lisp/ChangeLog' (properties changed: -x to +x)
 > --- lisp/ChangeLog2013-04-29 20:09:18 +0000
 > +++ lisp/ChangeLog2013-05-20 19:36:32 +0000
 > < at >< at > -1,3 +1,7 < at >< at >
 > +2013-05-20  Gauthier Ostervall  <gauthier< at >ostervall.se>
 > +
 > +* window.el (window-size-adjust): New function.
 > +
 >  2013-04-29  Leo Liu  <sdl.web< at >gmail.com>

 >  * progmodes/octave.el (octave-font-lock-keywords): Handle 'end' in

 > === modified file 'lisp/window.el' (properties changed: -x to +x)
 > --- lisp/window.el2013-04-13 14:37:20 +0000
 > +++ lisp/window.el2013-05-07 12:13:36 +0000
 > < at >< at > -6025,6 +6025,48 < at >< at >
 >    (interactive "p")
 >    (shrink-window delta t))

 > +;;;###autoload (define-key ctl-x-map [(?{)] 'window-size-adjust)
 > +;;;###autoload (define-key ctl-x-map [(?})] 'window-size-adjust)
 > +;;;###autoload
 > +(defun window-size-adjust (inc)
 > +  "Adjust the width or height of the current window by INC.
 > +
 > +INC may be passed as a numeric prefix argument.
 > +
 > +The actual adjustment made depends on the final component of the
 > +key-binding used to invoke the command, with all modifiers removed:
 > +
 > +   {      Decrease the window width by one step
 > +   }      Increase the window width by one step
 > +
 > +When adjusting with `{' or `}', continue to read input events and
 > +further adjust the windows width as long as the input event read
 > +\(with all modifiers removed) is `{' or `}'.
 > +
 > +This command is a special-purpose wrapper around the
 > +`enlarge-window-horizontally' command which makes repetition convenient
 > +even when it is bound in a non-top-level keymap.  For binding in
 > +a top-level keymap, `enlarge-window-horzontally' or
 > +`shrink-window-horizontally' may be more appropriate."
 > +  (interactive "p")
 > +  (let ((ev last-command-event)
 > +        (echo-keystrokes nil))
 > +    (let* ((base (event-basic-type ev))
 > +           (step
 > +            (pcase base
 > +              (?{ (- inc))
 > +              (?} inc)
 > +              (t inc))))
 > +      (enlarge-window-horizontally step)
 > +      (message "Use {,} for further adjustment")
 > +      (set-temporary-overlay-map
 > +       (let ((map (make-sparse-keymap)))
 > +         (dolist (mods '(()))
 > +           (dolist (key '(?{ ?}))
 > +             (define-key map (vector (append mods (list key)))
 > +               `(lambda () (interactive) (window-size-adjust (abs ,inc))))))
 > +         map)))))
 > +
 >  (defun count-screen-lines (&optional beg end count-final-newline window)
 >    "Return the number of screen lines in the region.
 >  The number of screen lines may be different from the number of actual lines,
 > < at >< at > -6734,8 +6776,8 < at >< at >
 >  (define-key ctl-x-map "3" 'split-window-right)
 >  (define-key ctl-x-map "o" 'other-window)
 >  (define-key ctl-x-map "^" 'enlarge-window)
 > -(define-key ctl-x-map "}" 'enlarge-window-horizontally)
 > -(define-key ctl-x-map "{" 'shrink-window-horizontally)
 > +(define-key ctl-x-map "}" 'window-size-adjust)
 > +(define-key ctl-x-map "{" 'window-size-adjust)
 >  (define-key ctl-x-map "-" 'shrink-window-if-larger-than-buffer)
 >  (define-key ctl-x-map "+" 'balance-windows)
 >  (define-key ctl-x-4-map "0" 'kill-buffer-and-window)

 > # Begin bundle
 > IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWUR/XcIAA/JfgH74WPf///+n
 > ho7////6YAkK7fS3YOIhVusmxkEqACmjWEiiJkxDKPTRppPVHpPU/VGQZI0GRoMIMCB5QSiJk0MS
 > aegonoQ0NDQNAAaAAGQGg5hNAaA0aMI0GI0xMmJoMI0DIBkwEpoUKaNT1N6gGpg0hgABqZkIwhoZ
 > oTAOYTQGgNGjCNBiNMTJiaDCNAyAZMBJEEyCMJNT01PJpMmNQT0k2EnpkgNAAabRK6mNCpOOvNw/
 > OIe/dNMDz+/5GP6nDKPHn45+VmllrIPBUm1m4uQt3tbOqpYhDglwOvchbLk+9SIm0crpRhHhgZOW
 > rUZ5CqssSQoh2dsEB87ObMs5sMOy89x49p/GqG68xIs5uTEfC1Corm0aJWgQjKwBYkxGVuVmTJKS
 > Cpdmy+RTBmujjTpNTI7nJnUYsLmtuZuvHyK+Z838rpjofnMsh9ll/PXruCQbxjgNl+MjHWYjPbrL
 > PfdaRrhyhImt5hzK2llPVWWRxFs3y0ZYWaKXZWFm/hatpRXPCLCOFQTb+nLm+VmkqxarFbdAZB0I
 > FUBRx02V7TN3ZYrYWwO/bn3ddT0w34eo85PfOmnZ8xSnlBmSZgY+S+IuCyJKxBcQX1txgdQTA5fe
 > 9evXaqhvFX+RyaH5XsYcr6davd/jjFG5uMV56sspl3mea+iIUz4SRdObCF8uEtVk1vb+Z8u8tMjD
 > 6RWiSsPDocggnpan18xfNB7A9hIoL24lviHuPqFDS0rAcCsLfLA+1l8AoEnnTg88Gx6Mq24BjsUE
 > g8pjPVc7v7PjhYl8m6XdMQf4cYIPI6JQQhkwsuIva5snJkML4ugoScTa11II9VPfjSCVwsAvGpjC
 > wgx+T0KFhJ7sgla6InM+TrcF/oIiREy0HDyRNA+Ntk1dAqQQc60TBAkVREUzMOPnl5bRMo4E0vjn
 > rpWO4/6kUTatEV4UM7XOHGlCoTHSlw1EszoojGHE0EJCVvE4DOaBazVGTqVgb2Nca7GLEuBkZnOk
 > Myd6ouiAIrUciQE6SxVarDNBUiKapYWRN4q7ETV1pZ5jjs5P2iwnetEGrOTvqfhHJJ9OozFSUI7R
 > lBXJxW57DOcSOhsg4NAfXrY15lpkkNWF80VAvUuVEmmsfBG6mriy1pDHbe/mEy0Ez1alQJ5TGK0z
 > UR8l0JHPtITWDcWPoYoMLijXpuZoFUJxFvlmbB1qBeQ3ihcqVC4xY2vhQGXUMBHb287GZvCbtbYm
 > M61heaWle3OzKhK6swKvQbIc4kFpMVyCFYtjAV+0lDC2wVk3wk1eGVgkimCvnllleNlQ1Ka4j8oN
 > JsOLHixuMgtaZtLC4vJkkPYZjhYOJgsJKyE0USpEY+YuxHBM6S+kZq8LbUG1ce0gdQZ3umyWIgnq
 > naYmP/eOGC0KeOmgkqeZJ7yQoalOLNKbJjDgbnDAdlU7YWtQwjmAv04lJgSHbPUtvXsNPloY734F
 > IxNYXvsVErPV+Lj+3c/g3gqjCDJHomOUtJjjMbkMkaRj6NgioQHi6yMNB5Tqo79bkD/q8RB+CgWe
 > Ns3k6r3pIkm/ph5OTXzc/l26LJjCj6tB1GCDNVQoVEMRRDaZAYQNCIQrMi2tZG2zrlNZ3+Epyqnj
 > ogc+qsfV4rC6T5ZTWcwcLFSaogIdxzRaCUKGTpnQkXLeOdCvJIlIXKBuI0mJ5bdLtr8TkLHqnYHM
 > 1EF/thGfvFUkkiY2sT4iguzupzXV54e6OMHXXlQgvIzea8rQhJDlrJL1gUsRCy9SPUTO8nu1WHhD
 > frnzhwVLy0qJljc9THA0ko0oFxay5Y8Pu6Oisxm+m/7TkqphIaRZZFRaLYYTwLh1oqd4u4XUdGoa
 > orrNG+Bzd/4EQ4LEz1GDbh+n8Dv69kqkHHHYdJhVBltZ5q0thLRvNAmIGI1rlIoTQjzn3ES8KI7V
 > qurj6ZHU/ri9QKfbAnqS1Arz0nXkcTgNz7TvFI7errfmdwWi3i/0ZmiqLcLbAPEvYlBTaaCYaMMt
 > y1oPrPrGtBhxnvVwr7ExUZJh8NBOv+IbeLyMy5AfkQMJF/rE2jTb2dfelINCM0+xTOnpvSmVpvhP
 > WpuiGsoO0TNIRlQjEznSKqW+UUZQrCLyZ88ku6XpImjSl/qZ65MrlA5G8oSitgzC6YLRvUB6UeaN
 > auz4jOSkFO60t4vOg5RLfQzcZNu7eivXCA3FLVxYsTjjediGYQiIMJAML0rMCJEC/WrzPjaXsOMT
 > Wo8DIhMBZHw2EESWBfqTsiG0XD0blY175dIYqMXPH/LE0RNWjHSZFeskHVeZCqTY0LSgShrqDwZh
 > rXQ7BNiNh9ToifssTjNY7hEAIeKoQQy91YQZEw0LJRHTudgmgJTQ4w4nZK9OSi6XkzDz26ILhdK2
 > B0XH0IndHtLl3AaijLsZJzwOVromq0GU3ZfTN4JU7Ne5bAsRKYoP7BBt7r6nRoZMhHTuYYXc7rvL
 > R6GfmGGFJ+zrkHbVTydrRyHxmSxvKtxvLcCzLiBFYJhkyo6UubgiKWw7HxQMXHE5VgYlwh8BtQ0n
 > OJAKqYRTYTb0eWYZqI6OBKas2KY7jk2QhkWjiYFtkroahNLYQjbbEzqeK5ZCyZFXb3UlTQOq64DU
 > 4NcybM+F+QEQNRIbWZMmaRLbv+SCwK4FgzMk7QJ4MYfotggpYopcmuqZhdMupEmb04mSQVDujVh4
 > whyQfCIYkgkR8YY+tZSQQjFHaXrQICW4vQi4znEyCpaR5LFhRLQtTa4xSsSZqsKhGXlFFa9TnWgy
 > OcHDEww5XkiJ0iUSJoAvuFofZohHrFsN+omtbJhM7APlOpJBiRw1CNgp4H7hCHh+9wIvITnvFYg1
 > UAejiKS3INafigcC7aOG05PEdmTkYqDG5ZFDaCptDM4mpVfsJqtQiGuu8yQR7i7kinChIIj+u4Q=

Re: MS-Windows build using Posix configury

Stephen Leake — 2013-05-21T08:31:16


That's a good point.


I assume 'make install' will create the directory, so that's not a
problem.


Right. I forgot that 'make install' is run from an MSYS shell, not a DOS
or Cygwin bash shell.


That would be true for naive users. 

For Emacs users used to customizing things on Linux, the additional
information is helpful. A pointer to a thorough discussion of MSYS
issues would be very nice, but I don't think such a thing exists :(.

A pointer to an Emacs W32 FAQ would be another choice.


Actually not, since MSYS treats "/usr/local" as Cygwin
"/cygdrive/c/MSYS/local".

Re: emacs takes exhorbitantly long to read long, one-line files.

Ulrich Mueller — 2013-05-21T07:57:35




I've done this test for a file with one line of 16 MB, and I get the
following times for the first and second commands (emacs -Q -nw in
an 80x24 xterm):

  Emacs 23.4:   4 s /  9 s
  Emacs 24.3:  16 s / 34 s

Is this degradation of performance expected?

Ulrich