From: Daniel Colascione <dancol@dancol.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Some comments about changes in revno 110444
Date: Mon, 08 Oct 2012 05:53:52 -0700 [thread overview]
Message-ID: <5072CCE0.9000108@dancol.org> (raw)
In-Reply-To: <83sj9p448h.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 6053 bytes --]
On 10/8/2012 4:01 AM, Eli Zaretskii wrote:
> This hunk removes w32inevt from SOME_MACHINE_OBJECTS. Why was that
> needed?
Merge problem. Fixed.
> To avoid confusion, I suggest to change the name of the variable here:
>
> + /* No, not utf-16-le: that one has a BOM. */
> + DEFSYM (Qutf_16_le, "utf-16le");
>
> to Qutf_16le.
Good catch.
> Isn't the below supposed to be done automagically by make-docfile,
> which puts these in globals.h?
>
> +EXFUN (Fcygwin_convert_path_to_windows, 2);
> +EXFUN (Fcygwin_convert_path_from_windows, 2);
The earliest version of this code targeted Emacs 23, which doesn't have a
globals.h. Fixed.
> I don't think this (from w32select.h) is a good idea:
>
> +#define HAVE_W32SELECT 1
>
> We only have definitions for HAVE_* macros in config.h and
> conf_post.h. Having them in other headers is confusing, IMO. Can we
> move this to conf_post.h instead?
We only used HAVE_W32SELECT in two places, so I just replaced HAVE_W32SELECT
with the conditional we use to include the header --- WINDOWSNT || HAVE_NTGUI.
> You moved the definitions of these from w32heap.c to w32fns.c:
>
> +/* The major and minor versions of NT. */
> +int w32_major_version;
> +int w32_minor_version;
> +int w32_build_number;
>
> but they are still referenced by w32.c via get_* macros defined on
> w32heap.h. Can we clean this up, please?
The bigger issue is that w32heap.c is WINDOWSNT-only, but w32heap.h declares
useful facilities that apply more generally (and that have nothing to do with
the heap). I created a new w32common.h for these common declarations and left
the WINDOWSNT-specific heap stuff in w32heap.h.
> Regarding this:
>
> +#ifdef NTGUI_UNICODE
> + wchar_t filename_buf[MAX_PATH + 1];
>
> I believe Unicode names on Windows are not limited to MAX_PATH
> characters.
You can use special syntax to exceed that limit ---
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
--- but nobody does in practice. Bear in mind that this code only deals with
the file open dialog box, which (the last time I checked) didn't support long
file names in the first place.
Still, I've increased the limit to 32k + 1, which is a hard NT kernel limit, in
the NTGUI_UNICODE case.
> It looks like there are some unnecessary hops here:
>
> + CHECK_STRING (prompt);
> + CHECK_STRING (dir);
> +
> + dir = Fexpand_file_name (dir, Qnil);
> +
> + if (STRINGP (filename))
> + filename = Ffile_name_nondirectory (filename);
> + else
> + filename = empty_unibyte_string;
> +
> +#ifdef CYGWIN
> + dir = Fcygwin_convert_path_to_windows (dir, Qt);
> + if (SCHARS (filename) > 0)
> + filename = Fcygwin_convert_path_to_windows (filename, Qnil);
> +#endif
>
> + CHECK_STRING (dir);
> + CHECK_STRING (filename);
> +
> + /* The code in file_dialog_callback that attempts to set the text
> + of the file name edit window when handling the CDN_INITDONE
> + WM_NOTIFY message does not work. Setting filename to "Current
> + Directory" in the only_dir_p case here does work however. */
> + if (SCHARS (filename) == 0 && ! NILP (only_dir_p))
> + filename = build_string ("Current Directory");
> +
> + /* Convert the values we've computed so far to system form. */
> +#ifdef NTGUI_UNICODE
> + to_unicode (prompt, &prompt);
> + to_unicode (dir, &dir);
> + to_unicode (filename, &filename);
>
> AFAIU, inside Fcygwin_convert_path_to_windows, you convert the names
> of the file and directory to UTF-16, then decode it back into a
> multibyte string, and finally encode it again to UTF-16 when you call
> to_unicode. Perhaps the back and forth conversion to and from UTF-16
> can be avoided?
This code isn't on a hot path. I'm reluctant to optimize it: I'm not sure the
additional complexity would be worth it.
> In any case, a call to CHECK_STRING after we already checked the
> arguments seems both redundant and user-unfriendly: these tests are
> designed to reject errors in arguments passed to primitives, so
> signaling an error because something went wrong in processing valid
> arguments doesn't sound like a good idea.
>
> This error will not report the offending file name:
>
> + if (SBYTES (filename) + 1 > sizeof (filename_buf))
> + error ("filename too long");
>
> I think report_file_error is better here.
Fixed.
> Why do you need the fprintf part here:
> #ifdef EMACSDEBUG
> void
> _DebPrint (const char *fmt, ...)
> {
> char buf[1024];
> va_list args;
>
> va_start (args, fmt);
> vsprintf (buf, fmt, args);
> va_end (args);
> #if CYGWIN
> fprintf (stderr, "%s", buf);
> #endif
> OutputDebugString (buf);
> }
Because tracing on stderr is useful. Strings sent to OutputDebugString are
invisible unless Emacs is being run under a debugger.
> What happened to number 21 in the change below?
Bad merge. Fixed.
> #define WM_EMACS_HIDE_CARET (WM_EMACS_START + 18)
> #define WM_EMACS_SETCURSOR (WM_EMACS_START + 19)
> #define WM_EMACS_PAINT (WM_EMACS_START + 20)
> -#define WM_EMACS_BRINGTOTOP (WM_EMACS_START + 21)
> -#define WM_EMACS_END (WM_EMACS_START + 22)
> +#define WM_EMACS_BRINGTOTOP (WM_EMACS_START + 22)
> +#define WM_EMACS_INPUT_READY (WM_EMACS_START + 23)
> +#define WM_EMACS_END (WM_EMACS_START + 24)
>
> Why did you need the call to notify_msg_ready below?
>
> @@ -285,7 +309,7 @@ prepend_msg (W32Msg *lpmsg)
> nQueue++;
> lpNew->lpNext = lpHead;
> lpHead = lpNew;
> -
> + notify_msg_ready ();
The call to notify_msg_ready is needed because after a call to prepend_msg, a
message is now ready. It should have been there all along.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
next prev parent reply other threads:[~2012-10-08 12:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-08 11:01 Some comments about changes in revno 110444 Eli Zaretskii
2012-10-08 12:53 ` Daniel Colascione [this message]
2012-10-08 13:50 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5072CCE0.9000108@dancol.org \
--to=dancol@dancol.org \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.