- wine-gitlab - winehq.org

Re: [PATCH v24 0/1] MR7843: cmd: Implement tab completion for command line entry.
by Joe Souza (＠JoeS209) 26 Apr '25

26 Apr '25

On Sat Apr 26 15:12:31 2025 +0000, eric pouech wrote: > looks to be that curPos can be \> \*numRead, hence reading garbage in > that case Line 312 terminates the buffer at *numRead, line 314 sets len to *numRead, and loop at 320 stops when !(curPos < len). Worst case is if curPos == len then we are checking the null terminator. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_101952

1 0

[PATCH v2 0/1] MR7888: wbemprox: Implement Win32_CacheMemory table.
by Paul Gofman (＠gofman) 26 Apr '25

26 Apr '25

-- v2: wbemprox: Implement Win32_CacheMemory table. https://gitlab.winehq.org/wine/wine/-/merge_requests/7888

3 3

Re: [PATCH v24 0/1] MR7843: cmd: Implement tab completion for command line entry.
by Joe Souza (＠JoeS209) 26 Apr '25

26 Apr '25

On Sat Apr 26 17:10:07 2025 +0000, Joe Souza wrote: > Paths need to be quoted if they are long file names or they contain > spaces, hence the check for findData.cAlternateFileName. To do what you're asking here we would need to track whether each level in the path requires quotes, not just the current filename. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_101950

1 0

Re: [PATCH v24 0/1] MR7843: cmd: Implement tab completion for command line entry.
by Joe Souza (＠JoeS209) 26 Apr '25

26 Apr '25

On Sat Apr 26 15:12:32 2025 +0000, eric pouech wrote: > I think quote handling is not done as it should > from what I see on native: quotes are added when generated word does > contain characters that would need to be escaped (eg ' ', but didn't > check all the others) > need quote is an attribute of current filename (ie they are removed when > the new (partial) matching file no longer needs them) ; so quotes > shouldn't be part of the SEARCH_CONTEXT, but only used for display > (basically: go to beg of word; if needs quotes, print quote; print > (partial) word; print ending quotes (if needed) Paths need to be quoted if they are long file names or they contain spaces, hence the check for findData.cAlternateFileName. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_101949

1 0

[PATCH 0/2] MR7884: odbc32: Fix some NULL pointer issues
by Stefan Dösinger (＠stefan) 26 Apr '25

26 Apr '25

I ran into this trying to use the Mac-Native MS SQL Server ODBC driver -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7884

3 3

[PATCH 0/1] MR7912: appwiz.cpl: Report addon download failures.
by Esme Povirk (＠madewokherd) 26 Apr '25

26 Apr '25

This relates to https://bugs.winehq.org/show_bug.cgi?id=58160 but doesn't fix it, just reports the error instead of stalling. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7912

2 1

[PATCH 0/1] MR7911: odbc32: Fix replicating unixODBC data sources.
by Hans Leidekker (＠hans) 26 Apr '25

26 Apr '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58140 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7911

2 1

Re: [PATCH v21 0/1] MR7843: cmd: Implement tab completion for command line entry.
by eric pouech (＠epo) 26 Apr '25

26 Apr '25

didn't play a lot with resulting code, mostly reviewed it note: dir "c:\\Programs Files\\"\<tab\> should circle among the subdirectories... current code doesn't also dir c\<tab\> (with a first file displayed), then reduce size of console window to be shorter than input line, will display input on line after the prompt -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_101938

1 0

Re: [PATCH v21 0/1] MR7843: cmd: Implement tab completion for command line entry.
by eric pouech (＠epo) 26 Apr '25

26 Apr '25

eric pouech (@epo) commented about programs/cmd/lineedit.c: > + } > + lstrcatW(searchstr, L"*"); > + TRACE("New search: [%s]\n", wine_dbgstr_w(searchstr)); > + > + sc.isDirSearch = IsDirectoryOperation(inputBuffer, inputBufferLength); > + } > + > + FindNextMatchingDirectoryEntry(searchstr, &sc); > + > + if (sc.haveSearchResult) { > + /* If this is our first time through here for this search, we need to find the insert position > + * for the results. Note that this is very likely not the same location as the search position. > + */ > + if (!sc.insertPos) { > + /* If user entered a backslash after quotes, remove the quotes. */ > + if (curPos > 2 && inputBuffer[curPos-2] == L'\"' && inputBuffer[curPos-1] == L'\\') { I think quote handling is not done as it should from what I see on native: quotes are added when generated word does contain characters that would need to be escaped (eg ' ', but didn't check all the others) need quote is an attribute of current filename (ie they are removed when the new (partial) matching file no longer needs them) ; so quotes shouldn't be part of the SEARCH_CONTEXT, but only used for display (basically: go to beg of word; if needs quotes, print quote; print (partial) word; print ending quotes (if needed) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_101937

1 0

Re: [PATCH v21 0/1] MR7843: cmd: Implement tab completion for command line entry.
by eric pouech (＠epo) 26 Apr '25

26 Apr '25

eric pouech (@epo) commented about programs/cmd/lineedit.c: > + } else { > + cc = len; > + while (cc > 0 && inputBuffer[cc] != L' ' && inputBuffer[cc] != L'\t') { > + cc--; > + } > + } > + } > + > + if (cc != sc->searchPos || inputBuffer[sc->searchPos] == L'\\') { > + cc++; > + } > + > + sc->insertPos = cc; > +} > + > +static void FindNextMatchingDirectoryEntry(const WCHAR *searchstr, PSEARCH_CONTEXT sc) a couple of comments here: * actually, this is not exactly how native (Win10) behaves: native captures the list of matching files at first tab usage, and doesn't update that list if eg. a file matching the pattern is added * the way done here is a bit more dynamic (as it would capture file creation/deletion), and I don't think it matters much from a user perspective the main thing I'm concerned about is that code to handle backwards shift-tab will be a bit more painful, and also the restart case (when the matched file is deleted) I think code would be simpler and more readable when storing the list of files, but I won't block on that. I let you pick up your favorite one. if you keep current logic, it seems to me that: * \-\>hadOneMatch is only used locally, and should rather be a local variable * \-\>hasSearchResult would make more sense be return value from this function -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7843#note_101936

1 0

2025

2024

2023

2022

wine-gitlab